Was ist eine halb offene TCP-Verbindung und eine halb geschlossene TCP-Verbindung?

Ich versuche zu verstehen, was der Unterschied zwischen halb offener TCP-Verbindung und halb geschlossener TCP-Verbindung ist. Kann jemand genau sagen, was das ist?

Dieser Beitrag erweitert halb geschlossene Verbindungen. Für halboffene Verbindungen siehe die korrekte Beschreibung von KContreau.

Was sind halbgeschlossene Verbindungen? Oder: Es ist kein Bug - es ist ein Feature!

Jede TCP-Verbindung besteht aus zwei Halbverbindungen, die unabhängig voneinander geschlossen werden. Wenn also ein Ende eine FIN sendet, kann das andere Ende nur diese FIN bestätigen (anstatt sie mit FIN + ACK zu bestätigen), wodurch dem FIN-sendenden Ende signalisiert wird, dass noch Daten zu senden sind. So landen beide Enden in einem anderen stabilen Datenübertragungszustand als ESTABLISHED - nämlich FIN_WAIT_2 (für das Empfangsende) und CLOSE_WAIT (für das Sendeende). Eine solche Verbindung wird als halb geschlossen bezeichnet, und TCP wurde tatsächlich für die Unterstützung dieser Szenarien entwickelt. Halb geschlossene Verbindungen sind daher eine TCP-Funktion.

Die Geschichte der halbgeschlossenen Verbindung

Während RFC 793 nur den Raw-Mechanismus beschreibt, ohne auch nur den Begriff "halb geschlossen" zu erwähnen, geht RFC 1122 in Abschnitt 4.2.2.13 auf diesen Punkt ein. Sie mögen sich fragen, wer zum Teufel diese Funktion braucht. Die Entwickler von TCP implementierten auch TCP / IP für das Unix-System und mochten, wie jeder Unix-Benutzer, die E / A-Umleitung. Laut W. Stevens (TCP / IP, Abbildung, Abschnitt 18.5) war der Wunsch, TCP-Streams per E / A umzuleiten, die Motivation, das Feature einzuführen. Dadurch kann die FIN-Bestätigung die Rolle des EOF übernehmen oder als EOF übersetzt werden. Es handelt sich also im Grunde genommen um eine Funktion, mit der Sie spontan Interaktionen im Anforderungs- / Antwortstil auf der Anwendungsebene erstellen können, bei denen das FIN "Anforderungsende" signalisiert.

Wenn TCP eine Verbindung herstellt, gilt dies als garantiert, da ein Handshake stattfindet:

1. Der initiierende Computer sendet die Verbindungsanforderung und sendet eine SYN
2. Der antwortende Computer erteilt die Anfrage und antwortet mit einem SYN-ACK
3. Der initiierende Computer sendet eine Bestätigung und antwortet mit einer ACK

An diesem Punkt wird die Verbindung hergestellt und der Datenfluss beginnt. Im Gegensatz dazu ist ein UDP-Paket nicht garantiert und wird nur in der Hoffnung gesendet, dass es dort ankommt.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Offiziell handelt es sich laut RFCs um eine halboffene TCP-Verbindung, wenn eine Seite der eingerichteten Verbindung abgestürzt ist und keine Benachrichtigung gesendet hat, dass die Verbindung beendet wurde. Dies ist heute nicht die übliche Verwendung.

Inoffiziell, wenn auf eine embryonale Verbindung Bezug genommen werden kann, bei der es sich um eine Verbindung handelt, die gerade hergestellt wird.

http://en.wikipedia.org/wiki/Embryonic_connection

Half-closed ist das Gegenteil dieser inoffiziellen Definition. Es ist ein Zustand irgendwo in der Mitte, in dem die Computer die hergestellte Verbindung abbauen.

Die anderen Typen haben ziemlich anständig beschrieben, was halb offene und halb geschlossene Verbindungen eigentlich sind , aber die Idee von halb offenen Verbindungen wird auch oft im Zusammenhang damit gesucht, dass sie ein PROBLEM sind.

Es gibt Argumente im Internet, was die Terminologie "halb offen" oder "halb geschlossen" bedeuten soll, aber für mich ist Terminologie nur semantisch. Einige sagen, dass "halboffene" Verbindungen ein "Problem" sind, während "halbgeschlossene" ein Designmerkmal sind, mit dem Sie Ihren Sendestream schließen können, indem Sie den Sendestream schließen, bevor der Dateidownload im halbgeschlossenen Zustand abgeschlossen ist ( wie die anderen User beschrieben).

Was jedoch das andere Problem betrifft ... das "Problem": Es ist ein 3-Wege-Handshake erforderlich, um eine TCP-Verbindung herzustellen, und ein 4-Wege-Handshake, um sie zu schließen.

TCP weist eine Sicherheitsanfälligkeit dahingehend auf, dass das endgültige FIN-Paket, das an einen Client gesendet wird, möglicherweise von Routern / Netzwerken verworfen werden kann, was zu einer Verbindung führt, die halb offen ist, als die eigentliche Absicht bestand, die Verbindung vollständig zu schließen. Diese und ähnliche Ansätze sind beliebte Arten von Denial-of-Service-Angriffen, da sie nicht viel Bandbreite erfordern und je nach Serverimplementierung möglicherweise wertvolle Handles, Sockets und Threads verschlingen. Sie können jedoch auch in der realen Welt auftreten mit zunehmender Frequenz dank unserer schlampigen Mobilfunkanbieter.

Betriebssysteme haben versucht, halboffenen DDoS-Angriffen entgegenzuwirken, indem sie die Anzahl der halboffenen / geschlossenen Verbindungen, die zu einem bestimmten Zeitpunkt im Betriebssystem vorhanden sein können, und die maximale Verweildauer von Verbindungen in a begrenzt haben halboffener / geschlossener Zustand. Das letzte Mal habe ich persönlich nachgesehen, aber das Zeitlimit unter Windows war ziemlich hoch (2 Tage, wenn ich mich recht entsinne).

Dieser Zustand wird durch die optionale Eigenschaft von TCP-Keep-Alives noch verschlimmert, die bei vollständiger Implementierung als Lösung auf Protokollebene (im Gegensatz zur Anwendungsebene) zum Erkennen toter / Zombie-Verbindungen gedacht sind. Bei der Entwicklung von TCP war die Bandbreite jedoch erheblich höher als heute, und es gab Bedenken, dass Mandadory Keep-Alive-Timer für TCP zu "gesprächig" wären. Daher sind Keep-Alives optional, werden im Allgemeinen nicht verwendet und können von Routern gemäß RFC1122 nicht garantiert übertragen werden. Selbst wenn Sie Keep-Alives auf der TCP-Ebene aktivieren, um das Szenario zu erkennen / zu handhaben, stellen Sie möglicherweise fest, dass einige Router die Keep-Alive-Pakete ablegen, wenn der Datenverkehr um die Welt läuft Möglicherweise ein weiteres seltenes Szenario zu testen.

Half-Open-Verbindungen stellen eine technische Herausforderung für Codierer dar, die TCP-basierte Server schreiben, insbesondere, weil sie in Zeiten hoher Auslastung ... und normalerweise auch auf Produktionsservern ... ungewollt zufällig auftreten können schwer zu bemerken in Alpha / Beta-Testphasen. Ich habe festgestellt, dass sie bei etwa 1 von 40.000 Verbindungen auf Servern auftreten, die 2,5 Millionen Verbindungen pro Tag verarbeiten. Diese Zahlen hängen jedoch von Ihren Verkehrsbedingungen und den Verkehrsbedingungen in allen Bereichen des Internets zwischen Ihrem Server und dem Client ab .

Als Ingenieur kann es schwierig sein, Probleme aufzuspüren, die selten und nur auf aktiven, bereitgestellten Servern auftreten. Daher ist es wichtig, diesen seltenen Verbindungsstatus beim Schreiben von TCP-Servercode zu simulieren, um zu analysieren, wie Ihr Server wann reagiert mit dieser Situation konfrontiert. Wenn Ihr TCP-Server beispielsweise eine statische Anzahl von Worker-Threads verwendet, werden diese möglicherweise alle von Zombie-Verbindungen verbraucht, wenn Sie sie beispielsweise für die Produktion bereitstellen. Wenn für Verbindungen viel Arbeitsspeicher erforderlich ist, kann das Endergebnis einem Speicherverlust ähneln. usw. usw.

Ohne eine 100% funktionsfähige Keep-Alive-Lösung überlässt TCP es der Benutzerebene, zu bestimmen, wie halboffene / geschlossene Verbindungen behandelt werden. Daher muss Ihr Code über einen Plan / Mechanismus zum Erkennen, Zeitlimitüberschreiten und Reinigen verfügen. Ressourcen aufstocken, wenn dieser Zustand eintritt ... das heißt ... vorausgesetzt, dies ist ein von Ihnen erfundenes Protokoll und nicht einer der vielen (schlechten) offenen Standards, die Programmierer normalerweise verwenden. Natürlich beziehe ich mich auf Protokolle wie HTTP, die ausschließlich über TCP laufen. Diese Protokolle werden nach Meinung dieses Programmierers extrem überbewertet.

Angesichts der Schwächen von TCP und seiner unglücklichen Beliebtheit bei der Übertragung von HTTP / Web-Verkehr haben intelligente Unternehmen nach einem Ersatz gesucht. Zum Beispiel experimentierte Google mit einem Protokoll namens QUIC, das HTTP über UDP überträgt. Es gibt auch ein offenes Protokoll namens TSCP. Keines dieser Protokolle hat jedoch breite Akzeptanz gefunden.

In der Regel baue ich alle meine eigenen Server so auf, dass sie ausschließlich mit meinem eigenen UDP-basierten Protokoll kommunizieren. UDP ist jedoch kniffliger als Sie vielleicht denken, und ich habe das Gefühl, dass ich es immer weiter optimieren muss, um schneller, intelligenter, latenter und überlasteter zu sein ... aber zumindest muss ich mich nicht mehr um halboffene Verbindungen kümmern. )

Beste Erklärung für die Beendigung der TCP-Verbindung

In TCP 3-way Handshake Process haben wir untersucht, wie die Verbindung zwischen Client und Server im Transmission Control Protocol (TCP) unter Verwendung von SYN-Bitsegmenten hergestellt wird. In diesem Artikel werden wir untersuchen, wie eine TCP-enge Verbindung zwischen Client und Server hergestellt wird. Hier müssen wir auch Bitsegmente an den Server senden, deren FIN-Bit auf 1 gesetzt ist.

11

So funktioniert der Mechanismus in TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

mehr zu: https://www.geeksforgeeks.org/tcp-connection-termination/

Eine halb geschlossene Verbindung ist ein Prozess, der hergestellt wird, wenn ein Ende des Servers und des Clients die Verbindung beenden möchten. TCP ist ein verbindungsorientierter Prozess, daher wird jeder Socket für eine bestimmte Anwendung geöffnet. In TCP besteht kein Druck, die Anwendung zu beenden. Somit verlängert ein verbindungsorientierter Prozess die Beendigung mit Wartesignalen. Dies wird als halb geschlossen in TCP (Verbindung) bezeichnet