Aumente el rendimiento de la red mediante el escalamiento de ventanas TCP

El protocolo de control de transmisión (TCP) es un protocolo de red orientado a flujos que se basa en el protocolo de internet (IP). TCP garantiza que los paquetes de red se reciban en el orden en que se enviaron, sin duplicación. Para ello, TCP incorpora mecanismos de acuse de recibo y retransmisión.

TCP no requiere que se confirme la recepción de cada paquete IP antes de enviar el siguiente. La cantidad de datos (paquetes IP) que pueden estar "en vuelo" antes de ser reconocidos por el otro lado se llama "ventana TCP". Originalmente, la ventana TCP podía tener un tamaño máximo de 65.535 bytes. Sin embargo, la llegada de las redes modernas hizo inviable este límite.

Hoy en día, los datos se transmiten a una velocidad mucho mayor que cuando se inventó el protocolo TCP. Los datos que circulan por un centro de datos pueden alcanzar fácilmente los 100 GB/s. Esto convierte a la pequeña ventana TCP en un cuello de botella para la utilización eficiente de la red.

Por este motivo, en 1992 se añadió el escalamiento de ventanas TCP como extensión oficial de TCP en el RFC 1323. Esta extensión permite ventanas TCP mucho mayores, de hasta aproximadamente 1 GB de tamaño. En este artículo, exploraremos cómo funciona el escalamiento de ventanas TCP. También veremos sus ventajas y desventajas.

Fundamentos básicos de las ventanas TCP

En primer lugar, vamos a profundizar un poco más en las ventanas TCP y cómo funcionan en la práctica.

En realidad hay dos ventanas TCP, una para cada lado del flujo. Un lado del flujo mantiene un "contador de envíos" y un "contador de acuses de recibo". El contador de envíos cuenta cuántos bytes se han enviado, mientras que el contador de acuses de recibo informa al otro lado de cuántos bytes se han recibido. El otro lado de la conexión TCP mantiene los mismos contadores. Ambos contadores son campos de 32-bit incrustados en las cabeceras de los paquetes TCP.

El siguiente diagrama muestra el lado izquierdo enviando 90 bytes en tres paquetes y el lado derecho acusando recibo de esos 90 bytes colocando en su contador de acuse de recibo el número de secuencia enviado por el lado izquierdo:

En el ejemplo anterior, la ventana era de 90 bytes. En las especificaciones originales de TCP, el número máximo de bytes que se podían enviar sin recibir acuse de recibo era de 65.535.

¿Por qué las ventanas TCP pueden ser un cuello de botella?

En el caso de una red rápida y fiable, el límite original de la ventana TCP es un enorme cuello de botella. Para una red rápida de 100 GB/s, el tamaño máximo original de la ventana de 65.535 bytes se traduciría en unos 6 microsegundos de tráfico. Esto significa que la otra parte tendría que acusar recibo de los datos recibidos al menos cada 6 microsegundos para aprovechar al máximo el ancho de banda disponible en la red.

Por desgracia, es poco probable que esto ocurra dado el corto periodo de tiempo y porque el sistema operativo estará extremadamente ocupado procesando los datos entrantes. Lo más probable es que no envíe acuses de recibo a tiempo.

Las transmisiones suelen ser desiguales. En la mayoría de los casos, un lado de la conexión TCP actúa como un cliente que envía una consulta. El otro lado responde con los datos. De esta forma, en una conexión TCP, la gran mayoría de los datos fluyen unidireccionalmente y el lado receptor tendrá que enviar paquetes vacíos sólo para acusar recibo de los datos recibidos. Esto resulta ineficiente.

Para el tráfico dentro del centro de datos de gran volumen, existen las tramas jumbo Ethernet. Pueden transportar unos 9.000 bytes de datos, mientras que las tramas Ethernet normales transportan unos 1.500 bytes. Usando tramas jumbo, se podría alcanzar el límite de la ventana TCP luego de tan sólo 7 paquetes. De nuevo, la necesidad constante del receptor por un acuse de recibo ralentizará el tráfico de la red

Solución: escalamiento de ventanas TCP

El escalamiento de ventanas TCP es una extensión de TCP definida en el RFC 1323. Ambas partes negocian durante el establecimiento de la conexión con los dos primeros paquetes que se intercambian entre ambas partes. Estos dos paquetes tienen activado el indicador TCP de "sincronización", normalmente abreviado como indicador SYN. El escalamiento de ventanas TCP es un coeficiente multiplicador de la ventana TCP original. El multiplicador es una potencia de 2 y puede ir de 2^0 —es decir, sin cambios en la ventana TCP— a 2^14.

Si el paquete SYN inicial enviado por el cliente incluye la extensión de escalamiento de ventana con una escala de 0, esto permite a la otra parte negociar el escalamiento. Por lo tanto, se aconseja que —incluso si no desea aumentar su tamaño de ventana TCP— la parte cliente incluya una extensión de escalamiento de ventana TCP nula para permitir que la parte servidor negocie su propio escalamiento de ventana TCP.

El tamaño máximo de ventana TCP que se puede alcanzar utilizando el escalamiento de ventana TCP es para un factor de escalamiento de 2^14=16.384. Esto resultaría en un tamaño de ventana de 16.384 x 65.535 = 1.073.725.440 bytes. Esto es aproximadamente 1 GB. Hay que tener en cuenta que los contadores TCP tienen un tamaño de 32 bits, por lo que se pueden seguir utilizando sin cambios. Esto se debe a que pueden contener un valor máximo de 4 GB.

Cómo activar el escalamiento de ventanas TCP en Linux

Si estás ejecutando Linux, puedes comprobar si la extensión de escalamiento de ventanas TCP está habilitada ejecutando el siguiente comando:

$ cat /proc/sys/net/ipv4/tcp_window_scaling 

Esto mostrará "1" si está habilitada o "0" si no lo está.

Para activar temporalmente el escalamiento de ventanas TCP, ejecuta el siguiente comando:

$ sysctl net.ipv4.tcp_window_scaling=1 

A continuación se explica cómo habilitarla permanentemente:

 $ echo net.ipv4.tcp_window_scaling=1 \ > /etc/sysctl.d/50-tcp-window-scaling.conf \ && sysctl --system 

Cuando el escalamiento de ventanas TCP es una mala idea

Los beneficios del escalamiento de ventanas TCP parecen claros y puede que te sientas tentado a activarlo en todas partes. Sin embargo, hay circunstancias en las que el escalamiento de ventanas TCP causará más problemas de los que resuelve. Las probabilidades de que esto ocurra aumentan cuando la red no es fiable o es lenta.

En este caso, es mejor tener una ventana más pequeña. De lo contrario, habrá demasiadas retransmisiones y el rendimiento de la conexión TCP puede caer drásticamente. Esto puede llegar al punto de que la gran mayoría del tráfico consista en retransmisiones. Dado que la red es lenta y/o poco fiable desde un principio, puedes entender que esta situación será perjudicial para el rendimiento de la conexión TCP.