Transmission Control Protocol (doslovně „ Transmission Control Protocol “), zkráceně TCP , je spolehlivý protokol přenosuv připojeném režimu dokumentovaný v IETF RFC 793.
V internetovém modelu , známém také jako model TCP / IP, je TCP umístěn nad IP. V modelu OSI odpovídá transportní vrstvě , prostřední vrstvě sítě a vrstvě relace . Aplikace přenášejí datové toky přes síťové připojení. TCP rozděluje bajtový proud na segmenty, jejichž velikost závisí na MTU podkladové sítě ( vrstva datového spoje ).
TCP byl vyvinut v roce 1973 a přijat pro Arpanet v roce 1983 a nahradil NCP ( RFC 801).
Relace TCP funguje ve třech fázích:
Spojení je navázáno třemi kroky . Přerušení spojení využívá čtyřstupňový handshaking . Během fáze navazování spojení jsou inicializovány parametry, jako je pořadové číslo, aby byl zajištěn spolehlivý (bezztrátový a v pořadí) přenos dat.
V bitech
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 |
Zdrojový port 2 bajty | Cílový port 2 bajty | ||||||||||||||||||||||||||||||
Pořadové číslo | |||||||||||||||||||||||||||||||
Číslo potvrzení | |||||||||||||||||||||||||||||||
Velikost záhlaví | Rezervovat | ECN / NS | CWR | ECE | URG | ACK | PSH | RST | SYN | KONEC | Okno | ||||||||||||||||||||
Kontrolní součet | Ukazatel naléhavých dat | ||||||||||||||||||||||||||||||
Možnosti | Plnicí | ||||||||||||||||||||||||||||||
Data |
Význam polí:
I když je možné, aby dva systémy navázaly spojení mezi nimi současně, v obecném případě systém otevře „ soket “ (přístupový bod k připojení TCP) a pasivně čeká na požadavky na připojení z jiného systému. Tato operace se běžně označuje jako pasivní otevřená a používá ji serverová strana připojení. Klientská strana připojení provádí aktivní otevření ve 3 fázích:
Během této počáteční výměny se synchronizují pořadová čísla obou stran:
Během fáze přenosu dat zajišťují určité klíčové mechanismy robustnost a spolehlivost protokolu TCP. Sekvenční čísla se používají zejména k objednání přijatých segmentů TCP a k detekci ztracených dat, kontrolní součty umožňují detekci chyb a potvrzení a časové limity umožňují detekci ztracených nebo zpožděných segmentů.
Pořadová a potvrzovací číslaDíky pořadovým a potvrzovacím číslům mohou terminální systémy doručit přijatá data do aplikace příjemci.
Sekvenční čísla se používají k počítání dat v bajtovém proudu. V každém segmentu TCP jsou vždy dvě z těchto čísel, což jsou pořadové číslo a potvrzovací číslo . Pořadové číslo představuje vlastní pořadové číslo TCP, odesílatele, přičemž potvrzení číslo představuje pořadové číslo příjemce. Aby byla zajištěna spolehlivost protokolu TCP, musí příjemce potvrdit přijaté segmenty, což znamená, že přijal všechna data bajtového proudu až do určitého pořadového čísla.
Pořadové číslo označuje první bajt dat.
Například v případě výměny segmentů pomocí Telnetu :
Pořadová čísla jsou 32bitová celá čísla bez znaménka, která se po dosažení (2 ^ 32) -1 vrátí k nule. Volba počátečního pořadového čísla je jedním z klíčů robustnosti a zabezpečení připojení TCP.
Vylepšení TCP, nazývané selektivní potvrzení (SACK), umožňuje příjemci TCP potvrdit bloky dat přijatých mimo pořadí.
Kontrolní součetKontrolní součet z 16 bitů, sestávající z komplementu součtu doplněného pro všechny prvky TCP segmentu (hlavičky a dat) se vypočítá vysílačem, a jsou zahrnuty v vysílaný segment. Příjemce přepočítá kontrolní součet přijatého segmentu a pokud se shoduje s přijatým kontrolním součtem, považuje se segment za přijatý neporušený a bez chyby.
Časová prodlevaZtráta segmentu je zpracována TCP pomocí mechanismu časového limitu a opětovného přenosu. Po odeslání segmentu TCP počká určitou dobu, než obdrží odpovídající ACK. Příliš krátká doba vede k velkému počtu zbytečných opakovaných přenosů a příliš dlouhá doba zpomaluje reakci v případě ztráty segmentu.
Ve skutečnosti musí být zpoždění před opětovným přenosem větší než průměrná RTT segmentu, to znamená doba, kterou segmentu trvá zpáteční cesta mezi klientem a serverem. Protože se tato hodnota může časem měnit, jsou vzorky „odebírány“ v pravidelných intervalech a je počítán vážený průměr:
RTT moyen = (1-) * RTT moyen + * RTT échantillonTypická hodnota pro je 0,125. Vliv vzorků v průběhu času exponenciálně klesá.
Zpoždění, které se má použít, se získá z tohoto odhadu průměrné RTT a přidáním k ní bezpečnostní rezervy. Čím větší je rozdíl mezi vzorkem a průměrem, tím větší bezpečnostní rezervu lze očekávat. Výpočet se provádí z váženého rozptylu mezi vzorkem a průměrem:
Variance RTT = (1-) * Variance RTT + * |RTT échantillon - RTT moyen|Typická hodnota pro je 0,25. Časový limit, který se má použít, je nakonec dán následujícím vzorcem:
Délai = RTT moyen + 4 * Variance RTTKarn Algoritmus umožňuje lépe vyhodnotit zpoždění v přítomnosti nejednoznačného potvrzení . Ve skutečnosti, pokud byl odeslaný segment ztracen, následné segmenty způsobí potvrzení, ve kterých se objeví číslo prvního chybějícího bajtu, a proto již není známo, kterému segmentu odeslanému tato potvrzení odpovídají.
Někdy, když je zpoždění příliš dlouhé, je výhodné nečekat před opětovným vysíláním segmentu. Pokud hostitel obdrží 3 ACK pro stejný segment, má za to, že všechny segmenty přenášené po potvrzeném segmentu byly ztraceny, a proto je okamžitě odešle ( Fast retransmits ).
Řízení tokuKaždý partner v připojení TCP má přijímací vyrovnávací paměť, jejíž velikost není neomezená. Aby se zabránilo jednomu hostiteli v přetížení druhého, poskytuje TCP několik mechanismů řízení toku. Každý segment TCP tedy obsahuje velikost dostupnou v přijímací vyrovnávací paměti hostitele, který jej poslal. V reakci na to vzdálený hostitel omezí velikost okna odesílání, aby nedošlo k jeho přetížení.
Jiné algoritmy jako Nagle nebo Clarck také usnadňují řízení toku.
Kontrola přetíženíK přetížení dochází, když se příliš mnoho zdrojů pokusí odeslat příliš mnoho dat příliš rychle na to, aby je síť mohla přenést. To má za následek ztrátu mnoha paketů a dlouhé zpoždění.
Potvrzení o přenášených datech nebo absence potvrzení jsou používána vysílači k implicitní interpretaci stavu sítě mezi koncovými systémy. Pomocí časových limitů mohou odesílatelé a příjemci protokolu TCP upravit chování datového toku. Toto se obecně označuje jako kontrola přetížení.
Existuje velké množství algoritmů pro předcházení přetížení pro TCP .
jinýTCP používá řadu mechanismů k dosažení dobré robustnosti a vysokého výkonu. Mezi tyto mechanismy patří použití posuvného okna, algoritmus pomalého startu, algoritmus vyhýbání se přetížení, algoritmy rychlého opětovného přenosu a rychlé obnovy ( rychlé zotavení ) atd. V současné době probíhá výzkum s cílem zlepšit TCP, aby efektivně zvládal ztráty, minimalizoval chyby, zvládal přetížení a byl rychlý ve velmi vysokorychlostních prostředích.
Pomalý startPomalý start (TCP) je algoritmus, který vyvažuje rychlost síťového připojení. Pomalý start postupně zvyšuje množství přenášených dat, dokud nenajde maximální přepravní kapacitu sítě.
Pomalý start TCP je jedním z prvních kroků v procesu řízení přetížení. Vyvažuje množství dat, které může vysílač vysílat (nazývá se okno přetížení) a množství dat, které může přijímač přijímat (nazývá se okno pro příjem). Nižší ze dvou hodnot se stává maximálním množstvím dat, které může odesílatel odeslat před přijetím potvrzení od příjemce.
Jedním z nejběžnějších způsobů, jak optimalizovat rychlost připojení, je zvýšit rychlost spojení (tj. Zvýšit velikost šířky pásma). Pokud se však zařízení pokusí odeslat příliš mnoho dat, může dojít k přetížení jakéhokoli odkazu. Nadměrné nasycení spojení je známé jako přetížení a může vést k pomalé komunikaci a dokonce ke ztrátě dat.
Rychlý přenosRychlý přenos je vylepšení protokolu TCP, které zkracuje dobu, po kterou odesílatel čeká, než znovu odešle ztracený segment. Odesílatel TCP obvykle používá jednoduchý časovač k rozpoznání ztracených segmentů. Pokud není pro určitý segment přijato potvrzení ve stanoveném čase (na základě odhadované doby zpáteční cesty), odesílatel bude předpokládat, že segment byl v síti ztracen, a znovu jej vyslat.
Duplicitní potvrzení je základem mechanismu rychlého přenosu. Po obdržení paketu je zasláno potvrzení posledního přijatého datového bajtu v pořadí. U paketu v pořadí je to vlastně pořadové číslo posledního paketu plus délka užitečného zatížení aktuálního paketu. Pokud dojde ke ztrátě dalšího paketu v sekvenci, ale je přijat třetí paket v sekvenci, může přijímač potvrdit pouze poslední bajt dat v pořadí, který má stejnou hodnotu jako potvrzení prvního balíku. Druhý paket je ztracen a třetí paket je mimo pořadí, takže poslední bajt dat v pořadí zůstává stejný jako předtím. Existuje tedy dvojí potvrzení. Odesílatel pokračuje v odesílání paketů a příjemce obdrží čtvrtý a pátý paket. Druhý paket v sekvenci opět chybí, takže poslední bajt dat v pořadí se nezměnil. Pro tyto dva pakety se odesílají duplicitní potvrzení.
Když odesílatel obdrží tři duplicitní potvrzení, může být rozumně jisté, že segment nesoucí data, který následoval po posledním řídicím bajtu uvedeném v potvrzení, byl ztracen. Odesílatel s rychlým opětovným vysláním pak tento paket okamžitě odešle znovu, aniž by čekal na vypršení platnosti. Po přijetí znovu vyslaného segmentu může přijímač potvrdit příjem posledního přijatého datového bajtu. Ve výše uvedeném příkladu by to potvrdilo přijetí až do konce užitečného zatížení pátého paketu. Není nutné potvrzovat mezilehlé pakety, protože TCP je výchozí pro kumulativní potvrzení.
Fáze ukončení připojení využívá čtyřfázový handshaking, přičemž každý konec připojení se ukončí nezávisle. Ukončení připojení tedy vyžaduje pro každý konec dvojici segmentů FIN a ACK.
TCP, stejně jako UDP , používá k identifikaci aplikací číslo portu . Každý konec ( klient / server ) připojení TCP je spojen s 16bitovým číslem portu (od 1 do 65535) přiřazeným odesílající nebo přijímající aplikaci. Tyto porty jsou rozděleny do tří kategorií:
US Department of Defense (DoD), původně vyvinutý model srovnávací TCP / IP, protože potřebovala síť, která by mohla vydržet v každé situaci.
TCP je poměrně složitý a vyvíjející se protokol. Ačkoli v průběhu let došlo k významným vylepšením, jeho základní provoz se od RFC 793 , publikovaného v roce 1981, změnil jen málo . RFC 1122 ( Hostitelské Požadavky na internetových hostitelů ) objasnil řadu předpokladů pro implementaci protokolu TCP. RFC 2581 ( TCP Congestion Control ), jedna z nejdůležitějších v posledních letech, popisuje nové algoritmy používané protokoly TCP, aby se zabránilo přetížení. V roce 2001 byl RFC 3168 napsán, aby zavedl mechanismus upozornění na přetížení (ECN), a přidává do seznamu důležitých RFC, které doplňují původní specifikaci.
Na začátku XXI -tého století , TCP je používán pro přibližně 90% všech dopravních internetu . Nejběžnějšími aplikacemi, které používají TCP, jsou HTTP / HTTPS ( World Wide Web ), SMTP / POP3 / IMAP (e-mail) a FTP (přenos souborů). Youtube a Netflix také používají TCP pro streamování streamů .
Mnoho aplikací v reálném čase nepotřebuje a může dokonce trpět složitými mechanismy spolehlivého přenosu TCP: aplikace pro streamování multimédií (audio, video, hry pro více hráčů) v reálném čase, výměna souborů atd. V těchto typech aplikací je často lepší vypořádat se se ztrátami, chybami nebo přetížením, než se jim snažit vyhnout.
Pro tyto konkrétní potřeby byly vytvořeny a nasazeny další transportní protokoly .