The Cable GuyOptimización automática de la ventana de recepción TCP
Joseph Davies
Bienvenido a la primera entrega de The Cable Guy de TechNet Magazine. Los admiradores de la columna del sitio web de TechNet ya saben que abarcamos todos los temas relacionados con la red, tradición que continuaremos aquí todos los meses. Si es nuevo y desea encontrar un archivo de columnas anteriores, diríjase al sitio de Cable Guy (en inglés).
Comencemos con el primer tema de esta nueva etapa: la ventana de recepción TCP.
El rendimiento a través de las conexiones TCP se puede limitar mediante el envío y recepción de aplicaciones, de implementaciones de TCP y la ruta de transmisión entre los puntos TCP. En esta columna voy a describir la ventana de recepción TCP y su efecto en el rendimiento TCP, el uso del ajuste de escala de la ventana TCP y la característica nueva Optimización automática de la ventana de recepción de Windows Vista™ que optimiza el rendimiento TCP para los datos recibidos.
Ventana de recepción TCP
Las conexiones TCP presentan un número importante de características. En primer lugar, se trata de circuitos lógicos punto a punto entre dos protocolos de nivel de aplicación. TCP no ofrece un servicio de entrega de uno a varios, sólo proporciona entrega de uno a uno.
En segundo lugar, las conexiones TCP están orientadas a la conexión. Antes de poder transferir los datos, dos procesos de nivel de aplicación deben negociar formalmente una conexión TCP mediante el proceso de establecimiento de conexión TCP. De igual forma, las conexiones TCP se cierran formalmente tras la negociación mediante el proceso de terminación de la conexión TCP.
En tercer lugar, los datos confiables enviados a través de una conexión TCP están secuenciados y se espera que el receptor dé una confirmación positiva. Si no se recibe dicha confirmación, se retransmitirá el segmento. En el receptor, los segmentos duplicados se han descartado y los que proceden de una secuencia se vuelven a colocar en el orden correcto.
En cuarto lugar, las conexiones TCP son de dúplex completo. Para cada punto TCP, la conexión TCP está compuesta por dos canalizaciones lógicas: una saliente y otra entrante. El encabezado TCP contiene el número de secuencia de los datos entrantes y una confirmación (ACK) para los datos salientes.
Asimismo, TCP ve los datos enviados a través de las canalizaciones lógicas de entrada y salida como una secuencia continua de bytes. El número de secuencia y el de confirmación para cada encabezado TCP se definen mediante límites de bytes. TCP no tiene conocimiento de los límites de registro o mensaje de la secuencia de bytes. El protocolo de nivel de aplicación debe ofrecer el análisis correcto de la secuencia entrante de bytes.
Para limitar el número de datos que se puede enviar simultáneamente y para proporcionar el control de flujo del lado del receptor, los puntos TCP usan una ventana. La ventana son todos los datos de la secuencia de bytes que el receptor permite que el remitente envíe. El remitente sólo puede enviar los bytes de la secuencia de bytes incluidos en la ventana. La ventana recorre la secuencia saliente de bytes del remitente y la secuencia entrante de bytes del receptor.
Para una canalización lógica determinada (una dirección de la conexión TCP de dúplex completo) el remitente mantiene una ventana de envío y el receptor una ventana de recepción. Cuando no existen datos o los segmentos ACK están en tránsito, se establece una coincidencia entre ventanas de envío y de recepción de canalización lógica. Dicho de otro modo, se establece la concordancia entre todos los datos de la secuencia saliente de bytes que puede enviar el remitente y todos los datos de la secuencia entrante de bytes que el receptor puede recibir. En la figura 1 se muestra dicha relación entre envío y recepción.
Figura 1** Establecimiento de coincidencia entre las ventanas de envío y recepción **(Hacer clic en la imagen para ampliarla)
Para indicar el tamaño de la ventana de recepción, el encabezado TCP contiene un campo de ventana de 16 bits. Cuando el receptor obtiene datos, envía segmentos de ACK al remitente para indicar la recepción correcta de bytes. En cada ACK, el campo de ventana toma nota del número de bytes que permanecen en la ventana de recepción. Cuando la aplicación envía, confirma y recupera datos, las ventanas de recepción y envío se desplazan hacia la derecha. La ventana de recepción es la que controla la cantidad de datos sin confirmar que pueden estar en tránsito desde el remitente hasta el receptor.
Puesto que pueden existir datos en la ventana de recepción que la aplicación no ha recuperado y datos que se han recibido pero no reconocido, la ventana de recepción TCP presenta una estructura adicional, como se muestra en la figura 2.
Figura 2** Tipos de datos de la ventana de recepción TCP **(Hacer clic en la imagen para ampliarla)
Observe la diferencia entre las ventanas de recepción máxima y actual. La ventana de recepción máxima presenta un tamaño fijo. La ventana de recepción actual tiene un tamaño variable que se corresponde con el número de datos restantes que el receptor permite que el remitente le envíe. El tamaño de la ventana de recepción actual corresponde al valor del campo de ventana anunciado en los segmentos ACK que se han enviado de vuelta hacia el remitente y es la diferencia que existe entre el tamaño de la ventana de recepción máxima y el número de datos recibidos y reconocidos pero no recuperados por la aplicación.
Ventana de recepción TCP y rendimiento TCP
Para optimizar el rendimiento TCP (en función de una ruta de transmisión prácticamente sin errores), el remitente debe enviar suficientes paquetes para completar la canalización lógica entre remitente y receptor. Se puede calcular la capacidad de la canalización lógica mediante la fórmula siguiente:
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
La capacidad se conoce como el producto del retraso de ancho de banda (BDP). La canalización puede ser ancha (ancho de banda alto) o estrecha (ancho de banda bajo); corta (RTT bajo) o larga (RTT alto). Las canalizaciones anchas y largas presentan el BDP más elevado. Ejemplos de rutas de transmisión de BDP elevado son las existentes entre redes de área extensa (WAN) de satélites o empresas que incluyan vínculos de fibra óptica intercontinental.
Aumento de rendimiento por parte del remitente para transmisiones de BDP elevado
La característica nueva Optimización automática de la ventana de recepción presenta una mejora en el rendimiento para los datos recibidos a través de vínculo de BDP elevado, pero qué ocurre con el rendimiento del remitente.
Los algoritmos existentes que evitan que un envío de punto TCP congestione la red se denominan algoritmos de inicio lento y control de congestión. Dichos algoritmos aumentan la ventana de envío (número de segmentos que el remitente puede enviar) durante el envío de datos inicial a través de la conexión y durante la recuperación de un segmento perdido.
El inicio lento aumenta la ventana de envío mediante un segmento TCP completo por cada segmento de confirmación recibido (para TCP en Windows XP y Windows Server 2003) o por cada segmento confirmado (para TCP en Windows Vista y Windows Server "Longhorn"). El control de congestión aumenta la ventana de envío mediante un segmento TCP completo por cada ventana de datos completa que se confirme.
Estos algoritmos funcionan bien con BDP bajos y tamaños de ventana de recepción pequeños. Sin embargo, cuando tiene una conexión TCP con un tamaño grande de ventana de recepción y un BDP elevado, como en la duplicación de datos entre dos servidores ubicados en un vínculo WAN de alta velocidad con un tiempo de ida y vuelta de 100 ms, estos algoritmos no aumentan la ventana de recepción con la velocidad suficiente para usar todo el ancho de banda de la conexión.
Para aprovechar el ancho de banda de las conexiones TCP en estas situaciones, la pila Next Generation TCP/IP incluye TCP compuesto (CTCP). CTCP aumenta más radicalmente la ventana de envío para las conexiones con tamaños de ventana de recepción grandes y productos BDP. CTCP intenta maximizar el rendimiento de estos tipos de conexión mediante la supervisión de las variaciones y pérdidas de retraso. CTCP también garantiza que su comportamiento no cause un efecto negativo en otras conexiones TCP.
En pruebas realizadas internamente en Microsoft, los tiempos de copias de seguridad de archivos de gran tamaño se redujeron en casi la mitad para una conexión de 1 Gbps con un tiempo de ida y vuelta de 50 ms. Las conexiones con un BDP de gran tamaño pueden incluso tener mejor rendimiento. CTCP y Optimización automática de la ventana de recepción colaboran para aumentar el uso del vínculo y pueden obtener mejoras del rendimiento para conexiones con productos BDP de gran tamaño.
CTCP está habilitado de forma predeterminada en los equipos que ejecutan Windows Server "Longhorn" y deshabilitado en los que ejecutan Windows Vista. Puede habilitar CTCP mediante el comando "netsh interface tcp set global congestionprovider=ctcp". Puede deshabilitar CTCP mediante el comando "netsh interface tcp set global congestionprovider=none".
El tamaño del campo de ventana en el encabezado TCP es 16 bits, lo que permite que un punto TCP anuncie un tamaño máximo de la ventana de recepción de 65.535 bytes. Puede calcular el rendimiento aproximado para un tamaño de ventana TCP determinado mediante la fórmula siguiente:
Throughput = TCP maximum receive windowsize / RTT
Por ejemplo, para una ventana de recepción de 65.535 bytes sólo podrá obtener un rendimiento aproximado de 5,24 Megabits por segundo (Mbps) en una ruta con 100 ms de RTT, independientemente del ancho de banda real de la ruta de transmisión. Con las actuales rutas de transmisión de BDP elevado, el tamaño de ventana TCP diseñado originalmente, incluso con el valor máximo, se convierte en un cuello de botella para el rendimiento.
Ajuste de escala de la ventana TCP
Para que los tamaños de ventana más grandes alojen rutas de transmisión de alta velocidad, la especificación RFC 1323 (ietf.org/rfc/rfc1323.txt) (en inglés) define un ajuste de escala de ventana que permite a un remitente anunciar un tamaño de ventana superior a 65.535 bytes. Una opción de ajuste de escala de la ventana TCP incluye un factor de ajuste de escala de ventana que, cuando se combina con un campo de ventana de 16 bits en el encabezado TCP, puede aumentar el tamaño de ventana de recepción hasta un máximo de 1 GB aproximadamente. La opción de ajuste de escala de ventana sólo se envía en segmentos sincronizados (SYN) durante el proceso de establecimiento de conexión. Ambos puntos TCP pueden indicar factores de ajuste de escala de ventana diferentes para los tamaños de ventana de recepción. Al permitir a un remitente enviar más datos a través de una conexión, el ajuste de escala de ventana TCP permite los nodos TCP para un mejor uso de algunos tipos de rutas de transmisión con productos BDP elevados.
Aunque el tamaño de ventana de recepción es importante para el rendimiento TCP, otro factor importante para determinar el rendimiento TCP óptimo es la velocidad de la aplicación en recuperar los datos acumulados en la ventana de recepción (velocidad de recuperación de la aplicación). Si la aplicación no recupera los datos, la ventana de recepción se empieza a llenar, lo que provoca que el receptor anuncie un tamaño actual de ventana menor. En el peor caso, la ventana de recepción máxima se llena completamente, lo que provoca que el receptor anuncie un tamaño de ventana de 0 bytes. En tal caso, el remitente debe detener el envío de datos hasta que la ventana de recepción se haya borrado. Por lo tanto, para optimizar el rendimiento TCP, la ventana de recepción TCP para una conexión debe tener configurado un valor que refleje tanto el BDP de la ruta de transmisión de la conexión como la velocidad de recuperación de la aplicación.
Incluso si puede determinar correctamente el BDP y la velocidad de recuperación de la aplicación, pueden cambiar con el transcurso del tiempo. La velocidad BDP varía en función de la congestión de la ruta de transmisión y la velocidad de recuperación de la aplicación según el número de conexiones a través de las que la aplicación recibe datos.
Ventana de recepción en Windows XP
Para la pila TCP/IP de Windows XP (y Windows Server® 2003), el tamaño máximo de la ventana de recepción presenta un número importante de atributos. En primer lugar, el valor predeterminado se obtiene a partir de la velocidad de vínculo de la interfaz emisora. El valor real se ajusta automáticamente a los incrementos uniformes del tamaño máximo de segmento (MSS) negociados durante el establecimiento de la conexión TCP.
En segundo lugar, el tamaño máximo de la ventana de recepción se puede configurar manualmente. Los valores del Registro HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize y HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize se pueden establecer en un máximo de 65.535 bytes (sin ajuste de escala de la ventana) o 1.073.741.823 (con ajuste de escala de la ventana).
En tercer lugar, el tamaño máximo de la ventana de recepción puede usar ajuste de escala de ventana. Se puede habilitar el ajuste de escala de ventana mediante el establecimiento del valor del Registro HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts en 1 o 3. De forma predeterminada, el ajuste de escala de la ventana sólo se utiliza en una conexión si el segmento SYN recibido contiene casualmente la opción de ajuste de escala de ventana.
Por último, se puede especificar el tamaño máximo de la ventana de recepción mediante la opción SO_RCVBUF de Windows Sockets de una aplicación cuando se inicia una conexión. Para el ajuste de escala de la ventana, la aplicación debe especificar un tamaño superior a 65.535 bytes.
A pesar de la compatibilidad con las ventanas escalables, el tamaño máximo de la ventana de recepción en Windows XP puede limitar el rendimiento, ya que es un tamaño máximo fijo para todas las conexiones TCP (salvo que lo especifique la aplicación), que se puede mejorar para algunas conexiones y reducirse para otras. Además, el tamaño máximo fijo de la ventana de recepción para una conexión TCP no varía por cambios en la velocidad de recuperación de la aplicación o por congestión en la ruta de transmisión.
Optimización automática de la ventana de recepción en Windows Vista
Para optimizar el rendimiento TCP, especialmente para rutas de transmisión con un BDP elevado, la pila Next Generation TCP/IP de Windows Vista (y la próxima versión de Windows Server denominada con el código "Longhorn") es compatible con la optimización automática de la ventana de recepción. Esta característica determina el tamaño óptimo de la ventana de recepción mediante la medición del BDP y de la velocidad de recuperación de la aplicación y la adaptación del tamaño de la ventana para las rutas de transmisión y las condiciones de aplicación próximas.
La optimización automática de la ventana de recepción permite el ajuste de escala de la ventana de TCP de forma predeterminada hasta un tamaño máximo de la ventana de recepción de 16 MB. Mientras los datos fluyen en la conexión, la pila Next Generation TCP/IP supervisa la conexión, mide el BDP actual y la velocidad de recuperación de la aplicación, y ajusta el tamaño de la ventana de recepción para optimizar el rendimiento. La pila Next Generation TCP/IP ha dejado de usar los valores del Registro TCPWindowSize.
la optimización automática de la ventana de recepción presenta una serie de ventajas. Determina automáticamente el tamaño óptimo de la ventana de recepción en función de cada conexión. En Windows XP, el valor del Registro TCPWindowSize se aplica a todas las conexiones. Las aplicaciones ya no deben especificar los tamaños de ventana TCP mediante opciones de Windows Sockets. Además, los administradores de TI no volverán a configurar manualmente un tamaño de ventana de recepción TCP para determinados equipos.
Gracias a la optimización automática de la ventana de recepción, un punto TCP basado en Windows Vista anunciará normalmente tamaños de ventana de recepción mayores que un punto TCP basado en Windows XP. Esto permite que el otro punto TCP llene la canalización hacia el punto TCP basado en Windows Vista mediante el envío de más segmentos de datos TCP sin necesidad de esperar a una ACK (dependiente del control de congestión TCP). Para un tráfico de red de cliente normal, como páginas web o correo electrónico, el servidor web o el servidor de correo electrónico podrán enviar más datos TCP al equipo cliente con una velocidad mayor, lo que aumenta el rendimiento general de la red. Cuanto mayores son los valores de BDP y velocidad de recuperación de datos de la conexión, mayor será el rendimiento.
Su influencia se nota en la red en que una secuencia de paquetes de datos TCP que se envía normalmente a un ritmo más lento y medido, se envía más rápido, lo que provoca un mayor aumento en el uso de red durante la transferencia de datos. Para equipos basados en Windows XP y Windows Vista que realizan la misma transferencia de datos en una canalización larga y ancha, se transfiere el mismo número de datos. Sin embargo, la transferencia de datos para el equipo cliente de Windows Vista es más rápida gracias al mayor tamaño de la ventana de recepción y a la habilidad del servidor para llenar la canalización desde el servidor hasta el cliente.
Puesto que la optimización automática de la ventana de recepción aumentará el uso de red de rutas de transmisión con BDP elevados, el uso de Calidad de servicio (QoS) o del límite de la velocidad de envío de la aplicación puede llegar a ser importante para las rutas de transmisión que funcionan al borde de sus posibilidades. Para satisfacer esta futura demanda, Windows Vista es compatible con la configuración de QoS basada en directivas de grupo que le permite limitar la velocidad del tráfico saliente para una dirección IP o puerto TCP. Para obtener más información, consulte estos recursos de QoS basados en directivas (en inglés).
Aumento del rendimiento TCP para redes con pérdidas elevadas
El rendimiento TCP de redes con pérdidas altas puede disminuir drásticamente por tiempos de espera y retransmisiones frecuentes. Ejemplos de redes con pérdidas altas son las redes inalámbricas (como las redes basabas en la directiva IEEE 802.11, el Servicio GPRS o el Sistema Universal de Telecomunicaciones Móviles (UMTS)), que pueden registrar grandes pérdidas de paquetes en función de las condiciones de red, la atenuación de la señal, las interferencias electromagnéticas y el cambio de ubicación del equipo.
La pila Next Generation TCP/IP es compatible con las cuatro especificaciones RFC siguientes para optimizar el rendimiento de entornos con grandes pérdidas:
RFC 2582: la modificación NewReno al algoritmo de recuperación rápida de TCP
El algoritmo de recuperación rápida, definido en la RFC 2001, se basa en el algoritmo Reno, que incrementa la cantidad de datos que un emisor puede enviar cuando se retransmite un segmento debido a un evento de retransmisión rápido. Aunque el algoritmo Reno funciona correctamente con segmentos perdidos únicos, no lo hace igual de bien con múltiples segmentos perdidos. El algoritmo NewReno proporciona un rendimiento más rápido gracias a que cambia la forma en la que un remitente puede incrementar la velocidad de envío durante la recuperación rápida cuando se pierden varios segmentos en una ventana de datos y el emisor recibe una confirmación parcial (sólo de una parte de los datos que se han recibido correctamente).
RFC 2883: una extensión a la opción de confirmación selectiva (SACK) para TCP
SACK, definida en RFC 2018, permite a un receptor indicar hasta cuatro bloques no contiguos de datos recibidos mediante el uso de la opción SACK TCP. RFC 2883 define un uso adicional de los campos de la opción TCP de SACK para confirmar paquetes duplicados. De este modo, el remitente puede determinar cuándo se ha retransmitido innecesariamente un segmento y ajustar su comportamiento para evitar futuras retransmisiones innecesarias. Mientras menos retransmisiones se envíen, mejor será el rendimiento general.
RFC 3517: algoritmo de recuperación de pérdidas conservador basado en la confirmación selectiva para TCP
La implementación actual de TCP/IP en Windows Server 2003 y Windows XP sólo usa la información de SACK para determinar los segmentos TCP que no han llegado a su destino. RFC 3517 define un método de uso de la información de SACK para llevar a cabo la recuperación de pérdidas cuando se han recibido confirmaciones duplicadas mediante la sustitución del algoritmo de recuperación rápida anterior cuando SACK está habilitada en una conexión. La pila Next Generation TCP/IP realiza un seguimiento de la información de SACK en cada conexión y supervisa las confirmaciones entrantes y duplicadas para permitir una recuperación más rápida cuando no se reciben varios segmentos en el destino.
RFC 4138: reenvío de recuperación de tiempo de espera de retransmisión (F-RTO, Forward RTO-Recovery): algoritmo para detectar falsos tiempos de espera de retransmisión con TCP y el protocolo de transporte de control de secuencias (SCTP, Stream Control Transmission Protocol)
Las retransmisiones de segmentos TCP falsos pueden producir un aumento repentino del RTT, lo que provoca que los tiempos de espera de retransmisión (RTO) de los segmentos enviados anteriormente empiecen a caducar y TCP empiece a retransmitirlos. Si el incremento ocurre justo antes de enviar una ventana completa de datos, un emisor puede retransmitir toda la ventana. El algoritmo F-RTO impide la retransmisión de segmentos TCP falsos mediante el siguiente comportamiento.
Cuando se agota el tiempo de espera de retransmisión para varios segmentos, TCP retransmite sólo el primero de ellos. Cuando se recibe la primera confirmación, TCP comienza a enviar segmentos nuevos (si el tamaño de ventana anunciado lo permite). Si en la siguiente confirmación se reconocen los demás segmentos que han agotado el tiempo de espera pero que no se han retransmitido, TCP determina que el tiempo de espera era falso y no retransmite dichos segmentos.
El resultado es que para los entornos en los que se producen incrementos repentinos y temporales del tiempo de ida y vuelta como, por ejemplo, cuando un cliente inalámbrico se desplaza de un punto de acceso a otro, F-RTO impide la retransmisión innecesaria de segmentos y vuelve más rápidamente a su velocidad de envío normal. El uso de la recuperación de pérdidas basada en SACK y F-RTO resulta idóneo para conexiones que usan vínculos GPRS.
Joseph Davieses escritor técnico en Microsoft y ha enseñado y escrito sobre temas de red de Windows desde 1992. Ha escrito cinco libros para Microsoft Press y es el autor de la columna mensual TechNet Cable Guy (en inglés).
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.