Základy transportního protokolu TCP. Leoš Boháč

Transkript

1 Základy transportního protokolu TCP Leoš Boháč

2 Autor: Leoš Boháč Název díla: Základy transportního protokolu TCP Zpracoval(a): České vysoké učení technické v Praze Fakulta elektrotechnická Kontaktní adresa: Technická 2, Praha 6 Inovace předmětů a studijních materiálů pro e-learningovou výuku v prezenční a kombinované formě studia Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

3 VYSVĚTLIVKY Definice Zajímavost Poznámka Příklad Shrnutí Výhody Nevýhody

4 ANOTACE V architektuře TCP/IP plní nezastupitelnou funkci transportní protokoly, které poskytují programátorům síťových aplikací nezbytné služby. Protokol TCP patří v architektuře TCP/IP do skupiny nesložitějších a zároveň nejčastěji v praxi používaných transportních protokolů. TCP je schopen programátorům garantovat spolehlivý přenos libovolně dlouhé datové zprávy. Zároveň je schopen se vypořádat s případným vznikem přetížení datové cesty v síti a regulovat rychlost přenosu dat mezi vysílačem a přijímačem. CÍLE Cílem modulu je poskytnout studentům základní znalosti týkající se smyslu použití a funkce transportního protokolu TCP. LITERATURA [1] STEVENS, W. Richard. TCP/IP Illustrated : Vol. 1: The Protocols. [s.l.] : Addison- Wesley Professional, s. ISBN [2] KOZIEROK, Charles M. The TCP/IP Guide : A Comprehensive, Illustrated Internet Protocols Reference. San Francisco : No Starch Press, s. ISBN [3] DOYLE, Jeff; CARROLL, Jennifer. Routing TCP-IP : Volume I. 2nd ed. [s.l.] : Cisco Press, s. ISBN [4] ZININ, Alex. Cisco IP Routing : Packet Forwarding and Intra-domain Routing Protocols. [s.l.] : Addison Wesley Professional, s. ISBN

5 Obsah 1 Smysl a použití transportních protokolů v architektuře TCP/IP Přehled architektury TCP/IP Základy transportního protokoly UDP Vlastnosti a smysl použití UDP protokolu Základní vlastnosti transportního protokolu TCP Programovací primitivy pro přístup k transportním službám architektury TCP/IP Aplikační prostor a princip transportních soketů Princip soketové komunikace pro TCP protokol Popis funkce transportního protokolu Sekvenční čísla Formát TCP záhlaví Fáze navázání TCP spojení Fáze přenosu dat Princip přenosu pomocí okna Použití okna pro regulaci přenosu dat řízení toku Metoda multiplikativního potvrzování doručených segmentů Fáze ukončení spojení Metody řízení přetížení sítě u protokolu TCP Smysl řízení přetížení Metoda aditivního zvětšení a multiplikativního zmenšení okna přetížení Indikace přetížení u TCP přenosu Fáze pomalého růstu okna Fáze vyhýbání se přetížení Závěrečný test... 34

6 1 Smysl a použití transportních protokolů v architektuře TCP/IP 1.1 Přehled architektury TCP/IP Na obrázku je nakreslen model architektury TCP/IP (Transmission Control Protocol/Internet Protocol) a jeho srovnání s modelem RM OSI (Reference Model Open System Interconnection). Jak je patrné, jsou si oba modely velice podobné, avšak nejsou totožné. Vzhledem k tomu, že primárním úkolem Internetu a tedy s ním souvisejícím modelem TCP/IP bylo spíše propojení na úrovni sítí, než na úrovni koncových zařízení lokálně, nezabývá se TCP/IP problematikou definice dvou spodních vrstev RM OSI (fyzické a spojové). Původně se totiž předpokládalo, že TCP/IP bude nadstavbou nad již existujícími lokálními sítěmi v jednotlivých lokalitách a umožní jejich efektivní globální propojení mezi sebou. Cílem tedy nebylo definovat a vnucovat určitou konkrétní technologii LAN jednotlivým organizacím, ale jen vytvořit most, který by umožnil připojit do Internetu koncová zařízení různých lokálních technologií (např. Ethernet, Token Ring apod.) Architektura TCP/IP Sjednocujícím prvkem se stal jednotný formát IP paketu a taktéž principy, podle nichž se měly pakety přenášet mezi technologicky různými sítěmi od zdroje k cíli. V architektuře TCP/IP byla pro datový přenos zvolena metoda s negarantovaným doručením paketů bez nutnosti sestavovat spojení před přenosem dat. Tento princip byl zvolen s ohledem na technické možnosti technologií, které byly dostupné v době vzniku Internetu. Nikdo tehdy netušil, do jakých rozměrů se Internet vyvine v průběhu dalších let. TCP/IP architektura staví v první řadě na standardu IP protokolu, který dle RM OSI patří do vrstvy síťové.

7 Když se celý model podíváme jinak než jen technicky, tak je vidět, že je vše jedno velké logo, kde si návrhář sítě hraje s kostkami dílčích komponent, aby postavil jeden velký dům se jménem datová sít. V celé lego stavbě má vše svá jasná a opodstatněná místa, tak aby stavba nespadla a držela na pevných základech. Hrajme si, protože hraní je svobodným a nenuceným projevem lidské kreativnosti. 7

8 1.2 Základy transportního protokoly UDP Úkolem UDP (User datagram protokol) transportního protokolu je zajistit negarantovaný přenos dat, stejně jak je tomu při přenosu IP paketů. UDP však umožňuje použít jednu IP adresu cíle a zdroje pro přenos dat mezi více aplikacemi běžícími na koncových stanicích. Tuto možnost IP protokol v sobě integrovanou nemá. Tato vlastnost je velice důležitá u dnešních moderních koncových zařízení, která většinou pracují ve víceúlohovém režimu, kdy současně běží na stroji více aplikací současně. Aby bylo možné odlišit od sebe datové bloky patřící té či oné aplikaci/procesu, je nutné s nimi spojit identifikační informaci a tu přenášet společně v odpovídajících datových blocích sítí. Na protější straně lze díky ní snadno rozeznat, které aplikaci se mají data předat. Výše zmíněná informace může mít různou reprezentaci, nicméně v modelu TCP/IP bylo pro tento účel zavedené 16 bitové číslo. Aby bylo možné identifikovat i zdrojovou úlohu na straně vysílače, používá se toto číslo i pro zdrojovou aplikaci. V terminologii TCP/IP se tomuto číslu neřekne dnes jinak než číslo portu, viz obrázek Koncepce portů u transportních protokolů UDP a TCP 8

9 1.3 Vlastnosti a smysl použití UDP protokolu UDP protokol, kromě výše zmiňované identifikace portů, umožňuje: ověřit, zdali doručené datové segmenty jsou správně dlouhé, tj. zda nedošlo při přenosu k jejich zkrácení. UDP protokol k tomu používá pole délka, do něhož se na straně vysílací doplní celkové délka UDP segmentu, těsně před tím, než se segment pošle ke zpracování vrstvě IP umožňuje detekovat případný vznik chyb v rozšířeném záhlaví UDP segmentu, včetně uživatelských dat. Toto rozšířené záhlaví zahrnuje některá v průběhu přenosu neměnící se pole z IP paketu, jako je např. cílová a zdrojová adresa a některá další pole. Toto je vlastnost, která odlišuje UDP protokol od IP protokolu a posouvá komunikaci o další stupeň výše zasílat datové segmenty více koncovým stanicím současně. Tuto vlastnost dědí UDP od IP protokolu, který ji má také. Zde toto uvádíme pro úplnost, protože později zmiňovaný druhý transportní protokol TCP tuto vlastnost postrádá Důležité je se zmínit o tom, jaké služby UDP protokol poskytuje. Vzhledem k tomu, že většinu vlastností dědí po protokolu IP, neposkytuje stejně jako IP garantovaný přenos dat k protější cílové stanici. Pokud tedy programátor aplikace použije UDP protokol pro přenos dat své aplikace, musí být srozuměn s tím, že některá přenášená data ve formě UDP segmentů nemusí do cílové stanice dorazit. Důvodů nedoručitelnosti je několik, např. může dojít při přenosu k chybě nebo v některém z průběžných směrovačů, vzhledem k dočasnému přetížená, mohlo dojít k zahození paketů. UDP protokol je transportním protokolem síťové architektury TCP/IP, který poskytuje uživateli negarantovaný přenos dat globální sítí (typicky Internet) s možností identifikace aplikací pomocí čísel portů. Na rozdíl od IP umožňuje navíc provést na straně přijímače detekci případných chyb vzniklých při přenosu v záhlaví nebo i datové uživatelské části segmentu pomocí začleněného mechanismu kontrolního součtu. Otázkou ovšem je, zda mělo smysl navrhovat nespolehlivý protokol a k čemu je vlastně vhodný? Výhoda použití UDP pro přenos dat spočívá v jeho jednoduchosti. Pokud je cílem garantovat přenos dat, uvidíme později v souvislosti s transportním protokolem TCP, je nutné zajistit mnohem složitější funkci, včetně potvrzování přijatých datových segmentů přijímačem. Tato zpětná vazba průběžného potvrzování zvětšuje zpoždění přenosu dat a vnáší do komunikace zpoždění, které u některých aplikací může být více na škodu, než k užitku. U interaktivních služeb, jako je např. VoIP (telefonní služba s přenosem v datových sítích) je důležitější zachovat minimální zpoždění, než garantovat bezchybovost přenášených dat (digitalizovaný a většinou komprimovaný hlasový signál). Sporadická, chybná data se totiž v komunikaci většinou téměř slyšitelně neprojeví (třeba jen jako prasknutí) a jsou tedy méně významná, než velké 9

10 zpoždění, které výrazně ovlivní kvalitu této interaktivní služby uživatelé by si totiž při velkém zpoždění vzájemně skákali do konverzace a výrazně by toto chápali jako sníženou kvalitu hovoru. Vidíme tedy, že absolutní garance přenesených dat není vždy za každou cenu nezbytná u všech služeb. Uveďme nyní pravý opak. Služba přenosu souborů (např. FTP). Lze si snadno představit, k čemu by došlo, pokud bychom přenesli spustitelný soubor ze vzdáleného serveru s chybami a následně jej spustili. Vedlo by to určitě k nesprávné funkci programu. V tomto případě stahování datového spustitelného souboru je nám v zásadě lhostejné, jestli data budou mít při přenosu zpoždění místo 20 ms 200 ms, protože to na kvalitě služby (stažení souboru) prostě téměř nebo vůbec nepoznáme. Z výše uvedeného jednoduchého příkladu vyplývá, že každá aplikace nebo služba vyžaduje různé kvality transportu svých dat. Toto je jedním z důvodů, proč vývojáři architektury TCP/IP kdysi začlenili do standardů místo jednoho transportního protokolu rovnou dva. Tím druhým je TCP, který si vysvětlíme blíže v následující kapitole. 10

11 1.4 Základní vlastnosti transportního protokolu TCP Druhým v praxi velice často používaným protokolem z architektury TCP/IP je protokol TCP (Transmission Control Protocol). Hlavní motivací pro zavedení tohoto protokolu bylo zajistit spolehlivý přenos dat, tak aby programátor aplikace již nemusel řešit následující problémy, které při přenosu IP paketů mohou nastat: některé pakety nemusí do cílové stanice vůbec dorazit, protože protokol IP je koncipován od základu tak, že se data přenáší způsobem, kterému se v angličtině říká best effort, což lze volně přeložit, jako snaž se doručit, ale když se to z nějakého důvodu není možné, tak paket zahoď. Zde se jedná o zahození paketů v důsledku chyb v nich vzniklých vlivem fyzikálních podmínek přenosu. Žádný fyzický kanál není totiž za všech podmínek bezchybový protější stanice nemusí být schopna v daném okamžiku zpracovat velký objem generovaných dat stranou vysílací síť je přetížena a není schopna dočasně pakety přijímací stanici doručit, a tak je zahazuje někde podél (v uzlu sítě) cesty kcíli Z programátorského hlediska je toto velice významné, protože programátor aplikace se nemusí zabývat konkrétními otázkami systému přenosu v síti, pouze stačí předat TCP vrstvě ukazatel a délku dat v bajtech, které mají být předány cílové aplikaci. O vše ostatní se již postará protokol TCP. Připomeňme ještě jeden důležitý detail. U většiny dnešních operačních systémů programátor nepřistupuje k TCP vrstvě přímo, ale prostřednictvím softwarového rozhraní, kterému se říká sokety (sockets). I když se může na první pohled zdát, že je řešení výše uvedených problému triviální, není tomu tak. Protokol TCP je jedním z nejsložitějších protokolů z architektury TCP/IP. V průběhu let byl neustále vylepšován a jako celek je standardizován v mnoha dokumentech. Základní charakteristiky TCP protokolu jsou shrnuté na následujícím obrázku. Jedním z prvních a nejdůležitějších úkolů protokolu TCP je zajištění spolehlivého přenosu datového bloku konkrétní aplikace k aplikaci cílové. TCP protokol pracuje na 4. vrstvě RM OSI modelu a používá pro transport pakety níže v RM OSI modelu položeného protokolu IP, který nezaručuje jejich přenesení do cílové stanice. V případě nedoručení určitého počtu paketů k přijímací koncové stanici, není úkolem IP vrstvy tato data obnovit, naopak se předpokládá, že tuto funkci bude plnit protokol TCP. 11

12 Základní charakteristiky TCP protokolu Aby bylo možné garantovat bezchybný a ucelený přenos bloku dat dané aplikace, je nutné tento blok nejprve rozdělit do menších částí - segmentů, které musí být tak dlouhé, aby se každý z nich, včetně servisních informací, vešel do odpovídajícího IP paketu. Pro opětovné sestavení datového bloku na straně přijímače je zapotřebí znát, které ze segmentů nebyly doručené a které naopak ano. Je tedy nezbytné, aby každý vyslaný segment obsahoval kromě části dat aplikačního bloku ještě další identifikátor, který by jej jednoznačně odlišil od ostatních. Přijímací strana takto pozná, který segment z bloku dat chybí, podle chybějícího identifikátoru segmentu. 12

13 2 Programovací primitivy pro přístup k transportním službám architektury TCP/IP 2.1 Aplikační prostor a princip transportních soketů Služby transportních protokolů jako je TCP nebo UDP (není to však vázané jen na tyto protokoly) jsou dnes v moderních operačních systémech dostupné aplikacím prostřednictvím specializovaného programového rozhraní. Toto rozhraní používá představu transportních síťových zásuvek, zvaných sokety. Jedna transportní síťová zásuvka umožňuje přenos dat mezi danou aplikací a aplikacemi jinými a představuje jeden koncový bod komunikace. Způsob přenosu dat sítí skrze danou zásuvku je dán jejím typem, který úzce souvisí s protokolem, který se používá pro přenos. Zásuvka, či soket, může předávat data mezi aplikacemi, či procesy v rámci lokálního operačního systému nebo mezi vzdálenými operačními systémy přes datovou síť. Z pohledu soketu a daného procesu, který jej využívá, je lhostejné, jestli protější zásuvka komunikace je místní nebo vzdálená. Z obecného pohledu jsou sokety součástí aplikačního prostoru, který je vyznačen na následujícím obrázku. Aplikační prostor Soket je v rámci TCP/IP rodiny protokolů jednoznačně určen identifikátorem soketu, který je tvořen zřetězením následujícím údajů: 13

14 Indetifikátor soketu Komunikační okruh pro případ TCP protokolu je poté určen párem dvou koncových soketů/zásuvek, tak jak je naznačeno na následujícím obrázku. Párování soketů 14

15 2.2 Princip soketové komunikace pro TCP protokol Komunikace prostřednictvím TCP soketu je založena většinou na modelu komunikace klient/server. V tomto ohledu je vždy jedna TCP zásuvka pasivní a naslouchá na příchozí TCP spojení (viz další kapitoly) přicházející od TCP zásuvky aktivní. Většinou je tento princip spojený s aplikací využívají taktéž princip klient/server, např. služba WWW. V tomto případě WEB server naslouchá na příchozí spojení na pasivní zásuvce a daném portu (většinou 80) a klienti se k této zásuvce připojují. Způsob komunikace je naznačen na obrázku. Princip soketové komunikace Pokud má být zásuvka v pasivním, naslouchacím režimu, je nutné ji do tohoto stavu uvést sekvenčním voláním funkcí listen() a následně accept(), viz bod 3. Dlužno podotknout, že je nutné nejprve zásuvku datově vytvořit voláním funkce socket(), která vrátí referenci na tuto zásuvku ve formě čísla. Toto číslo se následně používá jako odkaz na zásuvku, pokud s ní chceme pracovat v dalších funkcích. Zásuvka, která bude hrát aktivní roli (na obrázku na levé straně) se spojí s pasivní zásuvkou pomocí funkce connect(), jejímiž parametry je referenční číslo na předem vytvořenou zásuvku a IP adresa s cílovým portem protější pasivní zásuvky. Po příchodu požadavku o navázání spojení na stranu pasivní se vrátí serverovému procesu přes funkci accept() referenční číslo na nově vytvořenou zásuvku (v našem případě 300), jíž použije proces na straně serveru ke komunikaci s aktivní stranou ve funkcích zápisu a čtení dat (write() a recv()). Původní zásuvka (reference 100) se používá jen pro příjem požadavků, nikoliv pro samotný přenos dat. 15

16 3 Popis funkce transportního protokolu 3.1 Sekvenční čísla Aby bylo možné garantovat bezchybný a ucelený přenos bloku dat dané aplikace, je nutné tento blok nejprve rozdělit do menších částí - segmentů, které musí být tak dlouhé, aby se každý z nich, včetně servisních informací, vešel do odpovídajícího IP paketu. Pro opětovné sestavení datového bloku na straně přijímače je zapotřebí znát, které ze segmentů nebyly doručené a které naopak ano. Je tedy nezbytné, aby každý vyslaný segment obsahoval kromě části dat aplikačního bloku ještě další identifikátor, který by jej jednoznačně odlišil od ostatních. Přijímací strana takto pozná, který segment z bloku dat chybí, podle chybějícího identifikátoru segmentu. TCP protokol pro identifikaci vysílaných datových segmentů standardně používá celé binární 32 bitové číslo, které se průběžně mění u každého vysílaného segmentu. Mějme však na paměti, že toto číslo není pořadovým číslem vyslaného segmentu, tak jak je tomu u některých jiných protokolů, ale přímo ukazatel místa v datovém bloku aplikace, jehož součástí segment je. To je také důvod, proč se mu říká sekvenční číslo (pro další výklad budeme toto číslo označovat jako sek ). Tuto situace se snaží přiblížit následující obrázek. Upřesněme, že zmiňované sekvenční číslo (ukazatel) ukazuje na bajty v datovém bloku aplikace, nikoliv na jednotlivé bity. Sekvenční číslo u TCP protokolu udává, jakou má relativní pozici první bajt daného segmentu vzhledem k počátku datového bloku aplikace, jež má TCP vrstva za úkol přenést. Relativností je zde míněno to, že první bajt datového bloku aplikace nemusí začínat číslem nula, ale číslem libovolným (viz obrázek, číslo ISN+1), k němuž se začátek vztahuje. Vztah datového bloku aplikace a vysílaných segmentů 16

17 Jak již bylo řečeno, aby byl přijímač schopen rozpoznat, který ze segmentů chybí v bloku aplikačních dat nebo dokonce, které byly přijaté duplicitně (viz dále), musí být každý segment doplněn jednoznačným sekvenčním číslem. Zásadní otázkou však je, od jakého sekvenčního čísla se začnou jednotlivé segmenty bloku dat počítat. Vzhledem k tomu, že je přenos TCP plně duplexní, je nutné mít k dispozici tyto informace na obou komunikujících stranách. Obě strany si proto ve fázi navázání TCP spojení musí vzájemně vyměnit mezi sebou počáteční sekvenční čísla ISN pro jednu a druhou stranu přenosu. 17

18 3.2 Formát TCP záhlaví TCP protokol používá pro zajištění své transportní role řídicí informace přenášené v záhlaví TCP segmentů. Na následujícím obrázku jsou naznačena jednotlivá pole v záhlaví TCP segmentu. Popíšeme si nyní jen některé z nich. Použití cílového a zdrojového pole portu je zřejmé. Koncept portů umožňuje vícenásobné použití jedné implementace TCP protokolu pro více procesů na jednom zařízení (nebo operačním systému) s jednou IP adresou. Tato pole jsou 16 bitová, což znamená, že teoreticky lze na jedné IP adrese vytvořit až vzájemně nezávislých TCP zásuvek. Spodní rozsah portů od nuly do 1024 je však rezervován pro specifické serverové služby (taková TCP zásuvka je ve většině případů pasivní) a za normálních okolností se tento rozsah nevyskytuje v poli zdrojový port (jsou však určité výjimky). Pro aktivní zásuvky (klientská část TCP) se volí dočasný dynamicky vytvořený rozsah počínaje většinou hodnotou 1025 a výše (rozsah však závisí na použitém operačním systému). Po ukončení spojení lze tato čísla použít pro jiná spojení, nejsou tedy napevno přiřazená, tak jak je tomu typicky u TCP portů služeb, na nichž se typicky naslouchá. Záhlaví TCP segmentů Pole sekvenční a potvrzovací číslo se používá pro číslování TCP segmentů na straně vysílací a pro potvrzení přijatých segmentů stranou přijímací. Důležitou roli v záhlaví TCP hrají bitové příznaky, které plní různorodé funkce. Nejdůležitější jsou tyto příznaky: SYN používá se při navázání spojení. Samotný příznak používá TCP strana aktivní, informuje TCP přijímač o příchozím požadavku na navázání spojení a o nastaveném počátečním sekvenčním čísle (ISN) v sekvenčním poli záhlaví ACK tento příznak se používá vždy, když segment nese potvrzovací číslo. Současné nastavení příznaků SYN a ACK je potvrzením od pasivní strany TCP spojení, že byl přijat požadavek na navázání spojení stranou aktivní a zároveň, že segment v záhlaví nese počáteční sekvenční číslo ISN pro číslování segmentů v opačném směru přenosu od strany pasivní ke straně aktivní 18

19 FIN používá se při požadavku libovolné strany TCP spojení na ukončení probíhající spojení RST používá se pro obnovu spojení TCP (reset) pokud dojde k nekonzistenci řídících dat spojení nebo když na daném portu není připojená žádná aplikace, nebo je daný port zakázán PSH tento příznak se používá, pokud vysílací část aplikace vyžaduje okamžité předání všech dat ve vyrovnávací paměti přijímací strany TCP protější aplikaci. Pole okno se používá pro řízení toku a pole kontrolní součet slouží pro účely kontroly chyb, přičemž se hodnota v tomto poli získá výpočtem kontrolního součtu přes celý TCP segment s přidáním některých dalších polí ze záhlaví IP datagramu (tzv. pseudohlavička). 19

20 3.3 Fáze navázání TCP spojení Prvotní výměně kontrolních dat (např. hodnoty počátečních sekvenčních čísel) mezi oběma komunikujícími stranami TCP se říká navázání spojení. Teprve po bezprostředním navázání spojení probíhá fáze přenosu dat. TCP protokol byl navržen tak, že používá třífázový systém navázání spojení. Před vlastním popisem procesu navázaní spojení se věnujme otázce, jakým způsobem reaguje TCP přijímací strana při příjmu datového segmentu. Jak již bylo řečeno, TCP zajišťuje spolehlivý přenos dat v tom smyslu, že všechna aplikační data jsou doručena beze změn protější aplikaci. Fáze navázaní spojení u TCP protokolu Při vysílání datových segmentů však nelze předem určit, zdali bude daný segment správně doručen, protože je přenášen v IP paketu a ten nemusí být vůbec doručen. Aby toto mohlo správně fungovat, je zapotřebí určitá součinnost vysílací TCP strany s přijímací, konkrétně zajištění průběžného potvrzování o doručení segmentů. Navázání spojení, viz obrázek, se uskutečňuje výměnou tří řídicích zpráv (three way handshake). Tyto zprávy se přenáší doplněním odpovídajících informací do záhlaví TCP segmentů. V záhlaví TCP segmentu se nachází kromě 32 bitového sekvenčního (na obrázku označené jako sek ) a potvrzovacího čísla (na obrázku označené jako ack ) i pole jednobitových bitových příznaků (SYN, ACK, URG, PSH, FIN, RST). Dva z těchto příznaků v různé kombinaci jsou použity ve fázi navázání TCP spojení, konkrétně SYN a ACK. Při navázaní TCP spojení je ve většině případů aktivní jedna strana spojení (typicky klient v modelu klient/server) a druhá strana pasivní (strana serveru), viz dříve. Aktivní strana vyšle první TCP segment s nastaveným příznakem SYN, který indikuje počáteční sekvenční číslo ISN (Initial Sequence Number) v poli sek (v našem případě se jedná o hodnotu ISN A ) pro směr A-B. Tímto sděluje aktivní strana TCP, že svá data bude číslovat počínaje hodnotou ISN A +1. Pokud tato zpráva dojde k pasivní straně TCP, tak ta, pokud je spojení akceptovatelné, odešle aktivní straně odpověď v TCP segmentu v jehož záhlaví nastaví bitový příznaky 20

21 SYN a ACK a do pole sekvenčního čísla sek dosadí své ISN číslo pro opačný směr přenosu dat B-A (v našem případě to bude hodnota ISN B ). Nastavením příznaku SYN v TCP záhlaví odpovědi signalizuje aktivní straně, že v tomto segmentu se nachází platné počáteční číslo pro obráceny směr přenosu. Příznak ACK signalizuje potvrzení přijetí zprávy od A ve směru od pasivní (server) strany TCP spojení k aktivní straně (klient). Pokud aktivní strana tuto odpověď přijme, má potvrzeno, že je spojení obousměrně funkční a také, že protější strana akceptovala její, tedy klientské počáteční sekvenční číslo. Stále ale chybí toto potvrzení straně pasivní. Z tohoto důvodu má aktivní strana TCP ještě za povinnost poslat v rámci procesu navázání spojení poslední, v pořadí třetí, zprávu, která potvrdí, že i aktivní strana akceptovala počáteční sekvenční číslo strany opačné (server). Výměnou výše uvedených tří řídicích segmentů je provedeno navázání TCP spojení, které tak přechází do další fáze přenosu dat, viz dále. 21

22 3.4 Fáze přenosu dat Po navázání spojení přejde TCP protokol do fáze přenosu dat. V této fázi probíhá oboustranná komunikace mezi oběma TCP stranami. Vysílací strana TCP dělí data předaná od aplikace do bloků zvaných TCP segmenty, které označí sekvenčním číslem. Nečíslují se ale segmenty jako takové, ale bajty v rámci bloku dat předaného aplikací. První bajt datového bloku aplikace má sekvenční ISN+1. Jestliže TCP protokol dělí data do segmentů délky např. 100 bajtů, bude mít N-tý segment sekvenční číslo ISN+(N-1)* Zároveň v procesu přenosu dat dochází k průběžnému potvrzování přijatých segmentů. Přijímací strana může regulovat rychlost vysílání TCP segmentů do sítě prostřednictvím okna. Význam použití okna bude probrán v následující kapitole. Zároveň se musí ve fázi přenosu dat přizpůsobovat TCP vysílací strana podmínkám zatížení datové cesty a regulovat tak rychlost přenosu. Rychlost vysílání segmentů je tedy řízena dvěma okny, přičemž podstatné je vždy to z nich, které je menší. První okno (WS) slouží pro řízení toku jen mezi TCP vysílačem a přijímačem a druhé (cwdn) pro řízení přetížení v síti. TCP vysílač bere v úvahu to okno, které splňuje co do velikosti následující podmínku: aktuální_okno = min (WS, cwnd) 22

23 3.5 Princip přenosu pomocí okna TCP protokol je navržen tak, aby v plné míře využil kapacitu komunikačního kanálu, kterým se TCP segmenty přenáší. Pro vysokorychlostní kanály s velkým zpožděním přenosu dat mezi vysílačem a přijímačem by nebyl jednoduchý systém vyslání segmentu a čekání na jeho potvrzení před odesláním dalšího vůbec efektivní. Efektivita využití kanálu by byla velice nízká. Proto se u TCP používá princip vysílacího okna, pro další výklad budeme pro jeho velikost používat proměnnou WS. TCP segmenty dat se vysílají bez toho, aniž by bylo nutné nejprve přijmout potvrzení o přijatých segmentech předchozích. Toto se ovšem děje pouze a jen do vyčerpání maximální velikosti vysílacího okna. Abychom toto uvedli na konkrétním případě, předpokládejme, že byla stanovena velikost vysílacího okna win pro právě probíhající TCP spojení na V tomto případě může vysílací TCP strana vyslat okamžitě bajtů aplikačního bloku dat ve formě několika za sebou jdoucích TCP segmentů, aniž by musela čekat na jejich individuální potvrzení stranou přijímací. Po odvysílání všech bajtů musí ale vysílací strana bezpodmínečně zastavit vysílání, a to i v případě, že jsou stále ještě data, která je nutné odvysílat. TCP umožňuje měnit velikost okna v průběhu spojení, čímž lze ovlivnit rychlost přenosu dat. Princip metody klouzavého okna u TCP 23

24 3.6 Použití okna pro regulaci přenosu dat řízení toku Změnu okna řídí TCP přijímací strana, která může okno jak otevřít, tj. zvětšit, tak i uzavřít, tj. zmenšit. Zvětšením okna se zrychluje průměrná rychlost přenosu dat TCP spojením (maximální rychlost je stále omezena maximální rychlostí přenosu IP paketů sítí) a naopak uzavřením okna se tato rychlost zmenšuje. Okno lze dokonce nastavit na hodnotu nula, čímž se zakazuje vysílači přenášet data. Princip klouzavého okna je znázorněn na obrázku. Princip metody klouzavého okna u TCP Propustnost TCP spojení P je dána aktuální velikostí TCP okna WS (Window Size) a dvoucestným zpožděním RTT (Round Trip Time), které je definováno jako doba potřebná pro odeslání segmentu a příjmu potvrzení o jeho správném doručení. Pro výpočet existuje tento jednoduchý vztah: P = kde: 8 WS [bit/s] RTT WS aktuální velikost TCP okna [bajt] RTT aktuální dvoucestné zpoždění v [s] Dynamická změna okna umožňuje i řízení toku (flow control). Pokud dočasně aplikace nebo TCP protokol není schopen přijímat data, informuje o této skutečnosti vysílač zmenšením okna nebo jeho úplným uzavřením. V okamžiku, kdy už je přijímač schopen opět data přijímat, okno se opět otevře. Důležité je se také zmínit, co se stane, když přijímací strana podle předchozího příkladu potvrdí vysílací TCP straně správný příjem např bajtů. V tomto okamžiku se okno automaticky otevře o velikost právě potvrzených dat a lze opět vyslat dalších bajtů bez potvrzení. Kdybychom si toto nakreslili graficky, zjistili bychom, že se okno pomyslně pohybuje směrem k vyšším sekvenčním číslům v průběhu TCP spojení. Proto se tomuto principu často říká metoda klouzavého okna (moving window). 24

25 3.7 Metoda multiplikativního potvrzování doručených segmentů Způsobů jak provádět toto potvrzení je více a obecně všechny spadají do kategorie, která se nazývá automatické opakované vyslání dat ARQ (Automatic Repeat-reQuest). Jednoduše řečeno, přijímací strana TCP vždy informuje vysílací stranu o příjmu neporušeného segmentu(ů). To se děje tak, že se kromě sekvenčního čísla přenáší v každém segmentu ještě potvrzovací číslo (acknowledgment), pro další výklad budeme toto číslo označovat jako ack, které informuje vysílací stranu TCP, že byla na straně přijímače v pořádku přijata data až do sekvenčního čísla rovnému číslu potvrzovacímu minus jedna, tj. ack-1. Jinými slovy, přijímací strana vysláním např. potvrzovacího čísla ack = očekává, že jí vysílací strana TCP vyšle segment se sekvenčním číslem a de facto tímto aktem automaticky potvrzuje bezchybné přijetí všech segmentů aplikačního bloku dat od jeho samého počátku, daného počátečním sekvenčním číslem ISN+1 (Initional Sequnce Number), až po sekvenční číslo Tomuto procesu se říká obecně kumulativní potvrzování, viz obrázek Kumulativní potvrzování 25

26 3.8 Fáze ukončení spojení Vzhledem k tomu, že s každým TCP spojením souvisí určité množství rezervové paměti, je nutné ji uvolnit, pokud sestavené TCP spojení není již potřeba. Pro ukončení spojení nelze použít dobu nečinnosti, protože TCP spojení může být teoreticky navázané, aniž by se v daném okamžiku přenášela určitá data. Teoreticky může být TCP spojení nekonečně dlouhé a přitom se jím mohou přenášet data jen po velice krátkou dobu, nebo interval. Nemáme tedy jinou možnost, jak nepotřebné spojení deaktivovat, než přímou indikací ukončení spojení. Tento princip u TCP musí existovat, protože by časem nerozpojená a nepotřebná TCP spojení vyčerpala většinu prostředků v koncovém systému (paměť, ale i CPU). Je to stejné, jako když v programu programátor uvolňuje již nepotřebné dynamicky alokované prostředky. Ukončení TCP spojení Explicitní metoda ukončení TCP spojení je založena na výměně zpráv mezi oběma TCP stranami, podobně jako se realizuje navázání TCP spojení. Ukončení spojení je však poněkud složitější. Pokud totiž jedna strana TCP žádá o ukončení spojení, protože v tomto směru již není zapotřebí data předávat, nemusí stejné podmínky platit i v opačném směru, kdy protější strana ještě určitá data potenciálně k přenosu mít může. Z tohoto důvodu je fáze ukončení spojení dvoustupňová. Nezávisle na sobě se ukončuje spojení nejprve v jednom a potom i v druhém směru. Pro každý směr jsou k tomu zapotřebí dvě zprávy, tj. celkově pro úplné ukončení TCP spojení jsou zapotřebí zprávy čtyři (4 way handshake), viz obrázek. Ukončení spojení v daném směru TCP přenosu se signalizuje protější straně nastavením příznaku FIN v záhlaví posledního datového segmentu. Protější strana odpoví na tento segment klasickým potvrzením ACK, čímž se v tomto směru tok data ukončí. Následuje ukončení spojení ve druhém směru podle stejných pravidel. Spojení TCP je plně ukončené pokud je ukončené v obou směrech. 26

27 4 Metody řízení přetížení sítě u protokolu TCP 4.1 Smysl řízení přetížení Důležitou funkcí při přenosu datových segmentů TCP protokolem je schopnost reagovat na aktuální zatížení v síti. Pokud by TCP spojení nebralo v úvahu aktuální zatížení sítě, docházelo by k lavinovému přetížení síťové cesty, podél níž se TCP segmenty přenášejí v IP paketech, což by vedlo k významnému snížení propustnosti. Tento stav byl skutečně v počátcích u TCP přenosu zpozorován a bylo proto nutné do TCP protokolu doplnit funkci vyhýbání se přetížení (viz dále). Po navázání TCP spojení se začnou datové segmenty do sítě vysílat relativně pomalu, aby se otestovala aktuální propustnost datové cesty. V okamžiku, kdy se zjistí, že dochází k zahazování paketů, se zmenší okno přetížení na jednu polovinu a postupně se začíná opět zvětšovat. Množství přenášených dat v čase vykazuje pilovitou funkci, jejíž střední hodnota udává průměrnou rychlost přenosu dat. Chování sítě z hlediska datové propustnosti při zvětšující se intenzitě nabídky paketů lze vidět na následujícím obrázku Chování sítě při zátěži Jak je patrné, při malé nabídce roste propustnost lineárně až do jistého bodu, který se nazývá koleno. V tomto bodě dochází postupně k saturaci propustnosti. Pokud bude však nabídka nadále růst, dojde k velmi nepříjemné situaci, kdy se propustnost začne velice strmě snižovat. Toto je dáno primárně tím, že většina paketů bude zahazována. Zároveň se také výrazně zvýší zpoždění přenosu. 27

28 Z výše uvedeného chování je zřejmé, že nesmí dojít k situaci, kdy bude vysílač generovat pakety do sítě rychleji, než odpovídá zhruba oblasti kolena na výše uvedeném obrázku. Je nutné si uvědomit, že cesta v sítě může být obecně využívána (je sdílena) velkým počtem relací, které se musí vzájemně o maximální kapacitu dané cesty vzájemně podělit. Klíčovým požadavkem však je, aby rozdělení dostupné kapacity proběhlo rovnoměrným způsobem tak, aby se nestalo, že některé relace budou z hlediska přenosové kapacity upřednostňované před jinými. V tomto případě bereme všechny pakety ze všech relací se stejnou prioritou, tj. neuvažujeme QoS. Dalším požadavkem je, aby při řízeném generování paketů do sítě nedocházelo k nevytížení datového spoje. 28

29 4.2 Metoda aditivního zvětšení a multiplikativního zmenšení okna přetížení Problém s řízením přetížení lze zařadit do třídy problémů, kde je zapotřebí dynamicky reagovat na aktuální stav zatížení datové cesty v síti zavedením zpětné vazby, která informuje vysílač, zdali může či nemůže vysílat pakety do sítě. Obecně vzato lze tuto zpětnou vazbu rozšířit o více informací, jako je např. aktuální výše zatížení datové cesty vyjádřená číselně. Toto se však v praxi vzhledem ke složitosti implementace u TCP protokolu zatím nepoužívá. Přetížení v síti a je jeho regulace TCP používá dvoustavový systém indikace přetížení, která je ještě kombinovaná s principem pomalého startu, který bude probrán v jedné z následujících kapitol. Princip řízeného přetížení je naznačen na výše uvedeném obrázku. Zde je celkem n koncových zařízení, které generujíc datový tok s odpovídajícími nabídkami. Pokud dojde k převýšení dostupné kapacity ve sdílené cestě, bude tento stav sítě indikován prostřednictvím zpětnovazebního dvoustavového signálu y. Pokud v daném okamžiku t 1 je stav signálu y(t 1 )=0, znamená to, že síť disponuje volnou přenosovou kapacitou, není tedy přetížena a stanice mohou zvýšit intenzitu generování paketů. Pokud dojde k přetížení (např. v čase t 2), je tento stav indikován v daném časovém okamžiku hodnotou signálu y(t 2 )=0. V tomto případě musí všechny stanice snížit intenzitu nabízených paketů do sítě. Otázkou však zůstává, podle jakého algoritmu snižovat nebo zvyšovat nabízený tok do sítě podle aktuálního stavu zpětnovazebního signálu y(t). Nejjednodušším principem je použití lineárního algoritmu podle následujícího vzorce: a1+ bx 1 i () t pokud y() t = 0 xi ( t+ 1) = {, a + b x() t pokud y() t = 1 D D i Koeficienty a a b (pro indexy D a I) jsou nastaveny jako konstanty. U TCP je konstanta b I =1 a a D =0, což znamená, že se zvyšování toku děje aditivním 29

30 způsobem, vždy se přičte konstanta a I k předchozí hodnotě toku a snižování se děje multiplikativním způsobem, vždy se současná hodnota násobí číslem b D, které je menší než jedna. Jak již bylo řečeno, regulace toku se u TCP děje prostřednictvím zvětšování nebo zmenšování vysílacího okna. Ve výsledku tedy TCP používá metodu řízení toku zvanou jako AIMD, tj. aditivní navýšení toku a multiplikativní snížení toku. Tato metoda zaručuje spravedlivé rozdělené dostupné kapacity cesty mezi více toků a zároveň i nejlepší vytížení cesty. 30

31 4.3 Indikace přetížení u TCP přenosu U TCP protokolu a metody vyhýbání se přetížení zvané jako New Reno se uplatňují dva způsoby indikace přetížení. První, tvrdá indikace přetížení je signalizována vypršením časovače pro opakované vyslání TCP segmentu. V tomto případě dochází v datové cestě k hraničnímu zaplnění odbavovacích front a směrovače musí dané segmenty nemilosrdně zahodit, není prostě na ně ve frontě volné místo, kam by je bylo možné uložit. Poněkud méně naléhající situaci indikuje druhý typ signalizace přetížení, měkká indikace přetížení, která je reprezentována vícenásobným požadavkem na opětovné vyslání stejného segmentu (3 duplikované žádosti o opětovné zaslání stejného TCP segmentu). Tato indikace znamená, že sice došlo v datové cestě k zahození zmiňovaného segmentu, avšak další segmenty za ním následující sítí prošly (jinak by nemohla přijít tato indikace). Znamená to tedy, že datová cesta sice není ještě zcela přetížena, ale pomalu se k této situaci blížíme. TCP protokol (přesněji vysílací část TCP) reaguje na obě zmíněné indikace přetížené odlišně, což si nyní probereme podrobněji. TCP spojení obecně přechází v průběhu přenosu dat mezi fází pomalého startu a fází vyhýbání se přetížení. Fáze vyhýbání se přetížení se vesměs řídí algoritmem AIMD, který byl probrán v předchozí kapitole. Otázkou však je, podle čeho TCP pozná, v jaké fázi se nachází? K tomuto účelu slouží jednak typ indikátoru přetížení (tvrdý nebo měkký) a také proměnná ssthresh, jejíž velikost se nastavuje dynamicky v průběhu TCP datového spojení. Pokud je aktuální velikost vysílacího okna (cwdn) menší nebo rovná hodnotě výše uvedené proměnná, bude se TCP protokol nacházet ve fázi pomalého startu. Pokud naopak bude velikost okna větší, přejde do fáze vyhýbání se přetížení. TCP spojení v procesu regulované zátěže sítě 31

32 4.4 Fáze pomalého růstu okna Jak již bylo řečeno dříve, po fázi navázání spojení přejde TCP protokol do fáze přenosu dat, kdy se v obou směrech předávají datové segmenty označené vždy patřičným sekvenčním číslem. Otázkou však zůstává, jak rychle má bezprostředně po navázání spojení začít TCP vysílač vysílat data, když vůbec nezná aktuální zatížení datové cesty. Pokud by začal vysílat data maximální rychlostí s plně otevřeným vysílacím oknem určeným protější přijímací stranou TCP v době navázání spojení, je dosti pravděpodobné, že by mohlo dojít k výraznému přetížení cesty v síti (oblast propasti na jednom z předchozích obrázků). Tento stav je nutné eliminovat. TCP protokol toto řeší tak, že začne vysílat data s velice malým počátečním oknem (1 segment TCP) a pokud nedojde k přetížení, bude se toto okno velice rychle, téměř exponenciálně, zvětšovat. Této fázi exponenciálního růstu velikosti vysílacího okna se říká pomalý start (slow start), což je poněkud zvláštní, protože se o pomalý start a růst okna vlastně vůbec nejedná. Tento název však nevznikl podle charakteru zvětšování okna, jak by se mohlo zdát, ale spíše byl vztažen k původní metodě, která umožňovala TCP vysílači vysílat segmenty do sítě plnou rychlostí danou velikostí okna předaného TCP vysílači stranou přijímací. Metoda, či fáze pomalého startu končí při první indikaci přetížení sítě. Do fáze pomalého startu (začne se vysílat s oknem nastaveným jen na 1 TCP segment) se přechází vždy, pokud došlo k vypršení časovače opětovného vysílání (tvrdá indikace přetížení). Zároveň se ale také modifikuje velikost proměnné ssthresh tak, že se nastaví na polovinu velikosti aktuálního vysílacího okna (cwnd). TCP spojení v procesu regulované zátěže sítě 32

33 4.5 Fáze vyhýbání se přetížení Pokud dojde v průběhu TCP přenosu k indikaci měkkého přetížení, sníží se sice hodnota proměnné ssthresh na polovinu, ale aktuální okno se nezmění. Výsledkem je tedy ponechání TCP vysílače ve fázi vyhýbání se přetížení. Ve fázi pomalého startu roste velikost vysílacího okna vždy o počet právě přijatých potvrzených segmentů stranou přijímací, kdežto ve fázi vyhýbání se přetížení roste vždy jen o jeden TCP segment za dobu trvání RTT (Round Trip Time). Výsledkem je tak exponenciální nárůst velikosti okna v čase pro pomalý start, ale jen lineární nárůst ve fázi vyhýbání se přetížení. Fáze vyhýbání se přetížení u metody Reno ještě prochází procesem, kterému se říká rychlé zotavení. Při příjmu tří duplikovaných žádostí (3_DUP_ACK) o zaslání stejného TCP segmentu, se tento segment bezprostředně ihned bez čekání na vypršení jeho časovače RTO vyšle přijímači a čeká se na kumulativní potvrzení všech odeslaných segmentů z celého okna před navrácením se do fáze vyhýbání se přetížení. Pokud toto potvrzení nepřijde do doby uplynutí časovače RTO, přejde se do fáze pomalého startu. Střídání fází pomalého startu a vyhýbání se přetížení 33