Como a Internet Funciona

Às 10h00 um fã em São Paulo toca em Comprar num celular ligado ao Wi-Fi de casa. Alguns milissegundos depois, um pod com o endereço 10.20.40.17 cobra o cartão num provedor de pagamento que aceita requisições de exatamente um endereço no mundo. Entre os dois há uma dúzia de roteadores, pelo menos três traduções de endereço e quatro tabelas de rotas — e nenhum deles sabe nada sobre o BoxOffice. Esta página explica esse caminho desde o começo: o que é um endereço IP, por que alguns endereços são públicos e outros privados, como um bloco de endereços é dividido em sub-redes, e como o NAT permite que milhões de dispositivos privados compartilhem poucos endereços públicos. A próxima página constrói a rede do BoxOffice na nuvem sobre essas ideias, e o resto da aula a protege.

Camadas: quem decide o quê

Uma requisição não é uma coisa só no fio. É uma mensagem HTTP dentro de um segmento TCP, dentro de um pacote IP, dentro de um quadro Wi-Fi ou Ethernet. Cada camada tem o seu endereço e responde a uma pergunta diferente:

flowchart LR
    subgraph F["quadro Wi-Fi (MAC → MAC): reescrito a cada salto"]
        subgraph P["pacote IP: origem 192.168.0.12 → destino 203.0.113.10"]
            subgraph T["segmento TCP: porta 51514 → 443"]
                H["HTTP: POST /orders (dentro do TLS)"]
            end
        end
    end

Dois fatos saem da figura e explicam quase toda esta página:

• Roteadores olham só o cabeçalho IP. Nunca leem a URL; o IP de destino decide o caminho. O quadro em volta do pacote é descartado e refeito a cada salto.
• Portas são da camada de transporte, mas dispositivos de NAT e firewalls também as leem: é assim que um endereço público é compartilhado, e é assim que um security group libera a 5432 e recusa a 22.

Como um pacote atravessa a Internet

A Internet é uma rede de redes: dezenas de milhares de sistemas autônomos (AS) — operadoras, universidades, provedores de nuvem, grandes empresas — cada um com os seus roteadores e os seus blocos de endereços. Cada AS anuncia os seus blocos aos vizinhos com BGP (Border Gateway Protocol)¹: "mande para mim os pacotes de 203.0.113.0/24". Os anúncios se propagam até que cada roteador do núcleo tenha rotas para cerca de um milhão de prefixos IPv4.

Nenhum roteador conhece o caminho inteiro. Cada um faz a mesma coisa com cada pacote:

1. Lê o IP de destino.
2. Encontra na sua tabela a rota mais específica que o contém (maior prefixo, longest prefix match: uma rota para um /24 vence uma rota para um /16, que vence a rota padrão 0.0.0.0/0).
3. Envia o pacote ao próximo salto dessa rota e decrementa o TTL do pacote (um contador de saltos que mata pacotes presos em laços).

Aperte play para seguir um pacote do celular do fã até o BoxOffice (os endereços são exemplos de documentação²):

sequenceDiagram
    autonumber
    participant P as Celular 192.168.0.12
    participant R as Roteador de casa (NAT)
    participant C as Operadora (AS do provedor)
    participant X as Trânsito / ponto de troca
    participant E as Borda do provedor de nuvem
    participant G as Internet gateway (VPC)
    participant L as Load balancer 10.20.0.10
    P->>R: destino 203.0.113.10 fora de 192.168.0.0/24 → gateway padrão
    R->>C: NAT: a origem vira 198.51.100.7 (o IP público da casa)
    C->>X: maior prefixo para 203.0.113.10: rota aprendida por BGP
    X->>E: próximo salto: a rede que anunciou 203.0.113.0/24
    E->>G: dentro do provedor: a VPC dona de 203.0.113.10
    G->>L: NAT 1:1: o destino 203.0.113.10 vira 10.20.0.10
    L-->>P: a resposta passa pelas mesmas traduções, ao contrário

Rode traceroute (Linux, macOS) ou tracert (Windows) para qualquer site: cada linha da saída é um roteador desta lista, com o seu tempo de ida e volta. Um caminho típico tem de 10 a 20 saltos; o tempo é dominado pela distância (a luz na fibra percorre cerca de 200 km por milissegundo), não pelo número de roteadores — é por isso que a borda coloca CDNs perto dos fãs.

Endereços IP e CIDR

Um endereço IPv4 é um número de 32 bits, escrito como quatro octetos decimais: 10.20.40.17 é 00001010.00010100.00101000.00010001. Todo endereço tem duas partes:

• a parte de rede (os primeiros n bits) diz em qual rede o host está — é o que os roteadores comparam;
• a parte de host (os outros 32 − n bits) diz qual host dentro dessa rede.

A notação CIDR (Classless Inter-Domain Routing)³ escreve a divisão depois de uma barra: 10.20.0.0/16 é "os 2³²⁻¹⁶ = 65 536 endereços que começam com os mesmos 16 bits de 10.20.0.0". Cada bit a mais no prefixo divide o bloco ao meio: um /17 é metade de um /16, um /24 tem 256 endereços, um /32 é um único host. A mesma divisão às vezes é escrita como máscara: /16 é 255.255.0.0. Numa rede clássica o primeiro endereço do bloco nomeia a rede e o último é o de broadcast, então um /24 tem 254 hosts utilizáveis; a AWS reserva 5 endereços em cada sub-rede.

Experimente:

1. O explorador começa com 10.20.40.17/19. Os bits de host não são zero, então o explorador mostra o bloco que contém este endereço: 10.20.32.0/19, a sub-rede privada de aplicação do BoxOffice na AZ a. Arraste o prefixo de /19 até /24 e veja o bloco cair pela metade a cada passo.
2. Digite 10.20.0.0/16, escolha Dividir em 4 sub-redes e teste o endereço 10.20.40.17: em qual dos quatro blocos /18 ele cai?
3. Clique nos exemplos: 192.168.0.12 (a sua casa), 100.64.7.9 (o NAT da sua operadora de celular), 169.254.169.254 (o serviço de metadados da nuvem), 8.8.8.8 (público). A linha tipo do endereço diz quais a Internet consegue rotear.

Endereços públicos e privados

Trinta e dois bits dão 2³² ≈ 4,3 bilhões de endereços — menos do que os celulares em uso hoje, sem contar servidores, carros e lâmpadas. Os registros distribuíram os últimos blocos IPv4 livres entre 2011 e 2019. A Internet sobreviveu com duas ideias:

• Alguns blocos são privados (RFC 1918)⁴: qualquer rede pode usá-los internamente, quantas vezes quiser, e ninguém os roteia na Internet.
• O NAT (próxima seção) permite que muitos hosts privados compartilhem um endereço público, único no mundo e anunciado por BGP.

Os tamanhos são calculados a partir dos prefixos:

Um endereço público é o que torna um host alcançável a partir da Internet: alguém anuncia o seu bloco, então os pacotes para ele encontram uma rota. Um endereço privado só é alcançável dentro da própria rede e através do que traduz ou roteia para dentro dela. No BoxOffice, só duas coisas têm endereço público — o load balancer (para receber os fãs) e o NAT gateway (para chamar o provedor de pagamento de um endereço fixo). Todo serviço, pod e banco tem apenas um endereço privado.

NAT: muitos hosts privados atrás de um endereço público

O NAT (Network Address Translation) reescreve endereços no cabeçalho IP quando os pacotes atravessam um dispositivo. A forma mais comum, o NAT de origem (também chamado PAT ou masquerading), é o que fazem o roteador da sua casa, a sua operadora de celular e o NAT gateway da nuvem: trocam a origem privada de cada pacote que sai pelo seu próprio endereço público e uma porta livre, e anotam o par numa tabela de tradução.

sequenceDiagram
    autonumber
    participant P as Celular 192.168.0.12
    participant N as Roteador de casa (NAT) público 198.51.100.7
    participant S as Servidor 203.0.113.10
    participant A as Alguém na Internet
    P->>N: origem 192.168.0.12:51514 → destino 203.0.113.10:443
    Note over N: tabela: 192.168.0.12:51514 ⇄ 198.51.100.7:40001
    N->>S: origem 198.51.100.7:40001 → destino 203.0.113.10:443
    S-->>N: resposta para 198.51.100.7:40001
    Note over N: achou na tabela → volta para 192.168.0.12:51514
    N-->>P: resposta entregue
    A->>N: uma conexão nova para 198.51.100.7:22
    Note over N: nenhuma entrada para a porta 22 → descartado

Quatro consequências aparecem o tempo todo em design de sistemas:

1. Conexões só começam de dentro. Um host de fora pode responder, mas não pode abrir uma conexão nova: não há entrada na tabela que diga ao NAT para onde mandá-la. É por isso que os pods numa sub-rede privada conseguem chamar o provedor de pagamento enquanto ninguém na Internet consegue chamá-los.
2. O servidor vê o NAT, não o cliente. Milhares de fãs atrás de um NAT de operadora chegam ao BoxOffice com o mesmo IP. Um limite de taxa por IP bloquearia um bairro inteiro às 10h00 — a razão pela qual a borda limita por chave de API ou por usuário e trata limites por IP como uma defesa grosseira.
3. Um NAT dá um endereço de saída estável. Os pods mudam de nó e os seus IPs mudam, mas tudo o que mandam para a Internet sai com o IP público fixo do NAT — o que o BoxOffice registra na lista de permissões do provedor de pagamento (redes em nuvem).
4. O NAT de destino publica um serviço privado. A reescrita inversa — "pacotes para a minha :443 pública vão para este host privado" — é o que fazem um load balancer, um internet gateway da nuvem (NAT 1:1 para IPs públicos) e o ports: "80:80" do Docker.

Um NAT também tem capacidade: cada conexão para o mesmo destino precisa da sua própria porta pública, e um endereço público tem no máximo 65 535. Um NAT gateway da AWS suporta até 55 000 conexões simultâneas para cada destino único⁶ — um limite real quando centenas de pods chamam a mesma API de pagamento durante uma abertura de vendas.

Sub-redes e o gateway

Um host não roteia pacotes como o núcleo da Internet. A sua configuração de rede tem só três números — o seu endereço, o seu prefixo e o seu gateway padrão (mais um servidor DNS) — e ele toma uma decisão para cada pacote:

flowchart TD
    A["pacote para o destino"] --> B{"o destino está dentro da<br/>minha sub-rede (endereço/prefixo)?"}
    B -->|"sim"| C["descobre o MAC do destino (ARP)<br/>e envia diretamente"]
    B -->|"não"| D["envia ao gateway padrão<br/>(o roteador da sub-rede)"]
    D --> E["o roteador consulta a tabela de rotas:<br/>maior prefixo → próximo salto"]
    E --> F["…até que um roteador o entregue<br/>dentro da sub-rede do destino"]

Uma sub-rede é, portanto, um bloco de endereços cujos hosts falam diretamente entre si; todo o resto passa por um roteador. Os projetos dividem o espaço de endereços em sub-redes por três razões:

• Posicionamento: na nuvem uma sub-rede vive numa zona de disponibilidade, então uma sub-rede por zona permite espalhar réplicas e perder uma zona sem perder um serviço.
• Política de roteamento: cada sub-rede tem uma tabela de rotas, e é a tabela que a torna pública (uma rota para um internet gateway), privada (uma rota para um NAT) ou isolada (nenhuma rota para fora).
• Raio de impacto e regras: firewalls e flow logs são associados por sub-rede; um erro numa camada não abre as outras.

Uma tabela de rotas é uma lista de bloco de destino → alvo. Toda tabela numa VPC tem a rota local para o próprio bloco da VPC; o resto decide a camada:

Quando um pacote para 10.20.8.10 sai de uma sub-rede privada, as duas rotas "o contêm" (0.0.0.0/0 contém tudo), e o maior prefixo vence: /16 vence /0, então ele fica dentro da VPC.

O caminho do pacote: a VPC do BoxOffice

Agora junte as peças. O simulador abaixo é uma versão pequena da rede do BoxOffice (uma zona de disponibilidade): uma sub-rede pública com o load balancer e o NAT gateway, uma sub-rede privada com os pods order e payment, e uma sub-rede isolada com o PostgreSQL. Cada passo mostra onde o pacote está, a sua origem e o seu destino (os campos que acabaram de mudar ficam destacados), a tabela de rotas ou o security group consultado, e a linha que casou.

Experimente:

1. Um fã abre o site. Conte as reescritas de endereço: o roteador de casa troca a origem (privado → público), o internet gateway troca o destino (público → o endereço privado do load balancer). Depois o load balancer abre uma segunda conexão, dentro da VPC, até o order.
2. payment chama o provedor. O endereço privado do pod, 10.20.40.17, é reescrito duas vezes na saída (NAT, depois internet gateway); o provedor vê só 203.0.113.20 e o encontra na lista de permissões. Siga a resposta de volta pela tabela do NAT.
3. Um fã tenta acessar um pod diretamente. O pacote nunca chega ao BoxOffice: nenhum roteador da Internet tem rota para um endereço privado.
4. Quebre a rede. Desmarque rota 0.0.0.0/0 → NAT e rode de novo o cenário 2; desmarque sg-data aceita 5432 e rode order consulta o PostgreSQL; desmarque o load balancer tem IP público e rode o cenário 1. Cada interruptor é um erro de configuração real que já derrubou sites.
5. Scanners. Tente a porta 5432 no IP do NAT e no IP do load balancer: um é descartado pelo NAT (sem tradução), o outro por um security group.

# three identical replicas; no "ports:" — only the edge is reachable from outside
catalog-1:
  <<: *catalog
  hostname: catalog-1
catalog-2:
  <<: *catalog
  hostname: catalog-2
catalog-3:
  <<: *catalog
  hostname: catalog-3

edge:
  image: nginx:1.30-alpine
  ports:
    - "80:80"
  volumes:
    - ./infra/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
  depends_on:
    - catalog-1
    - catalog-2
    - catalog-3

resolver  127.0.0.11  valid=10s  ipv6=off;

upstream catalog {
    zone catalog 64k;                 # shared memory, required by "resolve"
    # least_conn;                     # try it: pick the replica with fewest active requests
    server catalog-1:8082 resolve max_fails=3 fail_timeout=10s;
    server catalog-2:8082 resolve max_fails=3 fail_timeout=10s;
    server catalog-3:8082 resolve max_fails=3 fail_timeout=10s;

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: boxoffice
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30080   # NodePort of the Ingress controller (Traefik)
        hostPort: 80           # http://localhost
        protocol: TCP
  - role: worker
  - role: worker

IPv6 em um parágrafo

Endereços IPv6 têm 128 bits (2¹²⁸ ≈ 3,4 × 10³⁸), escritos em grupos hexadecimais como 2001:db8:20::17. Há o suficiente para cada dispositivo ter um endereço roteável globalmente, então redes IPv6 normalmente não usam NAT — o que significa que, com IPv6, um pod poderia ser alcançável a partir da Internet, e só as tabelas de rotas e os firewalls (security groups) decidem se ele é. Nuvens e operadoras rodam dual-stack (IPv4 e IPv6 lado a lado), e o IPv4 público virou um recurso cobrado: desde fevereiro de 2024 a AWS cobra por todo endereço IPv4 público, em uso ou não⁷. As ideias de projeto desta página — sub-redes, tabelas de rotas, maior prefixo, firewalls — são as mesmas no IPv6.

Como se conecta

flowchart LR
    L["camadas: quadro, pacote,<br/>segmento, requisição"] --> IP["endereço IP:<br/>bits de rede + host (CIDR)"]
    IP --> PP["público vs privado<br/>(RFC 1918, CGNAT)"]
    PP --> NAT["NAT: endereço público compartilhado,<br/>IP de saída estável"]
    NAT --> RL["limites por IP são injustos<br/>→ Borda: rate limiting"]
    IP --> SUB["sub-redes + gateway padrão"]
    SUB --> RT["tabelas de rotas:<br/>maior prefixo"]
    RT --> VPC["pública / privada / isolada<br/>→ Redes em nuvem"]
    BGP["BGP: redes anunciam prefixos"] --> RT
    PP --> ZT["privado ≠ confiável<br/>→ Zero Trust"]
    VPC --> SG["security groups<br/>→ Redes em nuvem"]

Componentes da paleta: vpc · subnet · nat · lb (o único endereço público que recebe tráfego) · dns (o nome que leva até ele). Continua em: Redes em nuvem (a VPC do BoxOffice, security groups, endpoints), Borda — a jornada da requisição e rate limiting, Zero Trust, Hands-on 3 e Hands-on 10.

Pontos-chave