La ritrasmissione TCP significa inviare nuovamente sulla rete i pacchetti che sono stati persi o danneggiati. In questo caso, la ritrasmissione è un meccanismo utilizzato da protocolli come TCP per fornire una comunicazione affidabile. In questo caso, comunicazione affidabile significa che il protocollo garantisce la consegna del pacchetto anche se il pacchetto di dati è andato perso o danneggiato.
elenco Java vuoto
Le reti sono inaffidabili e non garantiscono il ritardo o la ritrasmissione dei pacchetti persi o danneggiati. La rete che utilizza una combinazione di riconoscimento e ritrasmissione di pacchetti danneggiati o persi offre affidabilità.
Meccanismo di ritrasmissione
In questo caso la ritrasmissione significa che i pacchetti di dati sono andati perduti, il che porta alla mancata ricezione. Questa mancanza di riconoscimento attiva un timer per il timeout, che porta alla ritrasmissione dei pacchetti di dati. In questo caso il timer significa che se non viene ricevuta alcuna conferma prima della scadenza del timer, il pacchetto di dati viene ritrasmesso.
Consideriamo i seguenti scenari di ritrasmissione.
Scenario 1: quando il pacchetto dati viene perso o errato.
In questo scenario, il pacchetto viene inviato al destinatario, ma non viene ricevuta alcuna conferma entro il periodo di timeout. Allo scadere del periodo di timeout, il pacchetto viene nuovamente inviato. Quando il pacchetto viene ritrasmesso, viene ricevuta la conferma. Una volta ricevuta la conferma, la ritrasmissione non avverrà più.
Scenario 2: quando il pacchetto viene ricevuto ma la conferma viene persa.
In questo scenario, il pacchetto viene ricevuto dall'altra parte, ma la conferma viene persa, ovvero l'ACK non viene ricevuto dal lato mittente. Una volta scaduto il periodo di timeout, il pacchetto viene inviato nuovamente. Dall'altro lato ci sono due copie dei pacchetti; sebbene il pacchetto venga ricevuto correttamente, la conferma non viene ricevuta, quindi il mittente ritrasmette il pacchetto. In questo caso la ritrasmissione avrebbe potuto essere evitata ma, a causa della perdita dell'ACK, il pacchetto viene ritrasmesso.
Scenario 3: quando si verifica il timeout anticipato.
In questo scenario, il pacchetto viene inviato, ma a causa del ritardo nella conferma o del timeout che si è verificato prima del timeout effettivo, il pacchetto viene ritrasmesso. In questo caso il pacchetto è stato inviato nuovamente inutilmente a causa del ritardo nella conferma oppure il timeout è stato impostato prima del timeout effettivo.
Negli scenari sopra indicati, il primo scenario non può essere evitato, ma gli altri due scenari possono essere evitati. Vediamo come evitare queste situazioni.
Quanto tempo deve attendere il mittente?
Il mittente imposta il periodo di timeout per un ACK. Il periodo di timeout può essere di due tipi:
Per superare le due situazioni precedenti, TCP imposta il timeout in funzione dell'RTT (round trip time) dove il tempo di andata e ritorno è il tempo impiegato dal pacchetto per viaggiare dalla sorgente alla destinazione e poi tornare indietro.
Come possiamo ottenere la RTT?
L'RTT può variare a seconda delle caratteristiche della rete, ovvero se la rete è congestionata significa che l'RTT è molto alto. Possiamo stimare l'RTT semplicemente osservando gli ACK.
Vediamo come possiamo misurare l'RTT.
Utilizzeremo il algoritmo originale per misurare l'RTT.
Passo 1: Per prima cosa misuriamo il EsempioRTT per ciascun segmento o coppia ACK. Quando il mittente invia il pacchetto, conosciamo il timer al quale viene inviato il pacchetto e inoltre conosciamo il timer al quale viene ricevuta la conferma. Calcola il tempo tra questi due e quello diventa il EsempioRTT .
Passo 2: Non prenderemo un solo campione. Continueremo a prelevare campioni diversi e a calcolare la media ponderata di questi campioni, che diventa EstRTT (Estimated RTT).
dove α+β = 1
stato git
α è compreso tra 0,8 e 0,9
β è compreso tra 0,1 e 0,2
Passaggio 3: Il timeout è impostato in base a EstRTT.
timeout = 2 * EstRTT.
Il timeout è impostato su due volte l'RTT stimato. Ecco come viene calcolato il fattore di timeout effettivo.
Un difetto in questo approccio
C'è un difetto nell'algoritmo originale. Consideriamo due scenari.
Scenario 1.
come convertire una stringa in int
Il diagramma sopra mostra che il mittente invia i dati, che si dice sia una trasmissione originale. Entro il periodo di timeout non viene ricevuta alcuna conferma. Quindi, il mittente ritrasmette i dati. Dopo aver ritrasmesso i dati, viene ricevuta la conferma. Supponiamo che la conferma venga ricevuta per la trasmissione originale, non per la ritrasmissione. Dal momento che riceviamo il riconoscimento della trasmissione originale, quindi EsempioRTT viene calcolato tra il momento della trasmissione originaria e il momento in cui viene ricevuta la conferma. Ma in realtà, il EsempioRTT avrebbe dovuto essere tra il momento della ritrasmissione e il momento della conferma.
Scenario 2.
Il diagramma sopra mostra che il mittente invia il pacchetto di dati originale per il quale riceviamo anche la conferma. Ma la conferma viene ricevuta dopo la ritrasmissione dei dati. Se assumiamo che il riconoscimento appartenga alla ritrasmissione, allora EsempioRTT viene calcolato tra il momento della ritrasmissione e il momento della conferma.
In entrambi gli scenari sopra riportati, esiste l'ambiguità di non sapere se la conferma è per la trasmissione originale o per la ritrasmissione.
Conclusione dell'algoritmo di cui sopra.
- In questo caso ACK non significa riconoscere una trasmissione, ma in realtà conferma la ricezione dei dati.
- Se consideriamo il primo scenario, la ritrasmissione avviene per il pacchetto perduto. In questo caso presupponiamo che ACK appartenga alla trasmissione originale, per cui il SampleRTT risulta essere molto grande.
- Se consideriamo il secondo scenario, vengono inviati due pacchetti uguali, quindi in questo caso si verifica una duplicità. In questo caso presupponiamo che ACK appartenga alla ritrasmissione, per cui il SampleRTT diventa molto piccolo.
Per superare i problemi di cui sopra, una soluzione semplice è data dall'algoritmo di Karn/Partridge. Questo algoritmo ha fornito una soluzione semplice che raccoglie i campioni inviati in una sola volta e non considera i campioni al momento della ritrasmissione per il calcolo dell'RTT stimato.
Algoritmo di Karn/Pernice
Nei due scenari precedenti si verifica la ritrasmissione e abbiamo considerato l'RTT campione. Ma questo algoritmo non considera il Sample RTT durante la ritrasmissione. Dal momento che è avvenuta la ritrasmissione, ciò significa che qualcosa accade in questo tempo di andata e ritorno o che potrebbe verificarsi una congestione nella rete. Per superare questo problema, questo algoritmo raddoppia il timeout dopo ogni ritrasmissione. Questo algoritmo è implementato nella rete TCP.
Limitazione
Non considera la varianza dell'RTT.
Per superare la limitazione di cui sopra è stato sviluppato l'algoritmo di Jacobson/Karels che introduce il fattore di varianza in RTT.
Algoritmo di Jacobson/Karels
Questo algoritmo è stato sviluppato per superare la limitazione del Karn/Pernice algoritmo. Calcola la differenza tra SampleRTT e EstimatedRTT e aumenta l'RTT in base alla differenza.
anno di invenzione del computer
Calcoli per RTT medio
- Per prima cosa calcoliamo il fattore di differenza.
Diff = RTT campione - RTT stimato
- Ora calcoliamo l'EstimatedRTT, che verrà calcolato nello stesso modo di cui sopra.
EstRTT = EstRTT + (δ*Diff)
- Ora calcoliamo la media del fattore di differenza.
Dev = Dev + δ ( |Diff| - Dev)
Qui, Dev è un fattore di deviazione e δ è un fattore compreso tra 0 e 1 Dev è una stima della varianza da EstRTT .
- Considereremo la varianza durante il calcolo del valore di timeout.
Dove, µ =1 e ɸ =4
Ritrasmissione veloce
La strategia basata sul timeout per la ritrasmissione è inefficiente. TCP è un tipo di protocollo a finestra scorrevole, quindi ogni volta che avviene la ritrasmissione, inizia a inviarlo dal pacchetto perso in poi.
formattare la data in una stringa
Supponiamo di trasmettere i pacchetti 0, 1, 2 e 3. Poiché il pacchetto 0 e il pacchetto 1 vengono ricevuti dall'altra parte, il pacchetto 2 viene perso in una rete. Ho ricevuto la conferma del pacchetto 0 e del pacchetto 1, quindi invio altri due pacchetti, ovvero il pacchetto 4 e il pacchetto 5. Quando vengono inviati i pacchetti 3, 4 e 5, otterrò la conferma del pacchetto 1 come riconoscimenti TCP sono cumulativi, quindi riconosce fino al pacchetto che ha ricevuto in ordine. Non ho ricevuto la conferma dei pacchetti 2, 3,4 e 5 entro il periodo di timeout, quindi ritrasmetto i pacchetti 2, 3, 4 e 5. Poiché il pacchetto 2 è perso, ma altri pacchetti, ad esempio 3, 4 ,5 vengono ricevuti dall'altra parte, vengono comunque ritrasmessi a causa di questo meccanismo di timeout.
Come è possibile rimuovere questa inefficienza di timeout?
La soluzione migliore sotto una finestra scorrevole:
Supponiamo che n pacchetto sia andato perso, ma che siano stati comunque ricevuti i pacchetti n+1, n+2 e così via. Il ricevitore riceve continuamente i pacchetti e invia i pacchetti ACK dicendo che il ricevitore sta ancora aspettando l'ennesimo pacchetto. Il destinatario sta inviando conferme ripetute o duplicate. Nel caso precedente, l'ACK del pacchetto 1 viene inviato tre volte poiché il pacchetto 2 è andato perso. Questo pacchetto ACK duplicato indica che manca l'ennesimo pacchetto, ma vengono ricevuti i pacchetti successivi.
La situazione sopra descritta può essere risolta nei seguenti modi:
- Il mittente può prendere gli 'ACK duplicati' come un primo indizio che l'ennesimo pacchetto è stato perso in modo che il mittente possa eseguire la ritrasmissione il prima possibile, ovvero il mittente non dovrebbe attendere fino a quando non si verifica il timeout.
- Il mittente può implementare una strategia di trasmissione veloce in TCP. In una strategia di trasmissione veloce, il mittente dovrebbe considerare i tripli ACK duplicati come un trigger e ritrasmetterli.
TCP utilizza tre ACK duplicati come trigger e quindi esegue la ritrasmissione. Nel caso precedente, quando vengono ricevuti tre ACK del pacchetto 1, il mittente deve inviare il pacchetto perduto, ovvero il pacchetto 2, senza attendere il periodo di timeout.