Muchos administradores siguen perpetuando, en ServerFault y en otros lugares, lo mala que es la idea de TCP sobre TCP, por ejemplo, en VPN. Que incluso la más mínima pérdida de paquetes hará que uno sufra de una degradación de rendimiento al menos severa si no se produce una fusión de TCP, y que TCP-sobre-TCP, por lo tanto, debe evitarse estrictamente. Y eso probablemente alguna vez fue cierto, por ejemplo, 2001 cuando se escribió este artículo al que todavía se hace referencia.
Pero desde entonces hemos visto grandes avances en tecnología y protocolos. Hoy en día tenemos 'ACK selectivo' implementado en casi todas partes, y la ley de Moore nos ha dado mucha más memoria, y con ella vinieron grandes buffers TCP optimizados para enlaces ascendentes Gbit. Además, la pérdida de paquetes es un problema mucho menor en estos días en enlaces que no son de radio. Todo esto debería aliviar significativamente el problema de TCP sobre TCP, ¿no?
Tenga en cuenta que hay escenarios del mundo real en los que, por ejemplo, las VPN basadas en TCP son más fáciles de implementar y operar que las basadas en UDP / ESP (ver más abajo). Por lo tanto mi pregunta:
¿En qué circunstancias (pérdida de paquetes de enlace y latencia) el rendimiento de TCP sobre TCP es significativamente peor que el de TCP solo, suponiendo compatibilidad con SACK y almacenamientos intermedios de TCP de tamaño decente en ambos extremos?
Sería genial, así que vea algunas mediciones que muestran las correlaciones entre la pérdida / latencia de paquetes (conexión externa) y el rendimiento / fluctuación (conexión interna) - para TCP sobre TCP y solo para TCP. encontré este interesante artículo , pero parece estar preocupado solo por la latencia y no abordar la pérdida de paquetes (externos).
Además: ¿Hay configuraciones recomendadas (por ejemplo, opciones de TCP, configuraciones de búfer, reducción de MTU / MSS, etc.) para reducir la brecha de rendimiento entre TCP y TCP sobre TCP?
Actualización: nuestra razón de ser.
Esta pregunta sigue siendo muy relevante en algunos escenarios del mundo real. Por ejemplo, implementamos dispositivos integrados en grandes edificios que recopilan datos de sensores y los introducen en nuestra plataforma a través de VPN. El problema al que nos enfrentamos son los firewalls y los enlaces ascendentes configurados incorrectamente que no estamos bajo nuestro control, combinados con los reticentes departamentos de TI. Vea un ejemplo detallado discutido aquí .
En muchos de estos casos, cambiar de una VPN que no sea TCP a una basada en TCP (muy fácil si usa OpenVPN como nosotros) es una solución rápida que nos permite evadir las batallas ascendentes de señalar con el dedo. Por ejemplo, a menudo el puerto TCP 443 generalmente está permitido (al menos a través de proxy), o podemos superar los problemas de Path-MTU simplemente reduciendo la opción MSS de TCP.
Sería bueno saber en qué circunstancias una VPN basada en TCP puede considerarse una alternativa viable, por lo que podemos tomar una decisión informada que supere los pros y los contras de cualquiera de las opciones. Por ejemplo, sabemos que TCP-VPN está bien para nosotros en enlaces que no son de radio, pero tenemos una buena cantidad de clientes remotos en enlaces ascendentes 3G con pérdida significativa de paquetes y alta latencia: ¿cómo funcionaría un TCP-VPN allí?
Traté de mejorar el título y la pregunta central en consecuencia; espero que tenga sentido.