Warum wird ein TCP-Socket durch ein 4-Tupel identifiziert?

Neuling im Networking hier. Ich lese das Buch Computer Networking (3. Auflage) und in Abschnitt 3.2 wird Multiplexing / Demultiplexing für UDP und TCP behandelt.

Im UDP-Protokoll wird ein Socket durch die Quell-IP und den Quellport eindeutig identifiziert.

Im TCP-Protokoll wird der Socket durch die Quell-IP, den Quell-Port, die Ziel-IP und den Ziel-Port eindeutig identifiziert. Warum benötigt das TCP-Protokoll zwei zusätzliche Informationen, damit der empfangende Host das Segment korrekt demultiplext und an den richtigen Prozess sendet?

Der einzige Grund, warum ich mir vorstellen kann, warum dies notwendig ist, ist, wenn Clients das TCP-Segment immer an denselben Port wie das Verbindungsanforderungssegment senden. Beispielsweise sendet mein Browser immer Daten an Port 80 des Servers, obwohl der Server einen TCP-Socket speziell für diese Sitzung an einem anderen Port eingerichtet hat. In diesem Fall muss TCP die Quell-IP- und Quellport-Informationen verwenden, um den richtigen Socket zu demultiplexen. Es kann sich nicht nur auf die Quell-IP-Informationen verlassen, da ein einzelner Host mehrere Sitzungen einrichten kann, sondern sich jede Sitzung an einem anderen Port befinden muss.

Der Grund, warum UDP dieses Problem nicht hat, liegt darin, dass die Ziel-IP / Port-Kombination den Socket identifiziert, an den der Prozess angehängt ist, der die Anforderung verarbeitet, da in UDP nicht mehrere neue Sockets für Anforderungen "erzeugt" werden.

Ist das richtig oder bin ich zu dem falschen Schluss gekommen?

Leider werden die Dinge verwirrend, da es zwei verschiedene Definitionen von Socket gibt. Der TCP-RFC verwendet den Begriff Socket, um sich auf eine Kombination aus Adresse und Port zu beziehen, aber Berkerly-Sockets und ihre Derivate (die API, die von so ziemlich jeder heute verwendeten praktischen IP-Implementierung verwendet wird) verwenden den Begriff Socket, um sich auf eine Art von Betrieb zu beziehen Systemkommunikationsobjekt.

Warum benötigt das TCP-Protokoll zwei zusätzliche Informationen, damit der empfangende Host das Segment korrekt demultiplext und an den richtigen Prozess sendet?

Es geht nicht nur um den richtigen Prozess, sondern auch um das richtige Kommunikationsobjekt.

Der einzige Grund, warum ich mir vorstellen kann, warum dies notwendig ist, ist, wenn Clients das TCP-Segment immer an denselben Port wie das Verbindungsanforderungssegment senden. Zum Beispiel sendet mein Browser immer Daten an Port 80

Tun sie.

obwohl der Server einen TCP-Socket speziell für diese Sitzung an einem anderen Port eingerichtet hat.

Dies scheint ein weit verbreitetes Missverständnis zu sein, das wahrscheinlich auf die unterschiedlichen Definitionen von Socket zurückzuführen ist. Durch das Akzeptieren einer Verbindung wird ein neues Kommunikationsobjekt (Socket im Sinne von Berkerly Sockets) erstellt, jedoch keine neue IP / Port-Kombination (Socket im Sinne von TCP RFC) auf dem Server zugewiesen.

Der Grund, warum UDP dieses Problem nicht hat, liegt darin, dass die Ziel-IP / Port-Kombination den Socket identifiziert, an den der Prozess angehängt ist, der die Anforderung verarbeitet, da in UDP nicht mehrere neue Sockets für Anforderungen "erzeugt" werden.

Richtig (vorausgesetzt, Ihr Absatz verwendet "Socket" im Sinne von Berkerly Sockets).

Im UDP-Protokoll wird ein Socket durch die Quell-IP und den Quellport eindeutig identifiziert.

Im TCP-Protokoll wird der Socket durch die Quell-IP, den Quell-Port, die Ziel-IP und den Ziel-Port eindeutig identifiziert. Warum benötigt das TCP-Protokoll zwei zusätzliche Informationen?

Hinweis: Für die TCP-Terminologie ist der Socket das Adress-Port-Paar. Ein Paar Sockets definiert die Verbindung . (Gemäß RFC 793 p5)

Ich fürchte, Sie irren sich über UDP, das zwar nicht wirklich "Sockets" hat - auch wenn die Berkeley Sockets-Bibliothek sie so nennt, und es ist vernünftig, ein Adress-Port-Paar aufzurufen - Multiplexe im Wesentlichen der gleiche Weg wie TCP.

Eine typische Situation, in der Sie dies sehen können, sind mehrere DNS-Auflösungen gleichzeitig von einem Host auf denselben DNS-Server, wobei eindeutig nur die Quellportnummer notwendigerweise unterschiedlich ist. Sie sehen, dass dies genau die gleiche Situation ist wie bei mehreren gleichzeitigen TCP-Verbindungen von einem Client zu einem einzelnen Webserver.

UDP verfügt über verbindungslose Datagramme. Host A sendet das Datagramm aus einem Adress-Port-Paar, das an ein Adress-Port-Paar bei B gerichtet ist, das normalerweise, aber nicht immer, spiegelbildlich antwortet. Wenn man lockerer von der "Kommunikation" spricht, arbeitet sie über genau das gleiche 4-Tupel wie eine TCP-Verbindung.

Manchmal wird ein Verweis auf ein 5-Tupel von (Procotol, Quelladresse, Quellport, Zieladresse, Zielport) angezeigt, wobei das Protokoll 17 für UDP, 6 für TCP usw. lautet. Dies ist, wofür die meisten Firewalls, Router usw. verwendet werden NAT und ähnliche Operationen zur Identifizierung dieses kommunizierenden Paares.

obwohl der Server einen TCP-Socket speziell für diese Sitzung an einem anderen Port eingerichtet hat

Ich befürchte, Sie irren sich auch in Bezug auf TCP, möglicherweise aufgrund des Terminologiekonflikts zwischen der Definition des TCP-Protokolls (RFC 793) und seiner häufigsten praktischen Implementierung, der Berkeley Sockets Library, wie sie in Unix verwendet wird, und allem, von dem abstammt es.

Wenn Sie sich auf das Protokoll konzentrieren, ist es viel klarer: Es gibt keinen "anderen Port". Der Web - Server ist nur abhört, beispielsweise 1.1.1.1 Port 80. Der Client nur sendet aus, zur Illustration 2.2.2.2 Port 56789. Jedes einzelne Paket 1.1.1.1:80 zu 2.2.2.2:56789 oder umgekehrt sein wird , ;; leicht zu überprüfen durch Betrachten von Paketen mit tcpdump / wireshark / etc.

(Um ganz kurz auf die Berkeley-Implementierung einzugehen, wird eine TCP- Verbindung durch eine Ganzzahl dargestellt, die normalerweise aber verwirrend aufgerufen wird sockfd. Ein TCP- Socket wird durch a dargestellt struct sockaddr. Der accept()Systemaufruf spricht sehr verwirrend davon, einen "neuen verbundenen Socket" zu erstellen, womit er gemeint ist neue VerbindungStruktur im verbundenen Zustand. Das Tupel dieser resultierenden Sache wäre in unserem Beispiel (1.1.1.1, 80, 2.2.2.2, 56789). In Bezug auf UDP können Sie in der Bibliothek UDP als verbunden betrachten. Dies ist eine bequeme, wenn auch völlig falsche Art, den UDP-Datagrammaustausch zwischen zwei Prozessen zu beschreiben, und bedeutet lediglich, dass sich die Struktur an das entfernte Adress-Port-Paar erinnert, das das UDP programmatisch macht "Verbindung" sieht genauso aus wie eine TCP. Denken Sie daran, dass die Berkeley-Bibliothek nicht nur für IP gedacht ist und Verallgemeinerungen verschiedener zugrunde liegender Netzwerksysteme enthält. Wenn Sie diesen Begriffen der Netzwerkprogrammierung folgen möchten, empfehle ich Stack Overflow, das viele sehr kompetente Netzwerkprogrammierer hat.)

Im UDP-Protokoll wird ein Socket durch die Quell-IP und den Quellport eindeutig identifiziert.

Bitte mischen Sie Netzwerkprogrammierung (Sockets) nicht mit Netzwerkprotokollen.

Im Fall von UDP haben Sie jedoch auch dieses 4-Tupel!

Der Unterschied zwischen TCP und UDP besteht darin, dass UDP keine festen Verbindungen verwendet, sodass ein Socket zum Senden von Daten an verschiedene Computer und / oder verschiedene Zielports verwendet werden kann.

Aus diesem Grund speichert das Betriebssystem nur 2 Elemente des 4-Tupels (IP-Adresse und Portnummer des lokalen Ports), während die anderen 2 Elemente (IP-Adresse und Portnummer des anderen Computers) von der Anwendung bereitgestellt werden müssen (in die sendto()Funktion).

Andererseits ist TCP verbindungsorientiert und ein Socket beschreibt eine Verbindung zwischen zwei Computern. Daher kann ein Socket nur zum Senden von Daten an einen bestimmten TCP-Port eines bestimmten Computers verwendet werden (mithilfe der send()Funktion).

Dies bedeutet, dass alle 4 Elemente (und nicht nur 2) des 4-Tupels für den Socket festgelegt sind, sodass das Betriebssystem alle 4 Elemente speichern kann und die Anwendung nicht 2 der 4 Elemente bereitstellen muss.

Wenn das Buch, das Sie lesen, "Computer Networking - Ein Top-Down-Ansatz" von Jim Kurose ist, lesen Sie und ich dasselbe Buch. :-) Zu Ihrer Information, das Buch gibt tatsächlich an, dass das Zwei-Tupel, das einen UDP-Socket identifiziert, auf der Ziel-IP (und nicht der Quell-IP) und dem Port basiert. Zumindest heißt es in der 7. Ausgabe.

Um Ihre Frage zu beantworten, ist TCP verbindungsorientiert, während UDP verbindungslos ist. Wenn eine TCP-Anforderung zwischen einem Host und einem Server hergestellt wird, möchte jede Seite dieser Verbindung sicher sein, dass nachfolgende Anforderungen dieselbe Verbindung verwenden (andernfalls ist es sinnvoll, ein verbindungsorientiertes Protokoll wie TCP zu verwenden?). Und da zwei Datensegmente mit derselben Ziel-IP und demselben Port, aber unterschiedlichen Quell-IPs und Ports zwei separate Sockets auf der Serverseite verwenden, besteht die einzige Möglichkeit, sicherzustellen, dass nachfolgende Anforderungen denselben Socket wie die ursprüngliche Anforderung verwenden, darin, beide Quell- Sockets zu verwenden und Ziel-IP / Port, wenn Datensegmente mit ihren korrekten Sockets abgeglichen werden.

Im Gegensatz dazu können Sie sich UDP als das Einrichten einer neuen Verbindung (und damit eines neuen Sockets) mit jeder separaten Anforderung vorstellen. Da Sie sich nicht um die Verwendung des gleichen Sockets wie bei früheren Anforderungen kümmern müssen, müssen Sie die Quell-IP / den Quell-Port nicht angeben, wenn Sie angeben, an welchen UDP-Socket das Segment weitergeleitet werden soll. Daher ist ein Zwei-Tupel ausreichend.