Las técnicas de ajuste de TCP ajustan los parámetros para evitar la congestión de la red de las conexiones del Protocolo de control de transmisión (TCP) en redes de gran ancho de banda y alta latencia . Las redes bien ajustadas pueden funcionar hasta 10 veces más rápido en algunos casos. [1] Sin embargo, seguir ciegamente instrucciones sin comprender sus consecuencias reales también puede perjudicar el rendimiento.
Producto de retardo de ancho de banda (BDP) es un término utilizado principalmente junto con TCP para referirse al número de bytes necesarios para llenar una "ruta" TCP, es decir, es igual al número máximo de bits simultáneos en tránsito entre el transmisor y el receptor.
Las redes de alto rendimiento tienen BDP muy grandes. Para dar un ejemplo práctico, dos nodos que se comunican a través de un enlace de satélite geoestacionario con un tiempo de retardo de ida y vuelta (o tiempo de ida y vuelta, RTT) de 0,5 segundos y un ancho de banda de 10 Gbit/s pueden tener hasta 0,5×10 Gbits . es decir, 5 Gbit de datos en tránsito no reconocidos. A pesar de tener latencias mucho más bajas que los enlaces satelitales, incluso los enlaces de fibra terrestre pueden tener BDP muy altos porque su capacidad de enlace es muy grande. Los sistemas operativos y protocolos diseñados tan recientemente como hace unos años, cuando las redes eran más lentas, se ajustaron para BDP de órdenes de magnitud más pequeñas, con implicaciones para el rendimiento alcanzable limitado.
Las configuraciones TCP originales admitían buffers de tamaño de ventana de recepción TCP de hasta 65.535 (64 KiB - 1) bytes, lo que era adecuado para enlaces lentos o enlaces con RTT pequeños. Las opciones de alto rendimiento que se describen a continuación requieren búferes más grandes.
El almacenamiento en búfer se utiliza en todos los sistemas de red de alto rendimiento para manejar los retrasos en el sistema. En general, el tamaño del búfer deberá ampliarse proporcionalmente a la cantidad de datos "en tránsito" en cualquier momento. Para aplicaciones de muy alto rendimiento que no son sensibles a los retrasos de la red, es posible interponer grandes retrasos en el almacenamiento en búfer de extremo a extremo colocando puntos de almacenamiento de datos intermedios en un sistema de extremo a extremo y luego utilizar sistemas automatizados y programados en tiempo no real. transferencias de datos para llevar los datos a sus puntos finales.
El rendimiento máximo alcanzable para una única conexión TCP está determinado por diferentes factores. Una limitación trivial es el ancho de banda máximo del enlace más lento del camino. Pero también existen otros límites menos obvios para el rendimiento de TCP. Los errores de bits pueden crear una limitación tanto para la conexión como para el RTT.
En redes de computadoras , RWIN (ventana de recepción TCP) es la cantidad de datos que una computadora puede aceptar sin reconocer al remitente. Si el remitente no ha recibido acuse de recibo del primer paquete que envió, se detendrá y esperará y si esta espera excede un cierto límite, incluso podrá retransmitir . Así es como TCP logra una transmisión de datos confiable .
Incluso si no hay pérdida de paquetes en la red, las ventanas pueden limitar el rendimiento. Debido a que TCP transmite datos hasta el tamaño de la ventana antes de esperar los acuses de recibo, es posible que no siempre se utilice todo el ancho de banda de la red. La limitación causada por el tamaño de la ventana se puede calcular de la siguiente manera:
donde RWIN es la ventana de recepción de TCP y RTT es el tiempo de ida y vuelta de la ruta.
En un momento dado, la ventana anunciada por el lado de recepción de TCP corresponde a la cantidad de memoria de recepción libre que ha asignado para esta conexión. De lo contrario, correría el riesgo de perder paquetes recibidos por falta de espacio.
El lado emisor también debe asignar la misma cantidad de memoria que el lado receptor para un buen rendimiento. Esto se debe a que, incluso después de que los datos se hayan enviado a la red, el lado emisor debe mantenerlos en la memoria hasta que se reconozca su recepción exitosa, en caso de que sea necesario retransmitirlos. Si el receptor está lejos, los acuses de recibo tardarán mucho en llegar. Si la memoria de envío es pequeña, puede saturarse y bloquear la emisión. Un cálculo simple da el mismo tamaño de memoria de envío óptimo que para el tamaño de memoria de recepción indicado anteriormente.
Cuando se produce una pérdida de paquetes en la red, se impone un límite adicional a la conexión. [2] En el caso de una pérdida de paquetes leve a moderada cuando la velocidad TCP está limitada por el algoritmo para evitar la congestión , el límite se puede calcular de acuerdo con la fórmula (Mathis, et al.):
donde MSS es el tamaño máximo de segmento y P pérdida es la probabilidad de pérdida de paquetes. Si la pérdida de paquetes es tan rara que la ventana TCP se extiende por completo periódicamente, esta fórmula no se aplica.
A lo largo de los años, se han realizado varias extensiones a TCP para aumentar su rendimiento en enlaces rápidos de alto RTT ("redes largas y gruesas" o LFN).
Las marcas de tiempo TCP (RFC 1323) desempeñan una doble función: evitan ambigüedades debido al campo de número de secuencia de 32 bits y permiten una estimación de RTT más precisa en presencia de múltiples pérdidas por RTT. Con esas mejoras, resulta razonable aumentar la ventana TCP más allá de 64 kB, lo que se puede hacer usando la opción de escalado de ventana (RFC 1323).
La opción de reconocimiento selectivo de TCP (SACK, RFC 2018) permite a un receptor de TCP informar con precisión al remitente de TCP sobre qué segmentos se han perdido. Esto aumenta el rendimiento en enlaces de alto RTT, cuando son posibles múltiples pérdidas por ventana.
Path MTU Discovery evita la necesidad de fragmentación dentro de la red , aumentando el rendimiento en presencia de pérdida de paquetes.
La longitud de la cola IP predeterminada es 1000, que generalmente es demasiado grande. Imagine una estación base Wi-Fi con una velocidad de 20 Mbit/s y un tamaño de paquete promedio de 750 bytes. ¿Qué tamaño debe tener la cola de IP? Un cliente de voz sobre IP debería poder transmitir un paquete cada 20 ms. El número máximo estimado de paquetes en tránsito sería entonces:
Tamaño estimado del buffer = 20000000 * 0,020 / 8 / 750 = 66
Una mejor longitud de cola sería:
ifconfig wlan0 mtu 1492 txqueuelen 100
