SCTP (Stream Control Transmission Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 00:33, 23 мая 2016.

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

Основные функции SCTP

SCTP представляет собой unicast-протокол, который обеспечивает обмен данными между двумя конечными точками. Отметим, что каждая из этих точек может быть представлена более чем 1 адресом IP. Протокол SCTP обеспечивает гарантию доставки, детектирование случаев отбрасывания данных, изменения порядка доставки, повреждения или дублирования данных, а также повторную передачу пакетов при возникновении необходимости. Обмен данными по протоколу SCTP происходит в полнодуплексном режиме.

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

Поддержка множества потоков в SCTP

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

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

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

Другим примером является возможность использования множества потоков для доставки multimedia-документов (например, web- страниц) в рамках одной сессии. Поскольку такие документы состоят из разнотипных объектов разных размеров, многопотоковая доставка таких компонент не требует строгой упорядоченности. Однако использование множества потоков при доставке существенно повышает для потребителей привлекательность сервиса.

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

Протокол SCTP поддерживает многопотоковую передачу за счет устранения зависимости между передачей и доставкой данных. В частности, каждый блок полезной информации типа DATA (данные) использует два набора порядковых номеров. Номер TSN управляет передачей сообщений и детектированием их потери, а пара “идентификатор потока Stream ID – номер SSN ” используется для управления порядком доставки потребителю полученных данных.

Такая независимость механизмов нумерации позволяет получателю незамедлительно обнаруживать пропуски данных (например, в результате потери сообщения), а также видеть влияние потерянных данных на поток. Утрата сообщения вызывает появление пропуска в порядковых номерах SSN для потока, на который это сообщение оказывает влияние и не вызывает такого пропуска для других потоков. Следовательно, получатель может продолжать доставку незатронутых потоков, не дожидаясь повтора передачи утраченного сообщения

Поддержка многодомных хостов в SCTP

Другим важным качеством SCTP является поддержка многодомных хостов, позволяющая создавать конечные точки SCTP с мно- жеством IP-адресов. Поддержка многодомных хостов повышает уровень “живучести” сессий в случаях возникновения сбоев в сети. В традиционных однодомных сеансах отказ в соединении с ЛВС может изолировать конечную точку, а сбой в работе магистральной сети может привести к временным проблемам на транспортном уровне, пока протокол маршрутизации IP не найдет пути в обход сбойного участка. При использовании многодомных узлов SCTP могут быть организованы резервные (избыточные) соединения с ЛВС и поддерживаются различные варианты преодоления сложностей, связанных с отказами в магистральных сетях. Использование адресов с различными префиксами может обеспечить автоматическую маршрутизацию пакетов к другому оператору. Можно использовать методы route-pinning или даже резервировать соединения с магистральными сетями, если обеспечивается контроль над сетевой архитектурой и протоколами.

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

Для повышения уровня безопасности требуется, чтобы некоторые отклики передавались по адресу, указанному в поле отправителя сообщения, вызвавшего отклик. Например, когда сервер получает блок INIT от клиента для инициирования SCTP - ассоциации, сервер всегда будет передавать блок INIT ACK по адресу отправителя в заголовке IP блока INIT.

Процедура создания ассоциаций SCTP

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

Механизм Cookie

Механизм cookie обеспечивает защиту от атак вслепую, когда атакующий генерирует множество блоков INIT с целью перегрузки сервера SCTP за счет расхода памяти и иных ресурсов, требуемых для обработки новых запросов INIT. Взамен выделения памяти для TCB сервер создает параметр Cookie с информацией TCB, корректным временем жизни и сигнатурой для аутентификации. Этот параметр передается клиенту в сообщении INIT ACK. Поскольку сообщения INIT ACK всегда возвращаются по адресу отправителя запросов INIT, атакующий вслепую не будет получать Cookie. Легитимный клиент SCTP получит Cookie и вернет серверу блок COOKIE ECHO, по которому сервер SCTP может проверить корректность Cookie и использовать это значение для создания TCB. Поскольку параметр Cookie создается сервером и на сервере же проверяется, формат и секретный ключ Cookie знает только сервер и не возникает необходимости в передаче их через сеть клиенту.

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

INIT Collision Resolution

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

Функции обмена данными в SCTP

За обменом блоками DATA в SCTP следует процедура, подобная TCP ACK. Получение блока DATA подтверждается передачей блока SACK, который показывает не только диапазон принятых TSN , но и некумулятивные номера TSN, указывающие пропуски в принятой последовательности TSN. Как и в процедурах TCP подтверждения SACK передаются с использованием метода delayed ack (обычно одно сообщение SACK на каждый полученный пакет с ограничением задержки между передачей сообщений SACK и увеличением задержки на 1 при получении каждого пакета с обнаруженным пропуском).

Алгоритмы управления трафиком и предотвращения насыщения соответствуют аналогичным алгоритмам TCP. Анонсируемый размер окна показывает емкость буфера на приемной стороне, а поддерживаемое для пути окно насыщения позволяет управлять пакетами “на лету”. Алгоритмы Congestion avoidance, Fast recovery и Fast retransmit встроены в протокольные процедуры в соответствии с RFC 2581. Единственным отличием является то, что конечные точки должны обеспечивать преобразование между количеством принятых/переданных байтов и номерами TSN, поскольку нумерация TSN осуществляется для транка в целом.

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

Завершение работы ассоциаций SCTP

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

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

Формат сообщений SCTP

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

Каждый блок содержит поля типа, флагов, размера, а также значение. Управляющие блоки включают различные параметры и флаги, зависящие от типа блока. Блоки данных (DATA) включают флаг управления сегментацией и сборкой, а также параметры TSN, Stream ID, Stream Sequence Number и Payload Protocol Identifier.

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

Формат сообщений SCTP обеспечивает механизм связывания множества блоков данных и управления в одно сообщение для повышения эффективности транспорта. Использованием такой группировки (bundling) управляет приложение, поэтому группировка стартовой передачи невозможна. Связывание естественным образом осуществляется при повторе передачи блоков DATA в целях снижения вероятности насыщения.

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

Повтор передачи

Повторная передача блоков 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 позволяет определять новые типы блоков (chunk), поля флагов и параметров для расширения возможностей протокола. Любое расширение должно базироваться на стандартном соглашении с IETF, следовательно фирменные расширения не поддерживаются протоколом.

Значения Chunk Type разбиты на 4 группы, чтобы позволить расширениям использовать предопределенные процедуры для откликов на нераспознанные типы блоков. Варианты откликов включают: отбрасывание пакета целиком, игнорирование блока, а также игнорирование с передачей отчета. Аналогичные предопределенные отклики поддерживаются и для неопознанных значений Parameter Type.

Значения Chunk Parameter Type используют независимые диапазоны для каждого Chunk Type. На практике значения, определенные в спецификации SCTP, скоординированы таким образом, что конкретный параметр будет использовать одинаковые значения Chunk Parameter Type для всех Chunk Type. Необходимость такого выбора подтвердит практика использования протокола.

Пример реализации многопотоковой передачи

Сервер точного времени

int main()
{
  int listenSock, connSock, ret;
  struct sockaddr_in servaddr;
  char buffer[MAX_BUFFER+1];
  time_t currentTime;

  /* Создание сокета SCTP в стиле TCP */
  listenSock = socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );

  /* Принимается соединение с любого интерфейса */
  bzero( (void *)&servaddr, sizeof(servaddr) );
  servaddr.sin_family = AF_INET;
  servaddr.sin_addr.s_addr = htonl( INADDR_ANY );
  servaddr.sin_port = htons(MY_PORT_NUM);

  /* Адрес привязки – любой, порт - MY_PORT_NUM */
  ret = bind( listenSock,
               (struct sockaddr *)&servaddr, sizeof(servaddr) );

  /* Сокет сервера переводится в состояние ожидания соединения */
  listen( listenSock, 5 );

  /* Цикл работы сервера... */
  while( 1 ) {

    /* Ожидание соединения клиента */
    connSock = accept( listenSock,
                        (struct sockaddr *)NULL, (int *)NULL );

    /* Соединение с новым клиентом */

    /* Выясняется текущее время */
    currentTime = time(NULL);

    /* Посылается текущее время по потоку 0 (поток для локального времени) */
    snprintf( buffer, MAX_BUFFER, "%s\n", ctime(&currentTime) );

    ret = sctp_sendmsg( connSock,
                          (void *)buffer, (size_t)strlen(buffer),
                          NULL, 0, 0, 0, LOCALTIME_STREAM, 0, 0 );

    /* Посылается GMT по потоку 1 (поток для GMT) */
    snprintf( buffer, MAX_BUFFER, "%s\n",
               asctime( gmtime( &currentTime ) ) );

    ret = sctp_sendmsg( connSock,
                          (void *)buffer, (size_t)strlen(buffer),
                          NULL, 0, 0, 0, GMT_STREAM, 0, 0 );

    /* Закрывается клиентское соединение */
    close( connSock );

  }

  return 0;
 }

Исходный код начинается с создания сокета сервера (IPPROTO_SCTP используется для создания сокета SCTP прямого соединения). Затем создается структура sockaddr, в которой указывается, что разрешаются соединения к любому локальному интерфейсу (используется подстановочный (wildcard) адрес INADDR_ANY). Структура sockaddr привязывается к сокету с помощью вызова bind, а потом сокет сервера переводится в состояние прослушивания (listening state). С этого момента возможны входящие соединения.

Обратите внимание на то, что протокол SCTP использует многие из тех же сокетов API, что и протоколы TCP и UDP. Некоторые дополнительные функции API реализованы в инструментах разработки lksctp (см. раздел Ресурсы).

Серверная программа ожидает в цикле нового подключения клиента. При возвращении из функции accept создается новое клиентское подключение, определяемое сокетом connSock. С помощью функции time выясняется текущее время и переводится в строку функцией snprintf. С помощью функции sctp_sendmsg (нестандартный вызов сокета) строка посылается клиенту по заданному потоку (LOCALTIME_STREAM). После того как строка с локальным временем послана, текущее время переводится в формат GMT и посылается по потоку GMT_STREAM.

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

Клиент протокола точного времени

int main()
{
  int connSock, in, i, flags;
  struct sockaddr_in servaddr;
  struct sctp_sndrcvinfo sndrcvinfo;
  struct sctp_event_subscribe events;
  char buffer[MAX_BUFFER+1];

  /* Создание сокета SCTP в стиле TCP */
  connSock = socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP );

  /* Определяется адрес точки соединения */
  bzero( (void *)&servaddr, sizeof(servaddr) );
  servaddr.sin_family = AF_INET;
  servaddr.sin_port = htons(MY_PORT_NUM);
  servaddr.sin_addr.s_addr = inet_addr( "127.0.0.1" );

  /* Соединение с сервером */
  connect( connSock, (struct sockaddr *)&servaddr, sizeof(servaddr) );

  /* Ожидается получение данных SCTP Snd/Rcv с помощью функции sctp_recvmsg */
  memset( (void *)&events, 0, sizeof(events) );
  events.sctp_data_io_event = 1;
  setsockopt( connSock, SOL_SCTP, SCTP_EVENTS,
               (const void *)&events, sizeof(events) );

  /* Ожидается получение двух сообщений */
  for (i = 0 ; i < 2 ; i++) {

    in = sctp_recvmsg( connSock, (void *)buffer, sizeof(buffer),
                        (struct sockaddr *)NULL, 0,
                        &sndrcvinfo, &flags );

    /* Завершающий символ строки – 0 */
    buffer[in] = 0;

    if        (sndrcvinfo.sinfo_stream == LOCALTIME_STREAM) {
      printf("(Local) %s\n", buffer);
    } else if (sndrcvinfo.sinfo_stream == GMT_STREAM) {
      printf("(GMT  ) %s\n", buffer);
    }

  }

  /* Закрытие сокета и выход */
  close(connSock);

  return 0;
}

В клиентском приложении создается сокет протокола SCTP, а затем структура sockaddr, содержащая информацию о конечной точке подключения. После этого с помощью функции connect устанавливается соединение с сервером. Для того чтобы получить номер потока сообщений по протоколу SCTP, необходимо указать параметр сокета sctp_data_io_event. При получении сообщения с помощью функции API sctp_recvmsg дополнительно принимается структура sctp_sndrcvinfo, содержащая номер потока. Этот номер позволяет различать сообщения потока 0 (местное время) и потока 1 (GMT).

Будущее протокола 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, которые помогут вам в ваших исследованиях.

Cсылки