第2回：HTTP/1.1からのアップグレードメカニズム

HTTP Upgrade ヘッダーフィールドを利用する方法

　HTTP/1.1にはもともと、HTTP通信で確立されている通信セッションを別のプロトコルの通信セッションに再利用するための機構として、Upgradeヘッダーフィールドが用意されている（RFC2616）。この提案は、その機構を用いてHTTP/1.1の通信をHTTP/2.0に移行するものだ。

　Upgradeヘッダーフィールドの具体的な利用法としては、セッション確立後にHTTPからHTTPSへ通信を移行することによるTCPウェルノウンポート（443）の削減や、HTTPSにおける名前ベースバーチャルホストの実現など、いくつか考えられていたようだ（RFC2817）。

　しかし実際には、これまで全くと言っていいほどUpgradeヘッダーフィールドは利用されてこなかった。特に昨今では、HTTPSにおける名前ベースバーチャルホストは、TLSのSNI（Server Name Indication）拡張によって実現されている（RFC6066）。

　このように、これまであまり知られていなかったUpgradeヘッダーフィールドだが、変更先のプロトコルや通信内容について特に限定されていなかったことから、WebSocketプロトコルの通信開始時に利用されることとなり、最近になって有用性が見直されてきている。

　また、“Upgrade”という名前からして想像がつくように、新しいバージョンのHTTPに対する移行も考えて用意されており、Upgradeヘッダーフィールドを利用したHTTP/2.0への移行が提案されるのは、当然の結果といえるだろう。

　提出されている草案はまだ初版ということもあり、あまり詳細なことは書かれていないものの、以下のような流れが記述されている。後述するほかの提案と比べると、HTTPの中ですべて完結するためレイヤーをまたがない点や、既存のプロキシー等に対する親和性の高さなどで、妥当性が高いといえる。

HTTP/2.0対応時フロー

HTTP/2.0非対応時フロー

　HTTP/2.0へ移行した後の最初のレスポンス（図1、シーケンス2）に、HTTP/1.1で行ったリクエストの応答を含むのか、それともクライアントが新たにHTTP/2.0でリクエストを送り返す必要があるのかは明確に記述はされていない。しかし、現状ラウンドトリップ数の削減を重視する傾向にあることから、個人的にはHTTP/1.1で行ったリクエストに対する応答を含んで、HTTP/2.0のセッションが開始されるのではないかと考えている。

　その場合に、たとえば同時に複数のリクエストを送信することができないなど、HTTP/2.0のいくつかの機能を最初から利用できなくなることや、POSTから通信が開始する際に、そのPOSTリクエストが完了するまでアップグレードが完了しない可能性があるなど、引き続き考えるべき問題は存在する。

[参考] HTTP 2.0 Negotiation draft-montenegro-httpbis-http2-negotiation-00
http://tools.ietf.org/html/draft-montenegro-httpbis-http2-negotiation-00

DNS SRVレコードを利用する方法

　DNSのSRVレコードは、DNSを用いてサービスとサーバーを紐づけるためのもので、代表的な利用例としては、XMPP, LDAP（Active Directory）、CalDAV等が挙げられる。

　具体的なアップグレードの方法としては、“_http2._tcp.example.com.”のようなホストのSRVレコードを解決することによって、そのドメインをホストするサーバーがHTTP/2.0をサポートしているかを検出するようだ。

　問題としては、DNSクエリ発行の回数が増えることによるトラフィック及びラウンドトリップ数の増加や、SRVレコードが存在しない場合のタイムアウトにかかる時間の増加などが挙げられる。

　そのほか、「SRVレコードを、同一のTCPポート内に複数のサービスが同時に動作している中でのプロトコル識別に使用するのはレイヤーバイオレーションなのではないか」との見方もあり、反対する人も少なくはないようだ。

　実際のフローは、おそらく以下のようになると考えられる。

HTTP/2.0対応時フロー

HTTP/2.0非対応時フロー

　なお、この方式の図のみ、他の提案の図では省いているDNSのAレコード問い合わせを記述している。本来は他の方式においても、DNSのAレコードの問い合わせは発生する。

HTTP/1.1レスポンスのヘッダーに、HTTP/2.0サーバーが動作しているポート番号を含める方法

　この方法では、HTTP/1.1のレスポンスに、サーバーの別のポートで動作しているHTTP/2.0の情報を含め、クライアントに通知する。通知を受け取ったクライアントがHTTP/2.0に対応している場合、クライアントは既存のHTTP/1.1接続を切断し、HTTP/2.0で接続し直すことができる。

　Upgradeヘッダーフィールドを用いた方法と少し似ているが、コネクションを再利用せず、新たに接続を行う点が特徴だ。

　おそらく、SPDY draft2のスペックに含まれているAlternate-Protocol ヘッダーと同等のものだが、SPDY draft3では削除されており、現在デプロイされているSPDY実装においてもTLSのNPNを前提としたものばかりで、一般的に使われてはいないようだ。

　この方法の懸念点としては、再接続に必要なラウンドトリップ数が多いことのほか、通知されたポートへの接続が、企業等のファイアウォールによって遮断される可能性などが挙げられている。

　具体的には、以下のようなフローになると考えられる。

HTTP/2.0対応時フロー

HTTP/2.0非対応時フロー

その他

　上記の代表的な提案のほかに、クライアントが過去にアップグレードを行ったことがある等、接続先がHTTP/2.0対応サーバーであることを知っている際には、直接HTTP/2.0で接続しにいくことによってラウンドトリップ数が削減できるのではないかという提案があったものの、間にHTTP/2.0非対応プロクシが存在するケースで通信に支障が出るなどの問題が挙げられていた。

TLS NPN拡張の議論

　前述したように、HTTPS通信時のアップグレードメカニズムとしては、TLSのNPN拡張の標準化をTLSワーキンググループに要請する前提で話が進んでいる。

　実際に、httpbisワーキンググループのセッションの後、TLSワーキンググループのセッションにおいて、httpbisワーキンググループの議長であるMark Nottingham氏が、TLSのNPN拡張を標準化するよう要請した。

　TLSワーキンググループのセッションにおいて行われた議論では、「TLSで行う理由がないのではないか」、「レイヤーバイオレーションでありTCPのレイヤでやるべきだ」、「そのための仕組みとしてTCPにはポート番号というものがすでに存在する」、などといった批判的な意見も多かったものの、NPN拡張が必要だと認識している人も多く、最終的にはTLSワーキンググループにおいて引き続き議論を進めていく方向になりそうである。

新しいHTTP認証プロトコルと httpauth BoF

　IETF85におけるHTTP関連の動きとして、BasicやDigest等をはじめとする、HTTP層における認証方式を新たに策定するためのワーキンググループ設立に向けた、httpauth BoF（Birds of a feather: 興味を持つ人の集まり）の開催が挙げられる。

　HTTPbisワーキンググループはもともと、2012年の初めにパリで開催されたIETF83の際に、新たなHTTPの認証方式の策定をHTTPbisワーキンググループで行う可能性があるとし、新たな認証方式の提案を募集していた。

　その後、いくつかの方式が提案されたものの、バンクーバーで開催されたIETF84において、HTTPbisワーキンググループはHTTP/2.0の策定に注力し、HTTP認証方式については扱わないこととなった。そのかわり、HTTP認証方式について継続して議論を進め、実験的RFCの発行をゴールとするワーキンググループを立ち上げる方針となった。

　今回行われたBoFはその流れで開催されたもので、およそ100人弱の参加者のもと5つの提案が発表され、活発な議論が交わされた。

　現在、HTTP層の認証方式は機能の不足や安全性等の懸念もあり、あまり広く使われているとは言いがたい。しかし、広く用いられているフォーム認証にも、フィッシングの容易性をはじめ問題点が少なくない。これからのID連携技術等の進歩とともに、ウェブにおける安全な認証のための技術は、今後重要性を増していくと考えており、更なる議論の発展を期待している。

　HTTP/2.0の話題とは少し外れてしまうため詳細は割愛するが、次世代HTTPに関連する議論として、今後機会があればより詳しくご紹介したいと考えている。