2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Das TCP-Protokoll weist die Merkmale Verbindung, zuverlässige Übertragung, Bytestrom-orientiert, Vollduplex usw. auf. Zuverlässige Übertragung ist der Kernbestandteil davon.
Abbildung 1
Die obige Abbildung zeigt die Struktur des TCP-Headers.
(1) Der Quellport und der Zielport müssen nicht zu oft eingeführt werden. Dies sind die Programme, die zur Angabe des sendenden Endes und des empfangenden Endes verwendet werden.
(2) Die Sequenznummer und die Bestätigungssequenznummer werden für den später eingeführten Bestätigungsantwortmechanismus in TCP verwendet.
(3) Die 4 Bits im Daten-Offset-Teil werden hier tatsächlich verwendet, um die Länge des TCP-Headers anzugeben. Aufgrund der 4 Bits beträgt die maximale Anzahl 15, aber da die Einheit 4 Bytes beträgt, beträgt die maximale Länge Der TCP-Header ist 60 Byte groß.
(4) Wir alle wissen, dass die maximale Länge von UDP-Datenpaketen 64 KB beträgt, was sehr begrenzt ist. Um diese Situation zu vermeiden, werden im TCP-Header 6 reservierte Bits für die spätere Verwendung bereitgestellt, wenn die TCP-Funktion erweitert wird Verwendung reservierter Bits.
(5) Die 6-Byte-englische Kennung bezieht sich auf den später eingeführten TCP-Mechanismus und wird hier nicht vorgestellt.
(6) Die Prüfsumme hat die gleiche Funktion wie die Prüfsumme bei UDP und dient auch der Überprüfung, ob sich die Daten während des Übertragungsvorgangs geändert haben.
(7) Das Fenster wird später bei der Einführung des Mechanismus besprochen.
(8) Der Notfallzeiger wird später eingeführt.
(9) Zu den Optionen gehören einige optionale/optionale Optionen.
Das TCP-Protokoll muss ein sehr wichtiges Problem lösen – die zuverlässige Übertragung. Die sogenannte zuverlässige Übertragung bedeutet nicht, dass der Absender die Daten zu 100 % an den Empfänger senden kann, aber er wird sein Bestes geben, um dem Absender mitzuteilen, ob der Empfänger es weiß.
Figur 2
Wie in Abbildung 2 gezeigt, sendet die Göttin jedes Mal eine Nachricht an Sie zurück. Dasselbe gilt für TCP. Der Client sendet ein Datenpaket Zu diesem Zeitpunkt wird das ACK-Flag des Antwortdatenpakets auf 1 gesetzt.
Bild 3
Wie in Abbildung 3 gezeigt, können wir leicht verwirrt werden, wenn wir mehrere Nachrichten an die Göttin senden, da die Göttin unterschiedlich schnell reagiert Die Göttin sagt, man solle sich verirren. Das Problem, wer zuerst kommt, existiert objektiv in China. Offensichtlich müssen wir beim Senden mehrerer Datenpakete an den Client und bei der Reaktion des Clients auf mehrere Antwortdatenpakete auch unterscheiden, welche Antwort dem gesendeten Datenpaket entspricht. Dieses Problem kann mithilfe der Sequenznummer und der Bestätigungssequenznummer in Abbildung 1 gelöst werden .
Jedes gesendete Datenpaket hat eine Sequenznummer, aber es gibt keine Bestätigungssequenznummer, oder das Bestätigungssequenznummernfeld ist ungültig. Die Bestätigung des darauf antwortenden Datenpakets ist 1. Zu diesem Zeitpunkt ist das Bestätigungssequenznummernfeld gültig. und die Sequenznummer des gesendeten Datenpakets und die Antwort. Die Bestätigungssequenznummern der Datenpakete stimmen überein, sodass unterschieden werden kann, wer wem geantwortet hat, und das oben erwähnte Last-Come-First-Served-Problem im Netzwerk gelöst werden kann .
Die Sequenznummer des eigentlichen TCP-Datenpakets wird nach Bytes nummeriert. Der Wert der Sequenznummer im TCP-Header ist die Nummer des ersten Bytes in der Nutzlast Wenn das erste Byte im Nutzlastteil 1 ist und die Nutzlastlänge 1000 Byte beträgt, beträgt die Bestätigungssequenznummer im Antwortdatenpaket-Header des Datenpakets 1001. Dies liegt daran, dass die Bestätigungssequenznummer des Das dem Datenpaket entsprechende Antwortdatenpaket wird auf die Nummer des letzten Bytes der Nutzlast gesetzt. Dies ist tatsächlich einfacher zu verstehen. Die Rückgabe von 1001 bedeutet, dass die gesendete 1000-Byte-Nutzlast empfangen wurde Daten nach 1001 werden angefordert, wie in Abbildung 4 dargestellt.
Figur 4
Für nachfolgend gesendete Datenpakete wird die Sequenznummer erhöht. Beachten Sie jedoch, dass die Sequenznummer trotz der Erhöhung nicht bei 0 oder 1 beginnt.
Eine zuverlässige Übertragung kann vor allem durch den Einsatz des „Bestätigungsantwort“-Mechanismus erreicht werden. Durch die Antwortnachricht kann es dem Absender mitteilen, ob alles in Ordnung ist und ob ein Paketverlust auftritt. Was ist zu tun, wenn ein Paketverlust auftritt (die Daten gehen während des Übertragungsprozesses verloren und können das andere Ende nicht erreichen, ein objektives Zufallsereignis)?
Die Timeout-Neuübertragung wird verwendet, um Paketverlustprobleme im Netzwerk zu lösen.
Hier gibt es hauptsächlich zwei Situationen:
(1) Übertragene Datenpakete gehen verloren
Zu diesem Zeitpunkt sendet B kein Antwortpaket, wenn es das Datenpaket von A nicht empfängt. Wenn das Ereignis, auf das A wartet, einen bestimmten Schwellenwert überschreitet, stellt es fest, dass ein Paketverlustproblem aufgetreten ist, und überträgt das Datenpaket erneut.
(2) Das Antwortdatenpaket geht verloren
Wenn A das Antwortdatenpaket nicht empfängt, sendet es immer noch ein Datenpaket, aber zu diesem Zeitpunkt hat B bereits ein Datenpaket empfangen. Mit der erneuten Übertragung des Datenpakets empfängt es zwei identische Datenpakete unwissenschaftlich, insbesondere bei Themen wie Transfers, bei denen es zu wiederholten Transfers kommt.
Bei den oben genannten Problemen dedupliziert der TCP-Empfänger die empfangenen Daten entsprechend der Sequenznummer. Die TCP-Schicht kümmert sich nicht um das Duplizierungsproblem. Der Schlüssel liegt darin, dass die Anwendungsschicht keine doppelten Daten lesen kann, egal wie oft sie erneut übertragen werden. Es muss sichergestellt werden, dass nur eine Kopie der Daten von der Anwendungsschicht gelesen wird.
Im Kernel des empfangenden Betriebssystems gibt es eine Datenstruktur – den Empfangspuffer. Diese Datenstruktur ähnelt der Prioritätsblockierungswarteschlange. Wenn B das Datenpaket empfängt und die Schichten zur Transportschicht durchläuft, gibt es eine Geben Sie die Daten in die Blockierungswarteschlange ein, und die Warteschlange bestimmt anhand der Sequenznummer des Datenpakets, ob sie vorhanden sind (Vorhandensein bedeutet, dass das gleiche Datenpaket einmal empfangen und gelesen wurde). Anwendungsschicht), wird es direkt verworfen. Ein weiterer Punkt des Empfangspuffers besteht darin, dass er das Last-Come-First-Come-Problem im Netzwerk lösen kann. Die gesendeten Daten werden nach der Sequenznummer sortiert und dann vom Programm der Anwendungsschicht der Reihe nach verarbeitet.
Wie in der Abbildung oben gezeigt, werden die im Empfangspuffer eintreffenden Daten nach der Sequenznummer sortiert. Dies löst nicht nur das Problem, dass die zuletzt gesendeten Datenpakete zuerst kommen, sondern auch das Problem des Empfangs doppelter Datenpakete. Wenn die Seriennummer des erneut übertragenen Datenpakets beim Empfang 500 beträgt, wird es direkt verworfen, da die minimale Sequenznummer des Empfangspuffers 1000 beträgt, was bedeutet, dass 500 bereits vom Anwendungsprogramm gelesen wurden.
Der Paketverlust selbst ist ein Ereignis mit geringer Wahrscheinlichkeit. Wenn die Anzahl der Paketverluste zunimmt, wird das Netzwerk zu einem großen Problem. Mit zunehmender Anzahl der Neuübertragungen wird das Zeitintervall zwischen den Neuübertragungen immer länger, da mehr Neuübertragungen darauf hinweisen, dass ein Problem mit dem Netzwerk vorliegt und häufige Neuübertragungen Ressourcen verbrauchen. Wenn die Anzahl der erneuten Übertragungen einen Schwellenwert erreicht, wird eine Reset-Nachricht gesendet, wobei das RST-Flag-Bit auf 1 gesetzt ist, um den Zwischenstatus beider Enden zu löschen. Wenn auf die Reset-Nachricht nicht reagiert wird, wird die Verbindung an beiden Enden gelöscht.
Die Timeout-Neuübertragung ist eine Ergänzung zur Bestätigungsantwort.
Abbildung 5
Das Herstellen einer Verbindung bedeutet, dass beide kommunizierenden Parteien die Informationen des anderen Endes speichern. Der spezifische Abschluss erfordert drei Netzwerkinteraktionen, wie in Abbildung 5 dargestellt.
Der erste Drei-Wege-Handshake muss vom Kunden initiiert werden. Wer den Drei-Wege-Handshake initiiert, ist der Kunde. Der spezifische Vorgang ist in Abbildung 5 dargestellt. Zuerst sendet der Client ein SYN-Paket, das heißt, das SYN-Flag im Header wird auf 1 gesetzt. Anschließend gibt der Server ein Antwortpaket zurück. Die ACK- und SYN-Flags des Antwortpakets sind Beide sind auf 1 gesetzt, da ACK und SYN Datenpakete mit Flag-Bits gleichzeitig vom Betriebssystemkernel senden, sodass sie zur Verbesserung der Leistung zusammen gesendet werden können. Schließlich sendet der Client ein Antwortpaket an den Server und der Drei-Wege-Handshake ist abgeschlossen. Die dabei übermittelten Datenpakete enthalten keine Geschäftsdaten.
Die Bedeutung des Drei-Wege-Handschlags:
(1) Steine werfen, um nach dem Weg zu fragen
Überprüfen Sie, ob die Kommunikationsverbindung reibungslos funktioniert
(2) Verhandeln Sie einige wichtige Parameter
Beispielsweise die Sequenznummer des übertragenen Datenpakets
(3) Bestätigen Sie die Empfangs- und Sendefähigkeiten beider Parteien
Warum drei Händeschütteln? Sind vier Händeschütteln oder zwei Händeschütteln in Ordnung?
Obwohl der Vier-Wege-Handshake die normalen Funktionen nicht beeinträchtigt, verringert er die Leistung. Der Zwei-Wege-Handshake kann die Empfangs- und Sendefunktionen des Servers nicht vollständig bestätigen.
Darüber hinaus gibt es hier zwei weitere wichtige Zustände. Der erste ist der Abhörstatus, was bedeutet, dass der Server zu diesem Zeitpunkt den Port gebunden hat und darauf wartet, dass der Client ein SYN-Paket sendet Es ist leicht zu verstehen und bedeutet, dass der Drei-Wege-Handshake abgeschlossen ist. Der Status nach dem Verbindungsaufbau.
Im Gegensatz zum Drei-Wege-Handshake, der nur vom Client zuerst initiiert werden kann, können sowohl der Server als auch der Client den Vier-Wege-Handshake initiieren.
Abbildung 6
Der spezifische Vorgang des viermaligen Winkens ist in Abbildung 6 dargestellt. Wenn die Methode socket.close() im Clientcode aufgerufen wird oder der Prozess endet, wird eine FIN-Endnachricht an den Server gesendet ACK-Nachricht zurück, aber es muss gewartet werden, bis der Servercode erst nach dem Aufruf von Code wie socket.close() die FIN-Endnachricht an den Client gesendet werden kann. Danach sendet der Client eine ACK-Nachricht an den Server Der Vorgang wird durch viermaliges Winken abgeschlossen.
ACK und FIN in der Mitte können hier nicht kombiniert werden, da ACK vom Systemkernel gesendet wird. Daher wird es sofort gesendet, wenn der Server die FIN-Nachricht empfängt. Die FIN-Nachricht muss jedoch warten, bis der serverseitige Code ausgeführt wird socket. Es kann nach close() gesendet werden, und es gibt einen Zeitunterschied zwischen den beiden. Es gibt jedoch eine Möglichkeit, beides zu kombinieren. Unter besonderen Umständen kann das ACK verzögert gesendet werden, sodass es zusammen mit dem FIN gesendet werden kann.
Darüber hinaus sind an den vier Wink-Prozessen zwei Zustände beteiligt. Der erste Zustand ist der Zustand, in dem sich der Empfänger befindet, nachdem er die FIN-Nachricht empfangen hat Darauf muss die Partei warten, nachdem sie die vom Empfänger gesendete FIN erhalten und dann eine ACK an den Empfänger gesendet hat. Die Verbindung kann nicht sofort getrennt werden, da verhindert werden muss, dass die letzte vom Sender an den Empfänger gesendete ACK verloren geht Der Empfänger sendet die FIN erneut. Um sicherzustellen, dass der Sender diese FIN weiterhin empfangen kann, beträgt die Zeit in diesem Zustand normalerweise 2MSI (MSI: die maximale Zeit für die Datenübertragung an beiden Enden), was normalerweise 2 Minuten beträgt.
Wenn auf dem Empfänger eine große Anzahl von close_wait gefunden wird, bedeutet dies, dass die Methode close() vergessen wurde. Wenn auf dem Server eine große Anzahl von time_wait gefunden wird, bedeutet dies, dass der Server eine große Anzahl aktiver TCP-Trennungen ausgelöst hat Operationen.
TCP muss eine zuverlässige Übertragung gewährleisten, möchte aber gleichzeitig auch die Datenübertragung so effizient wie möglich abschließen. Das Schiebefenster ist ein Mechanismus zur Verbesserung der Effizienz. Dies ist tatsächlich eine Möglichkeit, dies auszugleichen, denn um die Zuverlässigkeit zu gewährleisten, opfert TCP viel Leistung. Unabhängig davon, wie Sie das Fenster verschieben, kann die Datenübertragungsgeschwindigkeit nicht schneller sein als bei UDP.
Abbildung 7
Wie in Abbildung 7 dargestellt, ist dies der Prozess der Datenübertragung, aber der Prozess des Sendens eines Datenpakets und des Empfangens eines Antwortdatenpakets ist immer noch relativ langsam.
Abbildung 8
Wie in Abbildung 8 dargestellt, geschieht dies, nachdem der Schiebefenstermechanismus eingeführt wurde. Anstatt ein Datenpaket, aber mehrere Datenpakete gleichzeitig zu senden, überschneidet sich die Wartezeit der zurückgegebenen Antwortdatenpakete. Ohne auf ACK zu warten, entspricht die stapelweise gesendete Datenmenge der Fenstergröße.
Abbildung 9
Der Prozess des Schiebefensters ist in Abbildung 9 dargestellt. Angenommen, die Fenstergröße beträgt 4 Gruppen. Wenn eine Gruppe ACK empfängt, werden neue Daten gesendet, um sie zu ergänzen, was einem Schiebeprozess entspricht. Wenn der Absender die ACK von 3001 erhält, bedeutet dies, dass die Daten von 1001 bis 3001 empfangen wurden, sodass das Fenster um zwei Leerstellen nach rechts verschoben werden kann.
Was tun, wenn im Schiebefenster ein Paketverlust auftritt? Es gibt zwei Situationen:
(1) Das gesendete Datenpaket geht verloren
Wenn eine bestimmte Gruppe gesendeter Datagramme verloren geht, ist die Bestätigungssequenznummer der empfangenen ACK immer noch die der verlorenen Gruppe, obwohl Sie viele Datengruppen stapelweise an den Empfänger senden. Beispielsweise gehen die Datagramme 1001 bis 2000 im Bild oben verloren. Selbst wenn später mehrere Datensätze übertragen werden, wird die ACK von 1001 zurückgegeben, bis der Sender sie erneut überträgt und der Empfänger sie empfängt, und dann mit der ACK von 7001 antwortet .
(2) Die Antwort ACK geht verloren
Wenn die Antwort-ACK verloren geht, müssen Sie sich darüber keine Sorgen machen, da Sie einfach warten können, bis die ACK von anderen Datengruppen zurückgegeben wird. Wenn beispielsweise die ACK von 1001 im Bild oben verloren geht, wird sie gelöscht Es spielt keine Rolle, ob der Absender des nächsten ACK von 2001 die vorherigen Daten empfangen hat, und das Gleiche gilt, wenn das ACK der nachfolgenden Daten verloren geht.
Die oben erwähnte Verarbeitung von Paketverlusten ist immer noch sehr effizient. Wenn das Datenpaket verloren geht, füllen Sie einfach die Lücke und übertragen Sie die Daten erneut. Wenn das ACK verloren geht, ignorieren Sie es einfach. Ein solcher Vorgang wird als schnelle Neuübertragung bezeichnet.
Timeout-Neuübertragung und schnelle Neuübertragung sind unterschiedliche Strategien, die in verschiedenen Umgebungen angewendet werden. Wenn Ihr TCP nur wenige und selten Daten überträgt, wird die Timeout-Neuübertragung ausgelöst. Wenn Ihr TCP in kurzer Zeit eine große Datenmenge übertragen muss, wird dies der Fall sein Eine schnelle Neuübertragung kann ausgelöst werden. Die schnelle Neuübertragung entspricht der Variante der Timeout-Neuübertragung unter dem Schiebefenster.
Wie bereits beim Schiebefenster erwähnt, ist die Fenstergröße variabel. Sie können die Sendegeschwindigkeit des Absenders steuern, indem Sie die Größe des Fensters ändern. Je größer das Fenster, desto mehr Daten werden pro Zeiteinheit gesendet. Je kleiner das Fenster, desto mehr Daten werden pro Zeiteinheit gesendet. Je weniger Daten vorhanden sind, desto weniger effizient ist es. Normalerweise hoffen wir, dass die Effizienz so hoch wie möglich ist, aber die Voraussetzung für eine hohe Effizienz ist die Gewährleistung der Zuverlässigkeit. Wenn der Sender zu schnell sendet und der Empfänger damit nicht umgehen kann, kann es zu einem Paketverlust kommen Der Empfänger teilt dem Absender mit, dass die Sendegeschwindigkeit zu hoch ist. Dies ist eine „Flusskontrolle“.
Wie in der obigen Abbildung gezeigt, gibt es, wie bereits erwähnt, im Kernel einen Datenstruktur-Empfangspuffer, und der Empfänger gibt die Größe des freien Speicherplatzes im Empfangspuffer als Fenstergröße zurück. Der vorherige TCP-Header verfügt über ein 16-Bit-Fenstergrößenfeld, das ACK zum Speichern und Zurückgeben dieser Informationen verwendet. Das Fenstergrößenfeld wird nur in ACK wirksam.
Wie in der Abbildung oben gezeigt, gibt ACK die Größe des Fensters zurück, um den Zweck der Flusskontrolle zu erreichen. Wenn die Fenstergröße auf 0 zurückkehrt, sendet der Absender regelmäßig Prüfnachrichten, die keine Geschäftsdaten enthalten, um ACK auszulösen Status des Puffers. Gibt es freien Speicherplatz?
Die Überlastungskontrolle ist der Flusskontrolle sehr ähnlich, beide Mechanismen sind mit Schiebefenstern gekoppelt.
Wie in der Abbildung oben dargestellt, sind die Verbindungen im Netzwerk sehr komplex und jeder Knoten auf der Verbindung kann die Geschwindigkeit des Absenders einschränken. Die Idee der Überlastungskontrolle besteht darin, sie als Ganzes zu behandeln, egal wie komplex Ihre Zwischenstruktur ist, und dann durch Experimente die am besten geeignete Fenstergröße zu finden.
Wie in der Abbildung oben gezeigt, handelt es sich um einen Überlastungskontrollprozess. Versuchen Sie es zunächst mit einer relativ kleinen Fenstergröße (langsamer Start), da die Überlastungssituation des Netzwerks nicht bekannt ist Wenn das Fenster einen bestimmten Schwellenwert erreicht, wächst es linear und es kommt zu einem Paketverlust. Zu diesem Zeitpunkt gibt es zwei Möglichkeiten, die Größe zu verringern:
(1) Schrumpfen Sie direkt nach unten, kehren Sie zum Anfang des langsamen Starts zurück und wiederholen Sie dann den vorherigen Vorgang (bereits abgebrochen).
(2) Um die Hälfte schrumpfen und dann linear wachsen (die tatsächlich verwendete Methode)
Die Überlastungskontrolle besteht darin, mithilfe von Experimenten eine geeignete Fenstergröße zu finden. Wenn es zu großem Paketverlust kommt, reduzieren Sie die Fenstergröße. Wenn kein Paketverlust auftritt, erhöhen Sie die Fenstergröße.
Wie der Name schon sagt, bedeutet verzögerte Antwort, dass eine Weile gewartet wird, bevor ACK zurückgegeben wird. Dabei geht es tatsächlich auch um die Frage der Fenstergröße, da die verzögerte Antwort von ACK dem Empfänger mehr Zeit gibt, die Daten im Empfangspuffer zu verbrauchen, wodurch sich die Zeit erhöht Größe des freien Puffers, die von ACK zurückgegebene Fenstergröße erhöht sich und der Absender kann mehr Daten in Stapeln senden.
Es gibt zwei verzögerte Antwortmethoden:
(1) Geben Sie die Verzögerung entsprechend einer bestimmten Zeit an
(2) Abhängig von der Menge der empfangenen Daten
Die beiden oben genannten Strategien werden in Kombination verwendet.
Huckepack-Reaktionen sind tatsächlich schon früher als Mechanismus zur Verbesserung der Übertragungseffizienz aufgetaucht. Dies ist der Fall, wenn ACK und SYN im Drei-Wege-Handshake mit demselben Datenpaket zurückgegeben werden. Es gibt auch eine ähnliche Situation wie bei Four Waves. Da ACK und FIN zu unterschiedlichen Zeiten gesendet werden, können keine Huckepack-Antworten erfolgen. Bei der verzögerten Antwort muss ACK jedoch nicht so schnell an den Absender gesendet werden können mit den beiden FINs kombiniert werden, indem die Antworten huckepack genommen werden.
Byte-Stream-orientiert ist ein TCP-Mechanismus. Ein Problem, das hier beachtet werden muss, ist die Unfähigkeit, die Grenzen zwischen verschiedenen Datenpaketen der Anwendungsschicht zu unterscheiden. Der Server kann mehrere Bytes lesen und auch ein Byte lesen, was leicht zu diesem Problem führen kann.
Es gibt zwei Lösungen für das oben genannte Problem mit klebrigen Beuteln:
(1) Verwenden Sie Trennzeichen
Es kann jedes Symbol verwendet werden, solange es nicht im Anforderungspaket vorhanden ist
(2) Vereinbaren Sie die Länge des Datenpakets
In den meisten Fällen verwenden Java-Programmierer jedoch nicht direkt TCP, sondern verwenden vorgefertigte Protokolle wie http oder implementieren Netzwerkkommunikation auf Basis von Tools wie Protobuffer oder Dubbo. Diese Methoden haben das Problem der Sticky-Pakete intern gelöst. Verloren.
(1) An beiden Enden der Kommunikation stürzte der Prozess an einem Ende ab.
Das Betriebssystem führt vier Wellen durch und bewegt die Leiterplatte.
(2) Ein bestimmter Host wird heruntergefahren (normaler Prozess)
Die erste Möglichkeit besteht darin, dass das Betriebssystem vier Wellen abgeschlossen hat. Die zweite Möglichkeit besteht darin, dass der Empfänger nach dem Senden der FIN nicht erneut sendet und dann die Verbindung einseitig löscht das wird heruntergefahren, da sie alle heruntergefahren sind. Die gespeicherten Informationen (Speicher) sind natürlich verschwunden.
(3) Die Stromversorgung eines bestimmten Hosts ist ausgeschaltet.
Wenn der ausgeschaltete Host ein Server ist, wird das vom Client gesendete Datenpaket ohne Bestätigung erneut übertragen. Wenn nach mehreren erneuten Übertragungen kein Ergebnis erzielt wird, wird die Verbindung gelöscht.
Wenn der ausgeschaltete Host ein Client ist und der Server längere Zeit kein Datenpaket empfangen hat, sendet er regelmäßig ein Heartbeat-Paket ohne Nutzlast, nur um eine ACK auszulösen. Wenn der Client normal ist, wird er zurückgegeben Wenn eine Antwort eingeht und der Client nach mehrmaligem Senden nicht antwortet, kann davon ausgegangen werden, dass der Client aufgehängt ist und die Verbindungsinformationen gelöscht werden.
Obwohl TCP Heartbeat-Pakete implementiert, ist der Zyklus außerdem lang. Es dauert oft Minuten, bis durch dieses Heartbeat-Paket herausgefunden wird, dass der Client ausgefallen ist. In der tatsächlichen Entwicklung werden Heartbeat-Pakete auf der Anwendungsebene implementiert, mit höherer Frequenz und kürzerer Periode (Heartbeat-Pakete werden von A->B gesendet, und B->A antwortet mit einem Pong). Sobald das Gerät ein bestimmtes Mal hängt, können Sie das Problem schnell finden.
(4) Das Netzwerkkabel ist nicht angeschlossen
Im Wesentlichen handelt es sich um den dritten Fall. Wenn der Absender das ACK nicht erhält, wird die Übertragung erneut durchgeführt, dann wird RST gesendet und die Verbindung wird dann einseitig gelöscht. Wenn der Empfänger das Datenpaket nicht empfängt, sendet er ein Heartbeat-Paket Wenn das ACK nicht empfangen wird, wird einfach ein Heartbeat-Paket mit Löschinformationen gesendet.
Es gibt zwei Flag-Bits in der TCP-Header-Struktur, die nicht erwähnt werden, nämlich PSH und URG, die die andere Partei dazu auffordern, so schnell wie möglich eine Antwort zurückzugeben. Der URG ist dem Notfallzeigerfeld des TCP-Paket-Headers zugeordnet und wird zusammen zur Steuerung der TCP-Out-of-Band-Datenübertragung verwendet.
Out-of-Band-Datenübertragung bedeutet, dass zusätzlich zu den Geschäftsdaten einige spezielle Datenpakete zur Steuerung des Arbeitsmechanismus von TCP selbst verwendet werden.
Er widmet sich seit mehr als 30 Jahren der Technologieforschung und beherrscht verschiedene Sprachen wie Java, Linux, Javascript, PHP, CSS usw. Er hat viele Beiträge im Open-Source-Bereich geleistet Entwicklerdokumentationsstation, um einige Themen in der Technologieentwicklung als zukünftige Referenz zu teilen
