¿Puede explicar cómo escucha un servidor el número de puerto?

Cada computadora ejecuta muchos procesos. La dirección IP solo le dice al remitente con qué computadora hablar.

Después de que una máquina ha recibido un mensaje y sabiendo por ip que está destinado a él, se necesita un mecanismo para identificar a qué proceso se debe entregar este mensaje.

Por lo tanto, la API de sockets se compone de un esquema numérico en el que al crear un socket, lo ENLACE a un puerto de escucha, que básicamente le dice a la pila de redes del sistema operativo que “necesito cualquier mensaje cuyo destino sea este puerto”.

Lo interno de cómo funciona esto en realidad requeriría revisar el código de pila de Networking de digamos Linux, que crea una estructura de datos para sockets y, al hacerlo, permite vincular con un número de puerto.

En términos de comunicación de red, cada mensaje necesita estas cosas, puerto de origen / destino y direcciones IP. Cuando usted es un cliente (digamos un navegador web), el sistema selecciona automáticamente un número de puerto fuente aleatorio para usted.

Esta es la razón por la que existe el concepto de puerto de servidor BIEN DEFINIDO, como 80/8080 para HTTP o 443 para HTTPS.

Todavía existen algunas aplicaciones que funcionan sin números de puerto como PING (basado en el protocolo ICMP). En este caso, el ping no es “uno de los muchos procesos que se ejecutan en una máquina”, sino que es una parte de la aplicación estándar de la pila de red de la máquina.

Aún así, si abre varias indicaciones de comando para hacer ping a la misma máquina, las respuestas se dirigen a la aplicación correcta. Debido a que pings maneja esto internamente de una manera única que varía según el sistema operativo, por ejemplo, Linux podría agregar el puerto udp de id / fuente del proceso en los últimos ocho bytes del encabezado icmp que la pila de red usaría para diferenciar qué respuesta es para qué indicador de comando del remitente de ping.

Abre un socket y establece las opciones de socket para escuchar en el puerto. Consulte, por ejemplo, las páginas de manual de Linux para socket (2), socket (7). Se necesitan unas pocas líneas de C.
Debido a que cada subproceso solo puede mantener abierta una conexión a la vez, los servidores generalmente son multiproceso. El antiguo servidor Apache en Unix bifurcó procesos separados para manejar cada nuevo cliente simultáneo, pero en parte debido a que fork () no era compatible con Windows, cambió a un modelo roscado.
En Unix, abrir un socket en un puerto por debajo de 1024 requiere privilegio de root, pero ejecutar un servidor como root es un riesgo de seguridad, por lo que la mayoría de los servidores abren un socket como root y luego dejan el privilegio para continuar ejecutándose mientras el puerto permanece abierto.

Busque, por ejemplo, “ejemplo de socket de escucha de código C”, o mire el código fuente de netcat.