Protokol riadenia prenosu
 |
Niektorý z redaktorov požiadal o revíziu tohto článku. Redaktor si napríklad nie je istý, či neobsahuje obsahové chyby alebo je dostatočne zrozumiteľný. Prosím, opravte a zlepšite tento článok. Po úprave článku môžete túto poznámku odstrániť. |
| Aplikačná vrstva |
| HTTP · HTTPS · FTP · SSH · IMAP · SMTP · NNTP · IRC · SNMP · SIP · RTP · NFS a iné |
| Transportná vrstva |
| TCP, UDP, SCTP, DCCP a iné |
| Sieťová vrstva |
| IPv4, IPv6, ARP a iné |
| Linková vrstva |
| Ethernet, Wi-Fi, Token ring, FDDI a iné |
| Fyzická vrstva |
| RS-232, EIA-422, RS-449, EIA-485 a iné |
Protokol riadenia prenosu (angl. Transmission Control Protocol), skratka TCP, je jedným z protokolov balíka internetových protokolov, ktoré tvoria jeho jadro. Vďaka TCP môžu programy na počítačoch v sieti vytvárať medzi sebou spojenia (connections), ktorými je možné posielať dáta. Protokol pritom zaručuje, že dáta odoslané z jedného konca spojenia budú prijaté na druhej strane spojenia v rovnakom poradí a bez chýbajúcich častí. Rozlišuje tiež dáta pre rôzne aplikácie (ako webserver a emailový server) v rámci jedného počítača.
TCP podporuje mnohé z najpopulárnejších internetových aplikácí, vrátane HTTP, SMTP a SSH.
Technická špecifikácia
[upraviť | upraviť zdroj]TCP je spojovo orientovaný, spoľahlivý komunikačný protokol transportnej vrstvy prenášajúci bajtový tok, v súčasnosti zdokumentovaný v IETF RFC 793.
V balíku internetových protokolov tvorí TCP strednú vrstvu medzi IP protokolom pod ním a aplikáciami nad ním. Aplikácie často potrebujú medzi sebou spoľahlivé rúrovité spojenia, ale Internet protokol takéto toky neposkytuje, umožňuje iba nespoľahlivé pakety. Zastáva funkciu transportnej vrstvy v zjednodušenom OSI modeli počítačových sietí.
Aplikácie posielajú sieťou pomocou TCP toky dát s 8-bitovými slabikami a TCP rozdeľuje tok bajtov do segmentov s vhodne zvolenou veľkosťou (zvyčajne ovplyvnenou maximálnou veľkosťou prenosovej jednotky (MTU)). TCP potom podáva výsledné pakety Internet protokolu na doručenie internetom TCP modulu na opačnom konci spojenia. TCP vykonáva kontrolu, aby sa uistil, že sa žiaden paket nestratí tak, že dá každému paketu poradové číslo, ktoré na druhom konci opäť TCP modul kontroluje a zabezpečuje tiež, že dáta sú doručené v správnom poradí. Vzdialený TCP modul zasiela späť potvrdenie (acknowledgement) o úspešne prijatých bajtoch; časovač odosielajúceho TCP spôsobí timeout, ak nedostane potvrdenie vo vhodne zvolenom intervale obehu (round trip time) a dáta o ktorých predpokladá, že sa stratili pošle znova. TCP kontroluje, či dáta neboli poškodené tak, že ráta kontrolný súčet (checksum) pre každý blok odoslaných dát, ktorý sa pri prijímaní kontroluje.
| Bity | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | zdrojový port | cieľový port | ||||||||||||||||||||||||||||||
| 32 | číslo sekvencie | |||||||||||||||||||||||||||||||
| 64 | potvrdený bajt | |||||||||||||||||||||||||||||||
| 96 | offset dát | rezervované | príznaky | okienko | ||||||||||||||||||||||||||||
| 128 | kontrolný súčet | Urgent Pointer | ||||||||||||||||||||||||||||||
| 160 | voľby (voliteľné) | |||||||||||||||||||||||||||||||
| 192 | voľby (pokračovanie) | výplň (do 32) | ||||||||||||||||||||||||||||||
| 224 | dáta | |||||||||||||||||||||||||||||||
Fungovanie protokolu podrobne
[upraviť | upraviť zdroj]TCP spojenie má tri fázy: nadviazanie spojenia, prenos dát a ukončenie spojenia. Na nadviazanie spojenia sa používa tzv. 3-way handshake. 4-way handshake sa používa na ukončenie spojenia. Počas vytvárania spojenia sa inicializujú parametre ako poradové čísla paketov, aby sa zabezpečila robustnosť a poradie doručenia.
Nadviazanie spojenia
[upraviť | upraviť zdroj]Hoci je možné, aby dva stroje nadviazali spojenie zároveň, zvyčajne na jednom stroji beží serverová služba počúvajúca na určitom porte a pasívne počúva, t. j. čaká na prichádzajúce spojenia. Bežne sa to nazýva pasívne otvorenie a určuje stranu spojenia, ktorá funguje ako server. Klientská strana spojenia začne aktívne otvorenie tým, že pošle úvodný SYN segment serveru. Server by mal odpovedať platnou požiadavkou SYN so SYN/ACK. Nakoniec by mal klient odpovedať ACK, čím sa 3-way handshake, a teda fáza nadviazania TCP spojenia ukončí.
Prenos dát
[upraviť | upraviť zdroj]Počas fázy prenosu dát určuje niekoľko kľúčových mechanizmov spoľahlivosť a robustnosť TCP. Patria medzi ne poradové čísla pre určenie poradia TCP segmentov a detekciu duplikátnych dát, kontrolné súčty pre detekciu chýb v segmentoch a potvrdzovanie a časovače pre detekciu a prispôsobenie sa strate alebo oneskoreniu dát.
Počas fázy nadviazania TCP spojenia sa medzi dvoma strojmi vymenia tzv. initial sequence numbers (ISN). Tieto slúžia na identifikáciu dát v dátovom toku a počítanie dátových bytov. V každom TCP segmente existuje dvojica poradových čísel, ktoré sa nazývajú poradové číslo a potvrdzovacie číslo. Odosielateľ TCP segmentu nazýva poradové číslo jednoducho poradové číslo, zatiaľ, čo odosielateľ považuje poradové číslo segmentu od prijímateľa za potvrdzovacie číslo. Aby bola zabezpečená spoľahlivosť, prijímateľ potvrdzuje dáta v TCP segmente tak, že indikuje obdržané množstvo súvislých bajtov v TCP toku. Rozšírenie TCP nazývané selektívne potvrdzovanie (selective acknowledgement, SACK) umožňuje prijímateľovi potvrdzovať bloky mimo poradia.
Použitím poradových a potvrdzovacích čísel je TCP schopné doručovať obdržané segmenty v správnom poradí v dátovom toku prijímajúcej aplikácii. Poradové čísla sú 32-bitové čísla bez znamienka, ktoré po dosiahnutí čísla 232-1 pokračujú znova od nuly. Kľučom k udržaniu robustnosti a bezpečnosti TCP spojenia je výber ISN.
16-bitový kontrolný súčet pozostávajúci z doplnkov do jednotky a sumy doplnkov do jednotky obsahu hlavičky TCP segmentu a dát vypočíta odosielateľ a zahrnie ho do prenosu. (Súčet doplnkov do jednotky sa používa preto, lebo je ho možné vypočítať v každom násobku dĺžky -- 16-bitov, 32-bitov, 64-bitov atď. -- a výsledok bude po preložení rovnaký.) TCP prijímač počíta súčet prijatej TCP hlavičky a dát. Doplnok (hore) bol použitý preto, aby prijímač nemusel nulovať súčtové pole po uložení hodnoty inde; namiesto toho prijímač jednoducho vypočíta doplnok do jednotky na mieste kontrolného súčtu a výsledok by mal byť -0. Ak je to tak, segmet prišiel nedotknutý a bez chýb.
Všimnite si, že kontrolný súčet tiež zahŕňa 96 bitovú pseudohlavičku obsahujúcu zdrojovú adresu, cieľovú adresu, protokol a dĺžku segmentu. Tým poskytuje ochranu pred chybne smerovanými segmentami.
Podľa súčasných štandardov je kontrolný súčet pomerne slabou kontrolou. Spojové vrstvy s vysokou pravdepodobnosťou bitových chýb môžu požadovať dodatočné kontroly a opravy chýb. Ak by dnes bolo TCP znova navrhované, pravdepodobne by obsahovalo 32-bitovú cyklickú kontrolu redundancie (CRC, cyclic redundancy check) namiesto súčasného kontrolného súčtu. Slabá kontrola je čiastočne kompenzovaná bežným použitím CRC alebo inej integritnej kontroly na vrstve 2, pod TCP a IP, ako je použité v rámci PPP alebo Ethernetu. To však neznamená, že je kontrolný 16-bitový TCP súčet nadbytočný: výskumy internetovej premávky ukázali, že softvérové a hardvérové chyby produkujúce chybné pakety medzi hopmi premávky chránenej CRC a že 16-bitový TCP kontrolný súčet zachytáva väčšinu týchto chýb. To je princíp end-to-end spojenia v praxi.
Veľkosť TCP okna
[upraviť | upraviť zdroj]Veľkosť TCP okna je množstvo prijatých dát (v bajtoch), ktoré je možné bufferovať počas spojenia. Posielajúci stroj môže odoslať najviac toto množstvo dát, potom je povinný čakať na potvrdenie a aktualizáciu okna prijatým strojom. Windows TCP/IP stack je navrhovaný, aby sa o väčšine prostredí automaticky nastavil a používa väčšie veľkosti okna ako v skorších verziách.
Škálovanie okien
[upraviť | upraviť zdroj]Pre efektívnejšie využitie sietí s veľkou šírkou pásma môže byť použité väčšie TCP okno. Veľkosť TCP okna riadi tok dát a môže sa pohybovať v rozsahu 2 bajty až 65 535 bajtov. Keďže ju nie je možné ďalej zväčšiť, používa sa škálovanie násobením maximálnej veľkosti okna. Škálovanie TCP okna je možnosť, ktorá sa používa na zväčšenie maximálnej veľkosti okna od 65,535 bajtov do 1 Gigabajtu. Používa sa iba počas 3-way handshake. Škála okna reprezentuje počet bitov posunutia do ľava v poli veľkosti TCP okna. Jeho veľkosť môže byť od 0 (bez posunutia) do 14.
Ukončenie spojenia
[upraviť | upraviť zdroj]Ukončenie spojenia sa deje za použitia 4-way handshake, kde sa spojenie ukončuje na každom konci nezávisle. Preto typické zrušenie spojenia vyžaduje pár segmentov FIN a ACK z každého konca TCP spojenia.
Je možné aj 3-way handshake, kde po prijatí FIN segmentu odošle druhá strana ACK+FIN v jednom pakete. Následne mu príde odpoveď ACK.
TCP porty
[upraviť | upraviť zdroj]TCP používa značenie pomocou čísel portov na identifikáciu prijímajúcich a odosielajúcich aplikácií. Každá strana TCP spojenia má priradené 16-bitové číslo bez znamienka (65535 portov) podľa odosielajúcej alebo prijímajúcej aplikácie. Porty sú kategorizované do troch oblastí: najznámejšie porty, ktoré priraďuje Internet Assigned Numbers Authority (IANA) a typicky ich používajú systémové procesy. Na týchto portoch počúvajú známe aplikácie bežiace ako server. Patria medzi ne napríklad FTP (21), Telnet (23), SMTP (25), HTTP (80). Registrované porty zvyčajne používajú používateľské aplikácie ako zdrojové porty, keď kontaktujú servery, ale môžu tiež identifikovať pomenované služby registrované tretími stranami. Užívateľské aplikácie tiež môžu používať dynamické alebo privátne porty, ale to sa deje zriedkavejšie. Dynamické/privátne porty nenesú žiaden význam mimo konkrétneho TCP spojenia.
Vývoj TCP
[upraviť | upraviť zdroj]TCP je komplexný, vyvíjajúci sa protokol. Hoci sa v priebehu rokov navrhli a vykonali významné rozšírenia, podstata jeho fungovania sa nezmenila od RFC 793 uverejneného v roku 1981. RFC 1122, Požiadavky pre internetové stroje vyjasnil množstvo špecifikácií týkajúcich sa implementácie TCP. RFC 2581, Riadenie preťaženia TCP, jeden z najdôležitejších RFC týkajúcich sa TCP v posledných rokoch popisuje aktualizované algoritmy predchádzajúce preťaženiu. V roku 2001 bol napísaný RFC 3168 opisujúci ECN (explicit congestion notification), signálny mechanizmus na predídenie preťaženia. Na začiatku 21. storočia je 95% paketov používaných na internete TCP. Bežné aplikácie používajúce TCP sú HTTP/HTTPS (world wide web), SMTP/POP3/IMAP (e-mail) a FTP (prenos súborov). Jeho široké použitie je dôkazom, že bol od začiatku dobre navrhnutý.
Nedávno bol vedcami z Caltechu vyvinutý nový protokol nazývaný FAST TCP (Fast Active queue management Scalable Transmission Control Protocol). Podobá sa na TCP Vegas v tom, že oba používajú zdržanie frontu paketov ako hlavný signál preťaženia. Ešte stále rozdiskutovanou témou je, či zdržanie frontu je vhodným signálom preťaženia.
Obmedzenia TCP softvéru
[upraviť | upraviť zdroj]V priebehu rokov sa postupne zvyšovala rýchlosť sietí. Čo začalo ako protokol vyvinutý pre nespoľahlivé nízkorýchlostné siete (niekoľko Kbps) v súčasnosti musí stíhať Gbps rýchlosti. Softvérové TCP implementácie vyžadujú vysoký výpočtový výkon. Samotná gigabitová TCP komunikácia konzumuje 100% Pentium 2.4 GHz procesora.[chýba zdroj]
Hardvérové implementácie TCP
[upraviť | upraviť zdroj]Jedným zo spôsobov, ako predísť vysokým požiadavkám TCP na výpočtový výkon je implementovať ho hardvérovo, čo sa nazýva TCP Offload Engine (TOE). Hlavným problémom TOE je, že je ťažké ich integrovať do výpočtových systémov, keďže vyžadujú rozsiahle zmeny v operačnom systéme alebo zariadení. Lepším riešením sú Network Traffic Accelerators (NTA) alebo TCP akcelerátory. NTA sú hardvérové koprocesory, ktoré asistujú CPU v systéme pri spracovávaní paketov. NTA vo všeobecnosti nevyžadujú zmeny v operačnom systéme a je relatívne jednoduché ich implementovať.
Alternatívy k TCP
[upraviť | upraviť zdroj]TCP však nie je vhodné pre mnohé aplikácie a navrhujú a implementujú sa nové protokoly transportnej vrstvy adresujúce niektoré jeho inherentné nedostatky. Napríklad real-time aplikácie nepotrebujú a utrpia na výkone kvôli mechanizmom spoľahlivého doručenia. V takých typoch aplikácií je často lepšie vyrovnať sa so stratami, chybami alebo preťažením než pokúšať sa im predísť. Medzi príklady aplikácií, ktoré zvyčajne nepoužívajú TCP patria streamovanie multimédií v reálnom čase (ako Internetové rádio), real-time multiplayer hry a VoIP. Každá aplikácia, ktorá nepotrebuje spoľahlivosť alebo sa snaží minimalizovať funkcionalitu sa môže vyhnúť použitiu TCP. V mnohých prípadoch je možné použiť User Datagram Protocol (UDP) namiesto TCP, keď sú požadované iba aplikačné multiplexingové služby.