HTTP/2における双方向通信とgRPCとこれから - Qiita
この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
初めてのHTTP/2サーバプッシュ | GREE Engineering
前回はWebサイトをHTTP/2に対応するためにリバースプロキシを検証した記事を書かせていただきました(HTTP2を試してみる)。 あれから幾つかの議論を経てHTTP/2の仕様も大分安定してきており、HTTP/2を実装したクライアントや実験的にHTTP/2を有効にしているサービスもあるので実際に試すことも出来ます。 そこで今回は応用編としてHTTP/2のサーバプッシュについて、その仕組と実際に試したことについて書かせていただきます。 余談ですが、 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称になります。 HTTP/2概要 まず、軽くHTTP/2の概要に触れておきます。 HTTP/2は2012年の末頃より、HTTP/1のセマンティクスを維持したままパフォーマンスを改善する目的で議論が開始されました。 Googleの考案したSPDYと言
WiresharkでHTTP/2をパケットキャプチャする - ASnoKaze blog
20190417追記 HTTP/3はこちら「WiresharkでのQUICの復号(decrypt) - ASnoKaze blog」 20151030追記 TLSを利用するHTTP/2では、秘密鍵を設定しても通信を復号することは出来ません。 HTTP/2の鍵交換はPFSなので、下記も参考にして下さい 「Wireshark で HTTP/2 over TLS の通信をダンプする方法」 https://gist.github.com/summerwind/a482dd1f8e9887d26199 この記事は HTTP2 Advent Calendar の 9 日目の投稿です。 初めましてゆきと申します。HTTP/2アドベントカレンダーにはガチ勢しかおらず戦々恐々としております。 アドベントカレンダーネタとしては、Push周りを書こうとしてたのですが先日Push周りの素晴らしい記事が投稿されてし
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP2 最速実装 〜入門編〜