it-swarm.com.de

Wie stellen mehrere Clients gleichzeitig eine Verbindung zu einem Port (z. B. 80) auf einem Server her?

Ich verstehe die Grundlagen, wie Ports funktionieren. Was ich jedoch nicht verstehe, ist, wie mehrere Clients gleichzeitig eine Verbindung zu Port 80 herstellen können. Ich weiß, dass jeder Client einen eindeutigen (für ihren Computer) Port hat. Antwortet der Server von einem verfügbaren Port an den Client zurück und gibt er einfach an, dass die Antwort von 80 kam? Wie funktioniert das?

373
IamIC

Zunächst einmal ist ein "Port" nur eine Zahl. Alles, was eine "Verbindung zu einem Port" wirklich darstellt, ist ein Paket, dessen Nummer in seinem "Zielport" -Headerfeld angegeben ist.

Nun gibt es zwei Antworten auf Ihre Frage: eine für zustandsbehaftete Protokolle und eine für zustandslose Protokolle.

Für ein zustandsloses Protokoll (dh UDP) gibt es kein Problem, da "Verbindungen" nicht existieren - mehrere Personen können Pakete an denselben Port senden, und ihre Pakete kommen in beliebiger Reihenfolge an. Niemand ist jemals im "verbundenen" Zustand.

Bei einem statusbehafteten Protokoll (wie TCP) wird eine Verbindung durch ein 4-Tupel identifiziert, das aus Quell- und Zielports sowie Quell- und Ziel-IP-Adressen besteht. Wenn also zwei verschiedene Computer mit demselben Port auf einem dritten Computer verbunden sind, gibt es zwei verschiedene Verbindungen, da sich die Quell-IPs unterscheiden. Wenn derselbe Computer (oder zwei Computer hinter NAT oder auf andere Weise dieselbe IP-Adresse verwenden) zweimal eine Verbindung zu einem einzelnen Remote-Ende herstellt, werden die Verbindungen nach Quellport unterschieden (bei dem es sich im Allgemeinen um einen zufälligen Port mit hoher Nummer handelt).

Wenn ich von meinem Client aus zweimal eine Verbindung zum gleichen Webserver herstelle, haben die beiden Verbindungen aus meiner Sicht unterschiedliche Quell- und Zielports vom Webserver. Es gibt also keine Mehrdeutigkeit, obwohl beide Verbindungen die gleichen Quell- und Ziel-IP-Adressen haben.

Ports sind eine Möglichkeit, Multiplex IP-Adressen zuzuweisen, damit verschiedene Anwendungen dasselbe IP-Adresse/Protokoll-Paar abhören können. Solange eine Anwendung kein eigenes übergeordnetes Protokoll definiert, besteht keine Möglichkeit, einen Port zu multiplexen. Wenn zwei Verbindungen, die dasselbe Protokoll gleichzeitig verwenden, identische Quell- und Ziel-IPs sowie identische Quell- und Ziel-Ports haben, müssen sie dieselbe Verbindung sein.

435
Borealid

Wichtig:

Es tut mir leid zu sagen, dass die Antwort von "Borealid" ungenau und etwas falsch ist. Erstens gibt es keinen Zusammenhang mit der Zustandslosigkeit oder Staatenlosigkeit, um diese Frage zu beantworten, und vor allem ist die Definition des Tupels für einen Socket falsch.

Denken Sie zuerst an die folgenden zwei Regeln:

  1. Primärschlüssel eines Sockets: Ein Socket wird durch {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL} und nicht durch {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT} identifiziert. - Das Protokoll ist ein wichtiger Bestandteil der Definition eines Sockets.

  2. OS-Prozess- und Socket-Zuordnung: Ein Prozess kann mehreren Sockets zugeordnet sein (sie können geöffnet/abgehört werden), was für viele Leser offensichtlich sein kann.

Beispiel 1: Zwei Clients, die sich mit demselben Serverport verbinden, bedeuten: socket1 {SRC-A, 100, DEST-X,80, TCP} und socket2{SRC-B, 100, DEST-X,80, TCP}. Dies bedeutet, dass Host A eine Verbindung zu Server Xs Port 80 herstellt und ein anderer Host B ebenfalls eine Verbindung zu demselben Server X zu demselben Port 80 herstellt. Wie der Server diese beiden Sockets behandelt, hängt davon ab, ob es sich bei dem Server um einen Single - Thread oder einen Multiple - Thread handelt erklären Sie dies später). Wichtig ist, dass ein Server mehrere Sockets gleichzeitig abhören kann.

Um die ursprüngliche Frage des Beitrags zu beantworten:

Unabhängig von statusbehafteten oder zustandslosen Protokollen können zwei Clients eine Verbindung zu demselben Serverport herstellen, da wir jedem Client einen anderen Socket zuweisen können (da sich die Client-IP definitiv unterscheiden wird). Ein Client kann auch zwei Sockets haben, die mit demselben Server-Port verbunden sind, da sich diese Sockets durch SRC-PORT unterscheiden. Trotz aller Fairness erwähnte "Borealid" im Wesentlichen die gleiche richtige Antwort, aber der Verweis auf zustandslos/vollständig war irgendwie unnötig/verwirrend.

Beantworten des zweiten Teils der Frage, wie ein Server weiß, welcher Socket zu beantworten ist. Verstehen Sie zunächst, dass es für einen einzelnen Serverprozess, der denselben Port überwacht, mehr als einen Socket geben kann (möglicherweise von demselben Client oder von verschiedenen Clients). Solange ein Server weiß, welche Anforderung mit welchem ​​Socket verknüpft ist, kann er immer mit demselben Socket auf den entsprechenden Client antworten. Daher muss ein Server niemals einen anderen Port in seinem eigenen Knoten öffnen als den ursprünglichen, an dem der Client ursprünglich versucht hat bind verbinden. Wenn ein Server nach dem Binden eines Sockets andere Server-Ports zuweist, verschwendet der Server meiner Meinung nach seine Ressource und muss dies vom Client tun bind Verbinden Sie sich erneut mit dem neu zugewiesenen Port.

Der Vollständigkeit halber etwas mehr:

Beispiel 2: Es ist eine sehr interessante Frage, ob zwei verschiedene Prozesse eines Servers denselben Port überwachen können. Wenn Sie das Protokoll nicht als einen Parameter betrachten, der den Socket definiert, lautet die Antwort nein. Initiativ ist dies so, weil wir sagen können, dass in einem solchen Fall für einen einzelnen Client, der versucht, eine Verbindung zu einem Server-Port herzustellen, kein Mechanismus vorhanden ist, um zu erwähnen, welcher der beiden Empfangsprozesse der Client beabsichtigt. Dies ist das gleiche Thema, das durch Regel (2) behauptet wird. Dies ist jedoch eine falsche Antwort, da "Protokoll" ebenfalls Teil der Socket-Definition ist. Somit können zwei Prozesse in demselben Knoten nur dann denselben Port überwachen, wenn sie ein anderes Protokoll verwenden. Zum Beispiel können zwei nicht verwandte Clients (der eine verwendet TCP und der andere verwendet UDP) bind verbinde dich und kommuniziere mit demselben Serverknoten und demselben Port, aber sie müssen von zwei verschiedenen Server-Prozessen bedient werden.

Servertypen - einfach und mehrfach:

Wenn die Prozesse eines Servers einen Port überwachen, können mehrere Sockets gleichzeitig eine Verbindung zum selben Server herstellen und mit diesem kommunizieren. Wenn ein Server nur einen einzigen untergeordneten Prozess verwendet, um alle Sockets zu bedienen, heißt der Server Single-Process/Threaded, und wenn der Server viele Unterprozesse verwendet, um jeden Socket durch einen Unterprozess zu bedienen, heißt der Server Multi-Process. Prozess/Thread-Server. Beachten Sie, dass ein Server unabhängig vom Servertyp immer den gleichen Initial-Socket verwenden kann/sollte, um zu antworten (keine Notwendigkeit, einen anderen Server-Port zuzuweisen).

Vorgeschlagenes Bücher und Rest der zwei Bände, wenn Sie können.

Ein Hinweis zum Eltern/Kind-Prozess (als Antwort auf die Anfrage/den Kommentar von 'Ioan Alexandru Cucu')

Überall dort, wo ich ein Konzept in Bezug auf zwei Prozesse (A und B) erwähnte, ist zu berücksichtigen, dass sie nicht durch die Beziehung zwischen Eltern und Kind zusammenhängen. Betriebssysteme (insbesondere UNIX) ermöglichen es einem untergeordneten Prozess, alle Dateideskriptoren (FD) von den Eltern zu erben. Somit können alle Sockets (in UNIX wie OS auch Teil von FD), die ein Prozess A abhört, von vielen weiteren Prozessen A1, A2, .. abgehört werden, sofern sie durch eine Eltern-Kind-Beziehung zu A verbunden sind Ein unabhängiger Prozess B (dh ohne Eltern-Kind-Beziehung zu A) kann nicht denselben Socket abhören. Beachten Sie außerdem, dass diese Regel, dass nicht zwei unabhängige Prozesse denselben Socket abhören dürfen, auf einem Betriebssystem (oder dessen Netzwerkbibliotheken) liegt und von den meisten Betriebssystemen bei weitem befolgt wird. Man kann jedoch ein eigenes Betriebssystem erstellen, das diese Einschränkungen sehr gut verletzt.

341
KGhatak

TCP/HTTP-Überwachung von Ports: Wie viele Benutzer können denselben Port gemeinsam nutzen?

Was passiert also, wenn ein Server auf eingehende Verbindungen an einem TCP -Port wartet? Angenommen, Sie haben einen Webserver an Port 80. Angenommen, Ihr Computer hat die öffentliche IP-Adresse 24.14.181.229, und die Person, die versucht, eine Verbindung zu Ihnen herzustellen, hat die IP-Adresse 10.1.2.3. Diese Person kann eine Verbindung zu Ihnen herstellen, indem Sie einen TCP - Socket unter 24.14.181.229:80 öffnen. Einfach genug.

Intuitiv (und fälschlicherweise) gehen die meisten Leute davon aus, dass es ungefähr so ​​aussieht:

    Local Computer    | Remote Computer
    --------------------------------
    <local_ip>:80     | <foreign_ip>:80

    ^^ not actually what happens, but this is the conceptual model a lot of people have in mind.

Dies ist intuitiv, da der Client eine IP-Adresse hat und eine Verbindung zu einem Server unter IP: PORT herstellt. Da der Client eine Verbindung zu Port 80 herstellt, muss sein Port auch 80 sein. Dies ist eine vernünftige Sache zu denken, aber eigentlich nicht, was passiert. Wenn das richtig wäre, könnten wir nur einen Benutzer pro fremder IP-Adresse bedienen. Sobald ein Remote-Computer eine Verbindung herstellt, wird die Verbindung von Port 80 zu Port 80 unterbrochen, und niemand anderes kann eine Verbindung herstellen.

Drei Dinge müssen verstanden werden:

1.) Auf einem Server überwacht ein Prozess einen Port . Sobald eine Verbindung hergestellt wurde, wird sie an einen anderen Thread übergeben. Die Kommunikation beeinträchtigt niemals den Abhörport.

2.) Verbindungen werden vom Betriebssystem durch das folgende 5-Tupel eindeutig identifiziert: (lokale IP, lokaler Port, Remote-IP, Remote-Port, Protokoll). Wenn sich ein Element im Tupel unterscheidet, handelt es sich um eine völlig unabhängige Verbindung.

3.) Wenn ein Client eine Verbindung zu einem Server herstellt, wählt er einen zufälligen, nicht verwendeten Quellport höherer Ordnung aus. Auf diese Weise kann ein einzelner Client bis zu ~ 64.000 Verbindungen zum Server für denselben Zielport haben.

Das wird also wirklich erstellt, wenn ein Client eine Verbindung zu einem Server herstellt:

    Local Computer   | Remote Computer           | Role
    -----------------------------------------------------------
    0.0.0.0:80       | <none>                    | LISTENING
    127.0.0.1:80     | 10.1.2.3:<random_port>    | ESTABLISHED

Anschauen, was tatsächlich passiert

Lassen Sie uns zunächst netstat verwenden, um zu sehen, was auf diesem Computer geschieht. Wir werden Port 500 anstelle von 80 verwenden (weil auf Port 80 eine ganze Menge Dinge passieren, da es sich um einen gemeinsamen Port handelt, aber funktionell macht es keinen Unterschied).

    netstat -atnp | grep -i ":500 "

Wie erwartet ist die Ausgabe leer. Nun starten wir einen Webserver:

    Sudo python3 -m http.server 500

Hier ist noch einmal die Ausgabe von netstat:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      - 

Es gibt jetzt also einen Prozess, der aktiv auf Port 500 lauscht (Status: LISTEN). Die lokale Adresse lautet 0.0.0.0, was dem Code für "Alle lauschen" entspricht. Ein einfacher Fehler besteht darin, die Adresse 127.0.0.1 abzuhören, die nur Verbindungen vom aktuellen Computer akzeptiert. Dies ist also keine Verbindung. Dies bedeutet lediglich, dass ein Prozess angefordert wird, () an die Port-IP zu binden, und dieser Prozess ist für die Verarbeitung aller Verbindungen zu diesem Port verantwortlich. Dies weist auf die Einschränkung hin, dass nur ein Prozess pro Computer an einem Port empfangsbereit sein kann (es gibt Möglichkeiten, dies mithilfe von Multiplexing zu umgehen, dies ist jedoch ein viel komplizierteres Thema). Wenn ein Webserver Port 80 überwacht, kann er diesen Port nicht für andere Webserver freigeben.

Verbinden wir nun einen Benutzer mit unserer Maschine:

    quicknet -m tcp -t localhost:500 -p Test payload.

Dies ist ein einfaches Skript ( https://github.com/grokit/dcore/tree/master/apps/quicknet ), das einen Socket TCP öffnet und die Nutzdaten sendet (" Test payload. "In diesem Fall), wartet einige Sekunden und trennt die Verbindung. Wenn Sie netstat in diesem Fall erneut ausführen, wird Folgendes angezeigt:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      -
    tcp        0      0 192.168.1.10:500        192.168.1.13:54240      ESTABLISHED -

Wenn Sie eine Verbindung zu einem anderen Client herstellen und netstat erneut ausführen, wird Folgendes angezeigt:

    Proto Recv-Q Send-Q Local Address           Foreign Address         State  
    tcp        0      0 0.0.0.0:500             0.0.0.0:*               LISTEN      -
    tcp        0      0 192.168.1.10:500        192.168.1.13:26813      ESTABLISHED -

... das heißt, der Client hat einen anderen zufälligen Port für die Verbindung verwendet. Es gibt also keine Verwechslungen zwischen den IP-Adressen.

172
N0thing

Normalerweise gibt der Server für jeden verbindenden Client einen untergeordneten Prozess aus, der mit dem Client (TCP) kommuniziert. Der übergeordnete Server übergibt dem untergeordneten Prozess einen eingerichteten Socket, der mit dem Client kommuniziert.

Wenn Sie die Daten von Ihrem untergeordneten Server an einen Socket senden, erstellt der Stapel TCP im Betriebssystem ein Paket, das zum Client zurückgeht, und setzt den "Von-Port" auf 80.

25
m1tk4

Mehrere Clients können auf dem Server eine Verbindung zu demselben Port (z. B. 80) herstellen, da auf der Serverseite nach dem Erstellen eines Sockets und Binding (Einstellung der lokalen IP und des Ports) Listen wird für den Socket aufgerufen, der das Betriebssystem zum Akzeptieren auffordert eingehende Verbindungen.

Wenn ein Client versucht, über Port 80 eine Verbindung zum Server herzustellen, wird der Aufruf accept am Server-Socket aufgerufen. Dadurch wird ein neuer Socket für den Client erstellt, der versucht, eine Verbindung herzustellen. Auf ähnliche Weise werden neue Sockets für nachfolgende Clients erstellt, die denselben Port 80 verwenden.

Kursiv gedruckte Wörter sind Systemaufrufe.

Ref

http://www.scs.stanford.edu/07wi-cs244b/refs/net2.pdf

4
pumpkin_cat