Stream Control Transmission Protocolの略で、TCP/UDPと同じTransport層のプロトコルである。
RFC4960。2000年に定義された、ってことはもう15年も前なのね。
これまで、あまり出会いがなかったけどどうしてだろう。
ようするに
TCPのような信頼性と、UDPのような少ないオーバヘッドのいいとこ取りを目指したものである、と。
特徴
マルチホーミング
複数のI/Fを束ねる機能のことらしい。bondingや、昔のISDNのMPみたいなものだね、きっと。
* IBMのサイトから拝借（クリックで飛べます）。上がTCPの場合、下がSCTPの場合。
各I/Fをモニタリングして、フェイルオーバーもする仕様らしいので、この辺のプロトコル実装はちょっと大変そうかも。
WiFiとBLEのマルチなんかも考えると便利そうかも。あれ、iOSのI/Fを意識させないフレームワークも実はSCTPを使っているとか！？（もしくはQUICとか）
マルチストリーミング
一つのストリームの中で複数のストリームを同時に流すことができる。これもいいね。これを聞いて、自分はVLANのTag付けや、MPLS(Multi-Protocol Label Switching)みたいな感じかなぁ、という印象。一つが詰まっても他を止めない、てのはよいね。
特にHTTP的な使い方を想定すると、1本のストリーム内で複数の部品転送ができると、通信効率もさることながら体感速度として格段に良くなりそう。
* IBMのサイトから拝借（クリックで飛べます）。
接続、切断処理
接続処理は、TCPの3wayから4wayに増えたんだって。
理由は、SYNフラッドを避けるため。へぇへぇ。
* IBMのサイトから拝借（クリックで飛べます）。
逆に、終了処理はTCPの4wayから3wayに変更なんだって。こちらはハーフクローズを避けるためらしい。
* IBMのサイトから拝借（クリックで飛べます）。
いずれも、TCPではハーフオープン、ハーフクローズ時点での主導権がクライアント側にあったのを危ないのでやめたってことのよう。
サーバからのSHUTDOWNに応えなかったら、ハーフクローズ状態のままになってしまいそう、と思ったり思わなかったり。。
メッセージ・フレーミング
UDPのように、メッセージ単位でフレーム化ができる。
つまり、送った単位で受け取れる。これはいいね。TCPはバイト指向なので素のまま使おうとするとちょっと不便よね。
* IBMのサイトから拝借（クリックで飛べます）。
構成可能な順不同配送
TCPは順番通りに到着することが保証されるので、とっても便利。UDPだと、必要に応じて自前で管理する必要があるので、かなり面倒よね。
SCTPは各ストリームごとに指定できるっぽい。なるほど、これもいいね。
所感
WebRTCや、QUIC絡みでSCTPにたどり着きました。
SCTPは、使ってみたことも実装したこともないけど、話だけみると、今までよく感じていた「TCPだとやりすぎ、UDPだと足りなすぎ」な部分を程よくいいとこ取りしていて、TCPを置き換える勢いがあってもよさそうなのに、と思います。
ここ15年間、そうはならなかった理由はわかりませんが、普及しすぎてしまったTCPも一因なのかもしれませんね。もしくは、知らないところで実は既にかなりの部分置き換えられているとか。そう、SPDYのように。
ここにきて、GoogleによるSPDYが一気にHTTP/2として、HTTPの代替わりを促そうとしているように、SCTPも日の目をみるかもしれません。
いや、その前にQUICが標準となってしまうかもですかね。
おわり。