QUICはTCPの代替ではない

ブルース・デイヴィーのブログより。 TCPの新しい決定的な仕様(RFC 9293)の公開は、私たちの世界ではとても大きな出来事で、このトピックに関する2回目の投稿をせずにはいられませんでした。特に、QUICとTCPを比較した議論に興味をそそられ、今週のニュースレターを書くきっかけとなりました。 TCPの過去と未来に関する前回の投稿では、QUICがTCPを置き換え始めるかも知れないという可能性について触れました。今週は、QUICは実際にはTCPが解決する問題とは異なる問題を解決しているので、TCPの置き換えとは別のものとして見るべきであると主張したいと思います。一部の(あるいはほとんどの)アプリケーションでは、QUICがデフォルトのトランスポートになるかも知れませんが、それはTCPが本来意図されていなかった役割に押しやられたからだと思います。なぜ私がそのような主張をするのか、一歩下がって考え

[koyhoge]

TCPとUDPの他にRPCに特化したプロトコルがIPの上に必要だったのが、HTTP3(QUIC)でようやくそれが実現したという話。

[yosuke_furukawa]

“HTTP(S)は、(snip)RPCに近いもので(snip)、QUICは(snip)HTTP(S)上で実行されるアプリケーション、特にgRPCや、私たちが依存するようになったすべてのRESTful APIに確実にメリットをもたらすものです。”

[honma200]

TCPは輻輳処理とか再送とかパケットのセグメントとか全部任せられたんだからその上の実装としてはまだまだ残ると思う

[aox]

HDMIで良いのでは

[hasiduki]

ふーん！！！！！

[lli]

何でもかんでもhttpに乗っけすぎな気もしなくもない

[onesplat]

面白いけど結局QUICが代替できないのはどんなケースなの？大きなファイルのダウンロードってこと？だとしたら何故？WebSocketsのような双方向バイトストリーム用ということであれば理解できる

[takehikom]

『TCP/IPスタックにRPCのサポートがないことが、QUICの土台を作りました』

[kagehiens]

勉強しやすいHTTP＋TCP/IPがQUICに置き換わることで最初のハードルが上がりそうな予感があるの、ジレンマだなと思う。