HTTP 2.0の最新動向
IETF86におけるHTTP/2.0関連トピックス
~HTTPbis、TLS、HTTPAuth各ワーキンググループの動向
(2013/8/12 06:00)
2013年3月10日より6日間に渡り、アメリカのフロリダ州オーランドにて、IETF86 Meetingが開催された。WebSocketのプロトコルを取り扱うhybiワーキンググループのセッションが前回に引き続き未開催だったのが残念ではあるものの、今回のIETFにおいてもウェブやHTTPに関連する話題は依然多く議論の対象となっている。
前回のInterim Meetingでの議論の紹介を踏まえ、今回はIETF86におけるHTTP/2.0周辺の動向として、HTTPbisワーキンググループでの議論の様子や、関連する話題としてTLSワーキンググループ、HTTPAuthワーキンググループの様子について紹介する。
httpbis WG
今回開催されたHTTPbisワーキンググループのセッションでは、HTTP/1.1の議論が収束しつつあることから、これまでと異なり、HTTP/1.1とHTTP/2.0両方の議論がひとつのセッション時間内で行われた。
HTTP/1.1の作業は、現状ワーキンググループ・ラストコール(WGLC)の段階にあり、4月30日までコメントを受け付けていた。ところが実際には5月に入った段階でもかなりの量のコメントがML等に投稿されており、未だなお続いている。そのため、まだある程度時間がかかりそうではあるものの、近いうちに作業が完了する見込みである。それもあり、ミーティングセッションにおいては現状のステータス共有程度の時間しか設けられなかった。
それでは、HTTP/2.0について会場で大きく議論が進行したのかというと、そういうわけでもないというのが実際のところだ。
どういうことかと思われるかもしれないが、今回の話題としては、前回の記事でも紹介したInterim Meetingや、それに加えてメーリングリスト・Github等で行われた議論の結果が主であり、議論の方針に問題がないか確認する作業が淡々と進行していったのである。感覚的には、参加者全体からのコンセンサスを慎重に取り、着実に進めていこうという空気が感じられた。
HTTP/2.0の作業は主にGithubで行われていることから参加の敷居も低くなっているようで、そこでは多くの人により活発的に議論が行われている様子が垣間見える。今回のミーティングのおとなしめな進行は、そういった要素によるものが大きいのではないかと思われる。
Interim Meeting等での議論の結果として主に以下のようなものが紹介され、ほぼ異論もなく進行している。
- フレームヘッダーにおけるストリーム識別子の必須化
- プロトコルレベルでのエラーコードの共通化
- IANA登録ポリシー
- Flagsフィールドの整理・共通化
- コネクションベース認証方式に関する記述の削除
- バージョンフィールドの削除
- HTTP/1.1における100-continueレスポンスに相当する動作の規定
- RST_STREAMメッセージの複数送信禁止
- 接続先におけるTCPのCWND値の設定を要請する、SETTINGS_CURRENT_CWNDの削除
- データ圧縮フラグの削除
httpbisワーキンググループでは今後もInterim Meetingを継続的に開催していく予定であり、早速第2回が6月にサンフランシスコで開催された。その次となる第3回はIETFの開催に合わせて8月にドイツでの開催が決定している。東京で開催された第1回と異なり、気軽に参加できそうにないのが残念ではあるものの、引き続き様々な議論が交わされることは間違いない。また、ドラフトを基にした試験実装とそれらの相互接続性試験を第3回のInterim Meeting周辺で行うとしており、ここからもHTTP/2.0の策定を着実に進めていこうとしている様子が伺える。
なお、余談ではあるが、現時点では筆者が確認している限り、2つの実装の開発がGithub上で始まっているようだ。
HTTPの利用は今後も、ウェブをはじめ様々な分野において、引き続き増加していくと考えられる。そのため、HTTP/2.0の取り組みはインターネット全体における急務であると言っても過言ではない。引き続きこの調子で策定が進んでいき、広く使われる良いプロトコルとなることを期待したい。
tls WG
HTTPbisワーキンググループからTLSワーキンググループに要請していた、Next Protocol Negotiation(NPN)等のアップグレードメカニズムについては、新たにApplication-Layer Protocol Negotiation(ALPN)という手法が提案されていたのは前回に説明したとおりだ。今回のTLSワーキンググループのセッションにおいてはNPNとALPNについて、それぞれどのような提案であるかの説明とともに、どちらを選択するかについて議論が行われた。
NPNとALPNはどちらもTLS上で通信するアプリケーションプロトコルを事前に交渉するためのTLS拡張であり、機能面で大きな違いはない。
それぞれの主な違いは、プロトコル決定の主体がクライアントであるかサーバーであるかという点である。NPNはクライアントからサーバーのサポートしているプロトコルがどれかを問い合わせ、クライアント側が使用するプロトコルを選択し決定する。それに対して、ALPNではクライアントからサポートしているプロトコルを送信し、サーバー側が使用するプロトコルを選択し決定するようになっている。
NPNとALPNのそれぞれをセキュリティ的な視点で見た際、NPNにはサーバーがサポートしているプロトコルを簡単に知ることが可能であるという問題があり、一方ALPNには決定されたアプリケーションプロトコルが暗号化されない形で送信されるという問題がある。
どちらもTLS上で利用できるアプリケーションプロトコルが知られてしまうといった問題であるが、直ちに大きな影響があるようには思われない。しかし、ごく一部においては、たとえばNPNを既知でないポート番号で用いるサービスをプライベートに提供している場合などにおいて、悪意ある人間に対して余計な情報を与える可能性はあるかもしれない。
ALPNにおいて決定されたアプリケーションプロトコルの情報が暗号化されない状態で送信される問題については、ALPNなしでTLSセッションを確立し、その後にALPNを利用しながらTLS Renegotiationを行うことで、暗号化された状態でALPNを行うことが可能であるとなっているものの、ラウンドトリップ数削減の観点からは懐疑が残る。
こういったことを踏まえた議論の後、TLSワーキンググループとしてどちらの拡張を進めていくべきかについて、ハミングによる意思確認が行われた。しかし、どちらも賛同者が一定以上おり、念のため繰り返し2度のハミングが行われたものの結果は変わらず、意思確認が成功したとは言えなかった。
最終的に、それぞれについての挙手を求めたところ、NPNに対する挙手12人に対して、ALPNに対する挙手が24人となり、ALPNのほうが多い結果となった。一般的に、IETFにおけるコンセンサスは大多数からの賛同によって形成されることから、挙手の人数をカウントするといったことが行われるのは異例である。
その後、セッションでの結果をもとにMLで最終的な確認が行われ、ALPNをもとに引き続き議論が始まりつつある。
httpauth WG
そのほかのHTTPに関連する話題として以前も少し紹介したが、今回ついに、HTTPにおける新しい認証プロトコルを検討するワーキンググループであるhttpauth ワーキンググループが設立された。
ワーキンググループ設立の通知ははなんとセッションの当日に行われ、BoFを行う予定で確保していたタイムスロットにおいてセッションが開催された。そういうこともあり、チェアやドラフトの著者を含め準備期間もあまりなく、セッションはほぼワーキンググループの方向性確認に終始したと言える。
httpauthワーキンググループでは今後、新たな認証プロトコルを考え、試験的なRFC(Experimental RFC)による公開を目指していくほか、これまでもHTTPで利用されてきたBasic認証及びDigest認証の国際化と、Digest認証に対するハッシュアルゴリズムの追加等を行うとしている。
おわりに
この連載で取り上げてきただけでも、約半年の期間で行われた2度のIETF Meetingと1度のInterim Meeting、そしてメーリングリスト等における議論によって、HTTP/2.0が当初から大きく姿を変えてきていることがなんとなく伝わっただろうか。
SPDYをはじめとするいくつかの提案からスタートしたHTTP/2.0は、SPDYを基に策定が開始されたものの多くの変更が行われ、もはやSPDYとは別物になっている。また、引き続き利用者や開発者の意見を元に、さらなる変更が加わることは間違いないだろう。
このように、様々な立場からの意見を踏まえ、より利用される現場の現実に即した利用価値のあるものを作り上げていけるのが、IETFをはじめとするオープンな標準化団体の利点であり、標準化活動に関与するモチベーションとなっていると個人的には思っている。
IETFでは、HTTP/2.0以外にも、様々な議論が交わされ、本当にたくさんのインターネット関連技術の策定が行われている。
4回に渡るHTTP/2.0についての連載はここで一旦終了となるが、2015年に横浜にてIETFが開催されることもあり、IETFで行われている様々な議論についてなど、今後また機会があれば発信していきたいと考えている。