SCTP

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2017. március 12-én felülvizsgált verziótól ; az ellenőrzések 34 szerkesztést igényelnek .

Az SCTP ( angolul  Stream Control Transmission Protocol  - „átviteli protokoll áramlásvezérléssel”) egy szállítási réteg protokoll a számítógépes hálózatokban , amely 2000-ben jelent meg az IETF -ben . Az RFC 4960 leírja ezt a protokollt, az RFC 3286 pedig technikai bevezetést nyújt hozzá.

Mint minden más szállítási réteg protokoll, az SCTP is hasonlóan működik, mint a TCP vagy az UDP [1] . Újabb protokollként az SCTP számos újítást tartalmaz, mint például a többszálú védelem, a DDoS támadások elleni védelem, a szinkron kapcsolat két gazdagép között két vagy több független fizikai csatornán keresztül (multi-homing).

Biztonságos kapcsolat létrehozása

Az új kapcsolat létrehozása a TCP és SCTP protokollokban a csomagok nyugtázási (kézfogási) mechanizmusával történik. A TCP protokollban ezt az eljárást háromutas kézfogásnak nevezik. A kliens egy SYN (rövidített szinkronizálás) csomagot küld. A szerver SYN-ACK (Synchronize-Acknowledge) csomaggal válaszol. A kliens egy ACK csomaggal nyugtázza a SYN-ACK csomag fogadását. Ezzel befejeződik a kapcsolat létrehozási folyamata.

A TCP potenciális biztonsági rést rejt magában, ahol a támadó több SYN-csomagot küldhet a szervernek hamisított forrás IP-címek beállításával. A SYN-csomag fogadásakor a szerver lefoglal néhány erőforrást egy új kapcsolat létrehozásához. Sok SYN-csomag feldolgozása előbb-utóbb a szerver összes erőforrását igényli, és lehetetlenné teszi az új kérések feldolgozását. Ezt a fajta támadást " SYN árvíznek " (SYN flood) hívják.

Az SCTP protokollt négyirányú kézfogási mechanizmus és token (cookie) bevezetése védi az ilyen támadásokkal szemben. Az SCTP-ben a kliens egy INIT-csomag elküldésével indítja el a kapcsolatlétesítési eljárást. Válaszul a szerver egy tokent (egyedi kulcsot, amely azonosítja az új kapcsolatot) tartalmazó INIT-ACK csomagot küld. Az ügyfél ezután egy COOKIE-ECHO csomag elküldésével válaszol, amely tartalmazza a szervertől kapott tokent. A szerver csak ezután osztja ki erőforrásait az új kapcsolathoz, és ezt egy COOKIE-ACK csomag elküldésével erősíti meg a kliensnek.

Az adatátviteli késleltetés problémájának megoldása érdekében az SCTP protokollban a négyirányú kézfogási eljárás végrehajtása során megengedett az adatok COOKIE-ECHO és COOKIE-ACK csomagokba való felvétele.

Az adatátvitel fokozatos megszüntetése

Nézzük meg a különbségeket az SCTP socket zárási eljárás és a TCP félzárási eljárás között.

A TCP protokollban akkor lehetséges a részleges kapcsolatlezárás, amikor az egyik csomópont befejezte az adatátvitelt (FIN-csomag küldésével), de továbbra is fogad adatokat ezen a kapcsolaton. A másik csomópont addig folytathatja az adatátvitelt, amíg a kapcsolatot meg nem zárja a saját oldalán. A részleges zárási állapotot ritkán használják az alkalmazások, ezért az SCTP protokoll fejlesztői szükségesnek tartották egy üzenetsorozatra cserélni, hogy megszakítsák a meglévő társítást. Amikor egy csomópont bezárja socketjét (SHUTDOWN üzenetet küld), mindkét partnernek le kell állítania az adatátvitelt, csak a korábban elküldött adatok fogadását nyugtázó csomagok cseréjét engedélyezve.

Többszálú

A TCP kezeli a bájtsorozatot : a küldő alkalmazás által küldött adatoknak pontosan ugyanabban a sorrendben kell megérkezniük a fogadó alkalmazásba (miközben az IP-protokoll képes megfordítani a csomagok sorrendjét; emellett a hiányzó csomagok újraküldésre kerülnek, és általában megérkeznek a címzetthez soron kívül; az adatok pufferelésre kerülnek e jelenségek leküzdésére). Az SCTP két pont ( csomópont ) között képes egyidejűleg adatokat szállítani több üzenetfolyamon keresztül . A TCP -vel ellentétben az SCTP teljes üzeneteket dolgoz fel (megőrzi az üzenethatárt), nem pedig közönséges információbájtokat . Ily módon az SCTP hasonló az UDP-hez. Így ha a feladó első lépésben egy 100 bájtból álló üzenetet küld a szervernek , amit további 50 bájt követ, akkor az első lépésben a címzett pontosan az első üzenet első 100 bájtját kapja meg, és csak ezután 50 bájtot. a második olvasási művelet a foglalatból .

A "multithreading" (eng. multi-streaming ) kifejezés az SCTP azon képességére utal, hogy párhuzamosan tud több független üzenetfolyamon keresztül továbbítani . Például egy HTTP - alkalmazáson ( például egy böngészőn ) keresztül több fényképet is továbbítunk . Ehhez több TCP -kapcsolatot is használhatunk, de elfogadható egy SCTP-társítás (eng. SCTP Association ), amely több üzenetfolyamot kezel erre a célra. Az adatfolyamok egyirányúak, vagyis csak egy irányba továbbítanak információt ( a fenti kép pontatlan ).

A TCP úgy éri el a megfelelő bájtsorrendet egy adatfolyamban, hogy absztrakt módon sorszámot rendel minden egyes elküldött egységhez, és a fogadott bájtokat a hozzárendelt sorszámok felhasználásával rendeli, ahogy megérkeznek. Másrészt az SCTP különböző sorszámokat rendel az adott adatfolyamon küldött üzenetekhez . Ez lehetővé teszi az üzenetek független rendezését a különböző szálakon. Egyébként a többszálú opció az SCTP-ben. A felhasználói alkalmazás kívánságától függően az üzenetek nem a küldésük sorrendjében, hanem a beérkezésük sorrendjében dolgozhatók fel.

Előnyök

Az SCTP használatának előnyei a következők:

Az előny részben abból fakad, hogy az SCTP eredeti fejlesztői úgy tervezték a protokollt, hogy IP -n keresztül továbbítsa a telefonálást ( SS7 ) .


Hátrányok

Biztonság

Az SCTP-t néhány szolgáltatással a biztonság javítása érdekében tervezték, például a "4x handshake"-t (a TCP "3x handshake"-jával szemben) a SYN árvíztámadások megelőzésére , valamint a nagyméretű cookie -kat az asszociációs hitelesítéshez.

A megbízhatóság volt az egyik kulcsfontosságú szempont az SCTP protokoll biztonsági tervezésében. A több-homing lehetővé teszi, hogy egy társítás nyitva maradjon még akkor is, ha a használt útvonalak és interfészek némelyike ​​elérhetetlenné válik. Ez különösen fontos a SIGTRAN számára , amely SCTP-t használ az SS7 protokollüzenetek és -szolgáltatások IP-hálózaton keresztüli továbbítására, ami erős rugalmasságot igényel a kapcsolatkimaradások során a távközlési szolgáltatások fenntartásához, még súlyos hálózati anomáliák esetén is.

A titkosítás nem része az SCTP eredeti tervének.

Bizonyos esetekben az SCTP alkalmas TCP /IPEnnek oka az a tény, hogy egyes operációs rendszereket az SCTP protokoll támogatásával terjesztenek, de annak kevéssé ismertsége miatt (a TCP-hez vagy UDP-hez képest) a rendszergazdák néha elfelejtik beállítani a behatolásészlelést a tűzfalban , ami lehetővé teszi a átvizsgálja a forgalmat.

A szállítási réteg protokolljainak képességeinek összehasonlítása

Paraméter UDP TCP SCTP
Kapcsolat létrehozása Nem Igen Igen
Megbízható sebességváltó Nem Igen Igen
Üzenethatárok megőrzése Igen Nem Igen
rendezett szállítás Nem Igen Igen
Rendeletlen szállítás Igen Nem Igen
Adatellenőrző összegek Igen Igen Igen
Ellenőrzőösszeg mérete (bit) 16 16 32
Útvonal MTU Nem Igen Igen
Felhalmozás kezelése Nem Igen Igen
Többszálú Nem Nem Igen
Több interfész támogatása Nem Nem Igen
Egy csomó szál Nem Igen Igen

Üzenet keretezése

Üzenetkeretek kialakításakor az üzenethatárok megőrződnek abban a formában, ahogy azt a sockethez továbbítják; ez azt jelenti, hogy ha a kliens 100 bájtot, majd 50 bájtot küld a szervernek, akkor a szerver 100 bájtot és 50 bájtot vesz fel két olvasásként. Az UDP protokoll pontosan ugyanúgy működik, ez az üzenetorientált protokollok jellemzője.

Ezzel szemben a TCP protokoll strukturálatlan bájtfolyamot kezel. Ha az üzenetkeretezési eljárást nem használják, akkor a hálózati csomópont olyan adatokat fogadhat, amelyek nagyobbak vagy kisebbek az elküldött adatoknál. Ez a működési mód megköveteli, hogy a TCP-n futó üzenetorientált protokollok esetében egy dedikált adatpuffert biztosítsanak az alkalmazási rétegben, és el kell végezni az üzenetek keretezését (potenciálisan összetett feladat).

Az SCTP protokoll keretezést biztosít az adatátvitelhez. Amikor egy csomópont egy socketbe ír, a partnere garantáltan azonos méretű adatblokkot kap.

Csomag szerkezete

bitek 0-7 bitek 8-15 16-23 24-31
+0 Forrás port Uticél kikötője
32 Érvényesítési címke
64 Ellenőrző összeg
96 Típus 1 blokk Zászlók 1 blokk Hossza 1 blokk
128 1 blokk adat
N típusú blokk Blokk N zászló A blokk hossza N
N adat blokkolása

Az SCTP-csomagok felépítése egyszerűbb, mint a TCP-csomagoké. Minden csomag két fő részből áll:

  1. Általános fejléc, amely az első 12 bájtot foglalja el (kék színnel kiemelve)
  2. Adatblokkok, amelyek a csomag fennmaradó részét foglalják el.

Az első blokk zölddel, az utolsó N blokk (N blokk) pirossal van kiemelve.

Minden blokknak van egy típusazonosítója, amely egy bájtot foglal el. Így maximum 255 különböző blokktípus definiálható. Az RFC 4960 meghatározza a blokktípusok listáját, jelenleg összesen 15 típussal. A blokk többi része egy 2 bájtos hosszúságú mezőből áll (a mező maximális hossza 65535 bájt), és valójában az adatokból áll. Ha a blokk mérete nem többszöröse 4 bájtnak, akkor nullákkal lesz kitöltve olyan méretig, amely 4 bájt többszöröse.

Hibakezelés

Újraadás

Az DATA blokkok újraküldésének oka lehet (a) az újraadási időzítő által meghatározott időtúllépés vagy (b) egy SACK fogadása, amely jelzi, hogy a célállomás nem vette meg az adatblokkot. A torlódások esélyének csökkentése érdekében az ADATblokkok újraküldése korlátozott. Az újrapróbálkozási időtúllépés (RTO) értéke a becsült oda-vissza úti idő alapján kerül beállításra, és az üzenetvesztés mértékének növekedésével exponenciálisan csökken. A csaknem állandó DATA forgalommal rendelkező aktív társítások esetén az újrapróbálkozás oka valószínűleg SACK üzenetek, nem pedig időtúllépés. A szükségtelen újrapróbálkozások valószínűségének csökkentése érdekében a 4 SACK szabályt alkalmazzák, amely szerint az újraküldés csak a negyedik SACK-en történik, jelezve, hogy egy adatblokkot kihagytak. Ez megakadályozza a nem megfelelő kézbesítés okozta újraküldést.

Baleset az úton

A rendszer egy számlálót tart fenn a sikeres kézbesítés megerősítése nélkül végrehajtott újrapróbálkozások számáról. Amikor ennek a számlálónak az értéke eléri a megadott küszöböt (konfigurációs paraméter), a cím inaktívvá válik, és az SCTP protokoll egy másik címet kezd el használni az ADATblokkok továbbítására. Ezenkívül a rendszer időszakonként speciális szívverés blokkokat küld az összes használaton kívüli (opcionális) címre, és számlálót tart fenn az elküldött szívverés blokkok számáról anélkül, hogy visszaküldené a megfelelő Heartbeat Ack-t. Amikor a számláló értéke elér egy adott küszöböt (konfigurációs paraméter), a megfelelő cím inaktívvá válik. A szívverés blokkokat a rendszer inaktív címekre továbbítja mindaddig, amíg egy Ack üzenet nem érkezik, amely jelzi, hogy a cím aktivitása helyreállt. A Heartbeat blokkok gyakoriságát az RTO érték és a további késleltetés határozza meg, amely lehetővé teszi a szívverés blokkok küldését a felhasználói forgalom zavarása nélkül.

Végponthiba

Valamennyi címzettnél közös számlálót tartanak fenn az ismétlések vagy Heartbeat blokkok számáról, az adatok egy távoli pontra kerülnek továbbításra anélkül, hogy onnan megfelelő megerősítést (Ack) kapnának. Amikor a számláló értéke eléri a megadott küszöbértéket (konfigurációs paraméter), a végpont elérhetetlenné válik, és az SCTP-társítás bezárul.

A

A TCP-protokoll biztosítja az adatok megbízható útvonalon történő továbbításának alapvető eszközeit az interneten . A TCP azonban bizonyos korlátozásokat ír elő az adatátvitelre:

Mindezek a korlátozások károsak az IP -n keresztüli telefonhálózatok teljesítményére .

A protokollt az IETF-en belül [2] egy speciálisan létrehozott SIGTRAN csoport munkájának részeként fejlesztették ki, hogy az SS-7 verem protokolljait és adaptációit implementálják IP-hálózatokban való használatra, a megbízható és gyors adattovábbítás szükségessége miatt. Ezt kifejezetten kimondja az RFC 4960 1.1 Motiváció fejezete :

...
A PSTN jelzés átvitele az IP-hálózaton egy olyan alkalmazás, amelyre a TCP valamennyi korlátozása vonatkozik. Míg ez az alkalmazás közvetlenül motiválja az SCTP fejlesztését, más alkalmazások találhatják az SCTP-t a saját követelményeiknek megfelelőnek... ... Az IP-hálózaton keresztüli PSTN

jelzés olyan alkalmazás, amelyre minden TCP-korlátozás közvetlenül vonatkozik. Noha ez közvetlenül motiválta az SCTP fejlesztését, más alkalmazások is találhatják az SCTP-t, hogy megfeleljen a követelményeknek... RFC 4960

SIGTRAN protokoll és adaptációs séma

Protokollok

OKS-7

   TCAP   
V5.2 MTP3 MTP3 ISUP    SCCP    DSS1    TCAP
SIGTRAN V5UA    M2UA    M2PA    M3UA    IUA    SUA
számítógépes hálózat SCTP
IP

Megvalósítások

Létezik egy referencia megvalósítás a FreeBSD, Mac OS X, Microsoft Windows és Linux számára [3] .

Az SCTP protokoll a következő operációs rendszereken valósul meg:

Megvalósítás harmadik féltől származó illesztőprogramokon keresztül:

Külön felhasználói könyvtárak:

Alkalmazások:

Jegyzetek

  1. A TCP és az UDP annyira eltérően működik, hogy nem helyes mindkettőhöz hasonlóságot vonni. Az egész analógia az, hogy az SCTP, a TCP és az UDP a TCP/IP-verem ugyanahhoz a rétegéhez tartozik.
  2. [Sigtran WG-akció: A jelzésátvitel (sigtran) lezárása] (a hivatkozás nem érhető el) . www.ietf.org. Letöltve: 2018. október 16. Az eredetiből archiválva : 2018. október 29. 
  3. Referencia megvalósítás az SCTP-RFC4960-hoz . - "Ez az SCTP referencia megvalósítása. Hordozható, és FreeBSD/MAC-OS/Windows alatt, valamint User Space-ben (beleértve a linuxot is) fut. Letöltve: 2013. október 14. Az eredetiből archiválva : 2017. március 1..
  4. A DragonFly eltávolítja az SCTP-t . Lists.dragonflybsd.org . Letöltve: 2016. április 28. Az eredetiből archiválva : 2017. augusztus 7..
  5. A FreeBSD technológiai fejlesztéseiről . A FreeBSD projekt (2008. március 9.). - "SCTP: A FreeBSD 7.0 az új IETF Stream Control Transmission Protocol (SCTP) protokoll referencia megvalósítása, amely VoIP, telekommunikációs és más alkalmazások támogatására szolgál, amelyek nagy megbízhatósággal és változó minőségű átvitellel rendelkeznek olyan funkciókon keresztül, mint például a többutas kézbesítés, hiba -over és multi-streaming.". Letöltve: 2008. szeptember 13. Az eredetiből archiválva : 2011. augusztus 5..
  6. Stream Control Transmission Protocol (SCTP) (a hivatkozás nem elérhető) . Hewlett-Packard Fejlesztési Társaság. Letöltve: 2017. március 10. Az eredetiből archiválva : 2013. január 3.. 
  7. TCP/IP hálózat . QNX fejlesztői támogatás . QNX szoftverrendszerek. Letöltve: 2008. szeptember 13. Az eredetiből archiválva : 2008. október 23.. Újdonságok ebben a hivatkozásban . QNX Library Reference . QNX szoftverrendszerek. Letöltve: 2012. december 18. Az eredetiből archiválva : 2012. október 18..
  8. Solaris 10 operációs rendszer hálózatkezelés – Extrém hálózati teljesítmény . Sun Microsystems . Letöltve: 2008. szeptember 13. Az eredetiből archiválva : 2009. április 20..
  9. SctpDrv: SCTP-illesztőprogram Microsoft Windowshoz (lefelé irányuló kapcsolat) . Letöltve: 2011. február 4. Az eredetiből archiválva : 2011. január 8.. 
  10. SCTP hálózati kernelbővítmény Mac OS X rendszerhez. Letöltve: 2017. március 10. Az eredetiből archiválva : 2018. június 11.
  11. Egy hordozható SCTP userland verem . Letöltve: 2017. március 10. Az eredetiből archiválva : 2018. december 20.
  12. SCTP letöltési oldal (2006. május 29.). Letöltve: 2011. február 4. Az eredetiből archiválva : 2019. április 22.
  13. Windows SCTP könyvtár telepítő . Letöltve: 2011. február 4. Az eredetiből archiválva : 2016. szeptember 11..
  14. Seggelmann, R.; Tuxen, M.; Rathgeb, EP SSH SCTP-n keresztül - Többcsatornás protokoll optimalizálása SCTP-hez való adaptálásával  // Kommunikációs rendszerek, hálózatok és digitális jelfeldolgozás (  CSNDSP), 2012 8. nemzetközi szimpózium : folyóirat. - 2012. - július 18. - P. 1-6 . — ISBN 978-1-4577-1473-3 . - doi : 10.1109/CSNDSP.2012.6292659 .

Linkek