NACK vs. ACK? Quando usarne uno rispetto all'altro?

Personalmente non sento nemmeno la necessità di ACK. È più veloce se inviamo semplicemente NACK (n) per i pacchetti persi invece di inviare un ACK per ogni pacchetto ricevuto. Quindi, quando / quali situazioni si potrebbero usare ACK su NACK e viceversa?

Il motivo dell'ACK è che un NACK non è semplicemente sufficiente. Supponiamo che ti invii un flusso di dati di segmenti X (diciamo 10 per semplicità).

La connessione non è buona e ricevi solo i segmenti 1, 2, 4 e 5. Il tuo computer invia l'NACK per il segmento 3, ma non si rende conto che dovrebbero esserci i segmenti 6-10 e non quelli NACK.

Quindi, rispedisco il segmento 3, ma poi il mio computer crede erroneamente che i dati vengano inviati con successo.

Gli ACK assicurano che il segmento è arrivato a destinazione.

Se vuoi che l'applicazione gestisca l'ordine dei dati e le ritrasmissioni, puoi semplicemente scegliere di utilizzare un protocollo come UDP (ad esempio, come fa TFTP).

Tutto si riduce alla distribuzione della probabilità di perdita e al modello di traffico.

Prendi ad esempio un tipico collegamento wireless, con un tasso di perdita costante del 10-30%. Se accetti ogni frame ricevuto (come 802.11abg), rileverai rapidamente quando un frame è stato perso, quindi non perderai tempo ad aspettare un timeout.

Se invece dovessi NAK, diventerai dipendente dal modello di traffico: - Se invii un singolo pacchetto di richieste e ti aspetti una risposta, e tale richiesta andrà persa, dovrai avere un timeout che scade se non ottieni un risposta. - Se si sta semplicemente inviando un flusso di pacchetto a un destinatario per lo più disattivato, è accettabile ricevere un NAK solo quando il destinatario riceve il pacchetto successivo o giù di lì. Ciò significa che il destinatario deve riordinare i pacchetti e che il mittente deve tenere traccia di un ampio arretrato di messaggi che ha inviato.

(Indovina quale soluzione scegliere 802.11n? Entrambi. Il ricevitore invia una bitmap di frame a lunghezza variabile che ha ricevuto)

Ora prendi una tipica rete Internet: hai quasi lo 0% di perdita di pacchetti, fino a quando non succede qualcosa di brutto, e hai una perdita di pacchetti vicina al 100% per un certo tempo a seguito di una legge di distribuzione esponenziale, da un'interruzione di 200ms a un minuto e un metà.

Accettare ciascun pacchetto sembrerebbe inutile in una rete senza perdite, fino a quando non si considera il caso in cui il collegamento viene interrotto: non si riceverà ACK o NACK per un periodo di tempo eventualmente prolungato e il destinatario in genere non invierà nulla fino al collegamento viene ripristinato.

Se si utilizza ACK, il mittente interromperà l'invio e manterrà il proprio backlog fino al ripristino del collegamento. Se invece usi NACK, il destinatario potrebbe alla fine dirti che non ha ricevuto il pacchetto che è caduto dal backlog del mittente da molto tempo e che la connessione è sostanzialmente irrecuperabile.

Gli ACK sono utili nei protocolli a finestra scorrevole, consentono al Trasmettitore A di essere consapevole che i dati inviati sono stati ricevuti dal telecomando B. Il Trasmettitore A può quindi procedere all'invio dei dati successivi - fino a quando la sua finestra di trasmissione è piena (di dati inviati a remoto ma non ancora riconosciuto).

Gli ACK possono essere considerati più essenziali dei NAK. I NAK consentono semplicemente un recupero più rapido , nel caso in cui un pacchetto / blocco inviato da A non sia ricevuto da B, e B rilevi in ​​qualche modo che manca un pacchetto / blocco.

È perfettamente possibile progettare un protocollo che supporti il ​​trasferimento affidabile e il controllo del flusso solo con ACK, senza NAK (con ritrasmissione da parte del trasmettitore nel caso in cui il trasmettitore non riceva un ACK, meccanismo di ritrasmissione necessario in ogni caso).

Una cosa molto importante che vorrei aggiungere qui, in TCP, NON abbiamo inviato ACK a OGNI PACCHETTO RICEVUTO.

Tuttavia, gli ACK vengono inviati solo per l'ULTIMO PACCHETTO RICEVUTO.

Perfavore, correggimi se sbaglio.