¿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?
Tienes toda la razón. Cambié el puerto predeterminado de mis servidores web de 80 a 90,91,92 y 93. La carga en el servidor se ha reducido drásticamente.
David Houde
17
... tal vez porque ya no hay clientes que puedan encontrar el servidor?
Marcos Gonzalez
55
80 es solo el puerto utilizado para http. Cuando dices "algo.com"; (o incluso "something.com") el navegador lo completa como una solicitud a "something.com:80"; (en el puerto 80, ya que es el puerto http conocido por defecto). Lo mismo para https en 443. Si decide cambiarlo, deberá decirlo en la URL: "myserver.com:1280"; de lo contrario, el navegador intentará en el puerto 80 y no lo encontrará. Se puede ver una lista en wikipedia
Olivier Dulac
66
Lo siento Marcos, fue un mal intento de humor. Nunca he sido bueno en eso.
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.
¡Eso es! ¡El puerto 80 no es un recurso! ¡Es solo parte de una tupla! Gracias por ponerlo tan claro.
Marcos Gonzalez
2
Tampoco vale la pena que incluso para diferentes servicios, la conexión HTTP real generalmente se recibe en el puerto 80 por un controlador de todo el sistema que realiza un análisis de protocolo inicial y luego lo entrega al servicio correcto, permitiendo así servicios totalmente diferentes en diferentes procesos para compartir el mismo puerto
Monstieur
1
Respuesta útil de Inútil
Deckard
26
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.
Agregaría a esta respuesta que el puerto 80 no es consumido por un usuario que le envía su solicitud. Es por eso que solo usar el puerto 80 (o cualquier puerto conocido para el protocolo entrante que está viendo) no es un cuello de botella para la escalabilidad.
Craig Sirkin
1
Eso es exactamente lo que no entendí del todo. Incluso 100.000 usuarios que se conectan simultáneamente a www.example.com:80 no consumirán el puerto 80. Gracias por la aclaración. La siguiente información de @Useless 'también me parece muy esclarecedora.
Marcos Gonzalez
Algunos software de servidores web tienen límites por instancias y / o procesos. En algún momento puede ser una buena idea ejecutar varias instancias, pero hacerlo en la misma máquina requiere otro puerto de escucha, el primero (TCP80 / 443) es reenviar las conexiones a la primera instancia.
Remi Letourneau
22
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.
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
Gracias por presentarme el concepto de "equilibrio de carga".
Marcos Gonzalez
1
Si desea tener algunas "pseudo" prácticas e ideas sobre algunos conceptos de equilibrio de carga, F5 tiene capacitación en línea gratuita en university.f5.com El registro es gratuito y le brinda acceso a LTM (Administrador de tráfico local, su equilibrador local) ) entrenamiento, donde puede ver cómo se ve y aprender algunos conceptos de equilibrio de carga (por ejemplo: IP real, IP virtual, piscinas, comprobación de estado, etc.)
Remi Letourneau
Buen consejo!
Marcos Gonzalez
9
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.
s / label then / label than / - Editaría, pero parece que solo un carácter no es una edición aceptable.
Paul Gear
7
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.
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.
Amén, los sitios web que usan puertos no estándar son la pesadilla de la existencia de cualquier administrador de seguridad, un usuario en su trabajo ned necesita usar un sitio web con puerto extraño = cambio de proxy, cambio de FW, revisión de seguridad, etc.
wintermute000
0
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.
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 adst 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.
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente
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
fuente
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
fuente
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.
fuente
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.
fuente
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
fuente