今回は静かなブームになっている、HTTP/2とQUICプロトコルについて記事としてまとめました。
HTTP/2のメリット
簡単に言うとサーバとクライアントとの通信が多重化され速くなります。多数のHTTPリクエストやレスポンスを1本にまとめて通信ができるようになります。他にはHPACK(RFC 7541)によるヘッダ圧縮など。
スマホ端末増加で生じてきたRTT遅延の軽減
- TCPを用いるアプリケーションの最大スループットは,往復の遅延時間(RTT:Round Trip Time)の影響をうける
- ウィンドウサイズが64Kバイトの場合のTCP最大スループットの理論値は以下のとおり
もっとも,ネットワークに接続しているPCが100台あって,それぞれが何らかの通信を行っている場合,100台のトータルでは100Mbpsの帯域幅を使い切ることが可能です。ですから,通常の用途であれば,遅延が大きな問題になることは,あまりないと思います。
しかし,遅延が問題になるケースもあります。代表的な例は,国際間通信とモバイル通信です。
@see ネットワークにかかるさまざまな遅延要素
RTT(Round Trip Time:往復遅延時間)
ただ実際のところ、ある程度の規模のサービスでないと体感できない程の差です。まだまだHTTP/2自体が開発途上のようで、大規模なサービスの通信でかなり差が出てくるのかなと。
対応ブラウザ
Chrome, Firefoxの最新版はHTTP/2に対応しています。
HTTP/2を利用するのに必要な設定はとても簡単!
また、HTTP/2に対応していないクライアントはHTTP/1.Xで通信が行うように柔軟に実装されているので、せっかくHTTPS通信を提供しているサーバであればHTTP/2を設定しないのは損な気がするけど、今実装していないからといって、大きいサービスでなければまだ実装を急がなくても良いもの。
※弊社公式サイトは今月中に別のサーバに移転する予定があるので、その時にでも(ㆁᴗㆁ✿)
NginxにHTTP/2を設定しよう
1 2 3 4 5 6 7 8 9 10 11 12 13 |
server { #listen 443 ssl; listen 443 ssl http2; ←http2と記述します server_name example.com; (略) ##SSL 証明書の設定 ssl_certificate /etc/pki/tls/certs/example_com_combined.crt; ssl_certificate_key /etc/pki/tls/private/example_com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; (略) |
HTTP/2の確認方法
Chromeのアドオンの『HTTP/2 and SPDY indicator』を使うのが簡単かなと。
【拡張機能を追加】をクリックでインストール出来ます。
HTTP/2の通信を見てみよう
HTTP/2の対応のサイトにアクセスすると青く光ります。
QUIC
QUICプロトコルも対応しているサイトだと緑になる模様です。
QUICプロトコル
QUICは機能的にはTCP+TLS+HTTP/2と同じであるが、QUICはUDPの上に実装される。QUICのTCP+TLS+HTTP/2より優れてる点は以下のとおりです
- コネクション確立のレイテンシ
- 柔軟な輻輳制御
- ヘッドオブラインブロッキングの無い多重化
- ヘッダとペイロードの認証及び暗号化
- ストリーム及びコネクションのフロー制御
- 前方誤り訂正
- 接続のマイグレーション
多重化
TCP上のTHTP/2は、TCPのヘッドオブラインブロッキングの影響を受けます。HTTP/2は多くのストリームをTCPの単一バイトストリーム上に構成するため、TCPセグメントの損失は再送が届くまで多くの後続の処理に影響を与えます。
QUICは多重処理のためにゼロから設計されているため、損失したパケットは、そのパケットが転送していたストリームにしか影響しません。それぞれのストリームにおいてフレームが届いた順に処理ができ、損失のないストリームはそのまま処理を進められます。
Googleが開発しているプロトコルで、特長としてHTTP/2のフレームをTCPでなく、UDPパケットとして送受信をしていて、現在既に実装されています。
HTTP/2もQUICプロトコルは、システム側で当たり前に実装しているような、そんな静かなブームになりそうな気がします。サーバ証明書無償化サービスが出てきたりと、WEBのHTTPS化の波はばんばん感じていますが、お客様から『HTTP/2で』という注文はまだまだ先かなと見ています。
引き続き動向をチェックしたいと思います。
お疲れ様です。