Любое приложение, работающее по протоколу TCP,

можно перевести на работу по SCTP.

Основная роль транспортного уровня состоит в организации сквозной (end-to-end) коммуникационной службы между двумя или несколькими приложениями, работающими на разных хостах. Он изолирует приложения от специфики сети, соединяющей хосты, и предоставляет разработчикам приложений простой интерфейс.

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

В течение последних 20 лет приложения и конечные пользователи, имевшие дело с семейством TCP/IP, работали с одним из двух протоколов: TCP или UDP. Однако уже сегодня некоторые приложения требуют функциональности, выходящей за рамки той, которую в состоянии предоставить TCP или UDP, а в будущем эти требования возрастут еще больше. Для того чтобы увеличить функциональность транспортного уровня, в Internet Engineering Task Force в октябре 2000 года одобрили в качестве предварительного стандарта протокол контроля потоковой передачей SCTP (stream control transmission protocol) [2].

SCTP был создан в рамках проекта, начатого рабочей группой IETF Signaling Transport и посвященного разработке специализированного транспортного протокола для решений, связанных с передачей голоса по IP-сетям (VoIP) [3]. Осознав, что и другие приложения могут использовать некоторые возможности нового протокола, в IETF теперь рассматривают SCTP в качестве протокола транспортного уровня общего назначения, объединяющего функции TCP и UDP над уровнем IP.

Как и TCP, протокол SCTP предлагает приложениям, взаимодействующим по IP-сети, ориентированную на соединения типа «точка-точка» транспортную службу с надежной доставкой. Новый протокол унаследовал многие функции, разработанные для TCP за последние два десятилетия, в том числе возможности контроля перегрузки и восстановления утерянных пакетов. Действительно, любое приложение, работающее по протоколу TCP, можно перевести на SCTP без потери функциональности, но нынешнее сходство между этими протоколами в ближайшем будущем послужит основой для определенных отличий. Самые любопытные из этих отличий связаны с поддержкой в SCTP «многодомности» (multihoming) и частичного упорядочивания. Многодомность позволяет SCTP-хосту устанавливать «сеанс» с другим SCTP-хостом с помощью нескольких интерфейсов, каждый из которых идентифицируется отдельным IP-адресом. Частичное упорядочивание дает SCTP возможность осуществлять упорядоченную доставку одной или нескольких связанных последовательностей сообщений, пересылаемых между двумя хостами. Благодаря этому, SCTP может оказаться особенно полезен в тех приложениях, где необходима надежная доставка и быстрая обработка множества несвязанных между собой потоков данных.

Проблемы TCP

TCP, поддерживающий самые популярные на сегодняшний день приложения Internet, в последние годы был значительно усовершенствован с тем, чтобы обеспечить надежность и производительность в сетях различной емкости и качества. Тем не менее, в своей основе, его поведение остается таким же, как в 1981 году его описал один из пионеров Internet Джон Постел [4]. В том числе, в нем сохранились свойства, в силу которых он плохо подходит в качестве транспортного протокола для таких задач, как передача сигналов в VoIP-сетях или асинхронная обработка на базе транзакций. TCP требует наличия службы доставки со строго упорядоченной передачей для всех данных, пересылаемых между двумя хостами. Это слишком серьезное ограничение для приложений, которые допускают как последовательную (частичное упорядочивание), так и непоследовательную доставку потоков. TCP трактует каждую передачу данных как неструктурированную последовательность байт. В силу этого, приложения, которые обрабатывают отдельные сообщения, должны добавлять в поток байт границы сообщений и отслеживать их.

Основанный на механизме TCP-сокетов API-интерфейс не поддерживает множественную адресацию. С конкретным TCP-соединением с другим хостом приложение может связать только один IP-адрес. Если интерфейс, назначенный этому IP-адресу, отключается, TCP-соединение прерывается и его необходимо устанавливать заново.

Наконец, TCP-хосты восприимчивы к атакам типа «отказ в обслуживании» (DoS — denial of service). Для таких атак характерны своего рода «штормы», огромное количество пакетов TCP SYN, сигнализирующих ничего не подозревающему хосту о том, что отправитель хочет установить с ним TCP-соединение. Хост-получатель резервирует память и отвечает на запрос сообщениями SYN ACK. Когда атакующая система не возвращает сообщения ACK, необходимые для завершения трехэтапной процедуры установки TCP-соединения, ресурсы хоста, подвергнувшегося атаке, остаются неосвобожденными. Поэтому он оказывается не готов к обслуживанию легитимных запросов на установку TCP-соединения [5].

Свойства SCTP

Рис. 1. Архитектура SCTP. Новый протокол предлагает расширенную функциональность транспортного уровня. Два SCTP-хоста образуют ассоциацию, использующую несколько интерфейсов при доступе к IP-сети

На рис. 1 показано место SCTP в архитектуре TCP/IP вместе с разбиением его на базовые функциональные подуровни. Чтобы подчеркнуть отличие от традиционного понятия «соединение» (connection), под которым неявно подразумевается связь между одним адресом отправителя и одним адресом получателя, в SCTP используют термин «ассоциация» (association) для определения состояния протокола, установленного между двумя равноправными SCTP-хостами, обменивающимися сообщениями. Ассоциация SCTP может использовать несколько адресов на каждом из хостов.

SCTP поддерживает ряд функций, унаследованных от TCP и других протоколов, которые предлагают дополнительную функциональность.

  • Сохранение границ сообщений. SCTP сохраняет границы сообщений в пакетах приложения, размещая сообщения в одной или нескольких структурах данных SCTP, называемых фрагментами (chunk). Несколько сообщений могут объединяться в один фрагмент, а длинное сообщение может быть распределено по нескольким фрагментам.
  • Отсутствие блокировок типа head-of-line. SCTP устраняет задержку, вызываемую блокировкой обслуживания, которая может возникнуть тогда, когда приемник TCP оказывается вынужден восстанавливать корректную последовательность пакетов, поступающих в нарушенном порядке из-за переупорядочивания в сети или утраченных.
  • Несколько режимов доставки. SCTP поддерживает несколько моделей доставки, в том числе строгий порядок передачи (как TCP), частичное упорядочивание (по потокам) и неупорядоченную доставку (как UDP).
  • Поддержка "многодомности". SCTP посылает пакеты по одному IP-адресу получателя, но может перевести сообщения на альтернативный адрес, если данный IP-адрес недоступен.
  • Контроль перегрузки. SCTP использует стандартные методики, впервые применявшиеся для контроля перегрузки в TCP [1, 6], в том числе "медленный старт", предотвращение перегрузки и быстрая повторная передача. Приложения SCTP могут, таким образом, получать свою долю сетевых ресурсов, сосуществуя с приложениями TCP.
  • Выборочные подтверждения. SCTP использует схему выборочного подтверждения, унаследованную из TCP, для восстановления утраченных пакетов [7]. Приемник SCTP поддерживает обратную связь с отправителем, сообщая, какие пакеты необходимо отсылать повторно когда они теряются.
  • Фрагментация пользовательских данных. SCTP разбивает сообщения на фрагменты, так чтобы максимальный размер передаваемого элемента (MTU - maximum transfer unit) соответствовал ограничениям конкретного маршрута пересылки между взаимодействующими хостами. Эта функция описана в RFC 1191 и опционально используется протоколом TCP/IP, чтобы избежать снижения производительности, когда IP-маршрутизаторы вынуждены выполнять фрагментацию [8].
  • Механизм контроля работоспособности (hearbeat, дословно "сердцебиение" - Прим. перев.). SCTP посылает пакеты контроля работоспособности на адреса, находящегося в режиме ожидания хоста, которые входят в ассоциацию. Протокол декларирует, что IP-адрес будет отключен, как только он достигнет порогового значения невозвращенных подтверждений о работоспособности.
  • Защита от DoS-атак. Чтобы смягчить воздействие атак, передающих массу пакетов TCP SYN на хост-адресат, SCTP использует механизм cookie при инициализации ассоциации.

Многодомность

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

Современные IP-сети, как правило, устойчивы к ошибкам, однако зачастую критическим оказывается отрезок времени восстановления (reconvergenve), в течение которого сеть маршрутизации «излечивает» себя. В течение этого периода трафик может «отсылаться в никуда», либо передача может оказаться прерванной. Множественная адресация в конечной точке может уменьшить влияние отрезка восстановления связи, поскольку потерянные пакеты повторно передаются на альтернативный адрес. Ассоциация SCTP должна благодаря этому восстанавливаться быстрее и обеспечивать более высокую пропускную способность.

Снижение нагрузки

Стремясь обеспечить избыточность, предприятия часто подключаются ко второму Internet-провайдеру. Чтобы гарантировать возможность доставки пакетов по второму каналу, пользователь должен сообщить набор адресов (обычно полученный от первого провайдера), который выходит за рамки адресного диапазона, поддерживаемого вторым провайдером. Второй Internet-провайдер должен затем сообщить свое собственное объединенное адресное пространство и конкретные адреса, выделенные данному клиенту, что приводит к значительному росту числа записей в таблице маршрутизации.

Такое решение становится необязательным при работе с SCTP, поскольку ассоциация будет охватывать IP-адреса, содержащиеся в объединенных адресных диапазонах, поддерживаемых обоими провайдерами. Многодомность SCTP может, таким образом, использоваться для снижения нагрузки в системе маршрутизации Internet.

Топологическое разнообразие

Преимущества многодомности реализуются, если пути маршрутизации IP-адресов в ассоциации в достаточной мере различаются. Разнообразие путей маршрутизации диктует уровень отказоустойчивости для ассоциации SCTP. Это «топологическое разнообразие» можно физически организовать в небольших сетях, но гигантской сети Internet добиться этого гораздо сложнее. Некоторые предприятия заключают договоры с разными Internet-провайдерами уровня I и уровня II, чтобы увеличить свои шансы на сохранение соединения с помощью раздельных и разнообразных топологий маршрутизации.

Другие методики также могут обеспечить отказоустойчивость интерфейса хоста, однако они не в состоянии гарантировать приемлемое (с точки зрения конкретных приложений) время восстановления соединения [9].

Варианты доставки

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

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

Инициация

Оба протокола и SCTP, и TCP, ориентированы на установление соединения, и они требуют определения состояния соединения на каждом хосте. Соединение TCP определяется двумя IP-адресами и двумя номерами портов. Пусть имеется два хоста A и Z, тогда соединение TCP определяется как [IP-A]+[Port-A]+[IP-Z]+[Port-Z], где IP-A и Port-A — это один конец соединения, а IP-Z и Port-Z — другой.

Ассоциация SCTP определяется как [набор IP-адресов на хосте A]+[Port-A]+[набор IP-адресов на хосте Z]+[Port-Z]. Любые из IP-адресов на любом хосте могут указываться в качестве отправителя или получателя в IP-пакете и это корректно идентифицирует ассоциацию.

Рис. 2. Четырехэтапная процедура установки соединения SCTP. Ее результатом является создание ассоциации SCTP между двумя хостами

Прежде, чем начнется обмен данными, два SCTP-хоста должны передать друг другу информацию о состоянии соединений (в том числе задействованные IP-адреса) с помощью четырехэтапной процедуры установки соединения, показанной на рис. 2. В трехэтапной процедуре установки соединения в TCP, процедура, предусмотренная протоколом SCTP, позволяет защититься от DoS-атак. Получателю сообщения о намерении установить контакт INIT в четырехэтапной процедуре установки соединения не требуется сохранять никакую информацию о состоянии или резервировать какие-либо ресурсы. Вместо этого он посылает в ответ сообщение INIT-ACK, которое включает в себя специальную запись (cookie) состояния, содержащую всю информацию необходимую отправителю INIT-ACK для того, чтобы сформировать свое состояние. Спецзапись состояния подписывается цифровой подписью (см., например, [10]). Оба сообщения, INIT и INIT-ACK, содержат несколько параметров, необходимых для установки начального состояния:

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

После обмена этими сообщениями, отправитель INIT возвращает назад спецзапись состояния в виде сообщения COOKIE-ECHO, которое также может содержать связанные с ним пользовательские сообщения DATA (при наличии связанных путем ограничений на максимальный размер передаваемого элемента). При получении COOKIE-ECHO получатель полностью меняет свое состояние и отправляет обратное сообщение COOKIE-ACK, подтверждающее, что настройка завершена. Этот COOKIE-ACK также может сопровождаться пользовательскими сообщениями DATA.

Передача данных

Рис. 3. Формат пакета SCTP. За общим заголовком (с адресами портов отправителя и получателя, контрольной суммой и тегом проверки) следует один или несколько фрагментов данных переменной длины

Структурой сообщений SCTP предусматривается контроль формирования пакетов и сообщения данных в одном формате. На рис. 3 показан формат пакета SCTP. Вслед за общим заголовком размещается один или несколько фрагментов переменной длины, которые используют формат «тип-длина-значение» (TLV — type-length-value). Различные типы фрагментов применяются для контроля переноса или информации о данных в пакете SCTP.

Любой пакет SCTP в ассоциации, не содержащий данный тег, при получении будет удален. Тег проверки защищает от старых, неактуальных пакетов, «отставших» от предыдущей ассоциации, а также от различных вторжений, позволяет избежать характерного для TCP состояния ожидания, при котором расходуются ресурсы и ограничивается общее число соединений, которые может поддерживать хост.

Каждый из типов фрагмента включает в себя информацию заголовка TLV, который содержит тип фрагмента, флаги обработки доставки и длину поля. Кроме того, перед фрагментом DATA будет размещаться пользовательская информация о полезной нагрузке, состоящей из номера транспортной последовательности (TSN — transport sequence number), идентификатора потока, номера последовательности потока (SSN — stream sequence number).

TSN и SSN — два разных номера последовательности для каждого фрагмента DATA. TSN используется для обеспечения надежности каждой ассоциации, а SSN для упорядочивания по потокам. Идентификатор потока отмечает отдельные сообщения в каждом потоке.

Рис. 4. Обмен сообщениями SCTP. Данные SCTP и фрагменты SACK пересылаются между взаимодействующими хостами

На рис. 4 показан пример нормального обмена данными между двумя хостами SCTP. Хост SCTP посылает избранные подтверждения (фрагменты SACK) в ответ на каждый пакет SCTP, сопровождающий фрагменты DATA. Сообщение SACK полностью описывает состояние получателя так, что отправитель может принимать решение о повторной передаче в зависимости от того, что ему уже удалось получить. SCTP поддерживает алгоритмы быстрой повторной передачи и повторной передачи с тайм-аутом, аналогичные тем, которые применяются в TCP.

За небольшим исключением большинство типов фрагментов можно объединить вместе в один пакет SCTP.

Отключение

Транспортному протоколу, ориентированному на соединение, необходим метод постепенного отключения ассоциации. SCTP использует трехэтапную процедуру установки соединения, которая имеет важное отличие от процедуры, применяемой в TCP: конечная точка TCP может инициировать процедуру отключения, сохраняя открытым соединение и получая новые данные от другого хоста. SCTP не поддерживает такого «наполовину закрытого» состояния, т. е. обе стороны не могут передавать новые данные на свой более высокий уровень, если инициирована последовательность постепенного отключения.

Рис. 5. Отключение SCTP. Ассоциация SCTP закрывается путем обмена последовательностью управляющих фрагментов SHUTDOWN

На рис. 5 показана типичная последовательность постепенного отключения в SCTP. В этом примере приложение на хосте A хочет отключить и закрыть ассоциацию с хостом Z. SCTP вводит состояние SHUTDOWN_PENDING, в котором он не будет принимать данные от приложения, но по-прежнему будет посылать новые данные, которые помещаются в очередь на передачу на хост Z. После подтверждения всех размещенных в очереди данных, хост A посылает фрагмент SHUTDOWN и вводит состояние SHUTDOWN_SENT.

До получения фрагмента SHUTDOWN хост Z уведомляет свой более высокий уровень, что прекращает принимать от него новые данные и вводит состояние SHUTDOWN_RECEIVED. Z передает оставшиеся данные на A, за которыми следуют фрагменты SHUTDOWN, информирующие Z о появлении данных и подтверждающие, что ассоциация отключена. Как только подтверждены все данные, помещенные в очередь на хосте Z, хост A посылает соответствующий фрагмент SHUTDOWN-ACK, за которым следует фрагмент SHUTDOWN-COMPLETE, завершающий отключение ассоциации.

Развертывание протокола SCTP

19 компаний, в том числе Ericsson, Motorola, IBM, Cisco и Nokia, приняли участие в «конкурсе» SCTP, состоявшемся в апреле 2001 года. Здесь были продемонстрированы решения, в рамках которых реализована поддержка SCTP, такими операционными системами, как Linux, IBM AIX, Sun Solaris, Windows и FreeBSD. Успех тестов на интероперабельность между различными решениями позволяет предположить, что SCTP в скором времени будет поддерживаться в коммерческих продуктах.

Код SCTP уже можно получить в нескольких организациях. Компания Intellinet (www.intellinet-tech.com), поставщик решений конвергенции SS7/IP, предлагает стек протоколов SCTP. Компания Data Connection (www.dataconnection.com/sctp), производитель программного обеспечения сетевых протоколов разработала мобильную реализацию SCTP. Исходные тексты ядра Linux для поддержки SCTP предоставляет OpenSS7 (www.openss7.org). Несколько университетов работают над стеками протоколов SCTP, в том числе университеты Темпла и Делавера, а Рэнделл Стюарт разработал эталонную реализацию протокола для FreeBSD (www.sctp.org).

В дополнение к усилиям рабочих групп Sigtrans и Transport Area, к примеру, IETF активно изучает вопрос применения SCTP для поддержки транспортного уровня в HTTP и Diameter для обработки больших объемов сообщений. Несомненно SCTP окажет значительное влияние на технологии VoIP.

По мере того, как IP-сети начинают обрабатывать все больший объем голосового трафика, им потребуется взаимодействие с телефонными сетями, использующими сигнальный протокол на базе надежной передачи сообщений Signaling System 7 для установки голосовых соединений. Усилия рабочей группы Sigtrans направлены на адаптацию и инкапсуляцию сообщений протокола SS7 в IP-пакеты. Шлюзы, которые являются интерфейсами между SS7 и IP-сетями, являются основными кандидатами на создание ассоциаций SCTP с другими шлюзами SS7/IP или узлами VoIP при установке голосовых соединений [11].

SCTP также предлагает механизм для разгрузки сети SS7; существующие сети SS7 используют относительно низкоскоростные каналы (56 Кбит/с) для транспортировки сообщений управления вызовами. По мере распространения мобильного Internet, эта дополнительная емкость, скорее всего, будет необходима для обработки растущих объемов сигнальных сообщений, представленных повсеместно распространенными приложениями, такими как служба коротких сообщений.

Вопросы будущего

Сейчас IETF работает над следующей версией протокола SCTP, в которую будут внесены некоторые усовершенствования. Так, Джонатан Стоун продемонстрировал, что испорченные пакеты могут выходить из SCTP с корректной контрольной суммой Adler-32 (изначально использовавшейся в SCTP) и порождать проблемы на уровне приложений. В силу этого, рабочая группа Transport Area намерена заменить контрольную сумму на CRC-32, которая превосходно подходит для обработки пакетов небольшого размера.

Чтобы добиться паритета с традиционными приемами работы с существующими сетями SS7, рабочая группа изучает вопрос о том, как динамически добавлять и удалять IP-адреса в ранее созданные ассоциации. Это усовершенствование позволит администраторам динамически добавлять сетевую плату (и, таким образом, новый IP-адрес) в устройство (скажем шлюз SS7/IP), не создавая заново ассоциацию SCTP.

Учитывая, что в скором времени начнется распространение IPv6, протокол SCTP также должен «уметь» работать с адресами IPv6.

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

Литература
  1. P. Amer, S. Iren, and P. Conrad, "The Transport Layer: Tutorial and Survey", ACM Computing Surveys, vol. 31, no. 4, Dec. 1999
  2. J. Postel, "Transmission Control Protocol", IETF RFC 793, Sept. 1981
  3. IETF Signaling Transport working group charter, ietf.org/html.charters/sigtran-charter.html
  4. R. Stewart et al., "Stream Control Transmission Protocol", IETF RFC 2960, Oct. 2000
  5. "Defining Strategies to Protect against TCP SYN Denial of Service Attacks", Cisco Systems, tech. memo, Aug. 2001; www.cisco.com/warp/public/707/4.html
  6. M. Allman, V. Paxson, W. Stevens, "TCP Congestion Control", IETF RFC 2581, Apr. 1999
  7. M. Mathis et al., "TCP Selective Acknowledgment Options", IETF RFC 2018, Oct. 1996
  8. J. Mogul, S. Deering, "Path MTU Discovery", IETF RFC 1191, Nov. 1999
  9. J. Touch, "Dynamic Internet Overlay Deployment and Management Using the X-Bone", Computer Networks, July 2001
  10. [10] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", IETF RFC 2104, Feb. 1997
  11. [11] A. Jungmaier et al., "SCTP: A Multi-link End-to-End Protocol for IP-based Networks", Int'l J. Electronics and Comm., vol. 55, no. 1, Jan. 2001

Рэнделл Стюарт (rrs@cisco.com) — ведущий научный сотрудник компании Cisco Systems, где он фокусируется, в частности, на вопросах беспроводных Internet-технологий. Основной разработчик документа RFC 2960, в котором описан SCTP. Стюарт — соавтор книги Stream Control Transmission Protocol (SCTP): A Reference Guide (Addison Wesley Longman, 2001).

Крис Метц (chmetz@cisco.com) — технический руководитель группы Cisco Service Provider Engineering. Соавтор книги ATM and Multiprotocol Networking (McGraw-Hill, 1997) и автор книги IP Switching: Protocols and Architectures (McGraw-Hill, 1999).

Randall Stewart, Chris Metz, SCTP: New Transport Protocol for TCP/IP. IEEE Internet Computing, November — December 2001. Copyright IEEE Computer Society, 2001. All rights reserved. Reprinted with permission

Ресурсы SCTP

Дополнительную информацию о протоколе контроля потоковой передачей можно найти в Web.