データ・コミュニケーション #

WebRTCのデータ通信で何が得られるのか？ #

WebRTCは、データ通信のためのデータチャンネルを提供します。2つのピアの間では、65,534個のデータチャンネルを開くことができます。データチャンネルはデータグラムをベースにしており、それぞれに耐久性の設定があります。デフォルトでは、各データチャネルには順序通りの配信が保証されています。

メディアの観点からWebRTCにアプローチしている場合、データチャネルは無駄に思えるかもしれません。HTTP や WebSocket を使用することができるのに、なぜこのようなサブシステム全体が必要なのでしょうか？

データチャネルの本当の強みは、UDP のように順序のない、または損失のある配信を行うように設定できることです。これは、低レイテンシーでハイパフォーマンスの場合に必要です。バックプレッシャーを測定し、ネットワークがサポートする量だけを送信できます。

WebRTCはどのように動作するのですか？ #

WebRTCは、RFC 4960で定義されているSCTP(Stream Control Transmission Protocol)を使用しています。SCTPはトランスポート層のプロトコルで、TCPやUDPの代替となることを目的としています。WebRTCでは、DTLS接続上で動作するアプリケーション層のプロトコルとして使用しています。

SCTPはストリームを提供し、各ストリームは独立して設定できます。WebRTCのデータチャネルは、それらを薄く抽象化したものに過ぎません。耐久性や順序に関する設定は、そのままSCTPエージェントに渡されます。

データチャネルには、チャネルラベルなど、SCTPでは表現できない機能があります。この問題を解決するために、WebRTCはRFC 8832で定義されているDCEP（Data Channel Establishment Protocol）を使用します。DCEPでは、通信を行うためのメッセージを定義しています。

DCEP #

DCEPには、DATA_CHANNEL_OPENとDATA_CHANNEL_ACKの2つのメッセージしかありません。データチャネルが開かれるたびに、リモートはackで応答する必要があります。

DATA_CHANNEL_OPEN #

このメッセージは、チャネルを開くことを望む WebRTC エージェントによって送信されます。

パケットフォーマット #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message Type |  Channel Type |            Priority           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Reliability Parameter                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Label Length          |       Protocol Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                             Label                             /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                            Protocol                           /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

メッセージタイプ #

メッセージタイプは、0x03の静的な値です。

チャンネルタイプ #

Channel Type は、チャネルの耐久性や順序の属性を制御します。以下のような値があります。

DATA_CHANNEL_RELIABLE (0x00) - メッセージが失われることはなく、順番に到着します。
DATA_CHANNEL_RELIABLE_UNORDERED (0x80) - メッセージは失われませんが、順不同に到着することがあります。
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01) - メッセージは要求された回数を試した後に失われる可能性がありますが、順番に到着します。
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81) - メッセージは要求された回数だけ試行した後に失われる可能性があり、順不同に到着することがあります。
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02) - メッセージは要求された時間内に到着しないと失われる可能性がありますが、順番に到着します。
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82) - メッセージは、要求された時間内に到着しなかった場合に失われる可能性があり、順不同に到着することがあります。

優先順位 #

データチャネルの優先順位を指定します。優先度の高いデータチャネルが先にスケジュールされます。優先度の低い大きなユーザーメッセージがあっても、優先度の高いユーザーメッセージの送信を遅らせることはありません。

信頼性パラメータ #

データチャネルのタイプが DATA_CHANNEL_PARTIAL_RELIABLE の場合、サフィックスで動作を設定します。

REXMIT - 送信者がメッセージをあきらめるまでに何回再送信するかを定義します。
TIMED - 送信者があきらめるまでに何回メッセージを再送信するかを時間（ms）で定義します。

ラベル #

データチャネルの名前を、UTF-8でエンコードした文字列で指定します。これは空の文字列でもよい。

プロトコル #

これが空の文字列の場合、プロトコルは指定されていません。空でない文字列の場合は、 RFC 6455で定義されている “WebSocket Subprotocol Name Registry “に登録されているプロトコルを指定します。

DATA_CHANNEL_ACK #

このメッセージは、WebRTCエージェントが、このデータチャネルがオープンされたことを確認するために送信します。

パケットフォーマット #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Message Type |
+-+-+-+-+-+-+-+-+

SCTP #

SCTPは、WebRTCのデータチャネルを支える真の力です。SCTPは、データチャネルの以下の機能をすべて提供します。

多重化
TCPライクな再送メカニズムによる信頼性の高い配信
パーシャル・リライアビリティ・オプション
輻輳回避
フロー制御

SCTPを理解するために、3つのパートに分けて説明します。目標は、この章の後、自分でデバッグしてSCTPの深い詳細を学ぶのに十分な知識を得ることです。

概念 #

SCTP は機能豊富なプロトコルです。このセクションでは、WebRTC で使用されている SCTP の部分のみを取り上げます。 WebRTC で使用されていない SCTP の機能には、マルチホーミングや経路選択があります。

20年以上も開発されてきたSCTPを完全に理解するのは難しいかもしれません。

アソシエーション #

SCTP セッションのことをアソシエーションと言います。2つのSCTPエージェントが通信している間、2つのSCTPエージェント間で共有される状態です。

ストリーム #

ストリームとは、ユーザーデータの1つの双方向シーケンスです。データチャネルを作成することは、実際には SCTP ストリームを作成することに他なりません。 SCTPストリームを作成しているに過ぎません。各SCTPアソシエーションには、ストリームのリストが含まれます。各ストリームには、異なる信頼性タイプを設定できます。

WebRTCではストリーム作成時にしか設定できませんが、SCTPではいつでも設定を変更できます。

データグラムベース #

SCTPはデータをバイトストリームではなく、データグラムとしてフレーム化します。データの送受信は、TCPではなくUDPを使っているような感覚です。複数のファイルを1つのストリームで転送するために、余分なコードを追加する必要はありません。

SCTPメッセージにはUDPのようなサイズ制限がありません。1つのSCTPメッセージのサイズは、複数のギガバイトになることもあります。

チャンク #

SCTP プロトコルはチャンクで構成されています。チャンクには様々な種類があります。これらのチャンクはすべての通信に使用されます。ユーザーデータ、接続の初期化、輻輳制御など、すべてチャンクを介して行われます。

SCTPの各パケットには、チャンクのリストが含まれています。そのため、1つのUDPパケットには、異なるストリームのメッセージを運ぶ複数のチャンクが含まれます。

トランスミッションシーケンス番号 #

TSN（Transmission Sequence Number）は、DATAチャンクのグローバルな一意の識別子です。ユーザーが送信したいすべてのメッセージを伝えるものです。TSNは、受信者がパケットの紛失や順序の乱れを判断する上で重要な役割を果たします。

TSNの欠落に気付いた受信者は、それが満たされるまでユーザーにデータを提供しません。

ストリームの識別子 #

各ストリームには固有の識別子があります。明示的なIDを持つデータチャネルを作成すると、実際にはそのIDがそのままSCTP にストリーム識別子として渡されます。ID を指定しない場合は、ストリーム識別子が選択されます。

ペイロードプロトコル識別子 #

各 DATA チャンクには、PPID（Payload Protocol Identifier）があります。これは、交換されるデータの種類を一意に識別するために使用されます。 SCTPには多くのPPIDがありますが、WebRTCでは以下の5つのPPIDのみを使用しています。

WebRTC DCEP (50) - DCEP メッセージ
WebRTC String (51) - データチャンネルの文字列メッセージ
WebRTC Binary (53) - Datachannel のバイナリメッセージ
WebRTC String Empty (56) - Datachannel の長さが 0 の文字列メッセージ
WebRTC Binary Empty (57) - Datachannel の長さが 0 のバイナリメッセージ

プロトコル #

以下は、SCTPプロトコルで使用されるチャンクの一部である。これは完全なデモンストレーションではありません。ステートマシンが意味をなすのに十分な構造を提供しています。

各チャンクは、typeフィールドで始まります。チャンクのリストの前には、ヘッダーもあります。

DATA チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0    | Reserved|U|B|E|    Length                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              TSN                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Stream Identifier        |   Stream Sequence Number      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Payload Protocol Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                            User Data                          /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DATAチャンクは、すべてのユーザーデータが交換される方法です。データチャンネルで何かを送信するときは、このようにして交換されます。

順不同のパケットであれば、Uビットが設定されます。ストリームシーケンス番号は無視できます。

B と E は開始ビットと終了ビットです。1つのDATAチャンクでは大きすぎるメッセージを送信する場合は、複数のDATAチャンクに分割して別々のパケットで送信する必要があります。 B と E のビットとシーケンスナンバーで、SCTPはこれを表現することができます。

B=1, E=0 - フラグメント化されたユーザメッセージの最初の部分
B=0, E=0 - フラグメント化されたユーザメッセージの中間部分
B=0, E=1 - フラグメント化されたユーザメッセージの最後の断片
B=1, E=1 - フラグメント化されていないメッセージ

TSN は、Transmission Sequence Numberの略です。4,294,967,295個のチャンクの後、これは0に折り返されます。TSNは、断片化されたユーザーメッセージのチャンクごとにインクリメントされるので、他のユーザーは、完全なメッセージを得るために受信したチャンクをどのように順序付けるかを知ることができます。

ストリーム識別子 は、このデータが属するストリームの一意の識別子です。

ストリームシーケンス番号 は、ユーザメッセージごとにインクリメントされる16ビットの番号で、DATAメッセージのチャンクヘッダに含まれます。この番号は、 U が0に設定されている場合に、ユーザーに配信されるメッセージの順序を決定するために使用されます。ストリーム・シーケンス・ナンバーが各チャンクではなく、各メッセージ全体に対してのみインクリメントされるという点を除いては、TSNと同様です。

ペイロードプロトコル識別子は、このストリームに流れているデータの種類です。WebRTCでは、DCEP、String、Binaryのいずれかになります。

ユーザーデータとは、あなたが送信するデータのことです。WebRTCのデータチャンネルで送信するデータは、すべてDATAチャンクを介して送信されます。

INIT チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 1    |  Chunk Flags  |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Initiate Tag                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Advertised Receiver Window Credit (a_rwnd)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Number of Outbound Streams   |  Number of Inbound Streams    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Initial TSN                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/              Optional/Variable-Length Parameters              /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

INITチャンクは、アソシエーションを作成するプロセスを開始します。

初期化タグはクッキーの生成に使われます。クッキーはMan-In-The-MiddleやDenial of Serviceの保護に使われます。これらについてはステートマシンのセクションで詳しく説明します。

アドバタイズドレシーバーウィンドウクレジットはSCTPの輻輳制御に使用されます。これは、受信者がこのアソシエーションに割り当てたバッファの大きさを伝えるものです。

アウトバウンド/インバウンドストリームの数は、このエージェントがサポートしているストリームの数をリモートに通知します。

初期TSN は、ローカルのTSNを開始するためのランダムな uint32 です。

オプションパラメータは、SCTPがプロトコルに新しい機能を導入することを可能にします。

SACK チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 3    |Chunk  Flags   |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Cumulative TSN Ack                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Advertised Receiver Window Credit (a_rwnd)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Gap Ack Blocks = N  |  Number of Duplicate TSNs = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Gap Ack Block #1 Start       |   Gap Ack Block #1 End        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
\                              ...                              \
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Gap Ack Block #N Start      |  Gap Ack Block #N End         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Duplicate TSN 1                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
\                              ...                              \
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Duplicate TSN X                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SACK（Selective Acknowledgment）チャンクは、受信者が送信者にパケットを受け取ったことを通知する方法です。送信者は、あるTSNに対するSACKを受け取るまで、問題のDATAチャンクを再送信します。SACKはTSNを更新するだけではありません。

累積 TSN ACK 受信した最も高いTSNを示します。

アドバタイズドレシーバーウィンドウクレジット レシーバーのバッファサイズです。受信者は、より多くのメモリが利用可能になった場合、セッション中にこれを変更できます。

累積 TSN ACKの後に受信されたAckブロックTSN。これは、配信されたパケットにギャップがある場合に使用されます。例えば、TSNが100、102、103、104のDATAチャンクが配信されたとします。累積 TSN ACKは100となりますが、102、103、104を再送する必要がないことを送信者に伝えるために、Ack Blocksを使用できます。

Duplicate TSNは、送信者に以下のDATAチャンクを2回以上受信したことを通知します。

HEARTBEAT チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 4    | Chunk  Flags  |      Heartbeat Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/            Heartbeat Information TLV (Variable-Length)        /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

HEARTBEAT チャンクは、リモートがまだ応答していることを確認するために使用されます。 DATAチャンクを送信しておらず、NATマッピングを開いておく必要がある場合に便利です。

ABORT チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 6    |Reserved     |T|           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
\               Zero or more Error Causes                       \
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ABORT チャンクは、アソシエーションを突然シャットダウンします。片側がエラー状態になったときに使用します。優雅に接続を終了させるには、SHUTDOWNチャンクを使用します。

SHUTDOWN チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 7    | Chunk  Flags  |      Length = 8               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Cumulative TSN Ack                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SHUTDOWNチャンクは、SCTPアソシエーションのグレースフルシャットダウンを開始します。各エージェントは、最後に送信したTSNをリモートに通知します。これにより、パケットが失われることはありません。WebRTC は SCTP アソシエーションのグレースフルシャットダウンを行いません。潔く処理するためには、各データチャネルを自分で取り壊す必要があります。

Cumulative TSN ACKは、最後に送信されたTSNです。各サイドは、このTSNでDATAチャンクを受信するまで終了しないことを知っています。

ERROR チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 9    | Chunk  Flags  |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                    One or more Error Causes                   /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ERROR チャンクは、致命的ではないエラーが発生したことをリモートSCTPエージェントに通知するために使用されます。

FORWARD TSN チャンク #

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 192  |  Flags = 0x00 |        Length = Variable      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      New Cumulative TSN                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Stream-1              |       Stream Sequence-1       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               /
/                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Stream-N              |       Stream Sequence-N       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FORWARD TSN チャンクは、グローバルTSNを前方に移動させます。SCTPがこれを行うことで、もう気にしないパケットをスキップできます。例えば、10 11 12 13 14 15と送ったとすると、これらのパケットはすべて到着した場合にのみ有効となります。また、このデータはリアルタイム性を重視しているので、到着が遅れると意味がありません。

もし、12と13を失ったら、14と15を送る理由はありません! SCTPはFORWARD TSN Chunkを使ってこれを実現します。SCTPはFORWARD TSN Chunkを使ってこれを実現します。これは受信者に14と15がもう配信されないことを伝えます。

New Cumulative TSN これは接続の新しいTSNです。このTSNより前のパケットは保持されません。

StreamおよびStream Sequenceは、Stream Sequence Numberの番号を先に進めるために使用されます。このフィールドの意味については、DATAチャンクを参照してください。

ステートマシン #

これらはSCTPステートマシンの興味深い部分です。WebRTC は SCTP ステートマシンのすべての機能を使用していないので、これらの部分は除外しています。また、いくつかのコンポーネントは単独で理解できるように簡略化しました。

接続確立の流れ #

INITとINIT ACKのチャンクは、各ピアの能力と構成を交換するために使用されます。SCTPはハンドシェイクの際にクッキーを使用して、通信相手を検証します。これは、ハンドシェイクが傍受されないようにするためと、DoS攻撃を防ぐためです。

INIT ACKチャンクには、クッキーが含まれています。その後、クッキーは COOKIE ECHO を使って作成者に返されます。クッキーの検証に成功すると、COOKIE ACKが送信され、DATAチャンクの交換が可能になります。

Connection establishment

コネクション・ティアダウンの流れ #

SCTPでは、SHUTDOWN Chunkを使用します。エージェントはSHUTDOWN Chunkを受信すると、要求されたCumulative TSN ACKを受信するまで待ちます。これにより、接続にロスがあっても、すべてのデータを確実に配信できます。

キープアライブの仕組み #

SCTPでは、接続を維持するために、HEARTBEAT REQUESTとHEARTBEAT ACKというチャンクを使用します。これらは設定可能な間隔で送信されます。また、SCTPはパケットが到着していない場合、指数関数的なバックオフを行います。

HEARTBEATには時間の値も含まれています。これにより、2つのアソシエーションが2つのエージェント間のトリップタイムを計算できます。