Aplikácia tcp ip klient server. Aplikácia klient-server na TCP stream sockete. Nastavenie hodnôt parametrov IP

Servery, ktoré implementujú tieto protokoly firemná sieť, poskytnúť klientovi IP adresu, bránu, sieťovú masku, menné servery a dokonca aj tlačiareň. Používatelia nemusia manuálne konfigurovať svojich hostiteľov, aby mohli používať sieť.

Operačný systém QNX Neutrino implementuje ďalší autokonfiguračný protokol s názvom AutoIP, ktorý je projektom výboru IETF pre automatické ladenie. Tento protokol sa používa v malých sieťach na prideľovanie IP adries na lokálnej úrovni (link-local) hostiteľom. Protokol AutoIP určuje lokálnu IP adresu linky sám pomocou vyjednávacej schémy s inými hostiteľmi a bez prístupu k centrálnemu serveru.

Použitie protokolu PPPoE

Skratka PPPoE znamená „Point-to-Point Protocol over Ethernet“. Tento protokol zapuzdruje dáta na prenos cez ethernetovú sieť s premostenou topológiou.

PPPoE je špecifikácia používateľskej konektivity Ethernetové siete k internetu prostredníctvom širokopásmového pripojenia, ako je prenajatá digitálna účastnícka linka, bezdrôtové zariadenie alebo káblový modem. Použitie protokolu PPPoE a širokopásmového modemu poskytuje používateľom lokálnu počítačová sieť individuálny autentifikovaný prístup k vysokorýchlostným dátovým sieťam.

Protokol PPPoE kombinuje technológiu Ethernet s protokolom PPP, čo vám umožňuje efektívne vytvoriť samostatné pripojenie k vzdialenému serveru pre každého používateľa. Riadenie prístupu, účtovanie pripojení a výber poskytovateľa služieb sú definované pre používateľov, nie pre hostiteľov. Výhodou tohto prístupu je, že telefónna spoločnosť ani ISP nemusia poskytovať žiadnu špeciálnu podporu.

Na rozdiel od telefonického pripojenia sú pripojenia DSL a káblový modem vždy aktívne. Pretože fyzické pripojenie k vzdialenému poskytovateľovi služieb je zdieľané viacerými používateľmi, je potrebná metóda účtovania, ktorá zaznamenáva odosielateľov prevádzky a ciele a spoplatňuje používateľov. Protokol PPPoE umožňuje používateľovi a vzdialenému hostiteľovi, ktorí sa zúčastňujú komunikačnej relácie, naučiť sa navzájom sieťové adresy počas počiatočnej výmeny tzv. objav(objav). Akonáhle sa vytvorí relácia medzi individuálnym používateľom a vzdialeným hostiteľom (napr. poskytovateľom internetových služieb), táto relácia môže byť monitorovaná, aby sa mohli účtovať prírastky. Mnoho domácností, hotelov a spoločností zdieľa internet prostredníctvom digitálnych účastníckych liniek pomocou technológie Ethernet a protokolu PPPoE.

Pripojenie PPPoE pozostáva z klienta a servera. Klient a server pracujú pomocou akéhokoľvek rozhrania, ktoré je blízke špecifikáciám Ethernetu. Toto rozhranie sa používa na prideľovanie IP adries klientom a viazanie týchto IP adries na používateľov a voliteľne na pracovné stanice namiesto autentifikácie založenej len na pracovnej stanici. Server PPPoE vytvorí spojenie point-to-point pre každého klienta.

Nastavenie relácie PPPoE

Ak chcete vytvoriť reláciu PPPoE, mali by ste použiť službupppoed. modulio-pkt-*pPoskytuje služby protokolu PPPoE. Najprv musíte bežaťio-pkt-*svhodný vodič. Príklad:

Aplikácia klient-server na TCP stream sockete

Nasledujúci príklad používa TCP na poskytovanie usporiadaných, spoľahlivých obojsmerných bajtových tokov. Poďme zostaviť kompletnú aplikáciu, ktorá obsahuje klienta a server. Najprv ukážeme, ako postaviť server na TCP stream socketoch, a potom klientsku aplikáciu na testovanie nášho servera.

Nasledujúci program vytvorí server, ktorý prijíma požiadavky na pripojenie od klientov. Server je zostavený synchrónne, takže vykonávanie vlákna je zablokované, kým server nesúhlasí s pripojením ku klientovi. Táto aplikácia demonštruje jednoduchý server, ktorý odpovedá klientovi. Klient ukončí spojenie odoslaním správy na server .

Server TCP

Vytvorenie štruktúry servera je znázornené na nasledujúcom funkčnom diagrame:

Tu úplný kód Programy SocketServer.cs:

// SocketServer.cs pomocou System; pomocou System.Text; pomocou System.Net; pomocou System.Net.Sockets; namespace SocketServer ( class Program ( static void Main(string args) ( // Nastavenie lokálneho koncového bodu pre socket IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = new IPEndPoint(ip 11000 ); // Vytvorenie soketu Tcp/Ip sListener = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Priraďte soket k lokálnemu koncovému bodu a počúvajte prichádzajúce sokety skúste ( sListener.Bind(ipEndPoint) ; sListener. Listen(10); // Začnite počúvať pripojenia, kým (true) ( ​​​​Console.WriteLine("Čaká sa na pripojenie na porte (0)", ipEndPoint); // Program sa pozastaví a čaká na prichádzajúce connection Socket handler = sListener.Accept(); string data = null; // Čakali sme na klienta, ktorý sa s nami pokúsi spojiť byte bytes = nový byte; int bytesRec = handler.Receive(bytes); data += Encoding.UTF8. GetString(bytes, 0, bytesRec); // Zobrazenie údajov na konzole Console.Write("Received text: " + údaje + "\n\n"); // Odoslanie odpovede klientovi\ string reply = "Ďakujeme za požiadavku v " + data.Length.ToString() + " znaky"; byte msg = Kódovanie.UTF8.GetBytes(odpoveď); handler.Send(msg); if (data.IndexOf(" ") > -1) ( Console.WriteLine("Server ukončil spojenie s klientom."); break; ) handler.Shutdown(SocketShutdown.Both); handler.Close(); ) ) catch (Exception ex) ( Console.WriteLine (napr.ToString()); ) nakoniec ( Console.ReadLine(); ) ) ) )

Pozrime sa na štruktúru tohto programu.

Prvým krokom je nastavenie lokálneho koncového bodu pre soket. Pred otvorením soketu na počúvanie pripojení musíte preň pripraviť adresu lokálneho koncového bodu. Jedinečná adresa služby TCP/IP je určená kombináciou adresy IP hostiteľa s číslom portu služby, ktorý vytvára koncový bod služby.

Trieda Dns poskytuje metódy, ktoré vracajú informácie o sieťových adresách podporovaných zariadením v lokálna sieť. Ak má zariadenie LAN viac ako jednu sieťovú adresu, trieda Dns vráti informácie o všetkých sieťových adresách a aplikácia musí z poľa vybrať vhodnú adresu, ktorá bude slúžiť.

Vytvorte IPEndPoint pre server kombináciou prvej hostiteľskej IP adresy získanej metódou Dns.Resolve() s číslom portu:

IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = new IPEndPoint(ipAddr, 11000);

Tu trieda IPEndPoint predstavuje localhost na porte 11000. Ďalej vytvoríme stream socket s novou inštanciou triedy Socket. Nastavením lokálneho koncového bodu na počúvanie pripojení môžete vytvoriť soket:

Socket sListener = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

Enumerácia AdresaRodinašpecifikuje schémy adresovania, ktoré môže inštancia triedy Socket použiť na rozlíšenie adresy.

V parametri SocketType TCP a UDP sokety sa líšia. Môže obsahovať nasledujúce hodnoty:

Podporuje datagramy. Hodnota Dgram vyžaduje, aby ste v parametri rodiny adries zadali Udp pre typ protokolu a sieť InterNetwork.

Podporuje prístup k základnému transportnému protokolu.

Podporuje stream zásuvky. Hodnota Stream vyžaduje, aby bolo pre typ protokolu špecifikované Tcp.

Tretí a posledný parameter určuje typ protokolu potrebného pre soket. V parametri ProtocolType môžete zadať nasledujúce najdôležitejšie hodnoty - Tcp, Udp, Ip, Raw.

Ďalším krokom by malo byť priradenie zásuvky pomocou metódy Bind(). Keď je soket otvorený konštruktorom, nie je mu priradený názov, je rezervovaný iba handle. Volá sa metóda Bind() na priradenie názvu serverovému soketu. Aby klientsky soket mohol identifikovať prúd TCP soket, program servera musí pomenovať svoj soket:

SListener.Bind(ipEndPoint);

Metóda Bind() viaže soket na lokálny koncový bod. Pred akýmkoľvek pokusom o volanie metód Listen() a Accept() musíte zavolať metódu Bind().

Teraz, keď ste vytvorili soket a priradili k nemu názov, môžete pomocou tejto metódy počúvať prichádzajúce správy Počúvať (). V stave počúvania bude soket čakať na prichádzajúce pokusy o pripojenie:

SListener.Listen(10);

Parameter definuje nevybavené veci (backlog) A, ktoré určuje maximálny počet pripojení čakajúcich na spracovanie vo fronte. Vo vyššie uvedenom kóde hodnota parametra umožňuje zhromaždiť až desať spojení vo fronte.

V stave počúvania musíte byť pripravení súhlasiť so spojením s klientom, na ktorý sa metóda používa súhlasiť(). Táto metóda získa pripojenie klienta a dokončí spojenie medzi názvami klienta a servera. Metóda Accept() blokuje vlákno volajúceho programu, kým sa neprijme spojenie.

Metóda Accept() získa prvú požiadavku na pripojenie z frontu čakajúcich požiadaviek a vytvorí nový soket na jej spracovanie. Kým sa vytvorí nový soket, pôvodný soket naďalej načúva a možno ho použiť s multithreadingom na akceptovanie viacerých požiadaviek na pripojenie od klientov. Žiadna serverová aplikácia by nemala zatvoriť načúvací soket. Musí naďalej fungovať spolu so soketmi vytvorenými metódou Accept na spracovanie prichádzajúcich požiadaviek klientov.

While (true) ( ​​​​Console.WriteLine("Čaká sa na pripojenie na porte (0)", ipEndPoint); // Program sa pozastaví a čaká na prichádzajúce pripojenie Obslužný program soketu = sListener.Accept();

Keď klient a server nadviažu spojenie medzi sebou, môžete pomocou metód odosielať a prijímať správy Odoslať() a prijať () Trieda zásuvky.

Metóda Send() zapisuje odchádzajúce dáta do soketu, ku ktorému je pripojený. Metóda Receive() načítava prichádzajúce údaje zo zásuvky streamu. Pri použití systému na báze TCP sa musí vytvoriť spojenie medzi soketmi pred vykonaním metód Send() a Receive(). Presný protokol medzi dvoma interagujúcimi entitami sa musí určiť vopred, aby sa klientske a serverové aplikácie navzájom neblokovali a nevedeli, kto má odoslať svoje údaje ako prvý.

Po dokončení výmeny údajov medzi serverom a klientom musíte zatvoriť spojenie pomocou metód vypnúť() a Zavrieť():

Handler.Shutdown(SocketShutdown.Both); handler.Close();

SocketShutdown je zoznam obsahujúci tri hodnoty na zastavenie: Obaja- prestane odosielať a prijímať dáta na zásuvke, prijímať- prestane prijímať dáta na zásuvke a poslať- zastaví socket odosielať dáta.

Zásuvka sa zatvorí, keď sa zavolá metóda Close(), ktorá tiež nastaví vlastnosť Connected zásuvky na hodnotu false.

Klient na TCP

Funkcie, ktoré sa používajú na vytvorenie klientskej aplikácie, sú viac-menej ako serverová aplikácia. Pokiaľ ide o server, rovnaké metódy sa používajú na určenie koncového bodu, vytvorenie inštancie soketu, odosielanie a prijímanie údajov a zatvorenie soketu.

Cesta cez sieťové protokoly.

TCP aj UDP sú protokoly transportnej vrstvy. UDP je protokol bez spojenia s negarantovaným doručovaním paketov. TCP (Transmission Control Protocol) je spojovo orientovaný protokol s garantovaným doručovaním paketov. Najprv dôjde k podaniu ruky (Ahoj | Ahoj | Porozprávame sa? | Poď.), po ktorom sa spojenie považuje za nadviazané. Ďalej sa cez toto spojenie posielajú pakety tam a späť (prebieha konverzácia) a skontroluje sa, či sa paket dostal k príjemcovi. Ak je balík stratený alebo dosiahnutý, ale s pálkou kontrolný súčet, potom sa odošle znova („opakujem, nepočul som“). TCP je teda spoľahlivejší, ale je náročnejší z hľadiska implementácie, a preto vyžaduje viac cyklov / pamäte, čo nie je najnovšia hodnota pre mikrokontroléry. Príklady aplikačných protokolov, ktoré používajú TCP, zahŕňajú FTP, HTTP, SMTP a mnohé ďalšie.

TL;DR

HTTP (Hypertext Transfer Protocol) je aplikačný protokol, pomocou ktorého server odosiela stránky do nášho prehliadača. HTTP je teraz všadeprítomný World Wide Web získať informácie z webových stránok. Na obrázku je lampa na mikrokontroléri s OS na doske, v ktorom sa farby nastavujú cez prehliadač.

Protokol HTTP je založený na texte a je pomerne jednoduchý. V skutočnosti takto vyzerá metóda GET odoslaná obslužným programom netcat na lokálnu adresu IPv6 servera so svetlami:

~$ nc fe80::200:e2ff:fe58:b66b%mazko 80<

Metóda HTTP je zvyčajne krátke anglické slovo napísané veľkými písmenami, pričom sa rozlišujú malé a veľké písmená. Každý server musí podporovať aspoň metódy GET a HEAD. Okrem metód GET a HEAD sa často používajú metódy POST, PUT a DELETE. Metóda GET sa používa na vyžiadanie obsahu špecifikovaného zdroja, v našom prípade tu GET /b HTTP/1.0, kde cesta /b je zodpovedná za farbu (modrá). Odpoveď servera:

HTTP/1.0 200 OK Server: Contiki/2.4 http://www.sics.se/contiki/ Pripojenie: zatvorte Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Content- typ: text/html

Červená je VYPNUTÁ

Zelená je VYPNUTÁ

Modrá je ZAPNUTÁ

Stavový kód (máme 200) je súčasťou prvého riadku odpovede servera. Je to trojciferné celé číslo. Prvá číslica označuje triedu stavu. Po kóde odpovede zvyčajne nasleduje vysvetľujúca fráza v angličtine oddelená medzerou, ktorá osobe vysvetľuje dôvod takejto odpovede. V našom prípade server fungoval bez chýb, všetko bolo v kope (OK).

Požiadavka aj odpoveď obsahujú hlavičky (každý riadok je samostatné pole hlavičky, pár názov-hodnota je oddelený dvojbodkou). Hlavičky končia prázdnym riadkom, po ktorom môžu nasledovať údaje.

Môj prehliadač odmieta otvoriť lokálnu IPv6 adresu, takže vo firmvéri mikrokontroléra je zaregistrovaná ďalšia adresa a rovnaká predpona musí byť priradená aj virtuálnemu sieťovému rozhraniu simulátora:

~$ sudo ip addr add abcd::1/64 dev mazko # linux ~$ netsh interface ipv6 nastaviť adresu mazko abcd::1 # windows ~$ curl http://

TCP sa prirodzene integruje do prostredia klient/server (pozri obrázok 10.1). Serverová aplikácia chyby(počúvať) prichádzajúce požiadavky na pripojenie. Napríklad WWW, prenos súborov alebo služby terminálového prístupu počúvajú požiadavky klientov. Komunikáciu v TCP iniciujú príslušné podprogramy, ktoré iniciujú pripojenie k serveru (pozrite si kapitolu 21 o rozhraní API soketu).

Ryža. 10.1. Klient volá server.

V skutočnosti môže byť klientom iný server. Napríklad poštové servery sa môžu spojiť s inými poštovými servermi a posielať e-mailové správy medzi počítačmi.

V akej forme majú aplikácie odosielať údaje v TCP? Ako TCP prenáša dáta do IP? Ako prenosové a prijímacie protokoly TCP identifikujú spojenie medzi aplikáciami a dátové prvky potrebné na jeho implementáciu? Všetky tieto otázky sú zodpovedané v nasledujúcich častiach, ktoré popisujú základné pojmy TCP.

Koncepčný model pripojenia predpokladá, že aplikácia posiela dátový tok partnerskej aplikácii. Zároveň je schopný prijímať dátový tok od svojho partnera na pripojenie. TCP poskytuje plný duplex(plne duplexný) režim prevádzky, v ktorom sú obe dva prúdyúdaje (pozri obrázok 10.2).

Ryža. 10.2. Aplikácie si vymieňajú dátové toky.

TCP dokáže konvertovať odchádzajúci dátový tok z aplikácie do formy vhodnej na umiestnenie do datagramov. Ako?

Aplikácia posiela dáta na TCP a tento protokol ich vkladá výstupná vyrovnávacia pamäť(odoslať vyrovnávaciu pamäť). Ďalej TCP oddelí časti údajov z vyrovnávacej pamäte a odošle ich, pričom pridá hlavičku (v tomto prípade segmentov segment). Na obr. 10.3 ukazuje, ako údaje z výstupná vyrovnávacia pamäť TCP sú paketované do segmentov. TCP odovzdá segment IP na doručenie ako jeden datagram. Zbalenie údajov do častí správnej dĺžky zaisťuje efektívne preposielanie, takže TCP pred vytvorením segmentu počká, kým bude príslušné množstvo údajov vo výstupnej vyrovnávacej pamäti.

Ryža. 10.3 Vytvorenie segmentu TCP

Veľké množstvo údajov však často nie je použiteľné pre aplikácie v reálnom svete. Napríklad, keď klientsky program koncového používateľa iniciuje interaktívnu reláciu so vzdialeným serverom, používateľ potom iba zadá príkazy (nasledované stlačením tlačidla vrátiť).

Klientsky program užívateľa potrebuje TCP, aby vedel, že údaje sa odosielajú do vzdialeného hostiteľa, a aby túto operáciu okamžite vykonal. V tomto prípade sa používa vytláčanie(TLAČIŤ).

Ak sa pozriete na operácie v interaktívnej relácii, môžete nájsť veľa zlomkov s malým množstvom údajov a čo viac, objavovanie sa dá nájsť takmer v každom zlomku údajov. Popping by sa však nemal používať počas prenosu súborov (okrem úplne posledného segmentu) a protokol TCP bude schopný zbaliť údaje do segmentov najefektívnejšie.

Model odovzdávania údajov aplikácie predpokladá na ceste do cieľa usporiadaný prúd bajtov. Opäť s odkazom na príklad interaktívnej relácie predpokladajme, že používateľ stlačil kláves pozornosť(pozor) resp prestávka(prerušiť). Vzdialená aplikácia musí byť schopná preskočiť rušivé bajty a reagovať na stlačenie klávesu čo najskôr.

Mechanizmus urgentné údaje(urgentné údaje) označuje špeciálne informácie v segmente ako súrne. S týmto TCP informuje svojho partnera, že segment obsahuje naliehavé údaje a môže indikovať, kde sa nachádza. Partner by mal tieto informácie čo najskôr postúpiť do cieľovej aplikácie.

Klient musí identifikovať službu, ku ktorej chce pristupovať. To sa vykonáva prostredníctvom špecifikácie IP adresy hostiteľskej služby a čísla jej TCP portu. Rovnako ako v prípade UDP, čísla portov TCP sa pohybujú od 0 do 65535. Porty od 0 do 1023 sú známe ako dobre známe porty a používajú sa na prístup k štandardným službám.

Niekoľko príkladov dobre známych portov a ich zodpovedajúcich aplikácií je uvedených v tabuľke 10.1. Služby Zahodiť(port 9) a spoplatnené(port 19) sú TCP verzie služieb, ktoré už poznáme z UDP. Majte na pamäti, že prevádzka na porte TCP 9 je úplne izolovaná od prevádzky na porte UDP 9.

Tabuľka 10.1 Dobre známe porty TCP a ich zodpovedajúce aplikácie

A čo porty používané klientmi? V zriedkavých prípadoch klient nebeží na dobre známom porte. Ale v takýchto situáciách, keď chce otvoriť pripojenie, často požiada operačný systém, aby mu priradil nepoužívaný a nevyhradený port. Na konci pripojenia musí klient vrátiť tento port späť, po ktorom môže byť port znovu použitý iným klientom. Pretože v oblasti nerezervovaných čísel je viac ako 63 000 portov TCP, limity klientskych portov možno ignorovať.

Ako už vieme, kombinácia IP adresy a portu pre komunikáciu je tzv adresa zásuvky. TCP spojenie je plne identifikované adresou soketu na každom konci tohto spojenia. Na obr. Obrázok 10.4 zobrazuje spojenie medzi klientom s adresou soketu (128.36.1.24, port = 3358) a serverom s adresou soketu (130.42.88.22, port = 21).

Ryža. 10.4. adresy zásuvky

Hlavička každého datagramu obsahuje zdrojovú a cieľovú IP adresu. V nasledujúcom texte uvidíte, že čísla zdrojových a cieľových portov sú špecifikované v hlavičke segmentu TCP.

Server je zvyčajne schopný spravovať viacero klientov súčasne. Jedinečné adresy soketov servera sú priradené súčasne všetkým jeho klientom (pozri obrázok 10.5).

Ryža. 10.5. K adresám soketu servera je pripojených viacero klientov

Keďže datagram obsahuje segment TCP spojenia identifikovaný IP adresami a portami, je pre server veľmi jednoduché sledovať viaceré pripojenia ku klientom.

V tejto časti sa pozrieme na mechanizmus TCP používaný na spoľahlivé doručenie údajov pri zachovaní poradia preposielania a zabránení strate alebo duplicite.

TCP používa číslovanie a potvrdenie (ACK) na zabezpečenie spoľahlivého prenosu dát. Schéma číslovania TCP je trochu nezvyčajná: každý preposlané cez spojenie oktet považované za majúce sériové číslo. Hlavička segmentu TCP obsahuje poradové číslo prvý dátový oktet tohto segmentu.

Príjemca je povinný potvrdiť príjem údajov. Ak počas časového limitu nepríde žiadne ACK, údaje sa prenesú znova. Táto metóda sa nazýva pozitívne potvrdenie s relé(pozitívne potvrdenie s retransmisiou).

Prijímač údajov TCP vykoná prísnu kontrolu prichádzajúcich sekvenčných čísel, aby skontroloval poradie, v ktorom boli údaje prijaté, a či nie sú stratené časti. Pretože ACK môže byť náhodne stratené alebo oneskorené, do prijímača môžu doraziť duplicitné segmenty. Sekvenčné čísla umožňujú určiť duplicitu údajov, ktoré sa potom vyradia.

Na obr. Obrázok 10.6 zobrazuje zjednodušený pohľad na časový limit a opakovaný prenos v TCP.

Ryža. 10.6.Časový limit a opakovaný prenos v TCP

Ako je znázornené na obr. 10.7, prvých niekoľko polí hlavičky TCP poskytuje priestor pre hodnoty zdrojového a cieľového portu, poradové číslo prvého bajtu vložených údajov a ACK rovnajúce sa poradovému číslu Ďalšie byte očakávaný na druhom konci. Inými slovami, ak TCP prijme všetky bajty do 30 od svojho partnera, toto pole bude mať hodnotu 31, čo označuje segment, ktorý sa má preposlať ďalej.

Ryža. 10.7. Počiatočné hodnoty v poliach hlavičky TCP

Treba poznamenať jeden malý detail. Predpokladajme, že TCP odoslal bajty 1 až 50 a nie sú k dispozícii žiadne ďalšie údaje na odoslanie. Ak sú údaje prijaté od partnera, TCP musí potvrdiť prijatie odoslaním hlavičky bez pripojených údajov. V tejto hlavičke je prirodzene prítomná hodnota ACK. V poli poradia - hodnota 51, t.j. číslo ďalšieho bajtu zamýšľa poslať TCP. Keď TCP odošle ďalšie údaje, nová hlavička TCP bude mať tiež hodnotu 51 v poli sekvencie.

Ako sú tieto dve aplikácie prepojené? Pred komunikáciou každý z nich zavolá rutinu na vytvorenie bloku pamäte, ktorý sa použije na uloženie parametrov TCP a IP tohto pripojenia, ako sú adresy soketov, aktuálne poradové číslo, počiatočná hodnota životnosti atď.

Serverová aplikácia čaká, kým sa objaví klient, ktorý chce získať prístup k serveru a zadá požiadavku zlúčenina(pripojenie) identifikujúce IP adresu a port servera.

Je tu jedna technická vlastnosť. Každá strana začína číslovať každý bajt nie od jedného, ​​ale od náhodné sériové číslo(Uvidíme, prečo sa to robí neskôr.) Pôvodná špecifikácia odporúča vygenerovať počiatočné poradové číslo na základe 32-bitového externého časovača, ktorý sa zvyšuje približne každé 4 µs.

Procedúra pripojenia sa často označuje ako trojstranný handshake, pretože na vytvorenie spojenia sa vymenia tri správy – SYN, SYN a ACK.

Počas vytvárania spojenia si partneri vymieňajú tri dôležité informácie:

1. Množstvo vyrovnávacieho priestoru pre príjem údajov

2. Maximálne množstvo dát prenášaných v prichádzajúcom segmente

3. Počiatočné poradové číslo používané pre odchádzajúce dáta

Všimnite si, že každá strana používa na označenie operácie 1 a 2 limity, v ktorých bude druhá strana konať. Osobný počítač môže mať malú prijímaciu vyrovnávaciu pamäť, zatiaľ čo superpočítač môže mať veľkú vyrovnávaciu pamäť. Pamäťová štruktúra osobného počítača môže obmedziť prichádzajúce časti údajov na 1 KB a superpočítač je riadený veľkými segmentmi.

Schopnosť kontrolovať, ako druhá strana odosiela údaje, je dôležitou vlastnosťou, vďaka ktorej je TCP/IP škálovateľný.

Na obr. Obrázok 10.8 zobrazuje príklad skriptu pripojenia. Aby nedošlo k preťaženiu čísla, sú k dispozícii veľmi jednoduché počiatočné poradové čísla. Všimnite si, že na tomto obrázku je klient schopný prijímať väčšie segmenty ako server.

Ryža. 10.8. Nadviazanie spojenia

Vykonávajú sa tieto operácie:

1. Server sa inicializuje a je pripravený na spojenie s klientmi (tento stav sa nazýva pasívne otvorené - pasívne otvorené).

2. Klient požiada TCP, aby otvoril spojenie so serverom na zadanej IP adrese a porte (tento stav sa nazýva aktívne otvorené).

3. Klient TCP prijme počiatočné poradové číslo (v tomto príklade 1000) a odošle časovací segment(synchronizovať segment - SYN). V tomto segmente sa odosiela poradové číslo, veľkosť prijímacieho okna (4K) a veľkosť najväčšieho segmentu, ktorý môže klient prijať (1460 bajtov).

4. Keď príde SYN, server TCP prijme môj počiatočné poradové číslo (3000). Odošle segment SYN obsahujúci počiatočné poradové číslo (3000), ACK 1001 (čo znamená číslovanie prvého bajtu odoslaného klientom ako 1001), veľkosť prijímacieho okna (4 kB) a veľkosť najväčšieho segmentu, ktorý môže server prijať. (1024 bajtov).

5. Klient TCP po prijatí správy SYN/ACK zo servera odošle späť ACK 3001 (prvý bajt dát odoslaných serverom by mal byť očíslovaný ako 3001).

6. Klient TCP povie svojej aplikácii, aby otvorila spojenie.

7. Server TCP po prijatí ACK správy od TCP klienta informuje svoju aplikáciu, že spojenie bolo otvorené.

Klient a server oznámia svoje pravidlá pre prijímané dáta, synchronizujú svoje poradové čísla a sú pripravení na výmenu dát. Špecifikácia TCP tiež umožňuje ďalší scenár (nie veľmi dobrý), kde sa partnerské aplikácie aktívne otvárajú súčasne.

Požiadavka aplikácie na vytvorenie spojenia môže tiež špecifikovať parametre pre IP datagramy, ktoré budú prenášať dáta spojenia. Ak nie je zadaná žiadna špecifická hodnota parametra, použije sa predvolená hodnota.

Aplikácia môže napríklad vybrať požadovanú hodnotu pre prioritu IP alebo typ služby. Keďže každá z pripojených strán si nezávisle nastavuje svoju vlastnú prioritu a typ služby, teoreticky sa tieto hodnoty môžu líšiť pre rôzne smery dátových tokov. V praxi sa spravidla uplatňujú rovnaké hodnoty pre každý smer výmeny.

Keď aplikácia používa vládne alebo vojenské bezpečnostné možnosti, každý koncový bod pripojenia musí používať rovnaké úrovne zabezpečenia, inak pripojenie zlyhá.

Prenos údajov sa spustí po dokončení potvrdenia vytvorenia spojenia v troch krokoch (pozri obrázok 10.9). Štandard TCP umožňuje zahrnúť bežné údaje do potvrdzovacích segmentov, ale nebudú doručené do aplikácie, kým sa nedokončí spojenie. Pre zjednodušenie číslovania sa používajú 1000-bajtové správy. Každý segment hlavičky TCP má pole ACK identifikujúce bajtové poradové číslo, ktoré sa očakáva od partnera pripojenia..

Ryža. 10.9. Jednoduchý tok dát a ACK

Prvý segment odoslaný klientom obsahuje bajty od 1001 do 2000. Jeho pole ACK musí obsahovať hodnotu 3001, ktorá označuje poradové číslo bajtov, ktoré sa očakáva zo servera.

Server odpovie klientovi segmentom obsahujúcim 1000 bajtov údajov (začínajúc číslom 3001). Jeho pole ACK v hlavičke TCP bude indikovať, že bajty 1001 až 2000 už boli úspešne prijaté, takže ďalšie očakávané poradové číslo segmentu od klienta by malo byť 2001.

Klient potom odošle segmenty začínajúce bajtmi 2001, 3001 a 4001 v tomto poradí. Všimnite si, že klient neočakáva ACK po každom odoslanom segmente. Dáta sa odosielajú peerovi, kým sa nezaplní jeho vyrovnávacia pamäť (nižšie uvidíme, že prijímač môže veľmi presne špecifikovať množstvo dát, ktoré mu majú byť odoslané).

Server šetrí šírku pásma pripojenia pomocou jediného ACK na označenie, že všetky segmenty boli úspešne preposlané.

Na obr. Obrázok 10.10 zobrazuje preposielanie údajov pri strate prvého segmentu. Keď uplynie časový limit, segment sa odošle znova. Všimnite si, že po prijatí strateného segmentu prijímač pošle jedno potvrdenie ACK potvrdzujúce preposielanie oboch segmentov.

Ryža. 10.10. Strata dát a opakovaný prenos

Normálne ukončenie spojenia sa vykonáva pomocou rovnakého postupu trojitého nadviazania spojenia ako pri otváraní spojenia. Každá strana môže začať zatvárať spojenie v nasledujúcom scenári:

A:

B:"Dobré".

AT:"Tiež som dokončil prácu."

A:"Dobré".

Prijateľný je aj nasledujúci scenár (hoci sa používa veľmi zriedka):

A:"Dokončil som úlohu. Už nie sú žiadne ďalšie údaje na odoslanie."

AT:"Dobre. Sú však nejaké údaje..."

AT:"Tiež som dokončil prácu."

A:"Dobré".

V nižšie uvedenom príklade pripojenie zatvorí server, ako je to často v prípade komunikácie klient/server. V tomto prípade potom, čo používateľ vstúpi do relácie telnet príkaz logout (odhlásenie zo systému) server spustí požiadavku na ukončenie spojenia. V situácii znázornenej na obr. 10.11 sa vykonávajú tieto akcie:

1. Aplikácia na serveri povie TCP, aby ukončil spojenie.

2. Server TCP odošle záverečný segment (FIN), ktorý informuje svojho partnera, že už nie sú k dispozícii žiadne údaje na odoslanie.

3. Klient TCP odošle ACK na segment FIN.

4. TCP klienta oznámi svojej aplikácii, že server chce ukončiť spojenie.

5. Klientska aplikácia informuje svoj TCP, že spojenie je ukončené.

6. Klient TCP odošle správu FIN.

7. Server TCP prijme FIN od klienta a odpovie správou ACK.

8. TCP servera povie svojej aplikácii, aby ukončila spojenie.

Ryža. 10.11. Uzatváranie spojenia

Obe strany sa môžu začať zatvárať súčasne. V tomto prípade je normálne uzavretie spojenia dokončené potom, čo každý z partnerov odošle správu ACK.

Ktorákoľvek strana môže požiadať o náhle ukončenie spojenia. Toto je prijateľné, keď si aplikácia želá ukončiť spojenie, alebo keď TCP zistí vážny komunikačný problém, ktorý nedokáže vyriešiť sám. Náhle ukončenie sa vyžaduje odoslaním jednej alebo viacerých resetovacích správ partnerovi, ako to indikuje špecifický príznak v hlavičke TCP.

Prijímač TCP je načítaný prichádzajúcim dátovým tokom a určuje, koľko informácií môže prijať. Toto obmedzenie ovplyvňuje odosielateľa TCP. Nasledujúce vysvetlenie tohto mechanizmu je koncepčné a vývojári ho môžu vo svojich produktoch implementovať odlišne.

Počas nastavovania pripojenia každý partner pridelí priestor pre vstupnú vyrovnávaciu pamäť pripojenia a upozorní na to druhú stranu. Typicky je veľkosť vyrovnávacej pamäte vyjadrená ako celé číslo maximálnych veľkostí segmentov.

Dátový tok vstupuje do vstupnej vyrovnávacej pamäte a je tam uložený, kým sa nepošle do aplikácie (určené TCP portom). Na obr. Obrázok 10-12 zobrazuje vstupnú vyrovnávaciu pamäť, ktorá môže zaberať 4 KB.

Ryža. 10.12. Okno prijímania vstupnej vyrovnávacej pamäte

Priestor vyrovnávacej pamäte sa zaplní pri príchode údajov. Keď prijímajúca aplikácia stiahne údaje z vyrovnávacej pamäte, uvoľnený priestor sa sprístupní pre nové prichádzajúce údaje.

prijímacie okno(prijímacie okno) - akékoľvek miesto vo vstupnej vyrovnávacej pamäti, ktoré ešte nie je obsadené údajmi. Údaje zostávajú vo vstupnej vyrovnávacej pamäti, kým ich nepoužije cieľová aplikácia. Prečo aplikácia nezhromažďuje údaje okamžite?

Odpoveď na túto otázku pomôže jednoduchý scenár. Predpokladajme, že klient nahral súbor na FTP server spustený na veľmi vyťaženom počítači s viacerými používateľmi. Program FTP potom musí prečítať údaje z vyrovnávacej pamäte a zapísať ich na disk. Keď server vykoná diskové I/O operácie, program čaká na dokončenie týchto operácií. V tomto čase sa môže spustiť iný program (napríklad podľa plánu) a kým sa program FTP znova spustí, ďalšie údaje už budú vo vyrovnávacej pamäti.

Prijímacie okno je rozšírené od posledného potvrdeného bajtu po koniec vyrovnávacej pamäte. Na obr. 10.12 je najprv k dispozícii celá vyrovnávacia pamäť, a preto je k dispozícii prijímacie okno v rozlíšení 4K. Pri príchode prvého KB sa okno príjmu zmenší na 3 KB (pre jednoduchosť budeme predpokladať, že každý segment má veľkosť 1 KB, aj keď v praxi sa táto hodnota mení v závislosti od potrieb aplikácie). Príchod ďalších dvoch 1K segmentov zníži prijímacie okno na 1K.

Každý ACK odoslaný prijímačom obsahuje informáciu o aktuálnom stave prijímacieho okna, v závislosti od toho je regulovaný dátový tok zo zdroja.

Väčšinou sa veľkosť vstupnej vyrovnávacej pamäte nastavuje pri spustení pripojenia, hoci štandard TCP nešpecifikuje, ako túto vyrovnávaciu pamäť spravovať. Vstupná vyrovnávacia pamäť sa môže zväčšiť alebo zmenšiť, aby poskytla odosielateľovi spätnú väzbu.

Čo sa stane, ak sa prichádzajúci segment dá umiestniť do prijímacieho okna, ale príde mimo poradia? Všeobecne sa usudzuje, že všetky implementácie ukladajú prichádzajúce dáta do prijímacieho okna a posielajú potvrdenie (ACK) len pre celý súvislý blok niekoľkých segmentov. Toto je správny spôsob, pretože v opačnom prípade vyhadzovanie údajov mimo poradia výrazne zníži výkon.

Systém prenášajúci dáta musí sledovať dve charakteristiky: koľko dát už bolo odoslaných a potvrdených a aktuálnu veľkosť prijímacieho okna. Aktívne posielanie priestoru(medzera na odoslanie) Rozširuje sa od prvého nepotvrdeného oktetu naľavo od aktuálneho prijímacieho okna. Časť okno použité poslať, označuje, koľko dodatočných údajov je možné poslať partnerovi.

Počiatočné poradové číslo a počiatočná veľkosť prijímacieho okna sa nastavia počas nastavovania pripojenia. Ryža. 10.13 znázorňuje niektoré vlastnosti mechanizmu prenosu údajov.

1. Odosielateľ začína odosielacím oknom s veľkosťou 4 KB.

2. Odosielateľ posiela 1 KB. Kópia týchto údajov sa uchováva až do prijatia potvrdenia (ACK), pretože môže byť potrebné znova ju odoslať.

3. Príde ACK pre prvý KB a odošle sa ďalšie 2 KB dát. Výsledok je znázornený v tretej časti zhora na obr. 10.13. Úložisko 2 KB pokračuje.

4. Nakoniec príde ACK pre všetky prenášané dáta (t.j. všetky prijaté prijímačom). ACK obnoví veľkosť odosielacieho okna na 4 kB.

Ryža. 10.13. Odoslať okno

Je potrebné zdôrazniť niekoľko zaujímavých funkcií:

■ Odosielateľ nečaká na potvrdenie ACK pre každý z odoslaných dátových segmentov. Jediným obmedzením prenosu je veľkosť prijímacieho okna (napr. odosielateľ musí preniesť iba 4K jednobajtové segmenty).

■ Predpokladajme, že odosielateľ odosiela údaje v niekoľkých veľmi krátkych segmentoch (napríklad 80 bajtov). V tomto prípade môžu byť dáta preformátované pre efektívnejší prenos (napr. do jedného segmentu).

Na obr. Obrázok 10.14 zobrazuje formát segmentu (hlavička TCP a dáta). Hlavička začína ID zdroja a cieľa. Ďalšie pole sériové číslo(číslo poradia) označuje pozíciu v toku odchádzajúceho dát, ktorú tento segment zaberá. Lúka ACK(potvrdenie) obsahuje informácie o očakávanom ďalšom segmente, ktorý by sa mal objaviť vo vstupnom dátovom toku.

Ryža. 10.14. TCP segment

Existuje šesť vlajok:

Lúka posuny údajov(Data Offset) obsahuje veľkosť TCP hlavičky v 32-bitových slovách. Hlavička TCP musí končiť na 32-bitovej hranici.

Parameter "maximálna veľkosť segmentu"(maximálna veľkosť segmentu - MSS) sa používa na deklarovanie najväčšieho kusu údajov, ktorý môže systém prijať a spracovať. Názov je však trochu nepresný. Zvyčajne v TCP segment spracované ako hlavička plus údaje. Avšak maximálna veľkosť segmentu definovaný ako:

Veľkosť najväčšieho datagramu, ktorý je možné prijať, je 40

Inými slovami, MSS odráža najväčšie užitočné zaťaženie na prijímači, keď sú hlavičky TCP a IP dlhé 20 bajtov. Ak existujú ďalšie parametre, ich dĺžka by sa mala odpočítať od celkovej veľkosti. Množstvo údajov, ktoré možno odoslať v segmente, je preto definované ako:

Deklarovaná hodnota MSS + 40 - (súčet dĺžok hlavičiek TCP a IP)

Pri otvorení spojenia si partneri zvyčajne vymieňajú hodnoty MSS v počiatočných správach SYN. Ak systém neuvádza maximálnu veľkosť segmentu, použije sa predvolená hodnota 536 bajtov.

Maximálna veľkosť segmentu je zakódovaná 2-bajtovou preambulou, za ktorou nasleduje 2-bajtová hodnota, t.j. najväčšia hodnota by bola 2 16 -1 (65 535 bajtov).

MSS ukladá pevný limit na dáta odosielané do TCP: prijímač nebude schopný spracovať veľké hodnoty. Odosielateľ však používa segmenty menšiu veľkosť keďže pre spojenie je určená aj veľkosť MTU po trase.

Prvý segment odoslaný na otvorenie spojenia má príznak SYN 1 a príznak ACK 0. Počiatočný SYN je jediný segment, ktorý má pole ACK 0. Všimnite si, že bezpečnosť používa túto funkciu na detekciu prichádzajúcich požiadaviek na reláciu TCP.

Lúka sériové číslo obsahuje počiatočné poradové číslo(počiatočné poradové číslo), pole okno - počiatočná veľkosť prijímacie okno. Jediné aktuálne definované nastavenie TCP je maximálna veľkosť segmentu (ak nie je špecifikovaná, použije sa predvolená hodnota 536 bajtov), ​​ktorú má TCP prijať. Táto hodnota je dlhá 32 bitov a zvyčajne sa nachádza v žiadosti o pripojenie v poli možnosti(Možnosť). Dĺžka hlavičky TCP obsahujúcej hodnotu MSS je 24 bajtov.

V odpovedi povolenia na požiadavku na pripojenie sú oba príznaky (SYN a ACK) nastavené na 1. Odpovedajúci systém uvádza počiatočné poradové číslo v zodpovedajúcom poli a veľkosť prijímacieho okna v poli okno. Maximálna veľkosť segmentu, ktorú chce príjemca použiť, sa zvyčajne nachádza v odpovedi pripojenia (v možnosti). Táto hodnota sa môže líšiť od hodnoty strany žiadajúcej o spojenie, t.j. možno použiť dve rôzne hodnoty.

Požiadavku na pripojenie možno odmietnuť zadaním príznaku resetovania (RST) s hodnotou 1 v odpovedi.

Špecifikácia TCP predpokladá, že pri nadväzovaní spojenia si vyberie každá strana počiatočné poradové číslo(na základe aktuálnej hodnoty 32-bitového interného časovača). Ako sa to robí?

Predstavte si, čo sa stane, keď systém zlyhá. Predpokladajme, že používateľ otvoril pripojenie tesne pred zlyhaním a odoslal malé množstvo údajov. Po obnovení si systém už nepamätá nič, čo bolo vykonané pred zlyhaním, vrátane už spustených pripojení a priradených čísel portov. Používateľ znovu nadviaže spojenie. Čísla portov sa nezhodujú s pôvodnými priradeniami a niektoré z nich už môžu byť používané inými pripojeniami vytvorenými niekoľko sekúnd pred zlyhaním.

Druhá strana na samom konci spojenia si preto nemusí byť vedomá toho, že jej partner prešiel haváriou a následne bol obnovený. To všetko povedie k vážnym poruchám, najmä keď trvá dlho, kým staré dáta prejdú sieťou a zmiešajú sa s dátami z novovytvoreného pripojenia. Výber časovača spustenia s aktualizáciou (nový štart) takéto problémy eliminuje. Staré údaje budú mať iné číslovanie ako rad poradových čísel nového pripojenia. Hackeri sa pri falšovaní zdrojovej IP adresy pre dôveryhodného hostiteľa pokúšajú získať prístup k počítačom zadaním predvídateľného počiatočného poradového čísla v správe. Kryptografická hašovacia funkcia založená na interných kľúčoch je najlepší spôsob, ako vybrať bezpečné počiatočné čísla.

Pri príprave TCP hlavičky na prenos je v poli uvedené poradové číslo prvého oktetu prenášaných dát sériové číslo(Poradové číslo).

Do poľa sa zadá číslo nasledujúceho oktetu očakávaného od partnera pripojenia potvrdenie(Číslo potvrdenia), keď je bit ACK nastavený na 1. Pole okno(Window) je pre aktuálnu veľkosť prijímacieho okna. Toto pole obsahuje počet bajtov z čísla potvrdenia, ktoré možno akceptovať. Upozorňujeme, že táto hodnota umožňuje presné riadenie toku údajov. Touto hodnotou partner označuje skutočný stav prijímacieho okna počas relácie výmeny.

Ak aplikácia indikuje operáciu TCP push, potom je príznak PUSH nastavený na 1. Prijímajúci TCP MUSÍ na tento príznak reagovať rýchlym doručením údajov do aplikácie hneď, ako si ich odosielateľ želá preposlať.

Príznak URGENT, ak je nastavený na 1, znamená urgentný prenos údajov a zodpovedajúci ukazovateľ musí ukazovať na posledný oktet urgentných údajov. Typické použitie pre urgentné dáta je odosielanie signálov z terminálu na zrušenie alebo prerušenie.

Naliehavé údaje sa často nazývajú mimopásmové informácie(von zo skupiny). Tento výraz je však nepresný. Naliehavé údaje sa odosielajú na bežnom toku TCP, hoci jednotlivé implementácie môžu mať špeciálne mechanizmy, ktoré aplikácii oznámia, že prišli urgentné údaje, a aplikácia musí preskúmať obsah urgentných údajov skôr, ako prídu všetky bajty správy.

Príznak RESET je nastavený na 1, keď sa má spojenie prerušiť. Rovnaký príznak je nastavený v odpovedi, keď je prijatý segment, ktorý nie je spojený so žiadnym z aktuálnych TCP spojení.

Príznak FIN je nastavený na 1 pre správy o uzavretí spojenia.

Kontrolný súčet IP je len pre hlavičku IP, zatiaľ čo kontrolný súčet TCP sa vypočítava pre celý segment, ako aj pseudo hlavička vygenerovaná z hlavičky IP. Počas výpočtu kontrolného súčtu TCP je príslušné pole nastavené na 0. Na obr. Obrázok 10-15 zobrazuje pseudohlavičku veľmi podobnú tej, ktorá sa používa v kontrolnom súčte UDP.

Ryža. 10.15. Pole pseudo hlavičky zahrnuté v kontrolnom súčte TCP

Dĺžka TCP sa vypočíta pripočítaním dĺžky hlavičky TCP k dĺžke údajov. Kontrolný súčet TCP je povinné, nie ako v UDP. Kontrolný súčet prichádzajúceho segmentu najprv vypočíta prijímač a potom ho porovná s obsahom poľa kontrolného súčtu v hlavičke TCP. Ak sa hodnoty nezhodujú, segment sa zahodí.

Ryža. 10.16, protokol analyzátora Sniffer podľa Network General, je sekvencia segmentov TCP. Prvé tri segmenty vytvárajú spojenie medzi klientom a serverom telnet. Posledný segment nesie 12 bajtov dát.

Ryža. 10.16. Zobrazenie hlavičky TCP pomocou analyzátora Sniffer

Analyzátor Sniffer prevádza väčšinu hodnôt na desatinné miesta. Hodnoty príznakov sa však vydávajú ako hexadecimálne. Príznak s hodnotou 12 je 010010. Kontrolný súčet sa tiež zobrazuje v hexadecimálnej sústave.

Rýchly odosielateľ a pomalý prijímač môžu tvoriť 0-bajtové prijímacie okno. Tento výsledok sa nazýva zatváranie okien(zavrieť okno). Keď je voľné miesto na aktualizáciu veľkosti prijímacieho okna, použije sa ACK. Ak sa však takáto správa stratí, obe strany budú musieť čakať neurčito.

Aby sa predišlo tejto situácii, odosielateľ nastaví uložiť časovač(persistent timer) pri zatváraní prémiového okna. Hodnota časovača je časový limit opätovného prenosu. Na konci časovača sa partnerovi odošle segment snímacie okno(okenná sonda; niektoré implementácie obsahujú dáta). Sonda spôsobí, že partner pošle späť ACK, ktoré hlási aktuálny stav okna.

Ak má okno stále veľkosť nula, hodnota trvalého časovača sa zdvojnásobí. Tento proces sa opakuje, kým hodnota časovača nedosiahne maximálne 60 s. TCP bude pokračovať v odosielaní testovacích správ každých 60 sekúnd, kým sa neotvorí okno, kým používateľ neukončí proces alebo kým nevyprší časový limit aplikácie.

Pripojenie partnera môže zlyhať alebo byť úplne prerušené v dôsledku zlyhania brány alebo prepojenia. Aby sa zabránilo opakovanému prenosu údajov v TCP, existuje niekoľko mechanizmov.

Po dosiahnutí prvého prahu opätovného prenosu (relé) TCP povie IP, aby skontroloval chybný smerovač a zároveň informuje aplikáciu o probléme. TCP pokračuje v odosielaní údajov, kým sa nedosiahne druhá limitná hodnota a až potom sa spojenie uzavrie.

Samozrejme, skôr ako sa to stane, môže sa objaviť ICMP správa oznamujúca, že cieľ je z nejakého dôvodu nedostupný. V niektorých implementáciách, dokonca aj potom, sa bude TCP naďalej pokúšať o prístup k cieľu, kým nevyprší časový limit (v tomto bode môže byť problém vyriešený). Ďalej je aplikácia informovaná, že cieľ je nedostupný.

Aplikácia môže nastaviť svoj vlastný časový limit doručovania údajov a vykonávať svoje vlastné operácie, keď tento interval uplynie. Zvyčajne sa spojenie ukončí.

Keď má nedokončené pripojenie údaje na odoslanie dlhší čas, dostane sa do stavu nečinnosti. Počas obdobia nečinnosti môže dôjsť k zlyhaniu siete alebo zlyhaniu fyzického spojenia. Hneď ako bude sieť opäť funkčná, partneri budú pokračovať vo výmene dát bez prerušenia komunikačnej relácie. Táto stratégia spĺňala požiadavky ministerstva obrany.

Akékoľvek pripojenie - aktívne alebo neaktívne - však zaberá veľa pamäte počítača. Niektorí správcovia potrebujú vrátiť nevyužité prostriedky do systémov. Preto je veľa implementácií TCP schopných posielať správu o udržiavanie spojenia(keep-alive), ktorý testuje neaktívne pripojenia. Takéto správy sa pravidelne odosielajú partnerovi, aby skontrolovali jeho existenciu v sieti. Odpoveďou musia byť správy ACK. Používanie udržiavacích správ je voliteľné. Ak má systém túto schopnosť, aplikácia ju môže prepísať vlastnými prostriedkami. Odhadované obdobie predvolenáčasový limit údržby pripojenia je celé dve hodiny!

Pripomeňme, že aplikácia si vie nastaviť vlastný časovač, podľa ktorého na svojej úrovni rozhodne o ukončení spojenia.

Aký efektívny je TCP? Výkon zdrojov je ovplyvnený mnohými faktormi, z ktorých hlavnými sú pamäť a šírka pásma (pozri obrázok 10.17).

Ryža. 10.17. Faktory výkonu TCP

Šírka pásma a oneskorenia v používanej fyzickej sieti výrazne obmedzujú priepustnosť. Nízka kvalita prenosu dát má za následok veľký objem vyradených datagramov, čo spôsobuje opakované prenosy a následne znižuje efektivitu šírky pásma.

Prijímacia strana musí poskytnúť dostatočný priestor vo vyrovnávacej pamäti, aby mohol odosielateľ prenášať dáta bez prestávok v prevádzke. To je dôležité najmä pre siete s vysokou latenciou, kde je dlhý čas medzi odoslaním dát a prijatím ACK (a tiež pri vyjednávaní veľkosti okna). Aby sa zachoval stabilný tok údajov zo zdroja, prijímacia strana musí mať okno nie menšie ako súčin šírky pásma a oneskorenia.

Napríklad, ak zdroj môže odosielať dáta rýchlosťou 10 000 bajtov/s a vrátenie ACK trvá 2 sekundy, potom prijímacie okno na druhej strane musí mať veľkosť aspoň 20 000 bajtov, inak sa tok údajov nebyť nepretržitý. Prijímacia vyrovnávacia pamäť s veľkosťou 10 000 bajtov zníži priepustnosť na polovicu.

Ďalším dôležitým faktorom pre výkon je schopnosť hostiteľa reagovať na udalosti s vysokou prioritou a rýchlo vykonať prepínanie kontextu, t.j. dokončite jednu operáciu a prepnite na inú. Hostiteľ môže interaktívne podporovať viacerých lokálnych používateľov, dávkové procesy na pozadí a desiatky simultánnych komunikačných pripojení. Kontextové prepínanie vám umožňuje obsluhovať všetky tieto operácie a skrývať zaťaženie systému. Implementácie, ktoré integrujú TCP/IP s jadrom operačného systému, môžu výrazne znížiť záťaž pri používaní prepínania kontextu.

Na operácie spracovania hlavičiek TCP sú potrebné prostriedky CPU počítača. Ak procesor nedokáže rýchlo vypočítať kontrolné súčty, vedie to k zníženiu rýchlosti prenosu dát cez sieť.

Okrem toho by sa vývojári mali snažiť zjednodušiť konfiguráciu nastavení TCP, aby ich správca siete mohol prispôsobiť ich miestnym požiadavkám. Napríklad možnosť upraviť veľkosť vyrovnávacej pamäte pre šírku pásma a latenciu siete výrazne zlepší výkon. Bohužiaľ, mnohé implementácie nevenujú tejto problematike dostatočnú pozornosť a komunikačné parametre natvrdo kódujú.

Predpokladajme, že sieťové prostredie je dokonalé: existuje dostatok zdrojov a prepínanie kontextu je rýchlejšie, ako kovboji vyťahujú zbrane. Dosiahne sa vynikajúci výkon?

Nie vždy. Dôležitá je aj kvalita vývoja softvéru TCP. V priebehu rokov bolo diagnostikovaných a vyriešených veľa problémov s výkonom v rôznych implementáciách TCP. Dá sa uvažovať, že najlepším softvérom bude ten, ktorý vyhovuje RFC 1122, ktorý definuje požiadavky na komunikačnú vrstvu internetových hostiteľov.

Rovnako dôležitá výnimka a aplikácia Jacobsonových, Kernových a Partridgeových algoritmov (tieto zaujímavé algoritmy budú diskutované nižšie).

Vývojári softvéru môžu získať značné výhody vytvorením programov, ktoré eliminujú zbytočné malé prenosy dát a majú vstavané časovače na uvoľnenie sieťových zdrojov, ktoré sa momentálne nepoužívajú.

Keď prejdeme k úvodu do pomerne zložitej časti TCP, pozrieme sa na mechanizmy na zlepšenie výkonu a riešenie zníženia priepustnosti. Táto časť pojednáva o nasledujúcich problémoch:

■ pomalý štart(pomalý štart) zabraňuje použitiu veľkého množstva sieťovej prevádzky na novú reláciu, čo môže viesť k réžii.

■ Uzdravenie z Syndróm bezradného okna(syndróm hlúpeho okna) zabraňuje zle navrhnutým aplikáciám zahlcovať sieť správami.

■ Oneskorené ACK(oneskorené ACK) znižuje preťaženie znížením počtu nezávislých správ o potvrdení prenosu dát.

■ Vypočítaný časový limit opätovného prenosu(computing retransmission timeout) sa spolieha na vyjednávanie relácie v reálnom čase, čím sa redukujú nepotrebné opakované prenosy, pričom nespôsobujú veľké oneskorenia pre skutočne potrebné výmeny dát.

■ Preposielanie TCP sa zastaví, keď preťaženia v sieti umožňuje smerovačom vrátiť sa do pôvodného režimu a zdieľať sieťové zdroje pre všetky relácie.

■ Doprava duplicitné ACK(duplicitné ACK) po prijatí segmentu mimo sekvencie, umožňuje rovesníkom opakovaný prenos pred uplynutím časového limitu.

Ak sú všetky domáce elektrické spotrebiče zapnuté súčasne doma, dôjde k preťaženiu elektrickej siete. V počítačových sieťach pomalý štart zabraňuje prepáleniu sieťových poistiek.

Nové pripojenie, ktoré okamžite začne odosielať veľké množstvo dát v už aj tak vyťaženej sieti, môže viesť k problémom. Myšlienkou pomalého štartu je zabezpečiť úspešné spustenie nového pripojenia s pomalým zvyšovaním rýchlosti prenosu dát v súlade so skutočným zaťažením siete. Odosielateľ je obmedzený veľkosťou nakladacieho okna, nie väčším prijímacím oknom.

načítavacie okno(okno preťaženia) začína veľkosťou 1 segmentu. Pre každý segment s úspešne prijatým ACK sa veľkosť okna načítania zväčší o 1 segment, pokiaľ zostane menšie ako okno prijatia. Ak sieť nie je preťažená, okno zaťaženia postupne dosiahne veľkosť prijímacieho okna. V normálnom stave preposielania budú mať tieto okná rovnakú veľkosť.

Všimnite si, že pomalý štart nie je taký pomalý. Po prvom ACK je veľkosť okna načítania 2 segmenty a po úspešnom ACK pre dva segmenty sa veľkosť môže zvýšiť na 8 segmentov. Inými slovami, veľkosť okna sa zväčšuje exponenciálne.

Predpokladajme, že namiesto prijatia ACK nastala situácia s časovým limitom. Správanie okna načítania v tomto prípade je popísané nižšie.

V prvých implementáciách TCP/IP sa vývojári stretli s týmto fenoménom Syndróm bezradného okna(Silly Window Syndrome - SWS), ktorý sa prejavoval pomerne často. Aby ste pochopili, čo sa deje, zvážte nasledujúci scenár, ktorý vedie k nežiaducim následkom, ale je celkom možné:

1. Odosielajúca aplikácia odosiela dáta rýchlo.

2. Prijímajúca aplikácia číta 1 bajt dát zo vstupnej vyrovnávacej pamäte (t.j. pomaly).

3. Vstupná vyrovnávacia pamäť sa po odčítaní rýchlo naplní.

4. Prijímajúca aplikácia načíta 1 bajt a TCP pošle ACK v zmysle „Mám voľné miesto na 1 bajt dát“.

5. Vysielacia aplikácia odošle TCP paket s veľkosťou 1 bajt cez sieť.

6. Prijímajúci TCP odošle ACK s významom "Ďakujem. Dostal som paket a už nemám voľné miesto."

7. Prijímajúca aplikácia opäť načíta 1 bajt a odošle ACK a celý proces sa opakuje.

Pomaly prijímajúca aplikácia dlho čaká na príchod dát a prijaté informácie neustále posúva k ľavému okraju okna, pričom vykonáva úplne zbytočnú operáciu, ktorá generuje ďalšiu prevádzku v sieti.

Reálne situácie, samozrejme, nie sú až také extrémne. Rýchly odosielateľ a pomalý prijímač si budú vymieňať malé (v pomere k maximálnej veľkosti segmentu) kusy dát a prepínať takmer plné prijímacie okno. Na obr. 10.18 ukazuje podmienky pre vznik syndrómu "hlúpeho okna".

Ryža. 10.18. Prijímajte vyrovnávaciu pamäť okna s veľmi malým voľným priestorom

Riešenie tohto problému je jednoduché. Akonáhle sa prijímacie okno skráti o dĺžku menšiu ako je daná cieľová veľkosť, TCP začne klamať odosielateľa. V tejto situácii TCP nesmie nasmerovať odosielateľa dodatočné priestor v okne, keď prijímajúca aplikácia načítava údaje z vyrovnávacej pamäte po malých kúskoch. Namiesto toho by mali byť uvoľnené zdroje utajené pred odosielateľom, kým ich nebude dostatok. Odporúča sa veľkosť jedného segmentu, pokiaľ celá vstupná vyrovnávacia pamäť neukladá jeden segment (v druhom prípade sa použije veľkosť rovnajúca sa polovici vyrovnávacej pamäte). Cieľovú veľkosť, ktorú by mal TCP hlásiť, možno vyjadriť ako:

minimum (1/2 vstupnej vyrovnávacej pamäte, maximálna veľkosť segmentu)

TCP začne podvádzať, keď je veľkosť okna menšia ako táto veľkosť, a povie pravdu, keď veľkosť okna nie je menšia ako hodnota daná vzorcom. Upozorňujeme, že odosielateľovi to neublíži, pretože prijímajúca aplikácia by stále nebola schopná spracovať veľkú časť údajov, ktoré očakáva.

Navrhované riešenie sa dá ľahko skontrolovať vo vyššie diskutovanom prípade s výstupom ACK pre každý z prijatých bajtov. Rovnaký spôsob je vhodný aj pre prípad, keď vstupná vyrovnávacia pamäť dokáže uložiť viacero segmentov (ako sa to v praxi často stáva). Rýchly odosielateľ naplní vstupnú vyrovnávaciu pamäť, ale prijímač bude indikovať, že nemá voľné miesto na ukladanie informácií a neotvorí tento zdroj, kým jeho veľkosť nedosiahne celý segment.

Odosielateľ sa musí bez ohľadu na príjemcu vyhnúť odosielaniu veľmi krátkych segmentov hromadením údajov pred odoslaním. Algoritmus Nagle implementuje veľmi jednoduchý nápad na zníženie počtu krátkych datagramov odosielaných cez sieť.

Algoritmus odporúča odložiť prenos dát (a vyskakovanie) počas čakania na ACK z predtým prenesených dát. Nahromadené dáta sa odosielajú po prijatí ACK k predtým odoslanej informácii alebo po prijatí na odoslanie dát vo veľkosti celého segmentu alebo po uplynutí časového limitu. Tento algoritmus by sa nemal používať pre aplikácie v reálnom čase, ktoré potrebujú odosielať údaje čo najrýchlejšie.

Ďalším mechanizmom na zlepšenie výkonu je spôsob oneskorenia ACK. Zníženie počtu ACK znižuje množstvo šírky pásma, ktoré možno použiť na odosielanie inej prevádzky. Ak partner TCP mierne oneskorí odoslanie ACK, potom:

■ Viaceré segmenty možno potvrdiť jedným ACK.

■ Prijímajúca aplikácia je schopná prijať určité množstvo dát v rámci časového limitu, tj. výstupná hlavička môže byť zahrnutá v ACK a nie je potrebné generovať žiadnu samostatnú správu.

Aby sa predišlo oneskoreniam pri preposielaní toku segmentov plnej dĺžky (napríklad pri výmene súborov), ACK by sa malo posielať aspoň pre každý druhý segment plnej dĺžky.

Mnoho implementácií používa časový limit 200 ms. Ale oneskorené ACK neznižuje výmenný kurz. Keď príde krátky segment, vo vstupnej vyrovnávacej pamäti je stále dostatok voľného miesta na príjem nových dát a odosielateľ môže pokračovať v prenose (navyše, opakovaný prenos je zvyčajne oveľa pomalší). Ak príde celý segment, musíte naň v tú istú sekundu odpovedať správou ACK.

Po odoslaní segmentu TCP nastaví časovač a monitoruje príchod ACK. Ak nie je prijaté ACK počas časového limitu, TCP znova odošle segment (relé). Aký by však mal byť časový limit?

Ak je príliš krátky, odosielateľ zahltí sieť nepotrebnými segmentmi, ktoré duplikujú už odoslané informácie. Príliš dlhý časový limit zabráni rýchlej oprave segmentov, ktoré sú počas prenosu skutočne poškodené, čo zníži priepustnosť.

Ako zvoliť správny interval pre časový limit? Hodnota, ktorá je vhodná pre vysokorýchlostnú sieť LAN, nebude vhodná pre vzdialené pripojenie s mnohými prístupmi. Zásada „jedna hodnota pre všetky podmienky“ je teda zjavne nevhodná. Navyše, dokonca aj pre existujúce špecifické pripojenie sa môžu zmeniť podmienky siete a oneskorenia sa môžu zvýšiť alebo znížiť.

Algoritmy Jacobsona, Kerna a Partridgea (popísané v článkoch , Van Jacobson a Zlepšenie odhadov spiatočnej doby v spoľahlivých dopravných protokoloch, Karn a Partridge) umožňujú TCP prispôsobiť sa meniacim sa sieťovým podmienkam. Tieto algoritmy sa odporúčajú na použitie v nových implementáciách. Nižšie ich stručne preskúmame.

Zdravý rozum hovorí, že najlepším základom pre odhad správneho časového limitu pre konkrétne pripojenie môže byť sledovanie čas cyklu(spiatočný čas) ako interval medzi odoslaním údajov a prijatím potvrdenia o ich prijatí.

Dobré riešenia pre nasledujúce veličiny možno získať na základe základných štatistík (pozri obrázok 10.19), ktoré pomôžu vypočítať časový limit. Nespoliehajte sa však na priemery, pretože viac ako polovica skóre bude vyššia ako štatistický priemer. Zohľadnením dvojice rozptylov možno získať lepšie odhady, ktoré zohľadňujú normálne rozdelenie a znižujú príliš dlhú latenciu opätovného prenosu.

Ryža. 10.19. Rozdelenie časov cyklov

Na získanie formálnych matematických odhadov odchýlok nie je potrebné veľké množstvo výpočtov. Môžete použiť pomerne hrubé odhady založené na absolútnej hodnote rozdielu medzi poslednou hodnotou a priemerným odhadom:

Posledná odchýlka = | Posledný cyklus – priemer |

Ak chcete vypočítať správnu hodnotu časového limitu, ďalším faktorom, ktorý treba zvážiť, je zmena doby cyklu v dôsledku aktuálnych podmienok siete. Čo sa stalo online na poslednú chvíľu, je dôležitejšie ako to, čo sa stalo pred hodinou.

Predpokladajme, že počítate priemer cyklu pre veľmi dlhú reláciu. Predpokladajme, že na začiatku bola sieť mierne zaťažená a určili sme 1000 malých hodnôt, ale potom došlo k nárastu prevádzky s výrazným zvýšením času oneskorenia.

Napríklad, ak 1 000 hodnôt poskytlo priemernú hodnotu 170 jednotiek, ale potom sa nameralo 50 hodnôt s priemerom 282, potom by aktuálny priemer bol:

170 x 1 000/1 050 + 282 x 50/1 050 = 175

Rozumnejšie by bolo vyhladený čas cyklu(Smoothed Round-Trip Time - SRTT), ktorý zohľadňuje prioritu neskorších hodnôt:

Nový SRTT = (1 – α)×(starý SRTT) + α×Hodnota posledného cyklu

Hodnota α je medzi 0 a 1. Zvýšiť a má za následok väčší vplyv aktuálneho času cyklu na vyhladený priemer. Pretože počítače dokážu rýchlo deliť mocninou 2 posunutím binárnych čísel doprava, hodnota α je vždy (1/2) n (zvyčajne 1/8), takže:

Nové SRTT = 7/8 × staré SRTT + 1/8 × čas posledného cyklu

Tabuľka 10.2 ukazuje, ako sa vzorec pre SRTT prispôsobuje aktuálnej hodnote SRTT 230 jednotiek, keď zmena podmienok siete vedie k postupnému predlžovaniu doby cyklu (za predpokladu, že nenastane časový limit). Hodnoty v stĺpci 3 sa používajú ako hodnoty v stĺpci 1 pre ďalší riadok tabuľky (t. j. stará SRTT).

Tabuľka 10.2 Výpočet doby vyhladeného cyklu

Teraz vyvstáva otázka výberu hodnoty pre časový limit opakovaného prenosu. Analýza časov cyklov ukazuje výraznú odchýlku týchto hodnôt od aktuálneho priemeru. Má zmysel stanoviť hranicu veľkosti odchýlok (odchýlok). Dobré hodnoty pre časový limit opätovného prenosu (nazývaný Retransmission TimeOut - RTO v štandardoch RFC) sú dané nasledujúcim vzorcom s obmedzeným vyhladeným rozptylom (SDEV):

T = Časový limit opätovného prenosu = SRTT + 2×SDEV

T = SRTT + 4xSDEV

Na výpočet SDEV najskôr určte absolútnu hodnotu aktuálnej odchýlky:

DEV = | Čas posledného cyklu – starý SRTT |

Potom sa použije vyhladzovací vzorec na zohľadnenie poslednej hodnoty:

Nové SDEV = 3/4×staré SDEV + 1/4×DEV

Zostáva jedna otázka - aké počiatočné hodnoty vziať? Odporúčané:

Počiatočný časový limit = 3 s

Počiatočné SRTT = 0

Počiatočná SDEV = 1,5 s

Van Jacobson definoval rýchly algoritmus, ktorý veľmi efektívne vypočítava časový limit opätovného prenosu.

Ako dobre bude fungovať časový limit vypočítaný vyššie? Pri implementácii získanej hodnoty boli pozorované výrazné zlepšenia výkonu. Príkladom môže byť štatistika príkazov netstat prijaté v systéme tiger- internetový server, ku ktorému má prístup mnoho hostiteľov z celého sveta.

1510769 prijatých paketov (314955304 bajtov) za sebou

systém tiger bolo opätovne odoslaných menej ako 2,5 % dátových segmentov TCP. Pre jeden a pol milióna prichádzajúcich dátových segmentov (zvyšok sú čisté ACK) bolo duplikovaných iba 0,6 %. V tomto prípade je potrebné vziať do úvahy, že úroveň strát vo vstupných údajoch približne zodpovedá úrovni pre výstupné segmenty. Neužitočná retransmisná prevádzka je teda asi 0,6 % z celkovej prevádzky.

Vyššie uvedené vzorce používajú hodnotu času cyklu ako interval medzi odoslaním segmentu a prijatím potvrdenia o jeho prijatí. Predpokladajme však, že počas časového limitu neprišlo žiadne potvrdenie a údaje sa musia odoslať znova.

Kernov algoritmus predpokladá, že v tomto prípade by sa čas cyklu nemal meniť. Aktuálna vyhladená hodnota času cyklu a vyhladená odchýlka ponechajú si svoje hodnoty, kým nedostane potvrdenie o odoslaní nejakého segmentu bez jeho opätovného odoslania. Od tohto bodu sa výpočty obnovia na základe uložených hodnôt a nových meraní.

Čo sa však stane pred prijatím potvrdenia? Po opätovnom odoslaní sa správanie TCP drasticky zmení, najmä kvôli strate údajov v dôsledku preťaženia siete. Preto odpoveď na opätovné odoslanie údajov bude:

■ Znížená rýchlosť opakovaného prenosu

■ Bojujte proti preťaženiu siete znížením celkovej prevádzky

Po opakovanom prenose sa časový limit zdvojnásobí. Čo sa však stane, keď časovač znova pretečie? Údaje sa znova odošlú a doba opakovaného prenosu sa opäť zdvojnásobí. Tento proces sa nazýva exponenciálne brzdenie(exponenciálny ústup).

Ak chyba siete pretrváva, časový limit sa zdvojnásobí, kým nedosiahne prednastavenú maximálnu hodnotu (zvyčajne 1 minútu). Po uplynutí časového limitu je možné odoslať iba jeden segment. Časový limit nastáva aj pri prekročení prednastavenej hodnoty počtu prenosov dát bez prijatia ACK.

Zníženie množstva odosielaných údajov je o niečo komplikovanejšie ako mechanizmy diskutované vyššie. Začína to fungovať, ako už spomínaný pomalý štart. Ale keďže je stanovený limit pre úroveň návštevnosti, čo môže spočiatku viesť k problémom, výmenný kurz sa v skutočnosti spomalí v dôsledku zvýšenia veľkosti okna zaťaženia pre jeden segment. Pre skutočné zníženie rýchlosti odosielania musíte nastaviť hodnoty hraníc. Najprv sa vypočíta prah nebezpečenstva:

Hranica – minimálne 1/2 (aktuálne okno načítania, obdobie prijímania partnera)

Ak je výsledná hodnota viac ako dva segmenty, použije sa ako hranica. V opačnom prípade sa veľkosť okraja nastaví na dva segmenty. Algoritmus úplného obnovenia vyžaduje:

■ Nastavte veľkosť okna načítania na jeden segment.

■ Pre každé prijaté ACK zväčšite veľkosť okna načítania o jeden segment, kým sa nedosiahne hranica (podobne ako mechanizmus pomalého spustenia).

■ Potom s každým prijatým ACK pridajte do okna zaťaženia menšiu hodnotu, ktorá sa vyberie na základe rýchlosti nárastu v jednom segmente počas doby cyklu (nárast sa vypočíta ako MSS/N, kde N je veľkosť okno zaťaženia v segmentoch).

Scenár pre ideálny prípad môže byť zjednodušeným znázornením toho, ako funguje mechanizmus obnovy. Predpokladajme, že prijímacie okno partnera (a aktuálne okno zaťaženia) bolo 8 segmentov pred zistením časového limitu a hranica je definovaná ako 4 segmenty. Ak prijímajúca aplikácia okamžite číta dáta z vyrovnávacej pamäte, veľkosť prijímacieho okna zostane na 8 segmentoch.

■ Odošle sa 1 segment (okno načítania = 1 segment).

■ ACK prijaté - 2 segmenty sú odoslané.

■ ACK prijaté pre 2 segmenty - 4 segmenty sú odoslané, (hranica dosiahnutá).

■ Prijaté ACK pre 4 segmenty. Odoslaných je 5 segmentov.

■ Prijaté ACK pre 5 segmentov. Odoslaných je 6 segmentov.

■ ACK prijaté pre 6 segmentov. Odoslaných je 7 segmentov.

■ ACK prijaté pre 7 segmentov. Odošle sa 8 segmentov (okno načítania má opäť rovnakú veľkosť ako prijímacie okno).

Pretože všetky odoslané údaje musia byť potvrdené počas časového limitu opätovného prenosu, proces pokračuje, kým okno načítania nedosiahne veľkosť prijímacieho okna. Vyskytujúce sa udalosti sú znázornené na obr. 10.20. Veľkosť okna sa zväčšuje exponenciálne, počas obdobia pomalého štartu sa zdvojnásobuje a po dosiahnutí hranice je nárast lineárny.

Ryža. 10.20. Limit forwardovej rýchlosti počas preťaženia

V niektorých implementáciách sa používa voliteľná funkcia – tzv rýchle opätovné odoslanie(rýchly retransmit) - s cieľom urýchliť retransmisiu dát za určitých podmienok. Jeho hlavná myšlienka súvisí s tým, že príjemca posiela ďalšie ACK indikujúce medzeru v prijatých dátach.

Po prijatí segmentu mimo poradia prijímač odošle späť ACK smerujúce na prvý bajt. stratenýúdaje (pozri obrázok 10.21).

Ryža. 10.21. Duplicitné ACK

Odosielateľ nevykonáva okamžitý opakovaný prenos údajov, pretože IP môže normálne doručiť údaje príjemcovi bez sekvencie odosielania. Ale keď je prijatých niekoľko ďalších ACK pre duplikáciu údajov (napríklad tri), potom sa chýbajúci segment odošle bez čakania na dokončenie časového limitu.

Všimnite si, že každé duplicitné ACK označuje príjem dátového segmentu. Niekoľko duplicitných ACK dáva jasne najavo, že sieť je schopná dodávať dostatok dát, a preto nie je príliš zaťažená. Ako súčasť celkového algoritmu sa vykoná malé zníženie veľkosti okna zaťaženia so skutočným zvýšením sieťovej prevádzky. V tomto prípade proces drastickej zmeny veľkosti pri obnove diela neplatí.

Podľa normy Požiadavky na hostiteľa(požiadavky na hostiteľa) TCP musí pri zhášaní zdroja vykonávať rovnaký pomalý štart, ako je popísané vyššie. Hlásenie však nie je cielené ani efektívne, pretože spojenie, ktoré prijalo správu, nemusí generovať príliš veľkú návštevnosť. Aktuálna špecifikácia Požiadavky na smerovač(požiadavky smerovača) určuje, že smerovače nemal by posielať správy o potlačení zdroja.

Nakoniec sa pozrime na štatistické správy príkazu netstat, vidieť mnohé z vyššie opísaných mechanizmov v činnosti.

879137 dátových paketov (226966295 bajtov)

Opätovne sa odoslalo 21 815 dátových paketov (8 100 927 bajtov).

132957 paketov iba na potvrdenie (104216 oneskorených)

oneskorené ACK.

veľkosť nula.

762469 acks (pre 226904227 bajtov)

mimo poradia.

1510769 paketov (314955304 bajtov)

9006 úplne duplicitných paketov (867042 bajtov)

doručovanie údajov.

74 paketov s nejakým dup. dáta (12 193 bajtov duplikovaných)

niektoré údaje boli prebalené, aby pri opätovnom odoslaní obsahovali ďalšie bajty.

13452 neobjednávkových paketov (2515087 bajtov)

530 paketov (8551 bajtov) dát po okne

zahrnuté v znejúcich správach.

Po uzavretí bolo prijatých 402 paketov

odosielanie.

108 zahodených pre zlé kontrolné súčty

0 sa zahodí pre zlé polia odsadenia hlavičky

7 vyradené, pretože paket je príliš krátky

Bolo vytvorených 14677 spojení (vrátane akceptovaných)

18929 uzavretých spojení (vrátane 643 prepojení)

Zaniklo 4100 embryonálnych spojení

572187 aktualizovaných segmentov rtt (z 587397 pokusov)

čas cyklu, pretože ACK neprišlo pred uplynutím časového limitu,

26 spojení prerušilo časový limit opätovného ukončenia

znova odoslať, čo znamená stratené spojenie.

nulové okno.

nečinné pripojenie.

Keepalive prerušilo 472 spojení

Aktuálny štandard TCP vyžaduje, aby implementácie prísne dodržiavali postup pomalého spustenia pri inicializácii pripojenia a používali algoritmy Kern a Jacobson na odhad časového limitu opätovného odoslania a kontroly zaťaženia. Testy ukázali, že tieto mechanizmy vedú k výraznému zlepšeniu výkonu.

Čo sa stane, keď nainštalujete systém, ktorý prísne nedodržiava tieto normy? Neposkytne primeraný výkon pre svojich vlastných používateľov a bude zlým susedom pre ostatné systémy v sieti, pretože bráni obnoveniu normálnej prevádzky po dočasnom preťažení a generuje nadmernú prevádzku, ktorá vedie k vypadávaniu datagramov.

TCP preukázal svoju flexibilitu prevádzkou v sieťach s prenosovou rýchlosťou stoviek alebo miliónov bitov za sekundu. Tento protokol dosiahol dobré výsledky v moderných lokálnych sieťach s topológiami Ethernet, Token-Ring a Fibre Distributed Data Interface (FDDI), ako aj pre nízkorýchlostné spojenia alebo spojenia na veľké vzdialenosti (ako satelitné spojenia).

TCP je navrhnutý tak, aby reagoval na extrémne podmienky, ako je preťaženie siete. Aktuálna verzia protokolu má však funkcie, ktoré obmedzujú výkon v nových technológiách, ktoré ponúkajú stovky a tisíce megabajtov šírky pásma. Aby ste pochopili vzniknuté problémy, pouvažujte o jednoduchom (hoci nereálnom) príklade.

Predpokladajme, že keď presúvate súbor medzi dvoma systémami, chcete si vymieňať súvislý tok čo najefektívnejšie. Predpokladajme, že:

■ Maximálna veľkosť cieľového segmentu je 1 KB.

■ Prijímacie okno - 4 KB.

■ Šírka pásma umožňuje odoslať dva segmenty za 1 s.

■ Prijímajúca aplikácia spotrebúva dáta tak, ako prichádzajú.

■ Správy ACK prichádzajú po 2 sekundách.

Odosielateľ je schopný odosielať dáta nepretržite. Koniec koncov, keď je objem pridelený pre okno plný, príde ACK, čo umožní odoslanie ďalšieho segmentu:

Po 2 s:

PRIJAŤ POTVRDENIE SEGMENTU 1, MÔŽETE ODOSLAŤ SEGMENT 5.

PRIJAŤ POTVRDENIE SEGMENTU 2, MÔŽETE ODOSLAŤ SEGMENT 6.

PRIJAŤ POTVRDENIE SEGMENTU 3, MÔŽETE ODOSLAŤ SEGMENT 7.

PRIJAŤ POTVRDENIE SEGMENTU 4, MÔŽETE ODOSLAŤ SEGMENT 8.

Po ďalších 2 sekundách:

PRIJAŤ POTVRDENIE SEGMENTU 5, MÔŽETE ODOSLAŤ SEGMENT 9.

Ak by prijímacie okno bolo iba 2 kB, odosielateľ by musel čakať jednu sekundu z každých dvoch pred odoslaním ďalších údajov. V skutočnosti, aby sa zachoval nepretržitý tok údajov, prijímacie okno musí byť aspoň:

Okno = šírka pásma × čas cyklu

Aj keď je príklad trochu prehnaný (aby sa poskytli jednoduchšie čísla), malé okno môže viesť k problémom so satelitnými pripojeniami s vysokou latenciou.

Teraz sa pozrime, čo sa stane s vysokorýchlostným pripojením. Napríklad, ak sa šírka pásma a prenosová rýchlosť merajú pri 10 Mbps, ale doba cyklu je 100 ms (1/10 sekundy), potom pre nepretržitý tok musí prijímacie okno uložiť aspoň 1 000 000 bitov, t.j. 125 000 bajtov. Ale najväčšie číslo, ktoré možno zapísať do poľa hlavičky pre prijímacie okno TCP, je 65 536.

Ďalší problém vzniká pri vysokých prenosových rýchlostiach, pretože poradové čísla sa míňajú veľmi rýchlo. Ak pripojenie dokáže odosielať dáta rýchlosťou 4 GB / s, poradové čísla by sa mali aktualizovať každú sekundu. Nebude možné rozlíšiť medzi starými duplicitnými datagramami, ktoré boli pri cestovaní po internete oneskorené o viac ako sekundu, a čerstvými novými údajmi.

Aktívne sa vykonáva nový výskum na zlepšenie TCP/IP a odstránenie vyššie uvedených prekážok.

Táto kapitola sa zaoberá mnohými funkciami TCP. Hlavné sú uvedené nižšie:

■ Priradenie portov k pripojeniam

■ Inicializácia pripojení prostredníctvom potvrdenia v troch krokoch

■ Vykonanie pomalého štartu, aby sa zabránilo preťaženiu siete

■ Segmentácia údajov počas prenosu

■ Číslovanie údajov

■ Spracovanie prichádzajúcich duplicitných segmentov

■ Výpočet kontrolného súčtu

■ Regulácia toku dát cez prijímacie a odosielacie okno

■ Ukončenie spojenia predpísaným spôsobom

■ Ukončenie spojenia

■ Preposielanie urgentných údajov

■ Pozitívne potvrdenie opätovného odoslania

■ Výpočet časového limitu opakovaného prenosu

■ Zníženie spätnej prevádzky počas preťaženia siete

■ Signalizácia segmentov mimo poradia

■ Snímanie zatvárania prijímacieho okna

TCP spojenie prechádza niekoľkými fázami: spojenie sa vytvorí prostredníctvom výmeny správ, potom sa odošlú dáta a potom sa spojenie uzavrie pomocou výmeny špeciálnych správ. Každý krok v prevádzke spojenia zodpovedá určitému stave toto spojenie. Softvér TCP na každom konci pripojenia neustále monitoruje aktuálny stav druhej strany pripojenia.

Nižšie stručne zvážime typickú zmenu stavu servera a klienta umiestnených na rôznych koncoch pripojenia. Naším cieľom nie je poskytnúť vyčerpávajúci popis všetkých možných stavov pri prenose údajov. Je uvedený v RFC 793 a dokumente Požiadavky na hostiteľa.

Počas vytvárania spojení prechádzajú server a klient podobnými postupnosťami stavov. Stavy servera sú uvedené v tabuľke 10.3 a stavy klienta sú uvedené v tabuľke 10.4.

Tabuľka 10.3 Sekvencia stavu servera

Tabuľka 10.4 Sekvencia stavu klienta

Ak by sa rovesníci pokúšali nadviazať spojenie medzi sebou v rovnakom čase (čo je extrémne zriedkavé), každý by prešiel stavmi CLOSED, SYN-SENT, SYN-RECEIVED a ESTABLISHED.

Koncové strany spojenia zostanú v stave ESTABLISHED, kým jedna zo strán nepokračuje zatváranie spojenie odoslaním segmentu FIN. Počas normálneho uzávierky strana, ktorá iniciuje uzávierku, prechádza stavmi uvedenými v tabuľke 10.5. Jej partner prechádza stavmi uvedenými v tabuľke 10.6.

Tabuľka 10.5 Poradie stavov strany, ktorá uzatvára spojenie

Tabuľka 10.6 Sekvencia stavu partnera zatvorenia pripojenia

Tím netstat -an umožňuje skontrolovať aktuálny stav pripojenia. Nasleduje zobrazenie spojení v stavoch počúvať, spustenie, založenie, zatvorenie a čakacia doba.

Všimnite si, že číslo portu pripojenia je uvedené na konci každej lokálnej a externej adresy. Môžete vidieť, že existuje prevádzka TCP pre vstupné aj výstupné fronty.

Pro Recv-Q Send-Q Miestna adresa Zahraničná adresa (štát)

Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD

Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 ZALOŽENÉ

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 ZALOŽENÉ

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 ZALOŽENÉ

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 ZALOŽENÉ

TCP 0 0 128.121.50.145.1022 128.121.50.141.1017 ZALOŽENÉ

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 ZALOŽENÉ

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 ZALOŽENÉ

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 ZALOŽENÉ

Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1

Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 ZALOŽENÉ

Protokol TCP bol od samého začiatku navrhnutý pre interoperabilitu sieťových zariadení od rôznych výrobcov. Špecifikácia TCP presne nešpecifikuje, ako by mali interné štruktúry implementácie fungovať. Tieto otázky sú ponechané na vývojárov, ktorí sú vyzvaní, aby našli najlepšie mechanizmy pre každú konkrétnu implementáciu.

Dokonca aj RFC 1122 (dokument Požiadavky na hostiteľa- požiadavky na hostiteľa) ponecháva dostatok priestoru na variácie. Každá z implementovaných funkcií je označená určitou úrovňou kompatibility:

■ MÁJ (povolené)

■ NESMIE SA

Bohužiaľ, niekedy existujú produkty, ktoré nespĺňajú požiadavky MUST. V dôsledku toho používatelia pociťujú nepohodlie zníženého výkonu.

Na niektoré osvedčené postupy implementácie sa normy nevzťahujú. Bezpečnosť možno zlepšiť napríklad obmedzením používania známych portov na privilegované procesy v systéme, ak je táto metóda podporovaná v lokálnom operačnom systéme. Na zlepšenie výkonu by implementácie mali vykonávať čo najmenej kopírovania a presúvania odoslaných alebo získaných údajov.

Štandardné aplikačné programové rozhranie neurčené(ako aj bezpečnostná politika), takže existuje voľné pole pôsobnosti na experimentovanie s rôznymi súbormi softvérových nástrojov. To však môže viesť k rôznym programovacím rozhraniam na každej platforme a zabrániť presunu aplikačného softvéru medzi platformami.

V skutočnosti vývojári zakladajú svoje sady nástrojov na rozhraní Socket API, ktoré si požičali od Berkeley. Význam programovacieho rozhrania vzrástol s príchodom WINSock (Windows Socket), čo viedlo k množeniu nových desktopových aplikácií, ktoré by mohli bežať na akomkoľvek rozhraní WINSock kompatibilnom so zásobníkom TCP/IP.

Pôvodný štandard TCP je definovaný v RFC 793. Aktualizácie, opravy a požiadavky na kompatibilitu sú zahrnuté v RFC 1122. Kern (Kash) a Partridge (Partridge) publikovali článok Zlepšenie spiatočných odhadov v spoľahlivých dopravných protokoloch V časopise Zborník ACM SIGCOMM 1987. Jacobsonov článok Predchádzanie a kontrola preťaženia objavil sa v Zborník z workshopu ACM SIGCOMM 1988. Jacobson tiež zverejnil niekoľko RFC revidujúcich algoritmov na zlepšenie výkonu.