Základy transportního protokolu TCP

Základy transportního
protokolu TCP
Leoš Boháč
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
VYSVĚTLIVKY
Definice
Zajímavost
Poznámka
Příklad
Shrnutí
Výhody
Nevýhody
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.] : AddisonWesley Professional, 1994. 562 s. ISBN 0-201-63346-9
[2]
KOZIEROK, Charles M. The TCP/IP Guide : A Comprehensive, Illustrated Internet
Protocols Reference. San Francisco : No Starch Press, 2005. 1648 s. ISBN 978-159327-047-6
[3]
DOYLE, Jeff; CARROLL, Jennifer. Routing TCP-IP : Volume I. 2nd ed. [s.l.] : Cisco
Press, 2005. 936 s. ISBN 1-58705-202-4
[4]
ZININ, Alex. Cisco IP Routing : Packet Forwarding and Intra-domain Routing
Protocols . [s.l.] : Addison Wesley Professional, 2001. 656 s. ISBN 0-201-60473-6
Obsah
1 Smysl a použití transportních protokolů v architektuře TCP/IP .................................... 6
1.1
Přehled architektury TCP/IP ...................................................................................... 6
1.2
Základy transportního protokoly UDP ....................................................................... 8
1.3
Vlastnosti a smysl použití UDP protokolu ................................................................. 9
1.4
Základní vlastnosti transportního protokolu TCP .................................................... 11
2 Programovací primitivy pro přístup k transportním službám architektury TCP/IP . 13
2.1
Aplikační prostor a princip transportních soketů ..................................................... 13
2.2
Princip soketové komunikace pro TCP protokol ..................................................... 15
3 Popis funkce transportního protokolu ............................................................................. 16
3.1
Sekvenční čísla ......................................................................................................... 16
3.2
Formát TCP záhlaví.................................................................................................. 18
3.3
Fáze navázání TCP spojení ...................................................................................... 20
3.4
Fáze přenosu dat ....................................................................................................... 22
3.5
Princip přenosu pomocí okna ................................................................................... 23
3.6
Použití okna pro regulaci přenosu dat – řízení toku ................................................. 24
3.7
Metoda multiplikativního potvrzování doručených segmentů ................................. 25
3.8
Fáze ukončení spojení .............................................................................................. 26
4 Metody řízení přetížení sítě u protokolu TCP ................................................................. 27
4.1
Smysl řízení přetížení ............................................................................................... 27
4.2
Metoda aditivního zvětšení a multiplikativního zmenšení okna přetížení ............... 29
4.3
Indikace přetížení u TCP přenosu ............................................................................ 31
4.4
Fáze pomalého růstu okna ........................................................................................ 32
4.5
Fáze vyhýbání se přetížení ....................................................................................... 33
4.6
Závěrečný test........................................................................................................... 34
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 40–50 let. TCP/IP architektura staví v první
řadě na standardu IP protokolu, který dle RM OSI patří do vrstvy síťové.
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
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
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
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
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
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
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
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
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
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
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
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ž 65 536 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
•
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
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 ISNA) pro směr A-B. Tímto sděluje aktivní
strana TCP, že svá data bude číslovat počínaje hodnotou ISNA+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
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 ISNB). 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
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)*100+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
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 10 000. V tomto případě může
vysílací TCP strana vyslat okamžitě 10 000 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 10 000 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
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=
8 WS
RTT
[bit/s]
kde:
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ř. 3 000 bajtů. V tomto okamžiku se okno
automaticky otevře o velikost právě potvrzených dat a lze opět vyslat dalších
3 000 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
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“=11 000
očekává, že jí vysílací strana TCP vyšle segment se sekvenčním číslem 11 000
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 10 999. Tomuto
procesu se říká obecně kumulativní potvrzování, viz obrázek
Kumulativní potvrzování
25
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
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
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
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 t1 je stav signálu y(t1)=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 t2), je tento stav
indikován v daném časovém okamžiku hodnotou signálu y(t2)=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:
a + b x (t )
xi (t + 1) = { 1 1 i
aD + bD xi (t )
pokud
y(t ) = 0
pokud
y(t ) = 1
,
Koeficienty a a b (pro indexy D a I) jsou nastaveny jako konstanty. U TCP je
konstanta bI=1 a aD=0, což znamená, že se zvyšování toku děje aditivním
29
způsobem, vždy se přičte konstanta aI 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 bD,
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
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
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
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
4.6 Závěrečný test
1. V rácmi architektury sítí TCP/IP jsou jednolitvé koncové body
komunikace jednozančně určené
a) zdrojovou a cílovou IP adresou
b) zdrojová IP adresa/zdrojový port a cílová IP adresa/cílový port
c) zdrojová IP adresa/zdrojový port nebo cílová IP adresa/cílový port
d) zdrojová IP adresa/zdrojový port a cílová IP adresa/cílový port a použitý
transportní protokol
správné řešení: d
2. Programátorský koncept komunikace v síti TCP/IP se u většiny OS
nazývá
a) soket(socket)
b) sorets
c) buket
d) puret
správné řešení: a
3. V socketové TCP/IP komunikace je vždy prvním voláním funkce
a) socket()
b) write()
c) connect()
d) listen()
správné řešení: a
4. Klientský proces se spojí se serverovým procesem prostřednictvím volání
funkce
a) write()
b) listen()
c) connect()
d) accept()
správné řešení: c
34
5. U serverového socketu je po volání funkce socket() nutné zavolat funkci
a) write()
b) listen()
c) bind()
d) accept()
správné řešení: c
6. TCP protokol pracuje s datovými jednotkami, kterým se říká
a) pakety
b) segmenty
c) rámce
d) datagramy
správné řešení: b
7. Lze TCP protokol použít pro spojení bod/vícebod
a) lze, ale s podporou UDP
b) jen pokud je v síti OSPF protokol
c) jen pokud je v síti nakonfigurován IGMP protokol
d) nelze v žádném případě, TCP nemí pro tento typ komunikace navržen
správné řešení: d
8. Aktivní strana TCP v prvním segmentu navázání spojení s pasivní
stranou TCP nastavuje příznak
a) ACK
b) SYN a ACK
c) jen SYN
d) ACK a FIN
správné řešení: c
35
9. Pasivní strana TCP spojení odpovídá na požadavke navázání spojení
nastavením těchto příznaků v odesílaném segmentu odpovědi
a) jen ACK
b) SYN a ACK
c) jen SYN
d) ACK a FIN
správné řešení: b
10. Fáze navázání TCP spojení se sestává z výměny
a) 2 TCP segmentů
b) 4 TCP segmentů
c) 3 TCP segmentů
d) 6 TCP segmentů
správné řešení: c
11. Jak řeší TCP případné nedoručení bloků dat
a) TCP vysílač neustále vysílá s periodou 1ms data do sítě, než dostaně kladné
potvrzení od TCP přijímače, že všechna data byla již v pořádku přijata
b) TCP strana pro každý vyslaný segment nastaví časovač na 1 ms, a pokud po
jeho vypršení nepřijde kladné potvrzení, zašle tento segment znovu
c) TCP strana pro každý vyslaný segment nastaví časovač na průměrnou hodnotu
zpoždění v síti, a pokud po jeho vypršení nepřijde kladné potvrzení, zašle
tento segment znovu
d) TCP strana pro každý vyslaný segment nastaví časovač na dvojnásobnou
aktuální hodnoty zpoždění v síti, a pokud po jeho vypršení nepřijde kladné
potvrzení, zašle tento segment znovu
správné řešení: c
12. Přijímací okno TCP je rovno 30000 bajtům a RTT je 20 ms, jaká je
maximální propustnost spojení v Mbit/s, pokud neuvažujeme dynamiku
sítě a algoritmus vyhýbání se přetížení?
a) 150
b) 12
c) 15
d) 24
správné řešení: b
36
13. TCP používá ve fázi vyhýbání se přetížení metodu
a) AIMD
b) MIMD
c) AIAD
d) MIAD
správné řešení: a
14. Ve fázi vyhýbání se přetížení (congestion avoidance), TCP protokol
zvětšuje okno přetížená (cwd)
a) vždy o jeden bajt za uplynutí aktuální platné hodnoty zprůměrované doby
zpoždění RTO
b) vždy o jeden celý segment za fixní dobu 1 ms
c) vždy o jeden celý segment za uplynutí aktuální platné hodnoty zprůměrované
doby zpoždění RTO
d) vždy o počet bajtů právě potvrzených segmentů
správné řešení: c
15. Ve fázi pomalého startu (slow start) TCP protokol zvětšuje okno
přetížená (cwd)
a) vždy o jeden bajt za uplynutí aktuální platné hodnoty zprůměrované doby
zpoždění RTO
b) vždy o jeden celý segment za fixní dobu 1 ms
c) vždy o jeden celý segment za uplynutí aktuální platné hodnoty zprůměrované
doby zpoždění RTO
d) vždy o počet bajtů právě potvrzených segmentů
správné řešení: d
16. Co je rozhodující pro přechod TCP z režimu „slow start“ do režimu
„congestion avoidance“
a) velikost proměnné ssthresh
b) počet právě nepotrzených segmentů
c) velikost TCP vyrovnávací paměti
d) velikost RTO
správné řešení: a
37
17. Pokud třikrát za sebou dojde k TCP vysílači opakované potvrzení
určitého segmentu (triple duplicate), provede New RENO TCP vysílač
a) zmenší aktuální hodnotu cwd na polovinu a dosadí ji do ssthresh, dále přejde
do fáze „congestion avoidance“
b) zmenší ssthresh==cwnd/2 a přejde do fáze „slow start“
c) zvětší ssthresh==2*cwnd a přejde do fáze „congestion avoidance“
d) nic z uvedeného
správné řešení: a
18. Pokud u TCP vysílače dojde k vypršení časovače (nedojde tedy včas
potvrzení o příjmu), provede New RENO TCP vysílač
a) zmenší aktuální hodnotu cwd na polovinu a dosadí ji do ssthresh, dále přejde
do fáze „congestion avoidance“
b) zmenší ssthresh==cwnd/2 a přejde do fáze „slow start“
c) zvětší ssthresh==2*cwnd a přejde do fáze „congestion avoidance“
d) nic z uvedeného
správné řešení: b
19. První segment datové spojení má sekvenční číslo
a) ISN-1
b) ISN
c) ISN+1
d) ISN+2
správné řešení: c
20. Úplné ukončení spojení TCP se děje prostřednictvím
a) dvou zpráv
b) jedné zprávy
c) čtyř zpráv
d) tří zpráv
správné řešení: c
38