Transmission control protocol
Från Rilpedia
| Protokollstack för IP-nätverk | |
| IP-skikt | Protokoll |
|---|---|
| 5.Applikation | BitTorrent, DHCP, DNS, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, Telnet,TLS, SSL , TFTP, … |
| 4.Transport | DCCP, SCTP, TCP, RTP, UDP, IL, RUDP, … |
| 3.Nätverk | ARP, ICMP, IGMP, IP (IPv4, IPv6),RIP … |
| 2.Länk | ATM, Ethernet, FDDI, ISDN, MPLS, Token Ring, PPP, SLIP, Wi-Fi, … |
| 1.Fysiska | ISDN, RS232, IrDA, Bluetooth, xDSL, … |
- TCP omdirigerar hit. För artikeln om måttenheten för hur effektivt mobiltelefoner använder signalstrålningen, se TCP (mobiltelefoni).
TCP, akronym för Transmission Control Protocol, dataöverföringsprotokoll, är ett förbindelseorienterat protokoll som används för huvuddelen av all kommunikation över Internet. TCP tillhandahåller en pålitlig dataström mellan två datorer och används för exempelvis HTTP, FTP och e-post (SMTP, IMAP och POP3). TCP är mindre lämpligt i situationer där dess felkorrigerande egenskaper kan orsaka oönskade fördröjningar, exempelvis i datorspel. Där används ofta istället transportprotokollet UDP.
Innehåll |
Översikt
TCP använder sig av det underliggande protokollet IP. IP skickar data i form av paket. Varje paket innehåller en liten mängd data (ofta 1480 bytes), samt information om vilken dator som skickade paketet, och vilken dator som ska ta emot det. IP ger inga garantier för att paket som skickas över nätverket kommer fram, och paket som skickas behöver inte komma fram i samma ordning som det skickades.
När TCP skickar data så delas det upp i lämpliga stycken (så kallade segment), och varje segment skickas i ett eget IP-paket. När IP-paketet kommer fram till mottagaren skickar denna ett ACK-segment tillbaka till sändaren för att indikera att datat kommit fram. Om sändaren inte fått ett sådant ACK-segment inom en viss tid så antas att datapaketet har försvunnit i nätet, och datapaketet skickas om. På så sätt uppnås pålitligheten hos TCP.
För att hantera att IP-paket kan komma fram i oordning använder TCP sekvensnummer. Varje paket som skickas tilldelas ett 32-bitars nummer, och detta används av mottagaren för att sortera de mottagna datapaketen.
TCP innehåller mekanismer som begränsar hur fort data skickas för att inte överbelasta nätet. Varje gång nätverket tappar ett datapaket så antas detta bero på att det ligger på gränsen för att överbelastas. TCP drar då ned på sändningstakten till hälften av den nuvarande för att undvika att lasta ned nätet ytterligare. När inga datapaket går förlorade ökar protokollet takten igen.
Förbindelseorienterat
TCP-sessionen innehåller tre faser: anslutning, dataöverföring och nerkoppling. En trestegshandskakning används för att ansluta, medan nerkoppling kan kräva fyra steg (man skiljer mellan abortiv nerkoppling och hänsynsfull nerkoppling). Vid anslutning initieras vissa parametrar som används i dataöverföringsfasen.
Anslutningsfasen
Som ett första steg i anslutningsfasen skickar den anslutande datorn (klienten) en så kallat SYN-segment till den dator som förbindelsen ska göras mot (servern). I SYN-segmentet är SYN-flaggan satt. Detta segment kan innehålla ett antal optioner som beskriver vilka specialfunktioner som klienten stödjer, samt den maximala paketstorlek som klienten är beredd att ta emot. SYN-segmentet innehåller dessutom sekvensnumret för den första databyte som klienten skickar över förbindelsen.
Om servern är villig att ta emot förbindelsen svarar denna med ett SYNACK-segment. I detta segment är både SYN- och ACK-flaggorna satta, och det innehåller sekvensnumret för den första databyte som servern skickar. Det innehåller även det sekvensnummer som klienten skickade, men ökat med ett. Detta synkroniserar sekvensnumret så att båda parter vet vilket sekvensnummer som motparten använder sig av. SYNACK-segmenten kan också innehålla svar på de optioner som klienten skickade, om servern stödjer dem.
Om servern inte accepterar den inkommande förbindelsen så svarar den i stället med ett RST-segment, vilket avbryter förbindelseförsöket i klienten.
När SYNACK-segmentet når klienten skickar denne ett ACK-segment, och förbindelsen går över i dataöverföringsfasen. Denna procedur kallas trevägshandskakningen på grund av de tre paketen som skickas: SYN, SYNACK och ACK.
Dataöverföringsfasen
När anslutningsfasen är genomförd går förbindelsen in i dataöverföringsfasen och data kan skickas mellan de två ändpunkterna i förbindelsen. I dataöverföringsfasen finns inte längre någon skillnad mellan klienten och servern; den skillnaden finns endast i anslutningsfasen.
All data som skickas delas upp i segment och skickas i var sitt IP-paket. När mottagaren tar emot ett datasegment så skickar den ett ACK-segment till sändaren för att indikera att segmentet har kommit fram. Om sändaren inte får ett ACK-segment inom en viss tid så har paketet troligen tappats bort av nätverket och sändaren skickar om segmentet.
Nerkopplingsfasen
En TCP-förbindelse kan kopplas ned av båda eller endast den ena av ändpunkterna av förbindelsen. När en av ändpunkterna inte har mer data att skicka så markerar den detta med att skicka ett FIN-segment. FIN-segmentet bekräftas av mottagaren genom ett vanligt ACK-segment. Vanligtvis stänger då också mottagaren sin del av förbindelsen genom att skicka ett FIN-segment, även om det inte är ett krav. När båda ändpunkterna har skickat sina FIN-segment och de blivit bekräftade med ACK-segment är förbindelsen stängd. För att inte gamla segment från förbindelsen som blivit kvar i nätverket ska störa nya förbindelser ligger dock förbindelsen kvar i den ena ändpunkten i TIME_WAIT-tillståndet.
Ett vanligt programmeringsproblem är att man glömmer att stänga ena änden av förbindelser man ansluter. Detta får till följd att en massa förbindelser lever kvar i systemet i tillståndet CLOSE_WAIT.
Programmeringsgränssnitt
Det finns inget standardiserat programmeringsgränssnitt för TCP, utan ett antal olika gränssnitt har utvecklats. Två vanliga gränssnitt för program används: BSD Sockets och Transport Interface.
Socket
Gränssnitt mellan två processer.
Implementationsproblem
TCP är ett komplext protokoll och är besvärligt att implementera. Detta har visat sig som ett antal buggar, programmeringsfel, i många vanliga implementationer av TCP. Drabbade operativsystem är bland annat Solaris, Linux och Windows. Dessa programmeringsfel har gett upphov till problem i vissa nätverk på grund av problem med omsändningsklockor och överlasthantering. RFC2525 innehåller detaljerade beskrivningar och diskussioner om dessa.
Alternativ
TCP har både fördelar och nackdelar. Fördelen är att alla paket har överföringsgaranti (inom statistiska gränser). Detta är dock en nackdel för tillämpningar för vilka det är viktigare att data kommer fram i tid än att data kommer fram korrekt och i samma ordning som den sändes. Även om TCP i vissa fall används för strömmande media så är UDP-protokollet att föredra för sådana tillämpningar eftersom UDP-paket inte återsänds per automatik. Sådana tillämpningar måste dock sköta sin egen överlasthantering - UDP tillåter att en tillämpning skickar data med en sådan hastighet att den tränger ut annan kommunikation från nätverket.
Utöver UDP och TCP har en mängd andra transportprotokoll utvecklats genom åren, men dessa har inte fått någon större spridning. Ett transportprotokoll som är under aktiv utveckling är SCTP, Stream Control Transmission Protocol. SCTP kombinerar funktioner från både TCP och UDP, samt lägger till några funktioner som inte finns hos dessa protokoll. Till exempel tål SCTP att IP-adresserna hos ändpunkterna för en förbindelse ändras utan att förbindelsen kopplas ned.
Standarddokument
TCP är formellt definierat i en mängd RFC-dokument:
- RFC 793, "Transmission Control Protocol", september 1981. Den ursprungliga TCP-standarden som innehåller specifikationen för grundprotokollet.
- RFC 1122, "Requirements for Internet Hosts - Communication Layers", oktober 1989. Uppdateringar och förklaringar till RFC793.
- RFC 1323, "TCP Extensions for High Performance", maj 1992. Utvidgningar av TCP för högre prestanda: window scaling, time stamps, PAWS (protection against wrapped sequence numbers) för långa feta pipor (sic).
- RFC 2018, "TCP Selective Acknowledgement Options", oktober 1996. En förbättrad ACK-hantering för TCP.
- RFC 2581, "TCP Congestion Control", april 1999. Den senaste versionen av TCPs överlasthantering.
- RFC 2988, "Computing TCP's Retransmission Timer", november 2000. Uppdaterade formler för hur omsändningsklockan ska hanteras.
- RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP", september 2001. Ett sätt att markera överlast i nätverket, utan att paket behöver tappas bort.
Dessutom finns ett antal RFC-dokument som diskuterar bland annat speciella problem med implementationer av protokollet:
- RFC 2525, "Known TCP Implementation Problems", mars 1999.
- RFC 3360, "Inappropriate TCP Resets Considered Harmful", augusti 2002.
- RFC 3449, "TCP Performance Implications of Network Path Asymmetry", december 2002.
Utöver dessa finns ett antal dokument som specificerar experimentalla tillägg till TCP:
- RFC 2140, "TCP Control Block Interdependence", april 1997. Låter TCP dela viss information mellan olika förbindelser.
- RFC 2582, "The NewReno Modification to TCP's Fast Recovery Algorithm", april 1999. Ett förbättrat sätt att hantera förlust av enstaka datapaket.
Det finns även en uppsjö av RFC-dokument som diskuterar olika varianter av TCP och hur dessa fungerar i verkliga nätverk:
- RFC 1337, "TIME-WAIT Assassination Hazards in TCP", maj 1992. Diskuterar vissa randproblem med TIME-WAIT tillståndet hos TCP.
- RFC 2416, "When TCP Starts Up With Four Packets Into Only Three Buffers", september 1998.
- RFC 2760, "Ongoing TCP Research Related to Satellites", februari 2000.
- RFC 2884, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", juli 2000.
- RFC 2923, "TCP Problems with Path MTU Discovery", september 2000.
