La migliore descrizione che io abbia mai sentito dire che aveva senso del metodo di limitazione intrinseca di TCP era fuori da un recente podcast di Security Now . Per citare Steve Gibson:
Quindi, di comune accordo, essendo TCP un protocollo molto intelligente, fa qualcosa chiamato "avvio lento". In genere viene concesso il permesso di inviare un numero di pacchetti senza conferma. Quindi l'idea è, facciamo solo muovere le cose qui. E in genere quel numero è due. E così quando TCP si avvia, può inviare due pacchetti, uno dopo l'altro. Senza il primo riconoscimento, verrà inviato il secondo. Ma poi aspetta. E quindi la regola per la limitazione è consentire al numero di pacchetti non riconosciuti di aumentare di uno per ogni riconoscimento ricevuto.
Quindi pensiamo a quello. Consentiamo di aumentare il numero di pacchetti non riconosciuti di uno per ogni riconoscimento ricevuto. Quindi per prima cosa spediamo due pacchetti come il nostro inizio concordato. Vengono riconosciuti. Quindi abbiamo il nostro primo riconoscimento. Ci stavamo concedendo di inviarne due. Ora, con la ricezione di questo primo riconoscimento, lo aumentiamo di uno a tre. Quindi ora possiamo inviare altri tre pacchetti senza ulteriori conferme. Quando viene restituito un riconoscimento per tutto ciò che abbiamo inviato in precedenza, lo aumentiamo a quattro. Questa è nota come "finestra di congestione". Non è una finestra mai inviata sulla linea, cioè non è come la finestra di ricezione, che è 16 bit dell'intestazione TCP che ci dice quanti dati siamo in grado di inviare in anticipo. Questo è - è una finestra. E'
Se continuiamo ad aumentare il numero di pacchetti non riconosciuti che possiamo inviare da uno ogni volta che riceviamo un riconoscimento, ad un certo punto raggiungeremo un limite. E la bellezza di questo sistema è che, quando inizieremo a provare a inviare pacchetti più velocemente del collegamento più debole, collegherò letteralmente, tra router, a un certo punto troviamo il punto in cui si rompe il collegamento più debole. Rilascia i pacchetti che stiamo cercando di inviare perché stiamo cercando di inviarli troppo velocemente. Quindi i riconoscimenti dall'altra parte si interrompono perché i dati non vengono più trasmessi.
E quello che fa TCP è, se non è riuscito a ricevere - e questo varia nelle strategie. Nel corso del tempo, la strategia, l'attuale strategia di prevenzione della congestione è variata molto. Ci sono nomi come Tahoe e Reno, e un sacco di altri che vedrai se fai qualche googling e Wikipedia, che specificano esattamente quale sia il comportamento. Ma l'idea è che, quando il mittente si rende conto che i suoi dati non vengono più trasmessi perché manca di riconoscimenti, riduce rapidamente la sua velocità di invio. In genere, lo divide a metà. Quindi lo ridimensiona drasticamente, e poi torna ad aumentarlo.
Quindi, in sostanza, ciò significa che la perdita dei pacchetti è la funzione di segnalazione per "Non è possibile inviare i dati più velocemente" e che i mittenti TCP alle estremità di una connessione, su Internet, sono sempre una specie di - loro " stai cercando di andare più veloce della velocità massima disponibile tra i due endpoint, ovvero il collegamento più debole, ovunque si trovi, e lo spingono sempre al limite. Quindi, dato che esiste un punto più debole della loro capacità di inviare pacchetti, lo troveranno perché pomperanno i pacchetti. Fintanto che ci sono dati da inviare e hanno una connessione ad alta larghezza di banda, il mittente aumenterà la velocità di invio, ovvero il numero di pacchetti in sospeso, i pacchetti che possono essere disponibili al volo come riconoscimenti ritorno, continua a spostare aggressivamente quel numero verso l'alto fino a quando non lo spinge troppo lontano. Quindi indietreggia molto e poi si sposta di nuovo in avanti.
Quindi questo è ciò che sta realmente accadendo tra le connessioni TCP che, come, probabilmente, non so quale percentuale, ma la percentuale enormemente maggiore di traffico su Internet avviene attraverso le connessioni TCP. Tutti i nostri sistemi operativi nel kernel, nel cosiddetto stack TCP, hanno questi contatori. E quando inviamo un file, quando stiamo caricando un file di grandi dimensioni o stiamo ricevendo una pagina Web, il server all'altro capo fa la stessa cosa. Spinge, su una base di connessione individuale, il maggior numero di pacchetti che non sono stati ancora riconosciuti come possibile, aumentando la velocità dei pacchetti fino a raggiungere il punto in cui inizia a fallire o balbettare. Quindi si arresta, per consentire in qualche modo di ripristinare le cose, quindi ricomincia a funzionare.
E così finisce per essere una sorta di sistema auto-strozzante che, dati i vincoli, voglio dire, sembra davvero un po 'funky e rozzo. "