HTTP/3 já está a caminho da Internet e deixará o protocolo TCP de fora
Estão a chegar novidades ao mundo da Internet, mais concretamente ao nível do protocolo HTTP (Protocolo de Transferência de Hipertexto).
Com o novo standard HTTP/3, as comunicações serão mais rápidas e seguras graças ao protocolo QUIC. Vamos conhecer mais alguns pormenores do novo protocolo.
O HTTP é um protocolo utilizado para transferência de informação através de uma rede de dados. Este protocolo é utilizado para que a informação possa ser trocada entre servidores, computadores, dispositivos móveis, de uma forma universal e rápida.
O HTTP 2.0 foi aprovado em 2015, 16 anos depois da primeira versão. Para substituir o HTTP/2 está já a caminho o HTTP/3 (conhecido como HTTP-over-QUIC) que deixará de fora o protocolo TCP.
O TCP é o protocolo mais usado, isto porque fornece garantia na entrega de todos os pacotes entre um PC emissor e um PC recetor. No estabelecimento de ligação entre emissor e recetor existe um "pré-acordo" denominado de Three Way Handshake (SYN, SYN-ACK, ACK).
- A sessão entre um cliente e um servidor é sempre iniciada pelo cliente, que envia um pedido de ligação pacote com a flag SYN ativada;
- O cliente envia também um número sequencial aleatório;
- O servidor responde com um pacote SYN-ACK com o seu próprio número sequencial aleatório e um número de confirmação (igual ao número sequencial do cliente +1);
- Para finalizar, o cliente responde com um pacote ACK com o número de confirmação (igual ao número de sequência do servidor +1).
Para saber mais sobre o Three Way Handshake aceda aqui.
Considerem, por exemplo, que querem transmitir um filme ou um ficheiro com um jogo que ocupa 800 MB. Esse ficheiro terá de ser partido em partes mais pequenas (fragmentação), para que seja viável a sua transferência para outro PC.
Recorrendo ao protocolo TCP, existe a garantia que todos os pacotes serão entregues e ordenados do outro lado (uma vez que podem seguir caminhos diferentes). Além disso, por cada pacote ou conjunto de pacotes (previamente definido), a máquina de destino confirma que recebeu essa informação ao emissor e, no caso de falha de algum pacote, a máquina de destino procede ao emissor o pedido de retransmissão do(s) pacote(s) em falta. Saber mais aqui.
Sai o TCP entra o QUIC
Com a "saída" do TCP, o HTTP irá recorrer ao protocolo QUIC (Quick UDP Internet Connections)! Este novo protocolo, desenvolvido pela Google, mistura conceitos de HTTP/2, TCP, UDP e TLS, e substituirá o TCP na camada de transporte de dados.
Na prática, o protocolo QUIC é mais rápido, ao conseguir reduzir significativamente a latência das comunicações, recorre à multiplexagem de ligações e faz uso do protocolo UDP. Além disso, este protocolo garante a segurança das comunicações uma vez que usa o protocolo TLS 1.3.
Desde o Chrome 29 e do Opera 16 que existe suporte para o HTTP-over-QUICK. Os serviços da Google, no geral, já suportam ligações HTTP-sobre-QUIC. Este ano o Facebook também começou a adotar esta nova tecnologia de comunicação.
Leia também...
Este artigo tem mais de um ano
Cheira-me que vai dar esturro recuperar uma ligação segura sem nova renovação.
Abc
O UDP não é fire and forget? Ou seja, dispara pacotes sem confirmação da chegada e error checking? xD
também estava a pensar nisso. Para uma visualização boa de uma página web não pode haver perda de pacotes, e o UDP não verifica isso.
Sim é
Tambem fiquei com a mesma dúvida. Segundo pesquisa rapida “Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol’s evolution.”
Correto.
Mas porquê – nos dias de hoje – apostar na prevenção (dando carga de processamento a isso mesmo) quando provavelmente já temos motivos para sermos optimistas e acreditar que chega tudo (ou quase tudo).
Se a taxa de sucesso de entrega for de 99,99% não é melhor reagir do que prevenir?
mas podes contruir essa confirmação por cima. Eu no passado fazia isso para não ter uma conexão sempre activa.
Estou a perceber. Fica ao nível do software em vez de ser ao nível do hardware. Mas não sei se vai dar ao mesmo. Se de facto o software for fazer verificação de erros, não terá impacto negativo na performance em termos de memória e cpu? Ou será que as placas de rede usam também o CPU para “trabalhar” os erros no TCP/IP? 😐
Temos de fazer algo aos nossos websites? Ou estas mudancas só acontecem nos browsers?
Preciso de actualizar algo no meu website?
Obrigado
Tens de ser atualizarldo o servidor onde tens o teu blog alojado. O Apache ou o software usado tem de ter suporte.
Do lado do browser esta atualização é automática, desde que vás atualizando o browser.
Obrigado
Esperava mais informações no artigo sobre este novo protocolo.
Fica a sugestão.
Os downloads devem ser pimpões com UDP :3
…
https://tools.ietf.org/html/draft-ietf-quic-transport-16
Acho que este link estava em falta. O artigo tem links para os protocolos existentes, mas não tinha a indicar um bom com a informação do novo.
Obrigado
Gostei!
Só lamento que a maior parte do artigo seja a falar da tecnologia que deixará de ser usar (http over tcp)
Gostei da parte: “desenvolvido pela Google”
A explicação sobre o protocolo TCP está bem resumida mas a do QUIC não está muito detalhada.
Também se poderia ter mencionado que o TCP faz controlo de fluxo, isto significa isto que quando é detectado que o cliente está com a ligação congestionada a taxa de envio de pacotes é abrandada para evitar perdas.
Já o prodocolo UDP não faz este tipo de controlo, a taxa de envio é sempre a mesma.
Isto pode levar a que alguns pacotes senjam perdidos quando o cliente está congestionado.
Em caso de perda de pacotes fica a cargo da aplicação o pedir/enviar esses pacotes.
Não ficou muito claro como é que isto é resolvido com o QUIC.