この記事は HTTP2 Advent Calendar の 23 日目の記事です。
本記事では、個人的興味からHTTP/2の並列数別のパケットロス率影響度を測定した。
余談ではあるが、 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" としている。
背景
HTTP/2ではHTTP/1におけるリクエスト及びレスポンスをストリームと呼ばれる単位で並列化している。
HTTP/2では極力一つのTCP上で通信を行うことで、多くのメリットを得ているが、通信特性には変化がある。
筆者の個人的興味により、ストリーム並列数毎にパケットロス率を変化させた時の影響について調べた。筆者の至らなさゆえ有意な測定でない可能性がある点についてご留意頂ければと思う。
測定環境
同ホストマシン上に仮想マシンを2台(ブリッジ接続)し、ブリッジ接続したNICに対して通信を行った。また、仮想的にパケットロス率を設定するためにtcコマンドを利用した。
仮想マシンのOSはUbuntu 14.10を利用し、sysctl等はデフォルトのまま使用した。
測定ソフトウェアとしてはnghttp2のh2load及び、nghttpdを利用した。
測定方法は平文通信・TLS通信でそれぞれ行い、リクエスト数 50,000、クライアント数 100、ストリーム数は 10,50,100,200,500で5回測定した。なお、パケットロス率は0%,1%,10%,20%で測定した。
結果
以下図に結果を示す。
各線は色ごとに最大ストリーム数を示す(10,50,100,200,500)。横軸はパケットロス率(%)、縦軸はh2loadのリクエスト完了時間となっている。
まず分かるように
- パケットロス率が多くなるほど時間は長くなる
- 平文よりTLSの方が時間がかかっている
- 同一のパケットロス率であればストリーム数が多いほど時間は短くなる
- ストリーム数100と200の差よりも、ストリーム数10と20の差のほうが大きい（得られるメリットは少なくなる
- 概ね、パケットロス率の影響度は同じような直線となっているように見える
TLSの方が影響が傾きが小さいように見える（＊縦軸が合ってない図が悪い）全体の時間のうち通信部分が占める割合の差か、パケットのデータの扱い方がちがうためだと考えられる。
また、今回のパケットロス率の範囲ではストリーム数による影響の違いは特に観測できなかった(実装に依存する部分もあるが)。筆者の実際に行われている通信のパケットへの理解不足を感じる。
最後に
直前までアドベントカレンダーネタをどうするか悩んでいたので、かなりやっつけ感が出てしまった。各所からまさかりが飛んできそうで辛い。
本記事内容の不正確については全て筆者の至らなさのせいである。曖昧な部分については今後改善していく所存である。
