Tengo montado un servidor con soporte Xen, donde he virtualizado un servidor web con Apache. Desde hace un par de días me he dado cuenta que cuando intento acceder a la web usando como cliente Windows (indistintamente del navegador), la conexión era terriblemente lenta, mientras que desde un GNU/Linux la web me cargaba sin problemas.

Llevo casi 2 días obsesionado por ver que era lo que ocurría, el esquema virtualizado es el siguiente:

Internet < ==> | [Host real] ----> redirige puerto 80 ---> [Guest virtualizado] |

En la configuración del servidor securicé el sistema cambiando parámetros del kernel (p.ej. Syn cookies), realizando hardening de Apache, configurando el firewall con iptables, estableciendo QoS, etc… Me he pasado horas cambiando toda esa configuración para determinar el origen del problema.

Dado que había detectado el problema en clientes Windows y no en Linux, supuse que tenia que ser algo a nivel de red TCP. Sin embargo, en cuanto hice pruebas más exaustivas validando la velocidad de descarga, descubrí que si hacía un wget de un fichero del Guest la velocidad de bajada era como mucho 7 Kb/s, mientras que si el fichero lo situaba en el Host real, podia descargar a la velocidad máxima.

Por tanto aislé el problema a la red Xen y conseguí dar con la solución en este post. Basta con ejecutar en el guest:

/usr/sbin/ethtool -K eth0 tx off

Si explico toda la historia y no voy directo al grano es porque me llama la atención no haber percibido ese problema desde un cliente Linux. No llego a entender muy bien el motivo, a primera vista parece razonable deducir que la pila TCP/IP de Linux es bastante más óptima y se comporta mejor con conexiones lentas.

De hecho, mientras buscaba soluciones identifiqué un problema de Windows Vista con la ventana TCP que puede aparecer en función de los dispositivos de red por los que viaje el tráfico. Para ver la configuración actual en Windows:

netsh interface tcp show global

Resultado:

TCP Global Parameters
———————————————-
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : highlyrestricted
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled 

Probé a desactivar el auto-tuning de la ventana:

netsh interface tcp set global autotuning=disabled

Pero no tuve suerte, dado que esta no era la fuente del problema. No obstante, viene bien conocer esa problemática porque en redes de algunos clientes si he tenido problemas de velocidad y quizás esto pueda mejorarlo.