Una conexión por satélite generalmente tiene un RTT de alrededor de 500 ms. Las conexiones generalmente sufren velocidades de transferencia subóptimas, a pesar de las grandes cantidades de ancho de banda, porque los reconocimientos TCP tardan demasiado en llegar.
Tengo entendido que una buena manera de abordar este problema con las conexiones TCP es establecer el tamaño de la ventana TCP en la velocidad de conexión (en bits) multiplicada por RTT (en segundos). Por lo tanto, una conexión de 1 Mbps por satélite debería tener un tamaño de ventana de 512 kb.
¿Qué peligros hay en esto? ¿Hay otros ajustes similares que deberían realizarse para optimizar las conexiones satelitales? Entiendo que muchos sistemas operativos modernos modificarán el tamaño de la ventana automáticamente, pero ¿serán lo suficientemente agresivos como para hacer que el tamaño de la ventana sea lo suficientemente grande como para funcionar en comunicaciones por satélite?
Además, voy a suponer que un tamaño de ventana grande no es deseable en redes que frecuentemente descartan paquetes, ya que la retransmisión se realizará en el tamaño de la ventana y usted puede dedicar gran parte de su ancho de banda a la sobrecarga de retransmisión.
Gracias, todavía estoy aprendiendo mucho sobre networking y agradezco tus aportes.
Respuesta1
Por lo general, debería utilizar una pila TCP que implemente el escalado adecuado de Windows. Pero, por supuesto, tiene razón en que el tamaño de su ventana debe coincidir con ese producto de retardo de ancho de banda (BDP). En caso de que tenga un BDP variable, puede establecer el tamaño de la ventana en algo que esperaría como el "peor" caso común. Curiosamente, la mayoría de las conexiones no sufren demasiado si el tamaño de la ventana es mayor que el BDP (no debería serformademasiado grande, por supuesto), pero muestra un rendimiento degradado si el tamaño de la ventana es mucho más pequeño que el BDP.
Para comprobar si su pila TCP/IP está aumentando adecuadamente el tamaño de la ventana, debe emplear Wireshark o cualquier otro rastreador de tráfico. Puede mirar directamente la bandera del tamaño de la ventana en el encabezado (¡teniendo en cuenta los factores de escala!). Wireshark también puede mostrar el tamaño efectivo de la ventana teniendo en cuenta el factor de escala.
Consulte este tutorial sobre cómo trazar el tamaño de su ventana TCP en función del tiempo.aquí.
Respuesta2
Esto es totalmente académico porque nadie ejecuta TCP a través de conexiones satelitales. No conozco ningún proveedor de satélite que haga esto. Todos ejecutan protocolos específicos de satélite a través del satélite y colocan el punto final TCP en la estación terrestre.
Cuando una máquina en la red envía un paquete TCP SYN al terminal satélite, el terminal satélite envía una solicitud de proxy TCP al satélite. Esto indica a la estación terrestre que abra una conexión TCP a algún servidor en Internet. La estación terrestre habla TCP con el servidor de Internet. El terminal satelital no habla TCP a través del satélite, sino que habla un protocolo optimizado para uso satelital. La estación terrestre actúa como proxy entre el terminal satelital y el servidor de Internet.
Respuesta3
Para mayor comodidad, existen calculadoras de productos de retardo de ancho de banda disponibles; una de ellas esaquí. En cuanto a las ventanas grandes que causan problemas en caso de pérdida de paquetes, esa es exactamente la razón por la que las ventanas TCP son variables. Tras la pérdida de paquetes, el tamaño de la ventana disminuirá, lo que permitirá menos datos en tránsito y la consiguiente reducción en la velocidad de transmisión. Después de un período de tiempo, el tamaño de la ventana se renegociará.
En realidad, su latencia no es tan mala para el satélite: un RTT de 1 s a 1 M es solo una ventana de 125 K. Un buen número de sistemas operativos modernos admitirían esto fácilmente desde el primer momento, por lo que es posible que no sean necesarias modificaciones adicionales.
Además, algunos han tenido muy buena suerte con los distintos optimizadores de WAN disponibles en el mercado. Estos tienden a optimizar el tamaño de las ventanas TCP y a utilizar el almacenamiento en caché y la compresión para impulsar más el enlace y mejorar la capacidad de respuesta aparente.