Socket und Port, Verbindungen unterscheiden?



  • Hallo,
    habe versucht, den Unterschied zwischen einem Socket und einem Port herauszufinden. Nun bin ich soweit, dass ein Socket immer das Ende einer Kommunikationsverbindung darstellt. Ein Port wird hingegen von TCP verwendet, um zusammen mit der IP-Adresse eine Verbindung zwischen zwei Prozessen eindeutig zu spezifizieren. Jetzt kann man aber mehrere Sockets an einen Port binden, d.h. ein Socket ist nicht gleich einem Port.
    Meine Frage: Wie wird dann zwischen den einzelnen Sockets unterschieden? Auf TCP Ebene dürfte das nicht möglich sein, TCP verwendet ja nur die IP-Adresse und den Port. Findet das ganze auf der Anwendungsschicht (im TCP/IP Stack) mit einem speziellen Protokoll statt, d.h. gibt es dann einen zusätzlichen Header, der zusammen mit den Daten in das TCP-Paket eingepackt wird? Und wenn das ganze über solch ein Protokoll geschieht, wie heißt es, sodass ich dazu weitere Informationen finde? Wenn es nicht über ein auf TCP aufsetzendes Protokoll passiert, wie wird dann zwischen den einzelnen Sockets unterschieden?
    Ich hoffe ihr könnt mir weiterhelfen!!!
    Danke...



  • Amateur schrieb:

    Jetzt kann man aber mehrere Sockets an einen Port binden,...

    Nein, diese Annahme ist falsch. Ein Socket ist ein Kommunikationsendpunkt, je nach Protokoll unterschiedlich definiert, bei TCP/IP durch IP Adresse und Port.
    Die identifizieren diesen eineindeutig. Es kann nur immer ein Socket dafür registriert werden. Was aber geht, ein Socket kann mehrere Verbindungen akzeptieren(sprich ein Webserver am Port 80 z.b. kann viele Clients gleichzeitig akzeptieren.) Dabei ist es Sache der Applikation diese verschiedenen Anfragen auseinander zu halten. Je nach Technologie und Sprache sind die Sockets unterschiedlich stark abstrahiert. In C z.b. würde man bei nem accept nen Handle zurückbekommen über dieses man sich immer genau auf eine betimmte Verbindung beziehen kann. In C# kann man mit Callbacks arbeiten die immer aufgerufen werden für jede neue Verbindung. Usw., sind nur zwei Beispiele.

    Es gibt schon eine 1:1 Beziehung zwischen Sockets und IPAdresse+Port, aber Sockets beherschen ja nicht nur TCP. Deshalb sind Sockets viel allgemeinere Kommunikationsendpunkte.



  • Ok danke...
    Wenn ich dich richtig verstehe, kann ein Server auf einem Port mehrere Verbindungen annehmen, die er dann je nach Bibliothek mit einem Handle oder ähnlichem unterscheidet. Die Unterscheidung würde dann z.B. über die IP und den Port des Clients, der den anderen Endpunkt darstellt, passieren?
    Kann ein Client denn auch über einen Socket mehrere Verbindungen herstellen? Würde dabei dann die Unterscheidung über die IP und den Port des Servers passieren oder ist das bei einem Client nicht möglich?



  • Falsch.

    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.
    Danach wird diese Verbidung einem freien Port zugewiesen und der Port 80 wieder für weitere Verbindungensversuche freigegeben.
    Ein Webserver kommuniziert nie über Port 80 außer beim Verbindungsaufbau.
    Auch auf dem Client wird der Port 80 nicht verwendet. Es wird hier auch der Nächste freie genommen.

    Client:Port 32456 >> Server:Port 80 >> Server: Port 32326 >> Client:Port 32456

    Dies ist natürlich jetzt einfach erklärt denn sonst müsste ich dir noch erklären warum dann NAT über Port 80 funktioniert obwohl es ein anderen Serverport ist.

    Also merke Dir: Es gibt eine Listensocket und einen Connectsocket.
    Der Rest passiert im Protokoll.



  • Das stimmt doch gar net. Schau dir einfach nen Wireshark Mitschnitt z.B. an.
    Der Client sendet eine Anfrage auf den Server Port 80 und von dort kommt auch die Antwort. Bei HTTP 1.0 wird die Verbindung danach wieder geschlossen und muss bei einem erneuten Request neu aufgebaut werden, und bei HTTP 1.1 wird sie offen gehalten. Das die Anzahl an gleichzeitig verarbeitbaren Clients begrenzt ist, ist klar. Aber das immer nur eine Verbindung besteht ist falsch.

    Vielleicht war HTTP auch nen eher ungünstiges Beispiel, weil HTTP ja aus der Anwendungsschicht kommt und der ja eh egal sein kann worüber sie die Daten bekommt. HTTP ist ja noch net mal auf TCP als Transportprotokoll angewiesen.



  • Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂



  • Zitat WIKI

    http://de.wikipedia.org/wiki/Transmission_Control_Protocol

    Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert. Ein Endpunkt stellt ein geordnetes Paar dar, bestehend aus IP-Adresse und Port. Ein solches Paar bildet eine bi-direktionale Software-Schnittstelle und wird auch als Socket bezeichnet. Mit Hilfe der IP-Adressen werden die an der Verbindung beteiligten Rechner identifiziert; mit Hilfe der Ports werden dann auf den beiden beteiligten Rechnern die beiden miteinander kommunizierenden Programme identifiziert.

    Durch die Verwendung von Portnummern auf beiden Seiten der Verbindung ist es beispielsweise möglich, dass ein Webserver auf einem Port (normalerweise Port 80) gleichzeitig mehrere Verbindungen zu einem anderen Rechner geöffnet haben kann (Dienst, Server macht "listen" auf Port 80 und setzt bei "accept" für jeden Client die Verbindung auf anderem Port fort. Mehrmals "listen" auf dem gleichen Port ist nicht möglich -> "port in use". Client benutzt beliebige Portnummer).

    Hat auch nichts mit HTTP zu tun.
    Dies sind Grundlagen von TCP und Sockets.
    HTTP ist nur ein Protokoll welches auf TCP aufbaut.



  • fricky schrieb:

    Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂

    Falsch.
    Ein Server kann maximal etwas weniger als 65535 Verbindung gleichzeitig halten.
    Mehr Ports gibt es nicht.
    Und es spielt keine Rolle wieviele IP-Adressen ihm zugewiesen wurden.
    Es gibt nur max. 65535 Ports auf einem Rechner egal wieviele IP-Adressen er noch hat.



  • Unix-Tom schrieb:

    fricky schrieb:

    Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂

    Falsch.
    Ein Server kann maximal etwas weniger als 65535 Verbindung gleichzeitig halten.
    Mehr Ports gibt es nicht.
    Und es spielt keine Rolle wieviele IP-Adressen ihm zugewiesen wurden.
    Es gibt nur max. 65535 Ports auf einem Rechner egal wieviele IP-Adressen er noch hat.

    falsch!
    eine tcp-verbindung setzt sich zusammen aus lokaler ip-adresse und lokaler portnummer und remote ip-adresse und remote portnummer (4-tupel). d.h. ein server, welcher auf einer portnummer lauscht, kann (theoretisch, nicht alle kombinationen sind immer möglich) zu je 4294967296 clients 65536 verbindungen haben.
    🙂



  • Wenn ich einen Socket an eine lokale Adresse binde, wird mir das mit "Address already in use" bereits abgewiesen, wenn auf diesem Interface und diesem Port bereits ein offener Socket vorhanden ist. Komischerweise passiert dies bevor ich dem Netzwerkstack überhaupt mitteile, wie die Remote-Adresse lautet. Von daher kann an dieser Angabe irgendwas nicht stimmen...



  • Na egal. Glaube was Du möchtest.
    Vielleicht vesetzt dein Glaube mal Berge und Dein Rechner kann das.
    Könntest dann teuer an Ebay, und ähnliche verkaufen den die würden dadurch sehr sparen.
    Bräuchten dann nicht tausende Rechner um alle User bedienen zu können.



  • LordJaxom schrieb:

    Wenn ich einen Socket an eine lokale Adresse binde, wird mir das mit "Address already in use" bereits abgewiesen, wenn auf diesem Interface und diesem Port bereits ein offener Socket vorhanden ist. Komischerweise passiert dies bevor ich dem Netzwerkstack überhaupt mitteile, wie die Remote-Adresse lautet. Von daher kann an dieser Angabe irgendwas nicht stimmen...

    ja, das ist beim 'listen' so. wenn du zwei sockets auf dem gleichen port in den listen-modus schalten könntest, wüsste das socket-interface nicht, welchen davon es beim verbindungsversuch nehmen soll. aber wenn es einen gibt, der lauscht, dann können sich viele-viele rechner, und jeder davon 2^16 * simultan mit diesem port verbinden. natürlich nur rein theoretisch, weil durch rechen- und speicherkapazität grenzen gesetzt sind.
    🙂



  • fricky schrieb:

    ja, das ist beim 'listen' so. wenn du zwei sockets auf dem gleichen port in den listen-modus schalten könntest, wüsste das socket-interface nicht, welchen davon es beim verbindungsversuch nehmen soll. aber wenn es einen gibt, der lauscht, dann können sich viele-viele rechner, und jeder davon 2^16 * simultan mit diesem port verbinden. natürlich nur rein theoretisch, weil durch rechen- und speicherkapazität grenzen gesetzt sind.
    🙂

    Der Socket, den accept zurückliefert, hat aber als Localport nicht denjenigen, auf dem gehorcht wird, sondern einen freien Highport (nachzuprüfen mittels getsockaddr()). Es gibt nach mehreren Accepts nicht mehrere Sockets mit demselben Localport auf diesem Rechner.



  • LordJaxom schrieb:

    Der Socket, den accept zurückliefert, hat aber als Localport nicht denjenigen, auf dem gehorcht wird, sondern einen freien Highport (nachzuprüfen mittels getsockaddr()). Es gibt nach mehreren Accepts nicht mehrere Sockets mit demselben Localport auf diesem Rechner.

    getsockaddr() kenne ich nicht. meinst du getsockname()? kann es sein, dass die funktion dir die remote portnummer anzeigt? sockets sind übrigens keine 1:1 abbildung auf tcp-ports, sondern virtuelle verbindungsendpunkte. wenn dein server auf, sagen wir mal, port 1234 lauscht, dann ist deine lokale portnummer für alle verbindungen auf diesem port immer die 1234. (du kannst es z.b. mit wireshark nachprüfen) und natürlich wird für jedes 'accept' ein neuer socket generiert, da er eine neue verbindung darstellt. die anzahl dieser sockets kann übrigens über 65536 liegen, wenn verschiedene rechner sich auf deinen port verbinden (also nicht so, wie linux-tom meint).
    🙂



  • Ich schreibs nochmals:

    Listen wird auf einen Port gesetzt. Hier wird bei Aufruf schon definiert welche IP-Adresse diesem Port zugeordnet wird.

    Verbindet sich nun ein Client auf diesen Port wird Acccept aufgerufen und dem Socket ein freier HIGHPORT zugewiesen.
    Über diesem und dem Clientport findet die Kommunikation statt.
    Listen hört nun wieder auf dem Listenport.
    Es gibt also keine weiter kommunikation zw. dem Listenport und dem Clientport.
    Es ist auch nicht möglich z.B. dem Port 80 auf eine IP zu legen und den gleichen Port auf eine andere IP.
    Es gibt nur max. 65535 Port pro 32Bit-Rechner.
    Port sind 16-Bit-Zahlen und somit bis 65535 benutzbar.
    Mehrere IPADRESSEN erhöhen die Portanzahl nicht.
    Weiters gibt es auch noch Kernellimits dafür.
    Auf weitere Lernresistenz werde ich jetzt auch nicht mehr Antworten.
    Weiteres steht bei WIKIPEDIA.



  • Naja was ist denn nun genau richtig?
    Also ich hab folgenden Link gefunden: http://www.freesoft.org/CIE/Topics/20.htm
    Da wird auch gesagt, dass mehrere aktive Sockets auf einem Port laufen...



  • Außerdem hab ich eben noch folgendes bei der englischen Wikipedia gefunden:

    A server may create several concurrently established TCP sockets with the same local port number and local IP address, each mapped to its own server child-process and serving its own client process. These are treated as different sockets by the operating system, since the remote client address and/or socket numbers are different.

    Wenn ich das nicht falsch verstehe, kann ein Server mehrere Sockets an einem Port laufen haben, weil der die Verbindungen anhand der Clientadressen und -sockets unterscheiden kann.



  • Unix-Tom hat Unrecht.



  • Unix-Tom schrieb:

    Verbindet sich nun ein Client auf diesen Port wird Acccept aufgerufen und dem Socket ein freier HIGHPORT zugewiesen.

    nein, accept() wird von der anwendung aufgerufen und wartet (im normalfall) auf eine verbindung. sobald eine verbindung steht, liefert accept() einen socket zurück, über den die kommunikation stattfinden kann. aber... socket != port

    Unix-Tom schrieb:

    Über diesem und dem Clientport findet die Kommunikation statt.

    über diese client-socket!

    Unix-Tom schrieb:

    Listen hört nun wieder auf dem Listenport.

    listen hört die ganze zeit auf dem port.

    Unix-Tom schrieb:

    Es gibt also keine weiter kommunikation zw. dem Listenport und dem Clientport.

    es gibt keinen client-port. es gibt nur client sockets. die gleiche lokale portnummer kann sowohl vom server (listen/accept) als auch vom client (connect) auf dem gleichen rechner benutzt werden. wäre es nicht so, dann könntest du z.b. nicht mit einem rechner durchs internet surfen auf dem ein webserver läuft, denn dazu wird port 80 sowohl vom server als auch vom client benutzt.

    Unix-Tom schrieb:

    Es ist auch nicht möglich z.B. dem Port 80 auf eine IP zu legen und den gleichen Port auf eine andere IP.

    dass es mit der normalen socket-api möglich ist, kann ich jetzt nicht sagen. vom tcp-protokoll her ist es jedenfalls absolut möglich.

    Unix-Tom schrieb:

    Es gibt nur max. 65535 Port pro 32Bit-Rechner.

    totaler unfug! was haben diese beiden zahlen miteinander zu tun?

    Unix-Tom schrieb:

    Port sind 16-Bit-Zahlen und somit bis 65535 benutzbar.

    das ist die einzige, fast richtige behauptung, die du seit langem aufgestellt hast. theoretisch sind es 65536 portnummern. die portnummer 0 wird z.b. von manchen OS für spezielle zwecke verwendet, aber aus sicht des tcp-protokolls gibt es 65536 source- und 65536 destination-ports.

    Unix-Tom schrieb:

    Mehrere IPADRESSEN erhöhen die Portanzahl nicht.

    mehrere ip-adressen erhöhen die anzahl der möglichen verbindungen. es sind übrigens total abgefahrene konfigurationen möglich.

    Unix-Tom schrieb:

    Weiters gibt es auch noch Kernellimits dafür.

    du sagt mal was, das stimmt?! kompliment!

    Unix-Tom schrieb:

    Auf weitere Lernresistenz werde ich jetzt auch nicht mehr Antworten.

    aber ich! :p

    Unix-Tom schrieb:

    Weiteres steht bei WIKIPEDIA.

    lies lieber das: http://www.uic.rsu.ru/doc/inet/tcp_stevens/
    🙂



  • Unix-Tom schrieb:

    Na egal. Glaube was Du möchtest.
    Vielleicht vesetzt dein Glaube mal Berge und Dein Rechner kann das.
    Könntest dann teuer an Ebay, und ähnliche verkaufen den die würden dadurch sehr sparen.
    Bräuchten dann nicht tausende Rechner um alle User bedienen zu können.

    Du hast einfach keinen Plan. Verbindung ist identifiziert durch die 4 Kennzeichen ClientPort,ServerPort,ClientIP,ServerIP. Damit kannst
    Du auf einem Server viele Verbindungen zu Port 80 haben. Um im Ernst,
    wenn es an der Zahl der Ports läge, wieviele Verbindungen ein Rechner kann,
    wäre es da nicht einfacher, die Max. Anzahl zu erhöhen statt neue
    Rechner zu kaufen? Logisches Denken ist nicht deine Stärke...

    Also, halten wir fest

    1 Socket -> Eine Verbindung (Client Port, Client IP, Server IP, Server Port)

    Das mit dem Listen/Connectsocket hat eben genau den Grund, dass Du einen neuen
    Socket brauchst (für multithreadserver), wenn einer mit einer
    Verbdindung belegt ist. BEIDE sitzer aber nach wie vor auf dem
    selben Port.

    Du hast das FTP Vorgehen beschrieben, welches sowieso
    eher "braindead" ist.

    Gruss
    S


Anmelden zum Antworten