SCTP の原理：マルチストリーミングとマルチホーミング

SCTP は TCP と UDP の「いいとこ取り」を狙う

SCTP（Stream Control Transmission Protocol, RFC 9260、旧 RFC 4960）は、IP の直上で動く第3のトランスポートプロトコル（プロトコル番号 132）です。TCP の信頼性・順序保証・輻輳制御を受け継ぎつつ、TCP が苦手とした 2 つの弱点、すなわちバイトストリームによる Head-of-Line（HoL）ブロッキングと単一経路への依存を設計段階から解消するために生まれました。もともとは電話網の信号（SS7）を IP 上で運ぶ用途で標準化され、現在は WebRTC のデータチャネルなどでも使われます。前提となる TCP/UDP の役割分担は /network/tcp-udp/ を参照してください。

TCP との対応関係を一望すると、SCTP の設計意図が見えてきます。

チャンクベースのメッセージ指向設計

TCP がバイトの連なりを運ぶのに対し、SCTP はメッセージ（アプリが渡した 1 単位）の境界を保ったまま運びます。受信側は送信側が send した塊をそのまま 1 回の recv で受け取れるため、TCP のように「どこまでが 1 メッセージか」をアプリが自前で区切る必要がありません。

この実現の核が**チャンク（chunk）**という可変長の単位です。1 つの SCTP パケットは、共通ヘッダの後ろに複数のチャンクを連結した構造を持ちます。チャンクには制御用とデータ用があります。

SCTP パケット
├─ 共通ヘッダ（送信元ポート, 宛先ポート, 検証タグ, チェックサム）
├─ DATA チャンク（TSN, stream_id, SSN, ペイロード）
├─ DATA チャンク（TSN, stream_id, SSN, ペイロード）
└─ SACK チャンク（累積 TSN, ギャップ報告ブロック）

ここで識別子の役割分担が重要です。

• TSN（Transmission Sequence Number）: 関連全体で単調増加する番号。**信頼性（再送・重複排除）**を担う。受信側は SACK（Selective ACK）チャンクで「累積到達 TSN」と「飛び飛びに届いたギャップ」を報告する。
• stream_id: そのメッセージがどのストリームに属するか。
• SSN（Stream Sequence Number）: ストリーム内での順序番号。順序保証を担う。

TSN が信頼性、SSN が順序という役割の分離こそが、次に述べる HoL 解消の土台です。

複数ストリームによる HoL ブロッキングの解消

TCP は順序保証をコネクション全体に対して 1 本のシーケンス空間で行います。そのため、あるセグメントが 1 つ欠落すると、後続が届いていても接続全体の引き渡しが止まり、再送が完了するまで無関係なデータまで待たされます。これが TCP 層の HoL ブロッキングです。

SCTP は 1 つの関連（association、TCP のコネクションに相当）の中に複数の独立したストリームを持ちます。順序保証は SSN によりストリーム単位で閉じているのが核心です。あるストリームの DATA チャンクが失われても、待たされるのはそのストリームだけで、別ストリームのチャンクは到着次第アプリへ引き渡せます。

さらに SCTP は**順序なし配送（unordered delivery）**も選べます。DATA チャンクの U ビットを立てると SSN による順序づけを省き、届いた順に即引き渡します。順序が不要なメッセージで遅延を最小化できます。考え方は QUIC のストリーム多重化と共通で、対比は /network/quic-internals/ が参考になります。

複数アドレスへの冗長化（マルチホーミング）

TCP コネクションは「送信元IP・ポート・宛先IP・ポート」の 4 タプルで固定されるため、使っている経路が落ちると接続ごと失われます。SCTP は確立時に両端がそれぞれ複数の IP アドレスを交換し、1 つの関連が複数アドレスの集合として成立します（マルチホーミング）。

• 通常は**プライマリパス（primary path）**1 本でデータを送る。
• 各宛先アドレスへ定期的に HEARTBEAT チャンクを送り、HEARTBEAT-ACK の有無で各経路の到達性を監視する。
• 応答が連続して途切れ、その宛先への再送回数が Path.Max.Retrans の閾値を超えると、その経路を非アクティブと判定し、別の有効なアドレスへフェイルオーバーする。

ホストA {IP-a1, IP-a2}  ⇄  ホストB {IP-b1, IP-b2}
  primary: a1 → b1 でデータ送信
  HEARTBEAT を b1 と b2 の双方へ定期送出（到達性監視）
  b1 が無応答多発 → 経路を a1 → b2 等へ切替（関連は維持）

なお、複数 IP を端点が直接やり取りする設計上、SCTP は NAT との相性が悪く、インターネットの広域では普及が限られました。データセンター内部や WebRTC（DTLS でカプセル化）といった制御可能な環境が主な活躍の場です。

4-way ハンドシェイクと Cookie による SYN フラッド耐性

SCTP の確立は TCP の 3-way ではなく 4-way です。一見冗長ですが、これは SYN フラッド攻撃への根本的な耐性を確立手順そのものに組み込んだ結果です。

クライアント                              サーバー
  |-- INIT（自分のタグ・複数アドレス）------>|
  |                            （状態を保存せず Cookie を生成）
  |<- INIT-ACK（相手のタグ・State Cookie）---|
  |-- COOKIE-ECHO（受け取った Cookie）------>|
  |                            （Cookie を検証して初めて状態確保）
  |<- COOKIE-ACK ----------------------------|
  両端 ESTABLISHED（DATA 送信可能）

核心は、サーバーが INIT を受け取った時点では関連の状態をメモリに確保しないことです。代わりに、関連に必要な情報（相手のアドレス・タグ・タイムスタンプなど）を State Cookie にまとめ、サーバーの秘密鍵で MAC（メッセージ認証コード）を付けて INIT-ACK に載せて返し、自分はその Cookie を保持しません。

クライアントが COOKIE-ECHO で Cookie を送り返してきたとき、サーバーは MAC を検証して改竄も期限切れもないことを確認できて初めて、関連の状態をメモリに確保します。

INIT/INIT-ACK で交換する 検証タグ（Verification Tag）も重要です。以後のすべてのパケットは相手から受け取ったタグを共通ヘッダに載せ、タグが一致しないパケットは破棄されます。これにより、4 タプルを推測した攻撃者による盲目的なパケット注入（ブラインドインジェクション）や、古い関連の遅延パケットの誤配を防ぎます。TCP の ISN だけに頼る防御より明確に堅牢です。

部分信頼性（PR-SCTP）という拡張

SCTP には「信頼性の度合いをメッセージ単位で緩める」拡張（PR-SCTP, RFC 3758）もあります。たとえば有効期限を過ぎたら再送をあきらめるポリシーを指定でき、リアルタイム性が信頼性より重要なメディアデータに向きます。TCP が常に完全信頼であるのに対し、SCTP は「完全信頼・部分信頼・順序なし」をメッセージごとに選べる柔軟さを持ちます。フロー制御の基本的な考え方は TCP と共通で、/network/tcp-flow-control-window/ と対比すると理解が深まります。

まとめ

SCTP の本質は、TCP の信頼性・順序・輻輳制御を継承しつつ、順序保証をストリーム単位（SSN）に分解して HoL を断ち、端点を複数アドレスの集合（マルチホーミング）として障害に耐え、確立を Cookie によるステートレス 4-way にして SYN フラッドを無効化する点にあります。チャンクという可変長単位がメッセージ境界・信頼性・順序・制御をひとつの枠組みで運ぶ設計が、これらを支えています。NAT との相性ゆえ広域での普及は限定的でしたが、その設計思想は QUIC をはじめ後続のトランスポートに確かに受け継がれています。