Posted on: September 21, 2020 08:04 PM

Posted by: Renato

Categories: PHP nginx

Views: 611

HTTP/3, QUIC

Temos o prazer de anunciar a prévia da tecnologia do QUIC + HTTP / 3 para NGINX em um repositório de código aberto especial . Este é um software de pré-lançamento, baseado no rascunho IETF QUIC e é mantido em um ramo de desenvolvimento, isolado dos ramos estável e principal. O lançamento é o culminar de vários meses de desenvolvimento inicial e agora está pronto para testes de interoperabilidade, feedback e contribuições de código.

Um site de demonstração habilitado com a implementação NGINX QUIC + HTTP / 3 está disponível em https://quic.nginx.org/ .

Compreendendo HTTP/3

Neste mundo acelerado, o protocolo de transferência de hipertexto (HTTP) tem sido uma constante estável por mais de duas décadas. O padrão HTTP / 1.1 foi publicado em 1999 e se tornou o protocolo de transporte onipresente para aplicativos da web e APIs. O protocolo permaneceu o mesmo ao longo dos próximos 21 anos, apesar das grandes mudanças nos aplicativos e serviços que ele é usado para transportar.

Neste ponto, o leitor astuto pode estar perguntando, “mas e quanto ao HTTP / 2?”. Esta é uma pergunta muito boa. O padrão HTTP / 2 foi publicado em 2015 e teve uma adoção constante a ponto de  45% dos sites voltados para a Internet suportarem HTTP / 2 . No entanto, essa estatística desmente a realidade de que o uso de HTTP é bastante diferente na Internet pública em comparação com a “ última milha ” (a infraestrutura de tempo de execução).

A realidade da infraestrutura moderna da Internet é que o HTTP / 2 raramente é implantado de ponta a ponta. Ele é projetado para resolver problemas que se manifestam mais claramente na Internet pública, onde a latência é imprevisivelmente alta e problemas com uma solicitação HTTP podem atrasar solicitações subsequentes . Dentro do ambiente de tempo de execução do aplicativo - por exemplo, uma nuvem pública ou um data center privado - a latência é baixa, a confiabilidade da rede é excelente e a capacidade de inspecionar diretamente o fluxo de transporte baseado em texto do HTTP / 1.1 é mais valioso do que a eficiência de Fluxo de transporte binário do HTTP / 2.

O HTTP / 2 melhorou amplamente a experiência do usuário em navegadores e dispositivos móveis, porque é bem adequado ao ambiente entre o cliente e a “extremidade” da infraestrutura de tempo de execução. Nesse ponto, ele normalmente é enviado por proxy para um ambiente de tempo de execução onde HTTP / 1.1 é usado. É mais provável que a borda seja um provedor de CDN ou um balanceador de carga de proxy reverso que lida com o tráfego que entra no ambiente de tempo de execução.

Essa abordagem híbrida de usar HTTP / 2 e HTTP / 1.1 para entregar sites e aplicativos funciona bem. Então, por que propor outro novo protocolo, HTTP / 3?

A principal inovação do HTTP / 2 é multiplexar várias solicitações HTTP em uma única conexão que usa o TCP como o transporte de baixo nível. Infelizmente, o TCP tem limitações inerentes que restringem o desempenho e a experiência do usuário em sites e aplicativos. O padrão TCP foi publicado originalmente em 1981 e tem tido um sucesso surpreendente como protocolo de transporte de uso geral. No entanto, quando você multiplexa várias solicitações independentes na mesma conexão, todas elas ficam sujeitas à confiabilidade dessa conexão. Se um pacote para apenas uma solicitação for perdido, todas as solicitações multiplexadas serão atrasadas até que o pacote perdido seja primeiro detectado e, em seguida, retransmitido.

O HTTP / 3 é baseado no protocolo de transporte QUIC , que é projetado especificamente para oferecer suporte a conexões multiplexadas sem depender de uma única conexão TCP. O QUIC, em vez disso, usa UDP como mecanismo de transporte de baixo nível para mover pacotes entre o cliente e o servidor e implementa uma conexão confiável na qual as solicitações HTTP são feitas. Notavelmente, o QUIC também incorpora TLS como um componente integral, não como uma camada adicional como com HTTP / 1.1 e HTTP / 2.

O objetivo do QUIC é fornecer um protocolo de transporte de alto desempenho, alta confiabilidade e segurança para HTTP / 3 (embora o QUIC também seja adequado para tráfego não HTTP). Semanticamente falando, o HTTP / 3 em si é muito semelhante ao HTTP / 2. No entanto, não há versão explícita de HTTP - https://www.example.com pode oferecer suporte a um ou mais HTTP / 1.1, HTTP / 2 e HTTP / 3. Como os clientes (navegadores da web) sabem qual versão de HTTP usar?

O problema de controle de versão surgiu pela primeira vez com a introdução do HTTP / 2, que o resolveu usando o handshake TLS para detectar se o cliente e o servidor são capazes de se comunicar por HTTP / 2. Dessa forma, o cliente sabe como se comunicar com o servidor antes mesmo de a conexão ser estabelecida. No entanto, o uso de UDP pelo QUIC em vez de TCP como protocolo de transporte subjacente apresenta um novo desafio - como o cliente sabe que tipo de conexão solicitar inicialmente, TCP ou UDP? A solução é o cliente estabelecer uma conexão TCP para a solicitação HTTP inicial. A resposta de um servidor compatível com HTTP / 3 inclui o cabeçalho para especificar a porta UDP na qual está escutando o tráfego HTTP / 3. Além disso, o navegador se lembra de quais sites apoiar QUIC para eliminar a sobrecarga do baseadaAlt-Svc Alt-Svc método de descoberta.

Visualização NGINX QUIC + HTTP / 3

Hoje anunciamos o lançamento inicial da implementação oficial do QUIC e HTTP / 3 para NGINX, o http_v3_module. Esta é uma prévia da tecnologia e deve ser considerada experimental - não é para uso em produção. No momento em que este artigo foi escrito, o padrão QUIC ainda não foi finalizado e esta versão inicial foi implementada em um subconjunto do rascunho atual.

Após vários meses de design e desenvolvimento, o http_v3_module está pronto para testes de interoperabilidade. Também agradecemos feedback geral e contribuições de código. Observe que o http_v3_module não está disponível no ramo de desenvolvimento da linha principal de código-fonte aberto do NGINX (nem em qualquer versão do NGINX Plus); porque ainda é experimental, está em um branch de desenvolvimento dedicado em https://hg.nginx.org/nginx-quic .

Observe também que esta implementação QUIC + HTTP / 3 é totalmente nova e não está relacionada ao patch fornecido pela Cloudflare como parte de seu projeto quiche .

Para aqueles familiarizados com as configurações NGINX, habilitar o QUIC + HTTP / 3 é bastante simples.

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 http3 reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'quic=":443"'; # Advertise that QUIC is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

Para obter mais informações sobre como construir o NGINX a partir do repo nginx-quic e a configuração recomendada, consulte o README . Além disso, um site de demonstração com o http_v3_module habilitado está disponível em https://quic.nginx.org/ . A partir daqui, você pode verificar se o seu navegador já oferece suporte a QUIC e comparar a interoperabilidade HTTP / 3 com sua própria construção do nginx-quic . Dado o status de rascunho do QUIC, você pode precisar usar versões de desenvolvimento ou as compilações mais recentes dos navegadores comuns para habilitar uma conexão QUIC.

Running

Once built, NGINX can be configured to accept incoming HTTP/3 connections by adding the quic and reuseport options to the listen configuration directive.

Here is a minimal configuration example that you can start from:

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        
        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-23=":443"; ma=86400';
    }
}

This will enable both HTTP/2 and HTTP/3 on the TCP/443 and UDP/443 ports respectively.

O Que É HTTP/3 – A Verdade Sobre o Novo Protocolo Baseado em UDP

Em novembro de 2018, a Internet Engineering Task Force (IETF) se reuniu em Bangkok e um novo Internet Draft foi adotado. O protocolo de transporte QUIC, sucessor do HTTP/2, foi renomeado para HTTP/3. O HTTP/3 é baseado em UDP e já está sendo usado por empresas importantes na Internet, como Google e Facebook. Se você está usando o Chrome e se conectando a um serviço Google, provavelmente já está utilizando QUIC.

A nova versão do protocolo HTTP se beneficia de um protocolo bare-metal e de UDP de baixo nível, e define muitos dos novos recursos que estavam, em versões prévias do HTTP, na camada TCP. Isso oferece uma forma de resolver restrições dentro da infraestrutura de Internet existente.

Os primeiros resultados são promissores e quanto a Internet Draft da IETF expirar, em junho de 2019, podemos esperar que o HTTP/3 seja promovido como a nova e terceira geração do padrão HTTP.

Assim como com o HTTP/2, HTTP/3 novamente se baseará nessas conquistas para ajudar a acelerar a web. 🚀

HTTP/3 Está Chegando

Alguns dizem que a fome da indústria da web por mais velocidade e menor latência só é correspondida pela fome do Google Chrome por memória RAM.

Em 2016, publicamos um artigo sobre HTTP/2, um padrão que, de acordo com a W3Techs, tem uma taxa de adoção mundial de cerca de 34% atualmente. E de acordo com a Can I use, ele também é suportado por todos os navegadores modernos. Ainda assim, aqui estamos nós escrevendo um artigo sobre a próxima versão do protocolo: HTTP/3.

Uso de HTTP/2

HTTP/3 até o momento em que esse artigo é escrito, a Internet Draft ou ID da IETF, o que significa que atualmente está sendo considerado para ser o próximo padrão da Internet pela Internet Engineering Task Force – um corpo de padrões de Internet internacional encarregado de definir e promover um acordo sobre padrões de protocolo de Internet, como TCP, IPv6, VoIP, Internet das Coisas, etc.

Atualmente, a fase ID do HTTP/3 é a última antes que propostas sejam feitas no nível das RFCs (Request for Comments), o que podemos considerar, para todas as intenções e finalidades, como as definições do protocolo de Internet oficial. Na sequência, elas são implementadas por todos os principais players da Internet.

Isso significa que o HTTP/3 se tornará um padrão oficial quando seu rascunho expirar mais adiante neste ano (junho de 2019).

O Que É HTTP/3 – Em Termos Leigos

Fontes:

• https://github.com/openssl/openssl/pull/8797
• https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/
• https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/)
• https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/
• https://hg.nginx.org/nginx-quic
• https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/#:~:text=Once%20built%2C%20NGINX%20can%20be,to%20the%20listen%20configuration%20directive.&text=This%20will%20enable%20both%20HTTP,and%20UDP%2F443%20ports%20respectively.
• https://kinsta.com/pt/blog/http3/

Renato

Developer

No comments yet! Be the first to comment