あすのかぜ

HTTP/2の運用に関する考察のI-D

HTTP2.0

5月末に、「HTTP/2: Operational Considerations for Servers」というI-Dが公開された。

サーバでHTTP/2対応する際の、パフォーマンスや運用性に関する注意点などが述べられている。

主な項目は以下の通りである

1. TCPの設定
2. TLSの設定
3. ロードバランスとフェイルオーバー
4. HPACKの使用
5. フロー制御の使用
6. 優先付けの使用
7. サーバプッシュの使用

（ただし、4〜7についてはTBDとなっている）

書かれていることについてざっとメモ...

TCPの設定

Webサイトを表示する際、HTTP/1ではリソースのダウンロードに複数のTCPを使用する。HTTP/2ではひとつのTCPを使うように設計されています。

ひとつのTCPコネクションを使いまわすのは多くのメリットがあるとともに、HTTPを"公平"なプロトコルにしている。反面、TCPのロースタートアルゴリズムにより'HTTP/1と比べて'パフォーマンスに不都合をもたらす場合がります。

6つのTCPコネクションを使用していれば、輻輳ウインドウサイズの初期値 × 6までパケット送信できる。しかし、ひとつTCPコネクションでは輻輳ウインドウサイズの初期値分のパケットしか送信できないことになります。

文章中では、HTTP/2のサーバはinitcwndを10に*すべき*と書かれています。http://tools.ietf.org/html/rfc6928:title=RFC6928「Increasing TCP's Initial Window」

]のRFCを参考になります。

TLSの設定

TLS上でHTTP/2を使う際の考慮事項はレコードサイズです。

HTTP/2はメッセージを多重化するので、大きなレコードサイズのパケットロスは多くのストリームに影響を与えます。

レコードサイズがひとつのパケットに収まっていれば、処理ブロックされる事も少なくなります(TLSレコード全体を受け取らないと処理が進められない)。ゆえに、HTTP/2ではレコードサイズは小さいほうが好ましい。

（ただし、ファイルのダウンロードといった対話的でないものについてはレコードサイズが大きいほうが効率的な場合もある）

ロードバランスとフェイルオーバー

スケーラビリティや信頼性のために複数のサーバを使用することは一般的です。

HTTP/1では通信を開始するときにコネクションの単位でサーバに振り分けを行う。これはHTTP/1ではTCPコネクションではコネクションの生存期間が短かったため、再接続ごとに通信のロードバランスが可能であった。

しかし、HTTP/2ではコネクションの生存期間が長く、クライアントもひとつのコネクションを再使用しようとする。そのため、トラフィックを別のサーバに移す機会は少ない。もしサーバ側から通信を切断すると、実際に幾つかのリクエストが送信中の場合もあるので、影響は大きくなる可能性がある。

それに対して、HTTP/2では幾つかの方法で対応している。

• GOAWAYフレーム

このフレームを使用することで、サーバはこれ以上のリクエストを受け付けない事をクライアントに通知することができる。（また、どこまで処理をしたかもメッセージ付加されます）

• ALTSVC

このフレームを使用することで、サーバはトラフィックを別のサーバにリダイレクトすることが出来ます。

これはロードバランスやフェイルオーバーに使用できます。

Permalink | コメント(0) | トラックバック(0) | 15:51