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 ​​en 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 “QUIC: 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:

• proyecto-protocolo-de-transporte-de-hamilton-00
• draft-thomson-quic-tls-00
• draft-iyengar-quic-loss-recovery-00
• draft-shadow-quic-http2-mapping-00

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 .