HTTP / 3: de ra铆z a punta

El protocolo de capa de aplicaci贸n HTTP subyace a Internet. Comenz贸 su vida en 1991 como HTTP / 0.9, y en 1999 se convirti贸 en HTTP / 1.1, que fue estandarizado por el Consejo de Ingenier铆a de Internet (IETF).

HTTP / 1.1 satisfizo a todos durante mucho tiempo, pero las crecientes necesidades de la Web requirieron una actualizaci贸n, y en 2015 adoptaron HTTP / 2. La historia no termin贸 all铆: recientemente, el IETF anunci贸 una nueva versi贸n de HTTP / 3. Para algunos, esto fue una sorpresa y caus贸 cierta confusi贸n. Si no est谩 monitoreando el IETF, puede parecer que HTTP / 3 vino de la nada. Sin embargo, podemos rastrear su origen de acuerdo con la historia de los experimentos y la evoluci贸n de los protocolos web, en particular, el protocolo de transporte QUIC.

Si no est谩 familiarizado con QUIC, mis colegas de Cloudflare han cubierto varios aspectos con cierto detalle: por ejemplo, vea art铆culos sobre las fallas reales del HTTP moderno y detalles sobre el protocolo de la capa de transporte . Hemos recopilado estos y otros materiales en cloudflare-quic.com . Y si est谩 interesado, aseg煤rese de consultar quiche : es nuestra propia implementaci贸n de QUIC, escrita en Rust con c贸digo fuente abierto.

HTTP / 3: traducci贸n del protocolo de transporte QUIC para la capa de aplicaci贸n. El nombre HTTP / 3 fue aprobado oficialmente solo recientemente, en la versi贸n 17 del borrador ( draft-ietf-quic-http-17 ). Se propuso a finales de octubre de 2018, y se lleg贸 a un consenso en la reuni贸n IETF 103 en Bangkok en noviembre.

Anteriormente, HTTP / 3 era conocido como HTTP por QUIC, y antes de eso, como HTTP / 2 por gQUIC, e incluso antes, SPDY por gQUIC. Pero la conclusi贸n es que HTTP / 3 es solo la nueva sintaxis HTTP que se ejecuta en el protocolo IETF QUIC, un transporte multiplexado y seguro basado en UDP.

En este art铆culo, veremos el historial de algunos de los nombres HTTP / 3 anteriores e introduciremos la motivaci贸n para el cambio de apellido. Volvamos a los primeros d铆as de HTTP y todo lo que sucedi贸 durante este tiempo. Si desea obtener una imagen completa, puede ir inmediatamente al final del art铆culo o abrir esta versi贸n muy detallada de SVG .


Pastel HTTP / 3 Layer

Muebles


Justo antes de enfocarse en HTTP, vale la pena recordar que hay dos protocolos llamados QUIC. Como ya hemos explicado , gQUIC generalmente se usa como una abreviatura de Google QUIC (protocolo fuente) y QUIC como una versi贸n IETF que difiere de gQUIC.

Desde principios de los 90, las necesidades de Internet han cambiado. Tenemos nuevas versiones de HTTP y un nuevo nivel de seguridad en forma de protocolo TLS (Seguridad de la capa de transporte). En este art铆culo, cubriremos solo TLS, y en otros art铆culos de nuestro blog puede estudiar el tema con m谩s detalle.

La historia de HTTP y TLS no se puede expresar con una simple lista de fechas, ya que algunas ramas evolucionaron en paralelo y se superpusieron en el tiempo. Cuando intenta conectar todos los puntos en casi 30 a帽os de la historia de Internet, no puede prescindir de la visualizaci贸n. As铆 que hice este cronograma: Cloudflare Secure Web Timeline. (nota: t茅cnicamente este es un cladograma , aunque la gente est谩 m谩s familiarizada con la palabra "gr谩fico").



Por el bien de la belleza, descart茅 parte de la informaci贸n, centr谩ndome solo en las sucursales exitosas en el espacio IETF. Por ejemplo, los esfuerzos del grupo de trabajo HTTP-NG del consorcio W3, as铆 como algunas tecnolog铆as ex贸ticas, cuya pronunciaci贸n los autores todav铆a est谩n tratando de explicar, no se muestran aqu铆: HMURR (pronunciado "hummer") y WAKA (pronunciado "wah-kah").

En las siguientes secciones, veremos este cladograma y veremos algunos puntos de inflexi贸n en la historia de HTTP. Espero que esto ayude a comprender por qu茅 la estandarizaci贸n es beneficiosa para todos y c贸mo el IETF aborda este problema. Por lo tanto, comenzamos con una breve descripci贸n general del tema antes de volver al programa en s铆. Si茅ntase libre de omitir la siguiente secci贸n si ya est谩 familiarizado con el IETF.

Tipos de est谩ndar de Internet


Por lo general, las normas definen la competencia general, el alcance, las limitaciones, la aplicabilidad y otras consideraciones. Las normas existen en muchas formas y tama帽os. Pueden ser informales (est谩ndar de facto) o formales (acordados / publicados por una organizaci贸n de establecimiento de est谩ndares como IETF, ISO o MPEG). Los est谩ndares se utilizan en muchas 谩reas, incluso hay un est谩ndar brit谩nico formal para hacer t茅: BS 6008.

Las primeras definiciones de protocolo HTTP y SSL se publicaron fuera del IETF: est谩n marcadas con l铆neas rojas en el gr谩fico. Pero el uso generalizado los ha convertido en est谩ndares de facto.

En alg煤n momento, decidieron formalizar estos protocolos (algunas razones se describen a continuaci贸n). Los est谩ndares de Internet generalmente se definen en el IETF, que se gu铆a por el principio no oficial de "consenso ejemplar y c贸digo actual" basado en aplicaciones de la vida real en Internet. Esto es diferente del enfoque de sala limpia cuando alguien intenta desarrollar protocolos ideales en el vac铆o.

Los est谩ndares IETF se conocen com煤nmente como RFC. Es dif铆cil de explicar brevemente, por lo tanto, recomiendo el art铆culo "C贸mo leer RFC" del copresidente del grupo de trabajo QUIC Mark Nottingham. Un grupo de trabajo o WG es esencialmente solo una lista de correo.

Cada a帽o hay tres reuniones para reuniones personales de miembros de todos los grupos de trabajo, si as铆 lo desean. La agenda para estas semanas puede estar muy ocupada, no hay suficiente tiempo para una discusi贸n en profundidad de cuestiones t茅cnicas. Por lo tanto, algunos prefieren organizar m谩s reuniones de medio t茅rmino entre las reuniones generales de IETF. El grupo de trabajo QUIC ha celebrado varias reuniones provisionales desde 2017, la lista completa est谩 disponible en la p谩gina de reuniones .

Estas reuniones tienen la oportunidad de reunirse con expertos de otras organizaciones, como Internet Architecture Council (IAB) o Internet Technology Research Group (IRTF). En los 煤ltimos a帽os, el fin de semana anterior al IETF ha celebrado tradicionalmente el hackathon del IETF . El c贸digo real se desarrolla aqu铆 y, lo que es m谩s importante, pasa las pruebas de compatibilidad. Esto ayuda a encontrar problemas en las especificaciones que pueden discutirse directamente en la reuni贸n.

Es importante comprender que los RFC no surgen de la nada. Pasan por todo un proceso. Por lo general, comienza con un borrador de borrador (ID) de Internet de IETF, que se presenta para su revisi贸n. En el caso de que la especificaci贸n ya se haya publicado, preparar una ID se convertir谩 en un simple reformateo. La vida 煤til de la identificaci贸n es de 6 meses a partir de la fecha de publicaci贸n. Para mantenerlo activo, debe publicar nuevas versiones. En la pr谩ctica, est谩 bien que la ID caduque. Esto sucede con bastante frecuencia. Los documentos todav铆a se almacenan en el sitio web de IETF y est谩n abiertos a todos.

En el cladograma, los borradores se presentan en morado . Cada uno tiene su propio nombre en el formato borrador- {autor} - {grupo de trabajo} - {tema} - {versi贸n} . El campo WG es opcional, puede apuntar a un futuro grupo de trabajo de IETF y, a veces, cambia. Si el IETF aprueba el ID o se inicia directamente dentro del IETF, el borrador se llama draft-ietf- {workgroup} - {topic} - {version} . Las ID pueden ramificarse, fusionarse o desvanecerse. La versi贸n comienza en 00 y aumenta con cada nuevo proyecto en uno. Por ejemplo, el cuarto borrador recibir谩 el n煤mero de versi贸n 03. Cada vez que se cambia el nombre de ID, su versi贸n se restablece a 00.

Es importante tener en cuenta que cualquiera puede enviar su borrador al IETF: no pueden considerarse est谩ndares. Pero si el proceso de estandarizaci贸n llega a un consenso y el documento final pasa la prueba, obtendremos un RFC. En este punto, el nombre cambia nuevamente. Cada RFC recibe un n煤mero 煤nico, como RFC 7230 . Los documentos con este estado se muestran como l铆neas azules .

RFC tiene prohibido cambiar. Es decir, los cambios en el RFC requieren la adopci贸n de un documento con un nuevo n煤mero. Los cambios solo est谩n permitidos para corregir errores editoriales o t茅cnicos o para una simple optimizaci贸n del dise帽o. Los nuevos RFC pueden reemplazar por completo a los antiguos o complementarlos.

Todos los documentos de IETF est谩n disponibles p煤blicamente en http://tools.ietf.org . Personalmente, me parece un poco m谩s conveniente que el IETF Datatracker , porque la ruta del documento desde ID a RFC se muestra visualmente all铆.

A continuaci贸n se muestra un ejemplo que muestra el desarrollo del est谩ndar RFC 1945 , es decir, HTTP / 1.0.


Historia de RFC 1945 en la interfaz IETF Datatracker

Curiosamente, en el curso del trabajo, descubr铆 que la visualizaci贸n anterior es incorrecta. Por alguna raz贸n, falta el borrador-ietf-http-v10-spec-05 . Dado que la identificaci贸n tiene 6 meses, probablemente expir贸 antes de la adopci贸n del RFC, aunque en realidad el borrador estuvo activo hasta agosto de 1996.

Estudiando un cladograma


Despu茅s de una breve introducci贸n te贸rica, podemos comenzar a estudiar el cladograma. Esta secci贸n presenta algunos extractos con las partes m谩s importantes. Cada punto indica la fecha en que se proporcion贸 el documento o la funci贸n. Para mayor claridad, los documentos IETF omitieron los n煤meros de proyecto, pero todos est谩n en la versi贸n completa .

HTTP apareci贸 en 1991 como el protocolo HTTP / 0.9, y en 1994 se public贸 draft-fielding-http-spec-00 . Pronto fue aceptado por el IETF, como resultado de lo cual el nombre cambi贸 a draft-ietf-http-v10-spec-00 . Despu茅s de seis ediciones del borrador, el est谩ndar RFC 1945 , HTTP / 1.0, fue adoptado en 1996.



Sin embargo, incluso antes de completar el trabajo en HTTP / 1.0, se lanz贸 un proyecto HTTP / 1.1 separado. La versi贸n preliminar de draft-ietf-http-v11-spec-00 se public贸 en noviembre de 1995 y se adopt贸 oficialmente como RFC 2068 en 1997. El ojo agudo notar谩 que el cladograma no refleja esta secuencia de eventos, un fallo fallido de la herramienta de visualizaci贸n. Trat茅 de minimizar tales problemas siempre que sea posible.

A mediados de 1997, comenz贸 una revisi贸n de HTTP / 1.1 como draft-ietf-http-v11-spec-rev-00 . Termin贸 en 1999 con la publicaci贸n de RFC 2616 . Hasta 2007, todo estaba tranquilo en el mundo HTTP de IETF. Volveremos a esto un poco m谩s tarde.

Historia SSL y TLS




Dirigimos nuestra atenci贸n a la trayectoria SSL. Vemos que la especificaci贸n SSL 2.0 se lanz贸 alrededor de 1995, y SSL 3.0 se lanz贸 en noviembre de 1996. Curiosamente, SSL 3.0 est谩 aprobado en RFC 6101 , que apareci贸 solo en agosto de 2011. Se encuentra en la secci贸n hist贸rica . Seg煤n el IETF , fue creado "para documentar ideas que fueron consideradas y descartadas, o protocolos que ya exist铆an cuando se decidi贸 documentarlos". En este caso, necesitaba un documento IETF que describiera SSL 3.0 para poder usarlo en todas partes como un enlace can贸nico.

Estamos m谩s interesados 鈥嬧媏n c贸mo SSL inspir贸 a los ingenieros para desarrollar TLS, que comenz贸 con un proyecto de draft-ietf-tls-protocol-00 en noviembre de 1996. Pas贸 por 6 versiones preliminares y se public贸 como RFC 2246 - TLS 1.0 a principios de 1999.

En 1995-1999, se utilizaron SSL y TLS para proteger las conexiones HTTP en Internet. Esto funcion贸 muy bien como un est谩ndar de facto. Solo en enero de 1998 comenz贸 la estandarizaci贸n oficial de HTTPS con la publicaci贸n de un proyecto de borrador-ietf-tls-https-00 . Trabajo completado en mayo de 2000 con la publicaci贸n de RFC 2616 - HTTP sobre TLS.

TLS continu贸 evolucionando de 2000 a 2007, con la adopci贸n de TLS 1.1 y 1.2. Luego hubo una pausa de siete a帽os antes de que comenzara el trabajo en la pr贸xima versi贸n del protocolo TLS, que se publicar谩 como draft-ietf-tls-tls13-00 en abril de 2014, y despu茅s de 28 borradores se aprobar谩 como RFC 8446 - TLS 1.3 en agosto de 2018.

Proceso de estandarizaci贸n de internet


Despu茅s de un breve conocimiento del cladograma, espero que sea mejor entender c贸mo funciona el IETF. Al crear est谩ndares, los investigadores o ingenieros desarrollan protocolos experimentales para casos de uso espec铆ficos. En varios niveles, experimentan con protocolos p煤blicos o privados. La informaci贸n recibida le permite identificar problemas o mejorar el protocolo. La publicaci贸n del trabajo ayuda a explicar el experimento, la opini贸n de la reuni贸n de un c铆rculo m谩s amplio de especialistas o para encontrar ayuda de otros artistas. Si otros participantes aceptan este trabajo en una etapa temprana, se convertir谩 en el est谩ndar de facto y, en 煤ltima instancia, habr谩 suficiente impulso para la estandarizaci贸n oficial.

El estado oficial del protocolo es un factor importante para las organizaciones que piensan en usarlo. El proceso formal de estandarizaci贸n hace que el est谩ndar de facto sea m谩s atractivo porque generalmente proporciona estabilidad. Una organizaci贸n acreditada como el IETF, que refleja los intereses y la experiencia de muchos participantes, toma la iniciativa y el liderazgo. Pero debe notarse que no todos los est谩ndares formales se vuelven exitosos.

El proceso de crear un est谩ndar es casi tan importante como el est谩ndar mismo. Procesando la idea inicial, una invitaci贸n a discutir personas con un conocimiento, experiencia y casos de uso m谩s amplios, todo esto ayuda a crear algo m谩s 煤til para un p煤blico amplio. Sin embargo, el proceso de estandarizaci贸n no siempre es f谩cil. Hay dificultades y obst谩culos. A veces, un proceso lleva tanto tiempo que el resultado ya no es relevante.

Cada organizaci贸n que define est谩ndares generalmente tiene su propio proceso, enfocado en su campo de actividad y participantes. Explicar todos los detalles de c贸mo funciona el IETF est谩 m谩s all谩 del alcance de este art铆culo. Si est谩 interesado, la p谩gina "C贸mo trabajamos" en el sitio web del IETF es un excelente punto de partida. Como de costumbre, la mejor manera de resolverlo es participar usted mismo. Lo suficiente como para unirse a la lista de correo o discusi贸n en el repositorio de GitHub apropiado.

C贸digo de trabajo de Cloudflare


Cloudflare se enorgullece de ser uno de los primeros en introducir nuevos protocolos, como fue el caso de HTTP / 2 y otras tecnolog铆as. Tambi茅n probamos caracter铆sticas experimentales y a煤n no aprobadas, como TLS 1.3 y SPDY .

Ejecutar c贸digo real lo ayuda a comprender qu茅 tan bien funcionar谩 el protocolo en la pr谩ctica. Combinamos el conocimiento experto con informaci贸n experimental para ayudar a mejorar el c贸digo y, cuando tenga sentido, informar problemas o mejoras a un grupo de trabajo que estandariza el protocolo.

Probar las innovaciones no es la 煤nica prioridad. Un verdadero innovador siempre sabe cu谩ndo posponer la innovaci贸n hasta tiempos mejores. Esto a veces se aplica a los protocolos orientados a la seguridad: por ejemplo, Cloudflare deshabilit贸 SSLv3 de forma predeterminada debido a la vulnerabilidad POODLE. En otros casos, los protocolos son reemplazados por otros tecnol贸gicamente m谩s avanzados: por ejemplo, reemplazamos SPDY con HTTP / 2 .

La activaci贸n y desactivaci贸n de protocolos en Cloudflare est谩 representada por l铆neas naranjas . Los puntos de referencia verticales ayudan a correlacionar los eventos de Cloudflare con documentos IETF relacionados. Por ejemplo, Cloudflare introdujo el soporte TLS 1.3 en septiembre de 2016, y el RFC 8446 final se public贸 casi dos a帽os despu茅s, en agosto de 2018.



Refactorizaci贸n: HTTPbis


HTTP / 1.1 es un protocolo muy exitoso. El gr谩fico no muestra la actividad particular del IETF despu茅s de 1999. Pero en realidad, a帽os de uso activo del protocolo dieron experiencia y revelaron problemas ocultos de RFC 2616, incluidos algunos problemas de compatibilidad. Adem谩s, el protocolo ha sido ampliado por otros RFC, como 2817 y 2818. Como resultado, en 2007 se decidi贸 iniciar actividades para mejorar la especificaci贸n HTTP. Se llama HTTPbis (donde "bis" viene de la palabra latina "dos", "dos veces" o "repetir"). La carta inicial del nuevo grupo de trabajo describe bien los problemas que estaba tratando de resolver.

En general, HTTPbis ha comenzado a refactorizar RFC 2616 . Incluye correcciones de errores e implementaci贸n de algunos aspectos de otras especificaciones que se publican al mismo tiempo. Se decidi贸 dividir el documento en partes. Como resultado, se publicaron seis borradores en diciembre de 2007:

  • draft-ietf-httpbis-p1-messaging
  • draft-ietf-httpbis-p2-sem谩ntica
  • draft-ietf-httpbis-p4-conditional
  • draft-ietf-httpbis-p5-range
  • draft-ietf-httpbis-p6-cache
  • draft-ietf-httpbis-p7-auth



El diagrama muestra c贸mo progres贸 el trabajo durante un largo proceso de desarrollo de siete a帽os. Antes de la estandarizaci贸n final, se adoptaron 27 borradores. En junio de 2014, se lanz贸 la llamada serie RFC 723x (donde x var铆a de 0 a 5). El presidente del grupo de trabajo HTTPbis se帽al贸 este logro con la frase "RFC2616 est谩 muerto" . Si alguien no entendi贸, los nuevos documentos fueron enviados al archivo del antiguo RFC 2616 .

驴Qu茅 tiene esto que ver con HTTP / 3?


Mientras el IETF estaba finalizando el RFC 723x, el mundo no se detuvo. La gente continu贸 expandi茅ndose y complementando HTTP. Entre ellos est谩n los ingenieros de Google, que comenzaron a experimentar con su propio protocolo llamado SPDY (pronunciado "r谩pido"). Dijeron que este protocolo acelera la carga de p谩ginas web, que es una caracter铆stica esencial de HTTP. A finales de 2009, se anunci贸 la primera versi贸n, y en 2010 apareci贸 r谩pidamente SPDY v2.

No quiero entrar en detalles t茅cnicos de SPDY, pero es importante entender que SPDY tom贸 los paradigmas b谩sicos de HTTP y cambi贸 ligeramente el formato de intercambio para la optimizaci贸n. Mirando hacia atr谩s, vemos que HTTP tiene una clara distinci贸n entre sem谩ntica y sintaxis. La sem谩ntica describe el concepto de intercambio de solicitudes y respuestas, incluidos m茅todos, c贸digos de estado, campos de encabezado (metadatos) y cuerpos (datos 煤tiles). La sintaxis describe c贸mo asignar la sem谩ntica a bytes en la red.

HTTP / 0.9, 1.0 y 1.1 tienen mucha sem谩ntica com煤n. Tambi茅n usan una sintaxis com煤n en forma de cadenas de caracteres enviadas a trav茅s de conexiones TCP. SPDY tom贸 la sem谩ntica de HTTP / 1.1 y cambi贸 la sintaxis a binaria. Este es un tema realmente interesante, pero hoy no profundizaremos en este agujero de conejo.

Los experimentos con SPDY han demostrado que cambiar la sintaxis HTTP realmente tiene efecto. Al mismo tiempo, es importante mantener la sem谩ntica existente. Por ejemplo, guardar el formato de URL para usar https:// evit贸 muchos problemas que podr铆an afectar la implementaci贸n de HTTPS.

Despu茅s de ver algunos resultados positivos, el IETF decidi贸 que era hora de considerar las opciones para HTTP / 2.0. Las diapositivas de la sesi贸n HTTPbis durante la reuni贸n IETF 83 en marzo de 2012 indican los requisitos y objetivos que los desarrolladores se fijaron. Establece claramente: "HTTP / 2.0 solo significa que el protocolo de transporte (formato de cable) no es compatible con HTTP / 1.x"



Durante esta reuni贸n, se invit贸 a la comunidad a expresar sus ideas. Los borradores presentados inclu铆an el borrador-mbelshe-httpbis-spdy-00 , el borrador-montenegro-httpbis-speed-mobility-00 y el borrador-tarreau-httpbis-network-friendly-00 . Al final, el borrador SPDY fue aceptado, y en noviembre de 2012 se comenz贸 a trabajar en draft-ietf-httpbis-http2-00 . Despu茅s de 18 borradores, RFC 7540 - HTTP / 2 apareci贸 en poco m谩s de dos a帽os. Para 2015, la sintaxis de HTTP / 2 hab铆a sido exactamente suficiente para hacer que HTTP / 2 y SPDY sean incompatibles.

Estos a帽os se han convertido en un per铆odo muy estresante para los grupos de trabajo que refactorizaron simult谩neamente HTTP / 1.1 y adoptaron HTTP / 2. Esto contrasta fuertemente con a帽os de calma a principios de la d茅cada de 2000. Aseg煤rese de revisar el cladograma completo para apreciar realmente la cantidad de trabajo realizado.

A pesar de la estandarizaci贸n de HTTP / 2, los experimentos con SPDY siguen siendo 煤tiles. Cloudflare introdujo el soporte SPDY en agosto de 2012 y lo elimin贸 solo en febrero de 2018, cuando nuestras estad铆sticas mostraron que menos del 4% de los clientes web lo solicitan. Mientras tanto, poco despu茅s de la publicaci贸n del RFC en diciembre de 2015, introdujimos el soporte HTTP / 2, cuando el an谩lisis mostr贸 un apoyo significativo para los clientes web.

Los protocolos SPDY y HTTP / 2 usan TLS por defecto. La introducci贸n de SSL universal en septiembre de 2014 nos permiti贸 garantizar que todos los usuarios de Cloudflare utilizar谩n los nuevos protocolos a medida que se introduzcan.

gQUIC


Google continu贸 experimentando y hasta 2015 lanz贸 otra versi贸n de SPDY v3 y v3.1. Tambi茅n comenzaron a trabajar en el protocolo gQUIC, cuyo primer borrador se public贸 a principios de 2012.

Las versiones anteriores de gQUIC usaban la sintaxis HTTP SPDY v3. Esta elecci贸n ten铆a sentido porque HTTP / 2 a煤n no ha sido aprobado. La sintaxis binaria SPDY se empaqueta en paquetes QUIC que se env铆an en datagramas UDP. Esta es una desviaci贸n del transporte TCP en el que HTTP ha dependido tradicionalmente. Todo el sistema de ensamblaje se ve铆a as铆:


Pastel en capas SPDY de gQUIC

GQUIC utiliz贸 trucos para aumentar el rendimiento. Una de ellas es difuminar la l铆nea clara entre la aplicaci贸n y el transporte. En la pr谩ctica, esto significa que gQUIC solo admite HTTP. Esta conexi贸n era tan fuerte que gQUIC, que en ese momento se llamaba QUIC, era visto como candidato para la pr贸xima versi贸n de HTTP. Aunque se hicieron muchos cambios a QUIC en el futuro, hasta el d铆a de hoy, muchas personas creen que solo es compatible con HTTP. Desafortunadamente, esto lleva a una confusi贸n constante cuando se discute el protocolo.

gQUIC continu贸 evolucionando y finalmente cambi贸 a una sintaxis mucho m谩s cercana a HTTP / 2. Tan cerca que la mayor铆a de la gente comenz贸 a llamarlo "HTTP / 2 by QUIC". Pero debido a limitaciones t茅cnicas, aparecieron algunas diferencias muy sutiles. Un ejemplo es la serializaci贸n e intercambio de encabezados HTTP. Esta es una diferencia menor, pero en la pr谩ctica significa que gQUIC HTTP / 2 no es compatible con IETF HTTP / 2.

Por 煤ltimo, pero no menos importante, siempre debe considerar los aspectos de seguridad de los protocolos de Internet. Y los desarrolladores de gQUIC decidieron abandonar TLS en favor de otro enfoque llamado QUIC Crypto. Una de las innovaciones interesantes es que hay un nuevo m茅todo para acelerar los apretones de manos. Despu茅s de establecer una sesi贸n segura con el servidor, el cliente puede reutilizar la informaci贸n y corregir el tiempo "cero" del protocolo de enlace, es decir, 0-RTT. Este truco se incluy贸 m谩s tarde en el protocolo TLS 1.3.

驴Puedo finalmente descubrir qu茅 es HTTP / 3?


Casi.

Ahora entendemos c贸mo funciona la estandarizaci贸n. Entonces, la consideraci贸n de gQUIC fue de acuerdo con el mismo escenario. En junio de 2015, se present贸 el primer borrador draft-tsvwg-quic-protocol-00 , titulado 鈥淨UIC: transporte seguro y confiable basado en UDP para HTTP / 2鈥. Pero no olvide que, al final, la sintaxis del protocolo es casi compatible con HTTP / 2.

Google ha anunciado que "BoF se llevar谩 a cabo en la reuni贸n IETF 93 en Praga". Si est谩 interesado en qu茅 es BoF, consulte RFC 6771 . En resumen, BoF ( Birds of a Feather ) es una reuni贸n informal en una conferencia.



Como resultado de la discusi贸n con el IETF, se decidi贸 que QUIC tiene muchas ventajas a nivel de transporte, debe separar este protocolo de HTTP y reintroducir una separaci贸n clara entre las capas. Adem谩s, para este protocolo, decidieron devolver el protocolo de enlace basado en TLS (lo cual no es tan malo, porque para ese momento TLS 1.3 con el esquema 0-RTT ya hab铆a sido desarrollado).

Aproximadamente un a帽o despu茅s, en 2016, se lanz贸 un nuevo conjunto de borradores:


Aqu铆 es donde volvi贸 a surgir la confusi贸n: draft-shade-quic-http2-mapping-00 se llama "HTTP / 2 Semantics Using the QUIC Transport Protocol" y describe "HTTP / 2 Semantic Mapping over QUIC". Sin embargo, este es el nombre incorrecto. La esencia de HTTP / 2 es cambiar la sintaxis mientras se mantiene la sem谩ntica. Adem谩s, "HTTP / 2 by gQUIC" nunca ha sido una descripci贸n precisa de la sintaxis, por las razones que he esbozado anteriormente. Tenga esto en cuenta cuando se familiarice con eventos futuros.

Esta versi贸n de QUIC de IETF deber铆a convertirse en un protocolo de transporte completamente nuevo. Esta es una empresa seria, por lo que el IETF trat贸 de evaluar el inter茅s en el proyecto por parte de sus miembros. Para hacer esto, en la reuni贸n del IETF 96 en Berl铆n en 2016, se llev贸 a cabo una sesi贸n de BoF ( diapositivas ). Tuve la suerte de asistir personalmente a la reuni贸n, que atrajo a cientos de participantes, como lo demuestra la fotograf铆a de Adam Roach . Como resultado, se lleg贸 a un consenso: QUIC ser谩 adoptado y estandarizado por el IETF.

El primer borrador de IETF QUIC draft-ietf-quic-http-00 para traducir HTTP a un transporte QUIC simplific贸 l贸gicamente el nombre del protocolo a "HTTP sobre QUIC" (HTTP sobre QUIC). Desafortunadamente, el trabajo no se complet贸, por lo que se utilizaron diferentes t茅rminos HTTP / 2 en toda la organizaci贸n. Mike Bishop, el nuevo editor de repositorio de borrador est谩ndar, vio el problema y comenz贸 a corregir referencias HTTP / 2 incorrectas. En la pr贸xima versi贸n del protocolo, la descripci贸n cambi贸 a "mapeo de la sem谩ntica HTTP sobre QUIC".

Poco a poco, con el tiempo y las versiones m谩s recientes, el t茅rmino "HTTP / 2" comenz贸 a usarse con menos frecuencia, si fuera necesario, simplemente apuntando a RFC 7540 . Dos a帽os despu茅s, en octubre de 2018, se lanz贸 la decimos茅ptima versi贸n del borrador (n煤mero 16). Aunque el protocolo HTTP sobre QUIC se parece a HTTP / 2, es esencialmente una sintaxis HTTP independiente e incompatible. Sin embargo, para las personas que no supervisan de cerca el trabajo del IETF (y este es un porcentaje muy grande de la poblaci贸n mundial), el t铆tulo del documento no refleja esta diferencia. Una de las principales tareas de estandarizaci贸n es la promoci贸n de la comunicaci贸n y la interoperabilidad. Y algo tan simple como nombrar se ha convertido en la principal causa de confusi贸n en la comunidad.

Recordemos lo que se dijo en 2012: "HTTP / 2.0 solo significa que el formato no es compatible con HTTP / 1.x para el transporte". El IETF ha seguido este precedente. Despu茅s de mucha discusi贸n antes y durante la conferencia IETF 103, todav铆a se lleg贸 a un consenso sobre el cambio de nombre de "HTTP sobre QUIC" a HTTP / 3.

El mundo ha mejorado y podemos pasar a discusiones m谩s importantes.

隆Pero RFC 7230 y 7231 no est谩n de acuerdo con su definici贸n de sem谩ntica y sintaxis!


A veces los nombres de los documentos pueden ser confusos. Estos son los documentos HTTP que describen la sintaxis y la sem谩ntica:

  • RFC 7230 - Protocolo de transferencia de hipertexto (HTTP / 1.1): sintaxis y enrutamiento de mensajes
  • RFC 7231 - Protocolo de transferencia de hipertexto (HTTP / 1.1): sem谩ntica y contenido

Con tales nombres, se puede suponer que la sem谩ntica fundamental de HTTP es espec铆fica de una versi贸n espec铆fica de HTTP, es decir, HTTP / 1.1. Pero este es un efecto secundario aleatorio del 谩rbol geneal贸gico HTTP. La buena noticia es que el grupo de trabajo HTTPbis est谩 tratando de resolver el problema. Algunos valientes miembros del WG comenzaron otra ronda de revisi贸n del documento. Este trabajo est谩 en marcha en este momento y se conoce como el trabajo HTTP Core (es posible que haya escuchado sobre este grupo de trabajo bajo los nombres HTTPtre o HTTPter: aqu铆 tambi茅n todo es ambiguo). Sus esfuerzos le permitir谩n comprimir seis borradores a tres:

  • Sem谩ntica HTTP (draft-ietf-httpbis-semantics)
  • Cach茅 HTTP (draft-ietf-httpbis-caching)
  • Sintaxis y enrutamiento de mensajes HTTP / 1.1 (draft-ietf-httpbis-messaging)

Como parte de este nuevo marco, se hace m谩s evidente que HTTP / 2 y HTTP / 3 son definiciones sint谩cticas para la sem谩ntica general de HTTP. Esto no significa que no tengan sus propias funciones fuera de la sintaxis, pero esto deber铆a ayudar en la discusi贸n posterior.

Poniendo todo junto


Este art铆culo ha descrito superficialmente el proceso de estandarizaci贸n HTTP en el IETF durante las 煤ltimas tres d茅cadas. Sin tocar particularmente los detalles t茅cnicos, trat茅 de explicar c贸mo llegamos ahora a HTTP / 3. Si se perdi贸 el medio y busc贸 la esencia en una frase, aqu铆 est谩: HTTP / 3 es solo una nueva sintaxis HTTP que funciona en IETF QUIC, un transporte multiplexado y seguro basado en UDP . Hay muchos matices t茅cnicos interesantes, pero hay que posponerlos para otro momento.

Examinamos los pasos importantes en el desarrollo de HTTP y TLS, pero por separado el uno del otro. Ahora al final del art铆culo estamos publicando el cladograma completo nuevamente. Puede estudiarlo con calma y cuidado en un ambiente c贸modo. Y para los supersisteners: aqu铆 hay una versi贸n absolutamente completa, que incluye borradores .

Source: https://habr.com/ru/post/438810/


All Articles