Transmission Control Protocol

Transmission Control Protocol (TCP[1]) är ett förbindelseorienterat dataöverföringsprotokoll som används för huvuddelen av all kommunikation över Internet. TCP tillhandahåller en relativt 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.

TCP och IP (Internetprotokoll) kopplas ofta samman som TCP/IP, eftersom de båda protokollen utvecklades för att arbeta tillsammans.[2]

TCP och IP uppfanns ursprungligen av amerikanerna Vint Cerf och Bob Kahn 1974. Deras uppfinning, tillsammans med principen med distribuerade nätverk, som ARPANET, lade grunden till dagens moderna internet.[3]

Historik

TCP utvecklades under 1970-talet, för att hantera kommunikationen mellan olika delar av Arpanet. Viktiga namn i utvecklingen var bland andra fransmannen Louis Pouzin,[4] Alex Curran på Bell Northern Research[5] samt de båda amerikanska ingenjörerna Vint Cerf och Bob Kahn. Vid ett möte i brittiska Sussex i september 1973 presenterade Cerf och Kahn det nya kommunikationsprotokollet "Transmission Control Protocol".[6] Målet var att producera ett protokoll som var snabbare och mer felsäkert än de hos telefonnätverkens då allenarådande kretskopplade nätverk.

Via den senare utvecklingen av TCP upptäcktes att det var lämpligt att dela upp nätverkshanteringen och hanteringen av datatransporten i olika protokoll. Därför presenterades 1978 det särskilda Internetprotokollet (IP),[7] idag mest känt via sina versioner 4 och 6. Senare har ytterligare protokoll utvecklats för att ta hand om olika funktioner och nätverkstjänster.

Funktioner

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 de 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 bekräfta att data kommit fram. Om sändaren inte fått ett sådant ACK-segment inom en viss tid så antas att datapaketet har försvunnit på nätet och datapaketet skickas om. På så sätt uppnås pålitligheten hos TCP.

TCP är numera bara ett av många olika protokoll som används för att olika sorts kommunikation över Internet ska fungera.

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 förlorar 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) ett 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 valmöjligheter 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 valmöjligheter 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 SYN-ACK-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 bekräfta 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 ska kopplas ned av båda ä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. När mottagaren är klar stänger då också mottagaren sin del av förbindelsen genom att skicka ett FIN-segment. 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.

TCP-paketets uppbyggnad

Ett TCP-paket består av en header som efterföljs av data. TCP headerns uppbyggnad kan ses i nedanstående tabell:

TCP Header
OffsetOktett0123
OktettBit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0AvsändarportDestinationsport
432Sekvensnummer
864ACK-nummer
1296Data offsetReserverad
0 0 0
FlaggorFönsterstorlek
16128KontrollsummaPekare till brådskande data
20
...
160
...
Alternativ
...
Avsändarport
Anger vilken port datan skickades från.
Destinationsport
Anger vilken port datan skickas till.
Sekvensnummer
Anger vad för offset datan i paketet har i ordningen, mätt i bytes.
ACK-nummer
Anger det sekvensnummer som nästa paket mottagaren väntar på ska ha.
Data offset
Anger TCP-headers storlek mätt i 32-bitars ord.
Reserverad
Används ej och ska vara satt till 0.
Flaggor
Anger vilken typ av TCP-paket det är, exempelvis SYN, ACK, FIN eller RST.
Fönsterstorlek
Anger mottagarens nuvarande bufferkapacitet för framtida paket som ska skickas.
Kontrollsumma
Används för att kontrollera att paketet inte har blivit korrupt.
Pekare till brådskande data
Anger offset till brådskande data.
Alternativ
Kan innehålla några extra alternativ. Fylls ut med nollor för att TCP-paketet ska bestå av ett jämnt antal 32-bitars ord.

Problem och alternativ

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.

Referenser

Externa länkar

Media som används på denna webbplats

Internet map 1024 - transparent, inverted.png
Författare/Upphovsman: The Opte Project, Licens: CC BY 2.5
Partial map of the Internet based on the January 15, 2005 data found on opte.org. Each line is drawn between two nodes, representing two IP addresses. The length of the lines are indicative of the delay between those two nodes. This graph represents less than 30% of the Class C networks reachable by the data collection program in early 2005. Lines are color-coded according to their corresponding RFC 1918 allocation as follows:
  net, ca, us
  com, org
  mil, gov, edu
  jp, cn, tw, au, de
  uk, it, pl, fr
  br, kr, nl
  unknown
InternetProtocolStack.png
En grafisk representation över protokollstacken i datakommunikation över internet enligt RFC 1122.