Soy un desarrollador que tiene la situación buena y mala de diseñar un servicio de red que se verá muy afectado por los clientes de iPhone. La aplicación para iPhone tuvo más de 10 millones de descargas el año pasado y ahora estoy conectando a los usuarios para que interactúen entre sí.
Me gustaría ajustar la implementación de TCP para los servidores que alojarán mi servicio de red basado en TCP. El tamaño por solicitud enviada será "pequeño" (digamos <256 bytes). Bien, lo has descubierto, es un servidor de juegos (¡sorpresa!).
Para su información, no estoy interesado en UDP (o una capa confiable sobre UDP como se ve en ENet y RakNet, por ejemplo) para este servicio en particular ya que los juegos no son similares a Quake; todos los paquetes deben recibirse de manera confiable, y para eso se diseñó TCP. Por lo tanto, las conexiones entre el cliente iPhone y el servicio serán "largas" (en la medida de lo posible: ¡al diablo con los túneles y los ascensores!).
Para su información, estoy ejecutando el servicio en un enlace ascendente de 100 Mbps en servidores que ejecutan Linux 2.6.18-164.9.1.el5.
Mis objetivos son simultáneamente:
- mantenga la latencia lo más baja posible; y
- Minimizar la cantidad de memoria utilizada por cliente conectado.
Hay ungrande¡Cantidad de perillas relacionadas con TCP para modificar! Después de una investigación básica, parece que la mayoría de la gente recomienda dejar la configuración como está. Sin embargo, hay una serie de configuraciones queparecercomo si deberían modificarse para casos particulares. Eso es un poco vago, lo sé, y por eso pido ayuda.
Las cosas a considerar para ajustar pequeñas solicitudes/respuestas en redes inestables mientras se minimiza la memoria tanto como sea posible podrían ser:
- Memoria disponible para la implementación TCP/IP.
- configurar la opción "nodelay" (deshabilite el algoritmo de Nagle ya que este es un servidor de juegos en tiempo semi-real)
- algoritmos de control de congestión
- etc. (¿qué más?)
Considere TCPalgoritmos de control de congestión:
- reno: TCP tradicional utilizado por casi todos los demás sistemas operativos
- cúbico: CÚBICO-TCP
- bic: BIC-TCP
- htcp: Hamilton TCP
- vegas: TCP Vegas
- westwood: optimizado para redes con pérdidas
Mis servidores están predeterminados enbiccuyo "objetivo es diseñar un protocolo que pueda escalar su rendimiento hasta varias decenas de gigabits por segundo en redes de alta velocidad y larga distancia manteniendo al mismo tiempo una gran equidad, estabilidad y compatibilidad con TCP".
Sólo por la pequeña descripción,Westwoodsuena más apropiado ya que "está destinado a manejar mejor rutas de productos con grandes retrasos en el ancho de banda (canalizaciones grandes), con posible pérdida de paquetes debido a errores de transmisión u otros (canalizaciones con fugas) y con carga dinámica (canalizaciones dinámicas)".
¿Estoy profundizando demasiado aquí o esto es parte del curso?
¿Para qué tipo de cosas ajustan TCP/IP en general? ¿Cómo? ¿Qué reglas generales hay que conocer?
¿Qué palabras de sabiduría tienes para mi caso particular?
¡Muchas gracias!
Respuesta1
Entonces, como habrás descubierto, el control de la congestión TCP es un área bastante complicada.
Para este caso particular, debido a las solicitudes pequeñas, querrá intentar mantener las conexiones abiertas tanto como sea posible, porque una conexión por solicitud tomará cinco paquetes cada una, mientras que puede reducir el promedio a un poco más de dos paquetes si mantienes las conexiones disponibles.
NODELAY es lo correcto para un servidor de juegos; desea que sus 256 bytes se entreguen de inmediato, y eso no es un segmento completo, por lo que Nagle hará una pausa a menos que use NODELAY.
Si sus servidores tienen mucha memoria, las opciones de memoria no son gran cosa, los nuevos kernels las tienen bien.
En cuanto a los algoritmos de control de congestión, viste a Westwood. La otra opción es CÚBICA. Puede optar por uno o investigar un poco y compararlos. Podría suponer bastante trabajo, pero para 10 millones de clientes merece la pena. Entonces, estaría considerando ejecutar una simulación usando un generador de tráfico en una Mac o tres (ya que tienen la misma implementación TCP que el teléfono), una máquina Linux que actúa como enrutador (más sobre esto en breve) y uno de tus servidores, para ver cómo va.
Ahora, esa caja de Linux del medio debería ejecutarse.ns-3para que pueda simular una ruta más complicada que solo un conmutador Ethernet. Luego captura algunos rastros de paquetes en el extremo emisor de las conexiones TCP y los analiza contcptraceo los modos de gráficos tcptrace de Wireshark. La documentación de tcptrace es una buena introducción al análisis del comportamiento de congestión de TCP.