Коммуникация данных #

Что я получаю от коммуникации данных WebRTC? #

WebRTC предоставляет каналы данных для обмена данными. Между двумя пирами вы можете открыть 65 534 канала данных. Канал данных основан на датаграммах, и у каждого есть свои настройки надежности. По умолчанию каждый канал данных имеет гарантированную упорядоченную доставку.

Если вы подходите к WebRTC с точки зрения медиа, каналы данных могут показаться бесполезными. Зачем вам вся эта подсистема, когда вы могли бы просто использовать HTTP или WebSocket?

Реальная сила каналов данных заключается в том, что вы можете настроить их так, чтобы они работали как UDP с неупорядоченной/потерянной доставкой. Это необходимо для ситуаций с низкой задержкой и высокой производительностью. Вы можете измерять обратное давление и убеждаться, что отправляете только то, что поддерживает ваша сеть.

Как это работает? #

WebRTC использует протокол управления потоком передачи (Stream Control Transmission Protocol, SCTP), определенный в RFC 4960. SCTP - это транспортный протокол, который был задуман как альтернатива TCP или UDP. Для WebRTC мы используем его как протокол прикладного уровня, работающий поверх нашего DTLS-соединения.

SCTP дает вам потоки, и каждый поток может быть настроен независимо. Каналы данных WebRTC - это просто тонкие абстракции поверх них. Настройки надежности и упорядочивания просто передаются прямо в SCTP-агент.

Каналы данных имеют некоторые функции, которые SCTP не может выразить, например, метки каналов. Для решения этого WebRTC использует протокол установления канала данных (Data Channel Establishment Protocol, DCEP), который определен в RFC 8832. DCEP определяет сообщение для обмена меткой канала и протоколом.

DCEP #

DCEP только имеет два сообщения DATA_CHANNEL_OPEN и DATA_CHANNEL_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.

Тип канала #

Тип канала контролирует атрибуты надежности/упорядочивания канала. Он может иметь следующие значения:

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 - Определяет, сколько времени (в мс) отправитель будет передавать сообщение перед отказом.

Метка #

UTF-8-кодированная строка, содержащая имя канала данных. Эта строка может быть пустой.

Протокол #

Если это пустая строка, протокол не указан. Если это непустая строка, она должна указывать на зарегистрированный протокол в “WebSocket Subprotocol Name Registry”, определенном в RFC 6455.

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 |
+-+-+-+-+-+-+-+-+

Stream Control Transmission Protocol #

SCTP является реальной силой каналов данных WebRTC. Он предоставляет все эти функции канала данных:

Мультиплексирование
Надежная доставка с использованием механизма передачи TCP-подобной передачи
Опции частичной надежности
Предотвращение перегрузки
Управление потоком

Чтобы понять SCTP, мы рассмотрим его в трех частях. Цель состоит в том, чтобы вы узнали достаточно, чтобы отладить и изучить глубокие детали SCTP самостоятельно после этой главы.

Концепции #

SCTP является протоколом с богатыми функциями. Этот раздел будет охватывать только части SCTP, используемые WebRTC. Функции в SCTP, которые не используются WebRTC, включают мультихостинг и выбор пути.

С более чем двадцатилетним развитием SCTP может быть сложно полностью понять.

Ассоциация #

Ассоциация - это термин для SCTP-сессии. Это состояние, которое разделяется между двумя SCTP-агентами, когда они общаются.

Потоки #

Поток - это однонаправленная последовательность данных пользователя. Когда вы создаете канал данных, вы фактически создаете SCTP-поток. Каждая SCTP-ассоциация содержит список потоков. Каждый поток может быть настроен с разными типами надежности.

WebRTC позволяет вам настраивать только один поток при создании, но SCTP фактически позволяет изменять конфигурацию в любое время.

Датаграмма #

SCTP передает данные как датаграммы, а не как байтовый поток. Отправка и получение данных напоминает использование UDP вместо TCP. Вам не нужно добавлять дополнительный код для передачи нескольких файлов по одному потоку.

SCTP-сообщения не имеют ограничений по размеру, как UDP. Одно SCTP-сообщение может быть размером в несколько гигабайт.

Части #

Протокол SCTP состоит из частей. Существует множество различных типов частей. Эти части используются для всех коммуникаций. Данные пользователя, инициализация соединения, управление перегрузкой, и многое другое делается через части.

Каждый SCTP-пакет содержит список частей. Таким образом, в одном UDP-пакете можно иметь несколько частей, несущих сообщения из разных потоков.

Номер последовательности передачи #

Номер последовательности передачи (TSN) является глобальным уникальным идентификатором для частей DATA. Части DATA несут все сообщения, которые пользователь хочет отправить. TSN важен, потому что он помогает получателю определить, являются ли пакеты потерянными или неправильными.

Если получатель замечает отсутствующий TSN, он не передает данные пользователю до тех пор, пока он не будет выполнен.

Идентификатор потока #

Каждый поток имеет уникальный идентификатор. Когда вы создаете канал данных с явным ID, он фактически передается прямо в SCTP как идентификатор потока. Если вы не передаете ID, идентификатор потока выбирается для вас.

Идентификатор протокола полезной нагрузки #

Каждая часть DATA также имеет Идентификатор протокола полезной нагрузки (PPID). Это используется для уникальной идентификации типа данных, который обменивается. SCTP имеет много PPIDs, но WebRTC использует только следующие пять:

WebRTC DCEP (50) - Сообщения DCEP.
WebRTC String (51) - Сообщения канала данных String.
WebRTC Binary (53) - Сообщения канала данных Binary.
WebRTC String Empty (56) - Сообщения канала данных String с длиной 0.
WebRTC Binary Empty (57) - Сообщения канала данных Binary с длиной 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 - это биты начала и конца. Если вы хотите отправить сообщение, которое слишком велико для одной части DATA, оно должно быть фрагментировано на несколько частей DATA, отправленных в отдельных пакетах. С битами B и E и номерами последовательностей SCTP может выразить это.

B=1, E=0 - Первая часть фрагментированного сообщения пользователя.
B=0, E=0 - Средняя часть фрагментированного сообщения пользователя.
B=0, E=1 - Последняя часть фрагментированного сообщения пользователя.
B=1, E=1 - Нефрагментированное сообщение.

TSN - это номер последовательности передачи. Это глобальный уникальный идентификатор для этой части DATA. После 4,294,967,295 частей это обернется к 0. TSN увеличивается для каждой части фрагментированного сообщения пользователя, чтобы получатель знал, как упорядочить полученные части для восстановления исходного сообщения.

Идентификатор потока - это уникальный идентификатор потока, к которому принадлежит эта данные.

Номер последовательности потока - это 16-битное число, увеличивающееся с каждым сообщением пользователя и включаемое в заголовок части DATA-сообщения. После 65535 сообщений это обернется к 0. Это число используется для определения порядка доставки сообщений получателю, если U установлен в 0. Подобно TSN, за исключением того, что Номер последовательности потока увеличивается только для целого сообщения, а не для каждой отдельной части DATA.

Идентификатор протокола полезной нагрузки - это тип данных, который течет через этот поток. Для WebRTC это будет DCEP, String или Binary.

Данные пользователя - это то, что вы отправляете. Все данные, которые вы отправляете по каналу данных WebRTC передаются через часть DATA.

INIT Chunk #

 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 начинает процесс создания ассоциации.

Initiate Tag используется для генерации файла cookie. Файлы cookie используются для Man-In-The-Middle и защиты от DoS-атак. Они описываются более подробно в разделе состояние машины.

Advertised Receiver Window Credit используется для управления перегрузкой SCTP. Это сообщает, насколько большой буфер имеется у получателя для этой ассоциации.

Число исходящих/входящих потоков уведомляет удаленный о том, сколько потоков поддерживает этот агент.

Initial TSN - это случайный uint32 для запуска локального TSN.

Опциональные параметры позволяют SCTP вводить новые функции в протокол.

SACK Chunk #

 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) уведомляет отправитель о том, что он получил пакет. Пока отправитель не получит SACK для TSN он будет передавать часть DATA в вопрос. SACK делает больше, чем просто обновление TSN.

Cumulative TSN ACK - это самый высокий TSN, который был получен.

Advertised Receiver Window Credit - размер буфера получателя. Получатель может изменить это во время сессии, если становится доступно больше памяти.

Ack Blocks TSNs, которые были получены после Cumulative TSN ACK. Это используется, если есть разрыв в доставленных пакетах. Скажем, части DATA с TSNs 100, 102, 103 и 104 доставлены. Cumulative TSN ACK был бы 100, но Ack Blocks мог бы сказать отправителю, что ему не нужно передавать 102, 103 или 104.

Duplicate TSN информирует отправителя о том, что он получил следующие части DATA более одного раза.

HEARTBEAT Chunk #

 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 Chunk #

 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 Chunk #

 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, который был отправлен. Каждая сторона знает не отключаться, пока они не получат часть DATA с этим TSN.

ERROR Chunk #

 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 Chunk #

 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 для достижения этого. Он говорит получателю, что 14 и 15 не будут доставлены.

New Cumulative TSN - это новый TSN соединения. Все пакеты до этого TSN не будут сохранены.

Stream и Stream Sequence используются для перехода Номер последовательности потока вперед. См. часть DATA для значения этого поля.

State Machine #

Это некоторые интересные части состояния машины SCTP. WebRTC не использует все функции состояния машины SCTP, поэтому мы исключили эти части. Мы также упростили некоторые компоненты, чтобы сделать их понятными самостоятельно.

Flow установления соединения #

Части INIT и INIT ACK используются для обмена возможностями и конфигурациями каждого пира. SCTP использует файл cookie во время рукопожатия для проверки пира, с которым он общается. Это гарантирует, что рукопожатие не перехватывается и предотвращает DoS-атаки.

Часть INIT ACK содержит файл cookie. Файл cookie затем возвращается его создателю с помощью COOKIE ECHO. Если проверка файла cookie успешна, COOKIE ACK отправляется, и части DATA готовы к обмену.

Connection establishment

Flow разрыва соединения #

SCTP использует часть SHUTDOWN. Когда агент получает часть SHUTDOWN, он будет ждать, пока он не получит запрошенный Cumulative TSN ACK. Это позволяет пользователю убедиться, что все данные доставлены, даже если соединение потеряно.

Keep-Alive Mechanism #

SCTP использует части HEARTBEAT REQUEST и HEARTBEAT ACK для поддержания соединения. Эти отправляются на настраиваемом интервале. SCTP также выполняет экспоненциальную задержку, если пакет не пришел.

Часть HEARTBEAT также содержит временное значение. Это позволяет двум ассоциациям вычислить время поездки между двумя агентами.