Langator в 14:06, 27 июня 2011

2011-06-27T14:06:32Z

Langator: Новая страница: «'''SCTP''' ({{lang-en|Stream Control Transmission Protocol}} — «протокол передачи с управлением потоком»), [[сетевой п...»

2011-06-16T18:02:44Z

Новая страница: «'''SCTP''' ({{lang-en|Stream Control Transmission Protocol}} — «протокол передачи с управлением потоком»), [[сетевой п...»

Новая страница

'''SCTP''' ({{lang-en|Stream Control Transmission Protocol}} — «протокол передачи с управлением потоком»), [[сетевой протокол | протокол]] [[Транспортный уровень | транспортного уровня]] в [[Компьютерные сети|компьютерных сетях]], появившийся в [[2000 год]]у в [[IETF]]. [http://tools.ietf.org/html/rfc4960 RFC 4960] описывает этот протокол, а [http://tools.ietf.org/html/rfc3286 RFC 3286] содержит техническое вступление к нему.

Как и любой другой протокол передачи данных транспортного уровня, SCTP работает аналогично [[TCP]] или [[UDP]] <ref>TCP и UDP работают столь различно, что проводить аналогию к ним обоим некорректно. Вся аналогия — в том, что SCTP, TCP и UDP относятся к одному и тому же уровню модели OSI.</ref>. Но на самом деле SCTP имеет в арсенале широкий спектр приятных нововведений, таких как многопоточность, защита от [[SYN-flood]] атак, синхронное соединение между двумя хостами по двум и более независимым физическим каналам (multi-homing).

== Безопасное установление подключения ==
Создание нового подключения в протоколах TCP и SCTP происходит при помощи механизма подтверждения (квитирования) пакетов. В протоколе TCP данная процедура получила название трехэтапное квитирование (three-way handshake). Клиент посылает пакет SYN (сокр. Synchronize). Сервер отвечает пакетом SYN-ACK (Synchronize-Acknowledge). Клиент подтверждает прием пакета SYN-ACK пакетом ACK. На этом процедура установления соединения завершается.

Протокол TCP имеет потенциальную уязвимость, обусловленную тем, что нарушитель, установив фальшивый IP-адрес отправителя, может послать серверу множество пакетов SYN. При получении пакета SYN сервер выделяет часть своих ресурсов для установления нового соединения. Обработка множества пакетов SYN рано или поздно, затребует все ресурсы сервера и сделает невозможным обработку новых запросов Такая атака получила название «отказ в обслуживании» (Denial of Service (DoS)).

Протокол SCTP защищен от подобных атак с помощью механизма четырехэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.

[[Файл:Безопасность_устанавливаемого_подключения.jpg]]

Для решения проблемы задержки пересылки данных при выполнении процедуры четырехэтапного квитирования в протоколе SCTP допускается включение данных в пакеты COOKIE-ECHO и COOKIE-ACK.

== Поэтапное завершение передачи данных ==
Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.

В протоколе TCP возможна ситуация, когда узел закрывает у себя сокет (выполняя посылку пакета FIN), но продолжает принимать данные. Пакет FIN указывает корреспонденту на отсутствие данных для передачи, однако до тех пор, пока корреспондент не закроет свой сокет, он может продолжать передавать данные. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.

[[Файл:Поэтапное_завершение_передачи_данных.jpg‎]]

== Многопоточность ==
[[TCP]] управляет [[последовательность]]ю [[байт]]: данные, посланные приложением-отправителем, должны поступать приложению-получателю строго в том же порядке (в то время как протокол IP способен поменять последовательность пакетов; кроме того, пропавшие пакеты посылаются повторно и обычно прибывают к получателю с нарушением последовательности; для борьбы с этими явлениями данные накапливаются в буфере). SCTP может транспортировать [[данные]] между двумя [[точка]]ми одновременно по нескольким [[поток]]ам ''сообщений''. В противоположность к [[TCP]], SCTP обрабатывает целые ''сообщения'', а не обычные байты [[Информация|информации]]. Это означает, что если отправитель отсылает серверу ''сообщение'', состоящее из 100 байт за первый шаг, а за ним ещё 50 байт, то получатель за первый шаг получит именно первые 100 байт в первом сообщении, а только затем и только 50 байт на второй операции чтения из [[сокет]]а.

[[Файл:Многопотоковая передача данных.jpg]]

Термин «многопоточность» (англ. ''multi-streaming'') обозначает способность SCTP параллельно передавать по нескольким независимым потокам ''сообщений''. Например, мы передаем несколько [[Фотография|фотографий]] через [[HTTP]]-[[приложение]] (например [[браузер]]). Можно использовать для этого связку из нескольких [[TCP]]-соединений, однако также допустимо ''SCTP-ассоциация'' (англ. ''SCTP-association''), управляющее несколькими [[поток]]ами сообщений для этой цели.

TCP достигает правильного порядка байт в потоке, абстрактно назначая порядковый номер каждой отосланной единице, а упорядочивая принятые байты, используя назначенные порядковые номера, по мере их прибывания. С другой стороны, SCTP присваивает различные порядковые номера сообщениям, посылаемым в конкретном ''[[поток]]е''. Это разрешает независимое упорядочивание сообщений по разным потокам. Так или иначе, [[многопоточность]] является опцией в SCTP. В зависимости от желаний пользовательского приложения, сообщения могут быть обработаны не в порядке их отправления, а в порядке их поступления.

== Достоинства ==
Достоинства использования SCTP включают в себя:
* Использование множественных интерфейсов (англ ''Multihoming'') Допустим, у нас есть два [[хост]]а. И хотя бы один из них имеет несколько сетевых интерфейсов, и соответственно несколько IP-адресов. В TCP, понятие «соединение» означает обмен данными между двумя точками, в то время, как в SCTP имеет место концепция «ассоциации» (англ. ''association''), обозначащая всё происходящее между двумя хостами
[[Файл:SCTP.multi-homing.svg]]
* Многопоточность Данные приходят в точку по независимым потокам. Это позволяет устранить феномен [[:en:Head-of-line blocking]], которым так страдает [[TCP]]
* Поиск пути с мониторингом Протоколом выбирается ''первичный'' маршрут передачи данных, а также производится проверка и мониторинг связности пути.
* Механизмы валидации и проверки подлинности Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках.
* Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в [[Ethernet]].

Часть достоинств вытекает из того факта, что изначально разработчики SCTP проектировали протокол под нужды передачи телефонии ([[SS7]]) по протоколу [[IP]].

== Причины появления ==
[[TCP|Протокол TCP]] предоставляет основные средства для передачи данных по сети [[Internet]] по надежному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:
* TCP предоставляет надежную передачу данных в строгой последовательности. Тем не менее одни приложения требуют передачу без управления и контроля последовательности, а другие будут вполне удовлетворены частичной упорядоченностью данных. Оба этих случая страдают из-за ненужных задержек, связанных с восстановлением и упорядочиванием нарушенных последовательностей TCP.
* Природа TCP ориентирована на поток байт, что вызывает неудобства. Приложения вынуждены самостоятельно добавлять собственные маркеры в пакеты, чтобы распараллелить передачу собственных сообщений, а также использовать дополнительные ухищрения, чтобы убедиться в том, что целое сообщение было доставлено за определенное время.
* Ограниченные рамки возможностей [[TCP]]-[[сокет]]ов ещё более усложняют задачу предоставления возможности параллельной передачи информации к [[хост]]ам по нескольким каналам связи (см. ''multi-homing'' выше).
* TCP относительно уязвим к атакам класса «Отказ в обслуживании» ([[DoS]]), таким как [[SYN-flood]].

Все эти ограничения наносят ущерб производительности работы [[Телефонная сеть общего пользования|телефонных сетей]] через [[IP]].

== Безопасность ==
SCTP был разработан с некоторыми функциями позволяющими повысить безопасности, такими как «4-х кратное рукопожатие» (по сравнению с «трёхкратным рукопожатием» в TCP), чтобы предотвратить [[SYN-flood]] атаки, и больших [[Magic cookie|Cookie]] для проверки подлинности ассоциации.

Надежность была одним из ключевых аспектов разработки безопасности протокола SCTP. Multi-homing позволяет ассоциации оставаться открытой, даже если некоторые используемые маршруты и интерфейсы стали недоступны. Это имеет особое значение для [[SIGTRAN]], который используя SCTP, передаёт сообщения и сервисы протоколов [[ОКС-7]] поверх IP сети, что требует сильной устойчивости во время отключений линков для поддержания телекоммуникационных услуг, даже при серьёзных аномалиях в сети.

Шифрование не является частью оригинального дизайна SCTP.

В некоторых случаях SCTP является хорошим кандидатом для {{translation|:en:TCP/IP stack fingerprinting|Цифровой отпечаток стэка TCP/IP|проверки на прочность стэка TCP/IP}}. Причиной для этого является тот факт, что некоторые операционные системы распространяются с поддержкой протокола SCTP, но ввиду его слабой известности (по сравнению с TCP или UDP), администраторы иногда забывают настроить в [[Межсетевой экран|брандмауэре]] обнаружения вторжений, что даёт возможности для сканирования трафика.

== Сравнение возможностей протоколов транспортного уровня ==
{| class="wikitable"
|-
! Параметр
! UDP
! TCP
! SCTP
|-
| Установка соединения
| {{Нет}}
| {{Да}}
| {{Да}}
|-
| Надежная передача
| {{Нет}}
| {{Да}}
| {{Да}}
|-
| Сохранение границ сообщения
| {{Да}}
| {{Нет}}
| {{Да}}
|-
| Упорядоченная доставка
| {{Нет}}
| {{Да}}
| {{Да}}
|-
| Неупорядоченная доставка
| {{Да}}
| {{Нет}}
| {{Да}}
|-
| Контрольные суммы данных
| {{Да}}
| {{Да}}
| {{Да}}
|-
| Размер контрольной суммы (бит)
| 16
| 16
| 32
|-
| Путь MTU
| {{Нет}}
| {{Да}}
| {{Да}}
|-
| Управление накоплением 
| {{Нет}}
| {{Да}}
| {{Да}}
|-
| Многопоточность
| {{Нет}}
| {{Нет}}
| {{Да}}
|-
| Поддержка множественных интерфейсов
| {{Нет}}
| {{Нет}}
| {{Да}}
|-
| Связка потоков
| {{Нет}}
| {{Да}}
| {{Да}}
|}

== Формирование кадров сообщения ==
При формировании кадров сообщения обеспечивается сохранение границ сообщения в том виде, в котором оно передается сокету; это означает, что если клиент посылает серверу 100 байт, за которыми следуют 50 байт, то сервер воспринимает 100 байт и 50 байт за две операции чтения. Точно так же функционирует протокол UDP, это является особенностью протоколов, ориентированных на работу с сообщениями.

В противоположность им протокол TCP обрабатывает неструктурированный поток байт. Если не использовать процедуру формирования кадров сообщения, то узел сети может получать данные по размеру больше или меньше отправленных. Такой режим функционирования требует, чтобы для протоколов, ориентированных на работу с сообщениями и функционирующих поверх протокола TCP, на прикладном уровне был предоставлен специальный буфер данных и выполнялась процедура формирования кадров сообщений (что потенциально является сложной задачей).

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

[[Файл:Формирование_кадров_сообщения.jpg]]

== Структура пакета ==

{| align="right" width="40%"
|-
|
{| class="wikitable" style="margin: 0 auto; text-align: center; white-space: nowrap;" nowrap
|-
! Биты
! colspan="8" width="24%"| Биты 0-7
! colspan="8" width="24%"| 8-15
! colspan="8" width="24%"| 16-23
! colspan="8" width="24%"| 24-31
|- style="background-color: #ddddff"
!+0
|colspan="16" style="text-align: center"|Порт источника
|colspan="16" style="text-align: center"|Порт назначения
|- style="background-color: #ddddff"
! 32
|colspan="32" style="text-align: center"|Тег проверки
|- style="background-color: #ddddff"
! 64
|colspan="32" style="text-align: center"|Контрольная сумма
|- style="background-color: #ddffdd"
! 96
|style="text-align: center" colspan="8"|Тип 1 блока
|style="text-align: center" colspan="8"|Флаги 1 блока
|colspan="16" style="text-align: center"|Длина 1 блока
|- style="background-color: #ddffdd"
! 128
|colspan="32" style="text-align: center"|Данные 1 блока
|-
!…
|colspan="32" style="text-align: center"|…
|- style="background-color: #ffdddd"
!…
|style="text-align: center" colspan="8"|Тип N блока
|style="text-align: center" colspan="8"|Флаги N блока
|colspan="16" style="text-align: center"|Длина N блока
|- style="background-color: #ffdddd"
!…
|colspan="32" style="text-align: center"|Данные N блока
|}
|}

SCTP пакеты имеют более простую структуру, чем пакеты TCP. Каждый пакет состоит из двух основных разделов:
# Общий заголовок, который занимает первые 12 байт (выделены синим цветом)
# Блоки данных, которые занимают оставшуюся часть пакета.
Первый блок отмечен зелёным цветом, и последний из блоков N (N блок) выделен красным.

Каждый блок имеет идентификатор типа, занимающий один байт. Таким образом, возможно определение не более 255 различных типов блоков. RFC 4960 определяет список типов блоков, всего на данный момент определено 15 типов. Остальная часть блока состоит из поля длины размером в 2 байта (максимальная длина, которя может содержаться в данном поле, равна 65535 байтам) и, собственно, данных. Если размер блока не кратен 4-м байтам, то он заполняется нулями до размера, кратного 4-м байтам.

== Обработка ошибок ==

=== Повтор передачи ===
{{достоверность}}
Повторная передача блоков DATA может быть обусловлена (a) тайм-аутом, определяемым таймером повтора (retransmission timer) или (b) получением SACK, показывающих что блок DATA не был получен адресатом. Для снижения вероятности насыщения повтор передачи блоков DATA ограничивается. Значение тайм-аута для повтора (RTO) устанавливается на основе оценки времени кругового обхода и уменьшается экспоненциально с ростом частоты потери сообщений.
Для активных ассоциаций с почти постоянным уровнем трафика DATA причиной повтора скорей всего будут сообщения SACK, а не тайм-аут. Для снижения вероятности ненужных повторов используется правило 4 SACK, в соответствии с которым повтор передачи происходит только по четвертому SACK, указывающему на пропуск блока данных. Это позволяет предотвратить повторы передачи, вызванные нарушением порядка доставки.

=== Сбой в пути ===

Поддерживается счетчик для числа повторов передачи по конкретному адресу получателя без подтверждения успешной доставки. Когда значение этого счетчика достигает заданного порога (конфигурационный параметр), адрес объявляется неактивным и протокол SCTP начинает использовать другой адрес для передачи блоков DATA.
Кроме того, по всем неиспользуемым (дополнительным) адресам периодически передаются специальные блоки Heartbeat и поддерживается счетчик числа блоков Heartbeat, переданных без возврата соответствующего Heartbeat Ack. Когда значение счетчика достигает заданного порога (параметр конфигурации), соответствующий адрес объявляется неактивным.
Блоки Heartbeat передаются по неактивным адресам до тех пор, пока не будет получено сообщение Ack, говорящее о восстановлении активности адреса. Частота передачи блоков Heartbeat определяется значение RTO и дополнительной задержкой, которая позволяет передавать блоки Heartbeat без помех для пользовательского трафика.

=== Отказ в конечной точке ===

Для всех адресов получателя поддерживается общий счетчик числа повторов или блоков Heartbeat, переданных удаленной точке без получения от нее соответствующего подтверждения (Ack). Когда значение счетчика достигает заданного порога (параметр конфигурации) конечная точка декларируется как недостижимая и ассоциация SCTP закрывается.

== Реализации ==
Протокол SCTP реализован в следующих операционных системах:
* [[Linux (ядро)|Linux]] 2.4 и выше
* [[Sun Solaris]] 10
* [[Cisco IOS]] 12+
* [[DragonFly BSD]] начиная с версии 1.4
* [[QNX]] Neutrino,
* [[BSD|BSD UNIX]] (с внешним дополнением от проекта KAME)
* [[FreeBSD]] начиная с версии 7
* [[HP-UX]]
* [[AIX]] 5



== Примечания ==
{{примечания}}

== Ссылки ==
* RFC 3286
* http://rfc2.ru/3286.rfc - перевод RFC 3286 на русский язык
* http://www.sigtran.org
* http://www.sctp.org
* http://www.openss7.org
* http://www.sctp.de
* http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro.html
* [http://decoder.seventest.com/cgi-bin/decoder?family=TCP/IP SeveNTest онлайн декодер сообщений TCP/IP]

{{IPstack}}

{{compu-net-stub}}

[[Категория:TCP/IP]]
[[Категория:Интернет-протоколы]]

[[cs:Stream Control Transmission Protocol]]
[[de:Stream Control Transmission Protocol]]
[[en:Stream Control Transmission Protocol]]
[[es:Stream Control Transmission Protocol]]
[[eu:Stream Control Transmission Protocol]]
[[fr:Stream Control Transmission Protocol]]
[[he:Stream Control Transmission Protocol]]
[[it:Stream Control Transmission Protocol]]
[[ja:Stream Control Transmission Protocol]]
[[nl:Stream Control Transmission Protocol]]
[[nn:Stream Control Transmission Protocol]]
[[pl:Stream Control Transmission Protocol]]
[[pt:Stream Control Transmission Protocol]]
[[sv:Stream Control Transmission Protocol]]
[[tr:SCTP]]
[[yo:Stream Control Transmission Protocol]]
[[zh:流控制传输协议]]

SCTP - История изменений

Langator в 14:06, 27 июня 2011

Langator в 18:15, 16 июня 2011

Langator: Новая страница: «'''SCTP''' ({{lang-en|Stream Control Transmission Protocol}} — «протокол передачи с управлением потоком»), [[сетевой п...»

@@ Строка 57: / Строка 57: @@
 Шифрование не является частью оригинального дизайна SCTP.
-В некоторых случаях SCTP является хорошим кандидатом для {{translation|:en:TCP/IP stack fingerprinting|Цифровой отпечаток стэка TCP/IP|проверки на прочность стэка TCP/IP}}. Причиной для этого является тот факт, что некоторые операционные системы распространяются с поддержкой протокола SCTP, но ввиду его слабой известности (по сравнению с TCP или UDP), администраторы иногда забывают настроить в брандмауэре обнаружения вторжений, что даёт возможности для сканирования трафика.
+В некоторых случаях SCTP является хорошим кандидатом для TCP/IP stack fingerprinting (проверки на прочность стэка TCP/IP). Причиной для этого является тот факт, что некоторые операционные системы распространяются с поддержкой протокола SCTP, но ввиду его слабой известности (по сравнению с TCP или UDP), администраторы иногда забывают настроить в брандмауэре обнаружения вторжений, что даёт возможности для сканирования трафика.
 == Сравнение возможностей протоколов транспортного уровня ==
@@ Строка 235: / Строка 235: @@
 * http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro.html
 * [http://decoder.seventest.com/cgi-bin/decoder?family=TCP/IP SeveNTest онлайн декодер сообщений TCP/IP]
 [[Категория:TCP/IP]]
 [[Категория:Интернет-протоколы]]