はじめに

インターネット通信の高速化については個人的に結構前から興味があって、確か2012年か2013年時点でGoogleがQUICに取り組んでいたことはなんとなく覚えているのだけれど、インフラの話も絡んでくることもあり、なんとなく誰にでも検討できるものでもないんだろうなという印象を当時持った気がする。

(NoTCPという名前から連想される)NoSQLのように、現在当たり前に使用しているインフラを疑ってみるというのは発想として面白いと思うが、ネットワークのような全世界共通のインフラに対して何ができるかという点(例えばTCPの輻輳制御における公平性の議論など)に関しては検討が必要な点も多いと思う。いずれにしろ興味深い分野なので引き続きウォッチしたい。

なお、本文書の原文はThe NoTCP Manifestoであり、ライセンスはCreative Commons Attribution-ShareAlike 4.0 International Licenseである。

さらに別の最先端技術宣言

ああそうとも、Node.jsとNIOが難解なコードをもたらすもの性能そのものが常に価値を持つものであることを世に示したのと同じように、特注のNoSQLデータベースの氾濫は一般的なデータベースと比較して特定用途向けのソリューションに価値があることを教えてくれたのと同じように、Reactive Manifestoが新しいブランディングが10年前のアイデアに若々しい成長を与えてくれることを思い出させてくれたのと同じように、どこでも使われているTransmission Control Protocolの快適性に挑戦し、UDP上に構築された職人技のプロトコル群により今がまさにルネッサンスにふさわしい状態であるということを認識することにより、上記の先人の足跡に続こうと思う。私たち自身はこの炎を燃やし始めたわけではなく、単にこれをこう名づけただけだ：the NoTCPムーブメントと。

信頼性は感覚を麻痺させる

TCPが目指すものは生のIPもしくはUDP上で信頼性を提供することである。パケットはエラーチェックされ、明示的に応答確認されるか必要に応じて再送され、順番に再構成される; ユーザは読み込みもしくは書き込みが失敗した場合は通知される。これはアプリケーションを構築するために手軽な正確性を提供するが、私たちはこの"信頼性"という属性のブランドが誤解を招くものだという異議を表明する。Oxford英語辞書は信頼できるという単語を、形容詞として下記のように定義している:

人間、情報など対して:信用することができる; 依存もしくは信頼を置くことができる、頼りになる、安全である、確かである
製品、サービスなどに対して: 一貫して品質やパフォーマンスが優れている、依存することができる
測定の方法・技術に対して: 同一の条件で繰り返した場合に一貫した結果をもたらす

このことは安心感のある、あいまいな感情をもたらすが、あまり歓迎できないものである。それは"TCPは決して通知なく失敗することはない"というより"TCPは決して失敗しない"という不適切な連想をさせるかもしれない。加えて、通信の失敗はユーザ指定のある範囲として定義される: TCPのシーケンス処理とロストしたパケットの再送には時間が必要だ - ときどき本当に長時間となる - そして永遠に待つことはできない。典型的にはある(おそらく限られた)再送時間のタイムアウト制御を行い、ソケットAPIは(例えばPOSIXのsetsockoptのような)ユーザ指定のタイムアウトによる制御を常に提供しなければならない。それでも依然として、実装依存のデフォルトタイムアウトに頼り、失敗の対処を怠り、無知による自己満足に陥いる。なぜなら、"TCPには信頼性がある"からである。

一度で成功しなければ

TCPは接続志向であり、IP上で多重化されている。ここで接続はローカルとリモートホストのIPアドレスとポートにより特定される。さてここで全てのTCPメッセージに職人的なタイムアウトを慎重に設定してみることを考えよう。もしここのパケットがロストすると、再送タイムアウトにより定められたように、パケットは同じ接続上で再度送信される; もしユーザタイムアウトに達したら、接続はクローズされる。これは所望の振る舞いではないかも知れない。例えば:

もしアプリケーションがある程度のパケットロスを許容できる場合は、再送に関して非常に細かい制御を求める可能性がある。または、リアルタイムアプリケーションの場合には再送を全く好まないことさえあるかもしれない。
もしクライアントがプールされたサーバの間でロードバランスされる場合には、同じサーバに再送されるより、パケットロス後に別のサーバに再送されるほうが的を得ているかも知れない。それもアプリケーションに依存するが。
モバイルデバイスはワイヤレスネットワークの間を移動するにつれ頻繁にIPアドレスを変更するかも知れない。TCPはこれを新規接続だとみなすため中断されたストリームを最初から再開し、アプリケーション層はTCPとは別にストリームの状態を独自で管理する必要がある。

ここでの統一されたテーマはアプリケーションが自身の特定の要求、失敗の想定発生要因やリカバリについて知っており、それはTCPが見越せるものよりもよい状態となる、ということである。TCP上で構築されたアプリケーションにおけるネットワーク通信の失敗を扱うとき、決まって結局TCP自身のエラー対処ロジックの一部を不十分に再実装し、処理の明確な改良の機会を逸することになる。TCP上にレイヤを構築するとき多くの場合役に立つよりも不都合となる; これはend-to-end argumentの変種である。

損の上塗り

TCPは3wayハンドシェイクにより接続を確立し、このハンドシェイクは遅延という意味で比較的コストのかかる処理である。加えて問題はスロースタートであり、これはネットワーク輻輳の回避の目的で新規接続のスループットを制限する。もし複数の接続を行いたい場合、同じIPアドレス間のものであっても各接続ごとにこれらのコストを負担する必要がある。これはHTTP/1.1のトラフィックでよくあることで、例えばクライアントが並行して同じサーバに複数のリソースを問い合わせる際に発生する。

接続ごとのコストを回避しようと思うのは自然であるが、物事は奇妙な方向に進んでいる: 状況はストックホルム症候群と全く同じというわけではないが、レイヤ自体を捨ててしまうより、TCP上で複数接続を行うプロトコルを実装している - 例えばHTTP/2のように。複数の、論理的なデータのストリームを取り扱い、ストリームを単一のTCP接続上で非決定論的に相乗り運用している。

現在の問題はTCPが私たちが必要としている以上の順序保証を提供することにある: 全てのパケットが到着し次第順序の再構成が行われるが、インタリーブしているのだからそもそも複数ストリーム間のパケット到着順序を気にすることはないことは自明である。遅れて到着したパケットは接続上で多重化された全てのストリームのための使用可能なデータを人為的に遅延させる; これはhead-of-line blockingの一形態である。前述した通り、アプリケーションはTCPよりアプリケーション自身に特有の要件を知っている; このケースでは、私たちは重大な定常状態の遅延と交換に通信開始時の遅延を手に入れたのである、どちらも必要のないときに。

本気か?

ああ、もちろん。それがクールだとされる前に、UDPを用いて成功した特定用途のプロトコルがたくさんある: 少し例を挙げるとDNS, NTPとRTPである。さらに最近の成功例を挙げるとBitTorrentのuTPがある。しかし私たちがこのムーブメントの広告塔は実験的なQUIC プロトコルであろう。おそらく聞いたことはないだろうが、それは"信頼性"があり、接続志向のプロトコルである - TCPと同じような感覚で - head of line blockingなしに多重化をサポートし、そして勝手にローカル/リモートそれぞれのIP/ポートの4つ組に結合していることもない。通信は暗号化され、暗号化することで興味深く、おそらく巧妙な保証を提供する: 中間のノードはフローと輻輳制御の情報(ACKとNACKのような)を嗅ぎ回ることはできない。このことは要件に最も適した異なる輻輳制御アルゴリズムを選択する自由をもたらす。

しかし、おそらくQUICですら、読者の洗練された好みに対しては即席料理のようなものだろう。その前方誤り訂正の実装は単なるECIPの盗用だと考えるかもしれない。おそらくレイヤ化されたOSIモデルを基本的に間違ったものであると見え、水平方向に構築した新しい、モジュール化されたビルディングブロックから自然発生した他の方法を探索するかも知れない。もしくはインターネットが実際どのように動作しているかについてある手がかりをつかんでおり、すでに知っている事柄について伝えるマニフェストを必要としていないかも知れない。