tcp - significado - protocolo udp
¿Cómo retener un millón de conexiones TCP simultáneas? (6)
¿Qué sistemas operativos estás considerando para esto?
Si utiliza un sistema operativo Windows y utiliza algo más tarde que Vista, entonces no debería tener un problema con miles de conexiones en una sola máquina. Realicé pruebas (aquí: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) con un equipo de baja especificación de Windows Server 2003 y logré fácilmente más de 70,000 TCP activos conexiones. Algunos de los límites de recursos que afectan la cantidad de conexiones posibles se han levantado considerablemente en Vista (ver aquí: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) y así probablemente puedas lograr tu objetivo con un pequeño grupo de máquinas. No sé lo que necesitarías delante de esos para enrutar las conexiones.
Windows proporciona una instalación llamada Puertos de finalización de E / S (ver: http://msdn.microsoft.com/en-us/magazine/cc302334.aspx ) que le permiten dar servicio a muchos miles de conexiones concurrentes con muy pocos hilos (yo estaba ejecutando pruebas ayer con 5000 conexiones saturando un enlace a un servidor con 2 hilos para procesar la E / S ...). Por lo tanto, la arquitectura básica es muy escalable.
Si desea ejecutar algunas pruebas, tengo algunas herramientas disponibles en mi blog que le permiten utilizar un servidor de eco simple usando miles de conexiones ( http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html ) y ( 2 ) y algunos códigos gratuitos que puede usar para comenzar. ( 3 )
La segunda parte de su pregunta, de sus comentarios, es más complicada. Si la dirección IP del cliente sigue cambiando y no hay nada entre usted y ellos que proporcione NAT para darle una dirección IP consistente, entonces sus conexiones, sin duda, serán canceladas y deberán restablecerse. Si los clientes detectan que esta conexión se desconecta cuando cambia su dirección IP, pueden reconectarse con el servidor; si no pueden, sugeriría que los clientes necesiten sondear el servidor cada cierto tiempo para que puedan detectar la pérdida de conexión y reconectar No hay nada que el servidor pueda hacer aquí, ya que no puede predecir la nueva dirección IP y descubrirá que la conexión anterior ha fallado cuando intenta enviar datos.
Y recuerde, sus problemas apenas comienzan una vez que obtiene su sistema para escalar a este nivel ...
Debo diseñar un servidor que necesite servir a millones de clientes que están conectados simultáneamente con el servidor a través de TCP.
El tráfico de datos entre el servidor y los clientes será escaso, por lo que se pueden ignorar los problemas de ancho de banda.
Un requisito importante es que siempre que el servidor necesite enviar datos a cualquier cliente, debe usar la conexión TCP existente en lugar de abrir una nueva conexión hacia el cliente (porque el cliente puede estar detrás de un firewall).
¿Alguien sabe cómo hacer esto y qué hardware / software se necesita (al menor costo)?
Como Greg mencionó, el problema que está describiendo es C10K (o más bien "C1M" en su caso) Hace poco creé un servidor de eco TCP simple en linux que escala muy bien con el número de sesiones (solo probado hasta 200.000), por usando la cola epoll . En BSD, tienes algo similar llamado kqueue. Puede consultar el code si lo desea. Espero que esto ayude y buena suerte!
EDITAR: Como mencioné en los comentarios a continuación, mi afirmación original de que hay un límite de 64K basado en el número de puertos es incorrecta, sin embargo hay un límite de 32K en el número de identificadores de socket , por lo que mi diseño sugerido es válido.
Con un diseño de servidor TCP / IP típico, está limitado en la cantidad de conexiones abiertas simultáneas que puede tener. El servidor tiene un puerto de escucha y cuando un cliente se conecta, el servidor realiza una llamada de aceptación y crea un nuevo socket en un puerto aleatorio para el resto de la conexión.
Para manejar más de 64K conexiones simultáneas creo que necesita usar UDP en su lugar. Solo necesita un puerto para que el servidor lo escuche, y necesita administrar las conexiones utilizando un ID de cliente de 32 bits en los datos del paquete en lugar de tener un puerto separado para cada cliente. El ID del cliente de 32 bits podría ser la dirección IP del cliente, y el cliente puede escuchar en un puerto UDP conocido los mensajes que regresan del servidor. Ese puerto sería el único que debe abrirse en el firewall.
Con este enfoque, su única limitación es qué tan rápido puede manejar y responder a los mensajes UDP. Con millones de clientes, incluso el tráfico escaso podría darle grandes picos, y si no lee los paquetes lo suficientemente rápido su cola de entrada se llenará y comenzará a tirar paquetes. La página C10K que Greg señala te dará estrategias para eso.
Este problema está relacionado con el llamado problema C10K . La página C10K enumera una gran cantidad de buenos recursos para abordar los problemas que encontrará cuando intente permitir que miles de clientes se conecten al mismo servidor.
Me he encontrado con el Proyecto APE hace un tiempo. Parece un sueño hecho realidad. Pueden admitir hasta 100k clientes simultáneos en un solo nodo. Extiéndalos a través de 10 o 20 nodos, y puede servir a millones. Perfecto para aplicaciones RESTful. Es posible que desee buscar más profundo para cualquier espacio de nombres compartido. Una desventaja es que este es un servidor independiente, como complemento de un servidor web. Este servidor es, por supuesto, de código abierto, por lo que cualquier costo está relacionado con el hardware / ISP.
No puedes usar UDP. Si el cliente envía una solicitud y usted no responde inmediatamente, un enrutador olvidará la ruta inversa en 30 segundos o menos, por lo que su servidor nunca podrá responder al cliente.
TCP es la única opción, y también le dará dolores de cabeza. La mayoría de los enrutadores olvidarán la ruta y / o desconectarán la conexión después de unos minutos, por lo que su código cliente / servidor tendrá que enviar "keep alives" con bastante frecuencia.
Recomiendo configurar un "sniffer" para ver cómo las compañías telefónicas se mantienen en contacto con su teléfono inteligente para su tecnología de "empuje". Copia lo que sea que estén haciendo, ¡porque eso funciona !