QUIC para el kernel de Linux

(lwn.net)

12 puntos por GN⁺ 2025-08-02 | Aún no hay comentarios. | Compartir por WhatsApp

Se envió el primer parche para integrar oficialmente el protocolo QUIC en el kernel de Linux
El objetivo es mejorar las limitaciones de TCP (latencia, head-of-line blocking, osificación del protocolo por dispositivos intermedios, etc.)
QUIC se basa en UDP, ofrece soporte de multistream y cifrado de extremo a extremo, y su adopción en el kernel podría ampliar las posibilidades de uso en más plataformas y hardware
Aunque el rendimiento de la implementación inicial en el kernel se midió por debajo de TCP y de kernel TLS, se espera que mejore con offloading de hardware y optimizaciones futuras
Actualmente hay un intenso debate sobre su soporte en Samba, SMB/NFS basado en kernel, curl y otros, aunque todavía se prevé que falte tiempo para su integración en mainline

Contexto de la aparición de QUIC y limitaciones de TCP

QUIC fue creado con el objetivo de resolver varios problemas que TCP presenta en Internet
La experiencia web se degrada por la latencia causada por el 3-way handshake del proceso de conexión de TCP, la falta de soporte sólido para multistream y el fenómeno de head-of-line blocking ante pérdida de paquetes
Los metadatos de TCP se transmiten sin cifrar, lo que implica riesgo de filtración de información, y las middleboxes (dispositivos intermedios) filtran el tráfico según la información de la conexión, lo que termina derivando en osificación del protocolo (ossification)
Incluso los intentos de mejorar TCP, como Multipath TCP, no pueden funcionar con normalidad si no se hacen pasar por TCP tradicional

QUIC funciona sobre UDP y puede establecer conexiones rápidamente sin un 3-way handshake separado durante el proceso de conexión
Su diseño de transmisión multistream evita que la pérdida de paquetes afecte a todo el flujo
Los datos de transporte relacionados con QUIC siempre van con cifrado de extremo a extremo (basado en TLS), por lo que los dispositivos intermedios no pueden acceder a los mensajes internos
Si el entorno de red permite el paso de paquetes UDP, QUIC también puede funcionar con normalidad

El parche presentado introduce un nuevo tipo de protocolo llamado IPPROTO_QUIC, lo que permite aprovechar la llamada al sistema socket() existente
Igual que con TCP, se pueden usar llamadas como bind(), connect(), listen() y accept(), aunque el procesamiento posterior tiene diferencias
La gestión de sesiones TLS y el proceso de autenticación/cifrado se manejan en espacio de usuario, y tras establecer la conexión cada extremo debe completar el TLS handshake antes de poder enviar y recibir datos
Después de la conexión inicial, los resultados de la negociación TLS pueden almacenarse en caché, lo que permite acelerar considerablemente la reconexión entre dos sistemas

La implementación de QUIC dentro del kernel presentada todavía muestra desventaja en rendimiento frente a kernel TLS y TCP
- Menos de un tercio del throughput frente a TLS en kernel, y hasta 4 veces menos throughput que TCP incluso con el cifrado desactivado
Entre las causas señaladas están la falta de soporte para segmentation offloading, copias adicionales de datos en la ruta de envío y el proceso de cifrado de encabezados
Se espera que el rendimiento mejore cuando se agregue soporte para offloading de hardware y se optimice la implementación dentro del kernel

En varios proyectos como el servidor/cliente de Samba, los sistemas de archivos SMB y NFS del kernel, y curl, hay un debate activo sobre el soporte de QUIC dentro del kernel
El parche tiene unas 9,000 líneas y por ahora solo incluye código de soporte de bajo nivel. La implementación completa está prevista en parches adicionales
La revisión del código y el debate sobre su integración apenas están comenzando, por lo que todavía se espera que falte tiempo para su uso real
- Considerando el precedente reciente del protocolo Homa, cuya integración al kernel requirió 11 envíos durante 9 meses, se estima que QUIC también podría entrar en mainline después de 2026