QUIC ( / k w ɪ k / ) es un protocolo de red de capa de transporte [1] de propósito general [2] diseñado inicialmente por Jim Roskind en Google , [3] implementado e implementado en 2012, [4] anunciado públicamente en 2013 como experimentación ampliada, [5] [6] [7] y descrita en una reunión del IETF . [8] QUIC es utilizado por más de la mitad de todas las conexiones desde el navegador web Chrome a los servidores de Google. [9] Microsoft Edge (que, después de la versión 1, es un derivado del navegador Chromium de código abierto), [10] [11] Firefox , [12] y Safari lo admiten. [13]
Aunque su nombre se propuso inicialmente como el acrónimo de "Quick UDP Internet Connections", [3] [8] el uso que hace el IETF de la palabra QUIC no es un acrónimo; es simplemente el nombre del protocolo. [1] QUIC mejora el rendimiento de las aplicaciones web orientadas a la conexión que actualmente utilizan TCP . [2] [9] Para ello, establece una serie de conexiones multiplexadas entre dos puntos finales mediante el protocolo de datagramas de usuario (UDP) y está diseñado para dejar obsoleto TCP en la capa de transporte para muchas aplicaciones, lo que le otorga al protocolo el apodo ocasional de "TCP". /2". [14]
QUIC trabaja mano a mano con las conexiones multiplexadas de HTTP/3 , lo que permite que múltiples flujos de datos lleguen a todos los puntos finales de forma independiente y, por lo tanto, independiente 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 en el bloqueo del encabezado 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 , lo que, según se afirma, permitirá que estos algoritmos mejoren más rápidamente. Además, el protocolo se puede ampliar con corrección de errores directa (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. Ha sido diseñado para evitar la osificación del protocolo para que siga siendo evolucionable, a diferencia de TCP, que ha sufrido una osificación significativa.
En junio de 2015, se envió al IETF un borrador de Internet de una especificación para QUIC para su estandarización. [15] [16] Se estableció un grupo de trabajo QUIC en 2016. [17] 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 grupo de trabajo mundial. estándar. [18] En mayo de 2021, el IETF estandarizó QUIC en RFC 9000, respaldado por RFC 8999, RFC 9001 y RFC 9002. [19] DNS-over-QUIC es otra aplicación.
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, lo que garantiza que lleguen al otro extremo exactamente de la misma forma, o la conexión indicará que existe una condición de error. [20]
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 utiliza 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. [20]
En la mayoría de las implementaciones, TCP verá cualquier error en una conexión como una operación de bloqueo, deteniendo futuras transferencias hasta que se resuelva el error o se considere que la conexión falló. Si se utiliza una única 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 podría tener un problema. Por ejemplo, si se produce un solo error al descargar una imagen GIF utilizada para un favicon , el resto de la página esperará hasta que se resuelva el problema. [20] Este fenómeno se conoce como bloqueo de cabecera de línea .
Como el sistema TCP está diseñado para parecerse a un "canal de datos" o flujo, deliberadamente contiene poca comprensión de los datos que transmite. Si esos datos tienen requisitos adicionales, como cifrado mediante TLS , esto debe configurarse mediante sistemas que se ejecuten sobre TCP, utilizando TCP para comunicarse con 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 protocolo de enlace . 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. [20]
TCP ha sufrido una osificación del protocolo , [21] debido a que su imagen de cable está en texto claro y, por lo tanto, es visible y maleable por los middleboxes . [22] Una medición encontró que un tercio de las rutas a través de Internet encuentran al menos un intermediario que modifica los metadatos TCP, y el 6,5% de las rutas encuentran efectos osificantes dañinos de los intermediarios. [23] Las extensiones de TCP se han visto afectadas: el diseño de Multipath TCP (MPTCP) se vio limitado por el comportamiento del middlebox, [24] [25] y la implementación de TCP Fast Open también se vio obstaculizada. [26] [21]
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 dependen de la comprensión del comportamiento del tráfico HTTP . [20]
El primer cambio es reducir en gran medida los gastos generales durante la configuración de la conexión. Como la mayoría de las conexiones HTTP exigirán TLS , QUIC hace que el intercambio de claves de configuración y protocolos admitidos forme parte del proceso de intercambio inicial . Cuando un cliente abre una conexión, el paquete de respuesta incluye los datos necesarios para que futuros paquetes utilicen cifrado. Esto elimina la necesidad de configurar la conexión TCP y luego negociar el protocolo de seguridad mediante paquetes adicionales. Se pueden atender otros protocolos de la misma manera, combinando múltiples pasos en un único par de solicitud-respuesta. Estos datos se pueden utilizar tanto para las siguientes solicitudes en la configuración inicial como para solicitudes futuras que de otro modo se negociarían como conexiones separadas. [20]
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 se controla por separado y los datos perdidos se retransmiten al nivel de QUIC, no a nivel UDP. Esto significa que si se produce un error en una secuencia, como en el ejemplo de favicon anterior, la pila de protocolos puede continuar brindando servicio a otras secuencias 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 note 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 flujo multiplexado único. [27]
QUIC incluye una serie de otros cambios que mejoran la latencia y el rendimiento generales. Por ejemplo, los paquetes se cifran individualmente, de modo que no den como resultado que los datos cifrados esperen paquetes parciales. Por lo general, esto no es posible en TCP, donde los registros de cifrado están en un flujo de bytes y la pila de protocolos desconoce los límites de las capas superiores dentro de este flujo. Estos pueden ser negociados por las capas que se ejecutan en la parte superior, pero QUIC pretende hacer todo esto en un único proceso de protocolo de enlace. [8]
Otro objetivo del sistema QUIC era mejorar el rendimiento durante 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 proceso largo en el que cada conexión existente caduca una por una y luego se restablece según demanda. Para resolver este problema, QUIC incluye un identificador de conexión para identificar de forma única la conexión al 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 la conexión original seguirá siendo válida incluso si la dirección IP del usuario cambia. [28]
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á destinada a ser utilizada por una única 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 está 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 de la pila HTTP/2 o en la complejidad general. [8]
Esta organización permite realizar cambios futuros más fácilmente ya que no requiere cambios en el kernel para las actualizaciones. Uno de los objetivos a largo plazo de QUIC es agregar nuevos sistemas para la corrección de errores directos (FEC) y un mejor control de la congestión. [28]
Una preocupación sobre el paso de TCP a UDP es que TCP se adopta ampliamente y muchas de las "cajas intermedias" en la infraestructura de Internet están sintonizadas para TCP y limitan la velocidad o incluso bloquean UDP. Google llevó a cabo una serie de experimentos para caracterizar esto y descubrió que sólo un pequeño número de conexiones estaban bloqueadas de esta manera. [3] Esto llevó 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. [29]
QUIC ha sido diseñado específicamente para ser desplegable, evolucionable y tener propiedades antiosificación; [30] es el primer protocolo de transporte del IETF que minimiza deliberadamente su imagen de cable para estos fines. [31] Más allá de los encabezados cifrados, está "engrasado" [32] y tiene invariantes de protocolo especificadas explícitamente. [33]
El protocolo que fue creado por Google y llevado al IETF con el nombre de 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 IETF QUIC es un protocolo de transporte de propósito general. Los desarrolladores de Chromium continuaron siguiendo 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.
QUIC se desarrolló teniendo en cuenta HTTP y HTTP/3 fue su primera aplicación. [34] [35] DNS-over-QUIC es una aplicación de QUIC para la resolución de nombres, que proporciona seguridad para los datos transferidos entre resolutores similar a DNS-over-TLS . [36] El IETF también está desarrollando una aplicación de QUIC para crear un protocolo de túnel seguro . [35] XMPP se ha adaptado experimentalmente para utilizar QUIC. [37] Otra aplicación es SMB sobre QUIC, que, según Microsoft, puede ofrecer una "VPN SMB" sin afectar la experiencia del usuario. [38] Los clientes SMB utilizan TCP de forma predeterminada e intentarán QUIC si el intento de TCP falla o si requieren QUIC intencionalmente.
El código QUIC se desarrolló experimentalmente en Google Chrome a partir de 2012, [4] y se anunció como parte de la versión 29 de Chromium (lanzada el 20 de agosto de 2013). [18] Actualmente está habilitado de forma predeterminada en Chromium y Chrome. [39]
El soporte en Firefox llegó en mayo de 2021. [40] [12]
Apple agregó soporte experimental en el motor WebKit a través de Safari Technology Preview 104 en abril de 2020. [41] Se agregó soporte oficial en Safari 14, incluido en macOS Big Sur e iOS 14 , [42] pero la función debía activarse manualmente . [43] Posteriormente se habilitó de forma predeterminada en Safari 16. [13]
La biblioteca cronet para QUIC y otros protocolos está disponible para aplicaciones de Android como un módulo cargable a través de Google Play Services . [44]
cURL 7.66, lanzado el 11 de septiembre de 2019, admite HTTP/3 (y, por tanto, QUIC). [45] [46]
En octubre de 2020, Facebook anunció [47] que había migrado con éxito sus aplicaciones, incluido Instagram , y su infraestructura de servidor a QUIC, y que ya el 75% de su tráfico de Internet utiliza QUIC. Todas las aplicaciones móviles de Google son compatibles con QUIC, incluidas YouTube y Gmail . [48] [49] La aplicación móvil de Uber también utiliza QUIC. [49]
A partir de 2017 [update], existen varias implementaciones mantenidas activamente. Los servidores de Google admiten QUIC y Google ha publicado un servidor prototipo. [50] Akamai Technologies ha estado respaldando QUIC desde julio de 2016. [51] [52] También está disponible una implementación de Go llamada quic-go [53] que impulsa el soporte experimental de QUIC en el servidor Caddy . [54] El 11 de julio de 2017, LiteSpeed Technologies comenzó oficialmente a admitir QUIC en su balanceador de carga (WebADC) [55] y productos LiteSpeed Web Server . [56] En octubre de 2019 [update], el 88,6% de los sitios web QUIC utilizaban LiteSpeed y el 10,8% utilizaban Nginx . [57] Aunque al principio solo los servidores de Google admitían conexiones HTTP-over-QUIC, Facebook también lanzó la tecnología en 2018, [18] y Cloudflare ha estado ofreciendo soporte QUIC en versión beta desde 2018. [58] Se agregó el balanceador de carga HAProxy soporte experimental para QUIC en marzo de 2022 [59] y lo declaró listo para producción en marzo de 2023. [60] En abril de 2023 [update], el 8,9% de todos los sitios web utilizan QUIC, [61] frente al 5% en marzo de 2021. Microsoft Windows Server 2022 admite protocolos HTTP/3 [62] y SMB sobre QUIC [63] [10] a través de MsQuic . El Application Delivery Controller de Citrix (Citrix ADC, NetScaler) puede funcionar como proxy QUIC desde la versión 13. [64] [65]
Además, hay varios proyectos comunitarios obsoletos: libquic [66] se creó extrayendo la implementación Chromium de QUIC y modificándola para minimizar los requisitos de dependencia, y goquic [67] proporciona enlaces Go de libquic. Finalmente, quic-reverse-proxy [68] es una imagen de Docker que actúa como un servidor proxy inverso , traduciendo solicitudes QUIC a HTTP simple que el servidor de origen puede entender.
.NET 5 introduce soporte experimental para QUIC utilizando la biblioteca MsQuic . [69]
{{cite web}}: CS1 maint: numeric names: authors list (link)