Desde hace más de 20 años visualizamos páginas web utilizando el protocolo HTTP. La mayoría de los usuarios ni siquiera piensan en qué es y cómo funciona. Otros saben que en algún lugar debajo de HTTP está TLS, y debajo está TCP, debajo está IP, y así sucesivamente. Y otros, herejes, creen que TCP es cosa del pasado; quieren algo más rápido, más confiable y seguro. Pero en sus intentos de inventar un nuevo protocolo ideal, han vuelto a la tecnología de los años 80 y están tratando de construir su nuevo mundo feliz sobre ella.
Un poco de historia: HTTP/1.1
En 1997, el protocolo de intercambio de información de texto HTTP versión 1.1 adquirió su propio RFC. En ese momento, los navegadores llevaban varios años utilizando el protocolo y el nuevo estándar duró otros quince. El protocolo funcionaba únicamente según el principio de solicitud-respuesta y estaba destinado principalmente a la transmisión de información de texto.
HTTP fue diseñado para ejecutarse sobre el protocolo TCP, lo que garantiza que los paquetes se entreguen de manera confiable a su destino. TCP funciona estableciendo y manteniendo una conexión confiable entre puntos finales y dividiendo el tráfico en segmentos. Los segmentos tienen su propio número de serie y suma de comprobación. Si de repente uno de los segmentos no llega o llega con una suma de verificación incorrecta, la transmisión se detendrá hasta que se restablezca el segmento perdido.
En HTTP/1.0, la conexión TCP se cerraba después de cada solicitud. Esto fue un gran desperdicio, porque... establecer una conexión TCP (3-Way-Handshake) es un proceso lento. HTTP/1.1 introdujo el mecanismo de mantenimiento de conexión, que le permite reutilizar una conexión para múltiples solicitudes. Sin embargo, dado que puede convertirse fácilmente en un cuello de botella, varias implementaciones de HTTP/1.1 permiten abrir múltiples conexiones TCP al mismo host. Por ejemplo, Chrome y las versiones recientes de Firefox permiten hasta seis conexiones.
El cifrado también debía dejarse en manos de otros protocolos, y para ello se utilizó el protocolo TLS sobre TCP, que protegía los datos de forma fiable, pero aumentaba aún más el tiempo necesario para establecer una conexión. Como resultado, el proceso de apretón de manos comenzó a verse así:
Ilustración de nube
Por lo tanto, HTTP/1.1 tuvo una serie de problemas:
- Configuración de conexión lenta.
- Los datos se transmiten en forma de texto, por lo que la transmisión de imágenes, vídeos y otra información que no sea texto no es efectiva.
- Se utiliza una conexión TCP para una solicitud, lo que significa que otras solicitudes deben encontrar otra conexión o esperar hasta que la solicitud actual la libere.
- Solo se admite el modelo pull. No hay nada en el estándar sobre server-push.
- Los títulos se transmiten en texto.
Si el server-push se implementa al menos mediante el protocolo WebSocket, entonces los problemas restantes deberán abordarse de manera más radical.
Un poco de modernidad: HTTP/2
En 2012, Google comenzó a trabajar en el protocolo SPDY (pronunciado “rápido”). El protocolo fue diseñado para resolver los principales problemas de HTTP/1.1 y al mismo tiempo debía mantener la compatibilidad con versiones anteriores. En 2015, el grupo de trabajo del IETF introdujo la especificación HTTP/2 basada en el protocolo SPDY. Aquí están las diferencias en HTTP/2:
- Serialización binaria.
- Multiplexación de múltiples solicitudes HTTP en una única conexión TCP.
- Servidor listo para usar (sin WebSocket).
El protocolo fue un gran paso adelante. el fuertemente y no requiere la creación de múltiples conexiones TCP: todas las solicitudes a un host se multiplexan en una. Es decir, en una conexión hay varios flujos, cada uno de los cuales tiene su propia identificación. El bono es un push de servidor en caja.
Sin embargo, la multiplexación conduce a otro problema clave. Imagine que estamos ejecutando de forma asincrónica 5 solicitudes a un servidor. Cuando se utiliza HTTP/2, todas estas solicitudes se llevarán a cabo dentro de la misma conexión TCP, lo que significa que si uno de los segmentos de cualquier solicitud se pierde o se recibe incorrectamente, la transmisión de todas las solicitudes y respuestas se detendrá hasta que se elimine el segmento perdido. restaurado. Obviamente, cuanto peor es la calidad de la conexión, más lento funciona HTTP/2. , en condiciones en las que los paquetes perdidos representan el 2% de todos los paquetes, HTTP/1.1 en el navegador funciona mejor que HTTP/2 debido a que abre 6 conexiones en lugar de una.
Este problema se llama "bloqueo de cabecera de línea" y, lamentablemente, no es posible resolverlo cuando se utiliza TCP.
Ilustración de Daniel Steinberg
Como resultado, los desarrolladores del estándar HTTP/2 hicieron un gran trabajo e hicieron casi todo lo que se podía hacer en la capa de aplicación del modelo OSI. Es hora de bajar a la capa de transporte e inventar un nuevo protocolo de transporte.
Necesitamos un nuevo protocolo: UDP vs TCP
Muy rápidamente quedó claro que implementar un protocolo de capa de transporte completamente nuevo es una tarea imposible en la realidad actual. El caso es que el hardware o los middle-boxes (routers, firewalls, servidores NAT...) conocen la capa de transporte, y enseñarles algo nuevo es una tarea extremadamente difícil. Además, el soporte para protocolos de transporte está integrado en el núcleo de los sistemas operativos, y los núcleos tampoco están muy dispuestos a cambiar.
Y aquí uno podría levantar las manos y decir: "Nosotros, por supuesto, inventaremos un nuevo HTTP/3 con preferencia y cortesanas, pero su implementación tardará entre 10 y 15 años (después de este tiempo, la mayor parte del hardware estará disponible). reemplazado)”, pero hay uno más que no es así. La opción obvia es utilizar el protocolo UDP. Sí, sí, el mismo protocolo que usábamos para enviar archivos a través de LAN a finales de los noventa y principios de los XNUMX. Casi todo el hardware actual puede funcionar con él.
¿Cuáles son las ventajas de UDP sobre TCP? En primer lugar, no tenemos una sesión de capa de transporte que el hardware conozca. Esto nos permite determinar nosotros mismos la sesión en los puntos finales y resolver los conflictos allí. Es decir, no estamos limitados a una o varias sesiones (como en TCP), sino que podemos crear tantas como necesitemos. En segundo lugar, la transmisión de datos mediante UDP es más rápida que mediante TCP. Por lo tanto, en teoría, podemos superar el límite de velocidad actual alcanzado en HTTP/2.
Sin embargo, UDP no garantiza una transmisión de datos fiable. De hecho, simplemente estamos enviando paquetes con la esperanza de que el otro extremo los reciba. ¿No ha recibido? Bueno, no hubo suerte... Esto fue suficiente para transmitir videos para adultos, pero para cosas más serias necesitas confiabilidad, lo que significa que tienes que envolver algo más encima de UDP.
Al igual que con HTTP/2, el trabajo para crear un nuevo protocolo comenzó en Google en 2012, es decir, casi al mismo tiempo que comenzó el trabajo en SPDY. En 2013, Jim Roskind presentó al público en general. , y ya en 2015 se introdujo el Borrador de Internet para su estandarización en el IETF. Ya en ese momento, el protocolo desarrollado por Roskind en Google era muy diferente del estándar, por lo que la versión de Google comenzó a llamarse gQUIC.
¿Qué es QUIC?
En primer lugar, como ya se mencionó, se trata de un contenedor de UDP. Sobre UDP se encuentra una conexión QUIC, en la que, por analogía con HTTP/2, pueden existir varios flujos. Estas transmisiones existen solo en los puntos finales y se sirven de forma independiente. Si se produce una pérdida de paquete en una secuencia, no afectará a las demás.
Ilustración de Daniel Steinberg
En segundo lugar, el cifrado ya no se implementa en un nivel separado, sino que está incluido en el protocolo. Esto le permite establecer una conexión e intercambiar claves públicas en un solo protocolo de enlace, y también le permite utilizar el inteligente mecanismo de protocolo de enlace 0-RTT y evitar retrasos en el protocolo de enlace por completo. Además, ahora es posible cifrar paquetes de datos individuales. Esto le permite no esperar a que se complete la recepción de datos del flujo, sino descifrar los paquetes recibidos de forma independiente. Este modo de operación era generalmente imposible en TCP, porque TLS y TCP funcionaban de forma independiente el uno del otro, y TLS no podía saber en qué partes se dividirían los datos de TCP. Y por lo tanto, no pudo preparar sus segmentos para que encajaran en los segmentos TCP uno a uno y pudieran descifrarse de forma independiente. Todas estas mejoras permiten a QUIC reducir la latencia en comparación con TCP.
En tercer lugar, el concepto de transmisión de luz le permite desacoplar la conexión de la dirección IP del cliente. Esto es importante, por ejemplo, cuando un cliente cambia de un punto de acceso Wi-Fi a otro, cambiando su IP. En este caso, cuando se utiliza TCP, se produce un proceso largo durante el cual las conexiones TCP existentes expiran y se crean nuevas conexiones a partir de una nueva IP. En el caso de QUIC, el cliente simplemente continúa enviando paquetes al servidor desde una nueva IP con la antigua ID de flujo. Porque El ID de transmisión ahora es único y no se reutiliza; el servidor comprende que el cliente ha cambiado de IP, reenvía los paquetes perdidos y continúa la comunicación en la nueva dirección.
Cuarto, QUIC se implementa a nivel de aplicación, no a nivel de sistema operativo. Esto, por un lado, le permite realizar cambios rápidamente en el protocolo, porque Para obtener una actualización, sólo necesita actualizar la biblioteca, en lugar de esperar una nueva versión del sistema operativo. Por otro lado, esto provoca un fuerte aumento del consumo de procesadores.
Y por último, los titulares. La compresión de encabezado es una de las cosas que diferencian entre QUIC y gQUIC. No veo el sentido de dedicar mucho tiempo a esto, solo diré que en la versión enviada para estandarización, la compresión de encabezados se hizo lo más similar posible a la compresión de encabezados en HTTP/2. Puedes leer más .
¿Cuánto más rápido es?
Es una pregunta difícil. El hecho es que hasta que no tengamos un estándar, no habrá nada especial que medir. Quizás las únicas estadísticas que tenemos sean las de Google, que utiliza gQUIC desde 2013 y 2016. que alrededor del 90% del tráfico que llega a sus servidores desde el navegador Chrome ahora utiliza QUIC. En la misma presentación, informan que las páginas se cargan aproximadamente un 5 % más rápido a través de gQUIC y hay un 30 % menos de tartamudeo en la transmisión de video en comparación con TCP.
En 2017, un grupo de investigadores dirigido por Arash Molavi Kakhki publicó estudiar el rendimiento de gQUIC en comparación con TCP.
El estudio reveló varias debilidades de gQUIC, como la inestabilidad en la mezcla de paquetes de red, la codicia (injusticia) en el ancho de banda del canal y una transferencia más lenta de objetos pequeños (hasta 10 kb). Sin embargo, esto último se puede compensar utilizando 0-RTT. En todos los demás casos estudiados, gQUIC mostró un aumento en la velocidad en comparación con TCP. Es difícil hablar aquí de números específicos. mejor leer o .
Aquí hay que decir que estos datos se refieren específicamente a gQUIC y no son relevantes para el estándar que se está desarrollando. Qué pasará con QUIC: todavía es un secreto, pero hay esperanzas de que las debilidades identificadas en gQUIC se tengan en cuenta y se corrijan.
Un poco del futuro: ¿qué pasa con HTTP/3?
Pero aquí todo está muy claro: la API no cambiará de ninguna manera. Todo seguirá exactamente igual que en HTTP/2. Bueno, si la API sigue siendo la misma, la transición a HTTP/3 tendrá que resolverse utilizando una versión nueva de la biblioteca en el backend que admita el transporte QUIC. Es cierto que tendrá que conservar las versiones antiguas de HTTP durante bastante tiempo, porque Actualmente, Internet no está preparado para una transición completa a UDP.
Quien ya apoya
aquí está implementaciones QUIC existentes. A pesar de la falta de una norma, la lista no es mala.
Actualmente, ningún navegador admite QUIC en una versión de producción. Recientemente hubo información de que Chrome incluía soporte para HTTP/3, pero hasta ahora solo en Canary.
De los backends, HTTP/3 solo admite и , pero aún experimental. NGINX a finales de la primavera de 2019 , que comenzaron a trabajar en el soporte HTTP/3, pero aún no lo han terminado.
¿Cuáles son los problemas?
Tú y yo vivimos en el mundo real, donde ninguna gran tecnología puede llegar a las masas sin encontrar resistencia, y QUIC no es una excepción.
Lo más importante es que de alguna manera debes explicarle al navegador que "https://" ya no es un hecho y conduce al puerto TCP 443. Puede que no haya ningún TCP. Para esto se utiliza el encabezado Alt-Svc. Le permite indicarle al navegador que este sitio web también está disponible en tal o cual protocolo en tal o cual dirección. En teoría, esto debería funcionar a las mil maravillas, pero en la práctica nos encontraremos con el hecho de que UDP puede, por ejemplo, prohibirse en un firewall para evitar ataques DDoS.
Pero incluso si UDP no está prohibido, el cliente puede estar detrás de un enrutador NAT configurado para mantener una sesión TCP por dirección IP y, dado que Usamos UDP, que no tiene sesión de hardware, NAT no mantendrá la conexión y una sesión QUIC. .
Todos estos problemas se deben al hecho de que UDP no se había utilizado anteriormente para transmitir contenido de Internet y los fabricantes de hardware no podían prever que esto sucedería alguna vez. De la misma manera, los administradores aún no entienden realmente cómo configurar correctamente sus redes para que funcione QUIC. Esta situación irá cambiando gradualmente y, en cualquier caso, dichos cambios llevarán menos tiempo que la implementación de un nuevo protocolo de capa de transporte.
Además, como ya se describió, QUIC aumenta considerablemente el uso de la CPU. Daniel Stenberg crecimiento del procesador hasta tres veces.
¿Cuándo llegará HTTP/3?
Estándar para mayo de 2020, pero dado que los documentos previstos para julio de 2019 siguen sin terminar por el momento, podemos decir que lo más probable es que la fecha se retrase.
Bueno, Google ha estado utilizando su implementación gQUIC desde 2013. Si miras la solicitud HTTP que se envía al motor de búsqueda de Google, verás esto:
Hallazgos
QUIC ahora parece una tecnología bastante tosca, pero muy prometedora. Teniendo en cuenta que en los últimos 20 años todas las optimizaciones de los protocolos de la capa de transporte se han centrado principalmente en TCP, QUIC, que en la mayoría de los casos tiene el mejor rendimiento, ya luce extremadamente bien.
Sin embargo, todavía quedan problemas sin resolver que habrá que abordar en los próximos años. El proceso puede retrasarse debido al hecho de que hay hardware involucrado que a nadie le gusta actualizar, pero, sin embargo, todos los problemas parecen bastante solucionables y, tarde o temprano, todos tendremos HTTP/3.
¡El futuro está a la vuelta de la esquina!
Fuente: habr.com