logo

TCP-Neuübertragung

Bei der TCP-Neuübertragung werden verlorene oder beschädigte Pakete erneut über das Netzwerk gesendet. Hier ist die erneute Übertragung ein Mechanismus, der von Protokollen wie verwendet wird TCP um eine zuverlässige Kommunikation zu gewährleisten. Zuverlässige Kommunikation bedeutet hier, dass das Protokoll die Paketzustellung auch dann garantiert, wenn das Datenpaket verloren gegangen oder beschädigt ist.

Speicheraustausch

Die Netzwerke sind unzuverlässig und garantieren nicht die Verzögerung oder die erneute Übertragung verlorener oder beschädigter Pakete. Das Netzwerk, das eine Kombination aus Bestätigung und erneuter Übertragung beschädigter oder verlorener Pakete verwendet, bietet Zuverlässigkeit.

Neuübertragungsmechanismus

Eine erneute Übertragung bedeutet hier, dass die Datenpakete verloren gegangen sind, was zu einer fehlenden Bestätigung führt. Diese fehlende Bestätigung löst eine Zeitüberschreitung des Timers aus, die zur erneuten Übertragung von Datenpaketen führt. Der Timer bedeutet hier, dass das Datenpaket erneut übertragen wird, wenn vor Ablauf des Timers keine Bestätigung empfangen wird.

Betrachten wir die folgenden Szenarien der Neuübertragung.

Szenario 1: Wenn das Datenpaket verloren geht oder fehlerhaft ist.

TCP-Neuübertragung

In diesem Szenario wird das Paket an den Empfänger gesendet, aber innerhalb dieses Zeitlimits wird keine Bestätigung empfangen. Wenn die Zeitüberschreitung abläuft, wird das Paket erneut gesendet. Wenn das Paket erneut übertragen wird, wird die Bestätigung empfangen. Sobald die Bestätigung empfangen wurde, erfolgt keine erneute Übertragung.

Szenario 2: Wenn das Paket empfangen wird, die Bestätigung jedoch verloren geht.

TCP-Neuübertragung

In diesem Szenario wird das Paket auf der anderen Seite empfangen, aber die Bestätigung geht verloren, d. h. die ACK wird auf der Absenderseite nicht empfangen. Sobald die Timeout-Zeit abgelaufen ist, wird das Paket erneut gesendet. Auf der anderen Seite befinden sich zwei Kopien der Pakete; Obwohl das Paket korrekt empfangen wird, wird die Bestätigung nicht empfangen, sodass der Absender das Paket erneut überträgt. In diesem Fall hätte die erneute Übertragung vermieden werden können, aber aufgrund des Verlusts der ACK wird das Paket erneut übertragen.

Szenario 3: Wenn das frühe Timeout auftritt.

TCP-Neuübertragung

In diesem Szenario wird das Paket gesendet, aber aufgrund der Verzögerung bei der Bestätigung oder einer Zeitüberschreitung vor der tatsächlichen Zeitüberschreitung wird das Paket erneut übertragen. In diesem Fall wurde das Paket aufgrund der Verzögerung bei der Bestätigung unnötigerweise erneut gesendet oder der Timeout wurde früher eingestellt als der tatsächliche Timeout.

In den oben genannten Szenarien kann das erste Szenario nicht vermieden werden, die beiden anderen Szenarien können jedoch vermieden werden. Mal sehen, wie wir diese Situationen vermeiden können.

Wie lange sollte der Absender warten?

Der Absender legt den Timeout-Zeitraum für eine ACK fest. Es gibt zwei Arten von Timeout-Zeiträumen:

    Zu kurz:Wenn der Timeout-Zeitraum zu kurz ist, werden die erneuten Übertragungen verschwendet.Zu lang:Wenn der Timeout-Zeitraum zu lang ist, kommt es zu einer übermäßigen Verzögerung, wenn das Paket verloren geht.

Um die beiden oben genannten Situationen zu überwinden, TCP legt das Timeout als Funktion der RTT (Round Trip Time) fest, wobei die Round Trip Time die Zeit ist, die das Paket benötigt, um von der Quelle zum Ziel zu gelangen und dann wieder zurückzukommen.

Wie können wir die RTT erhalten?

Die RTT kann abhängig von den Eigenschaften des Netzwerks variieren. Wenn das Netzwerk beispielsweise überlastet ist, bedeutet dies, dass die RTT sehr hoch ist. Wir können die RTT abschätzen, indem wir einfach die ACKs beobachten.

Hrithik Roshan Alter

Mal sehen, wie wir die RTT messen können.

Wir werden das verwenden ursprünglicher Algorithmus um die RTT zu messen.

Schritt 1: Zuerst messen wir die SampleRTT für jedes Segment oder ACK-Paar. Wenn der Absender das Paket sendet, kennen wir den Timer, mit dem das Paket gesendet wird, und wir kennen auch den Timer, mit dem die Bestätigung empfangen wird. Berechnen Sie die Zeit zwischen diesen beiden, und das ergibt die SampleRTT .

Schritt 2: Wir werden nicht nur eine Probe nehmen. Wir werden weiterhin verschiedene Stichproben nehmen und den gewichteten Durchschnitt dieser Stichproben berechnen. Daraus wird die EstRTT (geschätzte RTT).

wobei α+ β = 1

α liegt zwischen 0,8 und 0,9

β liegt zwischen 0,1 und 0,2

Schritt 3: Das Timeout wird basierend auf EstRTT festgelegt.

Timeout = 2 * EstRTT.

Der Timeout ist auf das Doppelte der geschätzten RTT eingestellt. So wird der tatsächliche Timeout-Faktor berechnet.

Ein Fehler in diesem Ansatz

Es gibt einen Fehler im ursprünglichen Algorithmus. Betrachten wir zwei Szenarien.

Szenario 1.

TCP-Neuübertragung

Das obige Diagramm zeigt, dass der Absender die Daten sendet, was als Originalübertragung bezeichnet wird. Innerhalb des Timeout-Zeitraums wird keine Bestätigung empfangen. Der Absender überträgt die Daten also erneut. Nach erneuter Übertragung der Daten wird die Bestätigung empfangen. Nehmen wir an, dass eine Bestätigung für die ursprüngliche Übertragung empfangen wird, nicht für die erneute Übertragung. Da wir die Bestätigung der Originalübertragung erhalten, also SampleRTT wird zwischen dem Zeitpunkt der ursprünglichen Übertragung und dem Zeitpunkt des Empfangs der Bestätigung berechnet. Aber eigentlich ist das SampleRTT sollte zwischen dem Zeitpunkt der erneuten Übertragung und dem Zeitpunkt der Bestätigung liegen.

Szenario 2.

TCP-Neuübertragung

Das obige Diagramm zeigt, dass der Absender das ursprüngliche Datenpaket sendet, für das wir auch die Bestätigung erhalten. Die Bestätigung wird jedoch nach erneuter Übertragung der Daten empfangen. Wenn wir davon ausgehen, dass die Bestätigung zur erneuten Übertragung gehört, dann SampleRTT wird zwischen dem Zeitpunkt der erneuten Übertragung und dem Zeitpunkt der Bestätigung berechnet.

string.format Java

In beiden oben genannten Szenarien besteht die Unklarheit, dass nicht bekannt ist, ob die Bestätigung für die ursprüngliche Übertragung oder für die erneute Übertragung gilt.

Fazit des obigen Algorithmus.

  • Hier bedeutet ACK nicht die Bestätigung einer Übertragung, sondern vielmehr die Bestätigung des Empfangs der Daten.
  • Wenn wir das erste Szenario betrachten, erfolgt die erneute Übertragung für das verlorene Paket. In diesem Fall gehen wir davon aus, dass ACK zur ursprünglichen Übertragung gehört, weshalb SampleRTT sehr groß ausfällt.
  • Wenn wir das zweite Szenario betrachten, werden zwei gleiche Pakete gesendet, sodass es in diesem Fall zu Duplizität kommt. In diesem Fall gehen wir davon aus, dass ACK zur erneuten Übertragung gehört, wodurch SampleRTT sehr klein wird.

Um die oben genannten Probleme zu überwinden, bietet der Karn/Partridge-Algorithmus eine einfache Lösung. Dieser Algorithmus lieferte eine einfache Lösung, die die gleichzeitig gesendeten Proben sammelt und die Proben zum Zeitpunkt der erneuten Übertragung nicht zur Berechnung der geschätzten RTT berücksichtigt.

Karn/Partridge-Algorithmus

In den beiden oben genannten Szenarien kommt es zu einer erneuten Übertragung, und wir haben die Beispiel-RTT berücksichtigt. Dieser Algorithmus berücksichtigt jedoch nicht die Beispiel-RTT bei der erneuten Übertragung. Da die erneute Übertragung stattgefunden hat, bedeutet dies, dass in dieser Umlaufzeit etwas passiert oder es zu einer Überlastung in einem Netzwerk kommen kann. Um dieses Problem zu lösen, verdoppelt dieser Algorithmus das Timeout nach jeder erneuten Übertragung. Dieser Algorithmus ist im TCP-Netzwerk implementiert.

Einschränkung

Die Varianz der RTT wird nicht berücksichtigt.

    Wenn die Varianz gering ist, erweist sich die geschätzte RTT als genau. Wenn die Varianz groß ist, ist die geschätzte RTT nicht genau.

Um die oben genannte Einschränkung zu überwinden, wurde der Jacobson/Karels-Algorithmus entwickelt, der den Varianzfaktor in RTT einführt.

Laptop-Einsteckschlüssel

Jacobson/Karels-Algorithmus

Dieser Algorithmus wurde entwickelt, um die Einschränkung des zu überwinden Karn/Rebhuhn Algorithmus. Es berechnet die Differenz zwischen SampleRTT und timatedRTT und erhöht die RTT basierend auf der Differenz.

Berechnungen für die durchschnittliche RTT

  • Zuerst berechnen wir den Differenzfaktor.

Diff = SampleRTT – GeschätzteRTT

  • Jetzt berechnen wir die geschätzte RTT, die auf die gleiche Weise wie oben berechnet wird.

EstRTT = EstRTT + (δ*Diff)

  • Nun berechnen wir den Durchschnitt des Differenzfaktors.

Dev = Dev + δ ( |Diff| - Dev)

Hier ist Dev ein Abweichungsfaktor und δ ein Faktor zwischen 0 und 1. Der Entwickler ist eine Schätzung der Varianz von EstRTT .

  • Wir werden die Varianz bei der Berechnung des Timeout-Werts berücksichtigen.
Timeout = µ * EstRTT + ɸ * Dev

Wo, µ =1 und ɸ =4

Schnelle Weiterübertragung

Die Timeout-basierte Strategie für die erneute Übertragung ist ineffizient. TCP ist ein Sliding-Window-Protokoll, d. h. bei jeder erneuten Übertragung wird mit dem Senden ab dem verlorenen Paket begonnen.

TCP-Neuübertragung

Angenommen, ich übertrage die Pakete 0, 1, 2 und 3. Da Paket 0 und Paket 1 auf der anderen Seite empfangen werden, geht Paket 2 in einem Netzwerk verloren. Ich habe die Bestätigung für Paket 0 und Paket 1 erhalten, also sende ich zwei weitere Pakete, nämlich Paket 4 und Paket 5. Wenn die Pakete 3, 4 und 5 gesendet werden, erhalte ich die Bestätigung für Paket 1 als TCP-Bestätigungen sind kumulativ, es wird also bis zu dem Paket bestätigt, das es der Reihe nach empfangen hat. Ich habe die Bestätigung der Pakete 2, 3, 4 und 5 nicht innerhalb des Timeout-Zeitraums erhalten, daher übertrage ich die Pakete 2, 3, 4 und 5 erneut. Da Paket 2 verloren gegangen ist, sind jedoch andere Pakete, d. h. 3, 4, verloren gegangen ,5 auf der anderen Seite empfangen werden, werden sie aufgrund dieses Timeout-Mechanismus dennoch erneut übertragen.

Wie kann diese Timeout-Ineffizienz beseitigt werden?

Die bessere Lösung unter einem Schiebefenster:

Arraylist und Linkedlist

Nehmen wir an, dass n Pakete verloren gegangen sind, die Pakete n+1, n+2 usw. aber trotzdem empfangen wurden. Der Empfänger empfängt kontinuierlich die Pakete und sendet die ACK-Pakete mit der Meldung, dass der Empfänger immer noch auf das n-te Paket wartet. Der Empfänger sendet wiederholte oder doppelte Bestätigungen. Im obigen Fall wird die Bestätigung von Paket 1 dreimal gesendet, da Paket 2 verloren gegangen ist. Dieses doppelte ACK-Paket ist ein Hinweis darauf, dass das n-te Paket fehlt, die späteren Pakete jedoch empfangen werden.

Die obige Situation kann auf folgende Weise gelöst werden:

  • Der Absender kann die „doppelten ACKs“ als frühen Hinweis darauf werten, dass das n-te Paket verloren gegangen ist, sodass der Absender die erneute Übertragung so früh wie möglich durchführen kann, d. h. der Absender sollte nicht warten, bis die Zeitüberschreitung eintritt.
  • Der Absender kann in TCP eine schnelle Übertragungsstrategie implementieren. Bei einer schnellen Übertragungsstrategie sollte der Absender die dreifach doppelten ACKs als Auslöser betrachten und sie erneut übertragen.

TCP verwendet drei doppelte ACKs als Auslöser und führt dann eine erneute Übertragung durch. Wenn im obigen Fall drei ACKs von Paket 1 empfangen werden, sollte der Absender das verlorene Paket, d. h. Paket 2, senden, ohne auf das Eintreten des Timeout-Zeitraums zu warten.