Почему SCTP мало используется / известен
Недавно я проверил книгу Ричардса Стивенса "Сетевое программирование в UNIX, том 1" и обнаружил, что существует третий стандарт транспортного уровня, помимо TCP и UDP: SCTP.
Описание: SCTP - это протокол транспортного уровня, который управляется сообщениями, как UDP, но надежен, как TCP. Вот краткое введение из IBM DeveloperWorks.
Честно говоря, я никогда не слышал о SCTP раньше. Я не помню, чтобы я читал об этом в каких-либо сетевых книгах или слышал об этом на занятиях, которые я посещал. Чтение других вопросов о стековом потоке, в которых упоминается SCTP, говорит о том, что я не одинок в этом недостатке знаний.
Почему SCTP так неизвестно? Почему это не так часто используется?
11 ответов
Действительно, 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/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), так что вы действительно часто его используете, но никогда не знаете об этом;-)
SCTP требует большего дизайна в приложении, чтобы наилучшим образом использовать его. Вариантов больше, чем TCP, Socket -подобный API появился позже, и он молодой. Однако я думаю, что большинство людей, которые тратят время на его понимание (и знают недостатки TCP), ценят это - это хорошо разработанный протокол, основанный на наших ~30-летних знаниях TCP и UDP.
Один из аспектов, который требует некоторого размышления, - это потоки. Потоки предоставляют (обычно, я думаю, вы можете отключить) гарантию порядка внутри них (во многом как TCP-соединение), но на SCTP-соединение может быть несколько потоков. Если данные вашего приложения могут быть отправлены по нескольким потокам, вы избегаете блокирования заголовка строки, когда приемник голодает из-за одного потерянного пакета. По одному и тому же соединению можно вести разные разговоры, не влияя друг на друга.
Еще одним полезным дополнением является поддержка множественной адресации - одно соединение может быть подключено к нескольким интерфейсам на обоих концах, и оно справляется со сбоями. Вы можете эмулировать это в TCP, но на уровне приложений.
Правильное сердцебиение канала связи, которое является первым, что любое приложение, использующее TCP для нестационарных соединений, доступно бесплатно.
Моя личная сводка по SCTP - это то, что он не делает ничего, что вы не могли бы сделать другим способом (в TCP или UDP) с существенной поддержкой приложений. Он предоставляет возможность не реализовывать этот код (плохо) самостоятельно.
К вашему сведению, SCTP предписан как поддерживается для Diameter (ср. RADIUS следующего поколения). см. RFC 3588
Клиенты Diameter ДОЛЖНЫ поддерживать TCP или SCTP, а агенты и серверы ДОЛЖНЫ поддерживать оба. Будущие версии этой спецификации МОГУТ требует, чтобы клиенты поддерживали SCTP.
p1. SCTP, сопоставленный напрямую по IPv4, требует поддержки в шлюзах NAT, которые никогда нигде не были широко развернуты, и без него типичный шлюз NAT будет позволять использовать только один частный хост для каждого публичного адреса за один раз.
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-data-channel-13
Читая страницу SCTP Wikipedia, я бы сказал, что основная причина в том, что SCTP - очень молодой протокол (предложенный в 2000 году), который в настоящее время не поддерживается основными операционными системами (Windows, OS X, Linux).
Если "очень молодой" кажется вам неуместным, подумайте об IPV6: "В декабре 2008 года, несмотря на то, что 10-летний юбилей был отмечен как протокол отслеживания стандартов, IPv6 был только в зачаточном состоянии с точки зрения общего развертывания по всему миру".
SCTP широко используется в сети 4G LTE, где Diameter используется для AAA.
Что касается всех комментариев о том, что коммерческие маршрутизаторы сломаны или им не хватает поддержки SCTP, проблема заключается в том, что SCTP с NAT все еще находится в черновом варианте с IETF. Поэтому для них не существует спецификации RFC.
Sctp рождается слишком поздно, и для многих ситуаций достаточно TCP.
Кроме того, насколько я знаю, большая часть его использования в области телекоммуникаций.