TCP, UDP e IP
As camadas de transporte abaixo do HTTP, e a troca entre entrega garantida e baixa latência.
As camadas abaixo do HTTP
Quando o código faz um pedido HTTP, várias camadas trabalham por baixo, cada uma resolvendo um problema e se apoiando na de baixo:
| Camada | Exemplo | Resolve |
|---|---|---|
| Aplicação | HTTP, gRPC, o protocolo do PostgreSQL | O significado da conversa: pedidos, respostas, consultas |
| Transporte | TCP, UDP, QUIC | Como os dados de um programa chegam a outro programa |
| Rede | IP | Como um pacote chega de uma máquina a outra, atravessando roteadores |
| Enlace | Ethernet, Wi-Fi | Como os bits passam de um equipamento ao vizinho |
Este tópico trata das duas camadas do meio. Elas ficam escondidas pelas bibliotecas, mas o comportamento delas aparece em tempos de resposta, conexões presas e mensagens que chegam pela metade.
IP: entregar pacotes, sem promessas
O IP (Internet Protocol) dá um endereço a cada máquina e leva pacotes de um endereço a outro, passando por roteadores. Cada pacote é tratado sozinho: dois pacotes do mesmo envio podem seguir caminhos diferentes.
O IP faz o melhor que pode, e só isso. Um pacote pode:
- se perder, num roteador sobrecarregado ou num cabo com interferência;
- chegar duplicado;
- chegar fora de ordem, por ter seguido um caminho mais curto;
- chegar corrompido, e ser descartado.
Nenhum desses problemas é avisado a quem enviou. Construir algo confiável em cima disso é o trabalho da camada de transporte.
Além do endereço da máquina, a camada de transporte usa a porta para saber a qual programa entregar: o PostgreSQL escuta na 5432, o HTTP na 80, o HTTPS na 443. Uma conexão é identificada pelo par de endereços e portas das duas pontas.
TCP: um canal confiável
O TCP (Transmission Control Protocol) transforma pacotes sem garantia num canal confiável entre dois programas. Ele promete:
| Garantia | Como ele consegue |
|---|---|
| Tudo chega | Cada pedaço enviado é confirmado pelo outro lado; o que não é confirmado a tempo é reenviado |
| Em ordem | Os bytes são numerados, e o receptor os reorganiza antes de entregar ao programa |
| Sem duplicatas | A numeração permite descartar o que chegou duas vezes |
| Sem afogar o receptor | O receptor informa quanto ainda cabe; o emissor não manda mais que isso (controle de fluxo) |
| Sem afogar a rede | O emissor reduz o ritmo quando percebe perdas (controle de congestionamento) |
Medimos a garantia de entrega num container com 10% de perda de pacotes simulada. O TCP entregou as 1.000 mensagens enviadas, todas em ordem. O UDP, no mesmo cenário, entregou entre 884 e 899.
O preço: abrir a conexão
Antes de trocar dados, as duas pontas do TCP trocam três mensagens para combinar a numeração e abrir a conexão (o three-way handshake):
cliente servidor
│ ── SYN ────────────────────────────▶ │ "quero conversar"
│ ◀──────────────────────── SYN-ACK ── │ "pode falar"
│ ── ACK + primeiro pedido ──────────▶ │Isso custa uma ida e volta inteira pela rede antes do primeiro byte útil. Com HTTPS, a negociação TLS acrescenta mais uma ou duas idas e voltas.
Medimos com uma latência simulada de 50 milissegundos de ida e volta, típica entre regiões próximas:
| Operação | Tempo |
|---|---|
| Só abrir a conexão TCP | 51 ms |
| 20 pedidos HTTP, abrindo uma conexão nova a cada um | 2.083 ms |
| 20 pedidos HTTP, reaproveitando a mesma conexão | 1.033 ms |
Reaproveitar a conexão cortou o tempo pela metade: cada pedido passou a custar uma ida e volta, em vez de duas. Na mesma máquina, sem atraso, a diferença foi de 15 para 7 milissegundos, e ninguém repara. É por isso que esse problema só aparece em produção.
O TCP é um fluxo de bytes
Um ponto que confunde muita gente: o TCP não entrega mensagens, entrega um fluxo contínuo de bytes. Ele junta ou divide os dados como achar melhor para a rede.
Testamos com 1.000 chamadas a write() de pequenas mensagens numa conexão local. Do outro lado, os dados chegaram numa única leitura, com os 12.890 bytes juntos. Numa rede real, o contrário também acontece: uma mensagem grande chega dividida em várias leituras.
Por isso, todo protocolo construído sobre TCP precisa dizer onde termina cada mensagem:
| Técnica | Exemplo |
|---|---|
| Um delimitador | Uma quebra de linha no fim de cada mensagem, como no SMTP e no Redis |
| O tamanho antes dos dados | Os primeiros bytes dizem quantos bytes vêm a seguir, como no gRPC e no protocolo do PostgreSQL |
| Um cabeçalho com o tamanho | O Content-Length do HTTP |
Um código que lê do soquete e trata cada leitura como uma mensagem completa funciona nos testes locais e quebra em produção, com mensagens coladas ou cortadas. O nível Implementação mostra a leitura correta.
UDP: rápido, sem promessas
O UDP (User Datagram Protocol) é quase o IP puro, com portas. Cada envio é um datagrama independente, que chega inteiro ou não chega.
| TCP | UDP | |
|---|---|---|
| Conexão | Aberta antes de enviar | Nenhuma: envia direto |
| Entrega | Garantida, com retransmissão | Sem garantia |
| Ordem | Garantida | Nenhuma |
| Limites das mensagens | Não existem: é um fluxo de bytes | Preservados: um envio, um datagrama |
| Controle de fluxo e congestionamento | Sim | Não |
| Custo por mensagem | Maior | Mínimo |
A falta de controle de fluxo apareceu no nosso teste. Na primeira tentativa, enviando os 1.000 datagramas sem pausa, só 221 chegaram, embora a perda simulada fosse de 10%. O resto foi descartado porque o receptor não deu conta do ritmo, e o UDP não reduz a velocidade por conta própria. Com uma pequena pausa entre os envios, a perda voltou a ficar perto dos 10% da rede.
Para que serve o UDP
Para casos em que um dado atrasado é tão inútil quanto um dado perdido, ou em que a própria aplicação quer controlar a confiabilidade:
- DNS: uma pergunta e uma resposta pequenas; se não vier, pergunta-se de novo.
- Voz, vídeo e jogos em tempo real: reenviar o áudio de meio segundo atrás não ajuda; melhor seguir em frente.
- Métricas e telemetria: perder uma amostra entre milhares não importa.
- QUIC e HTTP/3: constroem a sua própria confiabilidade em cima do UDP, sem os limites do TCP. O tópico de HTTP compara as versões.
Por que isso importa quando a IA escreve o código
Assistentes usam bibliotecas que escondem o TCP, e os problemas aparecem nas bordas:
- Um cliente HTTP ou de banco criado a cada chamada abre uma conexão nova a cada pedido, e paga o handshake toda vez.
- Um protocolo próprio sobre soquete trata cada leitura como uma mensagem inteira.
- Não há tempo limite na conexão, e um servidor que parou de responder prende o cliente indefinidamente.
- Um envio por UDP é tratado como se tivesse chegado.
O próximo nível compara as escolhas de transporte e as configurações que mais afetam o backend.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
TCP e UDP em cinco minutos
Explique em no máximo cinco minutos de leitura o que são IP, TCP e UDP, para alguém que programa mas nunca olhou abaixo do HTTP. Cubra só o essencial: o que o IP faz e o que ele não garante, o que o TCP acrescenta, o que é o handshake e quanto ele custa, e quando o UDP é a melhor escolha. Use uma analogia simples. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
As camadas de um pedido HTTP
Quero entender o que acontece abaixo de um pedido HTTP, camada por camada. Aja como um mentor de redes. Pergunte primeiro qual é a minha experiência. Acompanhe um pedido HTTPS do meu backend para uma API externa e explique, uma camada por vez: 1. A camada de aplicação: o texto do pedido HTTP. 2. O TLS. 3. O TCP: portas, o handshake, a numeração dos bytes e as confirmações. 4. O IP: endereços, pacotes e roteadores. 5. O enlace: como os bits passam de um equipamento ao vizinho. Em cada camada, diga o que ela garante, o que ela acrescenta de custo e que tipo de problema aparece se ela falhar. Faça uma pergunta de verificação ao fim de cada camada.
Como o TCP garante a entrega
Quero entender os mecanismos do TCP por dentro. Explique, com diagramas em texto: 1. O handshake de três vias e por que ele existe. 2. A numeração dos bytes, as confirmações e a retransmissão. 3. Como o receptor reorganiza bytes fora de ordem. 4. O controle de fluxo e a janela do receptor. 5. O controle de congestionamento e por que a velocidade cai quando há perdas. 6. O encerramento da conexão e o estado TIME_WAIT. Depois de cada mecanismo, me faça uma pergunta de cenário (por exemplo: "um pacote do meio se perde; o que o receptor faz com os pacotes seguintes?") e corrija a minha resposta.
TCP é um fluxo de bytes
Quero entender por que o TCP não preserva os limites das mensagens, e o que isso significa para quem lê de um soquete. Explique: 1. A diferença entre um fluxo de bytes e uma sequência de mensagens. 2. Por que várias escritas podem chegar numa única leitura, e uma escrita pode chegar em várias leituras. 3. As técnicas de delimitação: delimitador, tamanho antes dos dados e cabeçalho com tamanho, com exemplos de protocolos reais que usam cada uma. 4. Os riscos de segurança de cada técnica. Depois me mostre três trechos de código que leem de um soquete e pergunte qual deles quebra com mensagens coladas ou cortadas. Corrija as minhas respostas.