http - protocolo - ¿Cuántas conexiones de socket puede manejar un servidor web?

programacion android pdf 2018 (7)

Digamos que si tuviera que compartir hosting compartido, virtual o dedicado, leí en alguna parte que un servidor / máquina solo puede manejar 64,000 conexiones TCP a la vez, ¿es así? ¿Cuántos podrían manejar cualquier tipo de hosting independientemente del ancho de banda? Supongo que HTTP funciona a través de TCP.

¿Esto significaría que solo 64,000 usuarios podrían conectarse al sitio web, y si quisiera servir más tendré que mudarme a una granja de servidores web?

Aquí hay dos discusiones diferentes: una es la cantidad de personas que pueden conectarse a su servidor. Éste ha sido respondido adecuadamente por otros, así que no entraré en eso.

Otro es ¿cuántos puertos puede escuchar su servidor? Creo que de aquí viene el número 64K. En realidad, el protocolo TCP usa un identificador de 16 bits para un puerto, que se traduce a 65536 (un poco más de 64K). Esto significa que puede tener tantos "oyentes" diferentes en el servidor por dirección IP.

Creo que la cantidad de conexiones de socket simultáneas que puede manejar un servidor web depende en gran medida de la cantidad de recursos que consume cada conexión y de la cantidad total de recursos disponibles en el servidor, salvo cualquier otro recurso de servidor web que limite la configuración.

Para ilustrarlo, si cada conexión de socket consume 1MB de recursos del servidor y el servidor tiene 16GB de RAM disponible (teóricamente) esto significaría que solo sería capaz de manejar (16GB / 1MB) conexiones concurrentes. Creo que es tan simple como eso ... ¡REALMENTE!

Entonces, independientemente de cómo maneje las conexiones el servidor web, cada conexión finalmente consumirá algún recurso.

En resumen: debe poder lograr en el orden de millones de conexiones TCP simultáneas activas y por extensión solicitudes HTTP.

Hoy, me preocupaba si IIS con ASP.NET admitiría en el orden de 100 conexiones simultáneas. Cuando vi esta pregunta / respuesta, no pude resistir contestarme, muchas respuestas a la pregunta aquí son completamente incorrectas.

Mejor caso

La respuesta a esta pregunta solo debe referirse a la configuración de servidor más simple para desacoplarse de las innumerables variables y configuraciones posibles en sentido descendente.

Así que considere la siguiente situación para mi respuesta:

No hay tráfico en las sesiones TCP, excepto para los paquetes keep-alive (de lo contrario, obviamente necesitaría una cantidad correspondiente de ancho de banda de red y otros recursos informáticos)
Software diseñado para usar sockets asíncronos y programación, en lugar de un hilo de hardware por solicitud de un grupo. (es decir, IIS, Node.js, Nginx ... servidor web [pero no Apache] con software de aplicación diseñado asincrónico)
Buen rendimiento / dólar CPU / Ram. Hoy, arbitrariamente, digamos i7 (4 núcleos) con 8 GB de RAM.
Un buen firewall / enrutador para que coincida.
Sin límite / gobernador virtual - es decir. Linux somaxconn, IIS web.config ...
Sin dependencia de otro hardware más lento, sin lectura desde el disco duro, porque sería el denominador común más bajo y el cuello de botella, no el IO de la red.

Respuesta detallada

Los diseños sincrónicos ligados a hilos tienden a ser los que peor rendimiento tienen con respecto a las implementaciones IO asincrónicas.

WhatsApp recibe un millón de tráfico WITH en una sola máquina OS con sabor de Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

Y finalmente, este, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , entra en un montón de detalles , explorando cómo se podrían lograr incluso 10 millones. Los servidores suelen tener motores de descarga TCP de hardware, ASIC diseñados para este rol específico de manera más eficiente que una CPU de propósito general.

Buenas opciones de diseño de software

El diseño asíncrono de IO diferirá en los sistemas operativos y las plataformas de programación. Node.js fue diseñado con asincronía en mente. Debería usar Promises al menos, y cuando aparezca ECMAScript 7, async / await . C # /. Net ya tiene soporte asincrónico completo como node.js. Cualquiera sea el sistema operativo y la plataforma, se espera que asincrónica funcione muy bien. Y cualquiera que sea el idioma que elija, busque la palabra clave "asíncrona", la mayoría de los idiomas modernos tendrán algún tipo de soporte, incluso si es un complemento de algún tipo.

Para WebFarm?

Cualquiera que sea el límite para su situación particular, sí, una granja de servidores web es una buena solución para escalar. Hay muchas arquitecturas para lograr esto. Uno está utilizando un equilibrador de carga (los proveedores de hosting pueden ofrecer estos, pero incluso estos tienen un límite, junto con el límite de ancho de banda), pero yo no estoy a favor de esta opción. Para las aplicaciones de una sola página con conexiones de larga ejecución, prefiero tener una lista abierta de servidores que la aplicación cliente elija de forma aleatoria al inicio y reutilizar a lo largo de la vida de la aplicación. Esto elimina el punto único de falla (equilibrador de carga) y permite escalar a través de múltiples centros de datos y, por lo tanto, mucho más ancho de banda.

Rompiendo un mito - 64K puertos

Para abordar el componente de pregunta con respecto a "64,000", este es un concepto erróneo. Un servidor puede conectarse a muchos más de 65535 clientes. Ver https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284

Por cierto, Http.sys en Windows permite que varias aplicaciones compartan el mismo puerto de servidor bajo el esquema HTTP HTTP. Cada uno de ellos registra un enlace de dominio por separado, pero en última instancia hay una única aplicación de servidor que envía las solicitudes a las aplicaciones correctas.

Esta pregunta es bastante difícil. No existe una limitación de software real en la cantidad de conexiones activas que puede tener una máquina, aunque algunos sistemas operativos son más limitados que otros. El problema se convierte en uno de los recursos. Por ejemplo, digamos que una sola máquina quiere admitir 64,000 conexiones simultáneas. Si el servidor usa 1MB de RAM por conexión, necesitaría 64GB de RAM. Si cada cliente necesita leer un archivo, la carga de acceso al disco o la matriz de almacenamiento se vuelve mucho más grande de lo que esos dispositivos pueden manejar. Si un servidor necesita bifurcar un proceso por conexión, entonces el sistema operativo pasará la mayor parte de su tiempo de conmutación de contexto o procesos de hambruna para el tiempo de CPU.

La página del problema C10K tiene una muy buena discusión sobre este tema.

Para agregar mis dos centavos a la conversación, un proceso puede tener simultáneamente una cantidad de enchufes conectados igual a este número (en sistemas de tipo Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Este número puede modificarse sobre la marcha (solo por usuario raíz, por supuesto)

echo 1024> / proc / sys / net / core / somaxconn

Pero depende completamente del proceso del servidor, el hardware de la máquina y la red, la cantidad real de enchufes que se pueden conectar antes de bloquear el sistema

Parece que la respuesta es de al menos 12 millones si tienes un servidor robusto, tu software de servidor está optimizado para eso, tienes suficientes clientes. Si prueba de un cliente a un servidor, la cantidad de números de puerto en el cliente será uno de los límites de recursos obvios (cada conexión TCP está definida por la combinación única de IP y número de puerto en la fuente y el destino).

(Debe ejecutar varios clientes, ya que de lo contrario, primero alcanza el límite de 64 K en los números de puerto)

Cuando se trata de esto, este es un ejemplo clásico de la ocurrencia de que "la diferencia entre la teoría y la práctica es mucho mayor en la práctica que en la teoría"; en la práctica, lograr los números más altos parece ser un ciclo de a. proponer cambios específicos de configuración / arquitectura / código, b. pruébalo hasta que llegues a un límite, c. ¿He terminado? Si no, entonces d. averiguar cuál fue el factor limitante, e. regrese al paso a (enjuague y repita).

Aquí hay un ejemplo con 2 millones de conexiones TCP en una gran caja (128 GB de RAM y 40 núcleos) ejecutando Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - terminaron necesitando aproximadamente 50 servidores razonablemente importantes solo para proporcionar la carga del cliente (sus clientes iniciales más pequeños han llegado al máximo, por ejemplo, "ha alcanzado el máximo de 4core / 15gb box @ 450k de clientes").

Aquí hay otra referencia para ir esta vez a 10 millones: http://goroutines.com/10m .

Esto parece estar basado en Java y 12 millones de conexiones: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

Tenga en cuenta que HTTP normalmente no mantiene las conexiones TCP abiertas durante más tiempo de lo que tarda en transmitir la página al cliente; y el usuario suele tardar mucho más tiempo en leer una página web que en descargar la página ... mientras el usuario está viendo la página, no agrega ninguna carga al servidor.

Por lo tanto, la cantidad de personas que pueden ver simultáneamente su sitio web es mucho mayor que la cantidad de conexiones TCP que puede atender simultáneamente.