¿Por qué no es sensato dedicar más de un puerto TCP / IP a http? Aunque es cierto que es ingenuo, ¿no es intuitivo pensar que el rendimiento del servidor podría incrementarse de alguna manera?
¿Por qué no es sensato dedicar más de un puerto TCP / IP a http? Aunque es cierto que es ingenuo, ¿no es intuitivo pensar que el rendimiento del servidor podría incrementarse de alguna manera?
Respuestas:
El puerto 80 es un puerto conocido , lo que significa que es conocido como la ubicación en la que normalmente encontrará servidores HTTP. Puede encontrarlo documentado en el RFC HTTP / 1.1 .
Tener un valor predeterminado es útil precisamente porque no tiene que escribirlo en su navegador web con el URI. Si ejecuta un servidor HTTP (o de hecho cualquier servicio) en un puerto no estándar, obliga al cliente a recordar qué número arbitrario de 16 bits eligió y lo escribe.
Además de esta hostilidad, no hay beneficio de rendimiento: un puerto es solo una parte de las (dst ip:port, src ip:port)
4 tuplas que identifica de forma exclusiva una conexión TCP. Si dos conexiones comparten a dst ip:port
, eso no significa que compartan algún recurso del sistema: pueden residir en diferentes subprocesos o en diferentes procesos.
Ahora, si usted tiene lógicamente diferentes servicios que tanto suceden para utilizar HTTP, no hay ningún problema con el funcionamiento de los diferentes puertos. Simplemente hace que el URI sea un poco más feo.
El servidor no desperdicia recursos manejando conexiones en uno o más puertos. Los recursos del servidor se asignan para manejar conexiones, y el número de puerto es solo una forma de conectar un programa específico a una conexión específica.
Por ejemplo: el servidor HTTP sabe que escuchará las conexiones que vienen en el puerto 80. Y el servidor sabe que cada vez que reciba alguna solicitud en el puerto 80, la manejará en el servidor http. Después de eso, el servidor http se encargará de la comunicación y luego consumirá recursos.
Parece que piensas en los puertos como algo real; es solo un número sin signo de 16 bits (0-65535) que es una etiqueta en el encabezado de un paquete IP. Esto ayuda con la multiplexación a nivel de aplicación. Cuando un paquete entrante llega a una tarjeta de red, el sistema operativo recibe una notificación. Comprueba a qué puerto se dirigió el paquete entrante y luego lo reenvía solo a la aplicación correcta. Si está ejecutando su servidor web (nginx) para escuchar en el puerto 80, solo nginx recibe los paquetes enviados al puerto 80.
Cuando un cliente (IP: 100.200.100.200) realiza una solicitud HTTP al servidor (55.55.55.55), realiza esa solicitud al puerto de destino 80 en el servidor (55.55.55.55:80), pero el puerto de origen es elegido aleatoriamente Sistema operativo para el navegador web (algo así como 45490). La respuesta HTTP del servidor web proviene de (55.55.55.55:80), pero se envía al destino (su IP) (100.200.100.200:45490). El sistema operativo de su computadora sabe que los paquetes entrantes en el puerto 45490 (de 55.55.55.55:80) deben entregarse al navegador web que realizó la solicitud. Como cada conexión única a un sitio web desde el cliente obtiene un puerto aleatorio único, puede tener múltiples navegadores web conectados al mismo sitio web y cuando una página se recarga en un navegador, las otras ventanas no se ven afectadas.
Cada paquete IP tiene las direcciones IP de origen y destino y el puerto disponible en el encabezado. El sistema operativo y la aplicación (navegador web o servidor web) pueden usar ambos para determinar la acción adecuada sobre cómo procesar el paquete.
Los puertos 80 y 443 son los puertos "predeterminados" para HTTP / HTTPS
Esto significa que no tiene que especificar el puerto ( http://www.example.com:80 , https://www.example.com:443 ) cuando utiliza un navegador web.
Si desea que un servidor web escuche en cualquier otro puerto, los usuarios deben agregar manualmente el puerto a la URL, o debe codificarse en cualquier enlace a ese puerto en particular.
Además, la mayoría de los Proxies y Firewalls no permitirán conexiones a esos puertos a menos que estén configurados específicamente para hacerlo (sin configuración, los proxies salientes no escucharán puertos no predeterminados, por lo tanto, no reenviarán la solicitud a los servidores web, mientras que los Firewalls simplemente bloquear intentos de conexiones que no sean TCP80 / 443)
Todo esto limita lo que se puede hacer a nivel TCP / IP
Una forma de aumentar el rendimiento sería tener un dispositivo / servicio de equilibrio de carga escuchando TCP80 / 443 que luego redirigiría la solicitud a los servidores en diferentes puertos y / o ip (equilibrio local) o incluso sitios remotos diferentes (equilibrio global). Pero este es otro tema por completo
Agregar puertos adicionales no agrega ancho de banda adicional ni nada de eso, un puerto es más una etiqueta que una tubería , puede "crecer" tan ancho como lo necesite sin volverse más lento debido a que la tubería está llena.
Si un servidor recibe demasiadas solicitudes, el servidor se ralentizará, sin embargo, este no es el tipo de problema que se puede solucionar agregando otro número de puerto.
Si usó puertos aleatorios, el usuario tendría que agregar los números de puerto correctos cada vez que visitara su sitio. es decir, www.example.com:80; www.example.com:81; www.ejemplo.com:82 etc.
No aumentaría el rendimiento usar más puertos. Los puertos de origen para cada conexión son puertos efímeros y tan diferentes de todos modos
Cada conexión TCP / IP tiene un sourceIP: sourcePort y un destinationIP: destinationPort.
Cuando inicia una conexión, siempre usaría 80 como puerto de destino (lo cual tiene sentido ya que el Servidor solo necesita escuchar en el puerto 80 para HTTP y no en varios puertos). El truco es que sourcePort es dinámico para cada conexión.
Ejemplo:
usuario1: 1.1.1.1:29999 a 2.2.2.2:80
usuario2: 1.1.1.2:45333 a 2.2.2.2:80
No confunda un puerto diferente con una conexión física diferente o un mayor ancho de banda de red o rendimiento de procesamiento del servidor. Lo que obtiene el servidor son los paquetes TCP o UDP, que tienen un número de puerto como parte de la dirección. Todavía pasan por los mismos cables, pasan por el mismo hardware y controlador de interfaz de red, y así sucesivamente.
Si tuviera que enviar dos paquetes a un servidor, en términos de recursos que el servidor gasta para procesar estos dos paquetes, no importa si uno de los dos tiene números de puerto diferentes o los mismos números de puerto asociados con ellos, el manejo interno será estar cerca de ser idéntico
Por lo tanto, este no es un método para aumentar el rendimiento de ninguna manera.
La única excepción posible a esto es si asociara dos demonios diferentes (o dos copias de los mismos) que se ejecutan al mismo tiempo a los dos números de puerto diferentes, y si cada uno de estos demonios aumentaría extremadamente con la carga. Lo cual no suele ser el caso.
Como mencionó Remi, los puertos 80 y 443 son los puertos "predeterminados" para HTTP / HTTPS.
La mayoría de las redes y firewalls no bloquean el tráfico que pasa por estos puertos. Por lo tanto, usar estos puertos es más fácil, ya que la mayoría de las veces es posible que no tenga que preocuparse por los cortafuegos que bloquean su servicio; de lo contrario, tendrá que pasar por la reconfiguración de las reglas del cortafuegos y obtener aprobaciones del cumplimiento / seguridad para el mismo.
Como todos los demás aquí han dicho, básicamente no tiene sentido alojar un servidor web en cualquier puerto que no sea el puerto 80 ... a menos que lo aloje desde su casa. Muchos ISP aceleran los puertos TCP / UDP de salida 80 y 443 ( IANA define como HTTP y HTTPS , respectivamente), y en este caso, el uso de esos puertos disminuirá las velocidades de carga del sitio, etc. Sin embargo, IANA ha asignado 3 puertos HTTP-ALT para tanto TCP como UDP. Estos son: 591, 8008 y 8080. El uso de estos puertos también es aceptable, pero hará que la vida de los administradores del servidor sea un infierno.
Fuente de los números de puerto: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml