Optimización de la latencia de red para servidores dedicados

Por qué la infraestructura dedicada sigue teniendo problemas de latencia

El alojamiento compartido añade la sobrecarga de la virtualización a los saltos de red. Los servidores dedicados eliminan la virtualización, pero la física de la propagación de la señal sigue siendo la misma. La luz viaja a través de la fibra a aproximadamente 200 000 km/s, lo que significa que un viaje de ida y vuelta de Los Ángeles a Ámsterdam está matemáticamente limitado a unos 90 ms antes de que comience cualquier procesamiento de la aplicación.

Esa referencia es importante. Si tus usuarios están distribuidos por todo el mundo, pero tu servidor dedicado se encuentra en un único centro de datos, algunos de ellos siempre sufrirán esa penalización por el tiempo de ida y vuelta. El objetivo no es vencer a la física, sino minimizar todas las variables controlables además de ella.

Paso 1: La selección del centro de datos es una decisión relacionada con la latencia

La mayoría de los equipos eligen un centro de datos basándose en el precio o la disponibilidad, y luego pasan meses intentando optimizar su solución para resolver un problema geográfico. Elige tu centro de datos en función del origen de la mayor parte de tu tráfico de producción y realiza una evaluación comparativa antes de comprometerte.

InMotion Hosting opera centros de datos en Los Ángeles y Ámsterdam, que cubren las concentraciones de tráfico de Norteamérica y Europa, respectivamente. Si tu aplicación presta servicio principalmente a usuarios de la costa oeste de EE. UU., las instalaciones de Los Ángeles ofrecerán una latencia considerablemente menor que cualquier alternativa de la costa este. Las bases de usuarios europeas se benefician de las relaciones de interconexión de la ubicación de Ámsterdam con los principales intercambios de Internet europeos.

Herramientas que vale la pena utilizar antes de firmar cualquier contrato:

• mtr (My Traceroute): muestra la latencia por salto y la pérdida de paquetes en tiempo real, no solo el ping RTT final que te proporciona.
• traceroute: Traza la ruta entre tu máquina de prueba y la IP del centro de datos.
• iPerf3: Mide el ancho de banda real y la fluctuación bajo carga, no los máximos teóricos.

Ejecuta estas pruebas desde equipos ubicados donde se encuentran realmente tus usuarios, no desde tu propia oficina. Según los datos de rendimiento de la red Cloudflare, la proximidad geográfica a un importante punto de intercambio de Internet puede reducir el RTT entre 30 y 50 ms en comparación con el enrutamiento a través de un centro distante.

Paso 2: La integración de CDN reduce el problema de la distancia

Una CDN no hace que tu servidor sea más rápido, sino que reduce la frecuencia con la que los usuarios tienen que acceder a él. Los recursos estáticos (CSS, JS, imágenes, vídeo) servidos desde un nodo periférico a 10 ms de distancia, en comparación con tu servidor dedicado a 80 ms de distancia, suponen una ganancia de 70 ms en cada carga de página, multiplicada por cada recurso de la página.

Para los operadores de servidores dedicados, la integración de CDN suele implicar uno de estos dos enfoques:

Proxy CDN completo: todo el tráfico pasa por la capa CDN. Tanto el nivel Enterprise Cloudflarecomo Fastly admiten este modelo. Tu servidor dedicado solo gestiona las faltas de caché y las solicitudes dinámicas. Cloudflare que las implementaciones de CDN correctamente configuradas reducen la carga del servidor de origen entre un 60 % y un 90 %.

Descarga parcial: solo redirigís subdominios o rutas de activos específicos a través de la CDN, mientras que los puntos finales de la API y las rutas autenticadas siguen dirigiéndose directamente a tu servidor. Este modelo requiere más configuración, pero te ofrece un control granular sobre lo que se almacena en caché y lo que siempre debe dirigirse al origen.

Para aplicaciones en las que la latencia es fundamental, la configuración clave es la de la conexión de origen de la CDN. Asegúrate de que la CDN se conecta a tu servidor a través de HTTP/2 (o HTTP/3, si es compatible): la multiplexación elimina el bloqueo de cabeza de línea en la conexión entre el borde de la CDN y tu servidor.

Paso 3: Ajuste de la pila TCP de Linux en tu servidor dedicado

Aquí es donde los servidores dedicados te ofrecen algo que los entornos VPS normalmente no ofrecen: la posibilidad de modificar los parámetros del kernel. Conéctate por SSH a tu servidor y comprueba tu configuración TCP actual:

sysctl net.core.somaxconn

sysctl net.ipv4.tcp_max_syn_backlog

sysctl net.ipv4.tcp_congestion_control

Hay varios ajustes que afectan directamente a la latencia de la aplicación bajo una carga simultánea:

Algoritmo de control de congestión TCP: El kernel de Linux utiliza Cubic como algoritmo predeterminado para el control de congestión. BBR (Bottleneck Bandwidth and Round-trip propagation time), desarrollado por Google, supera ampliamente a Cubic en conexiones de alta latencia y pérdida moderada de paquetes. Actívalo con:

echo «net.core.default_qdisc=fq» >> /etc/sysctl.conf

echo «net.ipv4.tcp_congestion_control=bbr» >> /etc/sysctl.conf

sysctl -p

Tamaños de búfer TCP: los tamaños predeterminados de búfer del núcleo se establecieron para una época diferente en cuanto a velocidades de red. En conexiones de más de 1 Gbps, los búferes de tamaño insuficiente se convierten en un límite para el rendimiento:

echo «net.core.rmem_max=134217728» >> /etc/sysctl.conf

echo «net.core.wmem_max=134217728» >> /etc/sysctl.conf

echo «net.ipv4.tcp_rmem=4096 87380 67108864» >> /etc/sysctl.conf

echo «net.ipv4.tcp_wmem=4096 65536 67108864» >> /etc/sysctl.conf

sysctl -p

TCP_NODELAY para API de baja latencia: si tu aplicación ejecuta una API en la que la latencia es más importante que el rendimiento, habilita TCP_NODELAY en el nivel de socket en el código de tu aplicación. Esto deshabilita el algoritmo de Nagle, que agrupa paquetes pequeños, lo cual es útil para transferencias masivas, pero contraproducente para API de solicitud-respuesta en las que se desea que cada respuesta se envíe de inmediato.

Paso 4: Mide lo que has cambiado

La optimización sin medición es una conjetura. Antes de tocar cualquier configuración, establece una línea de base con números reales:

• Tiempo hasta el primer byte (TTFB): medid desde múltiples ubicaciones geográficas utilizando WebPageTest. El objetivo es menos de 200 ms para la región de usuarios principal.
• Latencia p95 y p99: la latencia media oculta los picos que realmente molestan a los usuarios. Tu supervisión debe realizar un seguimiento de los percentiles.
• Estadísticas de la interfaz de red: netstat -s | grep -i retransmit muestra el recuento de retransmisiones TCP; los números altos indican una pérdida de paquetes que aumenta tu latencia.

Después de aplicar los cambios, ejecuta las mismas pruebas. Las mejoras en el TTFB de 20-40 ms son habituales solo con el ajuste de TCP en servidores con una configuración insuficiente. Los estudios sobre el rendimiento web muestran de forma sistemática que cada reducción de 100 ms en el TTFB se correlaciona con mejoras cuantificables en las tasas de conversión de las aplicaciones de comercio electrónico.

Paso 5: Nivel de ancho de banda y capacidad de ráfaga

Los servidores dedicados de InMotion se suministran con un ancho de banda ampliable de 10 Gbps. Para la mayoría de las cargas de trabajo, esto es suficiente. Para las aplicaciones que suelen requerir un alto rendimiento (entrega de vídeo, transferencias de archivos de gran tamaño o respuestas API de alta frecuencia), la actualización a 10 Gbps garantizados y sin medición elimina la posibilidad de que la contienda por el ancho de banda durante los periodos de máxima actividad afecte a tus cifras de latencia.

La saturación del ancho de banda provoca la acumulación de colas, y la acumulación de colas aumenta la latencia. Si tu iftop o nethogs muestran una utilización constante cercana al máximo, la limitación real es el nivel de ancho de banda, no la configuración TCP.

La latencia de red es diseño de infraestructura, no resolución de problemas

Los equipos que gestionan las implementaciones de servidores dedicados con menor latencia consideran la geografía, la configuración de la CDN y los ajustes del kernel como decisiones de infraestructura de primer orden, y no como cuestiones secundarias. Eligen el centro de datos adecuado para la distribución de sus usuarios, envían los activos estáticos al borde y ajustan el kernel para que se adapte al ancho de banda por el que pagan.

La buena noticia: un servidor dedicado bien configurado con las instalacionesInMotion Hostingen Los Ángeles o Ámsterdam te proporciona los recursos necesarios para alcanzar esos objetivos. La configuración es tuya.

Lectura relacionada: Supervisión de recursos del servidor y ajuste del rendimiento | Estrategias de protección contra ataques DDoS para infraestructuras dedicadas