Cloudflare tiene tokio-quiche de código abierto, una biblioteca asincrónica de QUIC y HTTP/3 Rust que integra su implementación de quiche probada en batalla con el tiempo de ejecución de Tokio. La biblioteca se ha perfeccionado dentro de sistemas de producción como Apple iCloud Private Relay, proxies basados en Oxy de próxima generación y el cliente MASQUE de WARP, donde maneja millones de solicitudes HTTP/3 por segundo con baja latencia y alto rendimiento. tokio-quiche se dirige a los equipos de Rust que desean QUIC y HTTP/3 sin escribir su propio UDP y código de integración de bucle de eventos.
De quiche a tokio-quiche
quiche es la implementación QUIC y HTTP/3 de código abierto de Cloudflare escrita en Rust y diseñada como una biblioteca sans-io de bajo nivel. Implementa la máquina de estado de transporte QUIC, incluido el establecimiento de conexión, el control de flujo y la multiplexación de flujo, sin hacer suposiciones sobre cómo las aplicaciones realizan IO. Para utilizar quiche directamente, los integradores deben abrir sockets UDP, enviar y recibir datagramas, administrar temporizadores e introducir todos los paquetes de datos en quiche en el orden correcto. Este diseño brinda flexibilidad, pero hace que la integración sea propensa a errores y requiera mucho tiempo.
tokio-quiche empaqueta este trabajo de integración en una caja reutilizable. Combina la implementación sans-io QUIC o HTTP/3 de quiche con el tiempo de ejecución asíncrono de Tokio y expone una API que ya administra sockets UDP, enrutamiento de paquetes y llamadas a la máquina de estado quiche.
Arquitectura basada en actores en Tokio
Internamente, tokio-quiche utiliza un modelo de actor además de Tokio. Los actores son pequeñas tareas con el estado local que se comunican a través de mensajes que pasan a través de canales, lo que se alinea bien con las implementaciones del protocolo sans-io que poseen el estado interno y operan con mensajes como buffers.
El actor principal es el actor del bucle IO, que mueve paquetes entre quiche y el socket UDP. Uno de los tipos de mensajes clave es una estructura entrante que describe los paquetes UDP recibidos. La integración asíncrona sigue un patrón fijo, el bucle IO espera nuevos mensajes, los traduce en entradas para quiche, hace avanzar la máquina de estado QUIC y luego traduce las salidas en paquetes salientes que se vuelven a escribir en el socket.
Para cada socket UDP, tokio-quiche genera dos tareas importantes. InboundPacketRouter posee la mitad receptora del socket y enruta los datagramas entrantes por ID de conexión de destino a cada canal de conexión. IoWorker es el bucle IO por conexión y controla una única conexión quiche, intercalando llamadas a quiche con llamadas a la lógica específica de la aplicación implementada a través de ApplicationOverQuic. Este diseño encapsula el estado de la conexión dentro de cada actor y mantiene el procesamiento QUIC aislado del código de protocolo de nivel superior.
AplicaciónOverQuic y H3Driver
QUIC es un protocolo de transporte y puede transportar múltiples protocolos de aplicación. HTTP/3, DNS sobre QUIC y Medios sobre QUIC son ejemplos cubiertos por las especificaciones del IETF. Para evitar acoplar tokio-quiche a un único protocolo, el equipo de Cloudflare expone un rasgo ApplicationOverQuic. El rasgo abstrae los métodos quiche y el IO subyacente, y presenta eventos de nivel superior y enlaces a la aplicación que implementa el protocolo. Por ejemplo, el cliente de prueba y depuración HTTP/3 h3i utiliza una implementación no HTTP/3 de ApplicationOverQuic.
Además de esta característica, tokio-quiche incluye una implementación dedicada centrada en HTTP/3 llamada H3Driver. H3Driver conecta el módulo HTTP/3 de quiche al actor de bucle IO y convierte eventos HTTP/3 sin procesar en eventos de nivel superior con flujos de cuerpo asincrónicos que son convenientes para el código de la aplicación. H3Driver es genérico y expone variantes de ServerH3Driver y ClientH3Driver que agregan comportamiento del lado del servidor y del lado del cliente además del controlador principal. Estos componentes proporcionan los componentes básicos para servidores y clientes HTTP/3 que comparten patrones de implementación con la infraestructura interna de Cloudflare.
Uso de producción y hoja de ruta
tokio-quiche se ha utilizado durante varios años dentro de Cloudflare antes de su lanzamiento público. Alimenta el Proxy B en Apple iCloud Private Relay, servidores HTTP/3 basados en Oxy y el cliente WARP MASQUE, así como la versión asíncrona de h3i. En el cliente WARP, los túneles basados en MASQUE creados en tokio-quiche reemplazan los túneles anteriores basados en WireGuard con túneles basados en QUIC. Estos sistemas se ejecutan a escala de borde de Cloudflare y demuestran que la integración puede soportar millones de solicitudes HTTP/3 por segundo en producción.
Cloudflare posiciona a tokio-quiche como una base en lugar de un marco HTTP/3 completo. La biblioteca expone capacidades de protocolo de bajo nivel y ejemplos de bucles de eventos de clientes y servidores, y deja espacio para que proyectos de nivel superior implementen servidores HTTP obstinados, clientes DNS sobre QUIC, VPN basadas en MASQUE y otras aplicaciones QUIC además. Al lanzar la caja, Cloudflare pretende reducir la barrera para que los equipos de Rust adopten QUIC, HTTP/3 y MASQUE, y alinear las integraciones externas con la misma pila de transporte utilizada en sus servicios de borde.
Conclusiones clave
tokio-quiche = quiche + Tokio: tokio-quiche es una biblioteca asíncrona de Rust que integra la implementación sans-io QUIC y HTTP/3 de Cloudflare, quiche, con el tiempo de ejecución de Tokio, por lo que los desarrolladores no necesitan escribir manualmente UDP ni fontanería de bucle de eventos. Arquitectura basada en actores para conexiones QUIC: la biblioteca utiliza un modelo de actor en Tokio, con un InboundPacketRouter que enruta datagramas UDP por ID de conexión y un IoWorker que impulsa una única conexión quiche por tarea, manteniendo el estado de transporte aislado y componible. Abstracción de ApplicationOverQuic: la lógica del protocolo se separa mediante el rasgo ApplicationOverQuic, que abstrae los detalles de quiche y IO para que se puedan implementar diferentes protocolos basados en QUIC, como HTTP/3, DNS sobre QUIC o protocolos personalizados, sobre el mismo núcleo de transporte. HTTP/3 a través de H3Driver, ServerH3Driver y ClientH3Driver: tokio-quiche envía H3Driver más las variantes ServerH3Driver y ClientH3Driver que unen el módulo HTTP/3 de quiche con el código Rust asíncrono, exponiendo flujos y cuerpos HTTP/3 de una manera que se adapta a los servicios típicos basados en Tokio.
Consulta los detalles técnicos. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 100.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
Michal Sutter es un profesional de la ciencia de datos con una Maestría en Ciencias de Datos de la Universidad de Padua. Con una base sólida en análisis estadístico, aprendizaje automático e ingeniería de datos, Michal se destaca en transformar conjuntos de datos complejos en conocimientos prácticos.