{"id":104306,"date":"2022-06-07T09:36:47","date_gmt":"2022-06-07T07:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta"},"modified":"2022-06-07T09:36:47","modified_gmt":"2022-06-07T07:36:48","slug":"protokol-http-3-0-poluchil-status-predlozhennogo-standarta","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"O protocolo HTTP\/3.0 recebeu o status de padr\u00e3o proposto","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
O Comit\u00ea IETF (Internet Engineering Task Force), respons\u00e1vel pelo desenvolvimento de protocolos e arquitetura da internet, concluiu a formata\u00e7\u00e3o do RFC para o protocolo HTTP\/3.0 e publicou as especifica\u00e7\u00f5es relacionadas com os identificadores RFC 9114 (protocolo) e RFC 9204 (tecnologia de compress\u00e3o de cabe\u00e7alhos QPACK para HTTP\/3). A especifica\u00e7\u00e3o HTTP\/3.0 recebeu o status de \"Padr\u00e3o Proposto\", ap\u00f3s o qual come\u00e7ar\u00e1 o trabalho para conferir ao RFC o status de Padr\u00e3o Draft (Draft Standard), o que significa a estabiliza\u00e7\u00e3o total do protocolo e a considera\u00e7\u00e3o de todos os coment\u00e1rios recebidos. Ao mesmo tempo, foram publicadas vers\u00f5es atualizadas das especifica\u00e7\u00f5es para os protocolos HTTP\/1.1 (RFC 9112) e HTTP\/2.0 (RFC 9113), al\u00e9m de documentos que definem a sem\u00e2ntica das requisi\u00e7\u00f5es HTTP (RFC 9110) e os cabe\u00e7alhos de controle de cache HTTP (RFC 9111). <\/p>\n
O protocolo HTTP\/3 define o uso do protocolo QUIC (Quick UDP Internet Connections) como transporte para HTTP\/2. O QUIC \u00e9 uma camada sobre o protocolo UDP, que suporta multiplexa\u00e7\u00e3o de v\u00e1rias conex\u00f5es e fornece m\u00e9todos de criptografia equivalentes a TLS\/SSL. O protocolo foi criado em 2013 pela Google como uma alternativa \u00e0 combina\u00e7\u00e3o TCP+TLS para a Web, abordando problemas de alto tempo de instala\u00e7\u00e3o e negocia\u00e7\u00e3o de conex\u00f5es em TCP e eliminando atrasos causados pela perda de pacotes durante a transmiss\u00e3o de dados.
<\/center> <\/p>\n
Atualmente, o suporte a QUIC e HTTP\/3.0 j\u00e1 foi implementado em todos os navegadores web populares (no Chrome, Firefox e Edge, o suporte a HTTP\/3 est\u00e1 ativado por padr\u00e3o, enquanto no Safari requer a ativa\u00e7\u00e3o da configura\u00e7\u00e3o \"Advanced > Experimental Features > HTTP\/3\"). No lado do servidor, as implementa\u00e7\u00f5es de HTTP\/3 est\u00e3o dispon\u00edveis para nginx (em um branch separado e na forma de um m\u00f3dulo separado), Caddy, IIS e LiteSpeed. O suporte a HTTP\/3 tamb\u00e9m \u00e9 fornecido pela rede de entrega de conte\u00fado Cloudflare. <\/p>\n
Principais caracter\u00edsticas do QUIC: <\/p>\n
\n
Alta seguran\u00e7a, equivalente ao TLS (na pr\u00e1tica, o QUIC possibilita o uso do TLS sobre UDP); <\/li>\n
Controle da integridade do fluxo, prevenindo a perda de pacotes; <\/li>\n
Capacidade de estabelecer uma conex\u00e3o instantaneamente (0-RTT, aproximadamente em 75% dos casos os dados podem ser transmitidos imediatamente ap\u00f3s o envio do pacote de instala\u00e7\u00e3o da conex\u00e3o) e garantir lat\u00eancias m\u00ednimas entre o envio da solicita\u00e7\u00e3o e o recebimento da resposta (RTT, Round Trip Time);
<\/center> <\/li>\n
Uso de um n\u00famero de sequ\u00eancia diferente para retransmiss\u00e3o de pacotes, o que permite evitar ambiguidades na determina\u00e7\u00e3o dos pacotes recebidos e eliminar timeouts; <\/li>\n
A perda de um pacote afeta apenas a entrega do fluxo relacionado e n\u00e3o interrompe a entrega de dados em fluxos paralelos transmitidos atrav\u00e9s da conex\u00e3o atual; <\/li>\n
Mecanismos de corre\u00e7\u00e3o de erros que minimizam atrasos devido \u00e0 retransmiss\u00e3o de pacotes perdidos. Uso de c\u00f3digos especiais de corre\u00e7\u00e3o de erros em n\u00edvel de pacote para reduzir situa\u00e7\u00f5es que exigem a retransmiss\u00e3o de dados de pacotes perdidos. <\/li>\n
Os limites dos blocos criptogr\u00e1ficos est\u00e3o alinhados com os limites dos pacotes QUIC, o que diminui o impacto da perda de pacotes na decodifica\u00e7\u00e3o do conte\u00fado dos pacotes subsequentes. <\/li>\n
Aus\u00eancia de problemas de bloqueio de fila TCP. <\/li>\n
Suporte a identificadores de conex\u00e3o, permitindo reduzir o tempo de estabelecimento de novas conex\u00f5es para clientes m\u00f3veis. <\/li>\n
Capacidade de conectar mecanismos avan\u00e7ados de controle de congestionamento. <\/li>\n
Uso de t\u00e9cnicas de previs\u00e3o de largura de banda em cada dire\u00e7\u00e3o para garantir a intensidade ideal de envio de pacotes, evitando um estado de sobrecarga em que ocorre a perda de pacotes. <\/li>\n
Um aumento significativo no desempenho e na largura de banda em compara\u00e7\u00e3o com o TCP. Para servi\u00e7os de v\u00eddeo, como o YouTube, a aplica\u00e7\u00e3o do QUIC mostrou uma redu\u00e7\u00e3o de 30% nas opera\u00e7\u00f5es de buffering durante a reprodu\u00e7\u00e3o de v\u00eddeos. <\/ul>\n
Entre as mudan\u00e7as na especifica\u00e7\u00e3o HTTP\/1.1, destaca-se a proibi\u00e7\u00e3o do uso isolado do caractere de retorno de carro (CR) fora do corpo da mensagem, ou seja, no protocolo, o caractere CR pode ser utilizado apenas em conjunto com o caractere de nova linha (CRLF). O algoritmo de montagem de requisi\u00e7\u00f5es chunked foi aprimorado para facilitar a separa\u00e7\u00e3o dos campos anexados e a se\u00e7\u00e3o de cabe\u00e7alhos. Foram adicionadas recomenda\u00e7\u00f5es para o tratamento de conte\u00fados amb\u00edguos para bloquear ataques do tipo \"HTTP Request Smuggling\", que permitem infiltra\u00e7\u00f5es no conte\u00fado das requisi\u00e7\u00f5es de outros usu\u00e1rios no fluxo entre o front-end e o back-end. <\/p>\n
Na atualiza\u00e7\u00e3o da especifica\u00e7\u00e3o do HTTP\/2.0, foi claramente definida a compatibilidade com o TLS 1.3. O esquema de defini\u00e7\u00e3o de prioridades e os campos relacionados nos cabe\u00e7alhos foram classificados como obsoletos. Foi declarado obsoleto o mecanismo de atualiza\u00e7\u00e3o de conex\u00e3o do HTTP\/1.1 que n\u00e3o se difundiu. As exig\u00eancias para a verifica\u00e7\u00e3o dos nomes dos campos e valores foram reduzidas. Alguns tipos de quadros e par\u00e2metros anteriormente reservados foram sugeridos para uso. Os campos de cabe\u00e7alho, referentes \u00e0 conex\u00e3o, foram definidos de forma mais precisa como proibidos. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"O](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"O](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n