{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: a destrui\u00e7\u00e3o de fundamentos e um novo mundo maravilhoso","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

H\u00e1 mais de 20 anos, observamos p\u00e1ginas da web pelo protocolo HTTP. A maioria dos usu\u00e1rios nem sequer se pergunta o que isso significa e como funciona. Outros sabem que sob o HTTP est\u00e1 o TLS, e abaixo dele est\u00e1 o TCP, sob o qual est\u00e1 o IP, e assim por diante. E h\u00e1 aqueles \u2013 hereges \u2013 que acreditam que o TCP \u00e9 coisa do passado, desejando algo mais r\u00e1pido, confi\u00e1vel e seguro. Mas em suas tentativas de inventar um novo protocolo ideal, eles voltaram \u00e0s tecnologias dos anos 80 e est\u00e3o tentando construir seu novo mundo maravilhoso sobre elas.
\n\"HTTP\/3:
\n<\/a><\/noindex><\/p>\n

Um pouco de hist\u00f3ria: HTTP\/1.1<\/h2>\n

\nEm 1997, o protocolo de troca de informa\u00e7\u00f5es textuais HTTP vers\u00e3o 1.1 obteve seu RFC. Naquela \u00e9poca, o protocolo j\u00e1 era utilizado por navegadores h\u00e1 v\u00e1rios anos, e o novo padr\u00e3o durou mais quinze. O protocolo funcionava apenas no princ\u00edpio de pedido-resposta e era destinado, principalmente, \u00e0 transfer\u00eancia de informa\u00e7\u00f5es textuais.<\/p>\n

O HTTP foi projetado para funcionar sobre o protocolo TCP, que garante a entrega confi\u00e1vel de pacotes ao destinat\u00e1rio. O funcionamento do TCP baseia-se no estabelecimento e manuten\u00e7\u00e3o de uma conex\u00e3o confi\u00e1vel entre os pontos finais e na divis\u00e3o do tr\u00e1fego em segmentos. Os segmentos possuem seu pr\u00f3prio n\u00famero sequencial e uma soma de verifica\u00e7\u00e3o. Se algum dos segmentos n\u00e3o chegar ou chegar com uma soma de verifica\u00e7\u00e3o incorreta, a transmiss\u00e3o ser\u00e1 interrompida at\u00e9 que o segmento perdido seja recuperado.<\/p>\n

No HTTP\/1.0, a conex\u00e3o TCP era fechada ap\u00f3s cada pedido. Isso era extremamente dispendioso, pois o estabelecimento de uma conex\u00e3o TCP (3-Way-Handshake) \u00e9 um processo demorado. No HTTP\/1.1, foi apresentado o mecanismo keep-alive, que permite reutilizar uma \u00fanica conex\u00e3o para v\u00e1rios pedidos. No entanto, como isso pode facilmente se tornar um gargalo, em diferentes implementa\u00e7\u00f5es do HTTP\/1.1 \u00e9 permitido abrir v\u00e1rias conex\u00f5es TCP para um \u00fanico host. Por exemplo, no Chrome e nas vers\u00f5es mais recentes do Firefox, s\u00e3o permitidas at\u00e9 seis conex\u00f5es.
\n\"HTTP\/3:
\nA criptografia tamb\u00e9m deveria ser deixada a outros protocolos, e para isso o protocolo TLS foi utilizado sobre o TCP, que protegia os dados de forma bastante confi\u00e1vel, mas aumentava ainda mais o tempo necess\u00e1rio para estabelecer a conex\u00e3o. No final, o processo de handshake passou a ser assim:
\n \"HTTP\/3:
\nIlustra\u00e7\u00e3o Cloudflare<\/i><\/p>\n

Assim, o HTTP\/1.1 tinha uma s\u00e9rie de problemas:<\/p>\n