El Impuesto TCP-sobre-TCP: Una Autopsia Arquitectónica

Tu túnel no es lento por tu ISP; es lento porque tus paquetes están atrapados en un bucle de “retransmisión doble”. Para un ingeniero de sistemas, la fibra de alta velocidad se siente como una conexión dial-up en el momento en que envuelves un flujo TCP dentro de otro flujo TCP. Este fenómeno, conocido en círculos de redes como el Impuesto TCP-sobre-TCP (o más dramáticamente, el Colapso TCP), es un patrón arquitectónico anti-pattern clásico.

En esta autopsia, disecaremos las razones matemáticas y algorítmicas por las cuales túneles SSH, OpenVPN-TCP y otras arquitecturas TCP anidadas fallan incluso con pérdida de paquetes menor, y por qué alternativas modernas como WireGuard y QUIC son la única cura para túneles “lentos”.

1. La Anatomía del Encapsulado

Para entender el impuesto, primero debemos observar la pila. Cuando ejecutas un túnel SSH o un VPN basado en TCP, no solo envías datos; estás encapsulando una máquina de estado Inner TCP completa dentro de una máquina de estado Outer TCP.

En una conexión estándar sin túnel, TCP gestiona el control de flujo y la fiabilidad directamente sobre la capa IP (que es “mejor esfuerzo” e poco fiable). Sin embargo, en un túnel:

El Inner TCP (tu aplicación) piensa que está hablando con un host remoto. Gestiona números de secuencia, ACKs y una ventana de congestión (cwnd).
El Outer TCP (el túnel) ve los paquetes internos como carga útil en crudo. Añade sus propios números de secuencia, ACKs y su propia cwnd.

En una red perfecta, esto funciona. Pero internet nunca es perfecto.

2. La Autopsia Matemática: ¿Por qué el 1% de pérdida se siente como el 90%?

El núcleo del “Impuesto” es cómo reaccionan las dos capas ante la pérdida de paquetes. En una conexión TCP de una sola capa, el rendimiento se rige aproximadamente por la Ecuación de Mathis:

Throughput ≤ MSS / (RTT × √p)

Donde: - MSS: Tamaño máximo de segmento - RTT: Tiempo de ida y vuelta - p: Probabilidad de pérdida de paquete

Cuando anidas TCP, la probabilidad de pérdida p no solo reduce el rendimiento linealmente; provoca un conflicto de sincronización entre dos temporizadores independientes.

El Bucle de Retransmisión Doble

Imagina que se pierde un paquete en el cable físico:

Respuesta del Outer TCP: El túnel detecta el paquete perdido y detiene todo para retransmitirlo. La cwnd del túnel se reduce a la mitad.
Perspectiva del Inner TCP: Mientras el túnel está retransmitiendo, el paquete de la aplicación interna está “atrapado” en el búfer del túnel. El Inner TCP ve un RTT masivo.
El Colapso: Si el tiempo que tarda el Outer TCP en retransmitir con éxito es mayor que el RTO (Retransmission Timeout) del Inner TCP, este también decide que el paquete se perdió. Dispara su propia retransmisión.

Ahora, tienes dos capas enviando los mismos datos. El túnel ya está congestionado, y la aplicación acaba de duplicar la carga. Esto crea un ciclo de retroalimentación donde los búferes se llenan con retransmisiones redundantes, elevando el RTT efectivo a segundos.

Según investigaciones recientes, los bucles de control en los TCP internos y externos interfieren destructivamente entre sí porque el TCP externo oculta la salud de la conexión del TCP interno. Esta interferencia es lo que transforma una pérdida menor en una degradación catastrófica del rendimiento.

3. Bloqueo Head-of-Line (HoL): La Prisión Secuencial

TCP es un protocolo de flujo de bytes confiable. Garantiza que la aplicación reciba los datos en el orden exacto en que fueron enviados. Esta es su mayor fortaleza y, en un túnel, su fallo fatal.

La Cola Secuencial

Si el Paquete #1 se pierde pero los Paquetes #2, #3 y #4 llegan seguros, la pila TCP no puede entregar los Paquetes #2–4 a la aplicación. Deben permanecer en el búfer hasta que el Paquete #1 sea retransmitido y llegue.

En un túnel SSH, este efecto es global. Si multiplexas múltiples flujos (por ejemplo, una conexión a base de datos y una solicitud web) a través de un solo túnel SSH, un paquete perdido en el flujo de la base de datos bloqueará que la solicitud web termine, incluso si los paquetes web llegaron perfectamente.

Matemáticas de la Espera

La probabilidad de que un paquete se retrase por bloqueo HoL en un flujo con n paquetes pendientes y tasa de pérdida p es aproximadamente 1 - (1-p)^n. A medida que n (el tamaño de ventana) aumenta para llenar un canal de alta velocidad, la probabilidad de una parada se acerca al 100%, incluso con p < 0.1%.

Este problema se vuelve aún más pronunciado en entornos modernos de alta velocidad donde los tamaños de ventana son necesariamente grandes para llenar el producto ancho-pendiente.

4. Impacto en el Mundo Real: Benchmarks y Estudios de Caso Recientes

WireGuard vs. VPNs Tradicionales

Estudios recientes proporcionan evidencia concreta del impuesto TCP-sobre-TCP. En entornos VMware, WireGuard demostró un rendimiento TCP superior a 210.64 Mbps en comparación con OpenVPN a 110.34 Mbps, con una pérdida de paquetes significativamente menor del 12.35% frente al 47.01%.

Las pruebas de campo han mostrado resultados aún más dramáticos. En condiciones prácticas, WireGuard fue en promedio 3.3 veces más rápido que OpenVPN, demostrando el costo real de la arquitectura TCP-sobre-TCP.

Rendimiento a Gran Escala

Las soluciones VPN modernas han evolucionado significativamente. En redes de gigabit, Netmaker logró velocidades de transferencia de datos consistentes de 7.88 Gbits/sec, casi idénticas a WireGuard en kernel a 7.89 Gbits/sec. Este rendimiento casi nativo solo es posible porque WireGuard evita por completo el impuesto TCP-sobre-TCP.

La brecha de rendimiento se amplía aún más en condiciones de red desafiantes. WireGuard logra su rendimiento gracias a varios factores clave: un diseño ligero de aproximadamente 4,000 líneas de código en comparación con las decenas de miles de OpenVPN, cifrado moderno ChaCha20-Poly1305 que funciona eficientemente en todos los procesadores, e integración en kernel que procesa paquetes sin costosos cambios de contexto.

Resultados en Implementaciones Reales

El hardware de nivel consumidor muestra un rendimiento impresionante de WireGuard. Benchmarks recientes en routers modernos demuestran que WireGuard puede alcanzar casi la tasa completa del enlace en conexiones de fibra gigabit simétricas, con un rendimiento alrededor de 1,080 Mbps incluso en hardware de gama media.

5. El “Colapso” y el Conflicto en el Control de Congestión

Algoritmos TCP como CUBIC o NewReno están diseñados para explorar el ancho de banda hasta que detectan una caída. Cuando dos algoritmos así están anidados, luchan por el mismo recurso:

El TCP externo intenta llenar el canal.
El TCP interno también intenta llenar el canal.
Cuando ocurre una caída, ambos reducen su ventana.

Debido a que el TCP externo almacena en búfer los ACKs del TCP interno, la estimación del RTT del TCP interno se vuelve “ruidosa.” No puede calcular con precisión el producto ancho-pendiente (BDP).

Este “Compresión de ACKs” hace imposible que la conexión interna alcance un estado estable de alta velocidad. Este diseño puede fallar cuando apilas conexiones TCP, y este tipo de ralentización de red se conoce como colapso TCP, que sucede cuando una conexión externa más lenta causa que la capa superior acumule más retransmisiones de las que la capa inferior puede procesar.

6. El “Asesino Silencioso” MTU/MSS

Incluso si tu pérdida de paquetes es cero, aún puedes estar pagando un “impuesto de fragmentación.”

Una trama Ethernet estándar tiene 1500 bytes. SSH y VPNs añaden encabezados (cifrado, encapsulación). Si el paquete resultante tiene 1520 bytes, debe fragmentarse en dos paquetes.

Fragmentación: - Duplica la cantidad de paquetes - Duplica la sobrecarga de interrupciones en la CPU - Si se pierde una fragmento, se descarta todo el paquete original

Para un túnel SSH, debes “limitar” el tamaño máximo de segmento (MSS) para asegurar que los segmentos TCP internos sean lo suficientemente pequeños para caber dentro de la carga útil del túnel sin fragmentación.

Ejemplo: Clamping MSS con IPTables

# Evitar fragmentación limitando MSS a MTU del camino
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

7. La Solución Moderna: Encapsulado Basado en UDP

El consenso en ingeniería es claro: Los túneles deben ser sin estado.

Por qué WireGuard Gana

WireGuard usa UDP. Si un paquete cifrado se pierde, a WireGuard no le importa. No retransmite. No tiene ventana de congestión. Simplemente pasa la responsabilidad de la “fiabilidad” de vuelta al Inner TCP.

Ventajas:

No hay retransmisión doble: Solo una capa (la aplicación) maneja la recuperación.
No hay bloqueo HoL: El paquete #2 puede ser descifrado y entregado incluso si el paquete #1 falta.
Integración en kernel: WireGuard vive en el kernel de Linux (desde la versión 5.6+), evitando la sobrecarga de cambios de contexto que aquejan a los túneles SSH en espacio de usuario.

UDP no retransmite nada por sí mismo, así que en el caso de UDP, solo la conexión TCP interna retransmite paquetes perdidos, evitando que se acumulen y se produzca el problema.

Por qué QUIC (HTTP/3) es el Futuro

QUIC construye esencialmente un “TCP más inteligente” sobre UDP. Soporta Multiplexed Streams sin bloqueo HoL. Si un stream en un túnel QUIC pierde un paquete, otros streams continúan sin afectar.

Avances en rendimiento de QUIC

Despliegues recientes en el mundo real demuestran las ventajas de QUIC:

El documento original de Google que describe los mecanismos básicos de QUIC reportó una reducción promedio del 8% en el tiempo para cargar resultados de búsqueda en Google en escritorio y 3.6% en móvil, con hasta un 16% más rápido en los usuarios más lentos.

Para streaming de video, el impacto es aún más dramático. Al analizar la transmisión de videos en YouTube, investigadores encontraron hasta un 20% menos de interrupciones.

Grandes CDN han validado estos beneficios a escala. Para un cliente grande de medios de Akamai durante un evento de transmisión en vivo de fútbol europeo popular en Latinoamérica, aproximadamente el 69% de las conexiones HTTP/3 alcanzaron un rendimiento de 5 Mbps o más en comparación con solo el 56% de las conexiones HTTP/2.

Velocidad de establecimiento de conexión

Usando QUIC, HTTP/3 puede establecer conexiones hasta un 33% más rápido que HTTP/2 combinando el apretón de manos de transporte y TLS en un solo paso, reduciendo las rondas de ida y vuelta.

Adopción de HTTP/3 en 2024-2025

El protocolo ha pasado de experimental a mainstream. Para 2024-2025, los principales navegadores web — Chrome, Firefox, Safari, Edge — soportan HTTP/3 por defecto, con decenas de por ciento de solicitudes web usando HTTP/3, mostrando crecimiento año tras año.

Grandes empresas de internet lideran la adopción. Google y Meta, por ejemplo, usan intensamente HTTP/3, lo que significa que una gran parte del tráfico actual ya usa HTTP/3.

Rendimiento real de HTTP/3

Benchmarks exhaustivos muestran mejoras consistentes. HTTP/3 fue más rápido que su predecesor en todos los casos probados, gracias a su naturaleza multiplexada, sin bloqueo HoL en toda la pila.

Los usuarios móviles ven beneficios particularmente importantes. Un informe de Akamai en 2025 muestra que HTTP/3 reduce la latencia en un 30% en redes móviles, abordando uno de los entornos más desafiantes para TCP tradicional.

¿Por qué las principales plataformas invierten en la implementación más costosa de QUIC/HTTP/3? Porque QUIC y HTTP/3 son mucho más caros de hospedar, consumiendo más CPU y memoria que TCP y HTTP/2 debido a cifrado más extenso, pero estos costos parecen ser compensados por los beneficios del protocolo.

Por eso herramientas como cloudflared (Túneles de Cloudflare) han migrado a QUIC como su transporte predeterminado.

8. La Lista de Verificación del Ingeniero: Evitando el Impuesto

Si tu túnel se siente lento a pesar de tu conexión de fibra, revisa esta autopsia arquitectónica:

1. Deja de usar VPNs basados en TCP

Cambia a WireGuard o Tailscale. Si debes usar OpenVPN, cambia el transporte de TCP a UDP.

Por qué importa: A pesar de considerarse más confiable, un VPN TCP irónicamente solo funciona de manera confiable cuando la línea es casi perfecta, y aunque no se rompa completamente, eventualmente habrá retransmisiones duplicadas que aumentan la latencia y disminuyen notablemente el rendimiento del VPN.

2. Audita tus túneles SSH

Para desarrollo, ssh -L está bien. Para movimiento de datos en producción, es un cuello de botella. Considera socat sobre UDP o un proxy basado en QUIC.

3. Verifica tu MTU

Usa el siguiente comando para encontrar el paquete más grande que pasa sin fragmentación:

ping -M do -s 1472 <destino>

Si tu túnel está activo, este número será menor (usualmente 1420 o 1380). Ajusta tu configuración de MTU en consecuencia.

4. Verifica “Bufferbloat”

TCP anidado exacerba el bufferbloat. Usa fq_codel o CAKE como disciplina de cola en la interfaz del túnel para mitigar picos de latencia:

# Configura CAKE en la interfaz del túnel
tc qdisc replace dev wg0 root cake bandwidth 100mbit

5. Considera Alternativas Modernas

Para aplicaciones web, aprovecha HTTP/3 cuando sea posible. Para necesidades de túnel personalizadas, evalúa soluciones basadas en QUIC en lugar de confiar en SSH o OpenVPN-TCP.

9. Entendiendo los Intercambios

Cuando todavía se puede usar TCP-over-TCP

A pesar de todas las desventajas, los túneles TCP-over-TCP persisten en escenarios específicos:

Superación de firewalls: Algunas redes corporativas solo permiten conexiones TCP salientes en el puerto 443.
Sistemas legados: Infraestructura existente que no soporta protocolos basados en UDP.
Simplicidad: Los túneles SSH son ubicuos y no requieren software adicional.

Sin embargo, los desarrollos recientes han abordado estas preocupaciones. La recomendación estándar es clara: si tu VPN interno debe ser TCP, ejecútalo sobre un túnel externo basado en UDP para evitar el problema del meltdown.

La Realidad del Rendimiento

Comprender las condiciones específicas donde TCP-over-TCP falla es crucial para el diseño de sistemas:

El túnel TCP es una tecnología que agrega y transfiere paquetes enviados entre hosts finales como una sola conexión TCP, pero dado que la mayoría de las aplicaciones en hosts finales usan TCP, dos controles de congestión TCP operan simultáneamente e interfieren entre sí.

¿El resultado? Un colapso TCP que resulta en una ventana de congestión del TCP externo severamente reducida, un timeout de retransmisión inflado y un búfer de envío completo, indicando que el TCP interno no puede escribir y que los ACKs no se envían en ninguna dirección.

10. Mirando hacia el Futuro: La Internet Post-TCP

El cambio de TCP a protocolos basados en UDP representa una reestructuración fundamental del transporte en internet:

Innovaciones Arquitectónicas de QUIC

QUIC se integra profundamente con el protocolo TLS (Transport Layer Security), y con QUIC, TLS cifra también grandes partes del propio protocolo QUIC, lo que significa que metadatos como números de paquete y señales de cierre de conexión, que en TCP eran visibles para todos los middleboxes, ahora solo están disponibles para el cliente y el servidor en QUIC.

Esta integración proporciona beneficios tanto en seguridad como en rendimiento, reduciendo la latencia en la configuración de la conexión y aumentando la privacidad.

Multiplexación de Streams Bien Hecha

Streams son conocidos en HTTP pero no en TCP, y los cuadros individuales de diferentes streams se numeran y transmiten como segmentos ordenados en TCP, por lo que si un segmento se pierde en tránsito, TCP retransmitirá ese después de un timeout, bloqueando todos los demás segmentos en la conexión.

QUIC resuelve esto haciendo que los streams sean un concepto de primera clase en la capa de transporte, eliminando el bloqueo HoL que afecta a HTTP/2 sobre TCP.

Redes Móviles y Poco Confiables

QUIC puede mantener una conexión a través de cambios de red, a diferencia de TCP que requiere el mismo endpoint (IP y puerto) durante toda la conexión. Esto permite transferencias sin interrupciones cuando los usuarios cambian entre WiFi y datos móviles, un escenario que TCP nunca fue diseñado para manejar.

Conclusión

El Impuesto TCP-sobre-TCP es un conflicto de interés fundamental entre dos capas de fiabilidad. Al intentar ser “demasiado confiable,” el túnel se vuelve inutilizable.

La evidencia es abrumadora: - WireGuard supera consistentemente a VPNs basados en TCP en 2-3 veces - HTTP/3 ofrece mejoras medibles en despliegues reales - Grandes plataformas de internet han adoptado QUIC a pesar de mayores costos de CPU - Los kernels modernos incluyen WireGuard de forma nativa, señalando un consenso en la industria

En el mundo de la ingeniería dura, el camino más rápido suele ser aquel que sabe cuándo dejar ir un paquete. Usa UDP para tus túneles, deja que TCP maneje los datos en la capa de aplicación, y deja de pagar el impuesto.

El futuro del transporte en internet es claro: túneles sin estado con protocolos basados en UDP como WireGuard y QUIC. A medida que las redes se vuelven más rápidas y complejas, las lecciones arquitectónicas del problema TCP-sobre-TCP son aún más relevantes. Elige tus protocolos sabiamente, comprende los intercambios y construye sistemas que trabajen con las realidades de la red, no en su contra.

Recursos Adicionales

Probando tu Propia Configuración

Para evaluar el rendimiento de tu VPN o túnel:

# Probar ancho de banda con iperf3
iperf3 -c <servidor> -t 30 -P 4

# Probar latencia
ping -c 100 <destino>

# Verificar pérdida de paquetes
mtr -c 100 <destino>

Compara los resultados con y sin tu túnel activo para cuantificar el impacto en el rendimiento.