ActionsSCTP版ApacheApacheのMLにSCTP版Apacheの話題が流れました。誰も反応していませんが。anotherなトランスポートプロトコルです。次のページが分かりやすいと思います。http://www.ibm.com/developerworks/jp/linux/library/l-sctp/残念ながら、HTTPをSCTPの上に載せるメリットは感じません。SCTPが向きそうなのは、現状、UDPの上で適度なフロー制御や再送処理をしているプロトコルだと思います。メジャーなところだと、RTP/RTSPあたりでしょうか。handshakeになって(TCPは3-way)、終了が4-wayになっているのが興味深いです。開始が4-wayになっているのは通信プロトコルの本質的な理由ではなく、DoS対策というのが時代を感じます。closeが無いのは良い気がします。closeは鬼門です。Windowsのshutdown(2)とか未だに動作が信用できません(ちゃんと調べていませんが)。TCPのようなバイトストリームではなく、メッセージ境界を維持することは、そんなもんか、という感想です。TCPのバイトストリーム方式は、TCPのソケットプログラミングを始めた人が最初にはまる問題のひとつです。送り手が1000バイトのデータをsend(2)しても、受け手が1000バイトの単位で受け取る保証はありません。100バイトずつのrecv(2)を10回かもしれませんし、999バイトと1バイトのrecv(2)になるかもしれません。メッセージ境界を保証するのは、TCPより上位のプロトコルの責任です。TCPの上位プロトコルがメッセージ境界を保証する手法は、主に3つあります。長さ情報を送る(HTTPのContent-Lengthヘッダを想像するのが一番理解しやすいです。この方式が一番、無難です)終端文字を決めておく(SMTPが代表的)送り終わったらセッションを切る(HTTP1.0が代表的)どれも面倒で、TCPを使うソケットプログラミングのガンです。長さ情報を先に送り後からデータを送るのが最も無難な解決策ですが、ストリーム的なデータをだらだらと送る場合、実は困ります。送っている方も送り始めた時点で全体の長さが分かっていなかったり、あるいは全体長を知るためにデータをなめる必要があり、それならデータをなめながら送ってしまう方が効率的だったりする場合があるからです。いう場合に終端文字を決める方式もひとつの解ですが、将来に禍根を残す可能性も高いですし(エスケープが必要になってカオスになったり)、そもそも送りたいデータがバイナリデータであれば現実的ではありません。Codingのような方式です(細切れで送り、かつ最後のチャンクを明示する)。この辺の面倒をトランスポート層で見てくれるのは嬉しいような気もする半面、TCPの場合でも苦労するのはライブラリやフレームワークを作る極一部のプログラマだけで、ほとんどの人は苦労を隠蔽した上位APIを使うので、どうでもいいような気もします。22:29あー、HTTPがSCTPに乗ったところで、メリットがない訳ではないです。同一ドメインに対して複数のリクエストを出すときに一つのパケットに複数のチャンクとして乗せられるので。したSCTPスタックなら、TCPでやるよりはオーバーヘッドが少なくなる可能性があります。