メインコンテンツまでスキップ

4. Relevant Differences between QUIC and TCP (QUICとTCPの関連する違い)

TCPのパケット損失検出と輻輳制御に精通している読者は、よく知られたTCPアルゴリズムと類似するアルゴリズムをここで見つけるでしょう。しかし、QUICとTCPの間のプロトコルの違いがアルゴリズムの違いにつながります。これらのプロトコルの違いを以下に簡潔に説明します。

4.1. Separate Packet Number Spaces (個別のパケット番号空間)​

QUICは各暗号化レベル (Encryption Level) に対して個別のパケット番号空間 (Packet Number Spaces) を使用しますが、0-RTTとすべての世代の1-RTT鍵は同じパケット番号空間を使用します。個別のパケット番号空間により、ある暗号化レベルで送信されたパケットの確認応答が、別の暗号化レベルで送信されたパケットの誤った再送信 (Spurious Retransmission) を引き起こさないことが保証されます。輻輳制御と往復時間 (RTT) 測定は、パケット番号空間全体で統一されています。

4.2. Monotonically Increasing Packet Numbers (単調増加するパケット番号)​

TCPは送信側の送信順序と受信側の配信順序を混同し、再送信曖昧性問題 (Retransmission Ambiguity Problem) [RETRANSMISSION] を引き起こします。QUICは送信順序と配信順序を分離します：パケット番号は送信順序を示し、配信順序はSTREAMフレーム内のストリームオフセット (Stream Offsets) によって決定されます。

QUICのパケット番号はパケット番号空間内で厳密に増加し、送信順序を直接エンコードします。より高いパケット番号はそのパケットがより遅く送信されたことを示し、より低いパケット番号はそのパケットがより早く送信されたことを示します。確認応答誘発フレームを含むパケットが損失として検出されると、QUICは新しいパケット番号を持つ新しいパケットに必要なフレームを含めることで、ACKが受信されたときにどのパケットが確認応答されたかについての曖昧さを解消します。その結果、より正確なRTT測定が可能になり、誤った再送信が簡単に検出され、高速再送信 (Fast Retransmit) などのメカニズムがパケット番号のみに基づいて普遍的に適用できます。

この設計ポイントにより、QUICの損失検出メカニズムが大幅に簡素化されます。ほとんどのTCPメカニズムは、TCPシーケンス番号に基づいて送信順序を暗黙的に推測しようとしますが、これは特にTCPタイムスタンプが利用できない場合、簡単ではない作業です。

4.3. Clearer Loss Epoch (より明確な損失エポック)​

QUICはパケットが損失したときに損失エポック (Loss Epoch) を開始します。損失エポックは、エポックの開始後に送信されたパケットが確認応答されると終了します。TCPはシーケンス番号空間のギャップが埋められるのを待つため、セグメントが連続して複数回損失した場合、損失エポックは数回の往復の間終了しない可能性があります。両方ともエポックごとに一度だけ輻輳ウィンドウを減少させるべきであるため、QUICは損失を経験するすべての往復に対して一度実行しますが、TCPは複数の往復にわたって一度だけ実行する可能性があります。

4.4. No Reneging (撤回なし)​

QUIC ACKフレームには、TCP選択的確認応答 (SACKs) [RFC2018] と類似の情報が含まれています。しかし、QUICはパケット確認応答の撤回 (Reneging) を許可せず、双方の実装を大幅に簡素化し、送信側のメモリ圧力を軽減します。

4.5. More ACK Ranges (より多くのACK範囲)​

QUICは、TCPの3つのSACK範囲とは対照的に、多くのACK範囲をサポートします。高損失環境では、これにより回復が高速化され、誤った再送信が減少し、タイムアウトに依存せずに前進の進行が保証されます。

4.6. Explicit Correction for Delayed Acknowledgments (遅延確認応答の明示的補正)​

QUICエンドポイントは、パケットが受信されてから対応する確認応答が送信されるまでに発生する遅延を測定し、ピアがより正確なRTT推定を維持できるようにします。[QUIC-TRANSPORT] のセクション13.2を参照してください。

4.7. Probe Timeout Replaces RTO and TLP (プローブタイムアウトがRTOとTLPを置き換える)​

QUICはプローブタイムアウト (PTO, Probe Timeout; セクション6.2を参照) を使用し、そのタイマーはTCPの再送信タイムアウト (RTO, Retransmission Timeout) 計算に基づいています。[RFC6298] を参照してください。QUICのPTOには、固定の最小タイムアウトを使用する代わりに、ピアの最大予想確認応答遅延が含まれています。

TCPのRACK-TLP損失検出アルゴリズム [RFC8985] と同様に、QUICはPTOが期限切れになったときに輻輳ウィンドウを折りたたみません。これは、テールでの単一のパケット損失が永続的輻輳 (Persistent Congestion) を示すものではないためです。代わりに、QUICは永続的輻輳が宣言されたときに輻輳ウィンドウを折りたたみます。セクション7.6を参照してください。これにより、QUICは不必要な輻輳ウィンドウの減少を回避し、Forward RTO-Recovery (F-RTO) [RFC5682] などの修正メカニズムの必要性を排除します。QUICはPTO期限切れ時に輻輳ウィンドウを折りたたまないため、QUIC送信者は、PTO期限切れ後に利用可能な輻輳ウィンドウがまだある場合、より多くの送信中パケットを送信することが制限されません。これは、送信者がアプリケーション制限 (Application Limited) されており、PTOタイマーが期限切れになったときに発生します。これは、アプリケーション制限時にはTCPのRTOメカニズムよりも積極的ですが、アプリケーション制限されていないときは同一です。

QUICは、タイマーが期限切れになったときに、プローブパケットが一時的に輻輳ウィンドウを超えることを許可します。

4.8. The Minimum Congestion Window Is Two Packets (最小輻輳ウィンドウは2パケット)​

TCPは1パケットの最小輻輳ウィンドウを使用します。しかし、その単一のパケットの損失は、送信者が回復するためにPTOを待つ必要があることを意味します (セクション6.2)。これはRTTよりもはるかに長くなる可能性があります。単一の確認応答誘発パケットを送信すると、受信者が確認応答を遅延させるときに追加の遅延が発生する可能性も高まります。

したがって、QUICは最小輻輳ウィンドウを2パケットにすることを推奨します。これによりネットワーク負荷が増加しますが、送信者が永続的輻輳下でも送信レートを指数関数的に減少させるため (セクション6.2)、安全であると考えられています。

4.9. Handshake Packets Are Not Special (ハンドシェイクパケットは特別ではない)​

TCPはSYNまたはSYN-ACKパケットの損失を永続的輻輳として扱い、輻輳ウィンドウを1パケットに減少させます。[RFC5681] を参照してください。QUICは、ハンドシェイクデータを含むパケットの損失を他の損失と同じように扱います。

に最終更新