インターネットエンジニアリングタスクフォースは、GoogleとCloudflareがHTTP/3の一部として提案したTCPキラーとなる可能性のある「クイックUDPインターネット接続」に関するコメントの最終日を2020年11月16日と定めた。
QUICの支持者たちは、TCPは通信量が多く、トラフィックの往復時間が長くなると指摘しています。これは決して歓迎すべきことではありませんが、特に無線ネットワークでは望ましくありません。
QUICは、従来のTCPではなく、インターネットのUDPプロトコル上でTLS（トランスポート層セキュリティ）の一種を使用することで、TCP接続でパケットが失われる際に発生するボトルネックを解消できます。そのため、QUICは、接続したことのないクライアントとサーバー間で、デバイス間の往復処理なしにデータを送信することを可能にします。
その結果、Web ページの読み込みが高速化され (これが Google が QUIC を支持した理由です)、インターネットワーキングがより洗練され (これが Cloudflare が QUIC を好む理由です) ます。
Cloudflareについて言えば、QUICワーキンググループの共同議長でもある同社のエンジニアのルーカス・パーデュー氏は先週、インターネット技術タスクフォース（IETF）が先週、QUICが現在「ラストコール」段階にあるという通知を投稿したと指摘した。
QUIC、掘り下げてみよう：マイクロソフトがGoogleが生み出したTCPキラーQUICの実装であるMsQuicをオープンソース化
続きを読む
IETF がここで説明しているように、ラスト コール ステータスは「オープン コミュニティ レビューの最終段階」を表します。
あるいは、パーデュー氏の言葉を借りれば、「ラストコール期間の終了時に、関係者は状況を評価し、必要に応じてフィードバックに対処し、うまくいけば、文書を標準化過程のRFCとして公開するよう要請する次のステップに進むことになるでしょう。」
ここで少し奇妙なことが起こります。Pardue 氏の記述によると、Last Call は QUIC 仕様のドラフト 32 を参照しているにもかかわらず、バージョン 29 が使用されるものとして選択され、実際にほとんどの主要ブラウザーで既に利用可能になっています。
しかし、これで問題は終わりではありません。QUICが最終決定を乗り切った場合、IETF RFCとなり、さらなる議論と検討が行われることになります。
また、Pardue 氏が説明しているように、QUIC と HTTP/3 は拡張可能なので、やるべきことはまだまだたくさんあります。®
