SCTPとは｜マルチストリーミング・マルチホーミングの仕組みからTCP/UDP比較・導入・運用ポイントまで徹底解説
エバープレイ編集部SCTP とは
SCTP（Stream Control Transmission Protocol）は、IETF により標準化されたトランスポート層プロトコルで、RFC 4960 によって定義されています。TCP の「信頼性」と UDP の「メッセージ指向」の利点を併せ持ち、特に電気通信系シグナリングや WebRTC のデータチャネルなど、マルチパスやメッセージ境界を重視する用途で設計されています。SCTP は「コネクション」ではなく「アソシエーション（association）」という概念を用い、マルチストリーミング、マルチホーミング、メッセージ単位の送受信、部分的信頼性（オプション）などの特徴を備えます。
設計の背景と目的
SCTP は 1990年代後半に電気通信ネットワークのシグナリング（例：SS7 の IP への移行＝SIGTRAN）向けに開発されました。通信の可用性や信頼性が極めて重要な環境で、単一の IP アドレスや単一ストリームによるヘッドオブライン（head-of-line）ブロッキングが問題となるため、複数経路／複数ストリームを利用してこれらを解決することが目的です。
主な特徴
- メッセージ指向：TCP のようなバイトストリームではなく、アプリケーションが送信する「メッセージ（データ単位）」を保持します。メッセージ境界が保たれるため、アプリケーションでの再構築が不要です。
- マルチストリーミング（multi-streaming）：1つのアソシエーション内で複数の独立したストリームを持てます。あるストリームでパケットロスが発生しても、他のストリームのメッセージ配送はブロックされにくく、ヘッドオブラインの影響を緩和します。
- マルチホーミング（multi-homing）：1つのエンドポイントが複数の IP アドレス（複数のインターフェース）を持てます。ある経路が切れても別の経路に切り替えて通信を継続でき、高可用性を実現します。
- 信頼性と順序制御：TCP と同様に信頼性を提供しますが、ストリームごとに「順序付き／順序無し」の選択が可能です。必要な場合は順序保証、不要ならば遅延を避けるために順序無しで送れます。
- 部分的信頼性（PR-SCTP）：RFC 3758 による拡張で、一定回数の再送を超えたらそのメッセージを諦めるといった、アプリケーションに合わせた「部分的に信頼性を落とす」運用が可能です（リアルタイム性重視のデータ等で有用）。
- 強固なハンドシェイク（Cookie Mechanism）：SCTP は INIT → INIT-ACK → COOKIE-ECHO → COOKIE-ACK の 4 ウェイ（擬似的）ハンドシェイクを用い、SYN flood のような攻撃に対する保護を提供します（サーバは最小限の状態でクッキーを返し、クライアントがそれを返して初めて状態を確立）。
- IP プロトコル番号：SCTP は IP のプロトコル番号 132 を使用します（ファイアウォール／中間機器での取り扱いに注意が必要）。
パケット構成とチャンク（chunk）
SCTP の基本単位は「パケット（パケットヘッダ + チャンク群）」で、チャンク（chunk）は制御情報やデータを表します。代表的なチャンクには以下があります。
- DATA：アプリケーションデータ（フラグメント／メッセージ境界情報含む）
- SACK：受信状況の報告（選択的 ACK）
- INIT / INIT-ACK：アソシエーション確立の最初のメッセージ
- COOKIE-ECHO / COOKIE-ACK：クッキーによる確認
- HEARTBEAT / HEARTBEAT-ACK：パスの生存確認（マルチホーミングにおけるパス管理）
- ABORT / SHUTDOWN 系：接続終了や異常停止の通知
大きなメッセージは複数の DATA チャンクに分割され、各チャンクに識別子が付与されます。再送や受信確認はチャンク単位で管理されます。
ハンドシェイクと状態管理
SCTP のアソシエーション確立は、先述の INIT → INIT-ACK → COOKIE-ECHO → COOKIE-ACK という流れです。サーバは INIT を受けると完全な状態を保持せずに INIT-ACK（クッキー含む）を返すため、リソース消費型の攻撃に対する耐性が向上します。アソシエーションは多数のパラメータ（初期シーケンス番号、ストリーム数、タイムアウト等）で管理されます。
SCTP の利点と課題
- 利点：マルチストリーミングやマルチホーミングにより高可用性と遅延の低減、アプリケーションが使いやすいメッセージ指向、部分的信頼性の柔軟性など。電気通信シグナリングや WebRTC のデータチャネルなどで有用です。
- 課題：IP プロトコル 132 を使うため、多くのファイアウォールや NAT がブロックする可能性があります。これに対処するため UDP トンネリング（SCTP を UDP にカプセル化する方式）やユーザー空間実装が用いられるケースが増えています。また、TCP に比べてインターネット全体での普及度が低く、中間機器の互換性問題が現実的な障壁になります。
実世界での利用例
- SIGTRAN（SS7 over IP）などの電気通信シグナリングプロトコル—信頼性と可用性が必須の分野で広く採用。
- WebRTC データチャネル—ブラウザや WebRTC ライブラリでは、SCTP を DTLS/UDP 上で動作させることでリアルタイムデータの多機能な配送を実現。
- 産業系アプリケーションや制御系ネットワーク—メッセージ単位の信頼性が重要な用途。
実装と運用のポイント
- OS / 実装：Linux カーネル（lksctp）、FreeBSD などにはカーネル実装があるほか、ユーザー空間実装（usrsctp など）も存在します。WebRTC ではユーザー空間実装が用いられることが多いです。
- NAT / ファイアウォール：標準の IP プロトコル 132 を通す必要があるため、NAT 越えの問題が生じます。UDP カプセル化（SCTP over UDP）や TURN サーバ経由の利用が回避策として用いられます。
- モニタリング：SCTP 固有の状態（アソシエーション、ストリームごとの統計、パス状態）を監視するツールや SNMP MIB を用意しておくと運用が容易になります。
TCP / UDP との比較（要点）
- TCP に対して：SCTP はメッセージ指向、マルチストリーミング、マルチホーミング、強力なハンドシェイクを提供。TCP は広く普及しており中間機器との互換性が高い。
- UDP に対して：UDP は軽量で遅延が少ないが信頼性を提供しない。SCTP は信頼性を提供しつつ、メッセージ境界を保持する点で UDP とは用途が異なる。
まとめ
SCTP は「信頼性」「メッセージ指向」「高可用性」を同時に実現するために設計されたトランスポート層プロトコルで、特に電気通信分野やリアルタイムデータの分野で有効です。一方で、IP プロトコル番号や中間機器の対応状況など、運用上の注意点もあります。導入を検討する際は、用途（順序保証の要否、可用性要件、NAT 環境の有無）に照らして、カーネル実装かユーザー空間実装か、UDP カプセル化が必要か等を判断することが重要です。
参考文献
- RFC 4960 - Stream Control Transmission Protocol (SCTP)
- RFC 3758 - Partial Reliability Extension for SCTP (PR-SCTP)
- RFC 6951 - UDP Encapsulation of SCTP Packets for the Purpose of NAT Traversals
- Wikipedia: Stream Control Transmission Protocol (日本語)
- 関連 RFC や IETF ドキュメント（IETF Datatracker / Tools で最新情報を確認してください）
