TCP か UDP か
TCP か UDP か
TCP の枠組みで head-of-line ブロッキングを直せないのであれば、理論的には、新しいトランスポートプロトコルをネットワークスタックの中、UDP と TCP に隣接して作れるようになるべきです。もしくは 最悪 SCTP を使うべきかもしれません。SCTP は RFC 4960 の中で IETF によって標準化されたトランスポートプロトコルの一つで、必要とされるいくつかの機能を持っています。
しかし、近年新規のトランスポートプロトコルを作る取り組みは、ほとんどすべて休止しています。何故なら、インターネット上に実際に展開することに困難が伴っていたからです。新規プロトコルの展開は、到達すべきユーザーとサーバーの間に展開されている TCP もしくは UDP のみ許可する、多数のファイアーウォール、NAT、ルーターなど、その他のミドルボックスによって阻まれてきました。他のトランスポートプロトコルを導入することは、N %のコネクションを失敗させることになります。何故なら UDP もしくは TCP ではないということは、何らかの形で不正、もしくは間違っているとボックスにみなされ、ブロックされるからです。多くの場合、 N %の失敗率は努力に対して高すぎるとみなされます。
加えて、通常ネットワークスタックのトランスポートプロトコルレイヤーの中を変更することは、OS のカーネルによって実装されているプロトコルを変更することを意味しています。OS のカーネルを更新して展開することは、多大な努力を必要とする遅いプロセスです。IETF によって標準化された多くの TCP の改善は、広くサポートされていないため、広範囲に渡って展開されたり使用されたりしていません。
なぜ SCTP-over-UDP ではないのか
SCTP はストリームを用いた信頼性のあるプロトコルで、WebRTC には UDP を介してSCTPを使用する実装さえ存在します。
これは QUIC に取って代わるものとして十分ではありませんでした。以下を含む幾つかの理由に原因があります。
SCTP がストリームの head-of-line ブロッキング問題を解決しないこと
SCTP では、ストリームの数をコネクションのセットアップ時に決めなければならないこと
SCTP が確かな TLS/security レイヤーを持たないこと
SCTP は 4-way ハンドシェイクを使用し、QUIC は 0-RTT を提供すること
QUIC は TCP 同様バイトストリームで、SCTP はメッセージベースであること
QUIC コネクションは IP アドレス間を移動することができ、SCTP はできないこと
更なる詳細と違いについては、A Comparison between SCTP and QUIC インターネットドラフトが参考になります。
Last updated