De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Conjunto de protocolos de internet
Capa de aplicación
Capa de transporte
Capa de internet
Capa de enlace
  • ARP
  • NDP
  • OSPF
  • Túneles
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Wifi
    • DSL
    • RDSI
    • FDDI
  • más...
  • v
  • t
  • mi

QUIC (pronunciado "rápido") es un protocolo de red de uso general [1] capa de transporte [2] diseñado inicialmente por Jim Roskind en Google , [3] implementado y desplegado en 2012, [4] anunciado públicamente en 2013 a medida que se ampliaba la experimentación , [5] [6] [7] y descrito al 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 , [10] Firefox , [11] y Safari [12] lo admiten, incluso si no está habilitado de forma predeterminada.

Aunque su nombre se propuso inicialmente como el acrónimo de "Quick UDP Internet Connections", [3] [8] El uso de 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 hacer obsoleto el TCP en la capa de red para muchas aplicaciones, lo que le otorga al protocolo el apodo ocasional "TCP / 2 ". [13]

QUIC trabaja mano a 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 a otros flujos. Por el contrario, HTTP / 2 alojado en el Protocolo de control de transmisión (TCP) puede sufrir retrasos en el bloqueo de la 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 extremos, 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 corrección de errores hacia adelante (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ó un Borrador de Internet de una especificación para QUIC al IETF para su estandarización. [14] [15] En 2016 se estableció un grupo de trabajo QUIC. [16] 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. [17]

Antecedentes [ editar ]

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 asegura que los datos lleguen al otro extremo exactamente de la misma forma, o la conexión indicará que existe una condición de error. [18]

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 fuera de orden, 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. [18]

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 ú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 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. [18]

Como el sistema TCP está diseñado para parecerse a una "tubería de datos", o flujo, deliberadamente contiene poca comprensión de los datos que transmite. Si esos datos tienen requisitos adicionales, como el cifrado mediante TLS , esto debe ser configurado por sistemas que se ejecutan 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 establezca 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. [18]

Características [ editar ]

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 . [18]

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 demandarán TLS , QUIC hace que el intercambio de claves de configuración y protocolos admitidos forme parte del proceso de reconocimiento 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. Otros protocolos pueden ser atendidos 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 las solicitudes futuras que, de lo contrario, se negociarían como conexiones separadas. [18]

El segundo cambio es utilizar UDP en lugar de TCP como base, 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 de UDP. Esto significa que si ocurre un error en una secuencia, como en el ejemplo de favicon anterior, la pila de protocolos puede continuar dando 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 un paquete falta o está roto, y todos estos datos se bloquean o incluso se eliminan mientras se corrige el error. En QUIC, estos datos pueden procesarse libremente mientras se repara el flujo multiplexado único. [19]

QUIC incluye una serie de otros cambios más mundanos que también mejoran la latencia general y el rendimiento. Por ejemplo, los paquetes se cifran individualmente, de modo que no provoquen que los datos cifrados esperen paquetes parciales. Por lo general, esto no es posible en TCP, donde los registros de cifrado están en una secuencia de bytes y la pila de protocolos desconoce los límites de capa superior dentro de esta secuencia. Estos pueden ser negociados por las capas que se ejecutan en la parte superior, pero QUIC tiene como objetivo hacer todo esto en un solo proceso de protocolo de enlace. [8]

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 se mueve 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 expira una por una y luego se restablece a pedido. Para resolver este problema, QUIC incluye un identificador de conexión que identifica de manera única la conexión al servidor independientemente de la fuente. Esto permite restablecer la conexión simplemente enviando un paquete, que siempre contiene este ID, ya que el ID de conexión original seguirá siendo válido incluso si cambia la dirección IP del usuario . [20]

QUIC se puede implementar en el espacio de la aplicación, en lugar de estar en el kernel del sistema operativo . Esto generalmente invoca una sobrecarga adicional debido a 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 sola aplicación, y cada aplicación que usa 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 que los cambios futuros se realicen 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 hacia adelante (FEC) y un mejor control de la congestión. [20]

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 para bloquear UDP. Google llevó a cabo una serie de experimentos exploratorios para caracterizar esto y descubrió que solo una pequeña cantidad de conexiones se bloqueaban 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 latencia cero. [21]

Google QUIC (gQUIC) [ editar ]

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, mientras que la evolución actual del protocolo IETF QUIC es el 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 completamente con los estándares de Internet más recientes para QUIC en Chromium.

Adopción [ editar ]

Compatibilidad con el cliente y el navegador [ editar ]

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). [17] Actualmente está habilitado de forma predeterminada en Chromium. En el navegador Chrome, el soporte QUIC experimental se puede habilitar en chrome: // flags. También hay una extensión de navegador [22] para indicar qué páginas son atendidas por QUIC.

De manera similar, se introdujo en Opera 16, se puede activar en opera: // flags / # enable-quic , y las sesiones activas se pueden ver en opera: // net-internals / # quic .

El soporte en Firefox Nightly llegó en noviembre de 2019. [23] [24]

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 . [25]

cURL 7.66, lanzado el 11 de septiembre de 2019, es compatible con HTTP / 3 (y, por lo tanto, QUIC). [26] [27]

En octubre de 2020, Facebook anunció [28] que había migrado con éxito sus aplicaciones e infraestructura de servidor a QUIC, y ya el 75% de su tráfico de Internet utiliza QUIC.

Soporte del servidor [ editar ]

A partir de 2017 , hay cuatro implementaciones mantenidas activamente. Los servidores de Google son compatibles con QUIC y Google ha publicado un servidor prototipo. [29] Akamai Technologies ha sido compatible con QUIC desde julio de 2016. [30] [31] También está disponible una implementación de Go llamada quic-go [32] , que potencia el soporte experimental de QUIC en el servidor Caddy . [33] El 11 de julio de 2017, LiteSpeed ​​Technologies comenzó oficialmente a admitir QUIC en sus productos de balanceador de carga (WebADC) [34] y LiteSpeed ​​Web Server . [35] En octubre de 2019 , el 88,6% de los sitios web de QUIC utilizaban LiteSpeed ​​y el 10,8% utilizabaNginx . [36] Aunque al principio solo los servidores de Google admitían conexiones HTTP sobre QUIC, Facebook también lanzó la tecnología en 2018, [17] y Cloudflare ha estado ofreciendo soporte QUIC en forma beta desde 2018. [37] En marzo de 2021 , El 5,0% de todos los sitios web utilizan QUIC. [38]

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

.NET 5 introduce soporte experimental para QUIC usando la biblioteca MsQuic . [42]

Código fuente [ editar ]

Las siguientes implementaciones de QUIC o gQUIC están disponibles en formato fuente:
ImplementaciónLicenciaIdiomaDescripción
CromoLibreC ++Este es el código fuente del navegador web Chrome y la implementación de gQUIC de referencia. Contiene programas de servidor y cliente gQUIC y QUIC independientes que se pueden utilizar para realizar pruebas. Código fuente navegable . Esta versión también es la base de la estelita de LINE y la bruja de Google.
Biblioteca QUIC (mvfst)Licencia MITC ++mvfst (pronunciado movimiento rápido) es una implementación de cliente y servidor del protocolo IETF QUIC en C ++ de Facebook.
Biblioteca LiteSpeed ​​QUIC (lsquic)Licencia MITCEsta es la implementación QUIC y HTTP / 3 utilizada por LiteSpeed ​​Web Server y OpenLiteSpeed .
ngtcp2Licencia MITCEsta es una biblioteca QUIC que es independiente de la biblioteca de cifrado y funciona con OpenSSL o GnuTLS. Para HTTP / 3, necesita una biblioteca separada como nghttp3 .
QuicheLicencia BSD-2-CláusulaOxidoAgnóstico de socket y expone una API de C para su uso en aplicaciones C / C ++.
rápidamenteLicencia MITCEsta biblioteca es la implementación QUIC para el servidor web H2O .
rápidoLicencia MITIrEsta biblioteca proporciona soporte QUIC en el servidor web Caddy . La funcionalidad del cliente también está disponible.
QuinnLicencia Apache 2.0Oxido
NeqoLicencia Apache 2.0OxidoEstá previsto que esta implementación de Mozilla se integre en Necko, una biblioteca de red utilizada en el navegador web Firefox.
aioquicLicencia BSD-3-CláusulaPitónEsta biblioteca presenta una API sin E / S adecuada para incrustar tanto en clientes como en servidores.
picoquicLicencia BSD-3-CláusulaCUna implementación mínima de QUIC alineada con las especificaciones de IETF
pquicLicencia MITCUna implementación QUIC extensible que incluye una máquina virtual eBPF que puede cargar extensiones dinámicamente como complementos
MsQuicLicencia MITCUna implementación QUIC multiplataforma de Microsoft diseñada para ser una biblioteca QUIC de propósito general.
CUANTLicencia BSD-2-CláusulaCQuant admite plataformas POSIX tradicionales (Linux, MacOS, FreeBSD, etc.) así como sistemas integrados.
rápidoLicencia BSD-3-CláusulaHaskellEste paquete implementa QUIC basado en subprocesos ligeros Haskell.
netty-incubator-codec-quicLicencia Apache 2.0JavaEste paquete implementa QUIC en netty basado en la implementación de Quiche .

Ver también [ editar ]

  • Protocolo de aplicación restringida (CoAP): un protocolo basado en UDP que utiliza el modelo REST
  • Protocolo de control de congestión de datagramas (DCCP)
  • Seguridad de la capa de transporte de datagramas (DTLS)
  • Protocolo rápido y seguro
  • HTTP / 3
  • LEDBAT (transporte en segundo plano con retardo extra bajo)
  • Protocolo de micro transporte (µTP)
  • Protocolo de transacciones multipropósito (MTP / IP): una alternativa a QUIC de Data Expedition, Inc.
  • Protocolo de flujo de medios en tiempo real (RTMFP)
  • Protocolo de datagramas de usuario confiable (RUDP)
  • SPDY
  • Protocolo de transmisión de control de flujo (encapsulación SCTP UDP; RFC 6951)
  • Transporte de flujo estructurado
  • Protocolo de transferencia de datos (UDT) basado en UDP: un protocolo de transporte basado en UDP

Referencias [ editar ]

  1. ^ a b QUIC: Un transporte seguro y multiplexado basado en UDP . IETF . segundo. 1. ID draft-ietf-quic-transport-34.
  2. ^ a b Nathan Willis. "Conexión en el QUIC" . Noticias semanales de Linux . Consultado el 16 de julio de 2013 .
  3. ^ a b c "QUIC: Documento de diseño y fundamento de la especificación" . Jim Roskind, colaborador de Chromium.
  4. ^ a b "Primer aterrizaje de código de Chromium: CL 11125002: Agregar QuicFramer y amigos" . Consultado el 16 de octubre de 2012 .
  5. ^ "Experimentar con QUIC" . Blog oficial de Chromium . Consultado el 16 de julio de 2013 .
  6. ^ "QUIC, Google quiere hacer la web más rápida" . François Beaufort, evangelista de Chromium.
  7. ^ "QUIC: transporte multiplexado de próxima generación sobre UDP" . YouTube . Consultado el 4 de abril de 2014 .
  8. ^ a b c d "QUIC: Presentación del área de IETF-88 TSV" (PDF) . Jim Roskind, Google . Consultado el 7 de noviembre de 2013 .
  9. ↑ a b Lardinois, Frederic. "Google quiere acelerar la web con su protocolo QUIC" . TechCrunch . Consultado el 25 de octubre de 2016 .
  10. ^ Christopher Fernandes (3 de abril de 2018). "Microsoft agregará soporte para el protocolo de Internet rápido QUIC de Google en Windows 10 Redstone 5" . Consultado el 8 de mayo de 2020 .
  11. ^ "Cómo habilitar HTTP3 en Chrome / Firefox / Safari" . bram.us . 8 de abril de 2020.
  12. ^ "El estado de QUIC y HTTP / 3 2020" . www.fastly.com . Consultado el 21 de octubre de 2020 .
  13. ^ Tatsuhiro Tsujikawa. "ngtcp2" . GitHub . Consultado el 17 de octubre de 2020 .
  14. ^ "Google propondrá QUIC como estándar IETF" . InfoQ . Consultado el 25 de octubre de 2016 .
  15. ^ "Acción de identificación: borrador-tsvwg-quic-protocol-00.txt" . id -noun (lista de correo). 17 de junio de 2015.
  16. ^ "QUIC - Grupo de trabajo IETF" . datatracker.ietf.org . Consultado el 25 de octubre de 2016 .
  17. ↑ a b c Cimpanu, Catalin (12 de noviembre de 2018). "HTTP-over-QUIC será renombrado HTTP / 3" . ZDNet .
  18. ↑ a b c d e f Bright, Peter (12 de noviembre de 2018). "La próxima versión de HTTP no utilizará TCP" . Arstechnica .
  19. ^ Behr, Michael; Swett, Ian. "Presentamos el soporte QUIC para el equilibrio de carga HTTPS" . Blog de Google Cloud Platform . Consultado el 16 de junio de 2018 .
  20. ^ a b "QUIC a 10,000 pies" . Cromo .
  21. ^ "Aplicabilidad del protocolo de transporte QUIC" . Grupo de trabajo de la red IETF . 22 de octubre de 2018.
  22. ^ "Indicador HTTP / 2 y SPDY" . chrome.google.com . Consultado el 7 de agosto de 2020 .
  23. ^ Daniel, Stenberg. "Daniel Stenberg anuncia soporte HTTP / 3 en Firefox Nightly" . Twitter . Consultado el 5 de noviembre de 2019 .
  24. ^ Cimpanu, Catalin (26 de septiembre de 2019). "Cloudflare, Google Chrome y Firefox añaden compatibilidad con HTTP / 3" . ZDNet . Consultado el 27 de septiembre de 2019 .
  25. ^ "Realizar operaciones de red utilizando Cronet" . Desarrolladores de Android . Consultado el 20 de julio de 2019 .
  26. ^ "rizo - Cambios" . curl.haxx.se . Consultado el 30 de septiembre de 2019 .
  27. ^ "curl 7.66.0 - el futuro HTTP / 3 paralelo está aquí | daniel.haxx.se" . Consultado el 30 de septiembre de 2019 .
  28. ^ "Cómo Facebook está llevando QUIC a miles de millones" . Ingeniería de Facebook . 2020-10-21 . Consultado el 23 de octubre de 2020 .
  29. ^ https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.cc
  30. ^ Soporte QUIC de Akamai , obtenido el 20 de mayo de 2020.
  31. ^ QUIC in the Wild, Passive Active Measurements Conference (PAM), 2018 , consultado el 20 de mayo de 2020.
  32. ^ "lucas-clemente / quic-go" . 7 de agosto de 2020 . Recuperado el 7 de agosto de 2020 , a través de GitHub.
  33. ^ Soporte QUIC en Caddy , obtenido el 13 de julio de 2016.
  34. ^ "LiteSpeed ​​Web ADC - Load Balancer - LiteSpeed ​​Technologies" . www.litespeedtech.com . Consultado el 7 de agosto de 2020 .
  35. ^ Publicación de blog QUIC de LiteSpeed ​​Technologies, obtenida el 11 de julio de 2017.
  36. ^ "Distribución de servidores web entre sitios web que utilizan QUIC" . w3techs.com . Consultado el 7 de agosto de 2020 .
  37. ^ "Obtenga una ventaja con QUIC" . 2018-09-25 . Consultado el 16 de julio de 2019 .
  38. ^ "Estadísticas de uso de QUIC para sitios web, marzo de 2021" . w3techs.com . Consultado el 4 de marzo de 2021 .
  39. ^ "devsisters / libquic" . 5 de agosto de 2020 . Recuperado el 7 de agosto de 2020 , a través de GitHub.
  40. ^ "devsisters / goquic" . 5 de agosto de 2020 . Recuperado el 7 de agosto de 2020 , a través de GitHub.
  41. ^ "Docker Hub" . hub.docker.com . Consultado el 7 de agosto de 2020 .
  42. ^ "Mejoras de red .NET 5" . Blog de .NET . 2021-01-11 . Consultado el 26 de enero de 2021 .

Enlaces externos [ editar ]

  • Especificación IETF QUIC, borrador 34
  • Chromium : QUIC, un transporte de flujo multiplexado sobre UDP
  • QUIC: Documento de diseño y fundamento de la especificación, documento original de Jim Roskind (2012/2013)
  • Daniel Stenberg : HTTP / 3 explicado
  • Noticias semanales de Linux : Conectando con QUIC (2013)
  • QUIC:, Presentación del área IETF-88 TSV (2013-11-07)
  • Blog de Chromium: Experimentando con QUIC (2013)
  • QUIC: transporte multiplexado de próxima generación sobre UDP (Google Developers, 2014)
  • HTTP sobre UDP: una investigación experimental de QUIC
  • QUIC de múltiples rutas (extensión de QUIC)
  • Innovación del transporte con QUIC: enfoques de diseño y desafíos de investigación (2017)