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のメンテナー」の決定から生じるわけじゃない。ミドルボックスを設計、販売、展開している人たちを見ないといけないよ。