2.10. SCTPの特徴
Stream Control Transmission Protocol (SCTP) はネットワーク戦線ではまだ新顔の部類に入るプロトコルだが、利用される場面は日に日に広がりつつあり TCP および UDP プロトコルの弱点を改善するものでもあるため、こうしてセクションを設けて解説することにした。 SCTP は TCP にも勝る高信頼性を備え、なお且つ、プロトコルヘッダの造りから、オーバーヘッドが低く抑えられている。
SCTP には非常に興味深い特長がいくつかある。このプロトコルについてより詳しく知りたい人は、RFC 3286 - An Introduction to the Stream Control Transmission Protocol と RFC 2960 - Stream Control Transmission Protocol を読んでいただくといい。前者は SCTP の紹介文書で、もう少しよく知りたいという人にとって非常に興味深い文書だろう。ふたつ目はプロトコルの仕様書そのもので、このプロトコルを使って何かを開発しようとする人か本気で興味を持った人でもなければ、読んでもあまり役には立たないかもしれない。
SCTP は元々 Telephony over IP や Voice over IP (VoIP) 用に開発されたプロトコルで、このことに由来した非常に興味を惹く特性がいくつかある。商用グレードの VoIP では非常に高次の信頼性が求められる。つまり、様々な障害に対する障害回復機能が幾重にも張り巡らされているのだ。以下に挙げるのが SCTP の主な特徴である。
マルチキャスト 属性によるユニキャスト 。ポイントtoポイント のプロトコルでありながら、末端ホストに対する複数のアドレスをサポートしているということだ。言い換えると、エンドホストまで到達するために複数の経路が利用できる。これに対して TCP では、搬送経路が断ち切られた時、 IP プロトコルによる補正に助けてもらわない限り断絶は避けられない。
高信頼性伝送 (Reliable transmission)。チェックサムと SACK を使用して、データの衝突 (corrupted)、損傷、破棄 (discarded)、重複 (duplicated)、入れ違い (reordered) の検出を行い、そうした場合には必要に応じて再送を行う。この点は TCP も同じだが、特に、順序の入れ違ったデータに関しては SCTP のほうが回復能力に優れ、検知も早い。
メッセージ指向 (Message oriented) メッセージ単位でフレーム化ができるため、データグラムの構造や順序を見失わずにすむ。 TCP はバイト指向であり、受け取れるのは中で順序がばらばらになったバイトの流れ (stream) でしかなく、それを補うために追加のレイヤーを必要とする。
レート対応 (Rate adaptive)。 TCP と協調/共存して帯域幅調整を行うことができるように作られている。 TCP と同様に、ネットワーク負荷に応じて帯域幅の増減ができる。また、スロースタート に相当するアルゴリズムも備える。ECN にも対応している。
マルチホーミング (Multi-homing)。先にも述べたように、複数のエンドノードと遣り取りする機能がプロトコル自体に組み込まれている。そのおかげで、 IP レイヤーに頼らなくても障害回復ができる。
マルチストリーム (Multi-streaming)。ひとつのストリームの中で複数のストリームを同時に流すことができる。これが Stream Control Transmission Protocol という名前の由来だ。例えば、ひとつの Webページをダウンロードするために 1本のストリームを開いておき、その中だけでイメージや html ドキュメントを同時進行的にダウンロードすることができる。これを複数のコントロールストリームの発生可能なデータベースプロトコルで活用すれば、複数のクエリに対する回答を並行して受け取ることができることは言うまでもない。
イニシエーション。コネクションの確立 (initiation) は 4 つのパケットから成るが、3番目と 4番目はデータの送信にも利用できる。syncookies と同等の仕組みも標準で組み込まれており、DoS 攻撃が防げる。SCTP コネクションのバッティングを防ぐことを目的に INIT collision resolution (初期化衝突解決機能) を備えている。
上のリストは、やろうと思えばいくらでも増やせるが、やめておく。関連の情報は RFC 3286 - An Introduction to the Stream Control Transmission Protocol のドキュメントで入手可能なので、必要があればそちらを読んでいただきたい。
 | SCTP の話をする時には、これまでのような パケット や ウィンドウ は使わず、チャンク (chunks) という言葉が用いられる。SCTP はメッセージ指向であるため、ひとつの SCTP フレーム が複数のチャンク を含むこともある。チャンク には、コントロールチャンク と データチャンク があり、各チャンク はそのどちらかとなる。コントロールチャンク はセッションの制御を行い、実際のデータは データチャンク によって送られる。 |
2.10.1. イニシャライズとアソシエーション
コネクションのイニシャライズ (initialize = 初期確立) は、互いに通信を交わしたいホストとホストの間で関係を締結すること (association) によって行われる。関係締結のイニシャライズはユーザからの要請があった時に行われ、それが以後必要に応じて使用される。
イニシャライズは 4つのパケットによって行われる。まず INIT チャンク を送信し、それに対して、クッキーを含んだ INIT ACK が返され、そこからデータの送信が始まる。しかし、イニシャライズの続きがまだあり、さらに 2個のパケットの遣り取りがなされる。クッキーに対して返す COOKIE ECHO チャンク と、その回答でありイニシャライズの締めとなる COOKIE ACK チャンク だ。
2.10.2. データの送信とコントロールセッション
SCTP は、ここまで準備が整えばデータの送信ができる。 SCTP においては コントロールチャンク と データチャンク があることは前に述べた。データチャンク は DATA チャンク によって送られ、 DATA チャンク は SACK チャンク の送信によって承認される (acknowledged)。実質的には TCP の SACK と同じだ。この SACK チャンク が コントロールチャンク だ。
コントロールチャンク はこの他にもある。HEARTBEAT と HEARTBEAT ACK チャンクがそのひとつ、もうひとつが ERROR チャンクだ。HEARTBEAT が使われるのはコネクションのキープアライブのため、 ERROR は、ストリーム ID の異常や、必須パラメータの欠如など、コネクション上の様々な問題やエラーを報告するために使われる。
2.10.3. シャットダウンと中止
いよいよ SCTP コネクションを閉じようという時には、ABORT チャンク あるいはより行儀正しい SHUTDOWN チャンク を送信する。SCTP には TCP のような半閉鎖 状態は存在しない。つまり、一端が送信ソケットを閉じてしまったら、他端はもう送信を継続することはできない。
ユーザあるいはアプリケーションが礼儀正しく SCTP ソケットを閉じようとする時には、プロトコルに対して SHUTDOWN を要望する。すると、SCTP はバッファ上に残存するデータを送りきった後、 SHUTDOWN チャンク を送信する。他端は、この SHUTDOWN を受け取るとアプリケーションからのデータを受け取るのをやめ、送信すべきデータをすべて完了させようとする。データに対しての SACK がすべて受信できたら、この端末は SHUTDOWN ACK チャンク を送信し、初めにクローズを言い出した側は締めの SHUTDOWN COMPLETE チャンク で返事をする。これでセッションは完全に終了だ。
セッションのクローズの仕方にはもうひとつある。それが ABORT。こちらは SCTP アソシエーション の礼儀正しくない解消法だ。一対の SCTP アソシエーション を即時に解消したい時がこれで、一方が然るべき値を持った ABORT チャンク を送る。バッファ上にあるものも含め、未送信のデータはすべて破棄されて、アソシエーションが解消される。相手方も、 ABORT チャンク の正当性を検査した後に同様の処理を行う。