Dlaczego SCTP nie jest często używany / znany?

190

Niedawno sprawdziłem książkę Richarda Stevensa „Programowanie sieciowe UNIX, tom 1” i odkryłem, że oprócz TCP i UDP: SCTP istnieje trzeci standard warstwy transportowej .

Podsumowanie: SCTP jest protokołem na poziomie transportu, opartym na komunikatach, takim jak UDP, ale niezawodny, jak TCP. Oto krótkie wprowadzenie z IBM DeveloperWorks .

Szczerze mówiąc, nigdy wcześniej nie słyszałem o SCTP. Nie pamiętam, aby czytać o tym w książkach o sieciach lub słyszeć o tym na zajęciach, które wziąłem. Czytanie innych pytań o przepełnieniu stosu, które wspominają o SCTP, sugeruje, że nie jestem sam z tym brakiem wiedzy.

Dlaczego SCTP jest tak nieznany? Dlaczego nie jest często używany?

dmeister
źródło
4
+1 nigdy o tym nie słyszałem - dzięki.
Robert Venables,
1
Każdy chce porównać SCTP do ZeroMQ (poza tym, że jeden jest protokołem, drugi biblioteką - spójrz na nie jako na narzędzie do rozwiązywania problemów).
Emil Iwanow
Jestem tylko ciekawy: co jest złego / innego w dniu 01.03.2013? Dlaczego tyle głosów w tym dniu?
dmeister
8
@dmeister: Ponieważ postawiłem cię na Reddit . Pozdrowienia z Darmstadt.
Janus Troelsen
32
Proszę nie pisać 01.03.2013. Preferowany jest dowolny z „1 marca 2013 r.”, „1 marca 2013 r.”, „1 marca 2013 r.”. Po prostu nie pisz miesiąca i dnia miesiąca w sposób, który może być źle interpretowany.
Zecc

Odpowiedzi:

94

Rzeczywiście, SCTP jest używany głównie w obszarze telekomunikacji. Tradycyjnie przełączniki telekomunikacyjne używają SS7 ( System Sygnalizacji nr 7 ) do łączenia różnych podmiotów w sieci telekomunikacyjnej. Na przykład - baza danych abonentów operatora telekomunikacyjnego (HLR), z przełącznikiem (MSC), abonent jest również podłączony (MSC).

Obszar telekomunikacyjny przechodzi do wyższych prędkości i bardziej osiągalnego środowiska. Jedną z tych zmian jest zastąpienie protokołu SS7 bardziej eleganckim, szybkim i elastycznym protokołem opartym na protokole IP.

Obszar telekomunikacyjny jest bardzo konserwatywny. Sieć SS7 jest tu używana od dziesięcioleci. Jest to bardzo niezawodna i zamknięta sieć. Oznacza to, że zwykły użytkownik nie ma do niego dostępu.

W przeciwieństwie do tego sieć IP jest otwarta i nie jest niezawodna, a telekomunikacja nie będzie na nią konwertowana, jeśli nie poradzi sobie przynajmniej z obciążeniem obsługiwanym przez SS7. Właśnie dlatego opracowano SCTP. Próbuje:

  • aby naśladować wszystkie zalety sieci SS7 nagromadzonej przez dziesięciolecia.
  • aby stworzyć protokół zorientowany na połączenie lepiej niż TCP pod względem szybkości, bezpieczeństwa i redundancji

Najnowsze wersje Linuksa mają już obsługę SCTP.

dimba
źródło
w szczególności powinieneś przyjrzeć się wynikom grupy roboczej „SIGTRAN” IETF, która napisała mapowanie między SS7 a SCTP.
Alnitak,
22
Prawdopodobnie głównym powodem, dla którego SCTP nie jest często używany w publicznym Internecie, jest fakt, że domowe bramy IPv4 / NAT muszą być świadome SCTP, aby obsługiwać powiązania multipleksowania między wieloma prywatnymi punktami końcowymi i hostami zewnętrznymi. Poszukaj SCTP, aby stał się bardziej użyteczny, gdy przejście IPv6 zacznie zbierać więcej pary.
James Woodyatt,
@ jameswoodyatt istnieją biblioteki implementacji SCTP przez UDP. Rozwiązuje niektóre problemy z routerami klasy konsumenckiej.
user7610,
1
To w ogóle nie odpowiada na pytanie. Odpowiedź Jamesa zawiera więcej informacji niż odpowiedź.
Ken Sharp
@jameswoodyatt Routery klasy konsumenckiej, z którymi pomieszałem, obsługują tę funkcję, nawet niektóre dość stare. Problem polega na tym, że nie jest ujawniany przez zwykły interfejs użytkownika, więc musisz zrobić kilka okropnych rzeczy w systemie, aby dostać się tam, gdzie możesz go skonfigurować. Moim zdaniem coś w rodzaju niedopatrzenia.
Perkins,
70

Wdrażamy SCTP w kilku aplikacjach i napotkaliśmy poważny problem z obsługą SCTP w różnych routerach domowych. Po prostu nie obsługują SCTP poprawnie. Uważam, że jest to przede wszystkim problem z wydajnością (specyfikacja protokołu SCTP wymaga sum kontrolnych do ponownego obliczenia całych pakietów, a nie tylko nagłówków).

Podobnie jak wiele innych obiecujących protokołów, SCTP jest niestety martwy w wodzie, dopóki D-link i Netgear nie naprawią swoich uszkodzonych pól NAT.

pehrs
źródło
7
Wow, nie byłem świadomy tej bariery wejścia. Masz całkowitą rację - zobacz narzędzia.ietf.org/ html/draft-ietf-behave-sctpnat-05, aby uzyskać propozycję obejścia tego problemu . To trzeci zestaw
szkiców
Brzmisz dość pesymistycznie - przynajmniej dla domowych routerów. Zakładając, że routery używane w profesjonalnych środowiskach produkcyjnych to obsługują, SCTP nadal wygląda bardzo przydatnie. Istnieje wiele przypadków użycia, w których topologie sieci nie opuszczają siedziby centrum danych, w którym to przypadku SCTP powinien być idealny.
Eugene Beresovsky
4
@EugeneBeresovksy: Minęło kilka lat, odkąd opublikowałem tę odpowiedź. Mam wrażenie, że od tego czasu SCTP nie poczyniło znaczących postępów. Jest nadal używany w kilku specjalistycznych aplikacjach w kontrolowanych środowiskach, ale rzadko spotykany na wolności. W systemach Windows i Mac OS X nadal brakuje obsługi SCTP od razu po wyjęciu z pudełka. Brak znajomości i kruchość protokołu złamanego przez większość zapór ogniowych i skrzynek NAT sprawia, że ​​ludzie niechętnie go używają.
pehrs
@pehrs Chciałbym używać go w centrum danych, więc nie dotyczy to NAT i żadnych zapór ogniowych, z wyjątkiem tych wbudowanych w system operacyjny. Mam nadzieję, że w środowisku serwera Linux to po prostu działa. Ale nawet w systemie Windows istnieją biblioteki SCTP - i uważam, że nie muszę majstrować przy systemie operacyjnym.
Eugene Beresovsky
SCTP zwykle nie jest włączony w Linuksie z powodu jego braku adaptacji, ale nawet w moim (starym) systemie Ubuntu Precise jest dostępny jako moduł ładowalny. Zapewnienie aplikacji, która chce korzystać z SCTP, ale wróci do TCP (na przykład), jest problemem podobnym do podwójnego układania w stosy, ale bardziej bolesnym.
Ken Sharp
55

SCTP wymaga więcej projektowania w aplikacji, aby jak najlepiej go wykorzystać. Jest więcej opcji niż TCP, API podobne do Sockets pojawiło się później i jest młode. Myślę jednak, że większość osób, które go rozumieją (i znają wady protokołu TCP), docenia to - jest to dobrze zaprojektowany protokół, który opiera się na naszej ~ 30-letniej wiedzy na temat TCP i UDP.

Jednym z aspektów wymagających przemyślenia jest kwestia strumieni. Strumienie zapewniają (zazwyczaj myślę, że można to wyłączyć) gwarancję zamówienia w nich (podobnie jak połączenie TCP), ale może istnieć wiele strumieni na połączenie SCTP. Jeśli dane Twojej aplikacji mogą być przesyłane wieloma strumieniami, unikniesz blokowania linii, w której odbiornik głoduje z powodu jednego zagubionego pakietu. Efektywnie różne rozmowy można prowadzić przez to samo połączenie, nie wpływając na siebie nawzajem.

Kolejnym przydatnym dodatkiem jest obsługa wielu baz danych - jedno połączenie może być realizowane przez wiele interfejsów na obu końcach i radzi sobie z awariami. Możesz to emulować w TCP, ale w warstwie aplikacji.

Prawidłowe bicie serca łącza, które jest pierwszą rzeczą, w której każda aplikacja korzystająca z TCP do implementacji połączeń nie-przejściowych jest dostępne za darmo.

Moje osobiste podsumowanie SCTP jest takie, że nie robi nic, czego nie można zrobić w inny sposób (w TCP lub UDP) przy znacznej obsłudze aplikacji. Zapewnia to możliwość samodzielnego wdrażania tego kodu (źle).

FYI, SCTP jest wymagane jako obsługiwane dla Diameter (patrz RADIUS następnej generacji). patrz RFC 3588

   Klienci obsługujący średnice MUSZĄ obsługiwać protokół TCP lub SCTP, podczas gdy agenci i
   serwery MUSZĄ obsługiwać oba. Przyszłe wersje tej specyfikacji MAY
   upoważnić klientów do obsługi SCTP.
Bwooce
źródło
43

SCTP nie jest bardzo znany i nie jest często używany / wdrażany, ponieważ:

  • Rozpowszechnione: niezbyt zintegrowane ze stosami TCP / IP (w 2013 r. Nadal natywnie brakuje w najnowszych systemach Mac OSX i Windows)
  • Biblioteki: Niewiele powiązań wysokiego poziomu w łatwych w użyciu językach (Oświadczenie: jestem opiekunem pysctp , obsługa łatwego stosu SCTP dla Pythona)
  • NAT: Nie przepuszcza NAT bardzo dobrze / wcale (mniej niż 1% domowych routerów domowych i korporacyjnych robi NAT na SCTP).
  • Popularność: nie korzysta z niej żadna aplikacja publiczna
  • Paradygmat programowania: trochę się zmienił: wciąż jest gniazdem, ale możesz połączyć wiele hostów z wieloma hostami (multihoming), datagram jest uporządkowany i niezawodny, erc ...
  • Złożoność: stos SCTP jest złożony do wdrożenia (ze względu na powyższe)
  • Konkurs: Nadchodzi Multipath TCP i powinien zaspokoić potrzeby / możliwości wielu użytkowników, aby ludzie w miarę możliwości powstrzymywali się od implementacji SCTP, czekając na MTCP
  • Nisza: Wymaga wypełnienia SCTP są bardzo specyficzne (uporządkowane niezawodne datagramy, wielostrumieniowe) i nie są potrzebne wielu aplikacjom
  • Bezpieczeństwo: SCTP wymyka się kontroli bezpieczeństwa (niektóre zapory ogniowe, większość IDS, wszystkie DLP, nie pojawiają się na netstat z wyjątkiem CentOS / Redhat / Fedora ...)
  • Możliwość audytu: Coś w rodzaju 3 firm na świecie rutynowo przeprowadza audyty bezpieczeństwa SCTP (Oświadczenie: Pracuję w jednej z nich)
  • Krzywa uczenia się: Niewiele narzędzi do zabawy z SCTP (sprawdź doskonały withsctp, który ładnie łączy się z netcat lub użyj socat)
  • Pod maską: używany głównie w telekomunikacji i za każdym razem, gdy wysyłasz SMS-y, zaczynasz surfować po sieci na telefonie komórkowym lub wykonujesz połączenia telefoniczne, często wywołujesz wiadomości przesyłane przez SCTP (SIGTRAN / SS7 z GSM / UMTS, średnica z LTE / IMS / RCS, S1AP / X2AP z LTE), więc właściwie go używasz, ale nigdy o tym nie wiesz ;-)
Phil L.
źródło
14
Odp: „Nisza / niepotrzebna przez wiele aplikacji”. Przeglądarki internetowe skorzystałyby na tym, zobacz HTTP2 i jego próby wdrożenia, oprócz TCP, części tego, co SCTP rozdaje za darmo. Większość technik optymalizacji HTTP (spriting, sharding, inline, konkatenacja) zostałaby (prawie całkowicie - marnotrawione nagłówki HTTP1 pozostają nierozwiązane) zbędna przez SCTP. to samo dotyczy aplikacji, które mają pulę połączeń, aby umożliwić równoczesny dostęp do bazy danych lub dowolnej innej usługi. Innymi słowy: Wiele aplikacji bardzo potrzebuje niektórych funkcji SCTP.
Eugene Beresovsky,
4
„Nie korzysta z niej żadna aplikacja publiczna”: To nieprawda, ponieważ WebRTC używa SCTP. „Bezpieczeństwo: SCTP wymyka się kontroli bezpieczeństwa” - to raczej problem kontroli bezpieczeństwa. Jeśli uniknie tych kontroli, byłoby cudownym protokołem dla złośliwego oprogramowania, aby pozostało pod radarem.
Maciej Piechotka,
14

p1. SCTP zmapowany bezpośrednio przez IPv4 wymaga wsparcia w bramach NAT, które nigdy wcześniej nie były szeroko wdrażane, a bez niego typowa brama NAT pozwoli tylko jednemu prywatnemu hostowi na adres publiczny używać SCTP jednocześnie.

p2. SCTP odwzorowany na UDP / IPv4 pozwala na więcej prywatnych hostów na adres publiczny, ale mapowania UDP w bramach IPv4 / NAT są niezwykle trudne do ustalenia i utrzymania, ponieważ UDP jest transportem bezpołączeniowym bez żadnego jawnego stanu dla NAT do śledzenia .

p3. SCTP zmapowany bezpośrednio przez IPv6 wymaga ... no cóż ... IPv6. Czy próbowałeś wdrożyć IPv6? Jeśli tak, to czy próbowałeś kupić zaporę IPv6? Czy obsługuje SCTP? Co powiesz na moduł równoważenia obciążenia? Akcelerator SSL?

p4. Wreszcie, duża część Internetu jest dość ograniczona do tego, co może zmieścić się przez port TCP 80 i port 443, więc SCTP o dowolnym smaku ma tendencję do utraty. Dlatego widzisz wysiłki takie jak grupa robocza MPTCP w IETF.

James Woodyatt
źródło
„próbowałeś kupić zaporę ogniową IPv6? Czy obsługuje SCTP” - zwykle swobodnie dystrybuowane iptables obsługuje je dobrze . Nie jestem facetem od sieci, więc nie mogę powiedzieć nic więcej.
Cześć Anioł
12

Wielu z nas wkrótce będzie używać SCTP, ponieważ jest on wykorzystywany przez kanały danych WebRTC do tworzenia niezawodnej warstwy podobnej do TCP na UDP - SCTP przez DTLS przez UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # sekcja-6

cjb
źródło
Zapomniałem wspomnieć, że głównym celem WebRTC jest połączenie strumieniowego przesyłania obrazu i dźwięku. Nie należy go wykorzystywać jako przekaźnika komunikatów. Usługi turn / ice / stun to kolejna część technologii, którą WebRTC obsługuje. Ale są to technologie, które wykorzystuje WebRTC. Te technologie nie są WebRTC.
TamusJRoyce
6

Czytając stronę Wikipedii SCTP , powiedziałbym, że głównym powodem jest to, że SCTP jest bardzo młodym protokołem (zaproponowanym w 2000 r.), Który obecnie nie jest obsługiwany przez główne systemy operacyjne ( Windows , OS X , Linux ).

Jeśli „bardzo młody” wydaje ci się nieodpowiedni, pomyśl o IPV6 : „w grudniu 2008 r., Pomimo oznaczenia jego 10-lecia protokołem Standard Track, IPv6 był dopiero w powijakach, jeśli chodzi o ogólne wdrożenie na całym świecie”.

IlDan
źródło
3
Zgodnie z artykułem Wikipedii, z którym się łączysz, SCTP jest zaimplementowany w systemach Linux, Solaris, FreeBSD, HP-UX i innych.
drrlvn
Połączony artykuł mówi teraz także, że działa na OS X i Windows.
dmeister 17.12.12
3

SCTP jest szeroko stosowany w sieci 4G LTE, w której Średnica jest używana dla AAA.

Lynne Patterson
źródło
2

Może nie jest dobrze znany, ale nie jest nieużywany. Całkiem niedawno na IETF opublikowano projekt dotyczący używania SCTP jako protokołu warstwy transportowej dla HTTP .

Mkoeller
źródło
2
Kiedy powiedziałeś „nieużywany”, pomyślałem o rzeczywistym użyciu protokołu. Ale podałeś tylko przykładowy dokument , który może potencjalnie doprowadzić do rzeczywistego wykorzystania w przyszłości.
Kissaki,
2

W odniesieniu do wszystkich komentarzy na temat przerwania komercyjnych routerów lub braku obsługi SCTP, problem polega na tym, że SCTP z NAT jest nadal w wersji roboczej z IETF. Dlatego nie ma specyfikacji RFC do ich wdrożenia.

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

Terry Bowling
źródło
-1

Sctp rodzi się za późno i dla wielu sytuacji wystarczy TCP.

Ponadto, jak wiem, większość jego wykorzystania jest w obszarze telekomunikacji.

Sam Liao
źródło