Transmission Control Protocol

Transmission Control Protocol (TCP) je nejpoužívanějším protokolem transportní vrstvy v sadě protokolů TCP/IP používaných v síti Internet. Použitím TCP mohou aplikace na počítačích propojených do sítě vytvořit mezi sebou spojení, přes které mohou obousměrně přenášet data. Protokol garantuje spolehlivé doručování a doručování ve správném pořadí. TCP také umožňuje rozlišovat a rozdělovat data pro více aplikací (například webový server a emailový server) běžících na stejném počítači.

TCP využívá mnoho populárních aplikačních protokolů a aplikací na internetu, včetně WWW, e-mailu a SSH.

Technický přehled

TCP je spojově orientovaný protokol pro přenos toku bajtů na transportní vrstvě se spolehlivým doručováním. V současnosti je zdokumentován v IETF RFC 793.

V sadě protokolů Internetu je TCP prostřední vrstvou mezi IP protokolem pod ním a aplikací nad ním. Aplikace ke vzájemné komunikaci využívají spolehlivé spojení na způsob roury, zatímco IP protokol neposkytuje takové streamy, ale jen nespolehlivé pakety. TCP používá služby protokolu IP; opakovaným odesíláním ztracených nebo poškozených paketů přes nespolehlivou síť zajišťuje spolehlivost a přeuspořádáváním přijatých paketů zajišťuje jejich správné pořadí. Tím TCP plní úlohu transportní vrstvy ve zjednodušeném modelu ISO/OSI počítačové sítě.

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																cílový port
32	pořadové číslo
64	potvrzovací číslo
96	offset dat				rezervováno						příznaky						okénko
128	kontrolní součet																Urgent Pointer
160	volby (volitelné)
192	volby (pokračování)																								výplň (do 32)
224	data

Aplikace posílá proud (stream) bajtů TCP protokolu k doručení sítí, TCP rozděluje proud bajtů do přiměřeně velkých segmentů. (Velikost segmentů je určena parametrem MTU (maximum transmission unit) linkové vrstvy sítě, ke které je počítač připojen.) TCP pak předá takto vzniklé pakety IP protokolu k přepravě internetem do TCP modulu na druhé straně TCP spojení. TCP ověří, že se pakety neztratily tím, že každému paketu přidělil pořadové číslo, které se také použije k ověření, že data byla přijata ve správném pořadí.

TCP modul na straně příjemce posílá zpět potvrzení pro pakety které byly úspěšně přijaty. Pokud by se odesilateli potvrzení nevrátilo do rozumné doby (dané obousměrným zpožděním, anglicky round-trip time, RTT), vypršel by odesilatelův časovač a (pravděpodobně ztracená) data by vyslal znovu.

TCP protokol ověřuje, zda přenesená data nebyla poškozena šumem tím, že před odesláním spočte kontrolní součet, uloží jej do odesílaného paketu a příjemce kontrolní součet vypočte znovu a ověří, že se shodují.

Fungování protokolu v detailu

Zjednodušený stavový diagram TCP.^[1]

TCP porty

K rozlišení komunikujících aplikací používá TCP protokol čísla portů. Každá strana TCP spojení má přidruženo 16bitové bezznaménkové číslo portu (existuje 65535 portů) přidělené aplikaci. Porty jsou rozčleněny do třech skupin: dobře známé, registrované a dynamické/privátní. Seznam dobře známých portů je přiřazován organizací Internet Assigned Numbers Authority (IANA) a jsou typicky používané systémovými procesy. Dobře známé aplikace běžící jako servery a pasivně přijímající spojení typicky používají tyto porty. Několik příkladů: FTP (port 21 a 20), SMTP (port 25), DNS (port 53) a HTTP (port 80). Registrované porty jsou typicky používané aplikacemi koncových uživatelů při otevírání spojení k serverům jako libovolná čísla zdrojových portů, ale také mohou identifikovat služby. Dynamické/privátní porty mohou být také používány koncovými aplikacemi, ale není to obvyklé.

Číslování bytů

Pro zajištění spolehlivého přenosu proudu dat v obou směrech, bez výpadků, opakování nebo přehazování dat, TCP používá zpětnou vazbu s automatickým opakováním, pro jejíž podporu jsou v TCP hlavičce dvě 32bitová pole a příznak ACK. Na rozdíl od jiných protokolů, které číslují datagramy, TCP čísluje jednotlivé byty. V poli pořadové číslo (anglicky sequence number) je číslo prvního bytu v poli data (příp. číslo následujícího bytu, pokud je pole data prázdné). Pokud je nastaven příznak ACK, je v poli potvrzovací číslo (anglicky acknowledgment number) číslo dalšího bytu, který potvrzující strana očekává od protistrany; jeho odesláním jsou potvrzena všechna přijatá předchozí data v proudu.

Navázání a ukončení spojení

Protože TCP je spojovaná transportní služba, musí se před odesíláním dat navázat spojení mezi klientem a serverem. K tomu slouží trojcestný handshaking (anglicky three-way handshake). V průběhu navazování spojení si každá z obou komunikujících stran náhodně zvolí pořadové číslo (anglicky sequence number), od kterého (zvětšeného o 1) bude číslovat odesílané byty. Úplně první datagram, který odesílá každá strana při navazování spojení, má nastaven příznak SYN.

Navázání spojení probíhá ve třech krocích:

• Klient odešle na server datagram s nastaveným příznakem SYN a náhodně vygenerovaným pořadovým číslem (x), potvrzovací číslo=0.
• Server odešle klientovi datagram s nastavenými příznaky SYN a ACK, potvrzovací číslo=x+1, pořadové číslo je náhodně vygenerované (y)
• Klient odešle datagram s nastaveným příznakem ACK, pořadové číslo=x+1, číslo odpovědi=y+1.

Obě strany si pamatují pořadové číslo vlastní i protistrany. Používají se totiž i pro další komunikaci a určují pořadí paketů. Když úspěšně proběhne trojcestný handshaking, je spojení navázáno a zůstane tak až do ukončení spojení. To se může zneužít na SYN flood útok.

Ukončení spojení probíhá podobně jako jeho navázání. Používá se k tomu příznaků FIN a ACK:

• Strana, která nechce posílat další data, odešle datagram s nastaveným příznakem FIN
• Protistrana odpoví datagramem s nastaveným příznakem ACK s potvrzovacím číslem o jedničku větším, než bylo pořadové číslo v datagramu s příznakem FIN (jako kdyby protistrana poslala místo FIN jeden byte dat)
• Druhá strana, která ukončuje posílání dat, odešle datagram s nastaveným příznakem FIN
• Protistrana odpoví datagramem s nastaveným příznakem ACK

Po prvních dvou krocích může druhá strana pokračovat v posílání dat. Pokud žádná data posílat nebude, mohou být kroky 2 a 3 sloučeny. Teprve po těchto čtyřech krocích je spojení ukončeno. Z hlediska číslování potvrzovaných bytů se příznaky SYN a FIN chovají jako jeden byte dat.

Vývoj TCP

TCP je komplexní protokol. Ačkoli bylo v průběhu let navrženo několik významných rozšíření, podstata jeho fungování se nezměnila od první verze z roku 1974 podle RFC 675 a specifikace v4 z roku 1981 podle RFC 793. V roce 1989 bylo vydáno RFC 1122, které vyjasnilo mnoho požadavků na implementaci TCP protokolu (Požadavky pro internetové stroje). V roce 2015 byl vydán seznam osmi požadovaných specifikací a přes 20 důrazně doporučených vylepšení dle RFC 7414. Mezi nimi je i RFC 2581 z roku 1999, které popisuje Řízení zahlcení pro TCP (anglicky TCP Congestion Control), což je jedno z nejdůležitějších RFC týkajících se TCP vydaných v posledních letech, které popisuje aktualizované algoritmy předcházející zahlcení přenosové cesty. V roce 2001 bylo vydáno RFC 3168 popisující „signalizační mechanizmus pro předcházení zahlcení“ (ECN, anglicky explicit congestion notification).

Původní TCP algoritmy pro předcházení zahlcení (při přenosu dat) byly známy pod názvem „TCP Tahoe“, avšak od té doby bylo navrženo mnoho alternativních algoritmů (TCP Reno, TCP Vegas, FAST TCP, TCP New Reno a TCP Hybla).

Alternativy za TCP

Pro mnoho aplikací není TCP vhodné. Velkým problémem představuje (alespoň u normálních implementací) blokování čela fronty, kvůli kterému aplikace po ztrátě jednoho paketu nedostává následující pakety do té doby, dokud není ztracený paket znovu poslán a úspěšně přijat. To způsobuje problémy realtimovým aplikacím jako streamovaná média (např. internetové rádio), realtimové hry pro více hráčů a VoIP, u kterých je důležitější dostávat data včas, než je dostávat ve správném pořadí a kompletní.

Složitost TCP může být problém také pro vestavěná zařízení (anglicky embedded systems). Nejznámějším příkladem je bootování po síti, které obecně používá TFTP (viz PXE). Navíc pro některé triky, jako je přenos dat mezi dvěma uzly, které jsou oba za NATem (použitím STUN nebo podobných protokolů), je mnohem jednodušší, když vám v cestě nestojí složitý protokol jako TCP.

Tam, kde je TCP nevhodné, se často používá UDP, které poskytuje aplikaci kontrolu/ovládání nad multiplexováním a ověřováním kontrolních součtů. Zato ale UDP neprovádí fragmentaci proudu dat do paketů a zpátky jejich rekonstruování, ani opětovné posílání ztracených paketů. To dovoluje vývojáři aplikace napsat si uvedené funkce tak, jak vyhovuje jeho potřebám, nebo je nahradit použitím samoopravných kódů (anglicky forward error correction) nebo interpolace.

SCTP je transportní protokol nad IP, který poskytuje spolehlivé, datagramové služby nepříliš odlišné od TCP. SCTP je novější a mnohem složitější protokol než TCP; rutinně se používá v telekomunikačních sítích pro přenos signalizace, ale v běžném provozu se nedočkal širokého nasazení, ačkoliv je obzvláště navržený k tomu, aby byl používaný v situacích, kdy jsou spolehlivost a téměř real-time ohledy důležité.

Venturi Transport Protocol (VTP) je patentovaný proprietární protokol, který je navržen tak, aby nahradil TCP a transparentně překonal vnímané nedostatky vztahující se k bezdrátovému přenosu dat.

TCP má také problémy v prostředí s vysokou šířkou pásma. TCP algoritmy pro zamezení zahlcení fungují velmi dobře pro ad-hoc prostředí, kde odesílatel dat není předem znám. Také v případě, že je prostředí dopředu známo, mohou časové principy protokolu, jako je například asynchronní typ přenosu snížit režii pro znovu odeslání dat.

UDT založené na User Datagram Protocol, má v sítích, které mají vysoký rozsah latence, lepší účinnost a „férovost“ než TCP. Víceúčelový Transakční Protokol (MTP/IP) je patentován jako proprietární software, který je navržen tak, aby adaptivně dosahoval vysoké propustnosti a výkonu v nejrůznějších síťových podmínkách, a to zejména tam, kde TCP je vnímán jako nevyhovující nebo nedostatečný.

QUIC (Quick UDP Internet Connections) je experimentální protokol využívající UDP, který vyvinula společnost Google pro novou verzi protokolu HTTP.

Reference

1. http://www.medianet.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf – detailní stavový diagram TCP (EFSM)

Související články

• TCP algoritmy pro předcházení zahlcení pro podrobnosti o TCP Reno, TCP Vegas, TCP Westwood, BIC a Hybla
• Seznam čísel portů TCP a UDP
• SCTP
• Spojovaná komunikace
• Ladění TCP protokolu u linek s velkým zpožděním a velkou propustností

Externí odkazy

• RFC793 v textovém
• RFC793 v HTML formátu
• RFC1122 opravy chyb
• RFC1323 rozšíření TCP
• porty přiřazené IANAou
• stránka Sally Floyd
• přehled Johna Kristoffa o TCP (Fundamental concepts behind TCP and how it is used to transport data between two endpoints)]
• úvod do TCP/IP s obrázky
• Základy Transmission Control Protocol
• Tcp/Ip port numbers. Information for Unix based system administrators
• TCP, Transmission Control Protocol Archivováno 14. 11. 2015 na Wayback Machine.
• Network World - Tech Insider Archivováno 22. 4. 2005 na Wayback Machine.
• EE Times - TCP Accelerators
• Understanding TCP Reset Attacks
• TCP/IP Sequence Diagrams
• TCP/IP
• TCP Traffic Shaper for Windows

Autoritní data	PSH: 12376

Portály: Internet