La evolución de las plataformas serverless en el edge, como Cloudflare Workers, hacia el soporte de protocolos de red genéricos más allá de HTTP, aborda una limitación fundamental en la computación distribuida: la necesidad de comunicación full-duplex y de baja latencia para aplicaciones en tiempo real y machine-to-machine. Históricamente, las funciones serverless se han centrado en el modelo request/response de HTTP, limitando su aplicabilidad a casos de uso que requieren conexiones persistentes o protocolos binarios.
La introducción de un handler connect(socket) permite a los Workers procesar conexiones TCP crudas, transformando el edge de una simple pasarela HTTP a un punto de terminación y enrutamiento para cualquier protocolo basado en TCP. Esto es crucial para cargas de trabajo como brokers de mensajes, proxies de bases de datos, y sistemas de IA conversacional que demandan latencia mínima y flujos de datos bidireccionales, redefiniendo el alcance de lo que es posible construir directamente en el edge de la red.
Arquitectura del Sistema
La nueva funcionalidad se articula en tres componentes principales: el handler connect(socket), el enrutamiento a través de Spectrum, y la integración con Durable Objects y contenedores. Cuando una conexión TCP entrante llega a Cloudflare, Spectrum (el proxy de ingreso para tráfico no HTTP) la dirige a un Worker. El Worker expone un handler connect(socket) que recibe el socket TCP crudo.
Desde el Worker, el socket puede ser manipulado directamente (lectura/escritura), pasado a otro Worker, o, de manera más significativa, transferido a un Durable Object. Los Durable Objects, que proporcionan estado persistente y coordenadas de consistencia, pueden a su vez pasar el socket a un contenedor (a través de getTcpPort()). Este último paso es donde se habilita la comunicación full-duplex con programas arbitrarios en cualquier lenguaje, ejecutándose en contenedores. Para gRPC, los Workers soportan gRPC unary y server-streaming mediante una traducción interna de gRPC a gRPC-web y viceversa, debido a las limitaciones de las APIs web subyacentes que no exponen el control a nivel de stream de HTTP/2. Los Durable Objects y contenedores, sin embargo, pueden manejar gRPC bidireccional de forma nativa.
Flujo de Conexión TCP Entrante
- 1 Cliente Inicia conexión TCP
- 2 Cloudflare Edge Recibe conexión, Spectrum la enruta
- 3 Worker Handler `connect(socket)` acepta el socket
- 4 Worker Procesa socket directamente o lo transfiere
- 5 Durable Object Recibe socket del Worker, mantiene estado
- 6 Durable Object Pasa socket a contenedor vía `getTcpPort()`
- 7 Contenedor Aplicación nativa maneja comunicación full-duplex
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | Cloudflare Spectrum | Proxy de ingreso para tráfico no HTTP, enruta conexiones TCP entrantes a Workers. |
| compute | Cloudflare Workers | Plataforma serverless en el edge que ahora puede aceptar y procesar conexiones TCP crudas, actuando como un punto de terminación y enrutamiento programable. Handler `connect(socket)` |
| compute | Cloudflare Durable Objects | Entidades con estado que pueden recibir sockets de Workers y pasarlos a contenedores, permitiendo la persistencia de la conexión y la coordinación distribuida. `getTcpPort()` para transferir sockets a contenedores. |
| networking | gRPC | Protocolo RPC de alto rendimiento utilizado para comunicación machine-to-machine. Soportado en Workers (unary/server-streaming vía traducción) y nativamente en Durable Objects/Contenedores (full-duplex). vs Cap'n Proto, Cap'n Web |
| networking | gRPC-web | Versión de gRPC adaptada para entornos web (navegadores, Workers) que no exponen las APIs de control de stream de HTTP/2. Utilizado por Cloudflare para la traducción interna. |
Trade-offs
Ganancias
- ▲ Flexibilidad de protocolo en el edge
- ▲ Reducción de latencia para aplicaciones TCP/gRPC
- ▲▲ Habilitación de nuevos casos de uso (brokers, proxies DB, IA conversacional)
Costes
- △ Soporte gRPC bidireccional limitado en Workers (requiere Durable Objects/Contenedores)
- △ Complejidad de la implementación (traducción gRPC-web)
- △ Maturidad (beta privada)
export default {
async connect(socket): Promise<void> {
const writer = socket.writable.getWriter();
await writer.write(new TextEncoder().encode("Hello, world!\n"));
await writer.close();
},
} satisfies ExportedHandler;Fundamentos Teóricos
Este desarrollo se alinea con los principios de las redes programables y la computación en el edge, donde la lógica de aplicación se acerca al origen de los datos para reducir la latencia y mejorar la eficiencia. Conceptos como los "Active Networks" de la década de 1990, propuestos por autores como David L. Tennenhouse et al. (1997), exploraron la idea de inyectar lógica de procesamiento en los nodos de la red. Aunque la implementación moderna difiere, la filosofía de mover la inteligencia de la aplicación a la infraestructura de red para tomar decisiones de enrutamiento y procesamiento en tiempo real es análoga.
La dependencia de gRPC en HTTP/2 y sus streams subraya la importancia de los protocolos de transporte eficientes, un área de investigación continua desde los primeros trabajos sobre TCP y UDP. La necesidad de gRPC-web para superar las limitaciones de las APIs de navegador y edge-runtime refleja los desafíos de adaptar protocolos de alto rendimiento a entornos con abstracciones de red restrictivas, un problema que ha sido abordado en la literatura académica sobre proxies de aplicación y pasarelas de protocolo.