Disciplina: Redes de Computadores Professor: Claudio Nunes Tópico: Camada de Aplicação — Protocolos HTTP/1.1 e HTTP/2 sobre TLS
Este documento contém a fundamentação teórica da atividade e direciona cada aluno para o roteiro prático apropriado, de acordo com seu nível de privilégio na máquina de laboratório.
- 1. Objetivos de Aprendizagem
- 2. Pré-requisitos
- 3. Escolha do Roteiro Prático
- 4. Fundamentação Teórica
- 5. Referências
- Anexo A — Tabela-resumo de cabeçalhos
- Anexo B — Tabela-resumo de status codes
Ao final desta atividade, o aluno será capaz de:
- Descrever a estrutura de uma mensagem HTTP (linha inicial, cabeçalhos, corpo) em nível de bytes.
- Identificar os métodos, os códigos de status e os principais cabeçalhos de requests/responses reais.
- Utilizar um debugging proxy (Fiddler Classic como ferramenta de referência) para capturar, inspecionar e, quando aplicável, manipular tráfego HTTP.
- Diferenciar o comportamento de HTTP e HTTPS na camada de transporte.
- Analisar fluxos completos como navegação web, submissão de formulário e manutenção de sessão via cookies.
- Modelo TCP/IP e camada de aplicação.
- Conceito de cliente/servidor e sockets TCP.
- Noções básicas de TLS/SSL.
- Sistema operacional: Windows 10/11 nas máquinas do laboratório. Em máquina pessoal, use Windows 10/11 se for executar o Fluxo A com Fiddler Classic; no Fluxo B, ferramentas equivalentes podem ser usadas quando indicadas no roteiro.
- Navegador Chrome, Firefox ou Edge atualizado.
- Acesso à internet sem bloqueios a sites de teste (
httpbingo.org,example.com,neverssl.com). - Debugging proxy: no laboratório, siga a orientação do professor e use a instalação disponibilizada. Em máquina pessoal, instale o Fiddler Classic a partir do site oficial da Telerik ou pelo
winget, conforme o roteiro do fluxo escolhido.
💡 Nota sobre o Fiddler Classic. A Telerik (mantenedora atual) declara que o Fiddler Classic está "sem desenvolvimento ativo", recomendando o Fiddler Everywhere (pago) para uso profissional. Para o propósito didático deste laboratório o Fiddler Classic continua adequado. Nas máquinas do laboratório, use a instalação indicada pelo professor; em máquina pessoal, obtenha a versão gratuita pelo site da Telerik (com cadastro de email) ou pelo gerenciador de pacotes do Windows com
winget install Telerik.Fiddler.Classic.
- Template
relatorio.mdpresente na pasta do roteiro escolhido. - Ferramenta de captura de tela do sistema (Print Screen, Snip & Sketch no Windows, Captura de Tela no macOS, GNOME Screenshot no Linux). As imagens serão arrastadas diretamente para o editor web do GitHub no momento de preencher o relatório.
A inspeção de tráfego HTTPS pelo Fiddler exige a instalação de um certificado raiz no armazenamento de confiança do sistema operacional. Essa operação requer privilégios de administrador. Para acomodar laboratórios mistos, há dois roteiros práticos independentes; ambos usam esta fundamentação teórica como referência comum:
| Fluxo | Quem usa | Escopo | Pasta |
|---|---|---|---|
| A | Alunos COM privilégio de administrador | Captura e inspeção de HTTP e HTTPS (com decriptação TLS) | fluxo-a-administrador/ |
| B | Alunos SEM privilégio de administrador | Captura e inspeção somente de HTTP em texto claro + análise teórica de HTTPS | fluxo-b-sem-administrador/ |
Teste rápido para decidir o fluxo. Tente abrir o Fiddler Classic como administrador (clique direito → Executar como administrador):
📝 Nota sobre avaliação. Os dois fluxos têm peso equivalente na nota final. O Fluxo B substitui a inspeção prática de HTTPS por comparação observacional e análise teórica curta. Cada aluno deve escolher um único fluxo no início da aula e segui-lo até o final.
O HyperText Transfer Protocol (HTTP) é um protocolo de camada de aplicação, baseado em texto (até HTTP/1.1), sem estado, do tipo request/response. Opera por padrão sobre TCP:
| Versão | Transporte | Porta padrão | Característica-chave |
|---|---|---|---|
| HTTP/1.0 | TCP | 80 | Uma conexão por request |
| HTTP/1.1 | TCP | 80 | Keep-alive, pipelining, chunked encoding |
| HTTP/2 | TCP + TLS (ALPN h2) |
443 | Binário, multiplexação, header compression (HPACK) |
| HTTP/3 | QUIC (UDP + TLS 1.3) | 443 | Sem head-of-line blocking, estabelecimento mais rápido |
HTTPS é HTTP encapsulado em TLS. Toda a mensagem HTTP — linha de status, headers e body — é cifrada. Em um cenário típico, sem tecnologias adicionais como ECH (Encrypted Client Hello) ou DNS cifrado, IP, porta, DNS e SNI (nome do host) ainda podem ficar visíveis a um observador externo.
Toda mensagem HTTP/1.x tem a mesma estrutura:
<linha inicial> ← request-line OU status-line
<Header-1>: <valor> ← zero ou mais linhas de cabeçalho
<Header-2>: <valor>
...
<linha em branco> ← CRLF separador
<corpo opcional> ← body (pode estar ausente)
Exemplo de request capturado num navegador:
GET /get?id=42 HTTP/1.1
Host: httpbingo.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: pt-BR,pt;q=0.9,en;q=0.8
Connection: keep-alive
Exemplo de response correspondente:
HTTP/1.1 200 OK
Date: Wed, 22 Apr 2026 18:23:14 GMT
Content-Type: application/json
Content-Length: 287
Server: Go-http-client/1.1
Access-Control-Allow-Origin: *
Connection: keep-alive
{
"args": {"id": ["42"]},
"headers": { ... },
"origin": "200.100.50.30",
"url": "https://httpbingo.org/get?id=42"
}
💡 Formato dos valores em
argseheaders. O serviçohttpbingo.org(porta Go do clássicohttpbin.org) retorna os valores de query string e cabeçalhos como arrays ("id": ["42"]) porque, em HTTP, a mesma chave pode aparecer múltiplas vezes na URL ou nos cabeçalhos. Essa representação é semanticamente mais correta que o formato escalar usado pelo httpbin original.
| Método | Função | Possui body? | Idempotente? | Seguro? |
|---|---|---|---|---|
GET |
Recuperar representação de um recurso | Não | Sim | Sim |
HEAD |
Como GET, mas só retorna cabeçalhos | Não | Sim | Sim |
POST |
Submeter dados (formulários, APIs) | Sim | Não | Não |
PUT |
Criar/substituir recurso em URI conhecida | Sim | Sim | Não |
PATCH |
Atualização parcial | Sim | Não | Não |
DELETE |
Remover recurso | Opcional | Sim | Não |
OPTIONS |
Descobrir métodos/CORS suportados | Não | Sim | Sim |
Seguro (safe): não altera estado no servidor. Idempotente: múltiplas execuções produzem o mesmo efeito que uma única.
Agrupados por classe (primeiro dígito):
| Classe | Faixa | Significado | Exemplos frequentes |
|---|---|---|---|
| 1xx | 100–199 | Informacional | 100 Continue, 101 Switching Protocols |
| 2xx | 200–299 | Sucesso | 200 OK, 201 Created, 204 No Content |
| 3xx | 300–399 | Redirecionamento | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | 400–499 | Erro do cliente | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | 500–599 | Erro do servidor | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
De request (cliente → servidor):
| Cabeçalho | Propósito |
|---|---|
Host |
Nome de domínio do servidor (obrigatório em HTTP/1.1) |
User-Agent |
Identificação do cliente/navegador |
Accept |
Tipos MIME aceitos na resposta |
Accept-Encoding |
Algoritmos de compressão suportados (gzip, br, deflate) |
Accept-Language |
Idiomas preferidos |
Cookie |
Cookies previamente recebidos |
Authorization |
Credenciais (Basic, Bearer <token>, etc.) |
Referer |
URL de origem da requisição |
Content-Type |
MIME do corpo enviado (em POST/PUT) |
Content-Length |
Tamanho do corpo em bytes quando o tamanho é conhecido antecipadamente |
If-None-Match |
Validação de cache por ETag |
De response (servidor → cliente):
| Cabeçalho | Propósito |
|---|---|
Server |
Identificação do software servidor |
Content-Type |
MIME do corpo retornado |
Content-Length |
Tamanho do corpo em bytes quando o tamanho é conhecido antecipadamente |
Content-Encoding |
Compressão aplicada ao corpo |
Set-Cookie |
Cookie a ser armazenado pelo cliente |
Cache-Control |
Política de cache (no-store, max-age=3600, public) |
ETag |
Identificador de versão do recurso |
Location |
URL para onde redirecionar (usado em 3xx e 201) |
WWW-Authenticate |
Esquema de autenticação exigido (em 401) |
Strict-Transport-Security |
Força uso de HTTPS em acessos futuros (HSTS) |
Um debugging proxy (como Fiddler, mitmproxy, Burp, HTTP Toolkit) é um man-in-the-middle controlado usado conscientemente pelo próprio usuário:
[Navegador] ──► [Proxy local na porta 8888] ──► [Internet] ──► [Servidor]
│
▼
[Interface de inspeção]
Para tráfego HTTPS, o proxy:
- Gera um certificado raiz próprio, instalado pelo usuário no armazenamento de confiança.
- Emite certificados "falsos" assinados por essa raiz para cada site visitado.
- Decifra a comunicação no meio e reencripta antes de enviar.
⚠️ Atenção ética. O certificado raiz do Fiddler, quando instalado, permite a decriptografia de qualquer conexão HTTPS feita pela máquina. Ele deve permanecer apenas na máquina do estudante e ser removido ao final do laboratório — essa exigência está detalhada no roteiro do Fluxo A.
- RFC 9110 — HTTP Semantics. https://datatracker.ietf.org/doc/html/rfc9110
- RFC 9111 — HTTP Caching. https://datatracker.ietf.org/doc/html/rfc9111
- RFC 9112 — HTTP/1.1. https://datatracker.ietf.org/doc/html/rfc9112
- RFC 9113 — HTTP/2. https://datatracker.ietf.org/doc/html/rfc9113
- RFC 6265 — HTTP State Management Mechanism (Cookies). https://datatracker.ietf.org/doc/html/rfc6265
- RFC 6797 — HTTP Strict Transport Security (HSTS). https://datatracker.ietf.org/doc/html/rfc6797
- MDN Web Docs — HTTP. https://developer.mozilla.org/en-US/docs/Web/HTTP
- Fiddler Classic — Documentação oficial. https://docs.telerik.com/fiddler/
- httpbingo.org — Serviço público de teste HTTP em Go. https://httpbingo.org/
- go-httpbin (repositório do serviço acima). https://github.com/mccutchen/go-httpbin
- KUROSE, J.; ROSS, K. Redes de Computadores e a Internet, 8ª ed., Cap. 2 — Camada de Aplicação.
- TANENBAUM, A. S.; FEAMSTER, N.; WETHERALL, D. Redes de Computadores, 6ª ed., Cap. 7 — Camada de Aplicação.
| Cabeçalho | Direção | Exemplo de valor |
|---|---|---|
Host |
Req | www.example.com |
User-Agent |
Req | Mozilla/5.0 (...) |
Accept |
Req | text/html, */*; q=0.1 |
Accept-Encoding |
Req | gzip, deflate, br |
Accept-Language |
Req | pt-BR, pt; q=0.9, en; q=0.5 |
Cookie |
Req | sess=abc123; lang=pt |
Authorization |
Req | Bearer eyJhbGci... |
Referer |
Req | https://origem.com/pagina |
Content-Type |
Ambos | application/json; charset=utf-8 |
Content-Length |
Ambos | 1342 |
If-None-Match |
Req | "686897696a7c876b7e" |
Server |
Resp | Go-http-client/1.1 |
Set-Cookie |
Resp | sess=xyz; Path=/; Secure; HttpOnly |
Cache-Control |
Resp | max-age=3600, public |
ETag |
Resp | "686897696a7c876b7e" |
Location |
Resp | https://destino.com/novo |
Strict-Transport-Security |
Resp | max-age=31536000; includeSubDomains |
Content-Encoding |
Resp | gzip |
WWW-Authenticate |
Resp | Basic realm="Admin" |
| Código | Frase de razão | Quando ocorre |
|---|---|---|
| 100 | Continue | Resposta intermediária a Expect: 100-continue |
| 200 | OK | Requisição bem-sucedida com corpo |
| 201 | Created | Recurso criado (comum em POST/PUT) |
| 204 | No Content | Sucesso sem corpo de resposta |
| 301 | Moved Permanently | Recurso migrou definitivamente |
| 302 | Found | Redirecionamento temporário |
| 304 | Not Modified | Cache do cliente ainda válido |
| 400 | Bad Request | Sintaxe inválida no request |
| 401 | Unauthorized | Autenticação ausente ou inválida |
| 403 | Forbidden | Autenticado mas sem permissão |
| 404 | Not Found | Recurso inexistente |
| 405 | Method Not Allowed | Método não suportado no recurso |
| 408 | Request Timeout | Cliente demorou a enviar |
| 418 | I'm a teapot | RFC 2324 (piada tradicional) |
| 429 | Too Many Requests | Rate limiting |
| 500 | Internal Server Error | Erro genérico do servidor |
| 502 | Bad Gateway | Gateway/proxy recebeu resposta inválida |
| 503 | Service Unavailable | Sobrecarga ou manutenção |
| 504 | Gateway Timeout | Gateway não obteve resposta do upstream |
Versão: 3.0 — Mai/2026 Licença: CC BY-NC-SA 4.0