Handshake TCP. Bezdrátové otázky - Počítačové sítě a telekomunikace

Úvod

TCP je protokol orientovaný na připojení. Než může každá strana poslat data jinou, musí být spojení stanoveno mezi nimi. V této kapitole podrobně zvážíme, jak je připojení TCP instalováno a jak je přerušeno.

Protože operace TCP vyžaduje spojení mezi oběma konci, liší se od protokolů bez připojení, jako je UDP. Viděli jsme, že když používáte UDP, každá strana jednoduše odkazuje na datagram, aniž by se před tím nastavil.

Připojovací zařízení a prasknutí

Chcete-li zjistit, co se stane při nastavení a porušení připojení TCP, jsme provedli následující příkaz na SVR4 systému:

sVR4% telnet BSDI Zlikvidujte.
Se snaží 192.82.148.3 ...
Připojen k BSDI.
Escape charakter je "^]".
^] Zadáváme kontrolu, pravou čtvereční držák,
telnet\u003e přestat. Klientem Telnet porušil připojení
Zavřeno spojení.

Příkaz Telnet nastaví připojení TCP do hostitele BSDI k portu odpovídající službě Zrušení (kapitola 1, sekce). To je jen typ služby, kterou potřebujeme vidět, co se stane při zřizování a rozbití spojení, ale bez výměny dat.

Tcpdumpový výstup

Obrázek 18.1 ukazuje výstup TCPDUMP pro segmenty generované tímto příkazem.

1 0.0 SVR4.1037\u003e BSDI.DISCARD: S 1415531521: 1415531521 (0)
Vyhrajte 4096.
2 0.002402 (0.0024) BSDI.DISCard\u003e SVR4.1037: S 1823083521: 1823083521 (0)
ACK 1415531522 Vyhrajte 4096

3 0.007224 (0.0048) SVR4.1037\u003e BSDI.DISCARD :. ACK 1823083522 Vyhrajte 4096
4 4.155441 (4.1482) SVR4.1037\u003e BSDI.discard: F 1415531522: 1415531522 (0)
ACK 1823083522 Vyhrajte 4096
5 4.156747 (0.0013) bsdi.discard\u003e SVR4.1037 :. ACK 1415531523 Win 4096
6 4.158144 (0.0014) bsdi.discard\u003e SVR4.1037: F 1823083522: 1823083522 (0)
ACK 1415531523 Win 4096
7 4.180662 (0.0225) SVR4.1037\u003e BSDI.DISCARD :. ACK 1823083523 Win 4096

Obrázek 18.1 Výstup TCPDUMP pro stanovení a prasknutí připojení TCP.

Tyto sedm segmentů TCP obsahují pouze záhlaví TCP. Výměna dat nebyla provedena.

Pro segmenty TCP začíná každý výstupní řetězec

zdroj\u003e Destinace: Flags (zdroj\u003e Účel: vlajky)

kde jsou příznaky čtyři z šesti bitů záhlaví TCP (). Obrázek 18.2 ukazuje pět různých znaků, které odpovídají příznakům a může se zobrazit ve výstupu.

	3-symbolická zkratka	Popis
		synchronizační čísla sekvencí
		sender dokončil přenos dat
		obnovit připojení
		odesílání dat do přijímacího procesu co nejrychleji
		Žádný ze čtyř příznaků není nastaven

Obrázek 18.2 Znaky vlajky odvozené pomocí příkazu tcpdump pro bity vlajky v záhlaví TCP.

V tomto příkladu vidíme vlajky S, F a bod. Později se objeví další dvě příznaky (R a P). Dvě další kousky příznaků v záhlaví TCP - ACK a URG - vytištěna příkazem tcpdump.

V jednom segmentu může být přítomen více než jeden ze čtyř vlajkových bitů uvedených na obrázku 18.2, nicméně, pouze jedna vlajka je obvykle rozdrcena.

RFC 1025 [Postel 1987] volá segment, ve kterém je maximální kombinace všech dostupných vlajkových bitů rozdrcena současně (SYN, URG, PSH, fin a 1 datový bajt) balíček Kamikaze (v angličtině je několik dalších definic Takový balíček, konkrétně "špinavý balíček", "Novoroční vánoční stromeček" atd.).

Řetězec 1 pole 1415531521: 1415531521 (0) znamená, že číslo balení sekvence je 1415531521 a počet datových bajtů v segmentu je 0. Příkaz tcpdump vytiskne počáteční pořadové číslo, dvojtečce, odhadovaný konečný počet sekvencí a Pak v závorkách počet datových bajtů. V tomto případě je možné zobrazit odhadované pořadové pořadové číslo, kdy je počet bytů větší než 0. Pole se zobrazí (1), pokud segment obsahuje jeden nebo několik bajtů uživatelských dat nebo (2), pokud je SYN, Fin nebo první vlajka semena. V řádcích 1, 2, 4 a 6 na obrázku 18.1 se zobrazí toto pole, protože bity vlajky jsou zapečetěny - výměna všech údajů v tomto příkladu nebyla vyrobena.

V řadě 2 pole ACK 1415531522 obsahuje číslo potvrzení. Je vytištěn pouze v případě, že je vlajka ACK rozdrcena. Pole Win 4096 v každém řádku výstupu ukazuje velikost okna, které bylo deklarováno odesílatele. V tomto příkladu, kde data nejsou vyměněna, velikost okna zůstala nezměněna a výchozí hodnota byla použita - 4096. (Podíváme se na velikost okna TCP v kapitole 20. kapitole 20.)

A poslední pole ve výstupu na obrázku 18.1, Zobrazuje maximální velikost segmentu (MSS - maximální velikost segmentu), možnost, že sady odesílatele. Odesílatel nechce přijímat segmenty TCP více než tuto hodnotu. To se obvykle provádí, aby se zabránilo fragmentaci (kapitola 11, oddíl). Podíváme se na maximální velikost segmentu v sekci této kapitoly a formát různých možností TCP se zobrazí v části této kapitoly.

Dočasné diagramy

Obrázek 18.3 ukazuje časový diagram odpovídající tomuto balíčku Exchange. (Popsali jsme některé hlavní charakteristiky dočasných diagramů, kdy se první čas otočí.) V tomto obrázku je ukázáno, že strana odešle pakety. Zobrazeno také příkaz tcpdump (syn byl zobrazen na tisk namísto s). V tomto časovém diagramu je velikost okna odstraněna, protože není nezbytná pro naši diskusi.

Připojovací protokol

A teď se vraťme zpět na podrobnosti protokolu TCP, které jsou znázorněny na obrázku 18.3. Chcete-li nainstalovat připojení TCP, musíte:

1. Požadující strana (která se zpravidla nazývá klienta) Odesílá segment SYG, určující číslo portu serveru, ke kterému se klient chce připojit, a zdrojové číslo sekvence klienta (v tomto příkladu, ISN, 1415531521) . Jedná se o segment číslo 1.
2. Server reaguje se segmentem SYG obsahujícího zdrojové číslo sekvence serveru (segment 2). Server také potvrzuje příchod klienta SYN pomocí ACK (ISN Client Plus jeden). SYN používá jedno pořadové číslo.
3. Klient musí potvrdit příjezd SYN ze serveru pomocí ACK (ISN Server Plus jeden, segment 3).

Tyto tři segmenty jsou dostačující k navázání spojení. Často se nazývá tříčasový handshake (trojcestný handshake).

Obrázek 18.3 Časový diagram založení a prasknutí připojení.

Předpokládá se, že strana, která vysílá první SYN, aktivuje připojení (aktivní otevírání). Druhá strana, která přijímá první SYN a odešle následující SYN, trvá pasivní účast na otevření spojení (pasivní otevírání). (V této kapitole popisujeme postup otevírání směsi podrobně, kde se obě strany považují za aktivní při stanovování sloučeniny.)

Když každá strana poslala jeho SYN, aby navázala spojení, vybere zdrojové číslo sekvence (ISN) pro toto připojení. Je třeba měnit pokaždé, takže každé připojení má své vlastní, jiné od ostatních ISN. RFC 793 [Postel 1981c] označuje, že ISN je 32bitový čítač, který se zvyšuje na jednotku každých 4 mikrosekund. Díky pořadovým číslům se pakety, které zpožděnou síť a dodávanou později, nejsou vnímány jako součást stávající sloučeniny.

Jak je vybráno pořadové číslo? V 4,4BSD (a ve většině implementací Berkeley), při inicializaci systému je zdrojový počet sekvencí nastaveno na 1. Tato praxe je odsouzena požadavky hostitele hostitele RFC hostitele hostitele. Tato hodnota se tato hodnota zvyšuje o 64 000 o polovinu sekundy a vrátí se na 0 každých 9,5 hodiny. (To odpovídá čítači, který se zvyšuje na jednotku každých 8 mikrosekund, a ne každé 4 mikrosekundy.) Kromě toho, při každém připojení spojení se tato proměnná zvýší o 64 000.

Interval 4,1 sekundy mezi segmenty 3 a 4 odpovídá času mezi navázáním připojení a zadejte příkaz QUIT pro telnet, aby přerušil připojení.

Protokol přerušení připojení

Za účelem stanovení sloučeniny jsou nutné 3 segmenty a za účelem přerušení - 4. To je vysvětleno skutečností, že připojení TCP může být v polovině uzavřeného stavu. Protože připojení TCP je plné duplex (data se mohou pohybovat v každém směru, bez ohledu na druhý směr), každý směr musí být uzavřen bez ohledu na druhý. Pravidlo je, že každá strana by měla zaslat FIN, když je přenos dat dokončen. Když TCP přijímá fin, musí tuto aplikaci oznámit, že vzdálená strana přerušuje připojení a ukončí přenos dat v tomto směru. Ploutve je obvykle odeslána v důsledku ukončení aplikace.

Lze říci, že strana, že první zavře spojení (posílá první fin), provádí aktivní uzávěr a druhá strana (která přijala toto plnění) provádí pasivní uzavření. Obvykle jedna strana provádí aktivní uzávěr a další pasivní, avšak v části této kapitoly uvidíme, že obě strany mohou provádět aktivní uzavření.

Segment číslo 4 na obrázku 18.3 vede k uzavření spojení a je odeslán při přestavcích klienta telnetu. To se stane, když vstoupíme. Současně je klient TCP nucen poslat fin, zavření datového toku z klienta na server.

Když server dostane fin, odešle zpět ACK s přijatým číslem sekvence plus jeden (segment 5). Na FIN je stráven jedno pořadové číslo, stejně jako na SYN. V tomto okamžiku poskytuje také server TCP také jmenování konce souboru (end-of-file) (vypnout server). Server zavře jeho připojení, což způsobí, že jeho TCP odesílá fin (segment 6), který musí klient potvrdit (ACK), zvýšit počet přijatých sekvence (segment 7) na jednotku.

Obrázek 18.4 ukazuje typickou výměnu segmentů při zavírání spojení. Čísla sekvencí jsou publikovány. Na tomto obrázku je z důvodu skutečnosti odeslána, že aplikace uzavírají jejich připojení, zatímco ACK pro tyto ploutve je generován automaticky s TCP softwarem.

Připojení jsou obvykle instalovány klientem, tj. První syn se přesune od klienta na server. Každá strana však může aktivně uzavřít spojení (poslat první fin). Často je však klient, který určuje, když musí být připojení přerušeno, protože proces klienta je spravován hlavně uživatelem, který zadá něco takového "Quit" pro zavření připojení. Na obrázku 18.4 můžeme štítky změnit v horní části obrázku, volání levé strany serverem a na pravé straně klienta. I v tomto případě však vše bude fungovat přesně podle obrázku. (První příklad v kapitole 14, například, ukázal, jak časový server zavře spojení.)

Obrázek 18.4 Normální výměna segmentů při zavírání spojení.

Normální tcpdumpový výstup

Vzhledem k tomu, že úkol řazení obrovského počtu pořadových čísel je poměrně složitý, výstup TCPDUMP obsahuje pouze čísla sekvencí pouze pro segmenty SYG a všechna následující pořadová čísla jsou zobrazena jako relativní posunutí ze zdrojových čísel sekvence. (Aby bylo možné dosáhnout výstupu znázorněného na obrázku 18.1, museli jsme specifikovat možnost -S volbu.) Obvyklý výstup TCPDUMP odpovídající obrázku 18.1 je znázorněn na obrázku 18.5.

1 0.0 SVR4.1037\u003e BSDI.DISCARD: S 1415531521: 1415531521 (0)
Vyhrajte 4096.
2 0.002402 (0.0024) BSDI.DISCard\u003e SVR4.1037: S 1823083521: 1823083521 (0)
ACK 1415531522.
Vyhrajte 4096.
3 0.007224 (0.0048) SVR4.1037\u003e BSDI.DISCARD :. ACK 1 Win 4096
4 4.155441 (4.1482) SVR4.1037\u003e BSDI.discard: F 1: 1 (0) ACK 1 Win 4096
5 4.156747 (0.0013) bsdi.discard\u003e SVR4.1037 :. ACK 2 Vyhrajte 4096
6 4.158144 (0.0014) bsdi.discard\u003e Svr4.1037: F 1: 1 (0) ACK 2 Win 4096
7 4.180662 (0.0225) SVR4.1037\u003e BSDI.DISCARD :. ACK 2 Vyhrajte 4096

Obrázek 18.5 Normální výstup TCPDUMP, což odpovídá zřízení a prasknutí připojení.

Pokud nemáme potřebu ukázat plná sekvenční čísla, použijeme tento výstupní formulář ve všech následujících příkladech.

Time-out při založení spojení

Existuje několik důvodů, proč nelze připojení stanovit. Například hostitel (server) je vypnut. Chcete-li simulovat podobnou situaci, provedli jsme příkaz telnet po odpojení ethernetového kabelu ze serveru. Obrázek 18.6 ukazuje výstup příkazu tcpdump.

1 0.0 bsdi.1024\u003e
Vyhrajte 4096.
2 5.814797 (5.8148) BSDI.1024\u003e SVR4.discard: S 291008001: 291008001 (0)
Vyhrajte 4096.
3 29.815436 (24.0006) BSDI.1024\u003e SVR4.discard: S 291008001: 291008001 (0)
Vyhrajte 4096.

Obrázek 18.6 Zobrazení příkazu tcpdump vytvořit připojení, které bylo zastaveno časovým limitem.

V tomto výstupu musíte věnovat pozornost tomu, jak často klient TCP odešle SYN tím, že se snaží navázat spojení. Druhý segment je odeslán v 5,8 sekundě po prvním a třetí je odeslán po 24 sekundách po druhé.

Je třeba poznamenat, že tento příklad byl zahájen asi 38 minut poté, co byl klient restartován. Proto odpovídající číslo zdroje sekvence je 291008001 (přibližně 38x60x6400x2). Na začátku kapitoly jsme říkali, že typické systémy Berkeley nastavit zdrojový počet sekvencí v 1, a pak ji zvýšit o 64 000 každou polovinu sekundy.

Je třeba také poznamenat, že se jedná o první připojení TCP od okamžiku, kdy byl systém restartován, protože číslo portu klienta je 1024.

Nicméně, na obrázku 18.6 nebylo ukázáno, jak dlouhý klient TCP znovu převede před odmítnutím jeho pokusu. Chcete-li zobrazit tyto časové hodnoty, musíme provést příkaz telnet následovně:

bsdi% datum; Telnet SVR4 zlikvidovat; Datum.
Čt Sep 24 16:24:11 MST 1992
ZKOUŠENÍ 192.82.148.2 ...
telnet: Nelze se připojit k vzdálenému hostiteli: Vypršete připojení
Čt Sep 24 16:25:27 MST 1992

Čas je 76 sekund. Většina systémů Berkeley Nastavte časový limit 75 sekund, během této doby musí být nainstalováno nové připojení. V sekci kapitola 21 uvidíme, že třetí balíček odeslaný klientem bude vyřazen časem na cca 16:25:29, to je 48 sekund po odeslání, zatímco klient se nezastaví pokusy po 75 sekundách.

Poprvé venku

Obrázek 18.6 by měla věnovat pozornost tomu, že první časový limit, 5,8 sekundy, je téměř 6 sekund, ale ne rovná se 6 sekundami, zatímco druhý časový limit je téměř přesně 24 sekund. Bylo provedeno další deset takových testů a v každém z nich se hodnota prvního časového limitu pohybu od 5,59 sekund na 5,93 sekundy. Druhý časový limit však bylo vždy 24.00 sekund.

To je vysvětleno tím, že BSD implementace TCP spustí časovač každých 500 milisekund. Tento časovač 500-milisekund se používá pro různé časové limity TCP, budou všechny popsány v následujících kapitolách. Když zadáme příkaz telnet, je nainstalován počáteční 6-sekundový časovač (12 ticks), ale může vypršet kdekoli mezi 5,5 a 6 sekundami. Obrázek 18.7 ukazuje, jak se to stane.

Obrázek 18.7 500-milisekund TCP časovače.

Vzhledem k tomu, že časovač je nastaven na 12 klíšťat, může se po instalaci vyskytnout první pokles časovače mezi 0 a 500 milisekundami. Z tohoto okamžiku se časovač snižuje přibližně každých 500 milisekund, ale první časové období může být odlišné. (Používáme slovo "přibližně", protože čas, kdy se tcp přijímá management každých 500 milisekund, přibližný, jak to může projít další přerušení, která bude zpracována jádrem.)

Když tento 6-sekundový časovač vyprší na klíště označené 0 na obrázku 18.7, časovač je přeinstalován za 24 sekund (48 klíšťat). Tento další časovač bude roven 24 sekund, protože byl nastaven v té době, kdy se časovač 500-milisekundový TCP nazývá jádro, a nikoli uživatelem.

Servis typu pole

Obrázek 18.6 Vidíme výraz. Jedná se o pole typu servisu (TOS - typ služby) v Datagram IP (). Telnetový klient v BSD / 386 nastaví toto pole tak, aby se minimální zpoždění.

Maximální velikost segmentu

Maximální velikost segmentu (MSS) je největší část dat, které TCP odešle na vzdálený konec. Po nastavení připojení může každá strana deklarovat své MSS. Hodnoty, které jsme viděli, byly 1024. IP Datagram, který bude mít za následek výsledek, obvykle 40 bytů více: 20 bajtů jsou uvedeny v záhlaví TCP a 20 bajtů pod názvem IP.

V některých publikacích se říká, že tato možnost je nastavena "po dohodě". Ve skutečnosti se uspořádání v tomto případě nepoužívá. Když je spojení navázáno, každá strana deklaruje MSS, které bude přijímat. (Možnost MSS lze použít pouze v segmentu SYG.) Pokud jedna strana nepřijímá možnost MSS z druhé strany, použije se výchozí velikost 536 bajtů. (V tomto případě s 8 bajtem IP záhlaví a 20-bajtové TCP záhlaví bude velikost IP Datagram 576 bajtů.)

Obecně, čím více MSS, tím lépe, dokud dojde k fragmentaci. (To není vždy pravda. Viz a aby se ujistil.) Velké velikosti segmentu vám umožní posílat více dat v každém segmentu, což snižuje relativní náklady na záhlaví IP a TCP. Když TCP odešle segment SYG, nebo když chce místní aplikace navázat připojení, nebo když požadavek na připojení ze vzdáleného hostitele lze nastavit na MSS odchozí rozhraní MTU hodnota mínus velikost pevných TCP a IP titulů. Pro Ethernet MSS může dosáhnout 1460 bytů. Při použití enkapsulace IEEE 802.3 (kapitola 2, oddíl) MSS může být až 1452 bajtů.

Hodnota 1024, kterou vidíme v této kapitole, odpovídá spojení, ve kterých jsou zapojeny BSD / 386 a Svr4, protože většina implementací BSD vyžadují MSS být více 512. Ostatní systémy, jako je SUNOS 4.1.3, Solaris 2.2 a AIX 3.2 .2, deklarovat MSS rovnocenné 1460, kdy oba strany jsou na jednom ethernetu. Výpočty uvedené v [Mogul 1993] ukazují, že MSS se rovná 1460 poskytovat lepší výkon na Ethernet než MSS rovnající se 1024.

Pokud IP adresa cíle "není lokální", MSS je obvykle nastavena ve výchozím nastavení - 536. je místní nebo místní cílová cíl následujícím způsobem. Cíl, jejíž adresa IP má stejný identifikátor sítě a stejnou masku podsítě, jak je odesílatel místní; Cíl, jejíž adresa IP je zcela odlišná od identifikátoru sítě, je nonlocal; Cíl se stejným identifikátorem sítě, nicméně, na jiné masce podsítě, může to být místní i ne-místní. Většina implementací poskytuje možnost konfigurace (S), která umožňuje správci systému určit, které podsítě jsou místní a které jsou nonlokální. Nastavení této možnosti určuje maximální hodnotitelné MSS (které v rozsahu může dosáhnout odchozích rozhraní MTU), jinak je výchozí hodnota 536.

MSS umožňuje hostiteli nastavit velikost datagramu, která bude odeslána na vzdálenou stranu. Pokud vezmete v úvahu skutečnost, že hostitel také omezuje velikost Datagram, který odešle, vyhýbá se fragmentaci, když je hostitel připojen k síti s menšími MTU.

Představte si náš kluk hostitel, který má skluzový kanál s MTU rovným 296 připojeným k routeru BSDI. Obrázek 18.8 ukazuje tyto systémy a hostitelské slunce.

Obrázek 18.8 Sluneční spojení TCP ke skluzu a MSS hodnot.

Nainstalovali jsme připojení TCP od Sun na skluzu a prohlížené segmenty pomocí TCPDUMP. Obrázek 18.9 ukazuje pouze zařízení pro připojení (prohlášení o velikosti okna).

1 0.0 Sun.1093\u003e Slip.discard: S 517312000: 517312000 (0)

2 0.10 (0.00) Slip.discard\u003e SUN.1093: S 509556225: 509556225 (0)
ACK 517312001.
3 0.10 (0.00) Sun.1093\u003e Slip.discard :. ACK 1.

Obrázek 18.9 Výstup tcpdump pro vytvoření spojení od Slunce k skluzu.

Je důležité upozornit na skutečnost, že toto slunce nemůže poslat segment s částí dat více než 256 bajtů, protože přijal MSS rovna 256 (řádek 2). Vzhledem k tomu, že Slip ví, že odchozí rozhraní MTU je 296, i když Sun prohlašuje MSS rovna 1460, nikdy nebude moci poslat více než 256 bajtů dat, aby se zabránilo fragmentaci. Systém však může posílat data menší než MSS deklarovaná vzdálenou stranou.

Je možné se vyhnout fragmentaci tímto způsobem pouze v případě, že hostitel je přímo připojen k síti s MTU menší než 576. Pokud jsou oba hostitelé připojeni k Ethernetu a oba oznámí MSS rovnocenné 536, ale mezisměrová síť má MTU rovné 296 , bude provedena fragmentace. Jediný způsob, jak tomu vyhnout, je použití mechanismu definice MTU MTU (kapitola 24, oddíl).

Napůl uzavřený tcp.

TCP poskytuje příležitost pro jeden účastník sloučeniny zastavit přenos dat, ale stále přijímat data ze vzdálené strany. Toto se nazývá polovina uzavřeného TCP. Jak jsme zmínili dříve, může tato příležitost využít málo žádostí.

Chcete-li použít tuto charakteristiku softwarového rozhraní, musíte poskytnout aplikaci s aplikací říci: "Dokončil jsem přenos dat, takže odesílám znak konce souboru (konec-of-file) na dálkové ovládání Konec, ale stále chci přijímat data ze vzdáleného konce k těm, dokud mi neposílá znaménko konce souboru (konec-of-file) (fin). "

Zásuvky API podporují napůl zavřený režim, pokud aplikace spouští vypnutí s druhým argumentem na 1 místo volání zavřít. Většina aplikací, nicméně, burst připojení v obou směrech volání zavřít.

Obrázek 18.10 ukazuje standardní scénář pro poloviční uzavřené TCP. Ukázali jsme klienta na levé straně, iniciuje napůl uzavřený režim, ale to může udělat jakoukoliv stranu. První dva segmenty jsou stejné: z iniciátoru, následovaný ACK a FIN z přijímání. Poté se však skript liší od toho, který je zobrazen na obrázku 18.4, protože strana, která obdržela příkaz "semi-nepořádek", může stále odeslat data. Ukázali jsme pouze jeden segment dat, následovaný ACK, ale v tomto případě lze odeslat libovolný počet datových segmentů. (Podrobněji diskutujeme o výměně datových segmentů a potvrzení v.) Když konec, který obdržel objednávku na "polo-nepořádek", provedl přenos dat, zavře jeho část spojení, což vede k ploutve, zatímco Znaménko konce souboru je doručeno aplikací, která iniciovala režim "Poloviční zavřené". Když je druhé plování potvrzeno, je spojení považováno za zcela uzavřené.

Obrázek 18.10 TCP v polovičním uzavřeném režimu.

Proč lze použít semi-zavřený režim? Jeden příklad může být příkaz UNIX RSH (1), který provede příkaz v jiném systému. tým

slunce% rSH BSDI Seřadit.< datafile

spustí příkaz Sort v hostitele BSDI a standardní záznam příkazu RSH bude čten ze souboru s názvem DataFile. Příkaz RSH vytvoří připojení protokolu TCP a program, který bude proveden na vzdáleném hostiteli. Pak funkce RSH poměrně jednoduše: Příkaz zkopíruje standardní vstup (DataFile) do připojení a kopií z připojení ke standardnímu výstupu (náš terminál). Obrázek 18.11 ukazuje, jak se to stane. (Pamatujeme si, že připojení TCP je plné duplex.)

Obrázek 18.11 Tým: RSH BSDI Seřadit< datafile.

Na vzdáleném hostiteli BSDI se server RSHD server provede třídicí program takovým způsobem, že jeho standardní vstup a standardní výstup jsou odeslány do připojení TCP. Kapitola 14 poskytuje podrobný popis struktury procesu UNIX, která se zde zapojuje, ale máme zájem, jak se používá připojení TCP a poloviční uzavřený režim TCP.

Program třídění nemůže začít generovat výstup, dokud není čten veškerý jeho vstup. Všechny zdrojové daty přicházející připojením z klienta RSH na Sort Server je odeslána do souboru, který musí být tříděn. Když je konec konce souboru dosaženo do ENTER (DataFile), klient RSH provádí poloviční klienta sloučeniny. Seřadný server pak přijímá označení souboru ze svého standardního vstupu (připojení TCP), třídí soubor a zapíše výsledek do svého standardního výstupu (připojení TCP). Klient RSH i nadále číst připojení TCP na jeho konci, kopírování tříděného souboru do svého standardního výstupu.

Bez použití poloviny uzavřeného režimu je nutná některá další technika, která umožní klientovi informovat server, který dokončil datový balík, ale klient je stále povolen přijímat data ze serveru. Alternativně je nutné použít dva sloučeniny, nicméně, s výhodou používat napůl uzavřený režim.

Diagram stavu přenosu TCP

Popsali jsme několik pravidel pro založení a prasknutí připojení TCP. Tato pravidla jsou shromažďována v tabulce pro přenosový stav, který je znázorněn na obrázku 18.12.

Je třeba poznamenat, že tento diagram je schéma standardních stavů. Obvyklým přenosem klienta jsme označili s pevnými tukovými šipkami a obvyklým přenosem serveru s tečkovanými odvážnými šipkami.

Dva přenosy vedoucí ke státnímu nastavení (stanovené) odpovídají otevření spojení a dvě přenosy ze stavu jsou stanoveny (stanoveny), odpovídají odpojení. Stav je nastaven v okamžiku, kdy se zobrazí možnost přenášet data mezi dvěma stranami v obou směrech v obou směrech. Následující kapitoly budou popisovat, co se děje v tomto stavu.

Spojujeme čtyři čtverce v levé dolní části diagramu uvnitř tečkovaného rámu a označili jejich "aktivní zavírání" (aktivní blízko). Dvě další čtverce (čekání na reference - close_wait a last_trevironmental - last_ack) jsou kombinovány s tečkovaným rámečkem a označeny jako "pasivní zavírání" (pasivní blízko).

Jména 11 států (uzavřené - zavřeno, naslouchá - poslouchat, syn_ opakované - syn_sent, a tak dále) v tomto obrázku jsou vybrány tak, aby odpovídaly stavům, které zobrazují příkaz netStat. Jména Netstatu, zase jsou téměř totožné s názvy popsanými v RFC 793. Stav je uzavřen (uzavřený) ve skutečnosti není stát, nicméně, je však počáteční a koncový bod pro diagram.

Změna stavu z poslechu Syn_tener (Syn_Sent) je teoreticky možné, ale není podporován v implementacích Berkeley.

A změna stavu od přijaté_syn (SYN_RCVD) Zpět na poslouchá (poslouchat) je možné pouze v případě, že Stav Receal_Syn (SYN_RCVD) je zadán ze Státem Sloupců (poslouchat) (to je pravidelný skript) a ne z stavu Syn_Sent (Syn_Sent) ) (současný otevření). To znamená, že pokud jsme implementovali pasivní zjišťování (vstupuje do státu - poslouchat), dostali SYN, SYN SYN s ACK (zadal Stát Receal_Syn - SYN_RCVD) a pak dostal reset místo ACK, koncový bod se vrátí do stavu Stát (Poslouchat) a čeká na příchod dalšího požadavku na připojení.

Obrázek 18.12 Diagram změn stavu TCP.

Obrázek 18.13 ukazuje obvyklé zařízení a zavírání připojení TCP. Také podrobně popsány různé stavy, kterým klient a serverový průkaz.

Obrázek 18.13 stavu TCP odpovídající obvyklému otevření a roztržení spojení.

Na obrázku 18.13 jsme navrhli, že klient umístěný na levé straně provádí aktivní otvor a server, který je správný, provádí pasivní otevření. Také jsme ukázali, že klient provádí aktivní uzavření (jak jsme zmínili dříve, každá strana může provádět aktivní uzavření).

Měli byste sledovat změny stavů na obrázku 18.13 Použití státu Změnit datagramy zobrazené na obrázku 18.12, což umožní pochopit, proč se tato změna stavu provede.

2msl čeká stav

Stav čas Time_wait je také někdy nazývá pohotovostní stav 2MSL. Každá implementace je zvolena hodnota pro maximální životnost segmentu (MSL - maximální životnost segmentu). To je maximální doba, během kterého segment může existovat v síti před vyřazením. Víme, že tentokrát je omezená, protože segmenty TCP jsou přenášeny prostřednictvím IP Datagrams a každý IP Datagram má pole TTL, která omezuje svůj životnost.

RFC 793 [Postel 1981c] označuje, že MSL musí být 2 minuty. V různých implementací má tato hodnota hodnotu 30 sekund, 1 minuta nebo 2 minuty.

Bylo řečeno, že doba života IP Datagram byla omezena na počet zásilek, ne časovače.

Při použití MSL se používají následující pravidla: Pokud TCP provádí aktivní uzávěr a odešle poslední segment obsahující potvrzení (ACK), připojení musí zůstat v režimu Time_wait v čase rovnající se dvěma MSL. To umožňuje protokolu TCP znovu odeslat poslední ACK v případě, že první ACK je ztracen (v tomto případě, vzdálená strana bude pracovat časový limit a re-dát své konečné fin).

Další 2MSL přiřazení je, že zatímco připojení TCP čeká na 2msL, dvojice zásuvek zaměřených na toto připojení (IP adresa klienta, číslo portu klienta, číslo IP adresy serveru a číslo portu serveru) nelze znovu použít. Toto připojení lze použít znovu pouze tehdy, když je čekací doba 2msl.

Většina implementací (Berkeley je jeden z nich) dodržovat přísnější požadavky. Ve výchozím nastavení nelze číslo lokálního portu znovu použít, dokud toto číslo portu je místním číslem portového páru zásuvek, který je v pohotovostním režimu 2MSL. Níže se podíváme na příklady obecných požadavků.

Některé implementace a API poskytují finanční prostředky, které nám umožňují obejít tato omezení. Použití zásuvkového rozhraní API lze zadat možnost SO_REUSEADDR Socket. Umožňuje volajícího přiřadit místní číslo portu, který je v 2MSL stavu, uvidíme, že pravidla TCP neumožňují toto číslo portu použít v připojení, která je ve stavu pohotovostního režimu 2MSL.

Každý zpožděný segment přijíždějícím připojením, které je v pohotovostním režimu 2MSL, je vyřazen. Vzhledem k tomu, že spojení je definováno dvojicí zásuvky v stavu 2MSL, nelze toto připojení znovu použít, dokud nebudeme nastavit nové připojení. To se děje, takže pakety nejsou vnímány jako součást nového spojení. (Připojení je určeno dvojicí zásuvky. Nové spojení se nazývá restaurování nebo revitalizace tohoto spojení.)

Jak jsme již ukázali na obrázku 18.13, klient obvykle provádí aktivní uzavření a vstupuje do režimu Time_wait. Server obvykle vykonává pasivní uzavření a neprochází režimem Time_wait. Lze konstatovat, že pokud zrušíme klienta a okamžitě jej přeskupit, tento nový klient nebude moci používat stejné číslo místního portu. V tom není žádný problém, protože zákazníci obvykle používají dynamicky přiřazené porty a nestarají se o to, co je v současné době používán dynamicky přiřazitelný port.

Z pohledu serveru však vše jinak, protože servery používají přednově známé porty. Pokud vypnete server, který má pevné připojení, a budeme se snažit okamžitě renovat, server nemůže používat své dříve známé číslo portu jako koncový bod připojení, protože toto číslo portu je součástí stavu připojení 2MSL. Proto může být nutné od 1 do 4 minut, než bude server rezignován.

Pomocí programu SOCK můžete obviňovat takový scénář. Začali jsme server, připojený k klientovi a poté vypnuto server:

slunce% ponožka -v -s 6666
(Spustíme klienta na BSDI, který bude připojen k tomuto portu)
připojení na 140.252.13.33.6666 z140.252.13.35.1081
^? Zadejte symbol přerušení pro vypnutí serveru
slunce% ponožka 6666. A snažíme se okamžitě poslat server do stejného portu
může "t svázat místní adresu: adresa, která již používaná
slunce% netstat. Pokusme se zkontrolovat stav připojení
Aktivní připojení k internetu
Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)
tcp 0 0 sun.6666 bsdi.1081 time_wait
Mnoho řádků odstraní

Když se snažíme odeslat server, program vydá chybovou zprávu, která označuje, že nemůže zachytit své přednastavené číslo portu, protože se již používá (je v pohotovostním režimu 2MSL).

Pak okamžitě provádíme Netstat, abyste viděli stav připojení a zkontrolujte, zda je ve stavu Time_wait.

Pokud se budeme pokračovat pokoušet o Renue serveru a vidět čas, kdy uspěje, můžeme spočítat hodnotu 2msl. Pro SUNOS 4.1.3, SVR4, BSD / 386 a AIX 3.2.2 je restart serveru 1 minutu, což znamená, že MSL se rovná 30 sekund. V Solaris 2.2 tento restart serveru trvá 4 minuty, znamená to, že MSL je 2 minuty.

Můžeme vidět stejnou chybu generovanou klientem, pokud se klient pokusí zachytit port, který je součástí připojení v pohotovostním režimu 2MSL (obvykle klient neudělá):

slunce% ponožka -v bsdi echo Spusťte klienta, který je připojen k serveru ECHO
připojeno na 140.252.13.33.1162 až 140.252.13.35.7
ahoj. Tiskneme tento řádek
dobrý den, tam se odráží od echo ze serveru
^D. Zadejte konec souboru a vypněte klienta.
slunce% sOCK -B1162 BSDI ECHO
může "t svázat místní adresu: adresa, která již používaná

Při prvním spuštění klienta byla zadána volba -v, která umožňuje zjistit, které číslo portu se používá (1162). S druhým spuštěním klienta byla zadána volba -B, která říká klientovi o potřebě přiřadit se počet místního portu 1162. Jak jsme očekávali, klient nemůže provést, protože toto číslo portu je součástí připojení je v 2msl.

Zde je nutné zmínit jednu funkci stavu čekání 2msl, na které se vrátíme, až budeme říkat o protokolu pro přenos souborů (protokol FTP - přenos souborů). Jak již bylo zmíněno dříve, dvojice zásuvek zůstane v stavu 2msl (skládající se z místní IP adresy, lokálního portu, vzdálené adresy IP a vzdáleného portu). Sada implementací však umožní proces opětovného použití čísla portu, který je součástí připojení umístěného v režimu 2msl (obvykle pomocí volby SO_REUSEADDR), TCP nemůže umožnit vytvoření nového spojení se stejným dvojicí zásuvky. To lze prokázat použití následujícího experimentu:

slunce% ponožka -v -s 6666 Start Server poslechu Port 6666
(Spusťte klienta na BSDI, který je připojen k tomuto portu)
připojení na 140.252.13.33.6666 od 140.252.13.35.1098
^? Zadejte symbol přerušení pro vypnutí serveru
slunce% sOCK -B6666 BSDI 1098 Spuštění klienta s místním portem 6666
může "t svázat místní adresu: adresa, která již používaná
slunce% ponožka -A -B6666 BSDI 1098 Zkuste to znovu, tentokrát s možností -
aktivní otevřená chyba: adresa již používaná

Poprvé jsme spustili náš Sock program jako server k portu 6666 a připojen k klientovi z hostitele BSDI. Počet dynamicky přiřazeného portu portů 1098. Vypnuli jsme server, tedy provedl aktivní uzávěr. Kromě toho 4 parametry - 140.252.13.33 (lokální adresa IP), 6666 (číslo lokálního portu), 140.252.13.35 (vzdálená adresa IP) a 1098 (vzdálené číslo portu) na serveru spadají do stavu 2MSL.

Podruhé jsme spustili tento program jako klienta, určete místní port číslo 6666 a byl proveden pokus o připojení k hostiteli BSDI k portu 1098. Když se pokusíte znovu použít lokální port 6666, byla generována chyba, Vzhledem k tomu, že tento port je ve 2msl.

Aby se zabránilo vzhledu této chyby, jsme program znovu spustili, určete možnost -A, která aktivuje volbu SO_REUSEADDR. To umožnilo program přiřadit číslo portu 6666, ale byla získána chyba, když se program pokusil provést aktivní otvor. I když program může přiřadit číslo portu 6666, nebude moci vytvářet připojení s portem 1098 na hostiteli BSDI, protože dvojice zásuvek definující toto spojení je ve stavu čekání 2MSL.

Co když se snažíme navázat spojení z jiného hostitele? Za prvé, musíme poslat server na slunci s vlajkou -A, protože přístav, který potřebuje (6666), je součástí pohotovostní směsi 2MSL:

slunce% ponožka -a -s 6666 Spusťte server poslechu portem 6666

Poté, než 2MSL Standby Status skončí na Slunce, spustíme klienta na BSDI:

bsdi% sOCK -B1098 Slunce 6666
připojeno na 140.252.13.35.1098 až 140.252.13.33.6666

Bohužel to funguje! Jedná se o nedostatek specifikací TCP, nicméně, většina podporovaná většinou implementací Berkeley. Tyto implementace vnímají příchod žádosti o nové připojení k připojení, což je v stavu Time_wait, pokud je nové pořadové číslo větší než poslední pořadové číslo použité v předchozímu připojení. V tomto případě je ISN pro nové připojení nastaveno na poslední pořadové číslo pro předchozí připojení plus 128000. Aplikace na RFC 1185 ukazuje možné nevýhody této technologie.

Tato implementace umožňuje klientovi a serverům znovu použít stejné čísla portů, aby úspěšně obnovili stejné připojení, v případě, že server nevykonával aktivní uzavření. Při diskusi o FTP uvidíme další příklad čekajícího státu 2msl. Také odkazují na tuto kapitolu.

Koncept tichého času

Stav čekajícího 2MSL poskytuje ochranu proti pozdním paketům patřícím k časným připojením, a nebudou interpretovány jako součást nového připojení, která používá stejné místní a vzdálené adresy IP a čísla portů. To však funguje pouze v případě, že hostitel s připojením je ve stavu 2MSL, nezdařil.

Co když hostitel s porty ve stavu 2MSL se nezdařil, restartován během MSL a okamžitě nastavit nové připojení pomocí stejných lokálních a vzdálených adres IP a čísel portů odpovídající místním portům, které byly 2MSL před poruchami? V tomto případě mohou být pozdní segmenty ze sloučeniny, které existovaly před porušením, mohou být chybně interpretovány jako patřící k nové sloučenině vytvořené po restartu. To může dojít bez ohledu na to, které zdrojové sekvence je vybráno po restartu.

Pro ochranu před takovými nežádoucími scénáři RFC 793 označuje, že protokol TCP by neměly vytvářet nové připojení před vypršením MSL po načtení. To se nazývá klidná doba.

V některých implementacích očekávají hostitelé ještě delší než čas MSL po restartu.

Čekání stav_i_forification_fin (fin_wait_2)

Ve stavu Fin_wait_2 posíláme naše ploutve a vzdálená strana to potvrzuje. Pokud nejsme v polovičním uzavřeném stavu, očekáváme od aplikace na dálkovém konce, že uznává příjem atributu konce souboru a zavře svou stranu připojení a pošlete nám plout. Pouze v případě, že proces na dálkovém konce bude tento uzávěr vezme, naše strana přepne z režimu Final_wait_2 do režimu Time_wait.

To znamená, že naše strana spojení může zůstat v tomto režimu navždy. Vzdálená strana je stále v close_wait stavu a může vždy zůstat v tomto stavu, pokud aplikace nevyřeší uzavření.

Většina implementací Berkeley zabraňuje takovému věčnému čekání ve stavu FIN_WAIT_2 následovně. Pokud aplikace, která uplatnila aktivní uzávěr, plně uzavřená, a nikoli semi-konverzí, což znamená, že očekává příjem dat, v tomto případě je časovač nastaven. Pokud se připojení nepoužívá do 10 minut a 75 sekund, TCP překládá připojení k uzavřenému režimu (uzavřeno). Komentáře uvádějí, že taková charakteristika odporuje specifikací protokolu.

Resetové segmenty (reset)

Zmínili jsme se, že v hlavičce TCP je trochu nazýván RST, což znamená "reset" (reset). V obecném případě je signál "reset" (reset) odesílán do protokolu TCP, pokud příchozí segmenty nepatří do zadaného připojení. (Používáme termín "specifikované připojení" (odkazované připojení), což označuje připojení, které je identifikováno IP adresou cíle a číslem cílového portu, stejně jako zdrojové IP adresy a číslem zdrojového portu. V RFC 793, to se nazývá "Zásuvka".)

Žádost o připojení k neexistujícímu portu

Nejobecnější případ, ve kterém je generován reset, je to, když přijde požadavek na připojení a neexistuje proces, který poslouchá cílový port. V případě UDP, jak jsme viděli v sekci Kapitola 6, pokud dárek dorazí do nepoužitého cílového portu - chyba ICMP je generována o nedostupnosti portu. TCP místo toho používá reset.

Uveďte jednoduchý příklad pomocí klienta Telnet, určete číslo portu, který se nepoužívá v cíli:

bsdi% telnet SVR4 20000. Port 20 000 není použito
ZKOUŠENÍ 140.252.13.34 ...
telnet: Nelze se připojit k vzdálenému hostiteli: Připojení odmítnuto

Okamžitě se vydává chybová zpráva klienta Telnet. Obrázek 18.14 ukazuje výměnu balíčků odpovídající tomuto příkazu.

1 0.0 BSDI.1087\u003e SVR4.20000: S 297416193: 297416193 (0)
Vyhrajte 4096.
2 0.003771 (0.0038) SVR4.20000\u003e BSDI.1087: R 0: 0 (0) ACK 297416194 Vyhrajte 0

Obrázek 18.14 Resetování generování při pokusu o otevření připojení k neexistujícímu portu.

Hodnoty, které musíme zvážit podrobněji v tomto obrázku, jsou pole pořadové číslo a pole potvrzení číslo v resetu. Vzhledem k tomu, že potvrzovací bit (ACK) nebyl nainstalován do dorazeného segmentu, číslo resetovací sekvence je nastaveno na 0 a číslo potvrzení je nastaveno na příchozí zdrojové sekvence číslo (ISN) plus množství datových bajtů v segmentu. Navzdory skutečnosti, že v dorazovém segmentu nejsou skutečná data, Syn Bit logicky zabírá 1 bajt v pořadovém čísle; V tomto příkladu je v tomto příkladu instalováno číslo potvrzení v ISN plus délku dat (0) plus jeden bit Syn.

Lámání spojení

V této kapitole jsme viděli, že obvyklá metoda používaná k porušení spojení je, že jedna část odesílá fin. Někdy se nazývá správné vydání (řádné uvolnění), protože fin je odeslána po odeslání všech údajů, které byly odeslány, a obvykle nedojde ke ztrátě dat. Existuje však možnost přerušení připojení, odesílání resetu (reset) namísto fin. Někdy se nazývá přerušení uvolňování (abortivní uvolnění).

Taková propustnost připojení poskytuje přílohu dvou vlastností: (1) Všechna data za fronty - jsou ztracena a reset je odeslán okamžitě a (2) Složení přijaté RST může říci, že vzdálená strana porušila připojení, namísto zavření obvyklým způsobem. Programovací rozhraní (API), které používají aplikací, musí poskytnout způsob, jak generovat podobný reset místo normálního uzavření.

Můžeme vidět, co se stane v případě podobné přestávky, pomocí našeho programu Sock. Zásuvky API poskytují tuto funkci pomocí volby závěrečné zpoždění zásuvky (SO_LINGER). Ukazovali jsme možnost -L volbu se zpožděním rovnou 0. To znamená, že reset bude odeslán namísto obvyklého ploutvu k uzavření připojení. Připojujeme se k programu SOCK, který působí jako server, na SVR4:

bsdi% ponožka -l0 SVR4 8888 Jedná se o klient; Server je uveden na adrese
ahoj světe. Zadejte jeden řádek, který bude odeslán na vzdálený konec
^D. Zadejte konec souboru a vypněte klienta.

Obrázek 18.15 ukazuje výstup příkazu TCPDUMP pro tento příklad. (Smazáme všechny výpisy oken na tomto obrázku, protože nemají vliv na naše uvažování.)

1 0.0 BSDI.1099\u003e SVR4.8888: S 671112193: 671112193 (0)

2 0.004975 (0.0050) SVR4.8888\u003e BSDI.1099: S 3224959489: 3224959489 (0)
ACK 671112194.
3 0.006656 (0.0017) BSDI.1099\u003e SVR4.8888 :. ACK 1.
4 4.833073 (4.8264) BSDI.1099\u003e SVR4.8888: P 1:14 (13) ACK 1
5 5.026224 (0.1932) SVR4.8888\u003e BSDI.1099 :. ACK 14.
6 9.527634 (4.5014) BSDI.1099\u003e SVR4.8888: R 14:14 (0) ACK 1

Obrázek 18.15 Připojení pomocí resetu (RST) namísto fin.

V řádcích 1-3 je zobrazeno obvyklé spojení. Linka 4 je odeslána řadu dat, které jsme zadali (12 znaků Plus Unix Nový řetězec symbol) a v řádku 5 dorazí potvrzení o příjmu dat.

Řádek 6 odpovídá zadanému symbolu souboru (Control-D), se kterým jsme klient vypnuli. Vzhledem k tomu, že jsme ukázali přestávku namísto normálního uzavření (volba příkazového řádku -L0), TCP na BSDI odešle RST místo obvyklého plnění. Segment RST obsahuje číslo sekvence a číslo potvrzení. Všimněte si také, že RST segment neočekává odpověď ze vzdáleného konce - neobsahuje potvrzení vůbec. Reset příjemce přeruší připojení a hlásí aplikaci, že spojení bylo přerušeno.

Ze serveru dostaneme následující chybu s takovou výměnou:

sVR4% sock -s 8888. Spustit jako server, poslouchejte port 8888
dobrý den, svět je něco, co poslal klienta
přečtěte si chyba: reset připojení peer

Tento server čte ze sítě a zkopíruje vše ke standardnímu výstupu. Obvykle dokončí svou práci, když obdržel znamení konce souboru z jeho TCP, ale tady vidíme, že dostal chybu při příjezdu RST. Chyba To je přesně to, co jsme očekávali: spojení bylo přerušeno jedním z účastníků sloučeniny.

Stanovení polo-otevřené připojení

Předpokládá se, že připojení TCP je napůl otevřeno, pokud jedna strana uzavřená nebo přerušila spojení bez oznamování druhé strany. To se může stát kdykoliv, pokud jeden ze dvou hostitelů selže. Od nějakého okamžiku nebudou pokusy sdělit údaje o polo-otevřeném spojení, jeden ze stran bude fungovat, dokud neujistí, že vzdálená strana selhala.

Dalším důvodem, pro které může dojít k polovičnímu otevření, je, že klient byl vypnut na hostitele klienta, namísto placení klientské aplikace a potom vypnout počítač. To se stane, například klient telnet běží na počítači a uživatelé vypnou počítač na konci pracovního dne. Pokud počítač není přenášen v době vypnutí, server se nikdy neučí, že klient zmizel. Když uživatel přijde další ráno, zapne počítač a spustí nový klient telnet, nový server začíná na hostiteli serveru. Z tohoto důvodu se na hostiteli serveru může objevit mnoho otevřených připojení TCP. (Ve vidíme metodu, se kterými může jeden konec připojení TCP určit, že druhý zmizel. To se provádí pomocí možností TCP "Zůstaňte naživu" (KeepAlive)).

Můžeme snadno vytvořit poloviční spojení. Spouštíme klienta Telnet na BSDI a připojte se k serveru Zhořízení na SVR4. Zadejte jeden řádek a zobrazí se pomocí TCPDUMP, jak to prochází, a pak odpojte ethernetový kabel ze serveru hostitele a restartujte jej. Tím nejvíce napodobuje selhání hostitele serveru. (Před restartováním serveru odpojujeme před restartováním serveru tak, aby neposílal fin do otevřeného připojení, které provádí některé moduly TCP při vypnutí.) Po restartování serveru jsme připojili kabel a pokusili jsme se odeslat další řádek od klienta na server. Vzhledem k tomu, že server byl restartován a ztratil všechna data o připojení, která existovala před restartováním, neví nic o připojení a nemá podezření, co souvisí dorazené segmenty. V tomto případě reaguje přijímající strana TCP s resetem (reset).

bsdi% telnet SVR4 Zlikvidujte. Spuštění zákazníka
ZKOUŠENÍ 140.252.13.34 ...
Připojen k SVR4.
Escape charakter je "^]".
ahoj Tato linka je odeslána normálně
Na tomto místě jsme restartujeli hostitelský server
další řádek Na tomto místě bylo resetováno (reset)
Spojení uzavřené zahraničním hostitelem.

Obrázek 18.16 ukazuje výstup TCPDUMP pro tento příklad. (Smazat okna z výstupu, informace o typu služby a reklamy MSS, protože nemají vliv na naše uvažování.)

1 0.0 BSDI.1102\u003e SVR4.discard: S 1591752193: 1591752193 (0)
2 0.004811 (0.0048) SVR4.discard\u003e BSDI.1102: S 26368001: 26368001 (0)
ACK 1591752194.
3 0.006516 (0.0017) BSDI.1102\u003e SVR4.discard :. ACK 1.

4 5.167679 (5.1612) BSDI.1102\u003e SVR4.discard: P 1:11 (10) ACK 1
5 5.201662 (0.0340) SVR4.discard\u003e BSDI.1102 :. ACK 11.

6 194.909929 (189.7083) BSDI.1102\u003e SVR4.discard: P 11:25 (14) ACK 1
7 194.914957 (0.0050) Arp, který má BSDI říct Svr4
8 194.915678 (0.0007) ARP Odpovědět BSDI je-na 0: 0: C0: 6F: 2D: 40
9 194.918225 (0.0025) SVR4.discard\u003e BSDI.1102: R 26368002: 26368002 (0)

Obrázek 18.16 Reset v reakci na příchod segmentu dat s polo-otevřené připojení.

V řádcích 1-3 se provádí obvyklé spojení. Linka 4 jde řetězec "Ahoj tam" (to může být zhruba přeloženo jako "Hey You, tam") na serveru Discard, v řádku 5 potvrzení přijde.

V tomto místě jsme odpojili ethernetový kabel od SVR4, restartujte jej a znovu připojil kabel. Celý postup obsazený asi 190 sekund. Pak jsme publikovali následující vstupní řádek na klientovi ("jiný řádek") a když jsme stiskli návratový klíč, řetězec byl odeslán na server (řádek 6 na obrázku 18.16). Současně byla reakce ze serveru přijata, protože server byl restartován, jeho mezipaměť ARP je prázdná, takže v řádcích 7 a 8 vidíme požadavek ARP a reakce. Poté byl reset (reset) odeslán v řádku 9. Obnovení klienta a vydaných, že spojení bylo přerušeno vzdáleným hostitelem. (Poslední zpráva výstupu z klienta Telnet není tak informativní, jak by to mohlo být.)

Simultánní objev

Pro dvě aplikace je možné provést aktivní otvor současně. Každá strana musí být převedena do SYN a tyto SYN musí projít sítí směrem k sobě. Je také nutné, aby každá strana má číslo portu, který je známý na druhé straně. To se nazývá simultánní otvor (současný otevřený).

Například aplikace na hostiteli A mít lokální port 7777 provede aktivní otevření hostitelského portu 8888 V. Aplikace na hostiteli do místního portu 8888 provádí aktivní otevření hostitele 7777 A.

Toto není stejné jako připojení klienta Telnet z hostitele A na serveru Telnet na hostiteli v hostiteli, zatímco klient telnet z hostitele je připojen k serveru Telnet na hostiteli A. V takovém scénáři, oba telnet servery nesou Zjistěte pasivní objev, a není aktivní, zatímco klienti TELNET přiřaďte dynamicky přiřazené čísla portů a ne porty, které jsou známé pro vzdálené servery telnet.

TCP je speciálně navržen tak, aby zpracoval současný objev, zatímco výsledkem je jedna sloučenina, ne dva. (V jiných rodinách protokolu, například na úrovni dopravy OSI, v tomto případě jsou vytvořeny dvě sloučeniny, a nikoliv.)

Když se provádí současný otvor, změny stavu protokolu se liší od těch, které jsou uvedeny na obrázku 18.13. Oba konce jsou zasílány současně syn, při vstupu do stavu syn_sent (syn_sent). Když každá strana přijímá SYN, stav se změní na SYN_CH (SYN_RCVD) (viz obrázek 18.12) a každý konec znovu odesílá SYN potvrzující, že SYN potvrzuje. Když každý konec přijímá SUN plus ACK, změní se stav nainstalován (zaveden). Změny jsou zobrazeny na obrázku 18.17.

Obrázek 18.17 Výměnné segmenty v procesu simultánního otvoru.

Simultánní objev vyžaduje výměnu čtyř segmentů, jeden více než s "tříčasovým handshake". Všimněte si také, že neolýváme jeden z konců klienta a jiný server, protože v tomto případě fungují jako klient a jako server.

Implementovat simultánní objev je možné, ale je to docela obtížné. Obě strany by měly být spuštěny přibližně ve stejnou dobu, takže se s nimi protíná. V tomto případě může pomoci velkou dobou návratu mezi oběma účastníky spojení, což umožňuje syn Cross. Chcete-li to získat, používáme BSDI hostitelského člena jako jeden účastník a další hostitele vangogh.cs.berkeley.edu. Vzhledem k tomu, že existuje skluzový kanál s vytáčením mezi nimi, doba návratu by měla být poměrně velká (několik set milisekund), které umožňuje syn k kříži.

Jeden konec (BSDI) přiřadí lokální port 8888 (možnost příkazového řádku -B) a provádí aktivní otevření jiného hostitele k portu 7777:

bsdi% ponožka -v -b8888 vangogh.cs.berkeley.edu 7777
připojeno na 140.252.13.35.8888 až 128.32.130.2.77777
Tcp_maxseg \u003d 512.
ahoj světe. Zadáváme tento řádek
a hi tam tento řádek byl vytištěn na druhém konci
připojení uzavřené peerem je závěr, když bylo přijato ploutve

Další konec byl zahájen přibližně ve stejnou dobu, jmenoval místní číslo přístavu 7777 a provedl aktivní otevírání přístavu 8888:

vangogh% ponožka -v -b7777 bsdi.tuc.noao.edu 8888
připojeno na 128.32.130.2.7777 na 140.252.13.35.8888
Tcp_maxseg \u003d 512.
dobrý den, svět, který je zapsán na druhém konci
a Ahoj tam Tištěně jsme vytiskli
^D. A pak zadal soubor EOF

Ukázali jsme vlajku -v vlajku na příkazovém řádku Sock a zkontrolovat adresy IP a čísla portů pro každý konec připojení. Tato vlajka také vytiskne MS, používané na každém konci připojení. Také jsme vytištěni jako vstupní řádek na každém konci, který byl odeslán na vzdálený konec a vytištěn tam, aby se ujistil, že oba hostitelé jsou navzájem "vidět".

Obrázek 18.18 ukazuje výměnu segmentů pro tuto sloučeninu. (Vymazali jsme některé nové možnosti TCP, které se objevily v původní SYN přišel z Vangegh, který běží běží 4.4BSD. Tyto nové možnosti popisujeme v části této kapitoly.) Vezměte prosím na vědomí, že dvě SYN (řádky 1 a 2) následují Dva Syn s ACK (řetězce 3 a 4). Zároveň existuje současný objev.

Řádek 5 ukazuje zavedený řetězec "Ahoj, World", který pochází z BSDI do Vangegho s potvrzením v řádku 6. řádky 7 a 8 odpovídají řetězci "a hi-theret", který jde jiným směrem. Řádky 9-12 ukazuje obvyklé uzavření spojení.

Většina implementací Berkeley nepodporuje simultánní otevření. V těchto systémech, pokud můžete dosáhnout, že SYN bude kříž, vše skončí výměnou segmentů, z nichž každá se SYN a ACK, v obou směrech. Většina implementací není vždy přechod ze stavu SYN_SENT na stav SYN_RCVD zobrazený na obrázku 18.12.

1 0.0 BSDI.8888\u003e Vangish.7777: S 91904001: 91904001 (0)
Vyhrajte 4096.
2 0.213782 (0.2138) Vangogh.7777\u003e BSDI.8888: S 1058199041: 1058199041 (0)
Vyhrajte 8192.
3 0.215399 (0.0016) BSDI.8888\u003e Vangogh.7777: S 91904001: 91904001 (0)
ACK 1058199042 Vyhrajte 4096

4 0.340405 (0.1250) Vangoh.7777\u003e BSDI.8888: S 1058199041: 1058199041 (0)
ACK 91904002 Vyhrajte 8192

5 5.633142 (5.2927) BSDI.8888\u003e Vangogh.7777: P 1:14 (13) ACK 1 Win 4096
6 6.100366 (0.4672) Vangogh.7777\u003e BSDI.8888 :. ACK 14 Vyhrajte 8192

7 9.640214 (3.5398) Vangogh.7777\u003e BSDI.8888: P 1:14 (13) ACK 14 Vyhrajte 8192
8 9.796417 (0.1562) BSDI.8888\u003e Vangogh.7777 :. ACK 14 Vyhrajte 4096

9 13.060395 (3.2640) Vangoh.7777\u003e BSDI.8888: F 14:14 (0) ACK 14 Vyhrajte 8192
10 13.061828 (0.0014) BSDI.8888\u003e Vangogh.7777 :. ACK 15 Vyhrajte 4096
11.079769 (0.0179) BSDI.8888\u003e Vangogh.7777: F 14:14 (0) ACK 15 Win 4096
12 13.2999940 (0.2202) Vangogh.7777\u003e BSDI.8888 :. ACK 15 Vyhrajte 8192

Obrázek 18.18 Segmenty výměny se současným otevřením.

Simultánní uzavření

Jak jsme říkali dříve, na jedné straně (často, ale ne vždy, od klienta), aktivní uzavření se provádí a první ploutve je odeslána. Je také možné, aby obě strany provádějí aktivní uzávěr, neboť protokol TCP umožňuje současné uzavření (simultánní blízko).

V termínech uvedených na obrázku 18.12 se oba konce pohybují ze stavu (zavedeného) ke stavu Waiting_Fin_1 (FIN_WAIT_1), když aplikace zobrazí signál k uzavření. Současně posílají ploutve, které mohou být objeveny někde v síti. Když je fin přijata, každý konec nastane z stavu final_wait_1 na zavírací stav (zavírání) a finální ACK je zaslána na každou část. Když každý konec obdrží konečnou ACK, stav se změní na Time_Wait. Obrázek 18.19 ukazuje změny stavu.

Obrázek 18.19 Segmenty výměny v procesu současného uzavření.

S současným uzávěrem je stejný počet paketů splněn jako za normálního uzavření.

TCP titul může obsahovat možnosti (). Jediné možnosti, které jsou definovány v původní specifikaci TCP, jsou následující: Konec seznamu možností, bez provozu a maximální velikost segmentu. Viděli jsme v našich příkladech, možnost MSS je téměř v každém segmentu SYG.

Nejnovější RFCS, jako je RFC 1323, definují další možnosti TCP, z nichž většina může být zjištěna pouze v pozdějších implementacích. (Popisujeme nové možnosti v.) Obrázek 18.20 ukazuje formát aktuálních možností TCP - ty, které jsou popsány v RFC 793 a RFC 1323.

Obrázek 18.20 Možnosti TCP.

Každá volba začíná typem 1 bajtů (druh), která označuje typ volby. Možnosti, jejichž typ je 0 a 1, zabírají 1 bajt. Další možnosti mají bajt délky (LEN), který následuje bajt typu. Délka je plná délka, včetně typu a délky bajtů.

Možnost "Žádná operace" (NOP) přidána tak, že odesílatel může vyplnit pole, která musí být více 4 bajty. Pokud nastavíme připojení TCP z systému 4.4BSD, v počátečním segmentu SYG pomocí TCPDUMP můžete zobrazit následující možnosti:

Možnost MSS je nastavena na hodnotu 512, následovaná NOP, následuje možnost Velikost okna. První možnost NOP se používá k doplnění velikosti 3 bajtů až 4 bajty. Stejně tak, že možnost 10 bajtů dočasné značky předchází dva nop, aby se 12 bajtů.

Čtyři další možnosti, které odpovídají typu rovné 4, 5, 6 a 7, se nazývají možnosti selektivních možností ACK a echo. Neznámí jsme je na obrázku 18.20, protože možnosti echo jsou nahrazeny možností dočasné značky a selektivní ACKS, jak je definováno v současné době, jsou stále v diskusi a nebyly zahrnuty do RFC 1323. Je třeba poznamenat, že t / TCP nabídka pro transakce TCP (oddíl kapitoly 24) označuje tři další možnosti s typy rovnými 11, 12 a 13.

Prodejní server TCP implementace

V sekci Kapitola 1 jsme říkali, že většina TCP serverů je konkurenceschopná. Pokud do serveru přichází nové připojení, přijímá připojení a spustí nový proces, který bude sloužit novému klientovi. V závislosti na operačním systému se používají různé způsoby vytvoření nového serveru. V systémech UNIX je vytvořen nový proces pomocí funkce vidlice.

Musíme diskutovat o tom, jak TCP spolupracuje s konkurenčními servery. Chtěl bych odpovědět na následující otázku: Jak se jedná o číslo přístavu, když server obdrží nové připojení k klientovi, a co se stane, pokud se několik požadavků na připojení dorazí současně?

TCP Server Ports.

Můžeme říci, jak TCP zpracovává čísla portu zvažením jakéhokoli serveru TCP. Zvažte server Telnet pomocí příkazu NetStat. Následující závěr je uveden pro systém, který nemá aktivní připojení telnet. (Vymazali jsme všechny řetězce s výjimkou toho, která ukazuje server telnetu.)

slunce% nETSTAT -A -N -N -F INET
Aktivní připojení k Internetu (včetně serverů)
Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)
tCP 0 0 * .23 *. * Poslouchejte

Flag -A hlásí všechny koncové body sítě, a to nejen o instalaci (založeno). Vlajka -N Vlajka vytiskne adresy IP v digitální desítkové reprezentaci, namísto použití DNS převést adresy na jména a tiskne čísla digitálních portů (například 23) namísto tisku tiskového tisku (v tomto případě telnet). Možnost -F -FET Option hlásí pouze na koncových bodech TCP a UDP.

Místní adresa se zobrazí jako * .23, kde se hvězdička obvykle nazývá substituční symbol nebo Metachamir. To znamená, že požadavek na příchozí připojení (SYN) bude přijata z libovolného místního rozhraní. Pokud má hostitel více rozhraní, mohli bychom určit jednu konkrétní adresu IP jako lokální IP adresu (jeden z adresních adres IP) a budou doručeny pouze požadavky na připojení z tohoto rozhraní. (Uvidíme, jak se provádí, později v této části.) Místní port je 23, jedná se o přednově známý port pro Telnet.

Dálková adresa je zobrazena jako *. *, To znamená, že vzdálená adresa IP a číslo vzdáleného portu není zatím známo, protože koncový bod je ve stavu Stát (poslouchat), čeká na příchod požadavku na připojení.

Nyní spustíme telnetový klient na skluzu (140.252.13.65), který bude připojen k tomuto serveru. Zde jsou odpovídající řádky příkazu netstat:

tCP 0 0 0 140.252.13.33.23 140.252.13.65.1029
tCP 0 0 * .23 *. * Poslouchejte

První řetězec pro port 23 je nainstalované připojení (založeno). Pro toto připojení jsou všechny čtyři prvky místních a vzdálených adres vyplněny: lokální IP adresa a číslo portu a vzdálené IP adresy a číslo portu. Lokální IP adresa odpovídá rozhraní, ke kterému dorazil požadavek na připojení (rozhraní Ethernet, 140.252.13.33).

Koncový bod zůstal ve stavu poslechu. Toto je koncový bod, který konkurenční server používá, aby bylo možné přijmout požadavky na připojení, které přijdou v budoucnu. V tomto případě modul TCP v jádře vytvořil nový koncový bod ve stanoveném stavu v době, kdy příchozí požadavek na připojení přijel a byl přijat. Všimněte si také, že číslo portu pro připojení, které je ve stanoveném stavu se nezměnila: je rovna 23, jako pro koncový bod, který je v poslechu.

Nyní začneme další telnetový klient ze stejného klienta (skluzu) na tento server. Odpovídající výstup příkazu netstat bude vypadat takto:

Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)
tCP 0 0 140.252.13.33.23 140.252.13.65.1030 Založeno
tCP 0 0 0 140.252.13.33.23 140.252.13.65.1029
tCP 0 0 * .23 *. * Poslouchejte

Nyní vidíme dvě instalované (zavedené) připojení ze stejného hostitele na stejném serveru. Oba mají místní číslo portů rovné 23. Toto není problém pro protokol TCP, protože vzdálená čísla portů jsou jiná. Musí být odlišné, protože každý klient telnet používá dynamicky přiřazitelný port a z definice dynamicky přiřazeného portu, víme, že pouze jeden port, který není aktuálně používán na hostiteli, může být dynamicky přiřazen hostiteli (skluzu).

Tento příklad ukazuje, že příchozí segmenty DemultIplexy TCP pomocí všech čtyř hodnot, které jsou porovnávány s místními a vzdálenými adresami: IP adresa cíle, číslo cílového portu, adresu IP zdroje a číslo zdrojového portu. TCP nemůže určit, který proces je příchozí segment přijímán zobrazením pouze čísla cílového portu. Také pouze jeden ze tří koncových bodů na portu 23, který je v režimu poslechu, přijímá příchozí dotazy pro připojení. Koncové body, které jsou ve stanoveném stavu, nemohou přijímat segmenty SYG a koncový bod ve stavu poslechu nemůže přijímat datové segmenty.

Nyní začneme další telnetový klient z hostitele Solaris, který projde přes kluzný kanál ze Slunce, a ne přes Ethernet.

Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)
tCP 0 0 140.252.1.29.23 140.252.1.32.34603 Založeno
tCP 0 0 140.252.13.33.23 140.252.13.65.1030 Založeno
tCP 0 0 0 140.252.13.33.23 140.252.13.65.1029
tCP 0 0 * .23 *. * Poslouchejte

Místní IP adresa pro první nastavení (zavedené) nyní odpovídá adresu rozhraní skluzu kanálů na hostiteli Sun Multi-Interface (140.252.1.29).

Umístění místních adres IP

Můžeme vidět, co se stane, když server nepoužívá symboly substituce jako místní adresy IP, instalace jedné konkrétní adresy místního rozhraní místo. Pokud zadáme adresu IP (nebo název hostitele) naším programem SOCK při použití jako server, tato adresa IP se stane lokální IP adresou koncového bodu poslechu. například

slunce% sock -s 140.252.1.29 8888

omezuje tento server pouze pro připojení přicházející s rozhraním Slip (140.252.1.29). Příkazový výstup NetStat zobrazí následující:

Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)

Pokud se připojíme k tomuto serveru přes kluzný kanál z hostitele Solaris, bude to fungovat.

Proto Recv-Q Send-Q Místní adresa Zahraniční adresa (stát)
tCP 0 0 140.252.1.29.8888 140.252.1.32.34614 Založeno
tCP 0 0 0 140.252.1.29.8888 *. * Poslouchejte

Pokud se však snažíme připojit k tomuto serveru z hostitele přes Ethernet přes Ethernet (140.252.13), požadavek na připojení nebude přijímán modulem TCP. Pokud se podíváme s TCPDUMP, uvidíme, že RST odpověď se získá na SYN, jak je znázorněno na obrázku 18.21.

1 0.0 BSDI.1026\u003e SUN.8888: S 3657920001: 3657920001 (0)
Vyhrajte 4096.
2 0.000859 (0.0009) Sun.8888\u003e BSDI.1026: R 0: 0 (0) ACK 3657920002 Vyhrajte 0

Obrázek 18.21 Omezení požadavků na připojení na základě lokální IP adresy serveru.

Aplikace běžící na serveru nikdy neuvidí požadavek na připojení - omezení se provádí modulem TCP v jádře na základě lokální adresy IP určené aplikací.

Omezení adresy IP adresy IP

V sekci Kapitola 11 jsme viděli, že server UDP může definovat vzdálenou adresu IP adresy a číslo portu, kromě zadaného lokálního adresy IP a číslo portu. Funkce rozhraní uvedené v RFC 793 umožňují serveru provést pasivní otvor založený na plně popsané vzdálené zásuvce (v tomto případě se očekává požadavek na aktivní otvor z konkrétního klienta) nebo neuvedené vzdálené zásuvky (v tomto případě, Očekává se požadavek na připojení z libovolného klienta).

Nejvíce API bohužel neposkytuje takové příležitosti. Server musí opustit vzdálenou zásuvku nespecifický, čeká na příchod připojení a poté zaškrtnutí adresy IP a číslo klientského portu.

Obrázek 18.22 ukazuje tři typy adres a propojení adres s porty, které může Server TCP nastavit pro sebe. Ve všech případech je Lport je předznámý serverový port serveru a lokalitou musí být IP adresa místního rozhraní. Objednávka, ve kterém jsou tři řádky umístěny v tabulce, odpovídá pořadí, ve kterém se modul TCP pokusí určit, který místní koncový bod obdrží příchozí požadavek na připojení. Nejprve se provede pokus o první řádek tabulky (pokud je podporován), a pak zbytek specifikací (poslední řádek s adresami IP zadaných ve formě substitučních symbolů) je poslední.

Obrázek 18.22 Zadání lokálních a vzdálených IP adres a čísel porostů pro server TCP.

Zahrnuty požadavky na připojení

Konkurenční server spustí nový proces, který slouží ke každému klientovi, takže poslechový server musí být vždy připraven zpracovat další požadavek na příchozí připojení. To je hlavní důvod, proč se používají konkurenční servery. Existuje však možnost, že několik požadavků na připojení dorazí právě v okamžiku, kdy je poslechový server vytvoří nový proces, nebo když je operační systém obsazen zpracováním dalšího procesu s vyšší prioritou. Jak proces TCP zpracovává požadavky na příchozí připojení, zatímco posluchač je obsazen?

Implementace Berkeley používají následující pravidla.

1. Každý koncový bod poslechu má pevnou délku připojení fronty připojení, která může být provedena pomocí protokolu TCP ("tříčasový handshake" je dokončena), ale dosud není potvrzena. Buďte opatrní, vedení rozlišování mezi přijetím připojení TCP a místnosti ve frontě a aplikace přijímání připojení z této fronty.
2. Aplikace určuje omezení nebo limit pro tuto frontu, která se běžně nazývá Backlog. Toto omezení by mělo být v rozsahu od 0 do 5. (většina aplikací označuje maximální hodnotu rovnou 5.)
3. Když přijde požadavek na připojení (SYN segment), zobrazí TCP aktuální počet připojení nastavené v okamžiku, kdy do fronty pro tento koncový bod poslechu, zatímco zjistí, zda je možné přijmout připojení. Očekáváme, že hodnota nezálohopisu určeného aplikací bude maximálně, to znamená, že pro tento bod je povoleno vložit maximální počet připojení, i když to není příliš jednoduché. Obrázek 18.23 ukazuje vztah mezi hodnotou Backlog a skutečným maximálním počtem připojení, které mohou být ve frontě v tradičních systémech Berkeley a Solaris 2.2.

   hodnota Backlog.	Maximální počet sadních sloučenin
   	Tradiční BSD.

   Obrázek 18.23 Maximální počet připojení přijatých pro koncový bod poslechu.

   Nezapomeňte, že tato hodnota Backlog označuje pouze maximální počet připojení ve frontě pro jeden koncový bod poslechu, z nichž všechny jsou již přijaty pomocí protokolu protokolu TCP a očekávají, že budou přijaty aplikací. Hodnota Backlog nemá žádný vliv na maximální počet připojení, které lze nastavit systémem, nebo počtem zákazníků, že konkurenční server může sloužit.

   Hodnoty pro Solaris v tomto obrázku přesně tak, jak jsme očekávali. Tradiční hodnoty pro BSD (za některé nepochopitelné důvody) se rovnou hodnotě nevyžádané hodnoty, vynásobené 3, děleno 2, plus 1.

4. Pokud je místo pro nové připojení ve frontě pro tento koncový bod poslechu (viz obrázek 18.23), modul TCP potvrzuje SYN (ACK) a navázal připojení. Serverová aplikace s koncovým bodem poslechu nevidí toto nové připojení, dokud není přijato třetí segment z "tříčasového handshake". Klient může také předpokládat, že server je připraven přijmout data, když je aktivní otevření klienta úspěšně dokončeno před oznámením aplikace serveru novou připojení. (Pokud k tomu dojde, server TCP bude jednoduše fronty příchozí data.)
5. Pokud není dostatek místa pro frontu nové připojení, TCP jednoduše ignoruje přijaté syn. V reakci, nic není odesláno (ani první segment není odeslán). Pokud poslechový server nemůže odmítnout přijímat některé z již přijatých sloučenin, které byly vyplněny fronty na limit, aktivní otevření klienta bude přerušeno podél časového limitu.

Tento skript vidíme pomocí programu Sock. Spusťte jej novou volbou (-O), která hlásí potřebu pozastavit po vytvoření koncového bodu poslechu, před obdržením jakéhokoli požadavku na připojení. Pokud pak začneme několik zákazníků během této pauzy, server bude nucen frontovat přijaté připojení a co se stane, uvidíme se pomocí příkazu tcpdump.

bsdi% ponožka -S -V -Q1 -O30 5555

Možnost -Q1 Nastaví nevyřízené nezálohy koncového bodu poslechu na 1, pro tradiční systém BSD splňuje dvě sloučeniny (obrázek 18.23). Možnost -030 způsobí, že program "otřít" 30 sekund před přijetím jakéhokoli připojení od klienta. To nám dává 30 sekund začít několik zákazníků, které vyplní frontu. Začneme čtyři zákazníky na Sun hostitele.

Obrázek 18.24 ukazuje výstup programu TCPDUMP, tento výstup začíná první synem z prvního klienta. (Vymazali jsme deklaraci velikosti okna a reklamy MSS. Zvýraznili jsme také čísla klientského portu tučně, když je připojení TCP nainstalován - a "tříčasový handshake".)

První požadavek pro připojení od klienta, který pochází z port 1090, je přijímán modulem TCP (segmenty 1-3). Druhá žádost o připojení od klienta z portu 1091 je také přijímána modulem TCP (segmenty 4-6). Aplikace Server je stále "spí" a nepřijímá jediné připojení. Všechny provedené bylo prováděno modulem TCP v jádře. Je také třeba poznamenat, že dva klienti úspěšně implementovali aktivní objev, to znamená, že "tříčasový handshake" byl úspěšně dokončen.

1 0.0 Slunce. 1090 \u003e BSDI.7777: S 1617152000: 1617152000 (0)
2 0.002310 (0.0023) BSDI.7777\u003e Slunce. 1090 : S 4164096001: 4164096001 (0)
3 0.003098 (0.0008) Slunce. 1090 \u003e bsdi.7777 :. ACK 1617152001.
ACK 1.
4 4.291007 (4.2879) Slunce. 1091 \u003e BSDI.7777: S 1617792000: 1617792000 (0)
5 4.293349 (0.0023) BSDI.7777\u003e Slunce. 1091 : S 4164672001: 4164672001 (0)
ACK 1617792001.
6 4.294167 (0.0008) Slunce. 1091 \u003e bsdi.7777 :. ACK 1.
7 7.131981 (2.8378) SUN.1092\u003e
8 10.556787 (3.4248) SUN.1093\u003e BSDI.7777: S 1618688000: 1618688000 (0)
9 12.695916 (2.1391) SUN.1092\u003e BSDI.7777: S 1618176000: 1618176000 (0)
10 16.195772 (3.4999) Sun.1093\u003e
11 24.695571 (8.4998) SUN.1092\u003e BSDI.7777: S 1618176000: 1618176000 (0)
12 28.195454 (3.4999) Slunce. 1093 \u003e BSDI.7777: S 1618688000: 1618688000 (0)
13 28.197810 (0.0024) BSDI.7777\u003e Slunce. 1093 : S 4167808001: 4167808001 (0)
14 28.198639 (0.0008) Slunce. 1093 \u003e bsdi.7777 :. ACK 1618688001.
ACK 1.
15 48.694931 (20.4963) Slunce. 1092 \u003e BSDI.7777: S 1618176000: 1618176000 (0)
16 48.697292 (0.0024) BSDI.7777\u003e Slunce. 1092 : S 4170496001: 4170496001 (0)
ACK 1618176001.
17 48.698145 (0.0009) Slunce. 1092 \u003e bsdi.7777 :. ACK 1.

Obrázek 18.24 Výstup TCPDUMP například pomocí Backlogu.

Snažili jsme se začít třetí klient v segmentu 7 (port 1092) a čtvrté v segmentu 8 (port 1093). TCP ignorovala obě syn, protože fronta pro tento poslechový koncový bod je vyplněn. Oba klienti znovu předložili své SYN v segmentech 9, 10, 11, 12 a 15. Třetí re-přenos čtvrtého klienta je přijat (segmenty 12-14), protože 30 sekundová pauza serveru je u konce, A server odstranil dva sloučeniny, které byly přijaty, čištění fronty. (Důvodem, pro které se to stalo, je, že toto spojení bylo pořízeno serverem v době 28.19, a ne v čase, který je více než 30; stalo se, protože to trvalo několik sekund pro zahájení prvního klienta [ Segment 1, čas zahájení ve výstupu] po zahájení serveru.) Čtvrtý re-přenos třetího klienta je také přijat (segmenty 15-17). Čtvrté připojení klienta (port 1093) je server akceptován před připojením třetího klienta (port 1092) z důvodu náhody mezi koncem 30 sekundové pauzy a opakováním klienta.

Mohli bychom očekávat, že fronta sloučenin přijatá, která má být zpracována aplikací v souladu s principem FIFO (první zadaný, první vyšel). Poté, co TCP přijal aplikaci na porty 1090 a 1091, očekávali jsme, že aplikace nejprve dostanete připojení k portu 1090, a pak připojení k portu 1091. Ve většině implementací Berkeley je však chyba (chyba), což má za následek chybu (chyba) Řád LIFO (druhý vstoupil, první vyšel). Výrobci se snažili mnohokrát opravit tuto chybu, ale stále existuje v takových systémech jako SUNOS 4.1.3.

TCP ignoruje příchozí syn, když je fronta vyplněna, a neodpovídá pomocí RST, vzhledem k chybě. Obvykle je fronta plná, protože aplikace nebo operační systém je obsazen, takže aplikace nemůže zpracovávat příchozí připojení. Takový stav se může změnit v krátkém časovém období. Pokud však server TCP reagoval s resetem (reset), bude aktivní otevření klienta přerušeno (jen to se stane, pokud server nebyl zajištěn). Protože SYN je ignorována, klient TCP bude nucen znovu předat SYN později, v naději, že se místo objeví ve frontě pro nové připojení.

Na tomto místě je nutné diskutovat o další velmi důležitou položku, která je přítomna téměř ve všech implementacích TCP / IP. Leží v tom, že TCP přijímá požadavek na příchozí připojení (SYN), pokud je místo ve frontě. Aplikace zároveň nemůže vidět, od koho přichází žádost (IP adresa zdroje a počet zdrojového portu). To není vyžadováno protokol TCP, je to jen společná technika používaná v implementacích. Pokud API, například TLI (oddíl kapitoly 1) upozorní aplikaci pro příchod požadavku na připojení a umožňuje aplikaci vybrat, přijmout toto připojení nebo ne, pak při použití protokolu protokolu protokolu protokolu TCP se ukáže, že když je aplikace hlášena že spojení právě dorazilo, ve skutečnosti TCP již dokončila "tříčasový handshake"! V jiných úrovních dopravy existuje možnost rozlišit mezi příjezdem a přijatými sloučeninami (úroveň dopravy OSI), ale TCP taková příležitost neposkytuje.

Solaris 2.2 poskytuje možnost, která neumožňuje TCP přijímat příchozí požadavek připojení, dokud neumožňuje aplikaci (tcp_eager_listenery v dodatku e).

Toto chování také znamená, že server TCP nemůže tak učinit tak, aby aktivní otevření klienta bude přerušeno. Když se připojení z nového klienta vstupuje do serverové aplikace, "Trilateral Handshake" TCP je již dokončena a aktivní otevření klienta byla úspěšně dokončena. Pokud se server pak podívá na adresu IP klienta a číslo portu a rozhodne, že nechce sloužit tomuto klientovi, všechny servery mohou jednoduše zavřít připojení (bude odesláno fin) nebo resetovat připojení (RST bude odesláno). V každém případě bude klient předpokládat, že vše je v pořádku se serverem, protože aktivní zjištění skončil, a bylo docela možné odeslat požadavek na server.

Stručné závěry

Před dvěma procesy si mohou vyměňovat data pomocí protokolu TCP, musí navázat spojení mezi sebou. Když je práce mezi nimi dokončena, musí být připojení přerušeno. Tato kapitola podrobně popisuje, jak je připojení navázáno pomocí "tříčasového handshake" a jak je přerušeno pomocí čtyř segmentů.

Použili jsme TCPDUMP pro zobrazení všech polí v záhlaví TCP. Také jsme se podívali na to, jak lze instalované spojení přerušeno časovým limitem, protože připojení je resetováno, což se děje s polovičním otevřeným připojením a způsobu TCP poskytuje napůl uzavřený režim, současný otevírací a současný uzávěr.

Aby bylo možné pochopit provoz TCP, je nutné zvážit základní graf změn v Stav TCP. Podívali jsme se na položky, protože sloučenina je instalována a přestávky a jaké změny se vyskytují ve státě. Také jsme přezkoumali, jak TCP servery navazují připojení TCP.

Connections TCP jsou jednoznačně identifikovány o 4 parametry: lokální adresa IP, čísla lokálního portu, vzdálené adresy IP a vzdáleného čísla portu. Pokud je spojení přerušeno, musí tato strana stále pamatovat toto připojení, v tomto případě říkáme, že režim Time_wait funguje. Pravidlo říká, že tato strana může provádět aktivní otvor zadáním tohoto režimu po uplynutí doby dvojitého MSL pro tuto implementaci.

Cvičení

1. V sekci jsme říkali, že zdrojový počet sekvence (ISN) je obvykle instalováno v 1 a zvyšuje se o 64 000 každých šest sekund a pokaždé, když se provádí aktivní otvor. To znamená, že mladší tři číslice v ISN budou vždy 001.1. Na obrázku 18.3 jsou však tyto mladší tři postavy pro každý směr roven 521. Jak se to stalo?
2. Na obrázku 18.15 jsme vytištěn 12 znaků, ale viděli jsme, že TCP poslal 13 bajtů. Na obrázku 18.16 jsme publikovali 8 znaků, ale TCP poslal 10 bajtů. Proč byl v prvním případě 1 bajt přidán, a ve druhém bajtovém 2 byte?
3. Jaký je rozdíl mezi polotovarem a polo-zavřeným připojením?
4. Pokud spustíme program SOCK jako server, a pak přerušit jeho práci (bez klienta je k němu připojen), můžeme okamžitě převrácení serveru. To znamená, že nebude ve stavu čekání 2msl. Vysvětlete to z hlediska diagramů změn stavu.
5. V sekci jsme ukázali, že klient nemůže znovu použít stejné místní číslo portu, dokud není port součástí připojení ve stavu pohotovostního režimu 2MSL. Pokud však spustíme program Sock dvakrát v řádku jako klienta, připojením k časovému serveru, můžeme použít stejné číslo místního portu. Kromě toho můžeme vytvořit nové spojení, které bude ve stavu čekání 2msl. Jak se to stane?

   slunce% ponožka -v bsdi dentime
   
   St Jul 7 07:54:51 1993
   připojení uzavřeno peerem

   slunce% sOCK -V -B1163 BSDI DAYTIME Opětovné použití stejného místního čísla
   připojeno na 140.252.13.33.1163 na 140.252.13.35.13
   St Č. 7 07:55:01 1993
   připojení uzavřeno peerem
   

6. Na konci sekce, kdy jsme popsali stav stat_wait_2, jsme uvedli, že většina implementací překládá spojení z tohoto stavu do uzavřeného stavu, pokud aplikace plně uzavřená (ne napůl zavřená) po asi 11 minutách. Pokud druhá strana (v close_wait stát) čeká po dobu 12 minut před zavřením (odeslání fin), které TCP obdrží v reakci na fin?
7. Která strana v telefonním rozhovoru provádí aktivního objevování a co je pasivní otevření? Je možné současně otevřít? Je možné simultánní uzavření?
8. Obrázek 18.6 Neviděli jsme ARP dotaz nebo odpověď ARP. Hardwarová adresa Hostitele SVR4 však musí být v ARP BSDI cache. Co se na tomto obrázku změní, pokud tento bod v cache ARP chybí?
9. Vysvětlete následující příkazový výstup TCPDUMP. Porovnejte s obrázkem 18.13.

   1 0.0 Solaris.32990\u003e BSDI.discard: S 40140288: 40140288 (0)
   Vyhrajte 8760.
   2 0.003295 (0.0033) BSDI.Discard\u003e Solaris.32990: S 4208081409: 4208081409 (0)
   ACK 40140289 Vyhrajte 4096
   
   3 0.419991 (0.4167) Solaris.32990\u003e BSDI.discard: P 1: 257 (256) ACK 1 Win 9216
   4 0.449852 (0.0299) Solaris.32990\u003e BSDI.discard: F 257: 257 (0) ACK 1 Win 9216
   5 0.451965 (0.0021) bsdi.discard\u003e Solaris.32990 :. ACK 258 Win 3840
   6 0.464569 (0.0126) BSDI.discard\u003e Solaris.32990: F 1: 1 (0) ACK 258 Win 4096
   7 0.720031 (0.2555) Solaris.32990\u003e BSDI.discard :. ACK 2 Win 9216
   

10. Proč server na obrázku 18.4 není kombinovat ACK na klientovi FIN s vlastním ploutem, čímž se snižuje počet segmentů až tři?
11. Na obrázku 18.16, proč je počet RST sekvence 26368002?
12. Řekni mi, je založeno na požadavku TCP na úroveň kanálu o jeho MTU na principu lámání na úrovních?
demultIpexed na základě čísla cílového portu TCP. Je to správně?

Nainstalujte připojení protokolu TCP

Protokol připojení TCP je nastaven pomocí "Triple Handshake" popsaný v části "Instalace připojení". Chcete-li vytvořit připojení, jedna strana (například server) pasivně očekává příchozí spojení prováděním primitiv poslouchat a přijmout, nebo specifikovat specifický zdroj nebo ne určení.

Další strana (například klient) provádí primitivu Connect Primitive, určující IP adresu a port, se kterými chce navázat spojení, maximální velikost segmentu TCP a pokud je to žádoucí, některá uživatelská data (například heslo) ). Připojení primitive odešle segment TCP s nainstalovaným synem a upuštěnými kousky zeptat se a čeká na odpověď.

Když tento segment dorazí do cíle, TCP Essence zkontroluje, zda žádný proces splnil poslouchat, určující stejný port jako parametr, který je obsažen v poli Příjemce. Pokud takový proces neexistuje takový proces, splňuje segment segmentu s rst bitem, který má být odepřen spojení.

Pokud nějaký proces poslouchá libovolný port, pak je příchozí segment TCP přenesen do tohoto procesu. Ten může přijmout spojení nebo jej odmítnout. Pokud proces vezme spojení, odkazuje se na potvrzení odpovědi. Sekvence segmentů TCP odeslaných v normálním případě (obr. A) Upozorňujeme, že segment SYG je 1 bajt prostoru sekvenčních čísel, která se vyhýbá nejednoznačnosti jejich potvrzením.

Pokud se dvěma hostiteli současně snaží navázat spojení s sebou, sekvence událostí se vyskytují, bude odpovídat obr. b. V důsledku toho bude instalována pouze jedna sloučenina, a ne dva, protože dvojice koncových bodů jedinečně určuje sloučeninu. To znamená, že pokud se obě připojení snaží identifikovat s pomocí dvojice (X, Y), pouze jedna položka tabulky pro (X, Y).

Počáteční hodnota pořadového čísla připojení není nulová podle výše uvedených důvodů. Systém založený na časovači, který změní svůj stav každý 4 μS. Pro větší spolehlivost je hostitel po neúspěchu zakázáno restartovat dříve než maximální životnost balíčku. To umožňuje zajistit, aby žádný balíček z předchozích připojení putoval někde na internetu.

TCP Connection Rupture.

Ačkoli připojení TCP jsou plně duplex, pochopit, jak se jejich oddělení dochází, je lepší je zvážit je dvojicemi Simplex spojení. Každé simplexní spojení je přerušeno bez ohledu na svého partnera. Pro porušení spojení může některý ze stran poslat TCP-segment s jednotkovým bitem, což znamená, že již nemá data pro přenos. Pokud je tento segment TCP potvrzen, je tento směr přenosu zavřený. Data však mohou být nadále přenášena neurčitě v opačném směru. Připojení je přerušeno, když jsou oba směry zavřené. Obvykle jsou zapotřebí čtyři segmenty TCP segmenty pro porušení spojení: jeden s ploutvím a jeden s trochou ASC v každém směru. První kousek ASC a druhého bitového ploutve může být také obsažen v jednom segmentu TCP, který sníží počet segmentů do tří.

Stejně jako u telefonického konverzace, když oba účastníci mohou současně rozloučit a zavěsit trubky, oba konce připojení TCP mohou zároveň posílat fin-certony. Oba dostávají pravidelné potvrzení a spojení je uzavřeno. Ve skutečnosti neexistuje žádný rozdíl mezi simultánními a konzistentními odpojeními.

Aby se zabránilo problému dvou armád, používají se časovače. Pokud odpověď na SEND FIN segment nepřichází během dvou maximálních životních intervalů baterie, odesílatel se vypne. Další strana nakonec si všimne, že nikdo ji neodpoví, a také rozbít spojení. I když takové rozhodnutí není dokonalé, ale vzhledem k nedosažitosti ideálu musíte použít to, co je. V praxi vznikají problémy.

Ovládání přenosu v TCP

Jak již bylo zmíněno, ovládání okna TCP není připojena přímo k potvrzení, jak se provádí ve většině protokolů přenosu dat. Předpokládejme například, že příjemce má 4096-bajtový vyrovnávací paměť. Pokud odesílatel vysílá 2048-bajtový segment, který příjemce úspěšně přijmou příjemcem, příjemce potvrzuje svůj příjem. Zároveň však příjemce zůstává pouze 2048 bajtů volného vyrovnávací paměti (dokud aplikace nebere žádná data z vyrovnávací paměti), která hlásí odesílatele, určující příslušnou velikost okna (2048) a další očekávané bajtové číslo .

Poté odesílatel odešle dalších 2048 bajtů, je potvrzeno, že je potvrzeno, ale velikost okna je deklarována stejná hodnota 0. Odesílatel musí zastavit převodovku, dokud přijímací hostitel neuvolní místo v vyrovnávací paměti a nezvyšuje velikost okna.

S nulovou velikostí okna nemůže odesílatel odesílat segmenty s výjimkou dvou případů. Za prvé, například je povoleno odesílat urgentní údaje, například, že uživatel může zničit proces spuštěný na vzdáleném počítači. Za druhé, odesílatel může poslat 1bajtový segment, požádat o příjemce, aby opakoval informace o velikosti okna a očekává se další bajt. Standard TCP jasně stanoví tuto příležitost, aby se zabránilo v případě ztráty deklarace velikosti okna.

Odesílatelé nejsou povinni vysílat data, jakmile pocházejí z aplikace. Také nikdo nevyžaduje příjemce k odesílání potvrzení co nejdříve. Například, TCP entita, přijímá prvních 2 kB dat z aplikace a s vědomím, že dostupná velikost okna je 4 kb, bylo by to naprosto správné, pokud jste právě uložili přijaté údaje do vyrovnávací paměti, dokud nebudou mít další 2 kbyty dat S okamžitým segmentem se 4 kb užitečným zatížením. Tato svoboda akce lze použít ke zlepšení výkonnosti.

Zvažte připojení Telnet s interaktivním editorem reagujícím na každé stisknutí klávesy. V nejhorším případě, kdy symbol dorazí na přenos TCP entity, vytvoří 21-bajtový segment TCP a přenáší jej na úrovni IP, což zase odesílá 41 bajtové IP-Datagram.

Na přijímající straně TCP Essence ihned odpovídá 40 bajtovému potvrzení (20 bajtů hlavičky TCP a 20 bajtů záhlaví IP). Potom, když editor přečte tento bajt z vyrovnávací paměti, Entita TCP odešle aktualizované informace o velikosti vyrovnávací paměti, přesunutí okna na 1 bajt vpravo. Velikost tohoto balení je také 40 bajtů. Konečně, když editor tento symbol zpracovává, odešle echo echo přenášené 41-bajtovým balíčkem. Celkem pro každý symbol zadaný z klávesnice je odeslán čtyři pakety o celkové velikosti 162 bajtů. V podmínkách nedostatku šířky pásma řádků je tento způsob práce nežádoucí.

Chcete-li zlepšit situaci, mnoho implementací TCP používá potvrzení zpoždění a velikost Windowsu aktualizace na 500 ms v naději na získání dalších dat, spolu s nimiž můžete potvrdit potvrzení s jedním balíčkem. Pokud má editor čas dát echo za 500 ms, vzdálený uživatel bude muset odeslat pouze jeden 41 bajtový balíček, takže zatížení sítě bude zmenšeno.

Ačkoli tento způsob zpoždění a snižuje zatížení sítě, nicméně, účinnost využívání sítě je i nadále nízká, protože každý bajt je odeslán v samostatném 41-bajtovém balíčku. Metoda, která umožňuje zvýšit účinnost, je známý jako vágní algoritmus (Nagle, 1984). Váha Vaga zní zcela jednoduchá: Pokud data přicházejí s odesílatelem jeden po jednom byte, odesílatel jednoduše přenáší první bajt a místa zbytek do vyrovnávací paměti, dokud není potvrzeno příjmu prvního bajtu. Poté můžete odeslat všechny znaky akumulované v bufferu ve formě jednoho segmentu TCP a znovu spustit vyrovnávací paměti, dokud není symbol potvrzen. Pokud uživatel vrátí znaky rychle, a síť je pomalá, pak v každém segmentu bude významný počet znaků, takže zatížení sítě bude výrazně sníženo. Tento algoritmus navíc umožňuje odesílat nový balíček, i když počet znaků v vyrovnávací paměti překročí polovinu velikosti okna nebo maximální velikost segmentu.

Vágní algoritmus je široce používán různými implementacemi protokolu TCP, ale někdy existují situace, ve kterých je lepší vypnout. Zejména když je aplikace X-Windows spuštěna na internetu, informace o pohyblivé myši jsou odesílány do vzdáleného počítače. (X-Window je systém řízení oken ve většině OS UNIX typu). Pokud tato data vyrovnávací data pro dávkové lodní dopravu, kurzor se pohybuje s velkými pauzy, v důsledku toho bude program velmi obtížný, téměř nemožný.

Dalším problémem, který může výrazně snížit výkon protokolu TCP, je známý jako hloupý syndrom okenního okna (Clark, 1982). Podstata problému je, že údaje jsou zasílány na TCP-essence velkých bloků, ale přijímající stránka interaktivní aplikace je čte v převažném.

Zvažte příklad - počáteční stav je takový: pufr TCP přijímací strany je plná, a to je známo odesílateli (tj. Velikost okna je 0). Pak interaktivní aplikace přečte jeden znak z toku TCP. Příjem TCP Essence radostně informuje odesílatele, že velikost okna se zvýšila, a že nyní může poslat 1 bajt. Odesílatel bude poslouchat a posílá 1 bajt. Vyrovnávací paměť je opět plný, jako příjemce a upozorňuje, odesílání potvrzení pro segment 1 bajtů s velikostí nuly. A tak to může pokračovat navždy.

David Clark (David Clark) nabídl, aby zakázal hostitele posílat informace o velikosti s jedním způsobem. Místo toho by příjemce měl počkat, dokud nebude v bufferu akumulována významné množství volného místa. Zejména příjemce by neměl poslat informace o nové velikosti okna, dokud nemůže přijmout segment maximální velikosti, který prohlásil, když je připojení nastaveno, nebo jeho vyrovnávací paměť nebyl propuštěn alespoň polovinu.

Kromě toho samotný odesílatel může přispět ke zvýšení účinnosti vysílání, odmítnutí posílat příliš málo segmentů. Místo toho by měl počkat, až se velikost okna stane poměrně velkým, takže můžete poslat plný segment nebo alespoň rovnat polovině vyrovnávací paměti příjemce. (Odesílatel může tuto velikost vyhodnotit posloupností zpráv o velikosti okna získaného dříve.)

V úkolu zbavit se hloupého okna syndromu, vágní algoritmus a rozhodnutí Clarka se navzájem doplňují. Aroganta se snažila vyřešit problém žádosti poskytovat subjekty TCP ve převládajícím. Clark se pokusil vyřešit problém aplikace, která se zdála, že data obdrží od TCP. Obě řešení jsou dobrá a mohou pracovat současně. Jejich podstata není posílat a nepožádá o přenos dat příliš malých porcích.

Přijímací jednotka TCP může jít ještě dále při zvyšování produktivity, jednoduše aktualizovat informace o velikosti okna velkými částmi. Stejně jako účetní jednotka TCP může také vyrovnávací paměť údaje a blokovat požadavek na čtení požadavku z aplikace, dokud má velké množství dat. Počet odvolání na Essence TCP se snižuje a proto se sníží režie. Tento přístup samozřejmě zvyšuje dobu odezvy, ale pro neinteraktivní aplikace, například při přenosu souboru, je snížení času stráveného na celé operaci mnohem důležitější než zvýšení doby odezvy na oddělené požadavky.

Problém jiného příjemce se skládá ze segmentů získaných ve špatném pořadí. Mohou být uloženy nebo odmítnuty podle uvážení příjemce. Samozřejmě, potvrzení lze vyloučit pouze v případě, že všechna data jsou na potvrzené bajtové získané. Pokud se segmenty o, 1, 2, 4, 5, 6 a 7 dosahují příjemce, může potvrdit přijetí dat až do posledního bajtu segmentu 2. Když odesílatel zvýšil čas, bude přenášet segment 3 znovu. Pokud v době příjezdu segmentu 3 bude příjemce ukládat segmenty ze 4. až 7. vyrovnávací paměti, bude moci potvrdit příjem všech bajtů až do posledního bajtu segmentu 7.

- 1 Triple Handshake TCP.

Proces zahájení TCP relace (také nazývaný "handshake" se skládá ze tří kroků.

1. Klient, který má v úmyslu navázat spojení odešle segment se sekvenčním číslem a příznakem Syn.

• Server obdrží segment, pamatuje si číslo sekvence a pokusí se vytvořit zásuvku (vyrovnávací paměti a struktury řízení paměti) pro udržení nového klienta.
• Pokud je úspěšný, server odešle segment se sekvenčním číslem a příznaky SYN a ACK a zadá stav SYN-REED.
• V případě neúspěchu server odešle segment s příznakem RST klientovi.

2. Pokud klient obdrží segment příznaku Syn, pak si pamatuje číslo sekvence a odešle segment s příznakem ACK.

• Pokud také obdrží příznak ACK (který se obvykle děje), pak to jde do stavu založeného.
• Pokud klient obdrží segment s příznakem RST, zastaví se pokusy o připojení.
• Pokud klient neobdrží odpověď do 10 sekund, opakuje proces připojení.

3. Pokud server v režimu SYN-REED obdrží segment s příznakem ACK, pak jde do zavedeného stavu.

• Jinak, po časovém limitu, zavře zásuvku a jde do uzavřeného stavu.

Proces se nazývá "třístupňová dohoda", jako navzdory skutečnosti, že je možné navázat spojení s využitím čtyř segmentů (SYN směrem k serveru, ACK klientovi, SYNS SONS Klientem, ACK ve směru serveru) , v praxi pro ušetření časového segmentu.

TCP - okno

Toto pole obsahuje číslo, které definuje velikost dat v bajtech, které lze odesílatel odeslat bez přijímání potvrzení.

Okno TCP - algoritmus pro řízení intenzity datového toku na základě změny maximálního množství dat, které příjemce je připraven přijmout a potvrdit s jedním segmentem odezvy
Velikost okna vždy přiřazuje příjemce na základě statistik počtu chyb

Domény kolizí

Domain Collisius. - tohle je síťová oblastEthernet, všechny uzly, které rozpoznávají kolizi bez ohledu na to, která část této oblasti se kolizí vznikla

• Výsledná kolize se nevztahuje nad rámecodpovídající doménu kolizí
• Čím větší je počet domén komunity, tím výraznější důsledky každé kolize
• Rozdělit síť do domucollisses platí spínače

Režimy VTP na přepínačích

VTP - VLAN Trunking Protocol, umožňuje usnadnit správu přepínačů, a to ovládání VLAN-AMI na přepínačích Cisco. S VTP můžete vytvořit, upravovat nebo mazat VLAN na serveru VTP a všechny tyto změny budou automaticky přeneseny do všech přepínačů ve stejné doméně VTP. To eliminuje správce z konfigurace VLAN na každém přepínači.
Existují tři režimy VTP (režim VTP):

1. VTTP server - režim serveru. V tomto režimu můžete vytvořit, odstranit a upravit VLANS, stejně jako nastavit různé parametry, jako je verze protokolu (verze VTP), filtrování VTP (VTP prořezávání) pro celou VTP doménu. Server VTP oznamuje o jeho konfiguraci VLAN. Jiné přepínače, které jsou ve stejné doméně VTP a synchronizuje jejich konfiguraci VLAN. Server VTP také může synchronizovat svou konfiguraci s konfigurací klienta VTP, pokud klient nad číslem revize konfigurace. Informace VTP jsou způsobeny přenosovými porty.

2. VTP klienta - klientský režim. Na přepínači s klientským režimem VTP nelze vytvořit, mazat nebo upravit VLAN-S. Celé nastavení Switter VLANS trvá ze serveru VTP.

3. VTP transparentní - transparentní režim. V tomto režimu přepínač neplatí konfiguraci VLAN z serveru VTP serveru a neoznámí žádné další přepínače o jeho konfiguraci, ale umožňuje přeskočit oznámení z jiných přepínačů prostřednictvím portů zavazadlového prostoru VTP.

Potvrzení

V rámci spojení musí být správný přenos každého segmentu potvrzen příjemcem příjemce. Potvrzení - To je jeden z tradičních metod pro zajištění spolehlivé komunikace. Myšlenka potvrzení je následující.

Aby bylo možné uspořádat re-přenos zkreslených dat, čísla odesílatele zaslala jednotky přenosných dat (dále jen zřídka jako jednoduchost personálu). Pro každý snímek odesílatel očekává od přijímače tzv. Pozitivního přijetí - servisní zpráva, která oznamuje, že zdrojový rámec byl získán a data v ní ukázala být správná. Doba tohoto očekávání je omezená - při odesílání každého rámce vysílač spustí časovač a pokud je pozitivní příjem získán jeho vypršením, rámec je považován za ztracený. V některých protokolech, přijímač, v případě přijetí rámečku s zkreslenými daty, by měl odeslat negativní příjem - explicitní indikaci, že tento snímek musí být znovu přenášen.

Funkce transportní úrovně

• poskytuje logické spojení mezi aplikacemi;
• realizuje spolehlivý přenos dat;
• poskytuje řízení rychlosti přenosu dat.

Sockets.

Zásuvka (Socket, hnízdo) je struktura dat identifikující síťové připojení.

Proč potřebují zásuvky? Server (Program) může současně podporovat více připojení TCP s jinými počítači pomocí stejného standardního čísla portu. Jak jej implementovat? Tento úkol můžete přiřadit na programátorovi. Nechte to vybrat balíčky z vyrovnávací paměti, abyste obdrželi pakety, vzhled, od koho jsou odesílány a odpovídajícím způsobem reagují. Ale můžete udělat vše pohodlnější.

S každým připojením musí být jeho proud spojen, se kterým můžete psát informace a od kterého si jej můžete přečíst. Každý proud odpovídá vaší IP adresy vzdáleného počítače a portu vzdáleného počítače. Zavoláme datovou strukturu odpovídající každému takovému proudu, zásuvce (zásuvka). Server může být srovnáván s rozdělovačem s bandou zásuvek, ke kterému jsou klienti připojeni.

Pokud tak učiníte, pak namísto řešení hromady více paketů z recepčního vyrovnávací paměti síťové vrstvy, bude server číst z toků, z nichž každý odpovídá klientovi. Údaje od zákazníků nespadají do parta, a budou distribuovány přes toky-zásuvky. Odpovědnost za takovou distribuci není na programátorovi, ale na ovladači úrovně provozu operačního systému.

Zásuvky byly vyvinuty na univerzitě v Kalifornii v Berkeley, se stala standardem de facto na rozdíl od OSI TLI (Interface dopravních vrstev).

Historický odkaz. Split Unix.

Od roku 1978 začíná svůj příběh BSD Unix, který byl vytvořen na univerzitě v Berkeley. Autorka BSD byla Bill Joy. Na počátku osmdesátých let, AT & T, kdo patřil Bell Labs, si uvědomil hodnotu Unixu a začal vytvářet komerční verzi Unixu. Důležitou příčinou rozdělení UNIX bylo implementace protokolů protokolů TCP / IP v roce 1980. Před tím, že intermentační interakce v Unixu byla v dětství - nejvýznamnějším způsobem komunikovat byl UUCP (prostředek kopírování souborů z jednoho systému UNIX do druhého, který zpočátku pracoval na telefonních sítích pomocí modemů).

Tyto dva operační systémy implementovaly 2 různá programovací rozhraní pro síťové aplikace: Berkley Sockets (TCP / IP) a rozhraní transportní úrovně TLI (OSI ISO) (rozhraní English Transport Layer). Rozhraní Berkley Sockets bylo navrženo v Berkeley University a použity zásobník protokolu protokolu TCP / IP vyvinutý tamtéž. TLI byl vytvořen AT & T v souladu s definicí úrovně transportu modelu OSI. Zpočátku neměl provádění protokolů TCP / IP nebo jiných síťových protokolů, ale tyto implementace poskytly firmy třetích stran. To, stejně jako další úvahy (z větší části, trh), způsobil konečné odběr vzorků mezi dvěma větvemi UNIXu - BSD (Berkeley University) a System V (komerční verze od AT & T). Následně mnoho společností licencovaných systémem V AT & T vyvinuly vlastní obchodní odrůdy UNIX, jako je AIX, HP-UX, IRIX, Solaris.

Primitive Socetov.

Zásuvka.	Vytvořte novou (prázdnou) zásuvku
Svázat.	Server připojuje místní adresu (port) se zásuvkou
Poslouchat.	Server zvýrazní paměť fronty Client Connections (TCP)
Akceptovat	Server očekává připojení klienta nebo vezme první připojení z fronty (TCP). Chcete-li blokovat očekávání příchozích připojení, server provádí primitivní přijetí. Po obdržení požadavku na připojení vytvoří transportní modul OS novou zásuvku se stejnými vlastnostmi jako zdrojové zásuvky a vrátí pro něj deskriptor souboru. Poté může server rozdělit proces nebo proud pro zpracování připojení pro novou zásuvku a paralelně očekávat následující připojení pro původní zásuvku.
Připojit.	Požadavky klienta (TCP)
Odeslat / send_to.	Odeslat data (TCP / UDP)
Přijmout / DeE_DECT_FROM.	Získejte data (TCP / UDP)
Odpojit.	Odpojení požadavku (TCP)

Multiplexování a demultiplexování

Multiplexování - Sbírka zpráv ze zásuvek všech aplikací a přidat záhlaví.

DemultIpexing. - Distribuce příchozích dat na zásuvkách.

Pro UDP je požadovaná zásuvka určena číslem příjmení příjemce, pro TCP, číslo příjemce portu, adresu IP a portem portu odesílatele.

Protokoly na úrovni dopravy

Na úrovni dopravy existují dva protokoly: TCP (spolehlivý) a UDP (nespolehlivý).

UDP protokol

UDP (User Datagram Protocol) provádí minimální akce, což umožňuje aplikaci pracovat téměř přímo s úrovní sítě. Funguje mnohem rychleji než TCP, protože nemusíte instalovat připojení a očekáváte potvrzení o doručení. Možné ztráty segmentů. Řídí správnost přenášených dat (kontrolní součet).

Struktura UDP-segmentu

Titul je pouze 8 bajtů.

Principy spolehlivého přenosu dat

Navrhujeme protokol myTCP, jeho komplikace.

• Stav protokolu MyTCP 1.0. Přenos na absolutně spolehlivý kanál

Stav protokolu MyTCP 1.0 (odesílatele) (vysílání absolutně spolehlivého kanálu) .jpg

Odesílatel

Stav protokolu MyTCP 1.0 (příjemce) (vysílání absolutně spolehlivého kanálu) .jpg

Příjemce

• Stav protokolu MyTCP 2.0. Přenos přes kanál, který umožňuje zkreslení bitů. Ztráty balíčků jsou nemožné

Stav protokolu MyTCP 2.0 (odesílatele) (přenos přes kanál, který umožňuje zkreslení bitů. Ztráta balíčků je nemožné) .jpg

Odesílatel

Stav protokolu MyTCP 2.0 (příjemce) (přenos přes kanál, který umožňuje zkreslení bitů. Ztráta balíčků je nemožné) .jpg

Příjemce

Ale příjmy mohou být také ztraceny. Pokud je potvrzení zkreslené odesílatelem znovu odešle balíček. Příjemce by měl myslet, jak zvládnout opětovné balíčky (musíte zadat nový stav - prošel předchozí aplikační balíček nebo ne).

Úloha identifikátorů "Opakované" a "nové" v TCP / IP hrají počet balíčků (protože pakety mohou být stále ztraceny).

• Stav protokolu MyTCP 2.1. Přenos přes kanál, který umožňuje zkreslení bitů. Ztráty balíčků jsou nemožné

Stav protokolu MyTCP 2.1 (odesílatel) (přenos přes kanál, který umožňuje zkreslení bitů. Ztráta balíčků je nemožné) .jpg

Odesílatel

Stav protokolu MyTCP 2.1 (příjemce) (Přenos přes kanál, který umožňuje zkreslení bitů. Ztráta balíčků je nemožné) .jpg

Příjemce

Hlavní rozdíl mezi příjemci stavy v tom, jak jsou zpracovány opakované balíčky. V seznamu "Poslední balíček balíčku" hodíme zpět pakety a v "posledním balíčku" nebyl předán aplikací. Přijímáme je a sdělujeme žádost.

Nyní je čas si pamatovat, že balíčky mohou být ztraceny.

• Musíte být schopni určit, že ztráta balíčku, například dávejte si čas po odeslání balení.
• Musíte číslovat balíčky.
• V příjmech musíte určit číslo paketu, ke kterému je odeslán.

Tak jsme přišli k potřebě časovače. V případě, že nějaký čas uplynulo a potvrzení nepřijde, pak zpráva znovu odesílá. Časový interval - malý, protože Pravděpodobnost ztráty se bere blízko 1 (to je opravdu tak i pro dobré wifi připojení).

Nevýhody protokolů s potvrzovacími očekáváními

Zvážit příklad. Nechť je 1 GB-Channel Rostov - Moskva. Vypočítejte čas odeslání 1000 bajtů (nebo 8000 bitů):

8000 bit / 1 gb / c \u003d 8 μs

Doba distribuce signálu:

1000 km / 300 000 km / s \u003d 3333 μs

Celkem: Následující 1000 bajtů bude dodáno více než 6674 μS

Závěr: 99,9% časového kanálu nepoužívá.

Cesta řešení je zvýšit velikost obalu. Pokud je však alespoň 1 bit zkreslený, pak celý balíček vyhne. Co pak?

Protokoly posuvné okno

Řešení problému: Nechte odesílatele odeslat jeden rámec, ale poněkud před zastavením a přejděte do pohotovostního režimu potvrzení (příjmy). Tato technika se nazývá zpracování dopravníku.

Na obrázku, zelená označena ty příjmy, které jsou již získány, žluté - odeslané, ale nezískané, modré jsou připraveny pro expedici a bílá nemůže být odeslána, dokud nedostaneme příjmu na žlutou. Okno: Žlutá a modrá jsou balíky, které mohou být přenášeny bez čekání na příjmy. První bílý balíček lze dodat pouze poté, co obdrželi potvrzení první žluté. Pak se okno pohybuje na 1 vpravo.

Otázka může nastat: Proč omezit velikost okna, pojďme dát všechny pakety, a pak očekáváme potvrzení. Ale není možné to udělat: je snadné získat přetížení v síti.

Existují dva způsoby, jak řešit problémy chyb při dopravním rámečku:

• GBN (vrátit se N - návrat na pak pakety zpět);
• SR (selektivní opakování - selektivní opakování).

GBN.

Příjemce odešle pouze pozitivní příjmy a pouze o přijetí těchto paketů, pro které je podmínka splněna: Všechny balíčky s menšími čísly jsou již získány. Tak zde se zde používá uznání skupiny: Získání odesílatele o přijetí s číslem Znamená, že všechny balíčky k i byly úspěšně předloženy. Pokud po určitém okamžiku odesílatel neobdrží příjmy, opakuje odjezd všech balíčků n z následujícího jako poslední potvrzení.

Metoda GBN je neúčinná s velkým oknem a dluhem distribuovat pakety v síti, ve které se vyskytují ztráty. Příklad: 1000 balíčků odeslaných, druhý nepřišel, musíte opakovat odesílání každého od druhého. Jsme "vrh" síť s neužitečným provozem.

Sr.

Tento přístup poskytuje zaslání účtenky pro každý balíček. Příjemce ukládá ve své vyrovnávací paměti všechny správné rámečky pořízené po nesprávném nebo ztraceném. V tomto případě je vyřazen nesprávný rám. Pokud čekací doba účtenky pro nějaký rámec vyprší, odesílatel odešle tento rámec opět bez opakování odesílání všech dalších. Pokud je druhý pokus úspěšný, nahromaděný z balíčků příjemců může být převeden na úroveň sítě, po kterém bude odeslán potvrzení o přijetí rámce s největším číslem.

Selektivní metoda je často kombinována se odesíláním "negativního potvrzení" příjemce (Nak-negativní potvrzení), když je detekována chyba (například s nesprávným kontrolním součtem). V tomto případě se zvyšuje účinnost práce.

S velkým oknem může přístup SR vyžadovat významnou velikost vyrovnávací paměti.

Protokol TCP

Formát TCP-segmentu

Segment TCP se skládá z datového pole a několika polí záhlaví. Data pole Obsahuje fragment dat přenášených mezi procesy. Velikost datového pole je omezena hodnotou MSS. (maximální velikost segmentu). Když protokol přenáší velký soubor, zpravidla porušuje data na fragmentech velikosti MSS (s výjimkou posledního fragmentu, který má obvykle menší velikost). Interaktivní aplikace, naopak, naopak, jsou často vyměňovány daty, jehož objem je podstatně nižší než MSS. Například sítě vzdáleného přístupu k síti, podobně jako Telnet, mohou přenášet 1 datové bajty do vozidla. Vzhledem k tomu, že obvykle délka záhlaví segmentu TCP je 20 bajtů (což je 12 bajtů, více než v UDP), plná velikost segmentu v tomto případě je 21 bajtů.

Stejně jako v protokolu UDP název zahrnuje čísla odesílatele a příjemců, určené pro multiplexování a demultiplexní postupy, stejně jako pole Kontrolní součet. Segment TCP navíc obsahuje některá další pole.

• 32bitová čísla sekvence a potvrzovací čísla. Pro spolehlivý přenos dat.
• Pole 4-bitové pole délky záhlaví určuje délku záhlaví TCP v 32bitových slovech. Minimální velikost je 5 slov a maximálně - 15, což je 20 a 60 bajtů. Hlavička TCP může mít proměnnou délku v důsledku pole parametru popsaného níže (zpravidla je pole parametrů prázdné; to znamená, že délka záhlaví je 20 bajtů).
• Pole vlajek se skládá ze 6 bitů. Potvrzené bity (ASC) označuje, že hodnota obsažená v potvrzení je správná. RST, SYN a FIN bity se používají k instalaci a dokončení připojení. Instalovaný bit PSH instruuje příjemce, aby tlačil data, která se nahromadila v přijímacím vyrovnávací paměti do uživatelské aplikace. Bit URG ukazuje, že segment obsahuje data umístěná horní úrovní jako "naléhavé". Umístění posledního využití bajtu je uvedeno v 16bitovém poli ukazatele urgentní dat. Na přijímající straně musí protokol TCP informovat nejvyšší úroveň na dostupnosti naléhavých dat v segmentu a převést ji ukazatel na konec těchto dat. V praxi se nepoužívají vlajky PSH, URG a pole Urgentní ukazatel dat. O nich jsme se zmínili pouze pro úplnost popisu.
• 16bitové okno příjmu se používá k řízení datového toku. Obsahuje počet bajtů, které jsou schopny přijmout přijímající stranu.
• Index důležitosti je 16bitová hodnota pozitivního posunu od sekvenčního čísla v tomto segmentu. Toto pole označuje číslo sekvence, z nichž je dokončeno důležitá (naléhavá) data. Pole se bere v úvahu pouze pro balíčky s nastaveným příznakem URG.
• Volitelné pole parametru se používá v případech, kdy vysílací a přijímající strany "vyjednávat" o maximální velikosti segmentu, nebo měnit okno v sítích vysokorychlostních. Také v tomto poli definuje parametr časového štítku. Další informace naleznete v dokumentech RFC 854 a RFC 1323.

Čísla sekvete a potvrzovací čísla

Číslo segmentu segmentu - Toto je počet prvního bajtu tohoto segmentu.

Potvrzovací číslo - Toto je pořadové číslo dalšího očekávaného bajtu.

Pole Pole Pole a potvrzovací čísla jsou nejdůležitější v záhlaví segmentu TCP, protože hrají klíčovou roli ve fungování spolehlivé služby přenosu dat. Před ohledem na úlohu těchto oblastí v mechanismu spolehlivého přenosu se však podíváte na hodnoty, které v těchto polích protokol TCP v těchto oblastech.

Protokol TCP považuje data jako nestrukturovaný objednaný bajtový proud. Tento přístup se projevuje ve skutečnosti, že protokol TCP přiděluje pořadové číslo, aby se segmenty, ale pro každého přenášeného bajtu. Na základě toho je číslo segmentu segmentu definováno jako sekvenční číslo prvního bajtu tohoto segmentu. Zvažte následující příklad. Nechte hostitele a chce předat datový proud hostitele v přes připojení TCP. Protokol TCP na vysílací straně implicitně čísla každého bytu stream. Předpokládejme, že velikost přenášeného souboru je 500 000 bajtů, hodnota MSS je 1000 bajtů a první bajt toku má pořadové číslo 0. TCP rozbije datový proud o 500 segmentech. První segment je přiřazen pořadové číslo 0, druhý segment je číslo 1000, třetí segment - číslo 2000, atd. Objednací čísla jsou zaznamenána v segmentu každého segmentu TCP.

Zvažte potvrzovací čísla. Připomeňme si, že protokol TCP poskytuje duplexní přenos dat, tj. Prostřednictvím jediného připojení TCP mohou být data mezi hostiteli A a B přenášena současně v obou směrech. Každý segment vycházející z hostitele v obsahují pořadový počet dat přenášených z hostitele do hostitele potvrzovacím číslem, které je hostitel A umístěn v jeho segmentu, je dalším počtem dalšího byte očekávaného hostitelem a od hostitele. Zvažte následující příklad. Předpokládejme, že hostitel přijaté všechny bajty s čísly od 0 do 535 odeslaného hostitelem v a tvoří segment pro přenos hostitele V. Khost, a očekává, že následující bajty zaslané hostitelem, bude mít čísla začínající 536, a umístí číslo 536 v potvrzovacím počtu jeho segmentu.

Zvážit jinou situaci. Nechte hostitele a přijímat od hostitele ve dvou segmentech, v prvním z nich obsahují bajty s čísly od 0 do 535, a ve druhém - bajtech s čísly od 900 do 1000. To znamená, že z nějakého důvodu byte s čísly z 536 na 899 nebyly přijímány hostitelem A. V tomto případě hostitele a očekává vznik chybějících bytů a číslo 536 je umístěno v poli potvrzovací číslo. Vzhledem k tomu, že TCP potvrzuje přijatá data na první chybějící bajt, to Říká se, že podporuje obecné potvrzení.

Poslední příklad ukazuje velmi důležitý aspekt provozu protokolu TCP. Třetí segment (obsahující bajty 900-1000) je přijímán hostitelem a starší než druhá (obsahující bajty 536-899), tj. Porušením postupu pro údaje. Vyvstává otázka: Jak reaguje protokol TCP na porušení objednávky? Pokud získaný segment obsahuje číslo sekvence větší než očekávané, pak jsou data z segmentu vyrovnána, ale počet potvrzených sekvence se nezmění. Pokud bude přijat segment týkající se očekávaného čísla sekvence, bude postup pro data automaticky obnovena na základě pořadových čísel v segmentech. TCP tedy odkazuje na protokoly SR, ale používá obecný záznam jako v GBN. Ačkoli SR není zcela čistý. Pokud strana boku přijímá několik (3) negativních příjmů do stejného segmentu X, pak si uvědomí, že přetížení sítě došlo a segmenty X + 1, X + 2, X + 3, ... nebyly také dodány. Pak je celá řada odeslána z X - jako v protokolech GBN.

Problémy s maximální velikostí segmentu

TCP vyžaduje jasnou indikaci maximální velikosti segmentu, pokud se virtuální spojení provádí prostřednictvím segmentu sítě, kde je maximální velikost bloku (MTU) menší než standardní Ethernet MTU (1500 bajtů). V tunelovacích protokolech, jako je GRE, IPIP, stejně jako PPPoE MTU tunelu menší než standard, proto má maximální segment TCP délka balení než MTU. Vzhledem k tomu, že fragmentace v drtivou většině je zakázáno, jsou tyto balíčky vyřazeny.

Projevmého problému vypadá jako "zavěšení" spojení. Současně se "zavěšení" může nastat v libovolných okamžicích času, a to, když odesílatel použil segmenty delší než přípustnou velikost. Chcete-li tento problém vyřešit, směrovače používají pravidla brány firewall, která přidávají parametr MSS na všechny balíčky, které iniciovaly připojení tak, aby odesílatel použil segmenty přípustné velikosti. MSS mohou být také spravovány parametry operačního systému.

Trojitý handshake

Pro navázání spojení, hostitel 2 pasivně očekává příchozí spojení provedením přijetí přijetí.

Host 2 provádí primitivu Connect, určující IP adresu a port, s nímž chce navázat spojení, maximální velikost segmentu TCP atd. Koncept primitive odešle segment TCP "požadavek na připojení" s trochou SYN \u003d 1 a vyřazený bit Ask \u003d 0 a čeká na odpověď. Hostitel 1 tedy hlásí číslo sekvence X sekvence bitů z hostitele 1 až 2.

Host 2 odkazuje na potvrzení odpovědi "Přijaté připojení" (přijmout funkci). Sekvence segmentů TCP odeslaných v normálním případě je zobrazena na obr .: SYN \u003d 1 Zeptejte se \u003d 1, hostitel 2 hlásí číslo sekvence x bitové sekvence z hostitele 2 až 1 a hlásí, že očekává, že bude pokračovat v údaje z bajtové číslo x + 1.

Hostitel 1 (Connect) odešle potvrzení o souhlasu s navázáním spojení.

Boj proti přetížení v TCP

Pokud je v jakékoli síti přijata více dat, než je schopna zpracovávat, je v síti vytvořena přetížení. Internet v tomto smyslu není výjimkou. Ačkoli úroveň sítě se také snaží bojovat proti přetížení, hlavním příspěvkem k řešení tohoto problému, který spočívá v snižování rychlosti přenosu dat, provádí protokol TCP.

Teoreticky se s přetížením může bojovat s pomocí principu vypůjčeného z fyziky, zákonem zachování balíčků. Myšlenka není přenášet nové balíčky do sítě, dokud neopakuje (to znamená, že nebudou doručeny) staré. Protokol TCP se snaží dosáhnout tohoto cíle pomocí ovládání velikosti dynamického okna.

Prvním krokem v boji proti přetížení je detekovat. Před několika desítkami let bylo těžké detekovat přetížení. Bylo těžké pochopit, proč nebyl balíček včas doručen. Kromě možnosti přetížení sítě došlo také vysoká pravděpodobnost ztráty balení kvůli vysoké úrovni interference na lince.

V současné době jsou ztráty přenosových paketů poměrně vzácné, protože většina dálkových komunikačních linií jsou optická vlákna (i když procento paketů ztracených v důsledku rušení je poměrně vysoká). V souladu s tím je většina ztracených balíčků na internetu způsobena strmým. Všechny algoritmy Internet TCP naznačují, že ztráty paketu jsou způsobeny přetížením sítě a následují časově autory jako forenzní problémy.

Před zahájením diskuse o tom, jak TCP reaguje na přetížení, poprvé poprvé popisujeme způsoby, jak zabránit tomu, aby se protokol použil. Při detekci přetížení musí být vybrána vhodná velikost okna. Příjemce může specifikovat velikost okna na základě množství volného místa v vyrovnávací paměti. Pokud odesílatel bude mít na paměti velikost okna přidělené ho, přetečení vyrovnávací paměti u příjemce nebude schopen způsobit problém, ale může se stále vyskytnout v důsledku přetížení v libovolné části sítě mezi odesílatelem a příjemce.

Boj proti přetížení v TCP

Tento problém ilustrujeme na příkladu vodovodního potrubí. Na obrázku, a vidíme tlustá trubka vedoucí k příjemci s malou kapacitou. Dokud odesílatele neodesílá vodu více, než se vejde do nádoby, voda není úniku, na obrázku B se restnant faktorem není lopaty, ale šířka pásma sítě. Pokud se voda vylévá z jeřábu do nálevky příliš rychle, hladina vody v nálevce začne stoupat a nakonec může část vody vypálit okraj nálevky.

Rozhodnutí o internetu je rozpoznat existenci dvou potenciálních problémů: nízkou šířku pásma sítě a nízká kapacita příjemce - a v samostatném rozhodnutí obou problémů. Za tímto účelem má každý odesílatel dvě Windows: okno poskytované příjemcem a oknem přetížení. Velikost každého z nich odpovídá počtu bajtů, které má odesílatel právo sdělit. Odesílatel je veden minimem těchto dvou hodnot. Příjemce například říká: "Poslat 8 KB", ale odesílatel ví, že pokud odešle více než 4 kB, pak je síť vytvořena, takže to odesílá 4 kBytes. Pokud odesílatel ví, že síť je schopna chybět a více dat, například 32 kB, bude dá stejně jako příjemce požádá (to je, 8 kb).

Při instalaci odesílatele odesílatel nastaví velikost okna přetížení rovnou velikosti maximálního segmentu použitého v tomto připojení. Pak přenáší jeden maximální segment. Pokud potvrzení tohoto segmentu přijde před vypršením čekací doby, je velikost segmentu přidána do velikosti okna, tj. Okno přetížení je zdvojnásobeno a jsou odeslány dva segmenty. V reakci na potvrzení každého ze segmentů je okno přetížení rozšířeno o hodnotu jednoho maximálního segmentu. Předpokládejme, že velikost okna je n v segmentech. Pokud potvrzení pro všechny segmenty přichází včas, okno se zvyšuje počtem bajtů odpovídajících segmentům n. Ve skutečnosti potvrzení každé sekvence segmentu vede k zdvojení okna přetížení.

Tento proces exponenciálního růstu pokračuje, dokud nebude dosaženo okna příjemce nebo bude vyvinuta funkce TAJA-out, který přetížení signálu v síti. Například, pokud pakety 1024, 2048 a 4096 bajtů úspěšně dosáhly příjemce, a v reakci na přenos balíku 8192 bajtů, potvrzení nebylo spadáno do stanoveného období, okno přetížení je nastaveno na 4096 bajtů. Zatímco velikost okna přetížení zůstane rovna 4096 bajtů, delší pakety nejsou odeslány, bez ohledu na velikost okna poskytnutého příjemcem. Tento algoritmus se nazývá zAČÁTEK STARTOr. pomalý start. Nicméně, on není tak pomalý (Jacobson, 1988). Je exponenciální. Všechny implementace protokolu TCP jej musí podporovat.

Zvažte nyní mechanismus boje proti přetížení použitému na internetu. Kromě oken příjemce a přetížení se prahová hodnota používá jako třetí parametr, který je zpočátku nastaven na 64 kb. Když nastane situace časového limitu (potvrzení není včas vráceno), nová prahová hodnota je nastavena na polovinu aktuálního okna přetížení a okno přetížení klesá na velikost jednoho maximálního segmentu. Stejně jako v předchozím případě se používá algoritmus startování, který umožňuje rychle zjistit šířku pásma sítě. Tentokrát však exponenciální zvýšení velikosti okna se zastaví pro dosažení prahové hodnoty, po které se okno zvyšuje lineárně, jeden segment pro každou další přenos. V podstatě se předpokládá, že můžete bezpečně snížit dvojnásobnou velikost okna přetížení, po kterém je postupně zvyšovat.

Spolehlivé přenosové mechanismy. Zobecnění

Zkontrolovat sum	Detekce bitového zkreslení v přijatém balíčku
Časovač	Počítání intervalu očekávání a údaj o jeho vypršení platnosti. To znamená, že s vysokým stupněm pravděpodobnosti je balení nebo jeho příjem ztracen během přenosu. V případě, že je balíček dodán se zpožděním, ale neztratí (předčasné rozšíření intervalu očekávání) nebo dojde ke ztrátě přijetí, re-převodovka vede k připevnění balení na přijímací straně
Řadové číslovky	Sekvenční číslování paketů odeslaných vysílací stranou. "Prostory" v počtu získaných balíčků umožňují uzavření ztráty dat. Stejný sériový počet balíčků znamená, že se obaly navzájem duplikují
Příjmy "+" a "-"	Generované přijímající stranou a označuje přenosovou stranu na skutečnost, že odpovídající balení nebo skupina balíčků byly nebo nebyly převzaty. Obvykle potvrzení obsahuje sekvenční čísla úspěšně přijatých balíčků. V závislosti na protokolu, individuální a skupinové potvrzení rozlišují
Okno / dopravník.	Omezte rozsah sekvenčních čísel, které lze použít k přenosu paketů. Skupinový přenos a potvrzení vám umožní výrazně zvýšit šířku pásma protokolů ve srovnání s režimem potvrzení o očekávání. Velikost okna lze vypočítat na základě příjmu a vyrovnávacích pamětí hostitele, stejně jako úroveň zatížení sítě

Programovací funkce

1. TCP Streaming.
   • situace A) je možná se špatným připojením, pokud časový interval mezi příchodem datových skupin sítí sítí je skvělý:
     • computer1 Po použití funkce Odeslat;
     • computer2 neobdrží všechny informace v jednom volání RECV (potřebujete několik hovorů).
   • situace b) je možné, pokud je časový interval mezi funkcemi odesílání malý a velikost dat je malá:
     • computer1 několikrát používá funkci Odeslat;
     • computer2 dostane všechny informace pro jeden volání.
2. UDP protokol
   • situace a) - nemožné
     • computer1 Po použití funkce Odeslat, segment UDP je rozdělen do několika paketů na úrovni sítě;
     • computer2 dostane segment je vždy jedno volání na přepočítání a pouze pokud přišly všechny IP Datagrams.
   • situace b) - nemožné
     • různé volání funkce SENDTO v počítači1 odpovídají jinému UDP Datagram a odlišné volání Recvfrom v počítači2.
3. Pokud je pufr ve funkcích RECV a RECVFrom menší než velikost odeslané dat, poté v případě UDP, datová část je ztracena a v případě protokolu protokolu protokolu protokolu protokolu TCP se zbytek uloží pro následné volání recv.
4. Server UDP má 1 zásuvku a server TCP má mnoho různých zásuvek (počtem současně připojených klientů) a každý předal své informace.