O protocolo da camada de aplicativos HTTP é subjacente à Internet. Começou sua vida em 1991 como HTTP / 0.9 e, em 1999, tornou-se HTTP / 1.1, padronizado pelo Internet Engineering Council (IETF).

O HTTP / 1.1 satisfez a todos por um longo tempo, mas as crescentes necessidades da Web exigiram uma atualização - e em 2015 adotou o HTTP / 2. A história não terminou aí: recentemente, a IETF anunciou uma nova versão do HTTP / 3. Para alguns, isso foi uma surpresa e causou alguma confusão. Se você não estiver monitorando o IETF, pode parecer que o HTTP / 3 veio do nada. No entanto, podemos traçar sua origem de acordo com o histórico de experimentos e a evolução dos protocolos da web, em particular o protocolo de transporte QUIC.

Se você não conhece o QUIC, meus colegas do Cloudflare abordaram vários aspectos com alguns detalhes: por exemplo, consulte artigos sobre as falhas reais do HTTP moderno e detalhes sobre o protocolo da camada de transporte . Reunimos esses e outros materiais em cloudflare-quic.com . E se você estiver interessado, não deixe de conferir a quiche : é a nossa própria implementação do QUIC, escrita em Rust com código-fonte aberto.

HTTP / 3 - tradução do protocolo de transporte QUIC para a camada de aplicação. O nome HTTP / 3 foi oficialmente aprovado apenas recentemente, na 17ª versão do rascunho ( draft-ietf-quic-http-17 ). Foi proposto no final de outubro de 2018 e foi alcançado consenso na reunião da IETF 103 em Bangcoc, em novembro.

Anteriormente, o HTTP / 3 era conhecido como HTTP pelo QUIC, e antes disso - como HTTP / 2 pelo gQUIC, e ainda mais cedo - o SPDY pelo gQUIC. Mas a conclusão é que o HTTP / 3 é apenas a nova sintaxe HTTP executada no protocolo IETF QUIC, um transporte seguro e multiplexado baseado em UDP.

Neste artigo, veremos o histórico de alguns dos nomes HTTP / 3 anteriores e apresentaremos a motivação para a alteração do sobrenome. Vamos voltar aos primeiros dias do HTTP e tudo o que aconteceu durante esse período. Se você deseja obter uma imagem completa, pode ir imediatamente para o final do artigo ou abrir esta versão muito detalhada do SVG .


Bolo HTTP / 3 Camadas

Mobiliário

Antes de focar no HTTP, vale lembrar que existem dois protocolos chamados QUIC. Como já explicamos , o gQUIC geralmente é usado como uma abreviação do Google QUIC (protocolo de origem) e o QUIC como uma versão IETF que difere do gQUIC.

Desde o início dos anos 90, as necessidades da Internet mudaram. Temos novas versões do HTTP e um novo nível de segurança na forma do protocolo TLS (Transport Layer Security). Neste artigo, abordaremos apenas o TLS e, em outros artigos do nosso blog, você poderá estudar o tópico com mais detalhes.

O histórico de HTTP e TLS não pode ser expresso com uma lista simples de datas, pois alguns ramos evoluíram em paralelo e se sobrepuseram no tempo. Quando você tenta conectar todos os pontos em quase 30 anos da história da Internet, você não pode prescindir da visualização. Então, eu fiz esse cronograma: Cloudflare Secure Web Timeline. (nota: tecnicamente, este é um cladograma , embora as pessoas estejam mais familiarizadas com a palavra "gráfico").



Por uma questão de beleza, deixei cair algumas das informações, concentrando-me apenas em ramos bem-sucedidos no espaço da IETF. Por exemplo, os esforços do grupo de trabalho HTTP-NG do consórcio W3, bem como algumas tecnologias exóticas, cuja pronúncia os autores ainda estão tentando explicar, não são mostradas aqui: HMURR (pronunciado "hummer") e WAKA (pronunciado "wah-kah").

Nas seções a seguir, examinaremos este cladograma e examinaremos alguns pontos críticos da história do HTTP. Espero que isso ajude a entender por que a padronização é benéfica para todos e como a IETF aborda esse problema. Portanto, começamos com uma breve visão geral do tópico antes de retornar ao próprio cronograma. Sinta-se livre para pular a próxima seção, se você já estiver familiarizado com o IETF.

Tipos de padrão da Internet

Normalmente, os padrões definem competência geral, escopo, limitações, aplicabilidade e outras considerações. Os padrões existem em várias formas e tamanhos. Eles podem ser informais (padrão de fato) ou formais (acordados / publicados por uma organização que define padrões, como IETF, ISO ou MPEG). Os padrões são usados ​​em muitas áreas; existe até um padrão britânico formal para fazer chá - BS 6008.

As primeiras definições de protocolo HTTP e SSL foram publicadas fora da IETF: elas são marcadas com linhas vermelhas no gráfico. Mas o uso generalizado os tornou padrões de fato.

Em algum momento, eles decidiram formalizar esses protocolos (alguns motivos são descritos abaixo). Os padrões da Internet são geralmente definidos na IETF, que é guiada pelo princípio não oficial de “consenso exemplar e código atual” com base em aplicativos da vida real na Internet. Isso é diferente da abordagem da sala limpa quando alguém está tentando desenvolver protocolos ideais no vácuo.

Os padrões IETF são comumente conhecidos como RFCs. É difícil de explicar brevemente, portanto, recomendo o artigo "Como ler a RFC" do co-presidente do grupo de trabalho QUIC Mark Nottingham. Um grupo de trabalho ou WG é essencialmente apenas uma lista de discussão.

A cada ano, há três reuniões para reuniões pessoais de membros de todos os grupos de trabalho, se assim o desejarem. A agenda para essas semanas pode ser muito ocupada, não há tempo suficiente para uma discussão aprofundada de questões técnicas. Portanto, alguns preferem realizar mais reuniões intermediárias entre as reuniões gerais da IETF. O grupo de trabalho QUIC realizou várias reuniões provisórias desde 2017, a lista completa está disponível na página de reuniões .

Essas reuniões têm a oportunidade de se reunir com especialistas de outras organizações, como o Internet Architecture Council (IAB) ou o Internet Technology Research Group (IRTF). Nos últimos anos, o fim de semana antes da IETF tradicionalmente realizou o hackathon da IETF . O código real é desenvolvido aqui e, principalmente, passa nos testes de compatibilidade. Isso ajuda a encontrar problemas nas especificações que podem ser discutidas diretamente na reunião.

É importante entender que os RFCs não surgem do nada. Eles passam por todo um processo. Geralmente, começa com um rascunho do IETF Internet Draft (ID), que é enviado para revisão. No caso em que a especificação já foi publicada, a preparação de um ID se tornará uma simples reformatação. A vida útil do ID é de 6 meses a partir da data de publicação. Para mantê-lo ativo, você deve publicar novas versões. Na prática, tudo bem que o código expire. Isso acontece com bastante frequência. Os documentos ainda estão armazenados no site da IETF e estão abertos a todos.

No cladograma, os rascunhos são apresentados em roxo . Cada um tem seu próprio nome no formato rascunho - {autor} - {grupo de trabalho} - {tópico} - {versão} . O campo WG é opcional, pode apontar para um futuro grupo de trabalho da IETF e, às vezes, muda. Se o ID for aprovado pela IETF ou iniciado diretamente dentro da IETF, o rascunho será chamado draft-ietf- {workgroup} - {topic} - {version} . Os IDs podem ramificar, mesclar ou desaparecer. A versão começa em 00 e aumenta a cada novo projeto em um. Por exemplo, o quarto rascunho receberá o número da versão 03. Cada vez que o nome do ID é alterado, sua versão é redefinida para 00.

É importante observar que qualquer pessoa pode enviar seu rascunho à IETF: eles não podem ser considerados como padrões. Mas se o processo de padronização chegar a um consenso e o documento final passar no teste, obteremos uma RFC. Neste ponto, o nome muda novamente. Cada RFC recebe um número exclusivo, como o RFC 7230 . Os documentos com esse status são mostrados como linhas azuis .

É proibido alterar a RFC. Ou seja, alterações na RFC exigem a adoção de um documento com um novo número. As alterações são permitidas apenas para correção de erros técnicos ou editoriais ou para otimização simples do layout. Os novos RFCs podem substituir completamente os antigos ou complementá-los.

Todos os documentos da IETF estão disponíveis ao público em http://tools.ietf.org . Pessoalmente, parece-me um pouco mais conveniente que o Datatracker da IETF , porque o caminho do documento de ID para RFC é exibido visualmente lá.

Abaixo está um exemplo que mostra o desenvolvimento do padrão RFC 1945 , ou seja, HTTP / 1.0.


História da RFC 1945 na interface do IETF Datatracker

Curiosamente, no decorrer do trabalho, descobri que a visualização acima está incorreta. Por algum motivo, draft-ietf-http-v10-spec-05 está ausente. Como o ID tem 6 meses, provavelmente expirou antes da adoção da RFC, embora, na realidade, o rascunho estivesse ativo até agosto de 1996.

Estudando um cladograma

Após uma breve introdução teórica, podemos começar a estudar o cladograma. Esta seção apresenta alguns trechos com as partes mais importantes. Cada ponto indica a data em que o documento ou função foi fornecido. Para maior clareza, os documentos IETF omitiram os números dos projetos, mas todos estão na versão completa .

O HTTP apareceu em 1991 como o protocolo HTTP / 0.9 e, em 1994, foi publicado o draft-fielding-http-spec-00 . Logo foi aceito pela IETF, como resultado do qual o nome mudou para draft-ietf-http-v10-spec-00 . Após seis edições do rascunho, o padrão RFC 1945 , HTTP / 1.0, foi adotado em 1996.



No entanto, mesmo antes da conclusão do trabalho no HTTP / 1.0, um projeto HTTP / 1.1 separado foi lançado. A versão preliminar do draft-ietf-http-v11-spec-00 foi publicada em novembro de 1995 e adotada oficialmente como RFC 2068 em 1997. Os olhos atentos perceberão que o cladograma não reflete completamente essa sequência de eventos - uma falha malsucedida da ferramenta de visualização. Tentei minimizar esses problemas sempre que possível.

Em meados de 1997, uma revisão do HTTP / 1.1 começou como draft-ietf-http-v11-spec-rev-00 . Terminou em 1999 com a publicação da RFC 2616 . Até 2007, tudo estava quieto no mundo HTTP da IETF. Voltamos a isso um pouco mais tarde.

Histórico de SSL e TLS

Voltamos nossa atenção para a trajetória do SSL. Vemos que a especificação SSL 2.0 foi lançada por volta de 1995 e o SSL 3.0 foi lançado em novembro de 1996. Curiosamente, o SSL 3.0 é aprovado na RFC 6101 , que apareceu apenas em agosto de 2011. Está localizado na seção histórica . Segundo a IETF , foi criado "para documentar idéias que foram consideradas e descartadas, ou protocolos que já existiam no momento em que foi decidido documentá-las". Nesse caso, eu precisava de um documento IETF descrevendo o SSL 3.0 para usá-lo em qualquer lugar como um link canônico.

Estamos mais interessados ​​em como os engenheiros do SSL inspiraram a desenvolver o TLS, que começou com um rascunho draft-ietf-tls-protocol-00 em novembro de 1996. Ele passou por seis versões preliminares e foi publicado como RFC 2246 - TLS 1.0 no início de 1999.

Entre 1995 e 1999, o SSL e o TLS foram usados ​​para proteger as conexões HTTP na Internet. Isso funcionou muito bem como um padrão de fato. Somente em janeiro de 1998 a padronização oficial do HTTPS começou com a publicação de um projeto de minuta-ietf-tls-https-00 . Trabalho concluído em maio de 2000 com a publicação do RFC 2616 - HTTP sobre TLS.

O TLS continuou a evoluir de 2000 a 2007, com a adoção do TLS 1.1 e 1.2. Houve uma pausa de sete anos antes do início dos trabalhos na próxima versão do protocolo TLS, que será publicado como draft-ietf-tls-tls13-00 em abril de 2014 e, após 28 rascunhos, será aprovado como RFC 8446 - TLS 1.3 em agosto de 2018.

Processo de padronização da Internet

Depois de um breve conhecimento do cladograma, espero que tenha se tornado melhor entender como o IETF funciona. Ao criar padrões, pesquisadores ou engenheiros desenvolvem protocolos experimentais para casos de uso específicos. Em vários níveis, eles experimentam protocolos públicos ou privados. As informações recebidas permitem identificar problemas ou melhorar o protocolo. A publicação do trabalho ajuda a explicar o experimento, a opinião de reunião de um círculo mais amplo de especialistas ou a encontrar ajuda de outros artistas. Se outros participantes aceitarem esse trabalho em um estágio inicial, ele se tornará o padrão de fato e, finalmente, haverá impulso suficiente para a padronização oficial.

O status oficial do protocolo é um fator importante para as organizações que pensam em usá-lo. O processo formal de padronização torna o padrão de fato mais atraente, porque geralmente fornece estabilidade. Uma organização respeitável como a IETF, que reflete os interesses e a experiência de muitos participantes, assume a liderança e a liderança. Mas deve-se notar que nem todos os padrões formais se tornam bem-sucedidos.

O processo de criação de um padrão é quase tão importante quanto o próprio padrão. Processando a ideia inicial, um convite para discutir pessoas com conhecimento, experiência e casos de uso mais amplos - tudo isso ajuda a criar algo mais útil para um amplo público. No entanto, o processo de padronização nem sempre é fácil. Existem armadilhas e obstáculos. Às vezes, um processo leva tanto tempo que o resultado não é mais relevante.

Cada organização que define padrões geralmente possui seu próprio processo, focado em seu campo de atividade e participantes. Explicar todos os detalhes de como o IETF funciona está muito além do escopo deste artigo. Se você estiver interessado, a página "Como trabalhamos" no site da IETF é um ótimo ponto de partida. Como sempre, a melhor maneira de descobrir é participar. O suficiente para ingressar na lista de discussão ou discussão no repositório GitHub apropriado.

Código de trabalho Cloudflare

A Cloudflare se orgulha de ser uma das primeiras a introduzir novos protocolos, como foi o caso do HTTP / 2 e outras tecnologias. Também testamos recursos experimentais e ainda não aprovados, como TLS 1.3 e SPDY .

A execução de código real ajuda a entender como o protocolo funcionará na prática. Combinamos conhecimento especializado com informações experimentais para ajudar a melhorar o código e, onde faz sentido, relatar problemas ou melhorias para um grupo de trabalho que padroniza o protocolo.

Testar inovações não é a única prioridade. Um verdadeiro inovador sempre sabe quando adiar a inovação para tempos melhores. Às vezes, isso se aplica a protocolos orientados à segurança: por exemplo, o Cloudflare desativou o SSLv3 por padrão devido à vulnerabilidade POODLE. Em outros casos, os protocolos são substituídos por outros tecnologicamente avançados: por exemplo, substituímos o SPDY pelo HTTP / 2 .

A ativação e desativação de protocolos no Cloudflare é representada por linhas laranja . Marcos verticais ajudam a correlacionar eventos do Cloudflare com documentos IETF relacionados. Por exemplo, o Cloudflare introduziu o suporte ao TLS 1.3 em setembro de 2016 e o RFC 8446 final foi publicado quase dois anos depois, em agosto de 2018.

Refatoração: HTTPbis

HTTP / 1.1 é um protocolo de muito sucesso. O gráfico não mostra atividade específica da IETF após 1999. Mas, na realidade, anos de uso ativo do protocolo deram experiência e revelaram problemas ocultos da RFC 2616, incluindo alguns problemas de compatibilidade. Além disso, o protocolo foi expandido por outras RFCs, como 2817 e 2818. Como resultado, em 2007, foi decidido iniciar atividades para melhorar a especificação HTTP. É chamado HTTPbis (onde "bis" vem da palavra latina "dois", "duas vezes" ou "repetir"). O estatuto inicial do novo grupo de trabalho descreve bem os problemas que estava tentando resolver.

Em geral, o HTTPbis começou a refatorar o RFC 2616 . Inclui correções de erros e implementação de alguns aspectos de outras especificações que são publicadas ao mesmo tempo. Decidiu-se dividir o documento em partes. Como resultado, seis rascunhos foram publicados em dezembro de 2007:

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

O diagrama mostra como o trabalho progrediu em um longo processo de desenvolvimento de sete anos. Antes da padronização final, 27 projetos foram adotados. Em junho de 2014, foi lançada a chamada série RFC 723x (onde x varia de 0 a 5). O presidente do grupo de trabalho HTTPbis observou essa conquista com a frase "RFC2616 está morto" . Se alguém não entendeu, os novos documentos foram enviados para o arquivo da antiga RFC 2616 .

O que isso tem a ver com HTTP / 3?

Enquanto a IETF estava finalizando o RFC 723x, o mundo não parou. As pessoas continuaram a expandir e complementar o HTTP. Entre eles estão os engenheiros do Google, que começaram a experimentar seu próprio protocolo chamado SPDY (pronunciado "veloz"). Eles disseram que esse protocolo acelera o carregamento de páginas da web, que é um recurso essencial do HTTP. No final de 2009, a primeira versão foi anunciada e, em 2010, o SPDY v2 apareceu rapidamente.

Não quero entrar em detalhes técnicos do SPDY, mas é importante entender que o SPDY adotou os paradigmas HTTP básicos e alterou levemente o formato de troca para otimização. Olhando para trás, vemos que o HTTP tem uma distinção clara entre semântica e sintaxe. Semântica descreve o conceito de troca de solicitações e respostas, incluindo métodos, códigos de status, campos de cabeçalho (metadados) e corpos (dados úteis). A sintaxe descreve como mapear a semântica para bytes na rede.

HTTP / 0.9, 1.0 e 1.1 têm muitas semânticas comuns. Eles também usam sintaxe comum na forma de seqüências de caracteres enviadas por conexões TCP. O SPDY adotou a semântica do HTTP / 1.1 e alterou a sintaxe para binário. Este é um tópico realmente interessante, mas hoje não vamos nos aprofundar nesta toca de coelho.

Experimentos com o SPDY mostraram que alterar a sintaxe HTTP realmente traz efeito. Ao mesmo tempo, é importante manter a semântica existente. Por exemplo, salvar o formato de URL para usar https:// evitou muitos problemas que poderiam afetar a implementação do HTTPS.

Depois de ver alguns resultados positivos, o IETF decidiu que era hora de considerar as opções para HTTP / 2.0. Os slides da sessão HTTPbis durante a reunião da IETF 83 em março de 2012 indicam os requisitos e as metas que os desenvolvedores definiram para si. Ele afirma claramente: "HTTP / 2.0 significa apenas que o protocolo de transporte (formato de fio) não é compatível com HTTP / 1.x"



Durante esta reunião, a comunidade foi convidada a expressar suas idéias. Os rascunhos enviados incluíram rascunho-mbelshe-httpbis-spdy-00 , rascunho-montenegro-httpbis-velocidade-mobilidade-00 e rascunho-tarreau-httpbis-network-friendly-00 . No final, o rascunho do SPDY foi aceito e, em novembro de 2012, começaram os trabalhos no draft-ietf-httpbis-http2-00 . Após 18 rascunhos, o RFC 7540 - HTTP / 2 apareceu em pouco mais de dois anos. Em 2015, a sintaxe do HTTP / 2 foi exatamente o suficiente para tornar o HTTP / 2 e o SPDY incompatíveis.

Esses anos se tornaram um período muito estressante para os grupos de trabalho que refatoraram simultaneamente o HTTP / 1.1 e adotaram o HTTP / 2. Isso contrasta fortemente com os anos de calma no início dos anos 2000. Certifique-se de verificar o cladograma completo para realmente apreciar a quantidade de trabalho realizado.

Apesar da padronização do HTTP / 2, experimentos com o SPDY ainda são úteis. O Cloudflare introduziu o suporte SPDY em agosto de 2012 e o removeu apenas em fevereiro de 2018, quando nossas estatísticas mostraram que menos de 4% dos clientes da Web o solicitam. Enquanto isso, logo após a publicação da RFC em dezembro de 2015, introduzimos o suporte HTTP / 2, quando a análise mostrou suporte significativo para clientes da Web.

Os protocolos SPDY e HTTP / 2 usam TLS por padrão. A introdução do SSL universal em setembro de 2014 nos permitiu garantir que todos os usuários do Cloudflare usem os novos protocolos à medida que forem introduzidos.

gQUIC

O Google continuou a experimentar e até 2015 lançou outra versão do SPDY v3 e v3.1. Eles também começaram a trabalhar no protocolo gQUIC, cujo primeiro rascunho foi publicado no início de 2012.

As versões anteriores do gQUIC usavam a sintaxe HTTP SPDY v3. Essa escolha fez sentido porque o HTTP / 2 ainda não foi aprovado. A sintaxe binária do SPDY é empacotada em pacotes QUIC enviados em datagramas UDP. Este é um desvio do transporte TCP em que o HTTP tradicionalmente contava. Todo o sistema de montagem ficou assim:


Torta em camadas SPDY por gQUIC

GQUIC usou truques para aumentar o desempenho. Uma delas é desfocar a linha clara entre o aplicativo e o transporte. Na prática, isso significava que o gQUIC suporta apenas HTTP. Essa conexão era tão forte que o gQUIC, que na época era chamado QUIC, era visto como candidato à próxima versão do HTTP. Embora muitas mudanças tenham sido feitas no QUIC no futuro, até hoje, muitos acreditam que ele suporta apenas HTTP. Infelizmente, isso leva a uma confusão constante ao discutir o protocolo.

O gQUIC continuou a evoluir e, eventualmente, mudou para uma sintaxe muito mais próxima do HTTP / 2. Tão perto que a maioria das pessoas começou a chamá-lo de "HTTP / 2 por QUIC". Mas devido a limitações técnicas, algumas diferenças muito sutis apareceram. Um exemplo é a serialização e troca de cabeçalhos HTTP. Essa é uma pequena diferença, mas, na prática, significa que o gQUIC HTTP / 2 não é compatível com o IETF HTTP / 2.

Por último, mas não menos importante, você deve sempre considerar os aspectos de segurança dos protocolos da Internet. E os desenvolvedores do gQUIC decidiram abandonar o TLS em favor de outra abordagem chamada QUIC Crypto. Uma das inovações interessantes é o novo método de acelerar os apertos de mão. Após estabelecer uma sessão segura com o servidor, o cliente pode reutilizar as informações e fixar o tempo "zero" do handshake, ou seja, 0-RTT. Este truque foi posteriormente incluído no protocolo TLS 1.3.

Posso finalmente descobrir o que é HTTP / 3?

Quase.

Agora entendemos como a padronização funciona. Portanto, a consideração do gQUIC ocorreu de acordo com o mesmo cenário. Em junho de 2015, o primeiro rascunho-tsvwg-quic-protocol-00 , intitulado "QUIC: Transporte Seguro e Confiável de UDP para HTTP / 2", foi introduzido. Mas não esqueça que, no final, a sintaxe do protocolo é quase compatível com HTTP / 2.

O Google anunciou que "o BoF será realizado na reunião da IETF 93 em Praga". Se você está interessado no que é o BoF, consulte a RFC 6771 . Em suma, o BoF ( Birds of a Feather ) é uma reunião informal em uma conferência.



Com base na discussão com o IETF, foi decidido que o QUIC tem muitas vantagens no nível do transporte, você deve separar esse protocolo do HTTP e reintroduzir uma separação clara entre as camadas. Além disso, para esse protocolo, eles decidiram retornar o handshake com base no TLS (o que não é tão ruim, porque naquele momento o TLS 1.3 com o esquema 0-RTT já havia sido desenvolvido).

Cerca de um ano depois, em 2016, um novo conjunto de rascunhos foi lançado:

• draft-hamilton-quic-transport-protocol-00
• draft-thomson-quic-tls-00
• draft-iyengar-quic-loss-recovery-00
• rascunho-sombra-quic-http2-mapeamento-00

É aqui que a confusão surgiu novamente: draft-shade-quic-http2-mapping-00 é chamado de "Semântica HTTP / 2 usando o protocolo de transporte QUIC" e descreve "mapeamento semântico HTTP / 2 usando QUIC". No entanto, este é o nome errado. A essência do HTTP / 2 é alterar a sintaxe, mantendo a semântica. Além disso, “HTTP / 2 por gQUIC” nunca foi uma descrição precisa da sintaxe, pelos motivos que descrevi anteriormente. Lembre-se disso quando se familiarizar com eventos futuros.

Esta versão do QUIC do IETF deve se tornar um protocolo de transporte completamente novo. Como é uma empresa séria, a IETF tentou avaliar o interesse no projeto de seus membros. Para fazer isso, na reunião da IETF 96 em Berlim em 2016, foi realizada uma sessão do BoF ( slides ). Tive a sorte de participar pessoalmente da reunião, que atraiu centenas de participantes, como evidenciado pela fotografia de Adam Roach . Como resultado, foi alcançado um consenso: o QUIC será adotado e padronizado pela IETF.

O primeiro rascunho IETF QUIC draft-ietf-quic-http-00 para converter HTTP em um transporte QUIC simplificou logicamente o nome do protocolo para "HTTP sobre QUIC" (HTTP sobre QUIC). Infelizmente, o trabalho não foi concluído, portanto, diferentes termos HTTP / 2 foram usados ​​em toda a organização. Mike Bishop, o novo editor de repositório de rascunhos padrão, viu o problema e começou a corrigir as referências HTTP / 2 incorretas. Na próxima versão do protocolo, a descrição mudou para "mapeamento da semântica HTTP sobre QUIC".

Gradualmente, com o tempo e nas versões mais recentes, o termo "HTTP / 2" começou a ser usado com menos frequência, se necessário, simplesmente apontando para a RFC 7540 . Dois anos depois, em outubro de 2018, foi lançada a décima sétima versão do rascunho (número 16). Embora o protocolo HTTP sobre QUIC seja semelhante ao HTTP / 2, é essencialmente uma sintaxe HTTP independente e incompatível. No entanto, para pessoas que não monitoram de perto o trabalho da IETF (e essa é uma porcentagem muito grande da população mundial), o título do documento não reflete essa diferença. Uma das principais tarefas da padronização é a promoção da comunicação e interoperabilidade. E uma coisa simples como nomear se tornou a principal causa de confusão na comunidade.

Lembre-se do que foi dito em 2012: "HTTP / 2.0 significa apenas que o formato não é compatível com HTTP / 1.x para transporte". O IETF seguiu esse precedente. Após muita discussão antes e durante a conferência IETF 103, ainda foi alcançado um consenso sobre a renomeação de "HTTP sobre QUIC" para HTTP / 3.

O mundo se tornou melhor e podemos avançar para discussões mais importantes.

Mas o RFC 7230 e o 7231 não concordam com sua definição de semântica e sintaxe!

Às vezes, os nomes dos documentos podem ser confusos. Aqui estão os documentos HTTP que descrevem sintaxe e semântica:

• RFC 7230 - Protocolo de transferência de hipertexto (HTTP / 1.1): sintaxe e roteamento de mensagens
• RFC 7231 - Protocolo de Transferência de Hipertexto (HTTP / 1.1): Semântica e Conteúdo

Por esses nomes, pode-se supor que a semântica fundamental do HTTP seja específica para uma versão específica do HTTP, ou seja, HTTP / 1.1. Mas este é um efeito colateral aleatório da árvore genealógica HTTP. A boa notícia é que o grupo de trabalho HTTPbis está tentando resolver o problema. Alguns bravos membros do WG começaram outra rodada de revisão do documento. Este trabalho está em andamento no momento e é conhecido como trabalho HTTP Core (você pode ter ouvido falar sobre este grupo de trabalho sob os nomes HTTPtre ou HTTPter: tudo é ambíguo aqui também). Os esforços deles permitem compactar seis rascunhos em três:

• Semântica HTTP (draft-ietf-httpbis-semtics)
• Armazenamento em cache HTTP (draft-ietf-httpbis-caching)
• Sintaxe e roteamento de mensagens HTTP / 1.1 (draft-ietf-httpbis-messaging)

Como parte dessa nova estrutura, fica mais evidente que HTTP / 2 e HTTP / 3 são definições sintáticas para a semântica geral do HTTP. Isso não significa que eles não tenham suas próprias funções fora da sintaxe, mas isso deve ajudar na discussão adicional.

Juntando tudo

Este artigo descreveu superficialmente o processo de padronização HTTP no IETF nas últimas três décadas. Sem tocar particularmente nos detalhes técnicos, tentei explicar como chegamos ao HTTP / 3. Se você perdeu o foco e procurou a essência em uma frase, aqui está: HTTP / 3 é apenas uma nova sintaxe HTTP que funciona no IETF QUIC, um transporte seguro e multiplexado baseado em UDP . Existem muitas nuances técnicas interessantes, mas você deve adiá-las por outro tempo.

Examinamos as etapas importantes no desenvolvimento de HTTP e TLS, mas separadamente um do outro. Agora, no final do artigo, estamos publicando o cladograma completo novamente. Você pode estudá-lo com calma e cuidado em um ambiente confortável. E para supersisteners: aqui está uma versão absolutamente completa, incluindo rascunhos .