Todo programador deve entender o protocolo HTTP, se você está começando agora, não se desespere, aos poucos você pega todos os detalhes, para ajudar eu vou trazer um pouco sobre a base que acho importante entendermos.

O que é HTTP?

HTTP (Hypertext Transfer Protocol) são regras para transferir arquivos (texto, imagens, audio, vídeo) pela internet. Assim que um usuário abre seu navegador da Web, ele está usando HTTP, um protocolo de aplicação que roda sobre o conjunto de protocolos TCP/IP, que forma a base da Internet. A versão mais recente do HTTP é o HTTP/2, mas o HTTP 1.1, seu antecessor, continua sendo utilizado.

Como funciona o HTTP

Por meio do protocolo HTTP, os recursos são trocados entre dispositivos clientes e servidores pela internet. Os dispositivos clientes enviam solicitações e os servidores enviam respostas que atenda a solicitação.

Um servidor web além dos arquivos deve rodar um servidor web, um serviço que está sempre esperando solicitações HTTP e respondendo. O navegado web é o cliente HTTP, ele solicita um arquivo e o servidor envia de volta.

Para exemplificar de forma mais clara, ao digitar o endereço do meu blog em seu navegador: diegorodrigo.dev, o mesmo faz uma solicitação GET para o servidor onde o site está hospedado.

Com essas informações o servidor devolve a conteúdo html home page do blog, no entanto as imagens e demais arquivos serão obtidos por outras conexões HTTP, quanto mais solicitações mais tempo para a página ser carregada.

Tanto solicitação quanto resposta utilizam TCP/IP para reduzir e transportar informações em pequenos pacotes de sequências binárias que trafegam no formato ASCII, se quiser se entender melhor, veja a RFC 2616, RFCs são documentações contendo os padrões e protocolos oficiais da internet.

HTTP vs. HTTPS

Server push

HTTPS é basicamente HTTP com SSL (Secure Sockets Layer) ou TLS (Transport Layer Security) como uma subcamada sob camadas de aplicativos HTTP regulares. O HTTPS criptografa e descriptografa as solicitações de página HTTP do usuário, bem como as páginas que são retornadas pelo servidor web, criando um conexão segura entre cliente e servidor.

HTTP/2

Server push

Se o HTTP/1.1 está funcionando, por que inventaram outra versão? Na verdade, assim como aconteceu na transição do HTTP/1.0 para o HTTP/1.1, a versão atual também está nessa transição.

O maior problema é que o HTTP/1.1 é um protocolo sequencial: seu navegador abre uma conexão, solicita um arquivo ao servidor do site, recebe o arquivo e só depois pede outro arquivo. Para minimizar essa perda de tempo, os navegadores normalmente abrem múltiplas conexões (algo entre quatro e oito) por servidor. Assim, o browser pode baixar vários elementos ao mesmo tempo e acelerar o carregamento da página.

O HTTP/2 usa multiplexação, um nome complicado para dizer que o navegador abre uma única conexão para baixar múltiplos arquivos. As requisições e respostas são paralelas e assíncronas: seu navegador pede vários arquivos ao mesmo tempo e recebe-os assim que eles estiverem prontos, na mesma conexão. Mas e se uma imagem na página, por exemplo, for pesada demais? Não tem problema: na mesma conexão, é possível misturar os dados, recebendo parte da imagem, depois um arquivo totalmente diferente e por fim o resto da imagem que faltava.

Server push

Outra novidade do HTTP/2 é o que está sendo chamado de server push. O Server Push resolve o problema do inline direto no protocolo de forma simples e elegante. A ideia é que, quando o usuário requisitar o HTML por exemplo, podemos enviar a resposta do CSS junto mesmo antes de ele requisitar.

Só que, com HTTP/2, o servidor poderá mandar esses elementos antes do seu navegador pedi-los. Dessa forma, assim que seu navegador solicitar nosso index.html, o servidor poderá responder com o index.html, o style.css favicon.svg. Quando seu navegador se der conta de que precisa usar esses arquivos para renderizar a página, eles já estarão no seu computador, prontos para uso.

Server push

Além disso, no HTTP/2, os cabeçalhos serão comprimidos com um formato chamado HPACK. Sempre que seu navegador solicita um arquivo, ele precisa baixar o cabeçalho desse arquivo, que pode conter o tamanho do arquivo, as informações do servidor e um cookie. Geralmente, um cabeçalho não passa de 1 KB, mas imagine isso se multiplicando por dezenas de arquivos? Com a compressão nos cabeçalhos, o uso de dados será menor — e as páginas carregarão mais rapidamente, claro.

HTTP/3

O HTTP/3 será a primeira grande atualização do protocolo desde o HTTP/2 em 2015. Uma diferença fundamental com o HTTP/3 é que ele é executado no QUIC, um novo protocolo de transporte.

O protocolo QUIC foi desenvolvido pelo Google em 2012 e foi adotado pela Internet Engineering Task Force (IETF). Depois de consultar especialistas em todo o mundo, o IETF fez uma série de mudanças para desenvolver sua própria versão do QUIC.

O QUIC foi projetado para uso pesado de internet móvel, onde as pessoas carregam smartphones que mudam constantemente de uma rede para outra enquanto se movem durante o dia. Este não era o caso quando os primeiros protocolos de internet foram desenvolvidos: os dispositivos eram menos portáteis e não mudavam de rede com muita frequência.

Solicitações e respostas HTTP

Server push

Cada interação entre o cliente e o servidor é chamada de mensagem. As mensagens HTTP são solicitações ou respostas. Os dispositivos cliente enviam solicitações HTTP aos servidores, que respondem enviando respostas HTTP de volta aos clientes.

Solicitações HTTP. É quando um dispositivo cliente, como um navegador de internet, solicita ao servidor as informações necessárias para carregar o site. A solicitação fornece ao servidor as informações desejadas de que ele precisa para adaptar sua resposta ao dispositivo cliente. Cada solicitação HTTP contém dados codificados, com informações como:

GET / HTTP/1.1
Host: diegorodrigo.dev
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate
  • A versão específica do HTTP seguida: HTTP e HTTP/2 são as duas versões.
  • Um URL: Isso aponta para o recurso na web.
  • Um método HTTP. Isso indica a ação específica que a solicitação espera receber do servidor em sua resposta.
  • Cabeçalhos de solicitação HTTP: Isso inclui dados como que tipo de navegador está sendo usado e quais dados a solicitação está buscando no servidor. Também pode incluir cookies, que mostram informações enviadas anteriormente do servidor que trata a solicitação.
  • Um corpo HTTP: Essas são informações opcionais que o servidor precisa da solicitação, como formulários de usuário - logins de nome de usuário/senha, respostas curtas e uploads de arquivos - que estão sendo enviados ao site.

Respostas HTTP: A mensagem de resposta HTTP são os dados recebidos por um dispositivo cliente do servidor web. Como o próprio nome sugere, a resposta é a resposta do servidor a uma solicitação HTTP. As informações contidas em uma resposta HTTP são adaptadas ao contexto que o servidor recebeu da solicitação. As respostas HTTP geralmente incluem os seguintes dados:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked

<!DOCTYPE html>
......
</html>
  • Código de status HTTP: que indica o status da solicitação ao dispositivo cliente. As respostas podem indicar sucesso, uma resposta informativa, um redirecionamento ou erros no lado do servidor ou do cliente.
  • Cabeçalhos de resposta HTTP: que enviam informações sobre o servidor e os recursos solicitados.
  • Um corpo HTTP (opcional): Se uma solicitação for bem-sucedida, ela conterá os dados solicitados na forma de código HTML, que é traduzido em uma página da Web pelo navegador do cliente.

Métodos HTTP

O protocolo HTTP utiliza métodos de requisições predefinidos que informam ao servidor qual tarefa ele deve executar no recurso desejado:

  • GET: requisição de um recurso
  • POST: adiciona/cria um recurso
  • DELETE: remove um recurso específico
  • PUT: modifica diretamente um recurso
  • PATCH: modifica parcialmente um recurso

Esses são os métodos mais utilizados, você pode ver todos aqui.

Códigos de status HTTP

Em resposta a solicitações HTTP, os servidores geralmente emitem códigos de resposta, indicando que a solicitação está sendo processada, houve um erro na solicitação ou que a solicitação está sendo redirecionada. Os códigos de resposta comuns incluem:

  • 200 OK. Isso significa que a solicitação, como GET ou POST, funcionou e está sendo executada.
  • 300 movidos permanentemente. Este código de resposta significa que a URL do recurso solicitado foi alterada permanentemente.
  • 401 não autorizado. O cliente, ou usuário que está fazendo a solicitação do servidor, não foi autenticado.
  • 403 Proibido. A identidade do cliente é conhecida, mas não recebeu autorização de acesso.
  • 404 não encontrado. Este é o código de erro mais frequente. Isso significa que a URL não é reconhecida ou o recurso no local não existe.
  • Erro de servidor interno 500. O servidor encontrou uma situação que não sabe como lidar.

Assim como os mé todos esses são alguns dos mais utilizados, você pode ver todos aqui.

Caso ainda tenha alguma dúvida sobre o protocolo HTTP esse site explica de uma forma bem divertida.