Чому 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, API-подібний Sockets з'явився пізніше, і він молодий. Однак я думаю, що більшість людей, які потребують часу, щоб зрозуміти це (і які знають недоліки TCP) цінують це - це добре розроблений протокол, який базується на наших 30-річних знаннях TCP та UDP.

Один із аспектів, який потребує певної думки, - це потоки. Потоки надають (як правило, я думаю, ви можете вимкнути його) гарантію замовлення всередині них (приблизно як з'єднання TCP), але може бути декілька потоків на з'єднання SCTP. Якщо дані вашої програми можуть надсилатися через декілька потоків, то ви уникаєте прямого блокування, де приймач голодує через один неправильно введений пакет. Ефективно різні розмови можна проводити через один і той же зв’язок, не впливаючи один на одного.

Ще одним корисним доповненням є підтримка мультиварки - одне з'єднання може бути через декілька інтерфейсів на обох кінцях, і воно справляється з відмовами. Емулювати це можна в TCP, але на рівні програми.

Належне серцебиття, яке перше, що будь-яке додаток, що використовує TCP для непрохідних з’єднань, існує безкоштовно.

Моє особисте резюме SCTP полягає в тому, що він не робить нічого, чого не вдалося б зробити іншим способом (в TCP або UDP) за допомогою суттєвої підтримки додатків. Що вона надає - це можливість не потрібно самостійно реалізовувати цей код.

FYI, SCTP призначений для підтримки діаметра (див. RADIUS наступного покоління). див. RFC 3588

   Клієнти діаметру ОБОВ'ЯЗКОВО підтримують TCP або SCTP, а агенти та
   Сервери ОБОВ'ЯЗКОВО підтримують обоє. Майбутні версії цієї специфікації МОЖУТЬ
   мандат клієнтів підтримувати SCTP.

SCTP не дуже відомий і не використовується / розгортається багато, тому що:

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

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

р2. 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 # section-6

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

Якщо "дуже молодий" здається вам невідповідним, подумайте про IPV6 : "У грудні 2008 року, незважаючи на відзначення своєї 10-ї річниці як протокол стандартів відстеження, IPv6 був лише у зародковому стані з точки зору загального поширення у всьому світі".

SCTP широко використовується в мережі 4G LTE, де Діаметр використовується для AAA.

Це може бути невідомо, але воно не використовується. Зовсім недавно в IETF був опублікований проект про використання SCTP як протоколу транспортного шару для HTTP .

Посилаючись на всі коментарі щодо того, що комерційні маршрутизатори порушені або їм не вистачає підтримки SCTP, проблема полягає в тому, що SCTP з NAT досі перебуває у формі проекту з IETF. Тому для них не існує специфікації RFC.

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

Sctp народжується надто пізно, і для багатьох ситуацій TCP достатньо.

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