Вопрос

Недавно я прочитал книгу «Сетевое программирование UNIX, Vol.1" Ричардс Стивенс и я обнаружили, что помимо TCP и UDP существует третий стандарт транспортного уровня: SCTP.

Краткое содержание:SCTP — это протокол транспортного уровня, который управляется сообщениями, как UDP, но надежен, как TCP.Вот краткое введение от IBM DeveloperWorks.

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

Почему SCTP так неизвестен?Почему он мало используется?

Это было полезно?

Решение

Действительно, SCTP используется в основном в сфере телекоммуникаций.Традиционно телекоммуникационные коммутаторы используют SS7 (Номер системы сигнализации7) для соединения различных объектов в телекоммуникационной сети.Например - база данных абонентов провайдера связи (HLR), со свитчем (MSC), абонент тоже подключен (MSC).

Сфера телекоммуникаций движется к более высоким скоростям и более доступной среде.Одним из этих изменений является замена протокола SS7 более элегантным, быстрым и гибким протоколом на основе IP.

Телекоммуникационная сфера очень консервативна.Сеть SS7 используется здесь уже несколько десятилетий.Это очень надежная и закрытая сеть.Это означает, что обычный пользователь не имеет к нему доступа.

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

  • имитировать все преимущества сети SS7, накопленные за десятилетия.
  • создать протокол, ориентированный на соединение, который лучше TCP по скорости, безопасности и избыточности.

Последние версии Linux уже поддерживают SCTP.

Другие советы

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

Как и многие другие многообещающие протоколы, SCTP, к сожалению, мертв, пока D-link и Netgear не починят свои сломанные NAT-блоки.

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

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

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

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

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

К вашему сведению, SCTP обязательно поддерживается для Diameter (см. RADIUS следующего поколения).см. RFC 3588

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers MUST support both.  Future versions of this specification MAY
   mandate that clients support SCTP.

SCTP малоизвестен и мало используется/развертывается, потому что:

  • Широко распространен:Не широко интегрирован в стеки TCP/IP (в 2013 г.:все еще отсутствует в последних версиях Mac OSX и Windows)
  • Библиотеки:Несколько высокоуровневых привязок на простых в использовании языках (Отказ от ответственности:я сопровождаю pysctp, поддержка простого стека SCTP для Python)
  • НАТ:Не очень хорошо/вообще пересекает NAT (менее 1% домашних и корпоративных маршрутизаторов в Интернете используют NAT по SCTP).
  • Популярность:Ни одно общедоступное приложение не использует его.
  • Парадигма программирования:оно немного изменилось:это все еще сокет, но вы можете соединить множество хостов со многими хостами (мультихоминг), дейтаграммы упорядочены и надежны, эээ...
  • Сложность:Стек SCTP сложен в реализации (из-за вышеизложенного)
  • Соревнование:Скоро появится многопутевой TCP, который должен учитывать потребности/возможности множественной адресации, поэтому люди, если это возможно, воздерживаются от внедрения SCTP, ожидая MTCP.
  • Ниша:Потребности в заполнении SCTP очень специфичны (упорядоченные надежные дейтаграммы, многопотоковые) и не нужны большинству приложений.
  • Безопасность:SCTP обходит средства контроля безопасности (некоторые межсетевые экраны, большинство IDS и все DLP не отображаются в netstat, за исключением CentOS/Redhat/Fedora...)
  • Возможность аудита:Примерно три компании в мире регулярно проводят аудит безопасности SCTP (Отказ от ответственности:Я работаю в одном из них)
  • Кривая обучения:Не так много инструментов для работы с SCTP (проверьте отличный сsctp это прекрасно сочетается с netcat или использованием socat)
  • Под капотом:Используется в основном в сфере телекоммуникаций, и каждый раз, когда вы отправляете SMS, начинаете пользоваться Интернетом на своем мобильном телефоне или совершаете телефонные звонки, вы часто запускаете сообщения, которые передаются через SCTP (SIGTRAN/SS7 с GSM/UMTS, Diameter с LTE/IMS/RCS, S1AP /X2AP с LTE), так что вы на самом деле часто его используете, но никогда об этом не узнаете ;-)

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

п2.SCTP, отображаемый через UDP/IPv4, позволяет использовать больше частных хостов на публичный адрес, но сопоставления UDP в шлюзах IPv4/NAT, как известно, сложно установить и поддерживать из-за того, что UDP — это транспорт без установления соединения без какого-либо явного состояния, которое NAT может отслеживать. .

п3.SCTP, отображаемый непосредственно через IPv6, требует...хорошо...IPv6.Вы пытались развернуть IPv6?Если да, пробовали ли вы купить брандмауэр IPv6?Поддерживает ли он SCTP?Как насчет балансировщика нагрузки?SSL-ускоритель?

п4.Наконец, большая часть Интернета в значительной степени ограничена тем, что может пройти через TCP-порт 80 и порт 443, поэтому SCTP любого типа имеет тенденцию проигрывать здесь.Следовательно, вы видите такие усилия, как MPTCP рабочая группа в IETF.

Многие из нас скоро будут использовать SCTP, поскольку он используется каналами данных WebRTC для создания TCP-подобного надежного уровня поверх UDP — SCTP поверх DTLS поверх UDP: https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6

Чтение Страница SCTP в Википедии Я бы сказал, что основная причина в том, что SCTP — очень молодой протокол (предложенный в 2000 году), который в настоящее время не поддерживается основными ОС (Окна, ОС Х, Линукс).

Если слово «очень молодой» кажется вам неуместным, подумайте о ИПВ6:«В декабре 2008 года, несмотря на 10-летие своего существования в качестве протокола Standards Track, IPv6 находился только в зачаточном состоянии с точки зрения общего глобального развертывания».

SCTP широко используется в сети 4G LTE, где Diameter используется для AAA.

Возможно, он не очень известен, но он не неиспользован.Совсем недавно произошел черновик опубликовано на IETF о Использование SCTP в качестве протокола транспортного уровня для HTTP.

Что касается всех комментариев о том, что коммерческие маршрутизаторы сломаны или не имеют поддержки SCTP, проблема заключается в том, что SCTP с NAT все еще находится в черновой форме в IETF.Таким образом, для их реализации не существует спецификации RFC.

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctp появился слишком поздно, и во многих ситуациях TCP достаточно.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top