Capítulo 2: Noções de Redes de Computadores

Hoje em dia, a base de quase qualquer aplicação que você imaginar, seja ela web, mobile ou desktop, é o protocolo de rede HTTP (HyperText Transfer Protocol). Compreender ele é essencial para entender como as aplicações que construíremos funcionam por baixo.

Se você não faz ideia do que seja um “protocolo”, não tem problema. Esse capítulo define conceitos fundamentais de redes de computadores, no nível que é necessário para o nosso curso.

Redes de Computadores

Os conceitos que iremos falar aqui podem ser vistos em qualquer curso ou livro de Redes de Computadores. Redes é uma sub-área de computação dedicada a entender como computadores, separados fisicamente por alguma distância, trocam dados entre si. É uma das partes mais importantes de um currículo de computação, pois o mundo moderno inteiro depende dos conceitos estudados nessa área.

Só para te dar uma noção, vamos ver como redes de computadores acabam surgindo no seu dia:

1. Seu celular toca o alarme e te acorda.
2. Você abre o Whatsapp para ver as mensagens. O seu celular usa conceitos de redes para obter as mensagens que foram enviadas para você. Ele inicia uma comunicação com os computadores (chamados aqui de “servidores”) do Whatsapp/Meta.
3. Você pede uma corrida na Uber. O seu dispositivo precisa se comunicar com os servidores da Uber. E os dispositivos dos motoristas também precisa se comunicar com os servidores da Uber. Eles se comunicam usando conceitos de redes.
4. Você encontra uma corrida. Tanto o dispositivo do passageiro quanto do motorista enviam continuamente informações para o servidor da Uber, contendo suas respectivas coordenadas. O servidor da Uber lê essas informações e as exibe no aplicativo para os dois usuários envolvidos na corrida: você e o seu motorista.
5. Você abre o Youtube ou a Netflix. Seu dispositivo precisa obter os dados que compõem os vídeos (áudio, imagens, legendas, etc) de algum lugar. Para isso, ele se comunica com o servidor do Youtube/Netflix, para então exibir os vídeos no seu dispositivo. Eles se comunicam usando conceitos de redes.
6. Você compartilha um arquivo via Bluetooth com um amigo de sala. Para isso funcionar, é preciso que os dois dispositivos se comuniquem entre si, no que chamamos de “rede sem fio”, utilizando apenas ondas eletromagnéticas. Eles se comunicam usando conceitos de redes.

Acho que deu pra ter uma noção da importância dessa disciplina para a sociedade moderna.

Conceitos básicos de redes

A figura abaixo ilustra uma rede de computadores simples, com quatro hosts conectados entre si.

Rede

Uma rede de computadores, ou simplesmente rede, nada mais é do que um conjunto de computadores que, mesmo separados fisicamente, podem trocar informações entre si.

Por “computadores”, eu quero dizer qualquer dispositivo de computação: Desktops, celulares, consoles de videogame, Smart TVs, carros, etc. Muitas vezes, esses computadores que participam da rede são chamados de hosts.

Existem redes privadas, que são gerenciadas e acessadas por uma organização, e redes públicas, que são acessíveis por múltiplas organizações. A rede pública mais importante de todas é a Internet.

A troca de informações numa rede não pode ser feita de qualquer forma. Para dois computadores trocarem informações, é importante que ambos falem a mesma língua e sigam as mesmas regras, o que nos leva ao próximo conceito.

Protocolo

Um conceito que está presente em toda a disciplina de redes é o de protocolo: um conjunto de regras que duas ou mais partes devem seguir fielmente para atingir um objetivo comum. Para um protocolo funcionar é necessário que todas as partes estejam cientes dele e o sigam.

Um protocolo de rede é um protocolo onde as partes são computadores! E as regras dos protocolos de rede geralmente seguem mais ou menos a mesma cara, geralmente fazendo alguma dessas funções:

• Definem quais são os tipos de mensagens possíveis que as partes podem trocar
• Definem qual o conteúdo das mensagens trocadas.
  • Como as partes são computadores, esse conteúdo é sempre em binário (1s e 0s). Então uma mensagem possível é 01110110001 que pode representar um OLÁ, por exemplo.
• Definem o fluxo válido das mensagens.
• Definem os erros e/ou situações de ajuste, e como proceder.

Em redes, temos vários protocolos, cada qual com um objetivo específico. Por exemplo, alguns protocolos que são usados hoje em dia em várias aplicações são:

• O SMTP (Simple Mail Transfer Protocol), que é o protocolo que permite envio e transmissão de e-mails entre computadores. É o que o Gmail, Outlook, entre outros usam quando precisam enviar um e-mail.
• O BitTorrent, que é o protocolo que permite a transmissão de torrents entre computadores. É o que aplicações como qBittorrent, µTorrent, entre outros usam.
• O DNS (Domain Name System), que é o protocolo que permite que nossos celulares e computadores consigam traduzir um nome como sigaa.ufs.br, que só faz sentido para humanos, para algo que possa ser entendido por máquinas.

Os protocolos são definidos em documentos de texto, conhecidos como RFCs (Request for Comments). Por exemplo, o SMTP é definido na RFC 5321, enquanto o DNS é definido na RFC 1035.

Camadas

Os protocolos não são todos iguais. Isso ocorre pois certos protocolos ficam responsáveis por apenas algumas partes da comunicação, enquanto outros ficam responsáveis por outras.

Por exemplo, considere o caso em que o protocolo SMTP seja utilizado pelo servidor do Gmail para enviar um e-mail para o servidor do Outlook.

Não faz sentido que a RFC do SMTP responda as seguintes perguntas:

• Como deve ser feita a transmissão física dos bits entre dois computadores? Será usado fio de cobre, fibra ótica ou tranmissão sem-fio (ondas de rádio). Qual o nível de voltagem que será usado para representa um bit 0 e um bit 1? Ou que deverá ser feito se acontecer alguma interferência eletromagnética na hora de transferir esses sinais elétricos. Essas são preocupações físicas, sem relação direta com troca de emails.
• Como o hardware de um dispositivo deve distinguir entre os sinais elétricos destinados para diferentes conexões num mesmo computador? Quando os sinais elétricos de uma conexão terminam e o de outra começam? Como garantir que os dados sejam direcionados para o dispositivo correto, dentro de uma rede local? Essas são preocupações de enlace, sem relação direta com troca de emails.
• Qual rota de computadores deve ser seguida para um certa conexão? Como diferenciar globalmente dois computadores? Como redes de diferentes organizações/empresas devem se conectar? Essas são preocupações a nível de redes em si, sem relação direta com troca de emails.
• Como as conexões são representadas no sistema operacional de cada dispositivo? Como associar um processo do sistema operacional a uma conexão de rede? Devemos garantir que o processo do computador de destino recebeu a última mensagem? Se sim, como? Como regular a velocidade da transmissão para evitar que a qualidade da rede seja degradada? Essa são preocupações de transporte, sem relação direta com troca de emails.

Nenhuma dessas preocupações dizem respeito a troca de emails, mas todas devem ser respondidas antes que qualquer email seja enviado. Além disso, essas preocupações não devem ser respondidas apenas para a troca de emails, mas também para outros tipos de aplicações, como transferência de arquivos, navegar pela web, DNS, BitTorrent, etc.

De fato, cada uma dessas preocupações se encaixa em uma camada.

Uma camada de rede é o conjunto de preocupações e responsabilidades que podem ser resolvidas em conjunto, por um mesmo protocolo.

Elas recebem o nome de camadas pois certas responsabilidades precisam ser resolvidas anteriormente, criando uma hierarquia ou camada de responsabilidades. Um protocolo numa camada \( L \) precisa que um protocolo na camada \( L - 1 \) já tenha resolvido os problemas sob sua responsabilidade. De maneira geral, dizemos que a camada \( L - 1 \) provê serviços para a camada \( L \).

Modelos de Rede: OSI e TCP/IP

Um modelo de rede é uma forma específica de definir quantas e quais são as camadas de rede. Existem dois modelos de rede: o modelo OSI e o modelo TCP/IP.

O modelo OSI é utilizado em alguns contextos acadêmicos e a sua numeração (de 1 a 7) é a que as pessoas geralmente utilizam para se referir as camadas. Já o modelo TCP/IP é o que é de fato implementado na Internet e utilizado na prática.

Abaixo, descrevemos as 5 camadas do modelo TCP/IP, a partir da mais básica (baixo nível):

1. Camada Física
   • Camada que se preocupa em como será feita a transmissão física dos sinais que carregam os dados na rede. É onde são projetados os padrões dos meios de transmissão, como cabos, ondas de radio-frequência, etc.
   • Principais protocolos dessa camada: IEEE 802.3 (redes cabeadas, também conhecido como Ethernet), IEEE 802.11 (redes sem fio do tipo Wi-fi), IEEE 802.15 (redes sem fio do tipo Bluetooth). Importante notar que esses protocolos cobrem ambas a camada física e de enlace, pois essas possuem uma dependência muito grande entre si.
2. Camada de Enlace
   • Camada que se preocupa no nível lógico imediatamente acima da transmissão física, em particular na conexão ponto-a-ponto (o enlace ou link) entre dois hosts.
   • Principais protocolos dessa camada: IEEE 802.3 (redes cabeadas, também conhecido como Ethernet), IEEE 802.11 (redes sem fio do tipo Wi-fi), IEEE 802.15 (redes sem fio do tipo Bluetooth).
3. Camada de Rede
   • Camada que se preocupa em definir o escopo de uma rede e como será feita a comunicação entre duas redes. Define um endereço lógico para cada host chamado endereço IP (Internet Protocol). É esse endereço que é utilizado para rotear as comunicações entre os hosts.
   • Principais protocolos dessa camada: IPv4, IPv6, ICMP, ICMPv6, etc.
4. Camada de Transporte
   • Camada que se preocupa na comunicação fim-a-fim entre dois processos do sistema operacional de cada host.
   • Principais protocolos dessa camada: TCP, UDP, SSL/TLS (baseado no TCP), QUIC (baseado no UDP).
5. Camada de Aplicação
   • Camada que se preocupa em definir o funcionamento das aplicações de rede, que entram em contato direto com o usuário. Troca de emails, envio de arquivos, impressão e navegação web são exemplos de “aplicações” aqui, pois representam as ações que o usuário-fim quer realizar.
   • Principais protocolos dessa camada: DNS, DHCP, HTTP, SMTP, FTP, WebSockets, BitTorrent.

Endereço de Rede/Endereço IP

Dentro de uma rede de computadores, é necessário que um participante dela (um host) saiba como identificar e diferenciar uma conexão que deve ser direcionada para o host A de outra que deve ser direcionada para o host B. Para resolver esse problema, foram criados os endereços de rede.

Cada host numa rede é identificado pelo seu endereço de rede. Um endereço de rede é simplesmente uma sequência de números que pode ser interpretada para identificar hosts.

No modelo TCP/IP, o endereço de rede segue o formato dos protocolos da camada de rede: IPv4 (Internet Protocol version 4) e/ou IPv6 (Internet Protocol version 6). Nesses casos, um nome alternativo para o endereço de rede é “endereço IP” ou apenas “IP”.

Vamos ver um exemplo, seguindo o formato do protocolo IPv4:

• Um host A tem o endereço de rede 10.10.3.47. Ele está se comunicando com dois outros hosts: B (cujo endereço é 10.10.3.3) e C (cujo endereço é 10.10.5.98).
• Sempre que A quiser mandar uma mensagem para B, ele manda um pacote cujo endereço de destino é 10.10.3.3. C não é o destino dessa mensagem.

Note que se um mesmo host está conectado em duas ou mais redes distintas (como um roteador que roteia pacotes entre duas ou mais redes), ele terá mais de um endereço IP.

Existem dois endereços IP especiais, chamados de endereços de loopback, que podem ser usados por um computador para se referir a ele mesmo. Um é o IPv4 127.0.0.1. O outro é o IPv6 ::1. Esses endereços são úteis na fase de desenvolvimento, onde executamos uma aplicação na nossa própria máquina local. Dessa forma, podemos nos comunicar com a aplicação através dos endereços de loopback, simulando um host externo.

Serviços de Rede

Enquanto na camada de rede os hosts de origem e destino são representados por meio de endereços IP, na camada imediatamente acima, a camada de transporte, um mesmo host pode oferecer vários serviços de rede. Um serviço de rede é um programa cuja entrada é obtida a partir de requisições de outros hosts (chamados de clientes) que chegam por meio de uma rede de computadores.

Ou seja, um serviço de rede é um processo do sistema operacional que tem a capacidade de escutar por requisições que vêm de uma rede de computadores e responder a essas requisições.

Cada serviço de rede executa algum protocolo da camada de aplicação que os dois lados da comunicação, tanto servidor (o host que executa/oferece o serviço de rede) quanto os clientes (os hosts remotos que mandam requisições e solicitam o serviço de rede), precisam saber falar.

Portas

Da mesma forma que podemos ter múltiplos processos em execução no sistema operacional, podemos ter múltiplos serviços de rede em execução. Portanto, o sistema operacional precisa distinguir o tráfego de rede que vai para um serviço de rede \( A \) do tráfego que vai para outro serviço de rede \( B \). Ou seja, o sistema operacional precisa demultiplexar¹ o tráfego de rede.

A maneira pela qual o SO faz essa demultiplexação é utilizando portas de rede. Cada porta de rede é um par (Protocolo de Transporte, Número de Porta) que identifica a qual serviço de rede um certo tráfego pertence. Nesse par:

• Protocolo de Transporte é um dos dois protocolos básicos da camada de transporte: TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol).

  O TCP é um protocolo orientado à conexão, o que significa que ele garante que um lado da comunicação saiba que as mensagens enviadas de fato chegaram ao destino e na ordem correta. Além disso, ele possui alguns controles para garantir a qualidade da rede. No entanto, é um protocolo que possui mais overhead (sobrecarga), isto é, custo computacional.

  Já o UDP é um protocolo não-orientado à conexão, o que significa que os participantes da comunicação não tem garantia sobre se as mensagens chegaram na ordem correta ou se elas sequer chegaram. Para compensar, é um protocolo com consideravelmente menos overhead.

• Número de Porta é um número de 16 bits (vai de 0 a 65535). Esse número serve para permitir que, em um mesmo computador, múltiplos serviços de rede de um mesmo protocolo de transporte possam estar em execução em um dado momento.

Cada serviço de rede em execução num dado host é mapeado para uma porta de rede, e a porta atua como um endpoint de comunicação. Por exemplo, num mesmo computador/host podemos ter 3 serviços de rede em execução:

• O serviço de rede do Spotify para fazer streaming de música usando a porta TCP/4070.
• O serviço de rede para enviar emails (protocolo SMTP) usando a porta TCP/25.
• O serviço de rede para transferir arquivos (protocolo FTP) usando a porta TCP/21.

Certas portas são chamadas de portas bem-conhecidas (well-known ports), pois geralmente são usadas para os serviços de rede (protocolos) mais comuns. Essas portas usam números que vão de 0 a 1023. Por exemplo, a porta TCP/80 é sempre utilizada para o protocolo HTTP. A porta TCP/443 é sempre utilizada para o protocolo HTTPS. A porta UDP/53 é muito usada para o protocolo DNS. E por aí vai.

Hostname

Apesar dos computadores utilizarem endereços IP, é muito mais fácil para um humano lembrar de mail.google.com do que lembrar do IP 142.250.219.37. Portanto, todo host costuma ter um hostname, que é o nome legível do host, além de um IP. Por exemplo, suponha que uma organização tenha os seguintes hosts:

• Um host para o seu portal web. O hostname do host é www e o IP é 10.100.3.2.
• Um host para o seu serviço de e-mail. O hostname do host é mail e o IP é 10.100.3.3.
• Um host para o seu serviço de API². O hostname do host é api e o IP é 10.100.3.4.

Domínio

Para agrupar os hostnames de todos os hosts que pertencem a uma mesma organização ou estrutura, é usado um domínio: uma sequência de nomes (legíveis por humanos), cujas partes são separadas por pontos.

Geralmente, a parte final de um domínio é o chamado de TLD (Top-Level Domain), que é comum a várias organizações que compartilham uma mesma característica. Então, por exemplo:

• O domínio .ufs.br é utilizado pela organização UFS. Seu TLD é .br, geralmente usado por organizações do Brasil.
• O domínio .globo.com é utilizado pela organização Globo. Seu TLD é .com, que vem de company, geralmente usado por organizações empresariais. Note que mesmo sendo uma organização brasileira, o domínio da Globo não está no TLD .br.

FQDN

Sempre que alguém quer se referir a um host específico de uma organização, evitando qualquer ambiguidade, ele utiliza o FQDN (Fully Qualified Domain Name) do host, que nada mais é do que a junção de hostname + domínio.

O FQDN também pode ser usado para obter o endereço IP do host. Alguns exemplos:

• O FQDN www.google.com refere-se ao host que oferece o serviço do site do Google.
• O FQDN g1.globo.com refere-se ao host que oferece o serviço g1 da Globo.
• O FQDN ge.globo.com refere-se ao host que oferece o serviço ge da Globo.

DNS

Lembre-se que os computadores não trabalham com hostnames, domínios ou FQDNs, mas sim com endereços IP. Portanto, sempre que digitamos algo como www.google.com, o computador precisa traduzir esse FQDN para um endereço IP.

Essa tradução (ou resolução) de nomes só é possível graças ao protocolo DNS (Domain Name System). Sempre que digitamos www.google.com, o DNS entra em ação e traduz esse FQDN para algum endereço IP (exemplo: 142.250.219.34).

O Protocolo HTTP

Vimos que aplicações são compostas de vários componentes que se comunicam entre si: frontend (web e/ou mobile), backend, banco de dados, etc. Apesar de não ser uma regra, hoje em dia praticamente toda aplicação realiza a comunicação entre frontend e backend utilizando um protocolo da camada de aplicação chamado HTTP (HyperText Transfer Protocol).

Modelo Cliente-Servidor

Sempre que temos uma conversa que segue o protocolo HTTP, são definidos dois papéis essenciais:

• O servidor HTTP: É um host que fica sempre escutando por novas conexões. Ele recebe requisições dos clientes e responde elas. Por exemplo, imagine que você acessa o SIGAA em http://sigaa.ufs.br/. Nesse caso, o servidor HTTP é o próprio sigaa.ufs.br (este é o FQDN do host que executa, ou hospeda, o SIGAA).
• O cliente HTTP: É o host que inicia novas conexões. É ele quem manda as requisições para o servidor e fica aguardando pela resposta dele. No exemplo anterior, quando você acessa o SIGAA em http://sigaa.ufs.br/, você é o cliente HTTP. Note que é possível que dois ou mais clientes HTTP diferentes conectem-se ao mesmo servidor HTTP.

Ou seja, o protocolo HTTP segue o chamado Modelo Cliente-Servidor. A imensa maioria dos protocolos da camada de aplicação seguem esse modelo³.

Mensagens HTTP: Requisições e Respostas

Toda conversa entre o cliente e o servidor é uma sequência de mensagens HTTP. Uma mensagem HTTP pode ser de dois tipos: uma Requisição HTTP (enviada pelo cliente para o servidor) ou uma Resposta HTTP (enviada pelo servidor para o cliente).

Anatomia de uma Requisição HTTP

Toda comunicação HTTP começa por uma requisição, pois é o cliente quem inicia a comunicação. O servidor fica passivamente aguardando novas conexões iniciadas pelos clientes.

Vamos primeiro ver um exemplo de requisição HTTP⁴. A requisição abaixo é de um cliente que está acessando uma página web sobre um relatório do clima.

GET /blog/2026/08/relatorio-clima.html?page=2&sort=date&highlight=temperatura HTTP/1.1
Host: www.guardian.co.uk
Accept: text/html
Accept-Language: pt-BR
User-Agent: Chrome/127.0.0.0
Cookie: session_id=a3f8b2c1e9d04716; _ga=GA1.2.1847263950.1723641200; consent=accepted
Connection: keep-alive

Vamos entender parte por parte:

• A primeira linha é a linha de requisição (request line). Ela contém 4 partes:

  • Um método (GET, especificando que quer obter/ver algum conteúdo).
  • Um path (/blog/2026/08/relatorio-clima.html, especificando a localização do conteúdo que será visto).
  • Uma query string (?page=2&sort=date&highlight=temperatura, especificando parâmetros para mudar/personalizar o conteúdo retornado).
  • A versão do protocolo HTTP (HTTP/1.1, especificando quais funcionalidades HTTP estão disponíveis).

• As próximas 6 linhas são cabeçalhos (headers) HTTP. Cada cabeçalho tem um nome (ex: Host) e um valor (ex: www.guardian.co.uk) separados por :.

  Os cabeçalhos HTTP permitem configurar a conexão e manter valores (estado) ao longo dela.

  • O header Host: www.guardian.co.uk especifica o host sendo acessado⁵.
  • Accept: text/html especifica qual o tipo esperado do conteúdo. Nesse caso, é esperado um conteúdo de texto que forma um documento HTML. Veremos mais a frente o que é um documento HTML.
  • Accept-Language: pt-BR especifica que o conteúdo deve ser retornado preferencialmente em Português do Brasil.
  • User-Agent: Chrome/127.0.0.0 indica que o cliente acessou o servidor por meio do navegador Google Chrome na versão 127.0.0.0. O valor desse header muda a depender do programa usado para acessar o site, podendo ser desde navegadores até ferramentas CLI como curl.
  • Cookie: session_id=a3f8...; _ga=GA1.2...; consent=accepted é o header que armazena os famosos cookies do site. Esse header guarda 3 cookies:
    • session_id é o ID de uma sessão específica do usuário naquele site. É por meio desse cookie que é possível fechar um site e, ao reabrí-lo, ainda estarmos conectados na nossa conta.
    • _ga é um cookie usado pelo Google Analytics, um serviço da Google que os sites contratam para poder rastrear e analisar o tráfego dos usuários, coletando dados como páginas visualizadas, duração da sessão, localização geográfica, tipo de dispositivo, etc.
    • consent é um cookie usado para identificar se um usuário consentiu com os termos de uso do site, como os cookies que são utilizados para rastrear o comportamento do usuário. É relevante principalmente em países que possuem legislação sobre uso de dados, como a LGPD.
  • Connection: keep-alive especifica que o clienter quer re-utilizar a mesma conexão TCP, re-aproveitando as configurações já feitas.

• Após os headers pode vir uma ou mais linhas que formam o payload (ou corpo) da requisição. Como trata-se de uma requisição GET, não há necessidade de payload.

Método

Cada requisição HTTP possui um método (também chamado de verbo). O método HTTP representa que tipo de ação aquela requisição pretende realizar. Os 5 principais métodos HTTP são:

• GET: Representa a ação de exibir um conteúdo ou listar os conteúdos existentes.
• POST: Representa a ação de criar um conteúdo.
• PUT: Representa a ação de substituir/modificar um conteúdo por completo.
• PATCH: Representa a ação de substituir/modificar partes de um conteúdo.
• DELETE: Representa a ação de remover um conteúdo.

As requisições que usam os métodos POST, PUT e PATCH costumam possuir uma payload (corpo da requisição), contendo os dados sobre o que será criado/modificado.

Veremos mais a frente como o padrão REST utiliza esses métodos para representar o gerenciamento de recursos.

Path

Uma requisição HTTP sempre diz respeito a algum conteúdo ou recurso. O path (caminho) da requisição indica o caminho daquele conteúdo/recurso em específico.

Por exemplo:

• O path / é geralmente usado para representar a raiz daquele site, e geralmente retorna a página inicial do site.
• O path /blog pode ser usado para representar todas as postagens do blog de um determinado site.
• O path /blog/2026 pode ser usado para representar todas as postagens do blog do ano de 2026.
• O path /blog/2026/08/relatorio-clima.html pode ser usado para representar uma postagem em específico do blog. Note que o path termina em .html, indicando que esse recurso trata-se de um arquivo/documento HTML.
• O path /blog/imagens/banner.png representa uma imagem em específico do blog. Note que o path termina em .png, indicado que esse recurso trata-se de uma imagem PNG.
• O path /api/usuarios/42 representa o recurso do tipo usuário cujo ID é igual a 42.

Query String

Dado um path, é possível que queiramos customizar o conteúdo retornado. Essas customizações normalmente são especificadas na parte da requisição chamada query string (também chamada de query parameters).

Geralmente, essas customizações costumam ser:

• Qual filtro de busca utilizar
• Qual página dos resultados deve ser retornada
• Se os resultados devem ser ordenados, crescentemente ou decrescentemente.

A query string é uma lista de pares parâmetro=valor, separador por &. A lista de query parameters sempre começa com ?. Por exemplo, veja a query string do exemplo, ?page=2&sort=date&highlight=temperatura. Temos 3 parâmetros:

• page=2 especifica que deve ser retornada a segunda página de resultados.
• sort=date especifica que os resultados devem vir ordenados pela data.
• highlight=temperatura especifica que o campo temperatura deve ter destaque.

Nem toda requisição tem uma query string. Ela é opcional.

A junção do path + query params formam o alvo da requisição.

Um dos benefícios dos query params é que como eles fazem parte do alvo da requisição, eles podem ser salvos e uma dada consulta (com seus filtros e opções) pode ser salvo e reutilizado. Por exemplo, o seguinte pode ser colado na barra de navegação para levar a uma consulta do Google pelo termo ufs: https://www.google.com/search?q=ufs. Veja que é utilizado o path /search e a query string ?q=ufs.

Versão HTTP

Toda requisição HTTP inclui a versão do protocolo que será utilizada. Atualmente, existem 4 versões em uso:

• HTTP/1.0: Versão definida na RFC 1945. Estabeleceu os fundamentos do protocolo. Alguns servidores antigos ainda utilizam essa versão.
• HTTP/1.1: Definida na RFC 2616. Estabeleceu otimizações importantes, como conexões persistentes (Connection: keep-alive). É a versão mais comum de ser vista na Internet.
• HTTP/2: Protocolo deixou de ser baseado em texto e se transformou num protocolo binário. Funcionalidades: Multiplexação de várias mensagens sobre um mesmo canal de comunicação, compressão de cabeçalhos, priorização de arquivos, server push, etc.
• HTTP/3: Versão mais recente, ainda pouco utilizada. Funcionalidades: troca do protocolo TCP pelo protocolo QUIC, criptografia obrigatória, mais rápido, etc.

Apesar disso, você só lerá requisições mencionando as duas primeiras versões, pois elas são baseadas em texto, já o HTTP/2 e o HTTP/3 são protocolos binários (não são legíveis por humanos).

Headers

Os campos anteriores juntos formam a linha de requisição (request line) de uma requisição HTTP. A request line é a primeira linha da requisição. Alguns exemplos de request lines:

• GET /index.html HTTP/1.1
• GET /search?q=openai&lang=en HTTP/1.1
• POST /api/usuarios HTTP/1.1

Além da request line, uma requisição HTTP também possui os cabeçalhos (headers). Os headers são pares Nome: Valor e servem para adicionar metadados e configurações para a comunicação em si.

Alguns exemplos de headers relevantes:

• Host. Especifica qual o FQDN do host que atua como servidor HTTP⁵. Esse é o único header de requisição que é obrigatório.

  Exemplo: Host: www.exemplo.com.

• Cookie. É o header cujo valor são os famosos cookies do site. Esses cookies são utilizados para guardar informações que persistem ao longo de várias requisições HTTP (estado). Cada cookie é um par nome=valor, separados por ;.

  Exemplo: Cookie: session_id=abc123def456; theme=dark; lang=pt-BR, com 3 cookies.

• Referer. É o header utilizado quando um site te redireciona para outro, e o seu valor é a URL do site que solicitou o redirecionamento.

  Exemplo: Referer: https://www.example.com/products?category=shoes.

Os headers vêm após a request line. Cada header é escrito em uma linha.

Payload

Quando a requisição HTTP usa métodos como POST, PUT e PATCH, ela inclui um payload (também chamado de corpo da requisição).

Por exemplo, considere a seguinte requisição, que cria uma nova usuária em um sistema:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 68

{"name":"Alice Morrow","email":"alice@example.com","age":29,"active":true}

Vamos entender por partes:

• A request line é POST /api/users HTTP/1.1. Portanto, ela irá incluir um payload. Após a request line, seguem 3 headers.

  1. Host: example.com é o host que atua como servidor HTTP.
  2. Content-Type: application/json é um header que especifica qual o tipo do conteúdo que está no payload. Nesse caso, application/json indica que o payload segue o formato JSON, que veremos mais a frente.
  3. Content-Length: 68 é um header que especifica o tamanho do payload em bytes.

• Após os 3 headers, temos uma linha em branco, que serve para indicar que a lista de headers acabou e o payload virá em seguida.

• O conteúdo do payload é:

  {"name":"Alice Morrow","email":"alice@example.com","age":29,"active":true}
  

  Os dados desse payload contêm o nome, email, idade e o status de ativação da nova usuária.

Anatomia de uma Resposta HTTP

Toda requisição HTTP precisa ser respondida pelo servidor. Uma resposta HTTP tem uma estrutura mais simples que as requisições.

Suponha que fizemos uma requisição da forma GET /index.html HTTP/1.1. É uma requisição para a página inicial de algum site. A resposta que o servidor HTTP entregou foi:

HTTP/1.1 200 OK
Date: Sun, 16 Aug 2026 18:37:12 GMT
Server: Nginx/1.25.2
Content-Type: text/html; charset=utf-8
Content-Length: 171
Connection: keep-alive

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Página Inicial</title>
</head>
<body>
    <h1>Seja bem-vindo!</h1>
    <p>A página carregou com sucesso.</p>
</body>
</html>

Vamos analisar por partes:

• A primeira linha é a linha de resposta (response line), contendo:
  • A versão do protocolo (HTTP/1.1)
  • O status code (200)
  • A reason phrase (OK), uma texto legível explicando o status code. Um status code sempre terá a mesma reason phrase. 200 OK = sucesso.
• Segue-se uma linha para cada cabeçalho de resposta (response header). Perceba que alguns headers também podem aparecer em requisições:
  • Date: Sun, 16 Aug 2026 18:37:12 GMT indica o horário que o servidor mandou a resposta.
  • Server: Nginx/1.25.2 indica qual o programa ou biblioteca utilizado pelo servidor para enviar respostas HTTP.
  • Content-Type: text/html; charset=utf-8 indica que o corpo da resposta vem no formato HTML e foi codificado utilizando o padrão UTF-8.
  • Content-Lenght: 171 indica que o corpo da resposta tem 171 bytes.
  • Connection: keep-alive indica que deve ser re-utilizada a mesma conexão TCP.
• Uma linha em branco indica o fim da lista de headers e o início do corpo da resposta.
• Seguem 171 bytes que formam o corpo da resposta. A resposta é um document no formato HTML que será exibido para o usuário, montando a estrutura e o conteúdo da página inicial.

Status Code e Reason Phrase

O servidor irá indicar o tipo de resultado usando o status code, que é um código de 3 dígitos. O status code pode indicar se foi falha, falha por erro do cliente, falha por erro do servidor, redirecionamento, timeout, etc).

Todo status code está associado a um texto legível chamado reason phrase, dando mais detalhes do que aconteceu para além do código numérico.

Os status codes podem ser classificados em categorias de acordo com o primeiro dígito:

Você pode consultar todos os status codes, seus significados e dicas de como usá-los na referência da MDN: Códigos de status de respostas HTTP.

Headers

Assim como as requisições, as respostas HTTP possuem headers para carregar metadados e configurar a conexão.

Alguns headers são exclusivos das respostas, como Server. Já outros podem ser usados tanto por requisições como por respostas, como Connection, Content-Type e Content-Length.

Body/Corpo

A parte mais importante de uma resposta HTTP é o corpo (body). É nele que está o conteúdo que o cliente está interessado. Esse conteúdo geralmente é:

• Um documento HTML, que define a estrutura e o conteúdo de uma página web.
• Uma arquivo de mídia (imagem, áudio, vídeo)
• Dados no formato XML ou JSON

O corpo da resposta pode ser vazio somente em algumas ocasiões, como em resposta a uma requisição DELETE.

E o HTTPS?

Praticamente todos os sites que você acessa hoje na web começam com https://. Esses sites usam o protocolo HTTP junto com um protocolo de segurança chamado SSL/TLS (Secure Socket Layer/Transport Layer Security). Esse protocolo criptografa os dados entre cliente e servidor, impedindo que um hacker malicioso leia os dados que estão trafegando.

Conclusão

Por hora, terminamos nosso estudo de redes. A parte mais importante desse capítulo para o restante do livro é o protocolo HTTP, pois este é o protocolo que o frontend e o backend de uma aplicação costumam usar para se comunicar.

Exercícios

1. Abra um terminal (no Windows, aperte Win + R, escreva cmd e aperte Ok) e digite o seguinte comando:

   (Obs: não precisa escrever C:\>, é apenas para indicar que deve ser digitado no Prompt de comando)

   C:\> curl -i sigaa.ufs.br
   

   Esse comando irá mostrar uma mensagem HTTP. Responda:

   1. O tipo da mensagem é uma resposta ou requisição HTTP?
   2. Qual o status code?
   3. Quantos e quais os headers?
   4. Essa mensagem tem corpo? Se sim, qual seu tamanho em bytes?
   5. O que o corpo diz? Como você mudaria o comando para atender o que o corpo diz?

2. No seu computador, abra um navegador web (Chrome, Firefox, Edge, Brave) e abra uma nova aba. Aperte F12 (ou Ctrl + Shift + I), irá aparecer um painel com várias informações. Na parte superior desse painel, tem várias abas. Clique na aba chamada Rede/Network. Essa aba mostra as mensagens HTTP que seu navegador faz enquanto você navega na web.

   Então, sem fechar esse painel, digite o seguinte na barra de navegação: example.com e aperte Enter.

   Responda:

   1. Quantas linhas apareceram?
   2. Clique na primeira linha. No novo painel aberto, vá na aba Headers/Cabeçalhos. Quantos headers tem a primeira requisição? Qual o método da primeira requisição? Qual o status code da primeira resposta?
   3. No mesmo painel, determine se a primeira requisição teve uma payload não-vazia. Faça o mesmo para a resposta.

3. Acesse https://httpbin.org/forms/post no seu navegador. Abra novamente o painel de Rede/Network. Preencha o formulário e envie. Observe a nova mensagem que apareceu após você clicar para enviar. A requisição tem corpo? Se sim, qual seu tamanho? E a resposta?

1. Demultiplexar é o processo de separar um único canal de comunicação em múltiplos canais. É o inverso da multiplexação: combinar diferentes canais em um único canal. ↩

2. Se você não sabe o que é uma API, não se preocupe: descobriremos no capítulo 3. ↩

3. Apesar da maioria dos protocolos da camada de aplicação seguirem o Modelo Cliente-Servidor, existem alguns protocolos que seguem outro modelo, chamado de Modelo Peer-to-Peer (P2P), onde cada host atua como um misto de cliente e servidor, falando em pé de igualdade com outros hosts. O exemplo clássico é o protocolo BitTorrent, mas também existem outros como o protocolo Bitcoin e XMPP/Jabber. ↩

4. Para simplificar, o exemplo mostrado omite os caracteres que representam as quebras de linhas (\r\n) numa requisição. Esses caracteres são importantes para indicar quando uma seção da requisição termina e outra começa. ↩

5. Os mais atentos podem estar se perguntando qual a necessidade do header Host se, para iniciar a comunicação HTTP, o cliente precisa saber antecipadamente qual o host que atuará como servidor. O motivo é que o header Host é utilizado para implementar uma técnica conhecida como virtual hosting, onde um único host físico, com um único IP, hospeda várias aplicações HTTP diferentes (chamados de hosts virtuais). O host físico que atua como servidor olha o valor desse header para saber qual aplicação/host virtual o cliente está interessado.

   Inclusive, é por esse motivo que o header Host é o único que é obrigatório. Uma requisição sem ele será rejeitada pelo servidor. ↩ ↩2