Redes:
a base que
tudo assume

1.1 As quatro que interessam

1.2 As abstrações vazam

Cada camada esconde a de baixo, e esconde quase sempre. Quando falha, falha de formas que só se percebem sabendo o que está por baixo:

• Uma ligação TCP "aberta" pode já não existir. Se o cabo foi desligado, nenhum dos lados sabe até tentar enviar algo. A ligação é uma ficção partilhada, não um objeto físico.
• Uma aplicação que "não responde" pode estar a responder — e a resposta a ser descartada a meio do caminho por um equipamento que ninguém sabia que estava lá (cap. 8).
• Um pedido lento pode não ser lento. Pode ser um pacote perdido e a retransmissão a demorar (cap. 3).
• Um nome que "não resolve" pode resolver noutra máquina, porque a resposta veio de uma cache diferente (cap. 4).

1.3 O que uma mensagem carrega

Duas consequências práticas: há um custo fixo por mensagem — dezenas de bytes de cabeçalhos, que dominam quando as mensagens são pequenas — e cada camada só vê o seu cabeçalho, o que explica porque um equipamento de rede pode encaminhar tráfego que não consegue ler.

1.4 O que esta apostila é

2.1 O endereço tem duas partes

Um endereço divide-se em parte de rede e parte de máquina, e a fronteira é dada pela máscara. Escreve-se junto: 192.168.1.10/24 significa que os primeiros 24 bits identificam a rede.

2.2 Endereços privados, e a tradução que mudou a internet

Certas gamas — 10.x, 172.16–31.x, 192.168.x — são reservadas para redes internas e não são encaminhadas na internet. Milhões de redes usam as mesmas.

Para essas máquinas saírem, existe a tradução de endereços: o router substitui o endereço privado pelo seu público, guarda a correspondência, e traduz de volta na resposta.

2.3 IPv6, em três pontos

• Existe porque os endereços de 32 bits acabaram. IPv6 usa 128 bits — endereços suficientes para não voltar a acontecer.
• Devolve o endereçamento direto: cada dispositivo pode ter endereço público, sem tradução. Isso simplifica muito e obriga a levar a sério a filtragem, porque deixa de haver a proteção acidental do NAT.
• A adoção é lenta e parcial. Na prática convive-se com os dois — o que significa que um serviço pode estar acessível por um e não pelo outro, e que «funciona no meu computador» pode ser literalmente uma questão de versão de protocolo.

2.4 Portas: o que distingue conversas

O endereço leva à máquina; a porta leva ao programa. Um servidor com um só endereço atende centenas de serviços porque cada um escuta numa porta diferente — 443 para HTTPS, 22 para SSH, 5432 para uma base de dados.

3.1 O que o TCP faz por si

• Estabelece a ligação com uma troca de três mensagens antes de qualquer dado — o que custa um tempo de ida e volta completo antes de enviar o primeiro byte.
• Numera os segmentos e reordena-os na chegada. O que sai desordenado chega ordenado.
• Confirma e retransmite. O que não for confirmado é reenviado, ao fim de um tempo estimado.
• Controla o ritmo. Começa devagar e acelera enquanto não houver perdas; ao detetar perda, abranda bruscamente.

3.2 O bloqueio de cabeça de fila

3.3 UDP: quando não garantir é melhor

3.4 O que isto custa em tempo

Daqui saem duas das melhores otimizações que existem, e nenhuma exige mais largura de banda: reutilizar ligações em vez de abrir uma por pedido, e aproximar o servidor do utilizador para reduzir o tempo de ida e volta (cap. 7).

4.1 Como uma resposta é encontrada

Três ideias que decorrem daqui: é hierárquico (ninguém sabe tudo), é delegado (cada nível aponta para o seguinte) e vive de cache — sem ela, a internet não funcionaria a esta escala.

4.2 Os registos que aparecem no dia a dia

4.3 "Propagação" não existe

4.4 Porque o DNS é a suspeita habitual

• Está no caminho de tudo e ninguém pensa nele até falhar.
• Falha de forma assimétrica. Funciona numa máquina e não noutra, porque usam resolvedores diferentes com caches diferentes. Produz o clássico "no meu computador funciona" com causa real.
• Cache negativa. Uma resposta "não existe" também é guardada. Criar o registo não corrige imediatamente — é preciso esperar que a resposta negativa expire.
• A ordem de resolução do sistema não é só DNS: ficheiros locais e outros mecanismos vêm antes, e uma entrada esquecida num ficheiro de máquinas explica comportamentos que nenhuma consulta ao DNS reproduz.
• Dentro de contentores é outro mundo. Resolvedor próprio, domínios de pesquisa próprios, nomes de serviço internos. Metade dos problemas de rede em orquestração são de resolução de nomes (DevOps).

4.5 O que fazer bem, e custa pouco

• TTL curto antes de mudar; longo em regime estável. Longo reduz carga e latência; curto dá agilidade. Não é preciso escolher — muda-se conforme o momento.
• Mais do que um servidor autoritativo, e de preferência em redes distintas. Perder o DNS é perder tudo, mesmo com os servidores de aplicação vivos.
• Vigie a validade do domínio. Um domínio que expira derruba tudo — correio incluído — e é a falha mais evitável que existe.
• Publique um registo CAA. Duas linhas, e limita quem pode emitir certificados em seu nome.

5.1 Não tem memória

5.2 Os métodos, e a propriedade que interessa

5.3 Os códigos que dizem alguma coisa

• 2xx — correu bem. 201 criou, 204 correu bem e não há corpo.
• 3xx — está noutro sítio. 301 permanente (as caches guardam-no agressivamente: um 301 errado é difícil de corrigir), 302 temporário, 304 "não mudou, usa o que tens".
• 4xx — o pedido está mal. 401 não se identificou, 403 identificou-se e não pode, 404 não existe, 429 demasiados pedidos.
• 5xx — o servidor falhou. 502 e 504 vêm quase sempre de um intermediário: o que está à frente não conseguiu falar com o que está atrás (cap. 8). É informação valiosa sobre onde falhou.

5.4 Cache: a otimização com melhor retorno

5.5 As versões, em uma linha cada

• HTTP/1.1 — uma resposta de cada vez por ligação. Daí o hábito antigo de juntar ficheiros e abrir várias ligações em paralelo.
• HTTP/2 — vários fluxos na mesma ligação. Elimina a necessidade de juntar ficheiros, e mantém o bloqueio de cabeça de fila do TCP por baixo (cap. 3).
• HTTP/3 — o mesmo sobre QUIC, sem esse bloqueio, e com estabelecimento mais rápido.

A implicação prática: otimizações que faziam sentido em HTTP/1.1 podem prejudicar em HTTP/2 e 3. Juntar tudo num ficheiro gigante deixou de ser vantagem e passou a impedir cache parcial.

6.1 As três garantias

6.2 A cadeia de confiança

É a causa de uma classe inteira de problemas com um sintoma característico: o navegador aceita e a chamada a partir de um servidor rejeita. Não é um problema do cliente; é uma cadeia incompleta.

6.3 O que fica visível apesar da cifra

6.4 Certificados na prática

• Automatize a renovação. Certificados expiram, e a expiração é das causas mais frequentes de indisponibilidade — e das mais evitáveis. Renovação automática, com alerta se falhar.
• Vigie o prazo como métrica. Não confie em receber o email de aviso.
• Um certificado por serviço público. Certificados com muitos nomes concentram risco: revogar um afeta todos.
• Internamente também. Serviços internos merecem TLS. "É rede interna" pressupõe que ninguém entra — e o desenho moderno pressupõe o contrário (CyberDevSecOps).

6.5 Terminação: onde a cifra acaba

Em quase todas as arquiteturas, o TLS termina num equipamento à frente — um balanceador ou uma rede de distribuição — e o tráfego segue depois para os servidores. Isso é normal e tem duas consequências que convém ter presentes:

• Quem termina o TLS vê tudo em claro. É um ponto de confiança real, e deve ser tratado como tal.
• O troço interno pode ir sem cifra. Decida-o em consciência, e não por omissão.

7.1 A distinção

7.2 Onde a latência se multiplica

Um tempo de ida e volta isolado é irrelevante. O problema é quando se acumulam:

• Pedidos em cadeia são o inimigo. Cada dependência multiplica a latência. Paralelizar o que for independente é a otimização mais rentável que existe.
• O mesmo vale dentro do servidor. Trinta consultas a uma base de dados, uma de cada vez, com 2 ms cada, são 60 ms — que aparecem ao utilizador como lentidão da aplicação.
• Redes móveis acrescentam dezenas de milissegundos antes de qualquer coisa acontecer, e mais ainda se o rádio estiver adormecido. É por isso que uma aplicação rápida no escritório é lenta na rua (IoT).

7.3 Quando mais banda deixa de ajudar

7.4 O que fazer, por ordem de retorno

1. Reduzir o número de idas e voltas. Reutilizar ligações, paralelizar, juntar o que é sempre pedido em conjunto.
2. Aproximar o conteúdo. Cache na periferia da rede, perto de quem pede.
3. Não pedir nada. A ida e volta mais rápida é a que não acontece — cache no cliente com validade longa (cap. 5).
4. Comprimir. Ajuda quando o conteúdo é grande; irrelevante quando são muitos recursos pequenos.
5. Mais banda. Último da lista, e o primeiro que costuma ser proposto.

8.1 O percurso típico

Cada um destes pode: atrasar, alterar cabeçalhos, terminar a ligação, responder por si, ou descartar em silêncio. E o último é o que produz os problemas mais difíceis.

8.2 O que cada um faz

8.3 O endereço de quem pediu

Com intermediários no caminho, a aplicação vê o endereço do último equipamento, não o do utilizador. Por isso existe a convenção de acrescentar o endereço original num cabeçalho.

8.4 Verificações de saúde: o detalhe que decide

Um balanceador retira do serviço as instâncias que considera doentes. O que ele pergunta determina a fiabilidade do conjunto:

• Uma verificação superficial — "o processo responde?" — mantém em serviço uma instância que perdeu a ligação à base de dados.
• Uma verificação profunda — que testa dependências — corre o risco oposto: se a base de dados oscila, todas as instâncias são consideradas doentes ao mesmo tempo e o serviço inteiro sai de circulação.
• A prática que resolve: distinguir estou vivo de estou pronto a receber tráfego, e ter cuidado para que a segunda não dependa de algo partilhado por todos. Vale a pena ler isto ao lado de Observabilidade & SRE.

10.1 A escada

10.2 As perguntas que estreitam depressa

10.3 As ferramentas, e o que cada uma responde

• Consulta de DNS — o que responde, de que servidor, com que TTL. Pergunte a dois resolvedores diferentes.
• Traçado de rota — por onde passa e onde para. Interprete com cuidado: muitos equipamentos não respondem e aparecem como falhas que não são.
• Cliente HTTP com detalhe — mostra resolução, ligação, TLS, cabeçalhos e tempos, tudo numa linha de comando. É a ferramenta mais útil da lista.
• Cliente TLS direto — para ver o certificado exatamente como o servidor o envia, incluindo se a cadeia vai completa.
• Estado das ligações locais — quantas abertas, em que estado, quantas à espera. Revela esgotamento de portas e ligações penduradas.
• Captura de pacotes — o último recurso, e o que dá a verdade quando tudo o resto é ambíguo.

10.4 Registar o que interessa

11.1 As oito falhas que se repetem

11.2 A tempestade de repetições, em detalhe

11.3 Tempos limite: os números que ninguém escolhe

• Por omissão, são quase sempre demasiado longos — por vezes minutos. Um pedido de utilizador que espera 60 segundos já falhou aos 3, do ponto de vista de quem espera.
• Devem diminuir para dentro. Se o utilizador espera no máximo 5 s, a chamada interna não pode ter 10 s de limite — senão o utilizador desiste enquanto o sistema continua a trabalhar para ninguém.
• São vários, e distintos: abrir a ligação, receber o primeiro byte, e concluir. Confundi-los produz comportamentos difíceis de explicar.
• Sem tempo limite, não há falha — há bloqueio. E um bloqueio propaga-se: o serviço que espera fica ele próprio indisponível, e assim sucessivamente.

11.4 O que se assume e não é verdade

11.5 Falhar de forma útil

• Degradar em vez de cair. Se o serviço de recomendações não responde, mostre a página sem recomendações. Uma dependência não essencial não deve derrubar o essencial.
• Falhar depressa. Um erro em 200 ms é melhor que um sucesso em 30 s, porque liberta recursos e permite tentar outra coisa.
• Dizer o que aconteceu. Um erro que distingue "não te consegui alcançar" de "alcancei e recusou" poupa horas a quem diagnostica (UX Writing, cap. 5).
• Isolar. Conjuntos de ligações separados por dependência impedem que um serviço lento consuma todos os recursos e leve o resto com ele.

12.1 As seis ideias

12.2 A lista de verificação de um serviço exposto

12.3 O que ler a seguir

• DevOps, Docker & Kubernetes — rede de contentores, serviços e resolução interna, onde metade dos problemas é o capítulo 4.
• Observabilidade & SRE — os quatro campos de registo do capítulo 10, à escala de um sistema.
• CyberDevSecOps — o que fazer com o que o capítulo 6 deixa visível.
• Arquitetura & System Design e API Design — idempotência, tempos limite e degradação como decisões de desenho.
• Caching & Redis — a otimização do capítulo 7, a sério.
• Robótica, IoT e Embarcados — as mesmas ideias com um orçamento de energia por cima (cap. 3).