QUIC

QUIC, pronunciado "quick" como rápido en inglés es la abreviación de Quick UDP Internet Connections o Conexiones UDP rápidas en Internet es un protocolo de red de capa de transporte de uso general diseñado inicialmente por Jim Roskind en Google, implementado e implementado en 2012, anunciado públicamente en 2013 a medida que se ampliaba la experimentación y descrito en una reunión de IETF. QUIC es utilizado por más de la mitad de todas las conexiones desde el navegador web Chrome a los servidores de Google. Microsoft Edge (un derivado del navegador Chromium de código abierto) y Firefox lo admiten. Safari implementa el protocolo, sin embargo, no está habilitado de forma predeterminada.

Aunque su nombre se propuso inicialmente como el acrónimo de "Quick UDP Internet Connections", el uso que hace el IETF de la palabra QUIC no es un acrónimo; es simplemente el nombre del protocolo. QUIC mejora el rendimiento de las aplicaciones web orientadas a la conexión que actualmente usan TCP. Lo hace mediante el establecimiento de una serie de conexiones multiplexadas entre dos puntos finales utilizando el Protocolo de datagramas de usuario (UDP), y está diseñado para dejar obsoleto el TCP en la capa de transporte para muchas aplicaciones, lo que le otorga al protocolo el apodo ocasional "TCP/2".

QUIC funciona de la mano con las conexiones multiplexadas de HTTP/2, lo que permite que múltiples flujos de datos lleguen a todos los puntos finales de forma independiente y, por lo tanto, independientemente de las pérdidas de paquetes que involucran otros flujos. Por el contrario, HTTP/2 alojado en el Protocolo de control de transmisión (TCP) puede sufrir retrasos de bloqueo de cabeza de línea de todos los flujos multiplexados si alguno de los paquetes TCP se retrasa o se pierde.

Los objetivos secundarios de QUIC incluyen la reducción de la latencia de conexión y transporte, y la estimación del ancho de banda en cada dirección para evitar la congestión. También mueve los algoritmos de control de congestión al espacio del usuario en ambos puntos finales, en lugar del espacio del kernel, que se afirma permitirá que estos algoritmos mejoren más rápidamente. Además, el protocolo se puede ampliar con la corrección de errores de reenvío (FEC) para mejorar aún más el rendimiento cuando se esperan errores, y esto se considera el siguiente paso en la evolución del protocolo.

En junio de 2015, se envió al IETF un borrador de Internet de una especificación para QUIC para su estandarización. Se estableció un grupo de trabajo QUIC en 2016. En octubre de 2018, los grupos de trabajo HTTP y QUIC del IETF decidieron conjuntamente llamar al mapeo HTTP sobre QUIC "HTTP/3" antes de convertirlo en un estándar mundial. En mayo de 2021, el IETF estandarizó QUIC en RFC 9000, respaldado por RFC 8999, RFC 9001 y RFC 9002.

Fondo

El Protocolo de control de transmisión, o TCP, tiene como objetivo proporcionar una interfaz para enviar flujos de datos entre dos puntos finales. Los datos se entregan al sistema TCP, que garantiza que lleguen al otro extremo exactamente de la misma forma, o la conexión indicará que existe una condición de error.

Para hacer esto, TCP divide los datos en paquetes de red y agrega pequeñas cantidades de datos a cada paquete. Estos datos adicionales incluyen un número de secuencia que se usa para detectar paquetes que se pierden o llegan desordenados, y una suma de verificación que permite detectar los errores dentro de los datos del paquete. Cuando ocurre cualquiera de los problemas, TCP utiliza la solicitud de repetición automática (ARQ) para indicarle al remitente que vuelva a enviar el paquete perdido o dañado.

En la mayoría de las implementaciones, TCP verá cualquier error en una conexión como una operación de bloqueo, deteniendo más transferencias hasta que se resuelva el error o se considere que la conexión falló. Si se utiliza una sola conexión para enviar múltiples flujos de datos, como es el caso del protocolo HTTP/2, todos estos flujos se bloquean, aunque solo uno de ellos puede tener un problema. Por ejemplo, si ocurre un solo error al descargar una imagen GIF utilizada para un favicon, el resto de la página esperará mientras se resuelve el problema. Este fenómeno se conoce como bloqueo de cabeza de línea.

Como el sistema TCP está diseñado para parecerse a una "tubería de datos" o flujo, contiene deliberadamente poca comprensión de los datos que transmite. Si esos datos tienen requisitos adicionales, como el cifrado mediante TLS, esto debe configurarse mediante sistemas que se ejecuten sobre TCP, utilizando TCP para comunicarse con un software similar en el otro extremo de la conexión. Cada uno de estos tipos de tareas de configuración requiere su propio proceso de reconocimiento. Esto a menudo requiere varios viajes de ida y vuelta de solicitudes y respuestas hasta que se establece la conexión. Debido a la latencia inherente de las comunicaciones de larga distancia, esto puede agregar una sobrecarga significativa a la transmisión general.

Características

QUIC pretende ser casi equivalente a una conexión TCP pero con una latencia muy reducida. Lo hace principalmente a través de dos cambios que se basan en la comprensión del comportamiento del tráfico HTTP.

El primer cambio es reducir en gran medida la sobrecarga durante la configuración de la conexión. Como la mayoría de las conexiones HTTP requerirán TLS, QUIC hace que el intercambio de claves de configuración y protocolos admitidos sea parte del proceso de negociación inicial. Cuando un cliente abre una conexión, el paquete de respuesta incluye los datos necesarios para que los paquetes futuros utilicen el cifrado. Esto elimina la necesidad de configurar la conexión TCP y luego negociar el protocolo de seguridad a través de paquetes adicionales. Se pueden atender otros protocolos de la misma manera, combinando varios pasos en una sola solicitud-respuesta. Estos datos se pueden usar tanto para las siguientes solicitudes en la configuración inicial como para futuras solicitudes que, de lo contrario, se negociarían como conexiones separadas.

El segundo cambio es utilizar UDP en lugar de TCP como base, lo que no incluye la recuperación de pérdidas. En cambio, cada flujo QUIC tiene un flujo controlado por separado y los datos perdidos se retransmiten al nivel de QUIC, no UDP. Esto significa que si se produce un error en una transmisión, como en el ejemplo de favicon anterior, la pila de protocolos puede continuar prestando servicios a otras transmisiones de forma independiente. Esto puede ser muy útil para mejorar el rendimiento en enlaces propensos a errores, ya que en la mayoría de los casos se pueden recibir datos adicionales considerables antes de que TCP detecte que falta un paquete o está roto, y todos estos datos se bloquean o incluso se eliminan mientras se corrige el error. En QUIC, estos datos se pueden procesar libremente mientras se repara el único flujo multiplexado.

QUIC also includes a number of other more mundane changes that also improve overall latency and throughput. For instance, the packets are encrypted individually, so that they do not result in the encrypted data waiting for partial packets. This is not generally possible under TCP, where the encryption records are in a bytestream and the protocol stack is unaware of higher-layer boundaries within this stream. These can be negotiated by the layers running on top, but QUIC aims to do all of this in a single handshake process.

Otro objetivo del sistema QUIC era mejorar el rendimiento durante los eventos de cambio de red, como lo que sucede cuando un usuario de un dispositivo móvil pasa de un punto de acceso WiFi local a una red móvil. Cuando esto ocurre en TCP, comienza un largo proceso en el que cada conexión existente se agota una por una y luego se restablece a pedido. Para resolver este problema, QUIC incluye un identificador de conexión que identifica de forma única la conexión con el servidor, independientemente de la fuente. Esto permite restablecer la conexión simplemente enviando un paquete, que siempre contiene esta ID, ya que la ID de conexión original seguirá siendo válida incluso si la dirección IP del usuario cambia.

QUIC se puede implementar en el espacio de la aplicación, en lugar de estar en el kernel del sistema operativo. Esto generalmente genera una sobrecarga adicional debido a los cambios de contexto a medida que los datos se mueven entre aplicaciones. Sin embargo, en el caso de QUIC, la pila de protocolos está diseñada para ser utilizada por una sola aplicación, y cada aplicación que utiliza QUIC tiene sus propias conexiones alojadas en UDP. En última instancia, la diferencia podría ser muy pequeña porque gran parte de la pila HTTP/2 general ya se encuentra en las aplicaciones (o en sus bibliotecas, más comúnmente). Colocar las partes restantes en esas bibliotecas, esencialmente la corrección de errores, tiene poco efecto en el tamaño o la complejidad general de la pila HTTP/2.

Esta organización permite realizar cambios futuros más fácilmente ya que no requiere cambios en el núcleo para las actualizaciones. Uno de los objetivos a largo plazo de QUIC es agregar nuevos sistemas para la corrección de errores de reenvío (FEC) y mejorar el control de la congestión.

Una preocupación sobre el cambio de TCP a UDP es que TCP se adopta ampliamente y muchas de las "cajas intermedias" en la infraestructura de Internet están ajustadas para TCP y límite de velocidad o incluso bloquean UDP. Google llevó a cabo una serie de experimentos exploratorios para caracterizar esto y descubrió que solo se bloqueaba una pequeña cantidad de conexiones de esta manera. Esto condujo al uso de un sistema de respaldo rápido a TCP; La pila de red de Chromium abre una conexión QUIC y TCP tradicional al mismo tiempo, lo que le permite retroceder con una latencia insignificante.

Google QUIC (gQUIC)

El protocolo que fue creado por Google y llevado al IETF con el nombre QUIC (ya en 2012 alrededor de la versión 20 de QUIC) es bastante diferente del QUIC que ha seguido evolucionando y perfeccionándose dentro del IETF. El QUIC de Google original fue diseñado para ser un protocolo de propósito general, aunque inicialmente se implementó como un protocolo para admitir HTTP(S) en Chromium. La evolución actual del protocolo QUIC de IETF es un protocolo de transporte de propósito general. Los desarrolladores de Chromium continuaron rastreando la evolución de los esfuerzos de estandarización de IETF QUIC para adoptar y cumplir plenamente con los estándares de Internet más recientes para QUIC en Chromium.

Adopción

Compatibilidad con navegador

El código QUIC se desarrolló experimentalmente en Google Chrome a partir de 2012 y se anunció como parte de la versión 29 de Chromium (lanzada el 20 de agosto de 2013). Actualmente está habilitado de forma predeterminada en Chromium y Chrome.

El soporte en Firefox llegó en mayo de 2021.

Apple agregó soporte experimental en el motor WebKit a través de Safari Technology Preview 104 en abril de 2020. Se agregó soporte oficial en Safari 14, incluido en macOS Big Sur e iOS 14, pero la función debe activarse manualmente.

Atención al cliente

La biblioteca de cronet para QUIC y otros protocolos está disponible para las aplicaciones de Android como un módulo que se puede cargar a través de Google Play Services.

cURL 7.66, lanzado el 11 de septiembre de 2019, admite HTTP/3 (y, por lo tanto, QUIC).

En octubre de 2020, Facebook anunció que había migrado con éxito sus aplicaciones, incluido Instagram, y la infraestructura del servidor a QUIC, con un 75 % de su tráfico de Internet usando QUIC. Todas las aplicaciones móviles de Google admiten QUIC, incluidas YouTube y Gmail. La aplicación móvil de Uber también usa QUIC.

Soporte del servidor

A partir de 2017, hay varias implementaciones mantenidas activamente. Los servidores de Google admiten QUIC y Google ha publicado un servidor prototipo. Akamai Technologies es compatible con QUIC desde julio de 2016. También está disponible una implementación de Go llamada quic-go, que potencia la compatibilidad con QUIC experimental en el servidor Caddy. El 11 de julio de 2017, LiteSpeed ​​Technologies comenzó oficialmente a admitir QUIC en sus productos de equilibrador de carga (WebADC) y servidor web LiteSpeed. En octubre de 2019, el 88,6 % de los sitios web de QUIC usaba LiteSpeed ​​y el 10,8 % usaba Nginx. Aunque al principio solo los servidores de Google admitían conexiones HTTP sobre QUIC, Facebook también lanzó la tecnología en 2018.y Cloudflare ha estado ofreciendo compatibilidad con QUIC en versión beta desde 2018. A partir de marzo de 2021, el 5,0 % de todos los sitios web usan QUIC. Microsoft Windows Server 2022 admite HTTP/3 y SMB sobre protocolos QUIC a través de MsQuic. El Application Delivery Controller de Citrix (Citrix ADC, NetScaler) puede funcionar como proxy QUIC desde la versión 13.

Además, hay varios proyectos comunitarios obsoletos: libquic se creó extrayendo la implementación de Chromium de QUIC y modificándola para minimizar los requisitos de dependencia, y goquic proporciona enlaces Go de libquic. Finalmente, quic-reverse-proxy es una imagen de Docker que actúa como un servidor proxy inverso, traduciendo las solicitudes QUIC en HTTP simple que puede entender el servidor de origen.

.NET 5 presenta soporte experimental para QUIC usando la biblioteca MsQuic.

Código fuente