TCP

Virkemåten til TCP i detalj

TCP forbindelser har tre faser: opprettelsen av en forbindelse, dataoverføringen og tilslutt avslutningen av forbindelsen. Et treveis håndtrykk blir brukt for å opprette en forbindelse. Et fireveis håndtrykk blir brukt for å avslutte en forbindelse. I opprettelsesfasen av en forbindelse vil parametre som sekvensnummer bli initialisert for å oppnå riktig rekkefølge på pakkene og robusthet.

Opprettelse av en forbindelse (treveis håndtrykk)

Selv om det er mulig for to endepunkter å åpne en forbindelse mellom hverandre samtidig, så vil dette typisk
skje ved at ene enden åpner en socket og venter passivt på at noen skal koble seg til. Dette blir ofte 
kalt passiv åpning og er typisk for tjener-enden av en forbindelse. Klientsiden av en forbindelse utfører
en aktiv åpning ved å sende et TCP segment med SYN flagget satt til tjeneren som en del av 3-veis håndtrykket. 
Tjenersiden skal da besvare en gyldig SYN forespørsel med SYN/ACK. Til slutt så skal klientsiden av forbindelsen
svare tjeneren med et ACK som fullfører treveis håndtrykket og opprettelsen av en forbindelse.

Dataoverføring

I dataoverføringsfasen har TCP noen mekanismer som avgjør grad av robusthet og pålitlighet. 
Et sekvensnummer brukes for å ordne segmentene i riktig rekkefølge, og for å detektere dupliserte data. Sjekksummer
brukes for å detektere feil i segmentene. Kvitteringer og tidsavbrudd brukes for å detektere feil og for å tilpasse
TCP ved tap av segmenter eller ved forsinkelse. 
I opprettelsesfasen utveksles innledende sekvensnummer mellom de to endepunktene. Disse sekvensnummerne blir brukt
til å identifisere hvert enkelt tegn i strømmen av tegn. Det er alltid et par av sekvensnummer i hvert TCP-segment. Disse blir referert til som henholdsvis sekvensnummeret og kvitteringsnummeret. En TCP-sender refererer til sitt eget sekvensnummer som sekvensnummer og mottakers  sekvensnummer som kvitteringsnummer. For å opprettholde pålitlighet, kvitterer en mottaker et TCP-segment ved å indikere at alle tegn fram til et gitt tegn i den kontinuerlige tegnstrømmen er mottatt. En utvidelse av TCP, kalt SACK (Selective Acknowledgements), tillater en TCP-mottaker å kvittere for blokker av tegn som ikke er i rekkefølge.
Dette gjør at hvis et enkelt tegn i strømmen går tapt så kan TCP kvittere for tegn før dette, og dermed unngå at alle disse tegna må sendes på nytt. 
Gjennom bruken av sekvens- og kvitteringsnummer kan TCP levere segmenter i korrekt rekkefølge til mottakerapplikasjonen. Sekvens- og kvitteringsnummer er 32-biters positive heltall som vil rulle rundt til 0 ved det neste tegnet i strømmen etter 2³²-1.
En 16-bit sjekksum som består av ener-komplementet til ener-komplement summen av innholdet i hodet og datadelen fra
TCP-segmentet blir kalkulert av senderen og inkludert i segmentet når det sendes.
TCP-mottakeren kalkulerer sjekksummen av TCP-hodet og datadelen som er mottatt, og hvis denne ikke avviker fra 
sjekksummen senderen kalkulerte så antas segmentet å være intakt og uten feil. 
TCP-sjekksummen er ganske svak i forhold til moderne standarder. Datalinklag med stor sannsynlighet for bitfeil,
krever gjerne bedre evne til å korrigere og påvise feil. Hvis TCP skulle bli konstruert på nytt i dag ville mest
sannsynlig en 32-bit syklisk redundanssjekk (CRC) spesifisert som en feilsjekk blitt brukt i stedet for sjekksummen. Den svake sjekksummen er delvis kompensert for ved bruken av CRC eller bedre integritetssjekk
på datalink-laget, under både TCP og IP, slik som for eksempel i en PPP- eller Ethernet-ramme. Imidlertid betyr
ikke dette at 16 bit-sjekksummen til TCP er redundant. Undersøkelser av internettrafikk har vist at programvare-
og maskinvarefeil som introduserer feil i pakker mellom CRC-beskytta hopp er vanlige, og at TCP-sjekksummen
fanger opp de fleste av slike enkle feil. Dette er et eksempel på ende-til-ende-prinsippet. 
Kvitteringer for tegn som er sendt, eller fravær av kvitteringer, blir brukt av sendere for å implisitt lære om
tilstanden på nettverket mellom TCP-avsender og -mottaker. Dette sammen med tidtakere gjør at TCP-sendere og -mottakere kan endre oppførselen til flyten av tegn. Dette kalles vanligvis flytkontroll, metningskontroll og/eller metningsunngåelse. TCP bruker et antall mekanismer for å oppnå både robusthet og høy ytelse. 
Disse mekanismene inkluderer bruken av et sliding window, slow-start algoritmen, congestion avoidance algoritmen, fast retransmit og fast recovery algoritmene, og så videre. Utvidelser av TCP for å pålitelig kunne håndtere tap, minimalisere feil, håndtere metning og ha en høy overføringshastighet i nettverk med svært høy kapasitet
er områder det forskes på og utvikles standarder for.

Avslutning av en forbindelse (4-veis håndtrykk)

I denne fasen benyttes et 4-veis håndtrykk. Hver ende av forbindelsen avslutter uavhengig av hverandre. 
For hvert endepunkt som lukker forbindelsen kreves et par med FIN og ACK segmenter.

TCP-porter

TCP bruker portnummer for å identifisere sender- og mottakerapplikasjoner. Applikasjonen på hver side 
av en TCP-forbindelse får tildelt et 16-bit unsigned portnummer. Porter er kategorisert i 3 grunnleggende kategorier: kjente, registrerte, og dynamiske/private. De kjente portene er tildelt av 
Internet Assigned Numbers Authority (IANA) og er typisk brukt av systemnivå
eller rotprosesser. Velkjente applikasjoner som kjører som tjenere og venter passivt på tilkoblinger fra
klienter bruker typisk disse portene. Noen eksempler på slike er: FTP (21), Telnet (23), SMTP (25) og HTTP (80).
Registrerte porter blir typisk brukt av brukerapplikasjoner som midlertidige kildeporter når 
tjenere kontaktes, men disse portene kan også identifisere kjente tjenester registrert av en tredjepart. 
Dynamiske/private porter kan også bruke av sluttbrukerapplikasjoner, men blir ikke så ofte brukt på den måten. 
Dynamiske/private porter har ingen mening utenfor en bestemt TCP-forbindelse. TCP-portnummeret lagres i 
et felt på 16-bit i TCP-hodet, og 65535 porter er dermed tilgjengelige.

Utviklingen av TCP

TCP er en kompleks protokoll og fortsatt under utvikling. Selv om betydelige utvidelser har blitt gjort og foreslått siden TCP ble dokumentert i RFC 793 i 1981, har den grunnleggende funksjonaliteten få endringer.
RFC 1122, Host Requirements for Internet Hosts, oppklarte noen implementasjonskrav for TCP protokollen. RFC 2581, TCP Congestion Control som er en av de viktigste TCP relaterte RFCene i de senere år
beskriver oppdaterte algoritmer for å unngå urimelig metning. I 2001 ble RFC 3168 publisert som beskriver 
explicit congestion notification (ECN) som er en mekanisme for å varsle om metning i nettverket. I dag brukes
TCP til tilnærmet 95% av all Internett trafikk. Vanlige applikasjoner som bruker TCP er blant annet  HTTP/HTTPS
(world wide web), SMTP/POP3/IMAP (e-post) og FTP (filoverføring). Den vidstrakte bruken vitner om at de 
opprinnelige utviklerne gjorde en svært god jobb.

Alternativer til TCP

TCP er imidlertid ikke like godt egnet til alle applikasjoner. Derfor har nyere transportlags-protokoller blitt utviklet for å takle noen av svakhetene. For eksempel trenger sanntidsapplikasjoner ofte ikke, og vil 
lide av TCP's pålitelige leveringsmekanismer. I slike applikasjoner er det ofte bedre å ha litt tap, feil eller
metning enn å prøve å tilpasse seg. Noen eksempler på slike applikasjoner er sanntids-strømmer av multimedia
(som Internett-radio), sanntidsspill og IP-telefoni. Slike applikasjoner kan velge å bruke
andre transportlagsprotokoller som for eksempel User Datagram Protocol (UDP), Stream Control Transmission Protocol SCTP), eller Datagram Congestion Control Protocol (DCCP)