La implementación de proxies de seguridad en entornos Zero Trust a menudo introduce una penalización de rendimiento debido a la sobrecarga de procesamiento y las ineficiencias en la pila de red. El problema fundamental de la computación aquí es cómo interconectar de forma eficiente servicios que operan en diferentes capas del modelo OSI, específicamente la traducción entre la capa de aplicación (L4) y la capa de red (L3) para el transporte. Históricamente, las soluciones de VPN y proxy han dependido de túneles L3 (como IPsec o WireGuard) para encapsular todo el tráfico, requiriendo una conversión explícita del tráfico L4 (TCP/UDP) a paquetes L3.
Esta necesidad de traducción de capa introduce latencia y limita el rendimiento, especialmente cuando se utilizan implementaciones de pila TCP/IP en espacio de usuario no optimizadas para entornos de alto rendimiento. El desafío se agrava en clientes multiplataforma donde el acceso directo al kernel para optimizaciones de red no es viable. La tesis central de este rediseño es que, al alinear el proxy con un protocolo de transporte moderno (QUIC) que soporta multiplexación y flujos a nivel de aplicación, se puede eliminar la traducción de capa ineficiente y aprovechar las características avanzadas de control de congestión y flujo, mejorando drásticamente la experiencia del usuario sin comprometer la seguridad.
Arquitectura del Sistema
La arquitectura original del cliente Cloudflare One en modo proxy utilizaba WireGuard como protocolo de túnel L3. Para manejar el tráfico L4 (SOCKS5 o HTTP) del navegador y encapsularlo en el túnel L3 de WireGuard, el cliente empleaba smoltcp, una implementación de pila TCP en espacio de usuario escrita en Rust. Esto implicaba que el tráfico L4 se descomponía en paquetes L3 mediante smoltcp antes de ser enviado por el túnel WireGuard. En el borde de la red de Cloudflare, se realizaba la operación inversa para reconstruir el flujo L4.
La nueva arquitectura elimina smoltcp y WireGuard para el modo proxy, optando por una encapsulación directa de tráfico L4 sobre QUIC. Específicamente, se utiliza HTTP/3 (RFC 9114) con el método CONNECT sobre QUIC. Cuando el navegador envía una solicitud SOCKS5 o HTTP al cliente, esta se encapsula directamente en un QUIC stream. Este enfoque aprovecha MASQUE (Multiplexed Application Substrate over QUIC), que ya se utilizaba para proxying de paquetes IP, extendiéndolo a flujos L4. La eliminación de la capa de traducción L3 y el uso de QUIC nativo permiten beneficiarse de las características de control de congestión y flujo de QUIC, así como la capacidad de ajustar sus parámetros para optimizar el rendimiento.
Flujo Original (WireGuard + smoltcp)
- 1 Browser/App Envía tráfico L4 (SOCKS5/HTTP) al proxy local.
- 2 Client Proxy Recibe tráfico L4.
- 3 smoltcp Convierte el flujo L4 en paquetes L3.
- 4 WireGuard Tunnel Encapsula y transporta paquetes L3.
- 5 Cloudflare Edge Recibe paquetes L3, los convierte de nuevo a L4.
- 6 Internet/Gateway Tráfico L4 hacia el destino.
Nuevo Flujo (QUIC Directo)
- 1 Browser/App Envía tráfico L4 (SOCKS5/HTTP) al proxy local.
- 2 Client Proxy Recibe tráfico L4.
- 3 QUIC Stream Encapsula directamente el tráfico L4 en un QUIC stream (HTTP/3 CONNECT).
- 4 Cloudflare Edge Recibe QUIC stream, procesa tráfico L4.
- 5 Internet/Gateway Tráfico L4 hacia el destino.
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | WireGuard | Protocolo de túnel L3 utilizado en la arquitectura original para encapsular el tráfico. |
| data-processing | smoltcp | Pila TCP/IP en espacio de usuario (Rust) utilizada para la conversión de L4 a L3 en la arquitectura original. |
| networking | QUIC | Protocolo de transporte moderno que reemplaza a WireGuard y smoltcp para el modo proxy, permitiendo encapsulación directa L4 y control de congestión avanzado. vs TCP, UDP |
| networking | HTTP/3 (RFC 9114) | Utilizado con el método CONNECT sobre QUIC para la encapsulación de tráfico L4. vs HTTP/2, HTTP/1.1 |
| networking | MASQUE | Extensión de QUIC utilizada para proxying de paquetes IP y ahora extendida para flujos L4. |
Trade-offs
Ganancias
- ▲ Download/Upload Speeds
- ▲ Latency
- ▲ Efficiency (L3 translation)
- ▲ Modern TCP features
Costes
warp-cli settings | grep protocolFundamentos Teóricos
El problema de la eficiencia en la traducción de protocolos entre capas no es nuevo y ha sido un tema recurrente en la investigación de redes. La idea de mover funcionalidades de la capa de transporte al espacio de usuario o de optimizar la interacción entre capas se ha explorado en trabajos como 'The End-to-End Arguments in System Design' de Saltzer, Reed y Clark (1984), que sugiere que ciertas funciones son mejor implementadas en las capas más altas de la aplicación, cerca de los puntos finales, para evitar redundancias o ineficiencias. La adopción de QUIC, un protocolo de transporte a nivel de aplicación, para encapsular flujos L4 directamente, es una manifestación moderna de estos principios.
QUIC en sí mismo es el resultado de años de investigación y desarrollo en protocolos de transporte, buscando superar las limitaciones de TCP, especialmente en entornos de alta latencia y pérdida de paquetes. Conceptos como la multiplexación de flujos sobre una única conexión subyacente, el control de congestión avanzado y la renegociación de parámetros de conexión sin interrupción, tienen raíces en trabajos académicos sobre rendimiento de red y diseño de protocolos de transporte. La elección de QUIC para este rediseño se alinea con la búsqueda de un protocolo que ofrezca un mejor rendimiento y flexibilidad que las soluciones L3 tradicionales para casos de uso de proxy a nivel de aplicación.