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

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

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

Честно говоря, я никогда не слышал о SCTP раньше. Я не помню, чтобы я читал об этом в каких-либо сетевых книгах или слышал об этом на занятиях, которые я посещал. Чтение других вопросов о стековом потоке , в которых упоминается 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, Socket-подобный API появился позже, и он молодой. Тем не менее, я думаю, что большинство людей, которые находят время, чтобы понять это (и знают недостатки TCP), ценят это - это хорошо разработанный протокол, основанный на наших ~ 30-летних знаниях TCP и UDP.

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

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

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

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

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

   Клиенты Diameter ДОЛЖНЫ поддерживать TCP или SCTP, а агенты и
   серверы ДОЛЖНЫ поддерживать оба. Будущие версии этой спецификации МОГУТ
   требует, чтобы клиенты поддерживали SCTP.

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

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

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

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

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

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

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

Читая страницу SCTP Wikipedia, я бы сказал, что основная причина в том, что SCTP - очень молодой протокол (предложенный в 2000 году), который в настоящее время не поддерживается основными операционными системами ( Windows , OS X , Linux ).

Если «очень молодой» кажется вам неуместным, подумайте об IPV6 : «В декабре 2008 года, несмотря на то, что 10-летний юбилей был отмечен как протокол отслеживания стандартов, 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.

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