QUICは機械間トラフィックのようなユースケースにはあまり向いていないね。でも、今のインターネットのトラフィックのほとんどはモバイルフォンからサーバーへのもので、そこでQUICとHTTP 3が輝くんだ。他のユースケースではTCPを使い続ければいいと思う。

そうなんだよね。さらに悪いことに、TCPトラフィックの混雑に直面すると、何もなくなっちゃうのを見たことがある。もしQUICが本当に未来のプロトコルなら、カーネルに移行するのはいいことだと思う。こんなに大きなユーザースペースの実装をあちこちに提供して、なおかつ古き良きTCPに勝てると思ってるのは狂気だよ。NICレイヤーまで最適化が必要になるかもしれないし、ミドルボックスもね。あ、UDPのCPUコストについてはまだ触れてないけど。逆に、TCPはジムでいつもダボダボの服を着てる静かな奴みたいなもので、誰も見てないときにベンチで4プレートやるんだ。過小評価しちゃダメだよ。この教訓を学ぶのに数ヶ月無駄にしたから。

「速い」という主張は単に違うと思う。QUICは以下のようにして速くすることを目指している: - レイテンシの低いハンドシェイク - ユーザーとサーバーの間の悪い「ミドルウェア」ボックスを避ける - ユーザーのIPアドレスが変わったときに接続をリセットしない - ヘッドオブラインブロッキングや多くの接続の立ち上げコストを避ける - 悪い混雑制御アルゴリズムを避ける - おそらく他にもいろいろ これらは、ユーザー（多くはモバイルデバイス）とサーバーの間でよく見られるネットワーク状況でうまく機能するためのものだと思う。QUICはデータ送信時のOSオーバーヘッドを減らすことで速くなることを目指しているわけじゃないし、オペレーティングシステムがこのフローに対してより最適化され、ハードウェアがより多くの作業をオフロードできるようになるまで、一般的には長い間遅くなることを期待すべきだと思う。もしあなたがGoogleなら、そのために特化したネットワークカードやドライバー、ソフトウェアに投資するつもりだろうね。

TCPがどれだけよく設計されているかの興味深い証拠だね。

QUICのパフォーマンスはバッチ処理の使い方に気をつけないといけない。UDPパケットを無造作に使うと、つまりシステムコールごとに1つのQUICパケットを送ると、すごくオーバーヘッドがかかるんだ。カーネルがどのインターフェースを使うか決めて、バッファにキューイングするたびにね。TCPのように使って、たくさんのデータをバッチ処理して1回の「呼び出し」でパケットをキューイングすると、すごく助かる。同様に、カーネルのWireGuard実装はトラフィックをバッチ処理しないから、wireguard-goより遅くなることがある。現代のハードウェアが提供する速度では、効率的にするためにベクタードI/Oを使う必要があるね。

そうだね。msquicは最高のパフォーマンスを誇る実装の一つで、約7Gbpsを達成してる。

TCPの方がQUICよりもベンチマークでずっと良いパフォーマンスを発揮すると思うよ。実際にローミングLTE接続でベンチマークをやって、結果を持ってきてほしいな。実際のベンチマークコードを見ないと、その特定の結果に気を使うべきかどうかも判断しづらいし。もし目的が内部または公共のインターネットでAからBに大量のバイトを送ることなら、TCPを上回るものはほとんどないと思う。数十年かけてTCPを最適化してきたからね。HOLブロッキングが問題でなければ、HTTPをTCPの上で使い続ければいいんじゃないかな。

個人的には、Googleのプロプライエタリなクソみたいなものだから、避ける理由としては十分だと思う。それが実際に良くないっていうのも、さらに説得力のある理由だね。

硬直化は「Linuxのメンテナー」の決定から生じるわけじゃない。ミドルボックスを設計、販売、展開している人たちを見ないといけないよ。

私の意見では、サーバー側はカーネルに置くべきだと思う。そうすれば、カーネル内TCPに近いパフォーマンスが得られるし、硬直化もそれほど問題にならない。サーバー側のカーネルを修正するのは「簡単」だからね。一方で、クライアント側はユーザースペースにいるべきだ。クライアントのカーネルを修正するのは難しいから。もしあなたがGoogleなら、Androidクライアントがカーネル内プロトコル処理を定期的に更新できるモデルに向けて取り組むかもしれないけど、どうもGoogleはそれをやる気も能力もないみたい。AppleやMicrosoftはほとんどのユーザーに優先的なカーネル更新を迅速に提供できるし、Appleはクライアントに使ってほしいもの（IPv6、MP-TCP）をサポートするようネットワークに影響を与えることもできる。もしTCPの両側での混雑制御に満足していて、http/1のように複数のTCP接続を開くことを厭わないなら、QUICはTCPにはない再送制御を提供するけど、それだけでは魅力的とは言えないと思う。そう、TCP最適化を行うミドルボックスにはまだ硬直化がある。私の情報は古いかもしれないけど、IPv6では誰もそれをやっていないという印象があったから、v6への推進はNATや特にCGNATを避ける手段でもあり、ネットワークプロバイダー（コスト削減）やサービス（ストレス軽減）にとってもメリットがあると思う。

QUICをカーネルに入れると、QUICがかなり硬直化しちゃうと思う？もしそうなら、実際に必要なシステムコールのパフォーマンスペナルティにはどう対処するつもり？君の懸念は理解できるよ。Linuxカーネルはユーザースペースのソフトウェアよりも動きが遅いし、ミドルボックスはカーネルを更新しないこともあるからね。

プロトコル自体は、実装がどうであれ、硬直化に対して抵抗力があるんだ。これは主に暗号化を使うことで達成されていて、プロトコルの重要で必須な部分になってる。エンドポイント間でプロトコルの露出を最小限に抑えるのが目的で、残りは暗号化されてるから、「ミドルボックス」がパケットを見て自分の解釈で変なことをするのを防げるんだ。エンドポイントは好きなことができるし、硬直化は起こり得るけど、インフラレベルでの硬直化を防ぐのには役立つ。サーバーのLinuxカーネルを更新するのは、ネットワークのバックボーンを構成するプロプライエタリハードウェアを変更するよりも簡単だよ。QUIC/IPを直接使う代わりにUDPを使うのも、硬直化防止の手法で、アプリはQUICのカーネル実装に関係なくUDPとユーザースペースのライブラリを使えるからね。理論的には生のソケットでもできるけど、ポートがないから自分のために全体のインターフェースが必要で、しばしばrootアクセスも必要になるから、もっと問題が多い。

https://lwn.net/ml/all/cover.1751743914.git.lucien.xin@gmail...

SSHは、QUICで暗号化やマルチプレクサのレイヤーを置き換えるためにかなりの作業が必要だね。QUICログインプロトコルをゼロから作るのが良さそう。いろんなプロトタイプの状態で、いくつかのアプローチがあるみたいだよ。

OpenSSHはOpenBSDのプロジェクトだから、LinuxのAPIはあまり興味ないかもしれないけど、もちろん間違ってるかもしれないね。

ハードウェアアクセスのためのモード切替が遅いね。TCP/IPはWindowsとLinuxのカーネル内に残ってる。

パフォーマンスは、ポーリングにコアを専念させることで得られるもので、ユーザースペースからは来ないよ。

その通りだけど、アプローチが二つあるからちょっと混乱するよね。どちらのアプローチもコンテキストスイッチやシステムコールを排除することでパフォーマンスを向上させるって言えると思う。1. カーネルバイパスとDMA、パケット処理にCPUを専念させる技術がパフォーマンスを上げる。2. 「データプレーンからユーザースペースを排除する」って考えると、sendfileやktlsのようなもののパフォーマンスが向上する。君の言う通り、カーネル内のQuicはこのどちらの利点も持ってないみたいだね。

それに関しては、ユーザースペースがネットワークデータを直接取得するんだ。syscallを関与させないと思うけど。これはエンドユーザー向けのソフトウェアにはやらないことで、MOFAANGみたいなところだけが必要とするものだね。理論的には、io_uringのようなものが全体にこれらの利点をもたらすはずだけど、まだ実現はされてない（でも、楽観的でいるよ）。

カーネル内のネットワーキングはすごく速いよ。ASICだとさらに速い。ネットワークスタックがユーザースペースに移動したのは、GoogleがTCP自体を置き換えたかったから（TLSもアップグレードしたかった）だけど、ブラウザのことしか気にしてなかったから、スタックをブラウザに入れちゃったんだよね。それで問題解決。

バイトをNICのバッファにオフロードする必要があるよ。DMAのようなことをして、NICが読み取るために特権スペースにバイトを書き込むか、syscallの境界を越えてカーネルにバイトをNICのバッファに書き込ませる必要がある。syscallの境界を越えると、メモリ空間と特権リングの切り替えによる大きなパフォーマンスペナルティが発生するから、ユーザースペースのネットワーキングは特権の変更に対処しなくて済む場合か、DMAがある場合にしか意味がないんだ。

ほとんどのQUICスタックは、カーネル内のUDPに基づいて構築されてるんだ。トラフィックがカーネルやユーザースペースを通るのを避けられれば、パフォーマンスがかなり向上するよ。ネットワーキングをユーザースペースに移動させて、NICキューに直接アクセスできるようにすれば、カーネルにコンテキストスイッチする必要がなくなる。あるいは、ネットワーキングをカーネルスペースに移動させる方法もあるよ。sendfileみたいな機能を使えば、TCPアプリケーションがカーネルにファイルを送信させることができて、内容をユーザースペースにコピーする必要がなくなる。カーネル内でTLSを使ってsendfileを使えば、ユーザースペースへのコピーを省略できるし、NICベースのTLSならカーネルがディスクからデータを読み取る必要もない。NICベースのTLSで、ディスクがNICバッファにDMAできるなら、データがメインメモリに触れる必要すらない。だけど、ほとんどのQUICスタックはどちらの利点も得られてないんだ。syscallsを通じてパケットを読み書きしていて、パケット化はユーザースペースで行われてる。sendfileを使ってコンテキストスイッチやコピーを省略するチャンスはないよ。io_uringなどを使ったバッチ処理はコンテキストスイッチには役立つけど、コピーを防ぐことはできないかもね。

うーん、それはいい質問だね。TCP+TLSのEncrypted Client Helloにも同じことが当てはまると思うんだけど、どうかな？おそらく、答えは両者で同じか似たようなものになるだろうね。

残念だけど、これは「バグではない」カテゴリーに入ると思う。エンドポイントをTLSエンドポイントまで隠すのはHTTP/3の特徴なんだ。* 実際、これは特徴だと思ってるけど、https://xkcd.com/1172/ も認めてるよ。PS. HAProxyは生のTLSをプロキシできるけど、ホスト名に基づいて直接はできない。Cloudflareトンネルは、TLSを終了させずにホスト名でプロキシできる特別な機能があると思うけど、DNSプロバイダーとして彼らを使う必要があるね。

QUICをサポートしているクライアントは通常、HTTPS DNSレコードもサポートしてるから、低優先度のレコードをフェイルオーバー用に使えるよ。クライアントがそれを処理できる可能性があるからね。（例えば、host -t https dgl.cxを見てみて。）理論上はそうなんだけど、クライアントがそれをやってくれるとは限らない（Chromiumが実際にどれだけHTTPSレコードをサポートしてるか見てみて[1]）。でも一般的に、QUICが何らかの理由で失敗した場合、クライアントは透明にフォールバックするし、Alt-Svc[2]ヘッダーも尊重されるよ。もし計画的なフェイルオーバーなら、Alt-Svcレコードの送信を止めて、代替がタイムアウトするのを待つこともできるけど、厳密には必要ない。もし本当にQUICをルーティングしたいなら、SNIは常に最初のパケットに含まれてるから、最初のパケットを検査することでフローをルーティングできるのがいいところだね。Cloudflareのudpgrm[3]を見てみて（これだけでは他のマシンにプロキシするには不十分だけど、基本的な部分はあるよ）。Encrypted Client Hello（ECH）がない場合、クライアントハロー（SNIを含む）は既知のキーで暗号化されてる（これはQUICのバージョンを知らないミドルボックスが壊すのを防ぐため）。だから、復号することは可能で、udpgrmのコードを見てみて[4]。ECHがある場合、「ルーター」はECHを復号するためのキーを持っている必要があって、それをインラインで復号して判断を下すことができる（これはTLSキーとは異なり、フォールバックHTTPSレコードを使って非フォールバックルートとは異なるキーを使うこともできるけど、ブラウザが現在それをサポートしているかは別の問題だね。ただ、プロトコル上では可能だよ）。これは、ECHを使ったフォールバックがHTTP/2とTCP接続でサポートされる方法に似てる。

フェイルオーバーの状況では、QUICのフェイルオーバーは全く気にしない方がいいと思う。ブラウザがQUIC接続を確立できない場合（DNSで広告されていても）、HTTP1/2 over TLSを試みるからね。そうすれば、問題がなければ同じフェイルオーバーメカニズムを使えるよ。

それはただのボトルネックの一つだね。もう一つの問題はヘッドオブラインブロッキングだよ。TCP接続でパケットロスが発生すると、その後に送信されたものはロスが修復されるまで配信されないからね。

記事では、QUICが現在遅い理由がいくつか挙げられてるね。ほとんどは「まだ最適化してないから」って感じみたい。> Longは、この違いのいくつかの理由を挙げていて、QUIC側でのセグメンテーションオフロードサポートの欠如、伝送経路でのデータコピーの追加、QUICヘッダーに必要な暗号化が含まれてる。これらの理由は、解決可能なものに見えるね。ここでのベンチマークは、完璧なネットワーク条件でのもので、言ってみればドラッグレースみたいなもの。モバイルだと、ネットワークの変動がもっと大きくなるから、そこでTCPの設計の限界がより明らかになるよ。TCP自体は、QUICのようなことをするために上にプロトコルが走ることが多い。HTTP/2がその一例だね。だからQUICとTCPを比べるのは、車の速さと、車輪のついたフレームにエンジンを取り付けた速さを比べるようなものだよ。QUICはOSIネットワークスタックの上の方に位置していて、レイヤー5以上。対してTCP+TLSはレイヤー3。システム設計が少ないんだ。QUICは接続が速く、特に再接続が速いっていう利点もある。IPモビリティもあって、モバイルでIPアドレスが変わった場合（よくあることだよね）、QUICはクライアントが次のパケットを送るまでセッションを維持できる。これは本当に考え抜かれた素晴らしい進歩で、いろんな面で劇的に良くなってる。複数のノンブロッキングストリーム（SCTPのようなもの）があることで、高レベルのプロトコル設計が引き受ける範囲が大幅に減るんだ。そして、そのマルチストリーミングがカーネルにあることで、TCPでは享受できない深い最適化が可能になる。もう古いボロボロのTCPを引きずり回すのはやめよう。変な手作りのものをその上に乗せるのもやめて、もっと良いスタート地点が必要だよね。QUICは本当に魅力的だよ。

「利点」は、サーバー提供の接続IDによるトラッキングだよ。 https://www.cse.wustl.edu/~jain/cse570-21/ftp/quic/index.htm...

TCPのボトルネックはハンドシェイクだと言われてる。でも、それは接続を再利用することで解決できる。 まだ存在しない接続を再利用することはできないよ。これの多くは、全体的な速度ではなく、レイテンシを減らすことに関することなんだ。