TCP protokoll

TCP (Transmission Control Protocol) är ett förbindelseorienterat protokoll som erbjuder tillförlitlig och ordnad dataöverföring mellan en avsändare och en mottagare. Det upprättar en förbindelse mellan avsändaren och mottagaren innan dataöverföringen påbörjas och använder sig av kommunikationskontroller för att säkerställa att data kommer fram i rätt ordning och utan förlust.

TCP använder sig av segmentering för att dela upp data i mindre enheter för överföring och använder också kvittenser och återsändning vid eventuell dataförlust. Det erbjuder också flödeskontroll och fönsterstorleksförhandling för att optimera dataöverföringen. TCP används ofta för applikationer där tillförlitlighet och ordning är viktiga, till exempel webbläsning, filöverföring och e-post.

Bild 1 visar TCP-headern och dess olika fält som används för att specificera kommunikationskontrollerna. TCP-version 4 använder en 32-bitars header som räknas från 0 till 31. Headern representeras som en tabell med flera fält per rad, där varje rad består av 32 bitar uppdelade i ett antal fält. Som ett exempel kan vi titta på den första raden som är uppdelad i två fält, vardera med 16 bitar. Dessa fält används för att ange källans och destinationens portnummer.

Här är en mer detaljerad beskrivning av varje fält i TCP-headern:

Source Port Number: Detta 16-bitars fält identifierar källans portnummer, det vill säga porten på avsändarsidan av TCP-kommunikationen. Det används för att ange avsändarapplikationen eller processen.
Destination Port Number: Även detta 16-bitars fält, precis som källportsfältet, anger destinationens portnummer. Det specificerar porten på mottagarsidan av TCP-kommunikationen och indikerar mottagarapplikationen eller processen.
Sequence Number: Detta 32-bitars fält används för att ordna TCP-segmenten i rätt ordning vid mottagaren. Avsändaren sätter Sekvensnumret till den första byten i segmentet och ökar det för varje efterföljande segment.
Acknowledge Number: Mottagaren sätter kvittens numret till nästa förväntade sekvensnummer som den förväntar sig ta emot. Det används i kombination med ACK-flaggan för att indikera att data har tagits emot korrekt.
Header Length: oftast förkortad som HLEN, indikerar längden på TCP-headern och mäts i multipel av 32 bitar (4 byte). HLEN i TCP-header består av 4 bitar, vilket ger 16 olika kombinationer (2^4 = 16, räknat från 0 till 15). Därför blir den maximala längden på headern 60 byte (4 x 15) eller (1111 = 15 x 32 = 480/8). Detta fält är även känt som ”DATA OFFSET”.En vanligt förekommande värde i detta fält är 5 (0101), vilket motsvarar en längd på 20 byte (4 x 5 eller 32 x 5 = 160/8).
Reserved: Dessa 6-bitars fält är reserverade för framtida användning och är för närvarande inte använda. De ska vara nollor.
Flags: CODE bits eller flaggor (9 bitar) används för att hantera handskakning. Här är några av de vanligaste flaggorna:
- Urgent – URG indikerar att det finns data av brådskande karaktär i segmentet.
- Acknowledgement – ACK indikerar att kvittensenumret är giltigt och att data har tagits emot korrekt.
- Push – PSH Det är TCP som ansvarar för att avgöra när data ska skickas ut, vilket gör att TCP har möjlighet att samla ihop data i en buffertminne innan de skickas iväg. Däremot kan en applikation ovanför TCP skicka kommandot ”push”, vilket instruerar TCP att omedelbart skicka data utan att buffra den temporärt. När detta inträffar, sätts PSH-flaggan till 1.
- Reset – RST används för att återställa en TCP-anslutning eller signalera ett felaktigt tillstånd.
- Synchronization – SYN Används vid uppkoppling för att initiera en anslutning mellan avsändaren och mottagaren.
- Finish – FIN Används för att stänga en TCP-anslutning.
- RST, SYN och FIN används vid upp- och ned koppling av en förbindelse.
Window Size: Detta 16-bitars fält specificerar antalet bytes som avsändaren är beredd att ta emot från mottagaren innan den vill ha en bekräftelse. Det används för att hantera flödeskontroll och reglera dataflödet mellan avsändaren och mottagaren.
Urgent Pointer: Urgent data överförs utan flödeskontroll, men fältet ”Urgent Pointer” brukar inte användas.
Options: Detta fält används för att bära eventuella tillval och specialfunktioner som kan behövas under TCP-kommunikationen. Det kan innehålla olika typer av tillval som alternativa maximala segmentstorlekar (MSS), tidstämplar och mer.

TCP-session initiering

TCP-session initiering och terminering är en viktig process för att säkerställa en pålitlig dataöverföring mellan klient och server. Det innebär att tre paket utväxlas mellan de båda parterna för att etablera och avsluta kommunikationen. Denna process, känd som TCP-handshake, garanterar att båda parter är synkroniserade och redo att överföra data. Handskakningen är en enkelriktad process som startas av klienten.

De tre stegen i TCP-handskakningen illustreras med följande bild:

De tre stegen i TCP-handskakningen:

Klienten initierar handskakningen genom att skicka ett segment med ett sekvensnummer (SEQ=100). Detta synkroniserar kommunikationen och säkerställer att både avsändaren och mottagaren är på samma sida.
Servern svarar med en kombination av ACK och SYN-flaggor. SEQ=300 anger den byte som servern skickar. ACK=101 indikerar att 100 byte har tagits emot och att det önskas överföring av ytterligare 100 byte.
Klienten svarar med en ACK-signal satt till 301 och bekräftar att 300 byte har mottagits korrekt.

Genom att följa dessa tre steg etableras en TCP-session mellan klienten och servern, vilket möjliggör den pålitliga överföringen av data. Vid avslutningen av sessionen används även en specifik termineringsprocess för att säkerställa att båda parterna avslutar kommunikationen korrekt.

TCP-session terminering

För att avsluta uppkopplingen används en tvåvägshandskakning där flaggor i TCP-segmentets header styr nedkopplingen. Här är en kortfattad förklaring av de steg som sker:

SYN – synkroniserar initiering av en session
ACK – kvittenser av mottagna segment
FIN – avslutar en session
RST – avbryter en session på grund av något fel

Klienten skickar ett segment till servern med flaggan FIN satt till ett för att signalera att den inte har mer data att skicka.
Servern svarar med en ACK-signal för att bekräfta mottagandet av klientens FIN-segment.
Servern skickar ett segment till klienten med flaggan FIN satt till ett för att signalera att den inte heller har mer data att skicka.
Klienten svarar med en ACK-signal för att bekräfta mottagandet av serverns FIN-segment och avsluta uppkopplingen.

Genom att använda dessa flaggor och utväxlingen av ACK-signaler kan klienten och servern säkert och ordnat avsluta TCP-sessionen.

TCP segmentering

För att säkerställa att det överförda meddelandet kan förstås av mottagaren, monteras de mottagna segmenten ihop i den ursprungliga ordningen. Detta åstadkoms med hjälp av sekvensnummer som tilldelas varje segment för att nå sin destination.

Vid sessionens start sätts ett initialt sekvensnummer (ISN). Detta ISN fungerar som utgångsvärdet för varje överförd byte. Medan data överförs ökar sekvensnumret i enlighet med antalet levererade byte. Denna sekvens av databyten gör det möjligt att identifiera och montera varje segment i rätt ordning vid mottagaren.

Den mottagande TCP-processen placerar data från varje segment i en mottagningsbuffert. Segmenten kan ha anlänt i olika ordning på grund av olika ankomsttider. Segmenten bearbetas sedan i mottagningsbufferten på destinationsadressen. De ordnas i rätt ordning innan de skickas vidare till applikationsskiktet. Under denna process stämplas alla segment med relevanta tidsinformation för att hjälpa till med bearbetningen.

TCP flödeskontroll med kvittensnummer

TCP använder sig av kvittensnummer för att säkerställa att dataleveransen är korrekt och för att hantera flödeskontroll. Genom att tilldela sekvensnummer till varje segment kan TCP-mottagaren bekräfta vilka segment som har kommit fram och vilka som behöver sändas om.

Kvittensnumret används av mottagaren för att indikera vilket sekvensnummer som förväntas i nästa segment i sessionen (förväntad kvittens). När mottagaren tar emot och bekräftar korrekt leverans av ett segment, förväntas avsändaren skicka nästa segment med ett sekvensnummer som matchar det förväntade kvittensnumret. Genom att utbyta både sekvensnummer och kvittensnummer i båda riktningarna kan TCP säkerställa att data överförs korrekt och i rätt ordning.

Denna kombination av sekvensnummer och kvittensnummer möjliggör en tillförlitlig och effektiv flödeskontroll i TCP-kommunikationen. Genom att noggrant hantera kvittensnummer kan avsändaren anpassa sitt sändningstempo och undvika överbelastning av mottagaren.

TCP flödeskontroll med Fönsterstorlek eller Windowing

Utöver kvittensnumret använder TCP en metod som kallas ”fönsterstorlek” eller ”Windowing” för att utnyttja mottagarens effektiva bearbetningskapacitet. Denna metod kan ställas in vid etableringen av en TCP-session eller ändras dynamiskt under sessionens gång, vilket bidrar till att minska behovet av att skicka om data.

Avsändaren anpassar storleken på mottagarens fönster genom att skicka olika mängder data till mottagaren. När avsändaren har verifierat att mottagaren kan hantera den överförda datamängden inom en viss fönsterstorlek, fortsätter dataöverföringen.

Fönsterstorleken specificeras i ett fält i TCP-huvudet, där den angivna mängden data indikerar hur mycket som kan överföras innan en bekräftelse behövs. Den ursprungliga fönsterstorleken bestäms under handskakningen vid sessionens start.

En vanlig situation där fönsterstorleken justeras dynamiskt är när nätverksförhållandena förändras under en pågående session. TCP kan då anpassa fönsterstorleken för att optimera dataöverföringen och minimera förlust av paket eller överbelastning.

Genom att använda fönsterstorleken som en mekanism för att anpassa dataöverföringen efter mottagarens kapacitet kan TCP säkerställa effektiv och tillförlitlig kommunikation. Vi studerar bilden nedan:

I detta exemplet en dataström inte når mottagaren. De två första 1500 byte skickas framgångsrikt och kvitteras av mottagaren med en ACK på 3001. Avsändaren antar att det är säkert att skicka ytterligare 3000 byte, vilket delas upp i två olika dataströmmar på 1500 byte. Tyvärr når den ena dataströmmen inte mottagaren, medan den andra tas emot korrekt. När mottagaren kvitterar med samma ACK-värde, det vill säga 3001, tolkar avsändaren det som att mottagaren har inte mottagit dataströmmen och därför den återsänder.

Långsammare dataöverföringen

Om avsändaren önskar en långsammare dataöverföring krävs fler kvittenser för att reglera hastigheten. Detta innebär att avsändaren måste vänta på en kvittens innan en ny dataöverföring kan ske, vilket saktar ner överföringshastigheten. Å andra sidan kan mottagaren skicka en kvittens för en mindre mängd data än vad som begärts. Detta tolkas som en signal om mottagarens aktuella buffertkapacitet. Avsändaren anpassar då fönsterstorleken enligt mottagarens kvittens. Sedan, när ingen dataförlust verifieras, kan avsändaren successivt öka fönsterstorleken tills det uppstår dataförlust, varvid överföringen justeras igen.

TCP återsändning

Dataförlust kan förekomma i nätverk trots dess design och prestanda. Ett tillförlitligt protokoll som TCP tillhandahåller säkerhetsmekanismer för att hantera sådana förluster. En viktig mekanism är användningen av kvittenser och återsändning av förlorade data. När destinationen mottar data kvitteras endast de leveranser som har utförts korrekt. Om vissa leveranser inte kvitteras, initierar avsändaren en återsändning av de osäkra datasegmenten.

Avsändaren lagrar en kopia av de överförda segmenten i sin dators buffert i väntan på kvittenser. Varje kopia är tids stämplad med en nedräkningstimer. Om ingen kvittens tas emot innan timern når noll, skickas kopiorna igen. Om kvittens tas emot tas de motsvarande kopiorna bort från bufferten.

Om nätverket stöder funktionen ”Selective Acknowledgements” kan en icke-kontinuerlig kvittens accepteras. Detta innebär att kvittens kan ges för flera leveranser på en gång, inklusive den sista leveransen. När avsändaren tar emot denna kvittens kan den kontrollera vilka leveranser som inte har utförts och sända om de förlorade segmenten.

UDP

UDP (User Datagram Protocol) är ett enkelt transportprotokoll som används för att skicka data över nätverk. Till skillnad från TCP saknar UDP vissa av de styrmekanismer och funktioner som TCP erbjuder, såsom säkerhetsmekanismer, återsändning av data och flödeskontroll. Det gör UDP till ett snabbare och mer effektivt protokoll för vissa typer av applikationer där tillförlitlighet inte är lika viktig.

UDP är ett förbindelselöst protokoll, vilket innebär att det inte kräver någon uppkopplingsprocess mellan avsändare och mottagare innan dataöverföring kan ske. Detta gör att UDP är snabbare än TCP.

Trots att UDP saknar vissa säkerhetsmekanismer är det fortfarande användbart för många applikationer. Det används ofta för realtidsapplikationer där snabb överföring av data är viktigare än att garantera att varje datapaket når fram. Exempel på sådana applikationer inkluderar röst- och videokommunikation, strömning av media och spel. Här nedan en kort lista på applikationer som använder UDP:

Domain Name System (DNS)
Simple Network Management Protocol (SNMP)
Dynamic Host Configuration Protocol (DHCP)
Routing Information Protocol (RIP)
Trivial File Transfer Protocol ( TFTP )
Online-spel

Det är viktigt att notera att säkerhetsfunktioner kan implementeras på applikationsnivå ovanpå UDP om det behövs. Applikationer kan använda egna mekanismer för felkontroll, flödeskontroll och hantering av förlorade eller duplicerade paket om det är nödvändigt för deras specifika behov.

Nätverksteknologier CCNA1