Protokoll for overføringskontroll

Transmission Control Protocol (bokstavelig talt " Transmission Control Protocol "), forkortet TCP , er en pålitelig transportprotokoll med tilkoblet modus dokumentert i IETF RFC  793.

I Internett-modellen , også kjent som TCP / IP-modellen, ligger TCP over IP. I OSI- modellen tilsvarer det transportlaget , mellomliggende nettverkslaget og øktlaget . Applikasjonene overfører datastrømmer over en nettverkstilkobling. TCP deler byte- strømmen i segmenter hvis størrelse avhenger av MTU til det underliggende nettverket ( datalinklag ).

TCP ble utviklet i 1973 og vedtatt for Arpanet i 1983, og erstattet NCP ( RFC  801).

Operasjon

En TCP-økt fungerer i tre faser:

Forbindelsen opprettes ved en tretrinns håndtrykk . Å bryte forbindelsen bruker fire-trinns håndtrykk . I løpet av tilkoblingsfasen initialiseres parametere som sekvensnummer for å sikre pålitelig overføring (tapsfri og i rekkefølge) av data.

Struktur av et TCP-segment

I biter

0 1 2 3 4 5 6 7 8 9 10 11 12 1. 3 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Kildeport 2 byte Destinasjonsport 2 byte
Sekvensnummer
Kvitteringsnummer
Toppstørrelse reservere ECN / NS CWR ECE URG ACK PSH RST SYN SLUTT Vindu
Sjekksum Haster datapekeren
Alternativer Fylling
Data

Betydningen av feltene:

Opprette en forbindelse

Selv om det er mulig for to systemer å opprette en forbindelse mellom dem samtidig, åpner generelt sett et system en ' kontakt ' (tilgangspunkt til en TCP-forbindelse) og venter passivt på tilkoblingsforespørsler fra et annet system. Denne operasjonen blir ofte referert til som passiv åpen , og brukes av serversiden av forbindelsen. Den klient side av forbindelses utfører en aktiv åpning i 3 faser:

  1. Klienten sender et SYN-segment til serveren,
  2. Serveren svarer med et SYN / ACK-segment,
  3. Kunden bekrefter med et ACK-segment.

Under denne første utvekslingen synkroniseres sekvensnumrene til de to partiene:

  1. Klienten bruker sitt opprinnelige sekvensnummer i "Sekvensnummer" -feltet i SYN-segmentet (for eksempel x),
  2. Serveren bruker sitt opprinnelige sekvensnummer i "Sekvensnummer" -feltet i SYN / ACK-segmentet (for eksempel y) og legger til klientens sekvensnummer pluss en (x + 1) i feltet "Bekreftelsesnummer".
  3. Klienten bekrefter ved å sende en ACK med et sekvensnummer økt med en (x + 1) og et kvitteringsnummer som tilsvarer sekvensnummeret til serveren pluss en (y + 1).

Dataoverføring

I løpet av dataoverføringsfasen sikrer visse viktige mekanismer robustheten og påliteligheten til TCP. Spesielt blir sekvensnumre brukt for å bestille mottatte TCP-segmenter og for å oppdage tapte data, sjekksummer tillater feiloppdagelse, og bekreftelser og tidsavbrudd tillater deteksjon av tapte eller forsinkede segmenter.

Sekvens- og kvitteringsnummer

Takket være sekvens- og bekreftelsesnumrene kan terminalsystemene levere mottatte data for mottakerprogrammet.

Sekvensnumre brukes til å telle dataene i byte-strømmen. Det er alltid to av disse tallene i hvert TCP-segment, som er sekvensnummeret og bekreftelsesnummeret . Den sekvensnummer representerer TCP avsender eget sekvenstall, mens den erkjennelse tallet representerer mottakerens sekvensnummer. For å sikre påliteligheten av TCP, må mottakeren anerkjenne de mottatte segmentene, noe som indikerer at den har mottatt alle dataene fra byte-strømmen opp til et bestemt sekvensnummer.

Sekvensnummeret indikerer den første byten av dataene.

For eksempel i tilfelle bytte av segmenter av Telnet  :

  1. Vert A sender et segment til vert B som inneholder en byte med data, et sekvensnummer lik 43 (Seq = 43) og et kvitteringsnummer lik 79 (Ack = 79),
  2. Vert B sender en ACK til verten A. Sekvensnummeret til segmentet tilsvarer bekreftelsesnummeret til verten A (Seq = 79), og bekreftelsesnummeret i sekvensnummeret A som mottatt av B, økt med mengden av data i mottatte byte (Ack = 43 + 1 = 44),
  3. Vert A bekrefter mottakelsen av segmentet ved å sende en ACK til verten B, med sekvensnummeret til det nye sekvensnummeret , nemlig 44 (Seq = 44), og som antall bekreftelser økte sekvensnummer- segmentet tidligere med mengden av mottatte data (Ack = 79 + 1 = 80).

Sekvensnummer er 32-biters usignerte heltall som går tilbake til null etter å ha nådd (2 ^ 32) -1. Valget av det første sekvensnummeret er en av nøklene til robustheten og sikkerheten til TCP-tilkoblinger.

En forbedring i TCP, kalt selektiv bekreftelse (SACK), gjør det mulig for TCP-mottakeren å bekrefte blokker med data som er mottatt utenfor ordre.

Sjekksum

En sjekksum på 16 bits, bestående av komplementet til summen komplementert til alle elementene i et TCP-segment (overskrift og data) beregnes av senderen og inkluderes i det sendte segmentet. Mottakeren beregner kontrollsummen til det mottatte segmentet på nytt, og hvis den samsvarer med den mottatte kontrollsummen, anses segmentet å være mottatt intakt og uten feil.

Tidsforsinkelse

Tap av et segment håndteres av TCP ved hjelp av en timeout- og retransmisjonsmekanisme. Etter å ha sendt et segment, vil TCP vente en viss tid på å motta den tilsvarende ACK. For kort tid resulterer i et stort antall unødvendige retransmissjoner og for lang tid bremser reaksjonen i tilfelle tap av et segment.

Faktisk må forsinkelsen før retransmissjon være større enn gjennomsnittet RTT for et segment, det vil si den tiden det tar av et segment å gjøre tur-retur mellom klienten og serveren. Ettersom denne verdien kan variere over tid, blir "prøver" tatt med jevne mellomrom, og et vektet gjennomsnitt beregnes:

RTT moyen = (1-) * RTT moyen + * RTT échantillon

En typisk verdi for er 0,125. Påvirkning av prøver avtar eksponentielt over tid.

Forsinkelsen som skal brukes oppnås fra dette estimatet av gjennomsnittlig RTT og ved å legge en sikkerhetsmargin til den. Jo større forskjell mellom et utvalg og gjennomsnittet, jo større sikkerhetsmargin kan forventes. Beregningen er laget fra den vektede avviket mellom prøven og gjennomsnittet:

Variance RTT = (1-) * Variance RTT + * |RTT échantillon - RTT moyen|

En typisk verdi for er 0,25. Fristen for bruk er endelig gitt av følgende formel:

Délai = RTT moyen + 4 * Variance RTT

Den Karn algoritme gjør det mulig å bedre evaluere forsinkelsen i nærvær av tvetydige bekreftelser . Faktisk, hvis et sendt segment har gått tapt, vil de påfølgende segmentene forårsake bekreftelser der nummeret på den første manglende byten vil vises, og det er derfor ikke lenger kjent hvilket sendesegment disse bekreftelsene tilsvarer.

Noen ganger når forsinkelsen er for lang, er det gunstig å ikke vente før du overfører et segment på nytt. Hvis en vert mottar 3 ACK-er for det samme segmentet, anser den at alle segmentene som sendes etter at det anerkjente segmentet er tapt, og sender dem derfor på nytt umiddelbart ( Fast retransmits ).

Flytkontroll

Hver partner i en TCP-forbindelse har en mottaksbuffer, hvis størrelse ikke er ubegrenset. For å forhindre at en vert overbelaster den andre, gir TCP flere strømningskontrollmekanismer. Dermed inneholder hvert TCP-segment størrelsen som er tilgjengelig i mottaksbufferen til verten som sendte den. Som svar vil den eksterne verten begrense størrelsen på sendevinduet for ikke å overbelaste det.

Andre algoritmer som Nagle eller Clarck letter også strømningskontroll.

Trengselskontroll

Overbelastning oppstår når for mange kilder prøver å sende for mye data for fort til at nettverket kan overføre dem. Dette resulterer i tap av mange pakker og lange forsinkelser.

Bekreftelsene av de overførte dataene, eller fraværet av bekreftelser, brukes av senderne til å implisitt tolke nettverkets tilstand mellom sluttsystemene. Ved å bruke tidsavbrudd kan TCP-avsendere og mottakere endre atferden til dataflyten. Dette er vanligvis referert til som overbelastningskontroll.

Det er en rekke algoritmer for å unngå overbelastning for TCP .

Annen

TCP bruker en rekke mekanismer for å oppnå god robusthet og høy ytelse. Disse mekanismene inkluderer bruk av et skyvevindu, algoritmen for langsom start, algoritme for å unngå overbelastning , hurtiggjenutsending og rask gjenopprettingsalgoritmer ( rask gjenoppretting ), etc. Forskning pågår for tiden for å forbedre TCP for effektivt å håndtere tap, minimere feil, håndtere overbelastning og være rask i miljøer med høy hastighet.

Treg start

Slow start (TCP) er en algoritme som balanserer hastigheten til en nettverkstilkobling. Langsom start øker gradvis mengden data som overføres til den finner den maksimale transportkapasiteten til nettverket.

Langsom start av TCP er et av de første trinnene i prosessen med overbelastningskontroll. Den balanserer mengden data som en sender kan overføre (kalt overbelastningsvinduet) og mengden data som mottakeren kan akseptere (kalt mottaksvinduet). Den nedre av de to verdiene blir den maksimale datamengden avsenderen har lov til å overføre før den mottar en bekreftelse fra mottakeren.

En av de vanligste måtene å optimalisere hastigheten på en forbindelse er å øke hastigheten på koblingen (det vil si å øke mengden båndbredde). Enhver kobling kan imidlertid bli overbelastet hvis en enhet prøver å sende for mye data. Overmetning av en lenke er kjent som overbelastning og kan føre til langsom kommunikasjon og til og med tap av data.

Rask overføring

Rask retransmit er en forbedring av TCP som reduserer tiden en avsender venter før den sender et tapt segment på nytt. En TCP-avsender bruker normalt en enkel tidtaker for å gjenkjenne tapte segmenter. Hvis det ikke mottas en bekreftelse for et bestemt segment innen en spesifisert tid (basert på estimert tur / retur-tid), vil avsenderen anta at segmentet har gått tapt i nettverket og sende det på nytt.

Kopiering av duplikat er grunnlaget for den hurtige retransmisjonsmekanismen. Etter å ha mottatt en pakke, sendes en bekreftelse for den siste mottatte databyen i rekkefølge. For en bestilt pakke er dette faktisk sekvensnummeret til den siste pakken pluss nyttelastlengden til den nåværende pakken. Hvis den neste pakken i sekvensen går tapt, men en tredje pakke i sekvensen blir mottatt, kan mottakeren bare bekrefte den siste byten av data i rekkefølge, som har samme verdi som bekreftelsen av den første pakken. Den andre pakken går tapt, og den tredje pakken er ute av drift, så den siste byten med data i rekkefølge forblir den samme som før. Det er derfor en dobbel erkjennelse. Avsenderen fortsetter å sende pakker, og en fjerde og en femte pakke blir mottatt av mottakeren. Igjen mangler den andre pakken i sekvensen, så den siste byten av data i rekkefølge har ikke endret seg. Du får duplikatbekreftelser for disse to pakkene.

Når en avsender mottar tre like bekreftelser, kan det være rimelig sikkert at segmentet som bærer dataene som fulgte den siste kontrollbyten som ble spesifisert i bekreftelsen, er tapt. En avsender med rask videresending vil deretter videresende denne pakken umiddelbart uten å vente på at den utløper. Ved mottak av det overførte segmentet, kan mottakeren bekrefte mottakelsen av den sist mottatte databyten. I eksemplet ovenfor vil dette bekrefte mottakelse til slutten av nyttelasten til den femte pakken. Det er ikke nødvendig å anerkjenne mellompakker, siden TCP som standard er kumulative anerkjennelser.

Avslutte en forbindelse

Avslutningsfasen for en forbindelse bruker fire-trinns håndtrykk, hvor hver ende av forbindelsen avsluttes uavhengig. Dermed krever avslutning av en forbindelse et par FIN- og ACK-segmenter for hver ende.

TCP-porter

TCP, som UDP , bruker portnummeret til å identifisere applikasjoner. Hver ende ( klient / server ) av TCP-tilkoblingen er tilknyttet et 16-biters portnummer (fra 1 til 65535) som er tilordnet sendings- eller mottaksapplikasjonen. Disse portene er klassifisert i tre kategorier:

  • De kjente portene er tildelt av IANA ( Internet Assigned Numbers Authority ) i området 0-1023, og brukes ofte av systemprosesser eller har privilegerte rettigheter. Kjente applikasjoner som fungerer som en server og venter på tilkoblinger, bruker vanligvis denne typen porter. Eksempler: FTP (21), SSH (22), Telnet (23), SMTP (25), HTTP (80), POP3 (110).
  • Registrerte porter brukes vanligvis av brukerapplikasjoner som kortvarige kildeporter for å koble til en server, men de kan også identifisere tjenester som ikke er registrert av IANA.
  • De dynamiske / private portene kan også brukes av brukerapplikasjoner, men sjeldnere. De gir ikke mening utenfor en bestemt TCP-forbindelse.

TCP utvikling

Det amerikanske forsvarsdepartementet (DoD) utviklet opprinnelig TCP / IP-referansemodellen fordi den trengte et nettverk som kunne tåle enhver situasjon.

TCP er en ganske kompleks og utviklende protokoll. Selv om det har blitt gjort betydelige forbedringer gjennom årene, har den grunnleggende driften endret seg lite siden RFC 793 , publisert i 1981 . Den RFC  1122 ( Host Krav til Internett-verter ) avklart en rekke forutsetninger for gjennomføring av TCP-protokollen. Den RFC  2581 ( TCP Congestion kontroll ), en av de viktigste i de siste årene, beskriver nye algoritmer som brukes av TCP for å unngå overbelastning. I 2001 ble RFC 3168 skrevet for å introdusere en eksplisitt overbelastningsvarslingsmekanisme (ECN), og legger til listen over viktige RFC-er som utfyller den opprinnelige spesifikasjonen.

Bruk av TCP

I begynnelsen av XXI th  århundre , er TCP brukes for ca 90% av all trafikk Internett . De vanligste applikasjonene som bruker TCP er HTTP / HTTPS ( World Wide Web ), SMTP / POP3 / IMAP (e-post) og FTP (filoverføring). Youtube og Netflix bruker også TCP for streamingstrømmene sine .

Alternativer til TCP

Mange applikasjoner i sanntid trenger ikke, og kan til og med lide, de komplekse mekanismene for pålitelig TCP-transport: multimedia-streaming-applikasjoner (lyd, video, spill for flere spillere) i sanntid, filutveksling osv. I denne typen applikasjoner er det ofte bedre å takle tap, feil eller overbelastning, i stedet for å prøve å unngå dem.

For disse spesielle behovene er andre transportprotokoller opprettet og distribuert.

  • UDP ( User datagram protocol ) brukes ofte når sanntid foretrekkes fremfor pålitelighet. I likhet med TCP tilbyr denne protokollen applikasjonsmultipleksering gjennom konseptet med porter, men fungerer i ikke-tilkoblet modus.
  • SCTP ( Stream Control Transmission Protocol ), protokoll som gir tjenester som ligner på TCP (pålitelighet, ombestilling av sekvenser og overbelastningskontroll), samtidig som det gir mulighet for kommunikasjon med flere mål som med UDP.
  • MPTCP ( Multipath TCP ) er et overlegg til TCP som samler forskjellige TCP-tilkoblinger (gjennom forskjellige nettverksgrensesnitt: GSM, Wifi, etc.), innenfor samme metaforbindelse ( RFC 6824 ). Denne operasjonen gjør det mulig å bruke alle tilgjengelige baner parallelt, og forbedrer derfor ytelsen og påliteligheten til en forbindelse betydelig.

Referanser

  1. (in) "  OVERGANGSKONTROLLPROTOKOLL  " Forespørsel om kommentarer nr .  793,September 1981.
  2. (i) Jon Postel, "  NCP / TCP overgangsplan  " Request for Comments n o  801,November 1981.
  3. (in) "  The Addition of Explicit Congestion Notification (ECN) to IP  " Forespørsel om kommentarer nr .  3168,September 2001.
  4. (in) "  Robust Explicit Congestion Notification (ECN) Signaling with Nuncios  " Forespørsel om kommentarer nr .  3540Juni 2003.
  5. "  DARPA / ARPA - Defense / Advanced Research Project Agency  " , livinginternet.com (åpnet 19. januar 2011 )
  6. (i) "  Krav til Internett-verter - Kommunikasjonslag  " Forespørsel om kommentarer nr .  1122Oktober 1989.
  7. (in) "  TCP Congestion Control  " Forespørsel om kommentarer nr .  2581,April 1999.
  8. "  Pakke-nivå trafikkmålinger fra Sprint IP-ryggraden  " (åpnet 5. juni 2020 )
  9. "  Nettverksegenskaper for videostreamingstrafikk  " (åpnet 5. juni 2020 )

Se også

Relaterte artikler

Eksterne linker