Transport de fiabilitat TCP
Tots coneixem el protocol TCP com a protocol de transport fiable, però, com garanteix la fiabilitat del transport?
Per aconseguir una transmissió fiable, cal tenir en compte molts factors, com ara la corrupció de dades, la pèrdua, la duplicació i els fragments fora d’ordre. Si no es poden solucionar aquests problemes, no es pot assolir una transmissió fiable.
Per tant, TCP utilitza mecanismes com ara el número de seqüència, la resposta a l’acceptació, el control de reinici, la gestió de la connexió i el control de la finestra per aconseguir una transmissió fiable.
En aquest treball, ens centrarem en la finestra lliscant, el control del flux i el control de la congestió de TCP. El mecanisme de retransmissió es cobreix per separat a la secció següent.
Control de flux de xarxa
Control de flux de xarxa o Know, ja que el control del trànsit de xarxa és en realitat una manifestació de la relació subtil entre productors i consumidors. Probablement heu trobat aquest escenari molt a la feina o a les entrevistes. Si la capacitat del productor de produir supera molt la capacitat del consumidor de consumir, farà que la cua creixi indefinidament. En un cas més greu, és possible que sàpigues que quan els missatges RabbitMQ s’acumulen massa, pot provocar una degradació del rendiment de tot el servidor MQ. El mateix passa per TCP; Si es deixa de comprovar, hi haurà massa missatges a la xarxa i els consumidors hauran superat la seva capacitat, mentre que els productors continuaran enviant missatges duplicats, que afectaran molt el rendiment de la xarxa.
Per abordar aquest fenomen, TCP proporciona un mecanisme perquè l’emissor controli la quantitat de dades enviades en funció de la capacitat de recepció real del receptor, que es coneix com a control de flux. El receptor manté una finestra de recepció, mentre que l’emissor manté una finestra d’enviament. Cal destacar que aquestes finestres només són per a una sola connexió TCP i no totes les connexions comparteixen una finestra.
TCP proporciona el control de flux mitjançant una variable per a una finestra de recepció. La finestra de recepció proporciona a l’emissor una indicació de la quantitat d’espai de la memòria cau encara disponible. L’emissor controla la quantitat de dades enviades segons la capacitat d’acceptació real del receptor.
L’amfitrió del receptor notifica l’emissor de la mida de les dades que pot rebre i l’enviador envia a aquest límit. Aquest límit és la mida de la finestra, recordeu la capçalera TCP? Hi ha un camp de finestra de recepció, que s’utilitza per indicar el nombre d’octes que el receptor és capaç o disposat a rebre.
L’amfitrió del remitent enviarà periòdicament un paquet de sonda de finestra, que s’utilitza per detectar si l’amfitrió del receptor encara és capaç d’acceptar dades. Quan el buffer del receptor està en perill de desbordament, la mida de la finestra es defineix en un valor més petit per instruir a l’emissor que controli la quantitat de dades enviades.
Aquí teniu un diagrama de control de flux de xarxa:
Control de congestió de xarxa
Abans d’introduir el control de la congestió, hem d’entendre que, a més de la finestra de recepció i la finestra d’enviament, també hi ha una finestra de congestió, que s’utilitza principalment per resoldre el problema de quina velocitat comença l’enviador a l’enviament de dades a la finestra de recepció. Per tant, la finestra de congestió també la manté el remitent TCP. Necessitem un algoritme per decidir quantes dades són adequades per enviar, ja que l’enviament de massa o massa dades no és ideal, d’aquí el concepte d’una finestra de congestió.
En el control de flux de xarxa anterior, el que vam evitar va ser que l’emissor omplís la memòria cau del receptor amb dades, però no sabíem què passava a la xarxa. Normalment, les xarxes informàtiques es troben en un entorn compartit. Com a resultat, pot haver -hi congestió de xarxa a causa de la comunicació entre altres amfitrions.
Quan la xarxa està congestionada, si es continua enviant un gran nombre de paquets, pot causar problemes com ara el retard i la pèrdua de paquets. Arribats a aquest punt, TCP retratarà les dades, però la retransmissió augmentarà la càrrega a la xarxa, donant lloc a retards més grans i més pèrdues de paquets. Això pot entrar en un cicle viciós i seguir cada cop més gran.
Així, TCP no pot ignorar el que està passant a la xarxa. Quan la xarxa està congestionada, TCP es sacrifica reduint la quantitat de dades que envia.
Per tant, es proposa el control de la congestió, que té com a objectiu evitar omplir tota la xarxa amb dades de l’emissor. Per regular la quantitat de dades que l’enviador hauria d’enviar, TCP defineix un concepte anomenat finestra de congestió. L’algoritme de control de la congestió ajustarà la mida de la finestra de congestió segons el grau de congestió de la xarxa, per tal de controlar la quantitat de dades enviades per l’emissor.
Què és una finestra de congestió? Què té a veure això amb la finestra d’enviament?
La finestra de congestió és una variable d'estat mantingut per l'emissor que determina la quantitat de dades que pot enviar el remitent. La finestra de congestió canvia dinàmicament segons el nivell de congestió de la xarxa.
La finestra d’enviament és una mida de finestra acordada entre l’emissor i el receptor que indica la quantitat de dades que pot rebre el receptor. La finestra de congestió i la finestra d’enviament estan relacionades; La finestra d'enviament sol ser igual al mínim de la congestió i les finestres receptores, és a dir, SWND = min (CWND, RWND).
La finestra de congestió canvia de la manera següent:
Si no hi ha congestió a la xarxa, és a dir, no es produeix un temps de retransmissió, la finestra de congestió augmenta.
Si hi ha congestió a la xarxa, la finestra de congestió disminueix.
L’emissor determina si la xarxa es congestiona observant si el paquet de reconeixement ACK es rep dins del temps especificat. Si l’emissor no rep el paquet d’acceptació d’ACK dins del temps especificat, es considera que la xarxa està congestionada.
A més de la finestra de congestió, és hora de discutir l'algoritme de control de la congestió TCP. L’algoritme de control de la congestió TCP consta de tres parts principals:
Inici lent:Inicialment, la finestra de congestió CWND és relativament petita i l’emissor augmenta la finestra de congestió exponencialment per adaptar -se ràpidament a la capacitat de la xarxa.
Evitació de la congestió:Després que la finestra de congestió superi un determinat llindar, l’emissor augmenta la finestra de congestió de manera lineal per alentir la taxa de creixement de la finestra de congestió i evitar la sobrecàrrega de la xarxa.
Recuperació ràpida:Si es produeix congestió, l’emissor redueix la finestra de congestió i entra a l’estat de recuperació ràpida per determinar la ubicació de la recuperació de la xarxa a través dels ACK duplicats rebuts, i continua augmentant la finestra de congestió.
Inici lent
Quan s’estableix una connexió TCP, la finestra de congestió CWND s’estableix inicialment en un valor MSS mínim (mida màxima del segment). D’aquesta manera, la tarifa inicial d’enviament és sobre els bytes MSS/RTT/segon. L’ample de banda real disponible sol ser molt més gran que MSS/RTT, de manera que TCP vol trobar la taxa d’enviament òptima, que es pot aconseguir mitjançant l’inici lent.
En el procés d’arrencada lenta, el valor de la finestra de congestió CWND s’inicialitzarà a 1 MSS, i cada vegada que es reconeix el segment de paquets transmès, el valor de CWND s’incrementarà per un MSS, és a dir, el valor de CWND es convertirà en 2 MSS. Després d'això, el valor de CWND es duplica per a cada transmissió amb èxit d'un segment de paquets, etc. El procés de creixement específic es mostra a la xifra següent.
Tot i això, la taxa d’enviament no sempre pot créixer; El creixement ha d’acabar alguna vegada. Aleshores, quan s’acaba la taxa d’enviament? L’inici lent acaba normalment l’augment de la taxa d’enviament d’una de diverses maneres:
La primera manera és el cas de la pèrdua de paquets durant el procés d’enviament de lent inici. Quan es produeix una pèrdua de paquets, TCP estableix la finestra de congestió de l’emissor CWND a 1 i reinicia el procés d’inici lent. Arribats a aquest punt, s’introdueix un concepte de llindar de start lent Ssthresh, el valor inicial del qual és la meitat del valor de CWND que genera pèrdua de paquets. És a dir, quan es detecta la congestió, el valor de Ssthresh és la meitat del valor de la finestra.
La segona manera és correlacionar directament amb el valor del llindar de lent lent ssthresh. Atès que el valor de Ssthresh és la meitat del valor de la finestra quan es detecta la congestió, es pot produir una pèrdua de paquets amb cada doblatge quan CWND és més gran que Ssthresh. Per tant, el millor és configurar CWND a SSTHRESH, cosa que farà que TCP canviï al mode de control de la congestió i el final de la lentitud.
L’última manera que l’inici lent pot acabar és si es detecten tres ACK redundants, TCP realitza una retransmissió ràpida i entra a l’estat de recuperació. (Si no està clar per què hi ha tres paquets ACK, s’explicaran per separat en el mecanisme de retransmissió.)
Evitació de la congestió
Quan TCP entra a l'estat de control de la congestió, CWND s'estableix a la meitat del llindar de congestió SSthresh. Això significa que el valor de CWND no es pot duplicar cada vegada que es rep un segment de paquets. En canvi, s’adopta un enfocament relativament conservador en què el valor de CWND s’incrementa només en un MSS (longitud màxima del segment de paquets) un cop finalitzada cada transmissió. Per exemple, fins i tot si es reconeixen 10 segments de paquets, el valor de CWND només augmentarà en un MSS. Es tracta d’un model de creixement lineal i també té un límit superior al creixement. Quan es produeix la pèrdua de paquets, el valor de CWND es canvia a un MSS i el valor de SSThresh s’estableix a la meitat de CWND. O també aturarà el creixement de MSS quan es rebin 3 respostes redundants ACK. Si encara es reben tres ACK redundants després de la reducció del valor de CWND, el valor de SSThresh es registra com a la meitat del valor de CWND i s’introdueix l’estat de recuperació ràpida.
Recuperació ràpida
En l'estat de recuperació ràpida, el valor de la finestra de congestió CWND s'incrementa per un MSS per a cada ACK redundant rebuda, és a dir, ACK que no arriba en seqüència. Es tracta d’utilitzar els segments de paquets que s’han transmès amb èxit a la xarxa per millorar l’eficiència de transmissió tant com sigui possible.
Quan arriba un ACK del segment de paquets perduts, TCP disminueix el valor de CWND i després entra a l’estat d’evitació de la congestió. Es tracta de controlar la mida de la finestra de congestió i evitar augmentar la congestió de la xarxa.
Si es produeix un temps d'espera després de l'estat de control de la congestió, la condició de la xarxa es fa més greu i TCP migra de l'estat d'evitació de la congestió a l'estat d'inici lent. En aquest cas, el valor de la finestra de congestió CWND s’estableix en 1 MSS, la longitud màxima del segment de paquets i el valor del llindar de lent ssthresh s’estableix a la meitat de CWND. L’objectiu d’això és augmentar de nou la mida de la finestra de congestió després que la xarxa es recuperi per equilibrar la taxa de transmissió i el grau de congestió de la xarxa.
Sumari
Com a protocol de transport fiable, TCP implementa un transport fiable per número de seqüència, reconeixement, control de retransmissió, gestió de connexions i control de finestres. Entre ells, el mecanisme de control de flux controla la quantitat de dades enviades per l’emissor segons la capacitat de recepció real del receptor, cosa que evita els problemes de congestió de xarxa i degradació del rendiment. El mecanisme de control de congestió evita l’aparició de congestió de xarxa ajustant la quantitat de dades enviades per l’emissor. Els conceptes de finestra de congestió i finestra d’enviament estan relacionats entre ells i la quantitat de dades de l’emissor està controlada ajustant dinàmicament la mida de la finestra de congestió. Inici lent, l’evitació de la congestió i la recuperació ràpida són les tres parts principals de l’algoritme de control de la congestió TCP, que ajusten la mida de la finestra de congestió a través de diferents estratègies per adaptar -se al grau de capacitat i congestió de la xarxa.
A la següent secció, examinarem detalladament el mecanisme de retransmissió de TCP. El mecanisme de retransmissió és una part important de TCP per aconseguir una transmissió fiable. Assegura la transmissió fiable de dades mitjançant la retransmissió de dades perdudes, corrompudes o retardades. El principi d’implementació i l’estratègia del mecanisme de retransmissió s’introduiran i s’analitzaran detalladament a la següent secció. Estigueu atents!
Posada Posada: 24-2025 de febrer
