"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

会議で意見が言える程度には「HTTP/2」の動向を整理しとこう

HTTP/2という言葉が、ちょこちょこ打ち合わせとかでもでてくるようになりました。

なので、ちょっと意見を求められた時に困らないよう整理しておこうと思います。

f:id:arakan_no_boku:20190424230220j:plain

 

HTTP/2は、HTTPの進化系

 

HTTP/2とは・・的なページは沢山あります。

その中で、一番わかりやすいなと思ったのがこちらです。

www.kagoya.jp

図を引用させてもらうと。

f:id:arakan_no_boku:20190424231036j:plain

HTTP/2の目標は「レイテンシの短縮化」です。

 レイテンシってのは「転送要求を出してから実際にデータが送られてくるまでに生じる、通信の遅延時間のこと」なので、リクエストとレスポンスを複数同時に処理できるようにして、それを目指す。

この図だけでイメージがつきますし、実にわかりやすいです。

実際には、「HTTP ヘッダーの圧縮によるオーバーヘッドの最小化」とか、「リクエストの優先順位付け」とか「サーバーからの プッシュ処理のサポート」とか、他にも改善点はありますけど、主役じゃない気がします。

 

HTTP/2って具体的にどうやったら使えるのか

 

よさげなのはわかった。

じゃあ、どうやったら使えるのか?・・ですが、これは簡単。

  • HTTP/2に対応したブラウザと、Webサーバーを使いましょう。
  • WebサーバーでHTTP/2を有効にする設定をしましょう
  • ただし、使えるのは「HTTPSTLS)通信」の時のみですよ

ということです。

当たり前ですが、通信ですから片方だけ対応してても仕方ないですから。

じゃあ、対応しているブラウザは?というと。

Wikipediaによれば

ということなので、主要ブラウザはほぼ対応済だと思ってよさそうです。

サーバー側についてはこちらが非常に参考になります。

knowledge.sakura.ad.jp

一部引用すると。

Apache HTTP Serverでは、バージョン2.4.17以降で「mod_http2」というモジュールを導入することでHTTP/2を利用可能になる。

とか

高速なWebサーバーとして近年シェアを増やしているNGINXでは、バージョン1.9.5でHTTP/2サポートが追加された。

NGINXでは、設定ファイルの「listen」ディレクティブに「http2」を追加することでHTTP/2を有効にできる。

ということです。

それほど、設定が大変ということはないですが、Linuxの各ディストリビューションにはいっているバージョンが古かったりとかするので、注意が必要ということです。

ですが、まあ、やろうと思えばHTTP/2に移行できる環境は整ってきてるという感じではあります。

 

じゃあ、移行するべきかどうか?なんだけど

 

速くなるのなら、速く移行した方が良いのか?と意見を求められたら、「まだ、もう少し待ってもいいんじゃないですか」と答えることにしようと思ってます。

理由は「単純に移行しても速くならないみたいだから」です。

実際に試した興味深い記事が2つあります。

まず、こちら。

webtan.impress.co.jp

引用すると

ほとんど変わりません! というか、この例ではHTTP/2のほうが遅いです

 とか

HTTP/1.1で多かった次の部分は、HTTP/2ではほとんどなくなっています。

仕様どおりですね。

・アクセス待機(blocking、バーのベージュの部分)
TCP接続(connecting、バーの緑色の部分)
その代わりに、

・サーバーからのデータ受信スタート待ち時間(バーの紫色の部分)
が長くなっており、各リクエスト完了までの時間は、ほとんど変わっていません。

 おやおや・・です。

もうひとつがこちら。

www.lucidchart.com

Google翻訳して引用します。

私達のサービスのいくつかのためにロードバランサーのHTTP / 2を有効にしました。

その後間もなく、HTTP / 2ロードバランサーの背後にあるサーバーのCPU負荷が高くなり、応答時間が他のサーバーよりも遅くなったことに気付きました。

 で、原因としては。

実際には、マルチプレキシングによってサーバーの負荷が大幅に増加しました。

1つ目は、リクエストが小規模でスプレッドの多いバッチではなく大きなバッチで受信されたためです。

第二に、HTTP / 2では、要求がHTTP / 1.1のようにずらされるのではなく、すべて一緒に送信されたため、開始時間が近づいたため、タイムアウトする可能性がありました。

ということです。

つまり、両方の例に共通して言えるのは、「HTTP/2ではHTTP/1.1と比較して、サーバー側の負荷が増える傾向にあって、そこをうまく処理できないとパフォーマンスが発揮できない場合がある」ということ。

なので、サーバー側のHTTP/2にあわせたチューニングや、アプリケーションの改善などの対応が必要になる場合もあるらしく、安易に切り替えるだけで爆速になる・・という夢のような話ではない・・ということみたいだからです。

だから。

どうしても、厳しいレスポンススピードの要求があって、HTTP/2に最適化してでも実現しないといけないみたいな状況でない限り、そこにコストをかけるという選択は得策ではないですよと。

うん。

会議でちょこっと発言する程度なら、これで十分じゃないですかね。

ではでは。