Ausführliche Erklärung und Fragen und Antworten zum Drei-Wege-Handschlag und Vier-Wege-Welle

Drei-Wege -Handshake bedeutet eigentlich, dass Client und Server beim Aufbau einer TCP- Verbindunginsgesamt 3 Pakete senden müssen. Der Hauptzweck des Drei-Wege-Handshakes besteht darin, zu bestätigen, ob die Empfangs- und Sendefähigkeiten beider Parteien normal sind , und Ihre eigene Initialisierungssequenznummer anzugeben, um eine spätere zuverlässige Übertragung vorzubereiten. Im Wesentlichen besteht es darin, eine Verbindung zum angegebenen Port des Servers herzustellen, eine TCP-Verbindung herzustellen, die Sequenznummer und Bestätigungsnummer beider Parteien zu synchronisieren und Informationen auszutauschen.TCP窗口大小

Zu Beginn befindet sich der Client im Zustand CLOSED und der Server im Zustand LISTEN.

Erster Händedruck :

Der Client sendet eine SYN-Nachricht an den Server und gibt die Initialisierungssequenznummer ISN des Clients an. Zu diesem Zeitpunkt befindet sich der Client im SYN_SENT Status. Das Synchronisationsbit im Header ist SYN = 1, die anfängliche Sequenznummer seq = x, und das Nachrichtensegment mit SYN = 1 kann keine Daten übertragen, verbraucht jedoch eine Sequenznummer; (der Client sendet ein Netzwerkpaket und der Server empfängt es . Auf diese Weise kann der Server Schlussfolgerungen ziehen: Die Sendefähigkeit des Clients und die Empfangsfähigkeit des Servers sind normal .

Zweiter Handschlag :

Nach dem Empfang der SYN-Nachricht des Clients antwortet der Server mit einer eigenen SYN-Nachricht und gibt außerdem seine eigene(n) Initialisierungssequenznummer(n) an. Gleichzeitig wird die ISN + 1 des Clients als ACK-Wert verwendet, was darauf hinweist, dass er die SYN des Clients empfangen hat und sich der Server zu diesem Zeitpunkt im Status befindet SYN_RCVD . Im Bestätigungsnachrichtensegment sind SYN = 1, ACK = 1, Bestätigungsnummer ack = x + 1 und anfängliche Sequenznummer seq = y; (Der Server sendet das Paket und der Client empfängt es. Auf diese Weise kann der Client zeichnen Die Schlussfolgerung: Der Server empfängt, die Sendefähigkeit und die Empfangs- und Sendefähigkeit des Clients sind normal. Zu diesem Zeitpunkt kann der Server jedoch nicht bestätigen, ob die Empfangsfähigkeit des Clients normal ist .)
Der dritte Handshake :

Der Client empfängt das SYN+ACK-Paket vom Server und sendet ein Bestätigungspaket ACK (ack=k+1) an den Server. Nach dem Senden des Pakets treten der Client und der Server in den ESTABLISHED-Status ein und schließen den Drei-Wege-Handshake ab (Der Client sendet das Paket und der Server empfängt es. Auf diese Weise kann der Server die Schlussfolgerung ziehen: Die Empfangs- und Sendefunktionen des Clients sind normal, und die eigenen Sende- und Empfangsfunktionen des Servers sind ebenfalls normal. )

1.2 Was ist eine Semi-Join-Warteschlange?

Nachdem der Server das SYN des Clients zum ersten Mal empfangen hat, befindet er sich im Status SYN_RCVD. Zu diesem Zeitpunkt haben die beiden Parteien ihre Verbindung noch nicht vollständig hergestellt. Der Server stellt die angeforderte Verbindung in diesem Status in eine Warteschlange. Wir rufen an Diese Warteschlange ist eine halbverknüpfte Warteschlange .

Natürlich gibt es auch eine vollständige Verbindungswarteschlange . Das heißt, der Drei-Wege-Handshake ist abgeschlossen und die hergestellte Verbindung wird in die vollständige Verbindungswarteschlange gestellt. Wenn die Warteschlange voll ist, kann es zu Paketverlusten kommen.

Hier ist ein zusätzlicher Punkt zur Anzahl der SYN-ACK-Neuübertragungen :
Nachdem der Server das SYN-ACK-Paket gesendet hat und das Kundenbestätigungspaket nicht empfängt, führt der Server die erste Neuübertragung durch. Nach einer gewissen Wartezeit und Wenn das Kundenbestätigungspaket immer noch nicht empfangen wird, wird die zweite Neuübertragung durchgeführt. Wenn die Anzahl der erneuten Übertragungen die vom System festgelegte maximale Anzahl erneuter Übertragungen überschreitet, löscht das System die Verbindungsinformationen aus der Halbverbindungswarteschlange.
Beachten Sie, dass die Wartezeit für jede erneute Übertragung nicht unbedingt gleich ist. Sie erhöht sich normalerweise exponentiell. Das Intervall beträgt beispielsweise 1 s, 2 s, 4 s, 8 s ...

1.3 Ist die ISN (Initial Sequence Number) festgelegt?

Wenn ein Peer seine SYN sendet, um eine Verbindung herzustellen, wählt er eine anfängliche Sequenznummer für die Verbindung. Die ISN ändert sich im Laufe der Zeit, sodass jede Verbindung eine andere ISN hat. ISN kann als 32-Bit-Zähler betrachtet werden, der alle 4 ms um 1 erhöht wird. Der Zweck dieser Auswahl von Sequenznummern besteht darin, zu verhindern, dass Pakete, die im Netzwerk verzögert wurden, später übertragen werden, was dazu führen könnte, dass ein Teilnehmer der Verbindung sie falsch interpretiert.

Eine der wichtigen Funktionen des Drei-Wege-Handshakes besteht darin, dass Client und Server ISN (Initial Sequence Number) austauschen, sodass die andere Partei beim nächsten Datenempfang weiß, wie sie die Daten entsprechend der Sequenznummer zusammenstellen muss. Wenn die ISN festgelegt ist, ist es für einen Angreifer leicht, nachfolgende Bestätigungsnummern zu erraten, sodass die ISN dynamisch generiert wird.

1.4 Können Daten während des Drei-Wege-Handshakes übertragen werden?

Tatsächlich können Daten während des dritten Handshakes übertragen werden. Der erste und zweite Handshake können jedoch keine Daten übertragen

Warum ist das so? Sie können über eine Frage nachdenken: Wenn der erste Handshake Daten übertragen kann und jemand den Server böswillig angreifen möchte, wird er beim ersten Handshake jedes Mal eine große Datenmenge in die SYN-Nachricht einfügen. Da der Angreifer einfach ignoriert, ob die Empfangs- und Sendefunktionen des Servers normal sind, und dann hektisch SYN-Nachrichten erneut sendet, verbraucht der Server viel Zeit und Speicherplatz für den Empfang dieser Nachrichten.

Mit anderen Worten: Daten können nicht im ersten Handshake platziert werden. Ein einfacher Grund besteht darin, dass der Server dadurch anfälliger für Angriffe wird. Zum dritten Mal befindet sich der Client bereits im Status ESTABLISHED. Für den Client hat er eine Verbindung hergestellt und weiß bereits, dass die Empfangs- und Sendefunktionen des Servers normal sind, sodass nichts falsch daran ist, Daten übertragen zu können.

1.5 Was ist ein SYN-Angriff?

Die Ressourcenzuweisung auf der Serverseite wird während des zweiten Handshakes zugewiesen, während die Ressourcen auf der Clientseite nach Abschluss des Drei-Wege-Handshakes zugewiesen werden . Daher ist der Server anfällig für SYN-Flooding-Angriffe. Ein SYN-Angriff bedeutet, dass der Client in kurzer Zeit eine große Anzahl nicht vorhandener IP-Adressen fälscht und kontinuierlich SYN-Pakete an den Server sendet. Der Server antwortet mit Bestätigungspaketen und wartet auf die Bestätigung des Clients. Da die Quelladresse dies tut Wenn sie nicht vorhanden sind, muss der Server erneut senden, bis das Zeitlimit überschritten wird. Diese gefälschten SYN-Pakete belegen lange Zeit die nicht verbundene Warteschlange, was dazu führt, dass normale SYN-Anfragen verworfen werden, da die Warteschlange voll ist, was zu einer Netzwerküberlastung und sogar zu einer Systemlähmung führt . Ein SYN-Angriff ist ein typischer DoS/DDoS-Angriff.

Das Erkennen von SYN-Angriffen ist sehr praktisch. Wenn Sie eine große Anzahl halbverbundener Zustände auf dem Server sehen, insbesondere wenn die Quell-IP-Adresse zufällig ist, können Sie grundsätzlich zu dem Schluss kommen, dass es sich um einen SYN-Angriff handelt. Unter Linux/Unix können Sie den systemeigenen Befehl netstat verwenden, um SYN-Angriffe zu erkennen.

netstat -n -p TCP | grep SYN_RECV

 
 1

Zu den gängigen Methoden zur Abwehr von SYN-Angriffen gehören die folgenden:

Verkürzen Sie die Timeout-Zeit (SYN-Timeout).
Erhöhen Sie die maximale Anzahl halber Verbindungen
Filter-Gateway-Schutz
SYN-Cookie-Technologie

2. Viermal winken

Für den Verbindungsaufbau sind drei Handshakes erforderlich, für den Verbindungsabbau sind vier Wellen erforderlich (die vier Wellen werden auch Vier-Wege-Handshake genannt). Dies wird durch TCPs half-close verursacht . Das sogenannte Halbgeschlossene bedeutet eigentlich, dass TCP einem Ende der Verbindung die Möglichkeit bietet, Daten vom anderen Ende zu empfangen, nachdem der Sendevorgang abgeschlossen ist.

Der Abbau einer TCP-Verbindung erfordert das Senden von vier Paketen, daher spricht man von einem Vier-Wege-Handshake. Entweder der Client oder der Server können die Wave-Aktion aktiv initiieren.

Zu Beginn befinden sich beide Parteien im ESTABLISHED Zustand: Wenn der Client zuerst eine Abschaltanforderung initiiert. Der Vorgang des viermaligen Winkens ist wie folgt:

Die erste Welle: Der Client sendet eine FIN-Nachricht und in der Nachricht wird eine Sequenznummer angegeben. Zu diesem Zeitpunkt befindet sich der Client im FIN_WAIT1 Status.
Das heißt, es sendet ein Verbindungsfreigabe-Nachrichtensegment (FIN=1, Sequenznummer seq=u), stoppt das Senden von Daten, schließt aktiv die TCP-Verbindung, wechselt in den Status FIN_WAIT1 (Beendigungswartezeit 1) und wartet auf die Bestätigung vom Server.
Die zweite Welle: Nach dem Empfang der FIN sendet der Server eine ACK-Nachricht und verwendet den Sequenznummernwert des Clients + 1 als Sequenznummernwert der ACK-Nachricht, um anzuzeigen, dass er die Nachricht des Clients empfangen hat. Zu diesem Zeitpunkt ist der Server im CLOSE_WAIT Staat.
Das heißt, nach dem Empfang des Nachrichtensegments zur Verbindungsfreigabe sendet der Server ein Bestätigungsnachrichtensegment (ACK = 1, Bestätigungsnummer ack = u + 1, Sequenznummer seq = v) und der Server wechselt in den Status CLOSE_WAIT (geschlossenes Warten). Zu diesem Zeitpunkt wird TCP in einem halbgeschlossenen Zustand die Verbindung vom Client zum Server freigegeben. Nach Erhalt der Bestätigung vom Server wechselt der Client in den Status FIN_WAIT2 (Beendigungswartezeit 2) und wartet auf das vom Server gesendete Verbindungsfreigabesegment.
Die dritte Welle: Wenn der Server ebenfalls die Verbindung trennen möchte, sendet er eine FIN-Nachricht und gibt eine Sequenznummer an, genau wie bei der ersten Welle des Clients. Der Status des Servers zu diesem Zeitpunkt LAST_ACK .
Das heißt, der Server hat keine Daten zum Senden an den Client. Der Server sendet ein Nachrichtensegment zur Verbindungsfreigabe (FIN = 1, ACK = 1, Sequenznummer seq = w, Bestätigungsnummer ack = u + 1) und der Server tritt ein LAST_ACK (endgültige Bestätigung). ) Status, wartet auf Bestätigung vom Client.
Die vierte Welle: Nach Erhalt der FIN sendet der Client auch eine ACK-Nachricht als Antwort und verwendet den Sequenznummernwert + 1 des Servers als Sequenznummernwert seiner eigenen ACK-Nachricht. Zu diesem Zeitpunkt befindet sich der Client im Status TIME_WAIT . Es dauert eine Weile, bis sichergestellt ist, dass der Server seine eigene ACK-Nachricht empfängt, bevor er in den Status „Geschlossen“ wechselt. Nachdem der Server die ACK-Nachricht empfangen hat, befindet er sich im Status „Geschlossene Verbindung“ CLOSED .
Das heißt, nachdem der Client das Nachrichtensegment zur Verbindungsfreigabe vom Server empfangen hat, sendet er ein Bestätigungsnachrichtensegment (ACK = 1, seq = u + 1, ack = w + 1) und der Client gibt TIME_WAIT (Wartezeit) ein. Zustand. Zu diesem Zeitpunkt wurde TCP noch nicht freigegeben und der Client muss auf die vom Timer festgelegte Zeit 2MSL warten, um in den GESCHLOSSENEN Zustand zu gelangen.

Der Erhalt einer FIN bedeutet lediglich, dass kein Datenfluss in diese Richtung stattfindet. Es ist normal, dass der Client ein aktives Herunterfahren durchführt und in den Status TIME_WAIT wechselt. Der Server führt normalerweise ein passives Herunterfahren durch und wechselt nicht in den Status TIME_WAIT.

Bei der Socket-Programmierung kann jede Partei, die die Operation close() ausführt, eine Waving-Operation generieren.

2.1 Warum dauert das Winken viermal?

Denn wenn der Server die SYN-Verbindungsanforderungsnachricht des Clients empfängt, kann er direkt eine SYN + ACK-Nachricht senden. Die ACK-Nachricht wird zur Antwort und die SYN-Nachricht zur Synchronisierung verwendet . Wenn der Server jedoch beim Schließen der Verbindung die FIN-Nachricht empfängt, wird der SOCKET wahrscheinlich nicht sofort geschlossen, sodass er zunächst nur mit einer ACK-Nachricht antworten kann, um dem Client mitzuteilen: „Ich habe die von Ihnen gesendete FIN-Nachricht erhalten.“ " Ich kann FIN-Nachrichten erst senden, nachdem alle Nachrichten auf meinem Server gesendet wurden, sie können also nicht zusammen gesendet werden. Es sind also vier Wellen erforderlich.

2.2 2MSL-Wartezustand

Der TIME_WAIT-Zustand wird auch zum 2MSL-Wartezustand. Jede spezifische TCP-Implementierung muss eine maximale Segmentlebensdauer MSL (Maximum Segment Lifetime) wählen. Dies ist die maximale Zeit, die ein Segment im Netzwerk verbleiben kann, bevor es verworfen wird. Diese Zeit ist begrenzt, da TCP-Segmente innerhalb des Netzwerks als IP-Datagramme übertragen werden und IP-Datagramme über ein TTL-Feld verfügen, das ihre Lebensdauer begrenzt.

Für den MSL-Wert, der durch eine bestimmte Implementierung angegeben wird, lautet das Verarbeitungsprinzip: Wenn TCP einen aktiven Abschluss durchführt und das letzte ACK zurücksendet, muss die Verbindung für das Zweifache des MSL im TIME_WAIT-Status bleiben. Dadurch kann TCP das letzte ACK erneut senden, falls dieses ACK verloren geht (das andere Ende läuft ab und sendet das letzte FIN erneut).

Ein weiteres Ergebnis dieser 2MSL-Wartezeit ist, dass während der 2MSL-Wartezeit dieser TCP-Verbindung der Socket, der diese Verbindung definiert (IP-Adresse und Portnummer des Clients, IP-Adresse und Portnummer des Servers), nicht mehr verwendet werden kann. Erst nach Ende von 2MSL kann diese Verbindung wieder genutzt werden.

2.3 Welche Bedeutung hat es, auf 2MSL zu warten, wenn man viermal winkt, um die Verbindung freizugeben?

MSL ist die englische Abkürzung für Maximum Segment Lifetime, was als „maximale Segmentlebensdauer“ übersetzt werden kann. Es ist die längste Zeit, die eine Nachricht im Netzwerk vorhanden ist. Nach dieser Zeit wird die Nachricht verworfen.

Um sicherzustellen, dass das letzte vom Client gesendete ACK-Segment den Server erreichen kann. Da dieses ACK möglicherweise verloren geht, erhält der Server im LAST-ACK-Status die Bestätigungsnachricht für FIN-ACK nicht. Der Server führt zu einer Zeitüberschreitung und sendet das FIN-ACK erneut. Anschließend sendet der Client die Bestätigung erneut und startet die Zeit erneut 等待计时器. Abschließend können sowohl der Client als auch der Server normal heruntergefahren werden. Angenommen, der Client wartet nicht auf 2MSL, sondern gibt das Schließen direkt nach dem Senden des ACK frei. Sobald das ACK verloren geht, kann der Server nicht normal in den geschlossenen Verbindungsstatus wechseln.

Zwei Gründe:

Stellen Sie sicher, dass das letzte vom Client gesendete ACK-Segment den Server erreichen kann .

Dieses ACK-Nachrichtensegment kann verloren gehen, sodass B im LAST-ACK-Status die Bestätigung des gesendeten FIN+ACK-Nachrichtensegments nicht empfangen kann und der Server das Zeitlimit überschreitet und das FIN+ACK-Nachrichtensegment erneut überträgt, während der Client dies tun kann Nach dem Empfang Nachdem das FIN+ACK-Nachrichtensegment innerhalb der 2MSL-Zeit erneut übertragen wurde, sendet der Client die Bestätigung erneut und startet den 2MSL-Timer neu. Schließlich gehen sowohl der Client als auch der Server in den Status CLOSED über. Wenn sich der Client im Status TIME-WAIT befindet, warten Sie nicht Für einen bestimmten Zeitraum, aber geben Sie die Verbindung sofort nach dem Senden des ACK-Nachrichtensegments frei. Sie können das vom Server erneut übertragene FIN + ACK-Nachrichtensegment nicht empfangen, sodass kein weiteres Bestätigungsnachrichtensegment gesendet wird, und der Server wird dies tun nicht in der Lage sein, normal zu funktionieren. Wechseln Sie in den GESCHLOSSENEN Zustand.
Verhindern Sie, dass in dieser Verbindung „abgelaufenes Verbindungsanforderungssegment“ angezeigt wird .

Nachdem der Client das letzte ACK-Segment gesendet und dann 2MSL durchlaufen hat, verschwinden alle während der Dauer dieser Verbindung generierten Segmente aus dem Netzwerk, sodass diese Segmente bei der nächsten neuen Verbindung nicht angezeigt werden. Ein altes Verbindungsanforderungssegment.

2.4 Warum muss der TIME_WAIT-Status 2MSL durchlaufen, bevor er in den CLOSE-Status zurückkehrt?

Theoretisch können Sie nach dem Senden aller vier Nachrichten direkt in den CLOSE-Status wechseln. Das Netzwerk ist jedoch möglicherweise unzuverlässig und die letzte Bestätigung geht möglicherweise verloren. Daher wird der Status TIME_WAIT verwendet, um möglicherweise verlorene ACK-Nachrichten erneut zu senden .

3. Zusammenfassung

„TCP/IP Detaillierte Erklärung Band 1: Protokoll“ verfügt über ein TCP-Zustandsübergangsdiagramm, das sehr repräsentativ ist und jedem hilft, die Zustandsänderungen des Drei-Wege-Handshakes und der Vier-Wege-Welle zu verstehen. Wie in der folgenden Abbildung dargestellt, repräsentieren die dicken durchgezogenen Pfeile normale Client-Statusübergänge und die dicken gepunkteten Pfeile normale Server-Statusübergänge.

TCP-Zustandsübergangsdiagramm.jpg

Volltextreferenz: https://blog.csdn.net/hyg0811/article/details/102366854Interviewer , fragen Sie mich nicht nach drei Handschlägen und vier Wellen_Ape Man Valleys Blog-CSDN-Blog_Fragen Sie mich nach jemandem, der ständig Nachrichten an den Server sendet Anfrage , das ist immer noch eine dynamische IP, was soll ich tun?