Názory k článku Transportní protokol SCTP

Nejak nechapu, jakou to ma vyhodu oproti nekolika paralelnim TCP spojenim. - ?

V clanku byly ocitovane tri:
- mensi rezie
- cookies
- vice IPs pri pretizeni

ad 1) STCP se asi bude pouzivat napr. na streamovani audio/video dat, takze tam je dost jedno, zda je hlavicka o par bajtu kratsi.
ad 2) To ma TCP take, viz SynCookies. Linux a dalsi to pri zahlceni pouzivaji, a tak jsou proti tomu typu utoku odolni.
ad 3) To je pekne, ale v podstate nikdo nebrani tomu, aby to TCP nedelalo take. Navic na strane serveru by to mohlo byt dost tezke to zaridit.

Jake to ma tedy vyhody oproti Nx TCP?

Pripominka 2 a 3 ma spolecny bod "to muze mit TCP take" - ano, to mate pravdu. Hacek je ale v tom, ze tento jeden z nejstarsich pouzivanych protokolu tyto vlastnosti proste NEMA. A pokud je tam chcete doplnit, jste vazan nutnosti naproste zpetne kompatibility. Proto je leckdy jednodussi navrhnout protokol novy - a stary, funkcni nechat zit tak jak je.

Co se tyce SynCookies, jde samozrejme pekny, lec ponekud kontroverzni vynalez. Pouziva ho v teto chvili pouze Linux (a tusim, ze i tam je default OFF) a z vami zminenych "dalsich" pak uz jen OS/2 Warp 4. Problemem je neschopnost negociace (nekterych) TCP options, ztrata "backlogu" a s tim souvisejici potencialni chybne reakce zatizenych serveru (obe vyhrady se uplatni jen v okamziku kdy SynCookies ochrana zrovna pusobi) a dale snizuji nahodnost prvotnich sekvencnich cisel, ktera jsou dulezitou soucasti bezpecnosti (tu snizuji vzdy, tedy nejen v okamziku probihajiciho utoku). V kazdem pripade jde o vlastnost, ktera odstranuje nektere negativni vlastnosti TCP protokolu za cenu vnaseni njinych a co hur, za cenu vnaseni urciteho prvku nekompatibility - a to je vec, na kterou pravdepodobne nelze pristoupit. K upravam celosvetove uzivaneho protokolu, jimz TCP rozhodne je je potreba pristupovat s maximalni konzervativnosti a tak je jen spravne, ze se autori pro takovehle zmeny rozhodli jit cestou vytvoreni protokolu noveho.

Výhodami by měla být hlavně vyšší spolehlivost a nižší zatížení zúčastněných strojů.

Více IP adres cíle neslouží k rozkládání provozu při přetížení, ale k zajištění větší spolehlivosti - pokud některá neodpovídá, použije jinou. K rozkládání provozu nemá SCTP potřebné informace.

Jako menší režie nebylo ani tak míněno pár bajtů v hlavičkách, ale spíše zpracování na koncích. Představte si dvě aplikace, které si vyměňují informace po deseti navzájem nezávislých kanálech. Když to uděláte jedním TCP spojením a kanály budete rozlišovat na úrovni aplikačních dat, zpoždění (opakování) jednoho paketu způsobí zpoždění všech kanálů.

Když navážete pro každý kanál jedno TCP spojení, získáte jejich vzájemnou nezávislost, ale spotřebujete alespoň na jedné straně 10 portů (TCP spojení je identifikováno čtveřicí: IP zdroje, port zdroje, IP cíle, port cíle) a na každé straně bude pracovat desetkrát algoritmus zajišťující spolehlivost - tedy buffery, okénka, časovače a veškerý cirkus kolem nich, což je nezanedbatelné zatížení.

Naproti tomu u SCTP jsou kanály odlišovány a "znezávisleny" na úrovni SCTP. Zpoždění paketu se dotkne jen kanálů, jejichž data v něm byla obsažena. Mechanismus zajišťující spolehlivost a opakování ztracených paketů je jen jeden, společný pro celou SCTP asociaci.

Čili teoretický smysl to jistě má, i když je podobnost s TCP dost značná. Jak (zda) se SCTP osvědčí v praxi se dá v současnosti jen těžko odhadovat. To ukáží až zkušenosti.