Надежная передача данных по протоколу SCTP

Протокол передачи с управлением потоком объединяет преимущества протоколов TCP и UDP

Протокол передачи с управлением потоком (Stream Control Transmission Protocol, SCTP) ? это надежный транспортный протокол, который обеспечивает стабильную, упорядоченную (с сохранением порядка следования пакетов) передачу данных между двумя конечными точками (подобно TCP). Кроме того, протокол обеспечивает сохранение границ отдельных сообщений (подобно UDP). Однако в отличие от протоколов TCP и UDP протокол SCTP имеет дополнительные преимущества, такие как поддержка множественной адресации (multihoming) и многопоточности (multi-streaming) – каждая из этих возможностей увеличивает доступность узла передачи данных. В этой статье мы познакомимся с основными характеристиками протокола SCTP ядра Linux® 2.6 и рассмотрим исходный текст программ сервера и клиента, демонстрирующий возможности протокола по многопоточной передаче данных.

 

 

 

         Основные особенности SCTP:

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

 

Множественная адресация

По сравнению с протоколом TCP поддержка протоколом SCTP множественной адресации обеспечивает приложениям повышенную готовность. Хост, подключенный к нескольким сетевым интерфейсам и потому имеющий несколько IP адресов, называется multi-homed хост. В протоколе TCP соединением называется канал между двумя конечными точками (в данном случае сокет между интерфейсами двух хостов). Протокол SCTP вводит понятие ассоциации, которая устанавливается между двумя хостами и в рамках которой возможна организация взаимодействия между несколькими интерфейсами каждого хоста.

На рисунке 1 показано отличие соединения протокола TCP и ассоциации протокола SCTP.

 

Рисунок 1. Отличие между соединением протокола TCP и ассоциацией протокола SCTP

 

В верхней части рисунка показано соединение протокола TCP. Каждый хост имеет один сетевой интерфейс, соединение устанавливается между одним интерфейсом на клиенте и одним интерфейсом на сервере. Установленное соединение привязано к конкретному интерфейсу.

В нижней части рисунка представлена архитектура, в которой каждый хост имеет два сетевых интерфейса. Обеспечивается два маршрута по независимым сетям: один от интерфейса C0 к интерфейсу S0, другой — от интерфейса C1 к интерфейсу S1. В протоколе SCTP два этих маршрута объединяются в ассоциацию.

Протокол SCTP отслеживает состояние маршрутов в ассоциации с помощью встроенного механизма контрольных сообщений; при нарушении маршрута передача данных продолжается по альтернативному маршруту. При этом приложению даже не обязательно знать о фактах нарушения и восстановления маршрута.

Переключение на резервный канал также может обеспечивать непрерывность связи для сетевых приложений. Для примера рассмотрим ноутбук, который имеет беспроводный интерфейс 802.11 и интерфейс Ethernet. Пока ноутбук подключен к док-станции, предпочтительнее использовать более скоростной интерфейс Ethernet (в протоколе SCTP используется термин основной адрес); при нарушении этого соединения (в случае отключения от док-станции), будет использоваться соединение по беспроводному интерфейсу. При повторном подключении к док-станции будет обнаружено соединение по интерфейсу Ethernet, через который будет продолжен обмен данными. Таким образом, протокол SCTP реализует эффективный механизм, обеспечивающий высокую готовность и повышенную надежность.

 

Многопотоковая передача данных

В некоторой степени ассоциация протокола SCTP похожа на соединение протокола TCP. Отличие состоит в том, что протокол SCTP поддерживает несколько потоков в рамках одной ассоциации. Все потоки являются независимыми, но принадлежат одной ассоциации (см. рисунок 2).


Рисунок 2. Взаимосвязь между ассоциацией протокола SCTP и потоками.


 

Каждому потоку ассоциации присваивается номер, который включается в передающиеся пакеты SCTP. Важность многопотоковой передачи обусловлена тем, что блокировка какого-либо потока (например, из-за ожидания повторной передачи при потере пакета) не оказывает влияния на другие потоки в ассоциации. В общем случае данная проблема получила название блокировка головы очереди (head-of-line blocking). Протокол TCP уязвим для подобных блокировок.

Каким образом множество потоков обеспечивают лучшую оперативность при передаче данных? Например, в протоколе HTTP данные и служебная информация передаются по одному и тому же сокету. Web-клиент запрашивает файл, и сервер посылает файл назад к клиенту по тому же самому соединению. Многопотоковый HTTP-сервер сможет обеспечить более быструю передачу, так как множество запросов может обслуживаться по независимым потокам одной ассоциации. Такая возможность позволяет распараллелить ответы сервера. Это если и не повысит скорость отображения страницы, то позволит обеспечить ее лучшее восприятие благодаря одновременной загрузке кода HTML и графических изображений.

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

 

Безопасность устанавливаемого подключения

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


Рисунок 3. Обмен пакетами при установлении соединения по протоколам TCP и SCTP


 

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

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

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

 

Формирование кадров сообщения

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

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

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


Рисунок 4. Формирование кадров сообщений по протоколу UDP/SCTP и по протоколу, обрабатывающему неструктурированный поток байт


При передаче потоковых данных (аудио- и видеоданных) процедура формирования кадров необязательна.

 

Настраиваемая неупорядоченная передача данных

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

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

 

Поэтапное завершение передачи данных

В отличие от протокола UDP, функционирование которого не предполагает установления соединения, протоколы TCP и SCTP являются протоколами с установлением соединения. Оба эти протокола требуют выполнения процедуры установления и разрыва соединения между корреспондентами. Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.

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

Протокол SCTP является сравнительно новым протоколом, учитывая то, что он был представлен в виде RFC в октябре 2000 года. С этого момента он начал использоваться во многих операционных системах, включая GNU/Linux, BSD и Solaris. В виде дополнительного коммерческого пакета независимого поставщика он также доступен для операционной системы Microsoft® Windows®.

По мере расширения доступности протокола SCTP его будут использовать в качестве основного транспортного протокола все новые приложения. На базе SCTP уже созданы такие традиционные приложения, как FTP и HTTP. Протокол SCTP также используется и в других протоколах, например, протоколе установления сессии (Session Initiation Protocol (SIP)) и протоколе канальной сигнализации № 7 (Common Channel Signaling System No7 (SS7)).. Коммерческую реализацию протокола SCTP имеет операционная система Cisco IOS.

После включения протокола SCTP в ядро Linux 2.6 стало возможным построение и развертывание надежных сетевых приложений высокой готовности. Основываясь на протоколе IP, SCTP позволяет прозрачно заменить протоколы TCP и UDP, введя при этом дополнительные возможности: множественную адресацию, многопоточную передачу и повышенную безопасность. Сейчас, когда вы познакомились с некоторыми преимуществами протокола SCTP, вы можете исследовать другие его возможности. В проекте Linux Kernel SCTP (lksctp) имеются документация и дополнительные функции API, которые помогут вам в ваших исследованиях.