Solución:
En primer lugar, un “puerto” es solo un número. Todo lo que realmente representa una “conexión a un puerto” es un paquete que tiene ese número especificado en su campo de encabezado “puerto de destino”.
Ahora, hay dos respuestas a su pregunta, una para los protocolos con estado y otra para los protocolos sin estado.
Para un protocolo sin estado (es decir, UDP), no hay problema porque las “conexiones” no existen: varias personas pueden enviar paquetes al mismo puerto y sus paquetes llegarán en cualquier secuencia. Nadie está nunca en el estado “conectado”.
Para un protocolo con estado (como TCP), una conexión se identifica mediante una tupla de 4 que consta de puertos de origen y destino y direcciones IP de origen y destino. Entonces, si dos máquinas diferentes se conectan al mismo puerto en una tercera máquina, hay dos conexiones distintas porque las IP de origen son diferentes. Si la misma máquina (o dos detrás de NAT o que comparten la misma dirección IP) se conecta dos veces a un solo extremo remoto, las conexiones se diferencian por Puerto de origen (que generalmente es un puerto aleatorio de números altos).
Simplemente, si me conecto al mismo servidor web dos veces desde mi cliente, las dos conexiones tendrán puertos de origen diferentes desde mi perspectiva y puertos de destino desde el servidor web. Por lo tanto, no hay ambigüedad, aunque ambas conexiones tienen las mismas direcciones IP de origen y destino.
Los puertos son una forma de multicine Direcciones IP para que diferentes aplicaciones puedan escuchar en el mismo par de dirección IP / protocolo. A menos que una aplicación defina su propio protocolo de nivel superior, no hay forma de multiplexar un puerto. Si dos conexiones que usan el mismo protocolo simultáneamente tienen direcciones IP de origen y destino idénticas y puertos de origen y destino idénticos, deben ser la misma conexión.
Importante:
Lamento decir que la respuesta de “Borealid” es imprecisa y algo incorrecta; en primer lugar, no hay relación con la estadidad o la apatridia para responder a esta pregunta y, lo más importante, la definición de la tupla para un socket es incorrecta.
Primero recuerda dos reglas a continuación:
-
Primario key de un enchufe: un enchufe se identifica por
SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOLno porSRC-IP, SRC-PORT, DEST-IP, DEST-PORT– El protocolo es una parte importante de la definición de un socket. -
Mapeo de sockets y procesos del sistema operativo: un proceso se puede asociar con (puede abrir / puede escuchar) múltiples sockets que pueden resultar obvios para muchos lectores.
Ejemplo 1: Dos clientes que se conectan al mismo puerto del servidor significa: socket1 SRC-A, 100, DEST-X,80, TCP y socket2SRC-B, 100, DEST-X,80, TCP. Esto significa que el host A se conecta al puerto 80 del servidor X y otro host B también se conecta al mismo servidor X al mismo puerto 80. Ahora, la forma en que el servidor maneja estos dos sockets depende de si el servidor es de un solo subproceso o de múltiples subprocesos (lo haré explica esto más tarde). Lo importante es que un servidor pueda escuchar varios sockets simultáneamente.
Para responder a la pregunta original de la publicación:
Independientemente de los protocolos con estado o sin estado, dos clientes pueden conectarse al mismo puerto del servidor porque para cada cliente podemos asignar un socket diferente (ya que la IP del cliente definitivamente diferirá). El mismo cliente también puede tener dos sockets que se conectan al mismo puerto del servidor, ya que dichos sockets se diferencian por SRC-PORT. Con toda justicia, “Borealid” esencialmente mencionó la misma respuesta correcta, pero la referencia a stateless / full fue un poco innecesaria / confusa.
Para responder a la segunda parte de la pregunta sobre cómo un servidor sabe qué socket responder. Primero, comprenda que para un solo proceso de servidor que está escuchando el mismo puerto, podría haber más de un socket (puede ser del mismo cliente o de diferentes clientes). Ahora, siempre que un servidor sepa qué solicitud está asociada con qué socket, siempre puede responder al cliente apropiado usando el mismo socket. Por lo tanto, un servidor nunca necesita abrir otro puerto en su propio nodo que el original en el que el cliente intentó conectarse inicialmente. Si algún servidor asigna diferentes puertos de servidor después de que se enlaza un socket, entonces, en mi opinión, el servidor está desperdiciando sus recursos y debe necesitar que el cliente se conecte nuevamente al nuevo puerto asignado.
Un poco más para completar:
Ejemplo 2: Es una pregunta muy interesante: “¿pueden dos procesos diferentes en un servidor escuchar el mismo puerto”? Si no considera el protocolo como uno de los parámetros que definen el socket, la respuesta es no. Esto es así porque podemos decir que, en tal caso, un solo cliente que intente conectarse a un puerto de servidor no tendrá ningún mecanismo para mencionar a cuál de los dos procesos de escucha pretende conectarse el cliente. Este es el mismo tema que afirma la regla (2). Sin embargo, esta es una respuesta INCORRECTA porque el ‘protocolo’ también es parte de la definición de socket. Por lo tanto, dos procesos en el mismo nodo pueden escuchar el mismo puerto solo si están usando un protocolo diferente. Por ejemplo, dos clientes no relacionados (digamos que uno está usando TCP y otro está usando UDP) pueden conectarse y comunicarse al mismo nodo de servidor y al mismo puerto, pero deben ser atendidos por dos procesos de servidor diferentes.
Tipos de servidor: único y múltiple:
Cuando los procesos de un servidor escuchan un puerto, eso significa que varios sockets pueden conectarse y comunicarse simultáneamente con el mismo proceso del servidor. Si un servidor usa un solo proceso hijo para servir todos los sockets, entonces el servidor se llama proceso único / subproceso y si el servidor usa muchos subprocesos para servir cada socket por un subproceso, entonces el servidor se llama multiproceso. servidor de proceso / subproceso. Tenga en cuenta que independientemente del tipo de servidor, un servidor puede / debe usar siempre el mismo socket inicial para responder (no es necesario asignar otro puerto de servidor).
Sugirió Libros y el resto de los dos volúmenes si puedes.
Una nota sobre el proceso padre / hijo (en respuesta a la consulta / comentario de ‘Ioan Alexandru Cucu’)
Dondequiera que mencione algún concepto en relación con dos procesos, digamos A y B, considere que no están relacionados por la relación padre-hijo. Los sistemas operativos (especialmente UNIX) por diseño permiten un proceso hijo para heredar todos los descriptores de archivo (FD) de los padres. Por lo tanto, todos los sockets (en UNIX como OS también son parte de FD) que un proceso A escucha, pueden ser escuchados por muchos más procesos A1, A2, .. siempre que estén relacionados por la relación padre-hijo con A. Pero un proceso independiente B (es decir, que no tiene relación padre-hijo con A) no puede escuchar el mismo conector. Además, también tenga en cuenta que esta regla de no permitir que dos procesos independientes escuchen el mismo socket se encuentra en un sistema operativo (o sus bibliotecas de red) y, con mucho, es obedecida por la mayoría de los sistemas operativos. Sin embargo, uno puede crear su propio sistema operativo que muy bien puede violar estas restricciones.
Escucha TCP / HTTP en puertos: ¿cómo pueden muchos usuarios compartir el mismo puerto?
Entonces, ¿qué sucede cuando un servidor escucha las conexiones entrantes en un puerto TCP? Por ejemplo, supongamos que tiene un servidor web en el puerto 80. Supongamos que su computadora tiene la dirección IP pública 24.14.181.229 y la persona que intenta conectarse con usted tiene la dirección IP 10.1.2.3. Esta persona puede conectarse con usted abriendo un socket TCP al 24.14.181.229:80. Suficientemente simple.
De manera intuitiva (y errónea), la mayoría de la gente asume que se parece a esto:
Local Computer | Remote Computer
--------------------------------
:80 | :80
^^ not actually what happens, but this is the conceptual model a lot of people have in mind.
Esto es intuitivo, porque desde el punto de vista del cliente, tiene una dirección IP y se conecta a un servidor en IP: PORT. Dado que el cliente se conecta al puerto 80, ¿entonces su puerto también debe ser 80? Esto es algo sensato de pensar, pero en realidad no es lo que sucede. Si eso fuera correcto, solo podríamos atender a un usuario por dirección IP extranjera. Una vez que una computadora remota se conecta, entonces toma la conexión del puerto 80 al puerto 80, y nadie más podría conectarse.
Deben entenderse tres cosas:
1.) En un servidor, un proceso es escuchando en un puerto. Una vez que obtiene una conexión, la pasa a otro hilo. La comunicación nunca acapara el puerto de escucha.
2.) Las conexiones son identificadas de forma única por el sistema operativo mediante la siguiente 5 tupla: (IP local, puerto local, IP remota, puerto remoto, protocolo). Si algún elemento de la tupla es diferente, entonces esta es una conexión completamente independiente.
3.) Cuando un cliente se conecta a un servidor, elige un puerto de origen de orden superior aleatorio y no utilizado. De esta manera, un solo cliente puede tener hasta ~ 64k conexiones al servidor para el mismo puerto de destino.
Entonces, esto es realmente lo que se crea cuando un cliente se conecta a un servidor:
Local Computer | Remote Computer | Role
-----------------------------------------------------------
0.0.0.0:80 | | LISTENING
127.0.0.1:80 | 10.1.2.3: | ESTABLISHED
Observando lo que realmente sucede
Primero, usemos netstat para ver qué está sucediendo en esta computadora. Usaremos el puerto 500 en lugar del 80 (porque un montón de cosas están sucediendo en el puerto 80 ya que es un puerto común, pero funcionalmente no hace una diferencia).
netstat -atnp | grep -i ":500 "
Como era de esperar, la salida está en blanco. Ahora comencemos un servidor web:
sudo python3 -m http.server 500
Ahora, aquí está el resultado de ejecutar netstat nuevamente:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
Así que ahora hay un proceso que está escuchando activamente (Estado: LISTEN) en el puerto 500. La dirección local es 0.0.0.0, que es el código para “escuchar a todos”. Un error fácil de cometer es escuchar en la dirección 127.0.0.1, que solo aceptará conexiones desde la computadora actual. Entonces, esto no es una conexión, esto solo significa que un proceso solicitó bind () a la IP del puerto, y ese proceso es responsable de manejar todas las conexiones a ese puerto. Esto sugiere la limitación de que solo puede haber un proceso por computadora escuchando en un puerto (hay formas de evitar eso usando multiplexación, pero este es un tema mucho más complicado). Si un servidor web está escuchando en el puerto 80, no puede compartir ese puerto con otros servidores web.
Así que ahora, conectemos a un usuario a nuestra máquina:
quicknet -m tcp -t localhost:500 -p Test payload.
Este es un script simple (https://github.com/grokit/dcore/tree/master/apps/quicknet) que abre un socket TCP, envía la carga útil (“Carga útil de prueba” en este caso), espera unos segundos y desconecta. Si vuelve a hacer netstat mientras esto sucede, se muestra lo siguiente:
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 -
Si se conecta con otro cliente y vuelve a hacer netstat, verá lo siguiente:
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 -
… es decir, el cliente usó otro puerto aleatorio para la conexión. Por lo tanto, nunca hay confusión entre las direcciones IP.
Tienes la posibilidad difundir esta sección si te ayudó.