ApacheのMLにSCTP版Apacheの話題が流れました。まあ、誰も反応していませんが。

• http://www.cis.udel.edu/~nataraja/research.html

SCTPというのは、TCPと同じレベルのyet anotherなトランスポートプロトコルです。次のページが分かりやすいと思います。

• http://www.ibm.com/developerworks/jp/linux/library/l-sctp/

残念ながら、HTTPをSCTPの上に載せるメリットは感じません。SCTPが向きそうなのは、現状、UDPの上で適度なフロー制御や再送処理をしているプロトコルだと思います。メジャーなところだと、RTP/RTSPあたりでしょうか。

SCTPをTCPと比較すると、開始が4-way handshakeになって(TCPは3-way)、終了が4-wayになっているのが興味深いです。開始が4-wayになっているのは通信プロトコルの本質的な理由ではなく、DoS対策というのが時代を感じます。half closeが無いのは良い気がします。half 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を使うソケットプログラミングのガンです。長さ情報を先に送り後からデータを送るのが最も無難な解決策ですが、ストリーム的なデータをだらだらと送る場合、実は困ります。送っている方も送り始めた時点で全体の長さが分かっていなかったり、あるいは全体長を知るためにデータをなめる必要があり、それならデータをなめながら送ってしまう方が効率的だったりする場合があるからです。こういう場合に終端文字を決める方式もひとつの解ですが、将来に禍根を残す可能性も高いですし(エスケープが必要になってカオスになったり)、そもそも送りたいデータがバイナリデータであれば現実的ではありません。面倒ですが、無難な方式は、HTTP1.1のChunked Transfer Codingのような方式です(細切れで送り、かつ最後のチャンクを明示する)。

この辺の面倒をトランスポート層で見てくれるのは嬉しいような気もする半面、TCPの場合でも苦労するのはライブラリやフレームワークを作る極一部のプログラマだけで、ほとんどの人は苦労を隠蔽した上位APIを使うので、どうでもいいような気もします。