SCTPがあまり使用されない/知られていない理由

私は最近、Richards Stevens 著の本「UNIX Network Programming、Vol。1」を調べたところ、TCPとUDP以外に3番目のトランスポート層標準であるSCTPがあることがわかりました。

概要：SCTPは、UDPのようにメッセージ駆動型ですが、TCPのように信頼できるトランスポートレベルのプロトコルです。以下は、IBM DeveloperWorksからの短い紹介です。

正直なところ、SCTPについて聞いたことがありません。ネットワーキングの本で読んだり、授業で聞いたことを思い出せません。SCTPについて言及している他のスタックオーバーフローの質問を読むと、この知識の欠如に私だけではないことがわかります。

なぜSCTPはそれほど知られていないのですか？なぜあまり使われないのですか？

実際、SCTPは主に通信エリアで使用されています。従来、テレコムスイッチはSS7（Signaling System No. 7）を使用して、テレコムネットワーク内のさまざまなエンティティを相互接続しています。たとえば、通信プロバイダーの加入者データベース（HLR）とスイッチ（MSC）を使用すると、加入者も接続されます（MSC）。

通信エリアはより高速で到達可能な環境に移行しています。これらの変更の1つは、SS7プロトコルをよりエレガントで高速かつ柔軟なIPベースのプロトコルに置き換えることです。

通信エリアは非常に保守的です。ここではSS7ネットワークが何十年も使用されています。非常に信頼性が高く、閉じたネットワークです。つまり、通常のユーザーはそれにアクセスできません。

これとは対照的に、IPネットワークはオープンで信頼性が低く、テレコムは、SS7が処理する負荷を少なくとも処理しない場合、ネットワークに変換しません。これがSCTPが開発された理由です。それは試みます：

• 何十年にもわたって蓄積されたSS7ネットワークのすべての利点を模倣します。
• 速度、セキュリティ、冗長性においてTCPより優れた接続指向プロトコルを作成する

Linuxの最新リリースはすでにSCTPをサポートしています。

現在、SCTPをいくつかのアプリケーションに展開しており、さまざまなホームルーターでのSCTPサポートに重大な問題が発生しています。それらは単にSCTPを正しく処理しません。これは主にパフォーマンスの問題だと思います（SCTPプロトコル仕様では、ヘッダーだけでなく、パケット全体を再計算するためのチェックサムが必要です）。

他の多くの有望なプロトコルと同様に、SCTPはD-linkとNetgearが壊れたNATボックスを修正するまで悲しいことに水中で死んでいます。

SCTPを最大限に活用するには、アプリケーション内でより多くの設計が必要です。TCPよりも多くのオプションがあり、SocketsのようなAPIは後で登場しました。しかし、時間をかけてそれを理解する（そしてTCPの欠点を知っている）ほとんどの人はそれを高く評価すると思います-これは、TCPとUDPに関する30年以上の知識に基づいて設計されたプロトコルです。

いくつかの考慮が必要な側面の1つは、ストリームの側面です。ストリームは（通常はオフにできると思います）ストリーム内の順序保証を提供します（TCP接続と同様）。ただし、SCTP接続ごとに複数のストリームが存在する可能性があります。アプリケーションのデータが複数のストリームを介して送信できる場合は、1つのパケットが誤って配置されたためにレシーバーが餓死するような行頭ブロッキングを回避できます。実質的には、互いに影響を与えることなく、同じ接続を介して異なる会話を行うことができます。

もう1つの便利な追加は、マルチホーミングサポートの追加です。1つの接続が両端の複数のインターフェースにまたがることができ、障害に対処します。これはTCPでエミュレートできますが、アプリケーション層で実行できます。

非一時的な接続にTCPを使用するアプリケーションが最初に実装する適切なリンクハートビートは無料で利用できます。

SCTPの私の個人的な要約は、それが実質的なアプリケーションサポートで（TCPまたはUDPで）別の方法で行うことができなかったことは何もしないということです。それが提供するものは、そのコードを自分で（ひどく）実装する必要がない能力です。

ちなみに、SCTPはDiameterのサポートとして義務付けられています（RADIUS次世代を参照）。RFC 3588を参照

   DiameterクライアントはTCPまたはSCTPのいずれかをサポートする必要がありますが、エージェントと
   サーバーは両方をサポートする必要があります。この仕様の将来のバージョンは
   クライアントがSCTPをサポートすることを義務付けます。

SCTPはあまり知られていないため、あまり使用/展開されていません。理由は次のとおりです。

• 広範囲：TCP / IPスタックにあまり統合されていません（2013年：最新のMac OSXおよびWindowsにはまだネイティブではありません）
• ライブラリ：使いやすい言語での高レベルのバインディングはほとんどありません（免責事項：私はpysctpのメンテナー、PythonのSCTP簡単なスタックサポート）
• NAT：NATをあま​​りうまく通過しません/まったく（1％未満のインターネットホームおよびエンタープライズルーターがSCTPでNATを実行します）。
• 人気：一般公開アプリでは使用していません
• プログラミングパラダイム：少し変わった：それはまだソケットですが、多くのホストを多くのホストに接続できます（マルチホーミング）。
• 複雑さ：SCTPスタックは実装が複雑です（上記のため）
• 競争：マルチパスTCPが登場し、マルチホーミングのニーズ/機能に対応する必要があるため、MTCPを待って、可能であればSCTPの実装を控えます。
• ニッチ：SCTPの塗りつぶしは非常に特殊であり（順序付けされた信頼性の高いデータグラム、マルチストリーム）、多くのアプリケーションでは必要ありません。
• セキュリティ：SCTPはセキュリティ制御を回避します（一部のファイアウォール、ほとんどのIDS、すべてのDLPは、CentOS / Redhat / Fedoraを除いてnetstatに表示されません...）
• 監査能力：世界中の3社のようなものが日常的にSCTPセキュリティの監査を行っています（免責事項：私はそのうちの1社で働いています）
• 学習曲線：SCTPで遊べるツールチェーンはそれほど多くありません（netcatと適切に組み合わせる優れたwithsctpを確認するか、socatを使用してください）
• 裏側：主に通信で使用され、SMSを送信したり、携帯電話でネットサーフィンを開始したり、電話をかけたりするたびに、SCTP（GSM / UMTSを備えたSIGTRAN / SS7、LTE / IMSを備えたDiameter）を介して流れるメッセージをトリガーします/ RCS、S1AP / X2AP with LTE）なので、実際にそれを頻繁に使用しますが、それについては決して知りません;-)

p1。IPv4を介して直接マッピングされたSCTPは、NATゲートウェイでのサポートを必要とします。これはどこにも広く配備されたことはなく、これがないと、一般的なNATゲートウェイは、パブリックアドレスごとに一度に1つのプライベートホストのみがSCTPを使用できるようにします。

p2。UDP / IPv4を介してマッピングされたSCTPでは、パブリックアドレスあたりのプライベートホストの数が増えますが、IPv4 / NATゲートウェイでのUDPマッピングは、NATが追跡する明示的な状態のないコネクションレストランスポートであるため、確立して維持するのが難しいことで有名です。

p3。IPv6で直接マッピングされたSCTPには、... IPv6が必要です。IPv6を導入しようとしましたか？その場合、IPv6ファイアウォールを購入しようとしましたか？SCTPをサポートしていますか？ロードバランサーはどうですか？SSLアクセラレータ？

p4。最後に、インターネットの多くは、TCPポート80およびポート443に適合できるものにかなり制限されているため、あらゆる種類のSCTPはそこで失われる傾向があります。したがって、IETFのMPTCPワーキンググループのような取り組みが見られます。

SCRTはUDPの上にTCPのような信頼性の高いレイヤーを作成するためにWebRTCデータチャネルによって使用されるため、私たちの多くは間もなくSCTPを使用します-UDP上のSCTP over DTLS：https : //tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13＃section-6

SCTPウィキペディアのページを読む主な理由は、SCTPが非常に新しいプロトコル（2000年に提案）であり、現在主流のOS（Windows、OS X、Linux）でサポートされていないことです。

「非常に若い」があなたにとって不適切であると思われる場合は、IPV6について考えてください。

SCTPは、AAAにDiameterが使用されている4G LTEネットワークで広く使用されています。

よく知られていないかもしれませんが、未使用ではありません。ごく最近、IETFで公開された、SCTPをHTTPのトランスポート層プロトコルとして使用することに関するドラフトがありました。

商用ルーターが壊れている、またはSCTPサポートが不足しているというコメントのすべてを参照すると、問題は、NATを使用したSCTPがIETFを使用してまだドラフト形式であることです。そのため、それらを実装するためのRFC仕様はありません。

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctpの誕生は遅すぎ、多くの状況ではTCPで十分です。

また、私が知っているように、その使用法のほとんどは通信エリアで使用されています。