golden-luckyの日記

ツイッターより長くなるやつ

QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう

OSI参照モデルTCP/IPモデル

かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。

と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1っていうけど、これレイヤ2の話も含まれてるような気がする」とか、逆に、「ATMってレイヤ2とされるけど、レイヤ1の話も含まれているような」とか。

それでもまだ、このへんの低レイヤのネットワーク技術は、OSI参照モデルの各層になんとなく合致しているような雰囲気がありました。 本当に混乱するのは、レイヤ5以上です。 ぼくの稼業はネットワーク技術の解説書を作ったりすることなんですが、レイヤ4を下位層として利用するさまざまな技術に対し、誰もが納得するようなOSI参照モデルの階層を与えるという仕事は、いつだって絶望的でした。 それでもなお、現在のようにすべてがインターネットになる以前は、OSI参照モデルの枠組みで理解すると都合がよいプロトコルスタックもありました。 OSI参照モデルに立脚した技術解説を与えることは、インターネットの時代になっても十分に意義があることだと自分を思い込ませながら、解説書を作っていました。

そうこうするうちに、コンピュータネットワークの世界は、事実上インターネットと互換な技術ばかりになります。 それらインターネットを前提に開発された技術は、OSI参照モデルに準拠して開発されたわけではありません。 OSI参照モデルのレイヤという枠組みで、それらの技術をすっきり説明することは、ますます絶望的になりました。

実際のところ、そうしたインターネット前提の技術(長いので以降ではインターネット技術と総称します)をうまく説明するだけなら、OSI参照モデルのすべてのレイヤについて語る必要はありません。 インターネット技術の中核となるのは、パケットをずっと先まで転送するための「IP」と、転送されるパケットをさらに上位のアプリケーションに結び付ける「トランスポート」です。 この2つのレイヤと、その上下のレイヤの合計4つだけを見れば、インターネット技術について語るには十分でしょう。 このようなモデルを、ここでは「TCP/IPモデル」と呼ぶことにします。

(IP、トランスポート、その上下のレイヤという4つの層にゆるく分けてインターネット技術を説明するモデルは、インターネットに接続する端末の技術要件を整理したRFC 1122にまとめられています。 RFC 1122では、この説明モデルの名前を特に定めていませんが、一ヶ所だけ「インターネットモデル」という言い方をしているので、ひょっとすると「TCP/IPモデル」よりも「インターネットモデル」と呼ぶほうが正確かもしれません。 しかし、この記事では、このモデルをモデルたらしめている部分を担うIPとTCPというプロトコルを強調したいので、「TCP/IPモデル」と呼ぶことにします。)

なぜいまでもOSI参照モデルによる説明が多いか

ここまでのおさらい。

  1. かつてOSI参照モデルというものが論じられ、ネットワーク技術の解説でもそれに沿ったアプローチが採用された
  2. ネットワーク技術の多くがインターネット技術と同義になっていくなかで、その技術の理解を促すのにOSI参照モデルは最適とはいえず、TCP/IPモデルと呼ぶべきモデルが考えられた

しかし、インターネット技術の解説においてTCP/IPモデルはあまり採用されていないように見えます。 むしろ、旧来のOSI参照モデルに照らしてインターネットを支える各種のプロトコルを説明していくスタイルの解説書のほうが優勢でしょう。

なぜ、インターネット技術の解説でも、OSI参照モデルが依然として採用され続けているのでしょうか?  解説のアプローチをTCP/IPモデルに移行できない根本的な理由があるのでしょうか?

理由の1つとして考えられるのは、「レイヤ2ネットワーク」とか「レイヤ3スイッチ」のようなOSI参照モデル由来の用語がそれなりに普及しているという現状でしょう。 これらの用語について説明するには、「2」とか「3」といった数字が何を意味するのかを解き明かす必要があり、そのためにはOSI参照モデルについてまったく紹介しないわけにはいきません。

そしてもう1つ、私見ではこちらのほうが理由として大きいと想像しているのですが、説明方法を変更するリスクを負いたくないという解説側の思惑があるような気がしています。 現代のネットワーク技術について説明するには、レイヤという概念がとても便利です。 なにせ、前述したRFC 1122でも、「きっちりレイヤを分けたモデルでインターネット技術を考えることは、それが仕様であれ実装であれ不完全(な理解しかもたらさない)」と明言しつつ、要件の整理には4レイヤからなるTCP/IPモデルを採用しています。

データをカプセル化し、あるプロトコルが提供する機能を別のプロトコルから呼び出して使うという抽象的なインターフェースを理解するには、プロトコルが層になったモデルで考えるのが手っ取り早いでしょう。 その概念を教えるためのアプローチとして、長年にわたり採用されてきたのが、OSI参照モデルです。 レイヤという、だいぶ説明がめんどくさい概念について、いままでの解説と同じ枠組みをそのまま再利用したいという要求があったことは想像に難くありません。

都合がいいことに、インターネット技術の中核となっているIPとトランスポートは、それぞれOSI参照モデルにおけるレイヤ3とレイヤ4にだいたい対応していました。 そのため、OSI参照モデルについて説明した部分は従来のまま、「このうちのレイヤ3がIP、レイヤ4がトランスポートです」という感じに説明を済ませることができます。 インターネット技術について解説するにあたり、OSI参照モデルを破棄する必要は特になかったのです。

こうして、技術理解にとって最適な枠組みはOSI参照モデルからTCP/IPモデルに変わったにもかかわらず、その解説ではOSI参照モデルが採用され続けるという状況が続きました。 OSI参照モデルの7つのレイヤをすべて意識し、そのすべてに個々のインターネット技術を対応させないといけない状況は、こんな具合にして形成されるに至ったのだと思われます。

QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい

ここからが本題です。

いま、TCP/IPモデルにおけるトランスポートを担う新しいプロトコルとして、QUICが標準化されつつあります。 このQUICの役割を解説するにあたって、ぼくらはいよいよ、OSI参照モデルというネットワーク技術の解説方法を手放すべきではないでしょうか。

これは、これからはOSI参照モデルではなくTCP/IPモデルを使ってレイヤの考え方を解説すべきという話ではありません。 むしろ、金科玉条のモデルはないという事実を受け入れて、もっと別の説明の仕方を考えないと、どう説明しても無理が生じる(場合によっては間違いと指摘されかねない)状況に陥るだろう、その好例がQUICではないか、という私見です。

QUICは、OSI参照モデルに押し込めればレイヤ4にあたりますが、たとえばTCPの代わりにQUICをそのまま使えるわけではなく、同じレイヤ4のプロトコルであるUDPが必要です。 OSI参照モデルにのっとった解説だと、この時点でもうすっきりしません。 UDPでレイヤ4の機能を実現しているのだから、QUICはレイヤ5、あるいはレイヤ6になるのでは?  実際、そういう側面もあります。 OSI参照モデルにのっとった解説では、TLSの機能をレイヤ5とかレイヤ6に分類することがありますが、QUICにはTLSで実現していた機能も含まれています。 そう考えると、QUICのことをレイヤ4のプロトコルとして考えるのは間違っているようにも感じられます。

では、いっそのことQUICをレイヤ5からレイヤ6を統合したプロトコルと説明するのはどうでしょうか?  それはそれで、QUICをTCP/IPモデルにおけるトランスポートプロトコルとみなす説明と矛盾しそうです。 トランスポートプロトコルだといえるけど、OSI参照モデルの枠組みで説明しようとするとレイヤ5や6に区分されてしまう、そういう役割にQUICという名前が与えられた、というのが実態に近い気がします。

そもそも、なんでこんな、従来のモデルにおけるレイヤ分けに合致しないプロトコルが誕生したのでしょうか?  この疑問について考えることが、おそらく、これからのネットワーク技術の解説の仕方を考えることになると思います。

ぼくの現在の考えを先に言ってしまうと、OSI参照モデルであれインターネットモデルであれ、既存のレイヤのモデルを頭に思い浮かべてそれに沿ってQUICを説明しようとすると、たぶん破綻します。 プラトンイデア的な理想のレイヤのモデルはありません。 ぼく自身、そういう理想のレイヤの存在を暗に前提していて、そのうちの1つのレイヤを担うプロトコルとして開発された技術という視点でQUICをとらえようとした結果、上記のようにわけがわからなくなっていました。

それなら、そういう視点を捨ててネットワーク技術のトレンドからQUICの意義を素直に考えて、そのうえで来るべきネットワーク技術の教科書の姿を思い描いてみようというのが、この記事で言いたいことです。

HTTP/QUICモデル

QUICのことを、TCP/IPモデルに当てはめると、トランスポートを担うプロトコルとされます。 しかし同時に、QUICは、TCP/IPモデルにおけるトランスポートとしてUDPを使います。 この2つの事実は、きっちりレイヤ分割されたモデルの世界観に照らして考えると、どうにも矛盾しているような気がします。 しかしこれは錯覚で、実際には上下2つの観点から冷静に技術トレンドとして考えるとすっきり説明がつきます。

まず上から考えましょう。 現在のインターネットを支配しているサービスはウェブです。そして、そのウェブを担うプロトコルHTTPです。 HTTPは、従来はトランスポートとしてTCPを利用しています。

HTTPの未来について考えている人たちは、ここで、トランスポートとしてTCPを使わずにHTTPをやる方法はないかと考えました。 なんでそんなことを考え始めたかというと、TCPのやり方をハックして接続を確立するまでの手間を減らしたり輻輳制御や再送処理をいじったり並列に接続を張って多重化したりしたいけど、TCPの機能はOSに組み込まれていて簡単には変更できないから。 で、そういう仕掛けをHTTPに組み込んだ魔改造HTTPの開発に着手しました。 この魔改造HTTPには、必然的に従来のTCPで提供されていた機能も含まれます。 そこで、この魔改造HTTPを開発したGoogleは、これを「トランスポートの機能を提供する新しいプロトコル」として発表しました。 これがQUICです。 Googleは、以前にも魔改造HTTPを作ってインターネットで運用し、HTTP/2として標準化までもっていきましたが、こちらは最初からTCPを利用するプロトコルとして開発されました。)

ここで問題になるのが、このGoogle魔改造HTTPであるQUICをどうやってインターネットに載せるかです。 トランスポートなので、可能ならIPv6の上に直接載せたいくらいだけど、そんな通信を許してくれるように世界中の通信機器を変更することはできません。 そこで、既存の中間機器すべてで既に対応済みであろうUDPを使うことにしました。 これにより、途中の機器ではUDPポート80や443を通ってやりとりされるパケットとして、この魔改造HTTPをいまのインターネットにそのままのっけることが可能になりました。 これが、QUICを下からみた場合の実体です。 要するに、UDPを使うことはQUICにとって本質的な要請ではなく、たまたま運用上都合がよかったからです。 なんでこれをわざわざ強調するかというと、QUICが登場したころの記事では「UDPなので速い」という論調の解説が多くあり、ぼくもつい最近まではそれを真に受けていたからです。

さらに、このGoogleが実装した魔改造HTTPとしてのQUICは、IETFで標準化されるにあたり、本来のHTTPっぽい部分は分けて考えられるようになりました。 QUICのうち、このHTTPよりの部分だけを指すときには、「HTTP over QUIC」という表現が使われるようになります。 この部分には、その後、「HTTP/3」という正式名称がつきます。

こんなふうに、現在標準化が進められているQUICを見ると、最初から汎用のトランスポート技術として開発されてきたわけではなく、HTTP中心の世界観からの要請で出発していることがわかります。 実際、QUICの最初の標準は、HTTP/3に特化したものに限定することが合意されているようです。 QUICをTCP/IPモデルでトランスポートとしてすっきり説明できないのは、こう考えると当然であるように思えます。 むしろQUIC(とHTTP/3)について解説するときは、HTTP/QUICモデルという、TCP/IPモデルとはまた別の見方をしたほうがいいのではないかと思えるくらいです。

QUICをどう解説するか

さて、本記事的に肝心なのはここからです。 TCP/IPを中心にした世界観から、HTTP側の要請で従来のTCPのさまざまな機能を提供しようという世界観になりつつある中で、インターネットの仕組みをどう解説するか。 ぼくはQUICもHTTP/3も具体的な仕様に熟知しているわけではないので、解説そのものは書けませんが、どういう構成にするのがいいかなという妄想ならできます。

おそらく、まず必要になるのは、TLSの仕組みと世界観をしっかり説明することでしょう。 なぜなら、QUICによるHTTP通信は、すべてTLSの仕組みが組み込まれた暗号通信だから。 ここでいうTLSの仕組みの理解には、接続の確立手順や暗号の合意のためのネゴシエーション手順の説明だけでなく、証明書を利用したインターネット信頼モデルの理解も必要です。

とはいえ、この部分については、「なにはともあれ『プロフェッショナルSSL/TLS』を読みましょう」でいい気もします。 『プロフェッショナルSSL/TLS』を読むと、認証付き暗号(AEAD)の考え方がわかるので、さらによい。 QUICでは、ほとんどのパケットはAEADで保護されるし、トークンの相互認証を使ったステートレスな接続終了とかもあるので、AEADを理解させないとたぶん概略すら説明できない気がします。

プロフェッショナルSSL/TLS(紙書籍+電子書籍)www.lambdanote.com

で、そのうえで、まずはHTTPの説明なんだろうなあ。 HTTPの部分については、とりあえず渋川さんの『Real World HTTP』があるし、これが改訂されれば当面は十分そう。 あるいは、ウェブ屋さん向けにコンピュータシステムの低レイヤの話を説明するという『Goならわかるシステムプログラミング』という本があります。 ふつうのコンピュータシステムの本だとTCP/IPやソケットの話が入るところで、この本ではHTTPの話を厚めにしています。 上に書いたようなQUICの背景をふまえると、ウェブ開発者にとってのHTTP/3は、ネイティブアプリのプログラマーにとってのTCPのような位置づけになるわけで、システムプログラミングと冠した『Goならわかるシステムプログラミング』でHTTPを扱うのはまったくもって自然だったのだなあ(たぶんあとづけ)。

Goならわかるシステムプログラミング(紙書籍)www.lambdanote.com

さらに、ネットワーク技術の解説書としては、再送制御とか輻輳制御の話もQUICとは独立に解説してあげないと意味がなさそう。 QUICそのものとは別なので、汎用の専門的な解説書がほしいところです(計画進行中)。

もちろん、QUICの下はIPv6です(繰り返しになりますがUDPは本質じゃないよ)。 IPv6については『プロフェッショナルIPv6』があるので安心ですね!

プロフェッショナルIPv6(紙書籍+電子書籍)www.lambdanote.com

そんな感じで、これからQUICとHTTP/3が本格的に普及してくると、インターネット技術の教科書にも大胆な構成変更が求められるようになるかもしれません。 具体的には、トップダウンでこんな構成にするのはどうですかね。

第1章 ウェブの概要
第2章 HTTP
第3章 インターネットの信頼モデルと認証付き暗号
第4章 QUICとその一部としてのTLS
第5章 トランスポートの信頼性に関するさまざまな技術
第6章 IPv6の概要

興味がある専門家の方からのご連絡をお待ちしています!(一部の章だけでもいいよ!)