Esteartículoexplica por qué TCP sobre TCP podría ser un desastre de rendimiento.
Según tengo entendido, la conexión TCP "externa" se ocupa de la pérdida de paquetes y la congestión de la red y actúa en consecuencia aumentando los tiempos de espera (y, por lo tanto, reduciendo el rendimiento). Sin embargo, la conexión TCP "interna" no ve estas condiciones de red porque están "reparadas" por el TCP externo. Y por lo tanto, el TCP "interno" sigue enviando paquetes a la velocidad anterior y, por lo tanto, explota el búfer de envío interno de la conexión TCP "externa".
Mis preguntas son:
- ¿Es correcto mi entendimiento?
- Parece que la crisis de TCP sobre TCP es sólo interna (es decir, sólo afecta a los buffers locales), pero ¿afecta también a la red? ¿Causa más congestiones en la red y degrada otras conexiones en la misma red?
- ¿Cómo resuelven este problema las VPN basadas en TCP? OpenVPN tiene unaartículosobre esto, pero no dice por qué no es un problema en la práctica (¿o sí lo es?)
¡Muchas gracias por cualquier respuesta!
Respuesta1
Según tengo entendido, el problema de la "fusión de TCP" no es difícil de resolver: solo necesita establecer un tiempo de espera de retransmisión grande para la conexión TCP interna.
Al aumentar en gran medida el tiempo de espera mínimo de retransmisión de la conexión TCP interna, hemos desactivado efectivamente el mecanismo de retransmisión de tiempo de espera del TCP interno. Por lo tanto, se evita el problema de la fusión de TCP.
Por ejemplo, en Linux, puede utilizar ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12spara aumentar el tiempo de espera mínimo de retransmisión de todas las conexiones internas establecidas a través de OpenVPN de 0,2 segundos a 12 segundos (se supone que 192.168.168.1/24 es su segmento de red OpenVPN).
Puede configurar el comando anterior como devolución de llamada del evento activo de OpenVPN. De esta manera, hemos evitado el problema de la fusión de TCP de una manera sencilla.
Usamos este método para optimizar el enlace tcp-over-tcp. Incluso en líneas con alta latencia (cientos de milisegundos) y alta pérdida de paquetes, no hemos encontrado ningún efecto adverso.
PD: en una línea con alta latencia, alta pérdida de paquetes y gran ancho de banda, es obvio que necesita preparar una ventana grande para que las conexiones TCP internas ocupen todo el ancho de banda.
ACTUALIZAR:
La pregunta aquí es: ¿por qué TCP sobre TCP no tiene un efecto notable en la VPN basada en TCP?
Porque en una línea de alta calidad que rara vez pierde paquetes, el fenómeno de fusión de TCP no es prominente.
Respuesta2
Yo diría que esto tiene más que ver con la forma en quetcpfunciona, y no con OpenVPN per se. Aquí viene una larga perorata y mis pocos centavos:
¿Es correcto mi entendimiento?
Más o menos sí, pero la conexión TCP interna no está "protegida". Si el externo descarta un paquete y el rendimiento disminuye o la latencia aumenta, la conexión interna también se verá limitada por esto; observe que no puede utilizar el rendimiento completo y comenzará a retroceder.
Parece que la crisis de TCP sobre TCP es sólo interna (es decir, sólo afecta a los buffers locales), pero ¿afecta también a la red?
Sólo tendrá una conexión TCP con el servidor, por lo que esto sólo afectará a esa conexión en particular y a todo lo que contenga. A lo que se refiere la crisis es a lo que describo en la respuesta anterior.
¿Causa más congestiones en la red y degrada otras conexiones en la misma red?
No, pero necesitaría definir "red" aquí. Si tiene una mala conexión a Internet, entonces sí, todo sufrirá caídas de paquetes u otros problemas de transmisión. Si quiere decir que solo hay un problema con la conexión de su cliente<=>servidor, entonces sus conexiones que no son VPN no se verían afectadas.
¿Cómo resuelven este problema las VPN basadas en TCP?
Al utilizar una única conexión al servidor, envíe el tráfico dentro de esa conexión y espere lo mejor.
OpenVPN tiene un artículo sobre esto pero no dice por qué no es un problema en la práctica, sino que es un problema en la práctica.
Sí. TCP tiene una sobrecarga mucho mayor en términos de tamaño de paquete que UDP, por lo que siempre estás pagando una penalización de tamaño al tener dos encabezados TCP (interior y exterior) en tu conexión. Los reenvíos y el aumento de TCP también afectarán su rendimiento. Si tiene una buena conexión, es decir, sin caídas, baja latencia y gran ancho de banda, entonces no verá gran parte del aumento/retroceso/reenvío y, por lo tanto, no lo notará. Si tiene una mala conexión, entonces la primera respuesta entra en juego: las conexiones externas podrían disminuir, esto afectará el tráfico interno que disminuirá, los paquetes pueden desordenarse y reenviarse, etc., lo que definitivamente afectar el rendimiento del túnel.
La respuesta larga es larga. Espero que esto haya tenido algún sentido para alguien más que para mí.