SCTPがあまり使用されていない/なぜ知られていないのか
最近、Richards Stevensの本 "UNIX Network Programming、Vol。1" を調べたところ、TCPおよびUDP： [〜＃〜] sctp [〜＃〜]。
概要：SCTPは、UDPのようなメッセージ駆動型のトランスポートレベルのプロトコルですが、TCPのような信頼性があります。 IBM DeveloperWorksからの短い紹介 です。
正直なところ、SCTPについて聞いたことがありません。ネットワーキングの本でそれについて読んだり、受けた授業で聞いたことを覚えていません。 その他のstackoverflowの質問 SCTPに言及していることは、私がこの知識不足だけではないことを示唆しています。
SCTPがなぜ未知なのか？なぜそれほど使用されないのですか？
実際、SCTPは主に通信分野で使用されています。従来、テレコムスイッチはSS7（ Signaling System No. 7 ）を使用して、テレコムネットワーク内のさまざまなエンティティを相互接続していました。たとえば、通信事業者の加入者データベース（HLR）にスイッチ（MSC）がある場合、加入者も接続されています（MSC）。
テレコムエリアは、より高速で到達可能な環境に移行しています。これらの変更の1つは、SS7プロトコルをよりエレガントで高速で柔軟なIPベースのプロトコルに置き換えることです。
通信エリアは非常に保守的です。ここでは、SS7ネットワークが何十年も使用されています。これは非常に信頼性の高い閉じたネットワークです。これは、通常のユーザーにはアクセスできないことを意味します。
対照的に、IPネットワークはオープンで信頼性が低く、少なくともSS7が処理する負荷を処理しない場合、通信事業者はIPネットワークに変換しません。これがSCTPが開発された理由です。試みます：
- 数十年にわたって蓄積されたSS7ネットワークのすべての利点を模倣するため。
- 速度、セキュリティ、冗長性においてTCPよりも優れた接続指向プロトコルを作成するには
Linuxの最新リリースでは、すでにSCTPがサポートされています。
現在、いくつかのアプリケーションでSCTPを展開しており、さまざまなホームルーターでのSCTPサポートに重大な問題が発生しています。彼らは単にSCTPを正しく処理しません。これは主にパフォーマンスの問題だと思います（SCTPプロトコルの仕様では、ヘッダーだけでなく、パケット全体の再計算が必要です）。
他の多くの有望なプロトコルと同様に、D-linkとNetgearが壊れたNATボックスを修正するまで、SCTPは水中で悲しいことに死んでいます。
SCTPを最大限に活用するには、アプリケーション内でより多くの設計が必要です。 TCPよりも多くのオプションがあり、SocketsのようなAPIは後で登場しました。しかし、私はそれを理解するのに時間をかける（そしてTCPの欠点を知っている）ほとんどの人がそれを高く評価していると思います-それは私たちの〜= 30年の知識TCP =およびUDP。
何らかの考えを必要とする側面の1つは、ストリームの側面です。ストリームは（通常、これをオフにできると思います）ストリーム内で順序保証を提供します（TCP接続）と似ていますが、SCTP接続ごとに複数のストリームが存在する可能性があります。複数のストリームを介して送信される場合、1つの誤ったパケットのために受信者が飢えているヘッドオブラインブロッキングを回避できます。
もう1つの便利な追加機能は、マルチホーミングのサポートです。1つの接続が両端の複数のインターフェイスにまたがることができ、障害に対処します。これをTCPでエミュレートできますが、アプリケーション層で行います。
適切なリンクハートビートは、非一時的な接続を実装するためにTCPを使用するアプリケーションが最初に使用するものです）、無料で提供されます。
SCTPの私の個人的な要約は、実質的なアプリケーションサポートで、他の方法（TCPまたはUDP）で）できなかったことは何もしないということです。そのコードを（ひどく）自分で実装します。
参考までに、SCTPはDiameterのサポートとして義務付けられています（cf RADIUS next gen）。RFC3588を参照してください。
Diameterクライアントは、TCPまたはSCTPのいずれかをサポートする必要がありますが、エージェントと サーバーは両方をサポートする必要があります。この仕様の将来のバージョンは、 SCTPをサポートします。
SCTPはあまり知られておらず、次の理由であまり使用/展開されていません。
- 広範囲：TCP/IPスタックに広く統合されていません（2013年：最新のMac OSXおよびWindowsにはまだネイティブにありません）
- ライブラリ：使いやすい言語での高レベルのバインディングはほとんどありません（免責事項： pysctp のメンテナーであり、PythonのSCTP簡単スタックサポート）
- NAT：交差しないNAT非常によく/まったく（1％未満のインターネットホームおよびエンタープライズルーターがNAT SCTPで））。
- 人気：一般公開アプリは使用していません
- プログラミングのパラダイム：少し変更されました：まだソケットですが、多くのホストを多くのホストに接続できます（マルチホーミング）。データグラムは順序付けられており、信頼性があります。
- 複雑さ：SCTPスタックは実装が複雑です（上記により）
- 競争：マルチパスTCPが近づいており、マルチホーミングのニーズ/機能に対処する必要があるため、可能な限りSCTPの実装を控え、MTCPを待つ
- ニッチ：必要なSCTPの塗りつぶしは非常に特殊（順序付けられた信頼できるデータグラム、マルチストリーム）であり、多くのアプリケーションには必要ありません
- セキュリティ：SCTPはセキュリティ制御を回避します（一部のファイアウォール、ほとんどのIDS、すべてのDLPは、CentOS/Redhat/Fedoraを除くnetstatには表示されません...）
- 監査能力：世界の3社のような企業がSCTPセキュリティの監査を定期的に行っています（免責事項：私はそのうちの1社で働いています）
- 学習曲線：SCTPでプレイするツールチェーンはあまりありません（netcatとうまく組み合わせるかsocatを使用する優れた withsctp を確認してください）
- ボンネットの下：主に通信で使用され、SMSを送信したり、モバイルでネットサーフィンを開始したり、電話をかけたりするたびに、SCTP（SIGTRAN/SS7 with GSM/UMTS、Diameter with LTE/IMS）を介して流れるメッセージをトリガーすることがよくあります/ RCS、LTEを使用したS1AP/X2AP）。したがって、実際に多く使用しますが、それについては決して知りません;-)
p1。 IPv4を介して直接マップされたSCTPは、NATゲートウェイでのサポートが必要です。これは、どこにも広く展開されたことはありません。それなしでは、通常のNAT一度にSCTPを使用するパブリックアドレスごと。
p2。 UDP/IPv4でマップされたSCTPは、パブリックアドレスごとにより多くのプライベートホストを許可しますが、IPv4/NATゲートウェイでのUDPマッピングは、NAT追跡する。
p3。 IPv6を介して直接マップされたSCTPには、... IPv6が必要です。 IPv6を展開しようとしましたか？ある場合、IPv6ファイアウォールを購入しようとしましたか？ SCTPをサポートしていますか？ロードバランサーはどうですか？ SSLアクセラレーター？
p4。最後に、多くのインターネットは、TCPポート80およびポート443を介して適合することができるものにほぼ制約されているため、あらゆるフレーバーのSCTPが失われる傾向があります。 [〜＃〜] mptcp [〜＃〜] IETFのワーキンググループ。
私たちの多くはすぐにSCTPを使用します。これは、UDPの上にTCPのような信頼できる層を作成するためにWebRTCデータチャネルによって使用されるためです。SCTPover DTLS over UDP： https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13＃section-6
SCTP Wikipediaページを読む 主な理由は、SCTPが非常に若いプロトコル（2000年に提案）であり、現在サポートされていないことですメインストリームOS（窓、 OS X、 Linux）。
「非常に若い」が不適切と思われる場合は、 IPV6 について考えてください。一般的な世界的な展開という点で、まだ初期段階にあります。」
あまり知られていないかもしれませんが、未使用ではありません。ごく最近、 [〜＃〜] ietf [〜＃〜] で公開された draft がありましたHTTPのトランスポート層プロトコルとしてSCTPを使用 =。
SCTPは、DiameterがAAAに使用される4G LTEネットワークで広く使用されています。
壊れているか、SCTPサポートが不足している商用ルーターに関するすべてのコメントを参照すると、問題はNATのSCTPがIETFのドラフト形式のままであることです。したがって、RFC仕様はありません。それを実装します。
Sctpの誕生は遅すぎて、多くの状況ではTCPで十分です。
また、私が知っているように、その使用の大部分は通信エリアで行われます。