実サービスにおけるHTTP/2ネゴシエーション数を調べる
こんにちは、インフラストラクチャ本部の後藤です。
先日、HTTP/2がRFC7540としてRFC化されました。RFCの中でも触れられている通り、日本の方も沢山関与されています。本当に皆様お疲れ様でした。
仕様としては一段落したHTTP/2ですが、実際に使っていく段階へと移ってく上で気になるのがどれ位のクライアントがHTTP/2に対応しているかということです。Google ChromeやFirefoxの最新版では既にHTTP/2対応していますが、全てのユーザがそれを使っているわけではありません。
そこで、今回は実際に弊社のサービスでHTTP/2対応クライアントの接続がどれ程あるのか調べてみました。(HTTP/2をサービスとしてサポートしているわけではありません。)
ユーザエージェントから調べる方法もあるのですが、今回はALPNを元に調べました。
ALPNについて
HTTP/2で通信する際のネゴシエーション方法には幾つかあり、ALPN(Application Layer Protocol Negotiation)を使う方法や、HTTP/1.1からのアップグレードを使用する方法があります。
ALPNはTLSハンドシェイク中に使用するプロトコルをネゴシエーションする仕組みであり、クライアント側からClientHelloを送信する際に使用するプロトコルリストを提示します。
例えばGoogle Chromeなどでは以下の様なリストをClientHelloを送信する際に送信しています。
1 |
http/1.1,spdy/3.1,h2-14,h2 |
h2という識別子がHTTP/2を示す識別子になります。h2-14と言ったハイフン付きの識別子は、ドラフト実装を示すものになります。
サーバはALPNでリストを受け取ったプロトコルの中から一つを選択し、SeverHelloを送信する際に選択したプロトコルをALPNでクライアントに提示します。
この一連の流れを通してHTTP/2で通信するネゴシエーションが完了します。
SPDYでは、似たような仕組みであるNPN(Next Protocol Negotiation)を使用していました。ALPNとは違いサーバからプロトコルリストを提示し、クライアントが選択するというものです。このNPNでHTTP/2をネゴシエーション可能なクライアントもまだまだ存在はしています。
パケットキャプチャ・パースする
tcpdump等でTLS通信をキャプチャしpcapファイルとして保存します、保存したパケットをtsharkで詳細に表示します。(今回、実際にはClientHelloのみを保存して利用しました。)
1 |
$ tcpdump -i eth1 port 443 -w out.pcap |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
$ tshark -r ./out.pcap -V ...(中略 Extension: next_protocol_negotiation Type: next_protocol_negotiation (0x3374) Length: 0 Extension: Application Layer Protocol Negotiation Type: Application Layer Protocol Negotiation (0x0010) Length: 26 ALPN Extension Length: 24 ALPN Protocol ALPN string length: 8 ALPN Next Protocol: http/1.1 ALPN string length: 8 ALPN Next Protocol: spdy/3.1 ALPN string length: 5 ALPN Next Protocol: h2-14 ALPN string length: 2 ALPN Next Protocol: h2 |
最新版のtsharkであれば、このようにClietnHelloのALPNをパースし、表示することが出来ます。あとは、コレを元にカウントするだけでどの程度のクライアントがHTTP/2でネゴシエーションしてきてるかが分かります。
NPNについては、ClientHelloではNPNに対応しいる事を示すのみになります。
結果
弊社サービスでPC向けサイトのサーバを対象にClientHelloパケットの一部を収集し測定しました。同一IPからのClientHelloが複数あった場合でも別々にカウントしています。
種別 | パケット数 | 割合 | |
総パケット数 | 5567 | 100 | |
ALPN付き | 2952 | 53 | |
h2 | 1092 | 19.6 | |
h2-16 | 486 | 8.7 | |
h2-15 | 486 | 8.7 | |
h2-14 | 1180 | 21.2 | |
spdy/3.1 | 1450 | 26 | |
spdy/3 | 1762 | 31.7 | |
spdy/2 | 25 | 0.4 | |
http/1.1 | 2952 | 53 | |
NPN付き | 3388 | 60.9 |
全体の約半数でALPNが使われており、h2が付いているものはその中でも20%ほどという結果になりました。
またALPNで提示されるプロトコルリスト別の数では以下のようになりました。
提示リスト | パケット数 |
spdy/3, http/1.1 | 1502 |
h2-16, h2-15, h2-14, h2, spdy/3.1, http/1.1 | 486 |
http/1.1, spdy/3.1, h2-14, h2 | 600 |
spdy/3, spdy/3.1, http/1.1 | 235 |
http/1.1, spdy/3.1, h2-14 | 94 |
spdy/2, spdy/3, spdy/3.1, http/1.1 | 25 |
h2, spdy/3.1, http/1.1 | 6 |
spdy/3.1, http/1.1 | 4 |
- 全パケットの内
- 53%がSPDY/3系(3 or 3.1)に対応している(NPNのみのクライアントもいるので実際はもう少し多いはず)
- 21%が実装ドラフトを含むHTTP/2に対応している
- ALPNを使用しているパケットの内
- 100%がSPDY/3系(3 or 3.1)に対応している
- 40%が実装ドラフトを含むHTTP/2に対応している
- ALPNよりNPN対応しているクライアントの方が多い
という事が分かりました。
まとめ
今回はPC向けサイトのサーバでHTTP/2対応クライアントの測定を行いました。
HTTP/2対応クライアントは全体の約20%、SPDY対応クライアントは約50%以上という結果になりました。多くのユーザがHTTP/2の恩恵を受けられるという段階では無いものの、個人的には思ってたより多いなという印象です。
最新ではないブラウザのアクセスは今後もなくならないかと思いますが、SPDY対応クライアントの割合を見るにHTTP/2対応クライアントによるアクセスは今後増えていくと思います。
HTTP/2対応を考えてる方は、一度自身のサービスで統計を取ってみては如何でしょうか?
注意
- 本データの内容の正確性・信頼性については保証いたしかねます。
- 本データはGREEの特定のWebサービスから得られた一部分を基にしています。