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

Digamos que si tuviera un alojamiento compartido, virtual o dedicado, leí en algún lugar que un servidor / máquina solo puede manejar 64,000 conexiones TCP a la vez, ¿es esto cierto? ¿Cuántos podría manejar cualquier tipo de alojamiento independientemente del ancho de banda? Supongo que HTTP funciona sobre TCP.

¿Significaría esto que solo 64.000 usuarios podrían conectarse al sitio web y, si quisiera servir más, tendría que mudarme a una granja web?

En resumen: debería poder lograr del orden de millones de conexiones TCP activas simultáneas y, por extensión, solicitudes HTTP. Esto le indica el rendimiento máximo que puede esperar con la plataforma adecuada con la configuración adecuada.

Hoy, me preocupaba si IIS con ASP.NET admitiría en el orden de 100 conexiones simultáneas (mire mi actualización, espere ~ 10k respuestas por segundo en versiones anteriores de ASP.Net Mono). Cuando vi esta pregunta / respuestas, no pude resistirme a responderme, muchas respuestas a la pregunta aquí son completamente incorrectas.

Mejor caso

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

Así que considere el siguiente escenario para mi respuesta:

1. No hay tráfico en las sesiones TCP, excepto para los paquetes de mantenimiento (de lo contrario, obviamente necesitaría una cantidad correspondiente de ancho de banda de red y otros recursos informáticos)
2. Software diseñado para usar sockets y programación asincrónicos, en lugar de un subproceso 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 asíncrono)
3. Buen rendimiento / CPU / Ram en dólares. Hoy, arbitrariamente, digamos i7 (4 núcleos) con 8GB de RAM.
4. Un buen firewall / enrutador para combinar.
5. Sin límite virtual / gobernador, es decir. Linux somaxconn, IIS web.config ...
6. Sin dependencia de otro hardware más lento, sin lectura desde el disco duro, porque sería el mínimo común denominador y cuello de botella, no la E / S de la red.

Respuesta detallada

Los diseños vinculados a subprocesos síncronos tienden a tener el peor rendimiento en relación con las implementaciones de E / S asíncronas.

WhatsApp obtiene un millón de tráfico CON en una sola máquina con sistema operativo 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 muchos 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 esta función específica de manera más eficiente que una CPU de propósito general.

Buenas opciones de diseño de software

El diseño de E / S asíncronas diferirá entre los sistemas operativos y las plataformas de programación. Node.js se diseñó teniendo en cuenta el sistema asincrónico . 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 que sea el sistema operativo y la plataforma, se debe esperar que el sistema asincrónico funcione muy bien. Y sea cual sea el idioma que elija, busque la palabra clave "asincrónico", la mayoría de los idiomas modernos tendrán algún soporte, incluso si es un complemento de algún tipo.

¿A WebFarm?

Cualquiera que sea el límite para su situación particular, sí, una granja web es una buena solución para escalar. Hay muchas arquitecturas para lograrlo. Uno es usar un equilibrador de carga (los proveedores de alojamiento pueden ofrecerlos, pero incluso estos tienen un límite, junto con un techo de ancho de banda), pero no estoy a favor de esta opción. Para las aplicaciones de página única con conexiones de larga duración, prefiero tener una lista abierta de servidores entre los que la aplicación cliente elegirá aleatoriamente al inicio y reutilizará durante la vida útil de la aplicación. Esto elimina el único punto 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: puertos de 64K

Para abordar el componente de la pregunta con respecto a "64.000", este es un concepto erróneo. Un servidor puede conectarse a muchos más de 65535 clientes. Consulte /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

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

Actualización 2019-05-30

Aquí hay una comparación actualizada de las bibliotecas HTTP más rápidas: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

• Fecha de prueba: 2018-06-06
• Hardware utilizado: Dell R440 Xeon Gold + 10 GbE
• El líder tiene ~ 7 millones de respuestas de texto plano por segundo (respuestas, no conexiones)
• El segundo, Fasthttp para golang, anuncia 1,5 millones de conexiones simultáneas; consulte https://github.com/valyala/fasthttp
• Los lenguajes líderes son Rust, Go, C ++, Java, C e incluso C # ocupa el puesto 11 (6,9 millones por segundo). Scala y Clojure se clasifican más abajo. Python ocupa el puesto 29 a 2,7 millones por segundo.
• Al final de la lista, anoto laravel y cakephp, rails, aspnet-mono-ngx, symfony, zend. Todo por debajo de 10k por segundo. Tenga en cuenta que la mayoría de estos marcos están diseñados para páginas dinámicas y son bastante antiguos; puede haber variantes más nuevas que aparezcan más arriba en la lista.
• Recuerde que esto es texto sin formato HTTP, no para la especialidad de Websocket: muchas personas que vienen aquí probablemente estarán interesadas en conexiones concurrentes para websocket.

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

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

Para agregar mis dos centavos a la conversación, un proceso puede tener abiertos simultáneamente un número de sockets 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 se puede modificar sobre la marcha (solo por el usuario root, 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 sockets que se pueden conectar antes de que el sistema falle.

Parece que la respuesta es al menos 12 millones si tiene un servidor robusto, el software de su servidor está optimizado para él, tiene 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 obvios de recursos (cada conexión TCP se define por la combinación única de IP y número de puerto en el origen y el destino).

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

Cuando se trata de eso, este es un ejemplo clásico del ingenio de que "la diferencia entre teoría y 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ébelo hasta alcanzar un límite, c. He terminado? Si no, entonces d. averiguar cuál fue el factor limitante, e. vuelva al paso a (enjuague y repita).

Aquí hay un ejemplo con 2 millones de conexiones TCP en una caja robusta (128 GB de RAM y 40 núcleos) que ejecuta Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - terminaron hasta necesitando 50 o más servidores razonablemente significativos solo para proporcionar la carga del cliente (sus clientes iniciales más pequeños llegaron al máximo al principio, por ejemplo, "maximizó nuestra caja de 4 núcleos / 15gb @ 450k clientes").

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

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

Tenga en cuenta que HTTP no suele mantener abiertas las conexiones TCP durante más tiempo del necesario para transmitir la página al cliente; y por lo general, el usuario tarda mucho más en leer una página web que en descargarla ... 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 a las que puede atender simultáneamente.

en el caso del protocolo IPv4, el servidor con una dirección IP que escucha en un puerto solo puede manejar 2 ^ 32 direcciones IP x 2 ^ 16 puertos, por lo que 2 ^ 48 sockets únicos. Si habla de un servidor como una máquina física y puede utilizar los 2 ^ 16 puertos, entonces podría haber un máximo de 2 ^ 48 x 2 ^ 16 = 2 ^ 64 sockets TCP / IP únicos para una dirección IP. Tenga en cuenta que algunos puertos están reservados para el sistema operativo, por lo que este número será menor. Para resumir:

1 IP y 1 puerto -> 2 ^ 48 sockets

1 IP y todos los puertos -> 2 ^ 64 sockets

todos los sockets IPv4 únicos en el universo -> 2 ^ 96 sockets

Aquí hay dos discusiones diferentes: una es cuántas personas pueden conectarse a su servidor. Este ha sido respondido adecuadamente por otros, así que no entraré en eso.

Otro es ¿en cuántos puertos puede escuchar su servidor? Creo que de aquí es de donde vino el número 64K. En realidad, el protocolo TCP usa un identificador de 16 bits para un puerto, que se traduce en 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 un servidor web puede manejar depende en gran medida de la cantidad de recursos que consume cada conexión y la cantidad de recursos totales disponibles en el servidor, salvo cualquier otra configuración de limitación de recursos del servidor web.

A modo de ilustración, si cada conexión de socket consumiera 1 MB de recurso del servidor y el servidor tiene 16 GB de RAM disponibles (teóricamente), esto significaría que solo podría manejar conexiones simultáneas (16 GB / 1 MB). Creo que es tan simple como eso ... ¡REALMENTE!

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