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

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?

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.

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.

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.

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 ;-)

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.

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

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”.

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

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 .

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

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

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