5月末に、「HTTP/2: Operational Considerations for Servers」というI-Dが公開された。
サーバでHTTP/2対応する際の、パフォーマンスや運用性に関する注意点などが述べられている。
主な項目は以下の通りである
（ただし、4〜7についてはTBDとなっている）
書かれていることについてざっとメモ...
TCPの設定
Webサイトを表示する際、HTTP/1ではリソースのダウンロードに複数のTCPを使用する。HTTP/2ではひとつのTCPを使うように設計されています。
ひとつのTCPコネクションを使いまわすのは多くのメリットがあるとともに、HTTPを"公平"なプロトコルにしている。反面、TCPのスロースタートアルゴリズムにより'HTTP/1と比べて'パフォーマンスに不都合をもたらす場合があります。
6つのTCPコネクションを使用していれば、輻輳ウインドウサイズの初期値 × 6までパケット送信できる。しかし、ひとつTCPコネクションでは輻輳ウインドウサイズの初期値分のパケットしか送信できないことになります。
文章中では、HTTP/2のサーバはinitcwndを10に*すべき*と書かれています。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
このフレームを使用することで、サーバはトラフィックを別のサーバにリダイレクトすることが出来ます。
これはロードバランスやフェイルオーバーに使用できます。
