NACK vs. ACK? Wann eins über das andere verwenden?

Persönlich habe ich nicht einmal das Gefühl, dass ACK erforderlich ist. Es ist schneller, wenn wir nur NACK (n) für die verlorenen Pakete senden, anstatt für jedes empfangene Paket eine ACK zu senden. Wann / in welchen Situationen würde man ACK über NACK und umgekehrt einsetzen?

Der Grund für das ACK ist, dass ein NACK einfach nicht ausreicht. Angenommen, ich sende Ihnen einen Datenstrom von X-Segmenten (der Einfachheit halber sagen wir 10).

Sie haben eine schlechte Verbindung und empfangen nur die Segmente 1, 2, 4 und 5. Ihr Computer sendet den NACK für Segment 3, merkt jedoch nicht, dass es die Segmente 6 bis 10 geben sollte, und nackt diese nicht.

Also sende ich Segment 3 erneut, aber dann glaubt mein Computer fälschlicherweise, dass die Daten erfolgreich gesendet wurden.

ACKs bieten eine gewisse Sicherheit, dass das Segment am Ziel angekommen ist.

Wenn die Anwendung die Reihenfolge der Daten und der erneuten Übertragungen verarbeiten soll, können Sie einfach ein Protokoll wie UDP verwenden (z. B. TFTP).

Es läuft alles auf die Verlustwahrscheinlichkeitsverteilung und das Verkehrsmuster hinaus.

Nehmen wir zum Beispiel eine typische drahtlose Verbindung mit einer konstanten Verlustrate von 10-30%. Wenn Sie jeden empfangenen Frame bestätigen (z. B. 802.11abg), erkennen Sie schnell, wenn ein Frame verloren gegangen ist, sodass Sie keine Zeit verlieren, um auf eine Zeitüberschreitung zu warten.

Wenn Sie stattdessen in NAK waren, werden Sie vom Verkehrsmuster abhängig: - Wenn Sie ein einzelnes Anforderungspaket senden und eine Antwort erwarten und diese Anforderung verloren geht, muss eine Zeitüberschreitung auftreten, die abläuft, wenn Sie keine erhalten Antworten. - Wenn Sie nur einen Paketstrom an einen größtenteils stummen Empfänger senden, ist es akzeptabel, einen NAK nur zu empfangen, wenn der Empfänger das nächste Paket empfängt. Dies bedeutet jedoch, dass der Empfänger Pakete neu ordnen muss und der Absender einen großen Rückstand an gesendeten Nachrichten nachverfolgen muss.

(Ratet mal, welche Lösung 802.11n auswählt? Beide. Der Empfänger sendet eine Bitmap variabler Länge der empfangenen Frames.)

Nehmen wir nun ein typisches Internet-Netzwerk: Sie haben einen Paketverlust von nahezu 0%, bis etwas Schlimmes passiert, und Sie haben einen Paketverlust von nahezu 100% für eine bestimmte Zeit nach einem exponentiellen Verteilungsgesetz, von einer Unterbrechung von 200 ms bis zu einer Minute und einer Sekunde Hälfte.

In einem verlustfreien Netzwerk erscheint es sinnlos, jedes Paket zu bestätigen, bis Sie den Fall betrachten, in dem die Verbindung unterbrochen wurde: Sie erhalten möglicherweise längere Zeit keine ACK oder NACK, und der Empfänger sendet in der Regel nichts, bis die Verbindung getrennt ist ist restauriert.

Wenn Sie ACK verwenden, hört der Absender auf zu senden und behält seinen Rückstand bei, bis die Verbindung wiederhergestellt ist. Wenn Sie stattdessen NACK verwenden, werden Sie möglicherweise vom Empfänger darüber informiert, dass er das Paket, das vom Rückstand des Absenders abgefallen ist, seit langer Zeit nicht mehr empfangen hat und die Verbindung im Wesentlichen nicht wiederherstellbar ist.

ACKs sind in Gleitfensterprotokollen nützlich. Sie ermöglichen es Sender A, zu erkennen, dass gesendete Daten von Remote B empfangen wurden. Sender A kann dann mit dem Senden der nächsten Daten fortfahren - bis sein Sendefenster voll ist (mit Daten, die an Remote gesendet wurden, aber noch nicht anerkannt).

ACKs können als wesentlich wichtiger angesehen werden als NAKs. NAKs ermöglichen einfach eine schnellere Wiederherstellung , wenn ein von A gesendetes Paket / Block von B nicht empfangen wird und B auf irgendeine Weise erkennt, dass ein Paket / Block fehlt.

Es ist durchaus machbar, ein Protokoll zu entwerfen, das eine zuverlässige Übertragung und Flusskontrolle nur mit ACK ohne NAK unterstützt (mit erneuter Übertragung durch den Sender, falls der Sender keine ACK empfängt, ein in jedem Fall erforderlicher Mechanismus zur erneuten Übertragung).

Eine wichtige Sache, die ich hier hinzufügen möchte, in TCP, haben wir keine Bestätigung für jedes empfangene Paket gesendet.

Die ACKs werden jedoch nur für das zuletzt empfangene Paket gesendet.

Bitte korrigieren Sie mich, wenn ich falsch liege.