Categoria
Redes
Todas as ferramentas e artigos desta categoria, reunidos em um só lugar.
Ferramentas
Bits, bytes e vazão
Um tamanho em todas as unidades das duas convenções, com a contagem de bits por extenso (1,5 GB são 12 000 000 000 bits e 1,397 GiB; lido do jeito 1024, seria 7,37 % a mais), uma taxa em bits e bytes por segundo e por minuto, hora e dia, e quaisquer dois entre tamanho, taxa e tempo dando o terceiro, com a eficiência de protocolo do TCP sobre Ethernet aplicada se você pedir. A tabela de conexões responde para um modem, T1, E1 e toda velocidade de Ethernet de uma vez. Aritmética exata; nada é arredondado até ser impresso.
Calculadora CIDR / de sub-redes
Decomponha qualquer bloco CIDR de IPv4 em endereços de rede e de broadcast, faixa de hosts utilizáveis, contagem de hosts e máscara de rede, e veja em qual faixa de uso especial da IANA ele cai. Os outros modos dividem um bloco pai em sub-redes de tamanho variável (VLSM), resumem prefixos numa super-rede e encontram sobreposições e lacunas. Roda inteiramente no seu navegador.
Calculadora de MTU / MSS
Informe a MTU do link e a pilha de encapsulamento (vxlan, gre, pppoe, vlan, mpls, +N personalizado) para obter a MTU interna e o MSS do TCP, os tamanhos de quadro Ethernet, a MTU de underlay que um overlay exige e a eficiência no fio de quadros padrão versus jumbo.
Calculadora de timers do BFD
Informe os intervalos e o Detect Mult dos dois sistemas e veja, em cada sentido, o intervalo de transmissão acordado, a faixa de jitter, o tempo de detecção que o receptor calcula e se o Echo pode rodar, cada número explicado com a seção da RFC 5880 de onde vem; ou cole um pacote de controle do BFD em hex para decodificá-lo campo a campo.
Calculadora de validação de origem de rota
Cole uma rota (prefixo e AS de origem) e os VRPs que você tem, e veja o estado definido pela RFC 6811 (Valid, Invalid ou NotFound) com o motivo VRP por VRP: quais VRPs cobrem a rota, quais dão match e por que os outros falham. AS 0 e maxLength são tratados como as RFCs dizem, em IPv4 e IPv6, e nada é buscado na rede.
Comparação de métodos HTTP
Informe de um a quatro métodos HTTP (experimente "get vs query") para ver os fatos de registro de cada um: seguro, idempotente, cacheável, semântica do corpo da requisição, presença na safelist do CORS, suporte em formulários HTML e a RFC que o define - além de exatamente quais propriedades diferem. Inclui o QUERY, o método da RFC 10008 registrado em junho de 2026.
Consulta de fabricante por OUI / MAC
Descubra o fabricante por trás de um endereço MAC e veja se ele é unicast ou multicast e de administração universal ou local. Tudo no seu navegador.
Decodificador + codificador de PRI syslog
Decodifique um PRI de syslog como 134 em sua facility e severity, ou codifique-os de volta, tudo no seu navegador.
Domínio registrado (eTLD+1)
Descubra o sufixo público (eTLD) e o domínio registrado (eTLD+1) de qualquer nome de host, usando a Public Suffix List.
Explicador de assinatura TCP/IP passiva p0f
Decodifique uma impressão digital SYN do p0f v3 em seus oito campos e veja o que cada um revela sobre o SO, o caminho de rede e a pilha do remetente.
ZscalerExplicador de códigos de status HTTP
Cole códigos de status (404, 301 302 307) ou famílias (5xx) e receba cada um decodificado: família, nome registrado, significado documentado e as notas operacionais - incluindo a própria regra de fallback do protocolo para códigos que ele nunca viu.
explicador de saída do dig
Cole a saída real do dig e obtenha um detalhamento decodificado e explicado: o cabeçalho e as flags, a pseudo-seção OPT do EDNS, cada registro em cada seção e as estatísticas da consulta. Analisado inteiramente no seu navegador, nada é resolvido nem enviado a lugar algum.
explicador de saída do nslookup
Cole a saída real do nslookup e obtenha um detalhamento decodificado e explicado: o resolvedor usado, se a resposta é autoritativa, cada registro (com breakdown de campos de MX / SRV / SOA) e quaisquer falhas. Analisado inteiramente no seu navegador, nada é resolvido nem enviado a lugar algum.
Explicador de tabela de roteamento
Cole a saída de ip route, netstat -rn ou route print para ler cada rota campo a campo, ver qual rota default vence e perguntar qual rota um destino usaria, pelo prefixo mais longo e depois pela métrica.
Explicador e validador de arquivo PAC
Cole um arquivo Proxy Auto-Config e ele mostra as diretivas de proxy que retorna, as funções auxiliares PAC que usa (com as que consultam DNS sinalizadas), verificações de estrutura e correção, e se é um arquivo de direcionamento de proxy explícito da Netskope. Nunca executa o arquivo.
NetskopeGerador de DHCP option 43
Monta o valor de option 43 que a controladora sem fio realmente espera. Um número de opção, quatro codificações incompatíveis.
Kit de ferramentas IPv6
Analise um endereço ou prefixo IPv6 para ver suas formas canônica (RFC 5952) e totalmente expandida, sua classificação de uso especial, a aritmética de prefixo, um MAC EUI-64 se presente e seu nome de DNS reverso ip6.arpa. Roda inteiramente no seu navegador.
Montador de comandos dig
Diga o que consultar, a quem perguntar e como, e receba um comando dig pronto para colar, com cada parte explicada, as combinações que o manual chama de redundantes ou contraditórias sinalizadas, e um resumo do que a consulta vai carregar: transporte, porta, RD, DO, CD, EDNS e cookie. O inverso do explicador de saída do dig. Não executa nada; montado no seu navegador a partir do manual do BIND 9 e das RFCs do DNS.
Planejador de lance de cabo
Velocidade, distância, ambiente e PoE entram - toda opção de cabo e fibra conforme sai, cada uma citando a regra TIA-568 ou 802.3 que a governa, com exclusões honestas para o resto.
Port blocks de CGN e port sets de MAP
Divida um endereço IPv4 público entre assinantes: port blocks por endereço e por pool (RFC 7768), o mapeamento determinístico da RFC 7422 com a consulta direta e a reversa, e o port set de um PSID no MAP-E e no MAP-T (RFC 7597), com o volume de log que os blocos eliminam.
Artigos
Como funcionam os endereços IPv4
Todo header IPv4 carrega dois endereços, origem e destino, cada um deles um número de 32 bits escrito como quatro octetos decimais, com um comprimento de prefixo que o divide em rede e host. Depois da leitura, você consegue converter um endereço para binário e para inteiro à mão, aplicar a máscara como um host faz para decidir se o destino está no próprio enlace, reconhecer os blocos de uso especial e suas regras, e dizer quem distribui os endereços e quando o estoque livre acabou.
LerComo um ponto de acesso encontra sua controladora
A option 43 do Dynamic Host Configuration Protocol (DHCP) carrega informação específica de fabricante, cujo significado é definido pelo fabricante indicado na option 60; por isso a mesma opção leva endereços binários para um ponto de acesso e texto para outro, enquanto um terceiro lê a controladora na option 138. Depois da leitura, você consegue montar e decodificar byte a byte o valor que cada fabricante documentado espera, fazer o servidor devolvê-lo à classe de fabricante certa, reconhecer a falha silenciosa e o risco do servidor intruso, e ler o valor de volta numa captura ou no servidor DHCP.
LerO PRI do syslog: um número, dois significados
Toda mensagem de syslog começa com um PRI, um número entre colchetes angulares que empacota uma facility e uma severity em um único valor. A fórmula é pequena e a aritmética é fácil depois que você a vê: PRI é igual a facility vezes oito mais severity.
LerFacilities e severities do syslog, explicadas
O syslog define 24 facilities e 8 severities. As severities são uma escala limpa de urgência, de emergency até debug; as facilities são uma mistura de categorias genuinamente úteis e resquícios históricos do Unix, mais oito slots locais nos quais os dispositivos de rede se apoiam bastante.
LerFundamentos de subnetting
Como dividir uma rede em sub-redes menores e por que todo o segredo está em pegar bits emprestados da parte de host: de onde vieram as sub-redes (RFC 950, 1985), a máscara e a única decisão que o host toma com ela, como achar a sub-rede, o broadcast e a faixa de hosts de qualquer endereço, a velha regra contra a sub-rede zero e por que ela caiu, e os dois prefixos que fogem do padrão de propósito.
LerComo funciona a notação CIDR
O que a barra em 192.168.1.0/24 quer dizer de verdade e como o tamanho do prefixo define um bloco de endereços IP: os três problemas que acabaram com o endereçamento classful (RFC 4632), a notação como o padrão a define, os prefixos mais comuns com a máscara e o tamanho de cada um, os endereços de rede e de broadcast e as duas exceções, por que a agregação era o objetivo e a mesma barra no IPv6.
LerSyslog em dispositivos de rede: qual facility faz o quê
Firewalls, balanceadores de carga e switches quase sempre registram nas facilities locais, mas cada fabricante escolhe um padrão diferente. Saber que o FortiGate usa local7 por padrão, o Cisco ASA usa local4 e o F5 BIG-IP usa local0 transforma uma parede de números de PRI em um mapa de qual caixa disse o quê.
LerFormatos de mensagem syslog: RFC 3164 vs RFC 5424
O PRI é o mesmo em todo lugar, mas o que vem depois não é. O syslog BSD legado (RFC 3164) tem um formato solto e sem ano, enquanto o formato moderno (RFC 5424) é preciso e estruturado. Saber qual você está vendo explica timestamps ausentes, campos ambíguos e por que parsers discordam.
LerVLSM: como dividir um bloco em sub-redes de tamanhos diferentes
Máscaras de tamanho variável (VLSM) permitem que as subnets recortadas de um mesmo bloco pai tenham prefixos de comprimentos diferentes, cada uma dimensionada para os hosts que precisa abrigar, em vez de uma única máscara para a rede inteira. Depois da leitura, você consegue dimensionar cada subnet pela quantidade de hosts, alocar os blocos do maior para o menor sem que nenhum pule para a frente, dizer quais protocolos de roteamento conseguem carregar o plano e por que o longest match torna as máscaras mistas seguras, contabilizar o espaço livre em blocos alinhados e conferir a alocação no modo VLSM da calculadora CIDR.
LerComo o syslog viaja: UDP, TCP e TLS
O syslog pode trafegar sobre UDP puro, sobre TCP, ou sobre TLS, e a escolha decide se as mensagens podem ser silenciosamente perdidas, reordenadas ou lidas em trânsito. Este artigo cobre os três transportes, as portas envolvidas, e por que qualquer coisa da qual você depende para auditoria não deveria ser enviada sobre UDP.
LerUma alocação com VLSM, resolvida do começo ao fim
Um bloco de documentação, 203.0.113.0/24, dividido em cinco subnets de tamanhos diferentes para um site pequeno, com cada endereço de rede, máscara, faixa de hosts e endereço de broadcast escrito e conferido, a sobra contabilizada, os mesmos dois links entre roteadores como prefixos /31, a falha que a ordem de chegada produz e a única rota que alcança o plano inteiro. Depois da leitura, você consegue repetir o procedimento num bloco seu, à mão, com a Calculadora CIDR / de sub-redes e com algumas linhas de Python.
LerA primeira hora: isolamento de falhas orientado por hipóteses
A diferença entre um incidente de duas horas e um de dois dias costuma ser decidida na primeira hora, e raramente é decidida por ferramentas. É decidida por método: alinhar o início com a mudança, isolar por escopo, ler assinaturas de camada e tratar toda explicação como uma hipótese que a evidência precisa sustentar ou enfraquecer antes que alguém aja sobre ela.
LerSupernetting e agregação de rotas
O supernetting encurta um prefixo para que uma só rota cubra vários blocos IPv4 alinhados, e a agregação de rotas anuncia essa rota no lugar das mais longas. Depois da leitura, você consegue testar em binário se blocos se fundem, distinguir o agregado exato da super-rede de cobertura e dizer quando esta é legítima, ler como o BGP marca um agregado e por que o AS_SET foi descontinuado em maio de 2025, reconhecer como a agregação falha e conferir tudo na calculadora CIDR, no Python e nos comandos do FRRouting, do Junos e da Cisco.
LerJanelas de mudança que não viram incidentes
A maior parte das quedas autoinfligidas são mudanças que deram errado sem um caminho limpo de volta. A diferença entre uma mudança e um incidente raramente está na mudança em si; está no runbook em torno dela — o que você verificou antes, como sequenciou, o que o faria parar e se o caminho de volta estava escrito e testado antes de você precisar dele.
LerSumarização de rotas
A sumarização de rotas anuncia um único prefixo através de uma fronteira de roteamento no lugar dos muitos que ele cobre, e assim os roteadores do outro lado guardam uma só entrada e não veem os componentes caírem e voltarem. Depois da leitura, você consegue calcular um resumo exato em binário, configurar e conferir faixas de área do OSPF, sumarização externa, sumarização do EIGRP por interface e rotas estáticas sumarizadas, explicar a rota de descarte que impede o loop e reconhecer como uma rota sumarizada esconde falhas e desvia caminhos.
LerCausa-raiz é um verbo, não um substantivo
A expressão causa-raiz convida a um único vilão e a um final arrumadinho. Incidentes reais raramente têm um; têm fatores contribuintes, e o trabalho honesto é estruturar os candidatos e a evidência que confirmaria ou descartaria cada um — não nomear um culpado antes de a evidência chegar.
LerCloudflare: o fosso entregue de graça
A Akamai vendia aceleração e proteção contra DDoS para a Fortune 500; a Cloudflare deu uma versão das duas para qualquer um com um domínio, e fez do próprio plano gratuito o motor — mais tráfego significava peering melhor, peering melhor significava banda mais barata, banda mais barata pagava mais usuários gratuitos. O reverse proxy que cresceu até virar uma rede, um resolver, um computador de borda e uma quantidade desconfortável de poder.
LerSobreposições e lacunas de sub-redes
Dois prefixos IPv4 se sobrepõem quando algum endereço pertence aos dois, e com prefixos sem classe isso só pode significar que um está inteiro dentro do outro, de propósito ou por engano; lacunas são os endereços de um bloco pai que nenhum prefixo cobre. Depois da leitura, você consegue provar em binário que dois prefixos se aninham ou nunca se tocam, distinguir uma rota mais específica deliberada de um defeito, listar as lacunas de uma alocação como blocos alinhados que fecham a conta de cada endereço e explicar por que túneis e peering na nuvem recusam faixas sobrepostas e como a tradução contorna isso.
LerAkamai: o teorema que carregou a web
Um problema de matemática proposto por Tim Berners-Lee, um algoritmo chamado consistent hashing, e a empresa que transformou os dois na camada invisível sob duas décadas de streaming, lançamentos e notícia quente. O overlay de deploy profundo, o IPO que quase a matou, o cofundador perdido no 11 de Setembro, e a longa reinvenção de cache a segurança a nuvem.
LerEspaço de endereços IPv4 privados e a RFC 1918
A RFC 1918, Best Current Practice 5 desde fevereiro de 1996, reserva 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 para endereços que qualquer organização pode usar internamente: únicos só dentro dela e mantidos fora do roteamento e do DNS da internet. Depois da leitura, você consegue dar os limites e o tamanho exatos de cada bloco, aplicar as regras da RFC 1918 para roteadores de borda e DNS, explicar por que juntar duas redes privadas obriga a renumerar, distinguir uma consulta reversa respondida localmente de uma que vazou para o sumidouro AS112 e conferir cada ponto com ip, dig e Python.
LerPensar no raio de impacto antes de mudar qualquer coisa
Antes de uma mudança, a pergunta não é só se isto vai funcionar, mas se der errado, até onde o dano chega. O raio de impacto é o formato desse alcance — alvo, vizinhos, dependentes, pessoas — e pensá-lo em camadas é como você decide o que conter antes de tocar em qualquer coisa.
LerChamados de TAC que são triados rápido
Os chamados de suporte mais lentos raramente são os problemas mais difíceis; são os que foram abertos sem o diagnóstico que o fornecedor precisa. Um chamado que chega completo — problema claro, erro exato, o pacote de diagnóstico, o impacto — pula as idas e vindas e começa com um engenheiro de fato trabalhando nele.
LerComo funciona o endereçamento IPv6
Um endereço IPv6 é um identificador de 128 bits de uma interface, escrito em hexadecimal com uma única grafia canônica, dividido em prefixo e identificador de interface e classificado pelos primeiros bits. Depois da leitura, você consegue escrever qualquer endereço na forma canônica, dizer o tipo e o escopo dele, dar a um endereço link-local a sua zona, recuperar o endereço de hardware contido num identificador derivado dele e dizer qual registro de DNS reverso liga um endereço a um host.
LerComo hosts IPv6 obtêm endereços: SLAAC e DHCPv6
Um host IPv6 se configura a partir do que os roteadores anunciam: um endereço link-local que ele testa contra duplicatas, endereços globais que monta por autoconfiguração sem estado a partir de cada prefixo marcado para isso e, onde a rede oferece, endereços, prefixos e servidores DNS concedidos pelo DHCPv6. Depois da leitura, você consegue ler as flags e os tempos de vida de um router advertisement, derivar identificadores de interface EUI-64, estáveis e temporários, distinguir o DHCPv6 com estado, sem estado e de delegação de prefixo, prever qual endereço de origem um host usa, reconhecer anúncios falsos, endereços duplicados e prefixos velhos, e acompanhar cada passo com ip, rdisc6, tcpdump e Wireshark.
LerPontos de captura antes dos pacotes
O instinto sob pressão é rodar tcpdump em qualquer lugar conveniente e encarar a enxurrada. O hábito sênior é o oposto: decidir onde observar, em que ordem e o que cada observação significaria - antes de coletar um único pacote. Evidência se projeta, não se pesca.
LerSub-redes IPv6 e a fronteira /64
Dividir o espaço IPv6 em sub-redes é repartir os 64 bits de cima do endereço entre registro, provedor, site e enlace, porque em quase todo enlace os 64 bits de baixo pertencem ao identificador de interface. Depois da leitura, você consegue explicar por que um enlace é um /64 e o que a autoconfiguração sem estado tem a ver com isso, dimensionar o prefixo de um site e acompanhar a delegação dele, contar e numerar sub-redes em fronteiras de nibble, numerar enlaces entre roteadores e loopbacks com /127 e /128, montar um prefixo local único e evitar os erros que quebram um plano de endereçamento.
LerSufixos públicos e o domínio registrado (eTLD+1)
O que são o sufixo público (eTLD) e o domínio registrado (eTLD+1), por que não dá para calculá-los pegando os dois últimos rótulos do nome, como o algoritmo da Public Suffix List chega à resposta e onde essa fronteira faz diferença: nos limites de emissão de certificados, nos cookies e no same-site.
LerDescoberta de Vizinhos: como o IPv6 substitui o ARP
O Neighbor Discovery é o protocolo ICMPv6 que todo nó IPv6 executa no seu enlace: cinco mensagens que assumem o papel do ARP, da descoberta de roteadores e dos redirects do ICMP, e cuidam também da detecção de vizinho inalcançável e de endereço duplicado. Depois da leitura, você consegue decifrar as cinco mensagens, calcular à mão um grupo solicited-node e seu endereço Ethernet, acompanhar uma resolução pelo cache de vizinhos, reconhecer anúncios de roteador falsos e o esgotamento de cache com suas defesas e observar tudo com ip, ndisc6, tcpdump e Wireshark.
LerMapeie o caminho antes de começar o troubleshooting
As sessões de troubleshooting mais caras têm um defeito em comum: ninguém sabia de verdade qual era o caminho. O hábito de quem tem experiência é se recusar a raciocinar sobre uma falha antes de modelar a cadeia inteira: com a resolução de nomes incluída, o caminho de volta tratado à parte, cada reescrita e cada fronteira de TLS identificadas, e tudo o que não se sabe marcado claramente como desconhecido.
LerBaselines antes de você precisar delas
Toda comparação é tão honesta quanto o seu lado mais fraco. A disciplina é baseline capturada antes das mudanças, confiança declarada em vez de saúde lembrada, janelas de observação que deixam a convergência falar, alfabetização de churn para os contadores que sempre se movem - e nunca chamar uma mudança de bem-sucedida só por componentes verdes.
LerComo rodar IPv6 e IPv4 juntos: dual-stack e tradução
IPv4 e IPv6 não trocam pacotes entre si, então as redes rodam os dois lado a lado, carregam IPv6 dentro de IPv4 ou traduzem um protocolo no outro. Depois da leitura, você consegue prever qual família um host dual-stack tenta primeiro, montar à mão endereços 6to4, Teredo, 6rd e NAT64, acompanhar passo a passo uma sessão NAT64 com DNS64, explicar por que o 464XLAT traduz em vez de tunelar e reconhecer as falhas que esses mecanismos causam com literais IPv4, respostas DNS assinadas e tamanho de pacote.
LerO que é um OUI e como os endereços MAC são atribuídos
Como é a estrutura de um endereço MAC, o que é o OUI (o prefixo do fabricante) e quem distribui esses prefixos, a diferença entre endereços de administração universal e local, e por que um MAC aleatório de Wi-Fi não tem fabricante nenhum.
LerComo ler a saída do dig de cima a baixo
O dig imprime toda resposta DNS na mesma forma fixa: as linhas de versão e de opções, a linha do header, a linha de flags e contagens, a pseudo-seção OPT, as seções que têm registros e quatro linhas de estatísticas. Depois da leitura, você consegue percorrer qualquer resposta do dig bloco a bloco, dizer o que cada linha informa, reconhecer NODATA, NXDOMAIN, SERVFAIL e uma resposta truncada só pela forma, e escolher as formas mais curtas que um script precisa.
LerO cabeçalho DNS: opcode, status e flags
Toda mensagem DNS começa com o mesmo header de 12 bytes: um ID de 16 bits, uma palavra de flags que guarda o opcode, sete flags nomeadas, um bit reservado e o código de resposta, e quatro contadores de seção, que o dig imprime como as linhas de header e de flags. Depois da leitura, você consegue decodificar um header a partir dos bytes em hexadecimal, dizer o que cada flag, opcode e status conta para um diagnóstico, reconhecer uma resposta truncada e testar a repetição por TCP que ela exige, e explicar por que o ID e a porta de origem precisam ser imprevisíveis.
LerComo ler os registros em uma resposta do dig
Cada registro que o dig imprime é um resource record em cinco colunas: nome do owner, TTL, classe, tipo e os dados específicos do tipo, sem o campo de comprimento que viaja na mensagem. Depois da leitura, você consegue nomear cada coluna, decodificar os dados de registros A, AAAA, CNAME, NS, SOA, MX, TXT, PTR, SRV e CAA, distinguir o TTL decrescente de um cache do TTL da zona, seguir uma cadeia de CNAME até o nome que define o código de status e reconhecer os aliases, timers e erros de aspas que fazem uma resposta aparentemente correta falhar.
LerO EDNS e a pseudo-seção OPT
A pseudo-seção OPT não é um registro, nem algo que você consultou: são metadados do EDNS(0) que o dig mostra perto do topo da resposta. Ela carrega o tamanho de payload UDP, a flag DO, que pede DNSSEC, e opções como COOKIE, e explica, sem alarde, toda uma classe de falhas de resolução.
LerRegistros DNSSEC na saída do dig
Acrescente +dnssec e a resposta do dig ganha uma nova família de registros: RRSIG, DNSKEY, DS e os registros de negação NSEC ou NSEC3. Aqui você vê o que é cada um, como eles se encadeiam da raiz até uma zona e o que a flag ad garante de verdade.
LerComo ler a saída do nslookup
O nslookup imprime um header Server / Address com o resolver que ele usou, um aviso opcional Non-authoritative answer e, depois, a resposta num formato de texto que muda conforme o tipo de registro. Quem conhece esse formato lê qualquer resultado depressa e vê de relance se a consulta deu certo, de onde veio a resposta e o que ela significa.
Lernslookup vs dig: qual usar
O nslookup e o dig ambos consultam DNS, mas o nslookup é mais enxuto e esconde as flags do cabeçalho e os TTLs que o dig mostra por completo. Este artigo mapeia uma saída sobre a outra e dá uma regra simples para saber qual usar.
LerComo o nslookup imprime cada tipo de registro
Em vez das colunas fixas do dig, o nslookup rotula cada registro em prosa: mail exchanger =, canonical name =, nameserver = e um bloco de várias linhas para o SOA. Um guia curto para ler a linha de cada tipo.
LerRespostas autoritativas vs não autoritativas
Uma resposta é autoritativa quando o servidor que a enviou mantém a zona do nome perguntado, e ele diz isso com um único bit do header de DNS, o bit AA, que o nslookup mostra como o marcador Non-authoritative answer e o dig como a flag aa. Depois da leitura, você consegue distinguir uma resposta de cache de um referral, explicar por que uma consulta recursiva é não autoritativa por desenho, perguntar ao servidor da própria zona com a recursão desligada e ler aa na resposta, e dizer o que o bit ainda assim não prova.
LerErros do nslookup e o que eles significam
Quando uma consulta falha, o nslookup imprime uma linha como ** server can't find NAME: CODE. O código é o diagnóstico inteiro. Este artigo explica NXDOMAIN, SERVFAIL, REFUSED e os timeouts, o que cada um diz e a primeira coisa a verificar em cada caso.
LerConsultas DNS reversas com o nslookup
O DNS reverso mapeia um endereço IP de volta para um nome por meio de registros PTR que ficam sob in-addr.arpa para IPv4 e ip6.arpa para IPv6. O nslookup faz isso automaticamente quando você lhe passa um endereço. Este artigo cobre como o nome reverso especial é construído, por que os servidores de e-mail se importam, e por que o direto e o reverso podem legitimamente discordar.
LerModo interativo do nslookup
Rode o nslookup sem argumentos e ele abre um prompt interativo, em que você pode trocar de resolver, mudar o tipo de registro, ligar a saída de debug e consultar vários nomes na mesma sessão. Os poucos comandos que vale a pena conhecer e quando o modo interativo é melhor do que uma consulta avulsa.
LerOpções de consulta do dig e como controlar a saída
O poder de verdade do dig está nas opções: escolher a qual servidor perguntar, o tipo de registro e exatamente quanto da resposta mostrar. O artigo cobre as poucas que você vai usar todo dia, do @servidor e do -t ao +short e à combinação +noall +answer, que deixa na saída do dig só os registros.
LerComo seguir a delegação com dig +trace
O dig +trace resolve um nome do jeito que a internet resolve de verdade: começa na raiz, segue a delegação até o TLD e depois até os servidores autoritativos do próprio domínio, mostrando cada hop. É a melhor forma de ver onde a resolução quebra e de entender como as peças do DNS se encaixam.
LerAnatomia da linha de comando do dig: como o dig interpreta o que você digita
O dig aceita um servidor depois de um @, opções com hífen, um nome, um tipo, uma classe e query options (opções de consulta) com +, em quase qualquer ordem, e usa um valor padrão para tudo o que você deixar de fora. Este artigo percorre a linha da esquerda para a direita: quais palavras valem pela posição e como o dig distingue um nome de um tipo, por que a ordem das opções com + faz diferença e por que duas delas são globais, como o transporte é escolhido (UDP com retry por TCP, TCP para ANY e para transferências de zona, TLS e HTTPS nas suas próprias portas), quais opções mudam bits do header e quais vão no registro OPT do EDNS, o que +trace e +nssearch fazem com a recursão e por que o manual manda guardar o segredo do TSIG num arquivo. Cada afirmação vem do manual do BIND 9 ou de uma RFC, com a fonte citada.
LerComo as redes herdaram dois alfabetos
Todo engenheiro lê letras gregas e algarismos romanos sem nunca ter estudado nenhum dos dois: Ω no terminador, μs no gráfico de latência, λ no plano de comprimentos de onda, Ethernet II em todo analisador de pacotes, um I ou um II gravado no repetidor. Nada disso foi escolhido pensando em redes. Cada símbolo chegou num momento que dá para datar, e são essas datas que contam a história.
LerLinux: o kernel de hobby que comeu o mundo
Um estudante em Helsinque anunciou um projeto que era 'só um hobby, não vai ser grande e profissional como o gnu' — e hoje ele roda os servidores, os celulares, os roteadores, os carros e cada um dos supercomputadores mais rápidos do mundo. Como o kernel foi de fato construído, a decisão de licença que tornou tudo possível, a discussão de arquitetura que ele perdeu no papel e venceu na prática, e as duas brigas que ainda o definem.
LerAs famílias de distribuições Linux: o que de fato as separa
Toda distribuição entrega mais ou menos o mesmo kernel e mais ou menos as mesmas ferramentas GNU, então as diferenças não estão onde o iniciante procura. Estão no gerenciador de pacotes, no modelo de lançamento, na filosofia de empacotamento e — o mais consequente — em quem decide. Um guia de campo das famílias, descritas pelo que se sente ao administrá-las.
LerO que nasceu do Linux: celulares, roteadores, contêineres e a pergunta de licença que cada um responde
Android, ChromeOS, SteamOS, OpenWrt, as construções Yocto dentro do seu carro e a indústria inteira de contêineres são todos Linux — mas são Linux de maneiras muito diferentes. A parte interessante não é a árvore genealógica. É como cada descendente respondeu à mesma pergunta: quanto precisamos devolver, e como cada um engenheirou a própria resposta?
LerComo ler um comando curl
Um comando curl é um comando de shell: a palavra curl, um conjunto de opções e uma URL. Para lê-lo, é preciso ver primeiro como o shell quebra a linha (aspas, barras invertidas, continuações de linha) e depois como o curl lê as flags curtas, longas e agrupadas.
LerSinalizadores de dados do curl e a armadilha do Content-Type
O curl tem várias formas de anexar um corpo, e elas diferem na codificação e no Content-Type padrão. A grande surpresa é que -d usa codificação de formulário por padrão, não JSON, então um corpo JSON pode ser rotulado errado e recusado.
LerComo traduzir curl para fetch()
A API fetch do navegador e o curl descrevem a mesma requisição de formas diferentes. Método, cabeçalhos e corpo se mapeiam de forma limpa, mas algumas diferenças (Content-Type de formulário implícito, cookies e verificação TLS) exigem cuidado.
LerCabeçalhos, autenticação e cookies no curl
Cabeçalhos, autenticação e cookies são como uma requisição se identifica e se autoriza. -H adiciona cabeçalhos, -u é HTTP Basic, um token bearer é apenas um cabeçalho, e -b/-c cuidam de cookies. Todos são sensíveis.
LerComo o curl infere o método HTTP
O curl nem sempre precisa de -X para escolher um método. Dados no corpo implicam POST, -I implica HEAD, -G força GET, e um -X explícito sempre vence. Conhecer as regras diz num relance o que uma requisição fará.
LerSinalizadores do curl que mudam a postura de segurança
Alguns sinalizadores do curl mudam o quão segura é uma requisição: -k desativa a verificação TLS, http envia tudo em texto puro, e credenciais na URL podem vazar. Nenhum torna uma requisição maliciosa, mas cada um vale a leitura antes de executar ou compartilhar um comando.
LerO proxy TCP: o que um middlebox de camada 4 enxerga e o que não enxerga
Um proxy TCP termina a conexão TCP do cliente e abre outra, separada, até o servidor, emendando dois fluxos independentes na camada 4. Ele reescreve endereços e portas, pode reaproveitar conexões num pool e não enxerga nada do payload da aplicação acima do header de transporte. O artigo explica a diferença entre full proxy e encaminhamento de pacotes, por que o IP de origem desaparece e como o Proxy Protocol o traz de volta.
LerProxies HTTP: forward ou reverse, explícito ou transparente
Um proxy HTTP faz o parsing das requisições na camada 7 e, por isso, consegue rotear por URL, reescrever headers e aplicar políticas sobre um conteúdo que um proxy TCP não enxerga. Dois eixos descrevem qualquer implantação: forward ou reverse (para qual lado ele trabalha) e explícito ou transparente (se o cliente sabe que ele está ali). O artigo cobre o método CONNECT, os headers X-Forwarded-For e Via, e onde cada combinação é usada.
LerOs 27 protocolos que o curl fala
O curl é conhecido como ferramenta de HTTP, mas a versão atual fala 27 esquemas de URL: transferência de arquivos por FTP, SFTP e SMB, e-mail por SMTP, POP3 e IMAP, publish-subscribe MQTT, consultas LDAP e relíquias como Gopher, DICT e Telnet. Conhecer o mapa, e saber quais esquemas começam em texto claro, muda a forma de usar a ferramenta.
LerHTTP/0.9 vs 1.0 vs 1.1 vs 2 vs 3: cinco versões do protocolo da web
De um GET de uma linha, que só buscava HTML, a um protocolo multiplexado rodando sobre QUIC: o que cada versão do HTTP acrescentou, por que ela foi necessária e qual RFC a define hoje, incluindo a reorganização de 2022, que separou a semântica do HTTP (RFC 9110) da sintaxe de transmissão de cada versão.
LerOs pontos de estrangulamento da internet: um guia de campo do que pode de fato quebrar
A internet não tem botão de desligar, mas tem seis lugares onde um número pequeno de pessoas, organizações ou objetos carrega uma fatia enorme das premissas de todo mundo. Nomeação, roteamento, cabo, confiança, concentração e autoridade — o que cada um é, com que velocidade falha, quem conseguiria causar, e o tipo diferente de resposta que cada um admite.
LerO que acontece se a raiz do DNS sair do ar, ou começar a mentir
Desligue as treze identidades de servidor raiz e a internet continua funcionando por uns dois dias; depois, vai se desfazendo um domínio de topo de cada vez, à medida que as delegações em cache expiram. O cenário bem mais perigoso é uma raiz que continua no ar e passa a responder outra coisa, porque o DNSSEC vai assinar fielmente essa nova realidade. A seguir: a linha do tempo real da falha, o que sobrevive, o que dá para fazer hoje e por que todas as raízes alternativas fracassaram.
LerBGP: o voto de confiança que sustenta a internet inteira
O BGP leva a informação de alcance entre cerca de 74.000 redes independentes e não tem nenhum mecanismo próprio para verificar se um anúncio é autorizado ou se um caminho é real. Depois da leitura, você consegue distinguir um hijack de um route leak como as normas os definem, explicar por que a rota mais específica vence e por que a filtragem do upstream decide o tamanho do estrago, ler os incidentes documentados nos registros de quem os viveu e dos reguladores, e dizer qual defesa (filtragem, origens de rota assinadas, papéis de peering, assinatura de caminho) responde a qual falha.
LerCabos submarinos: a internet é, literalmente, um cabo no fundo do mar
Praticamente todo o tráfego intercontinental passa por algumas centenas de cabos de fibra óptica no fundo do oceano, a maioria com no máximo a grossura de uma mangueira de jardim, e a grande maioria dos rompimentos é causada por equipamentos de pesca e âncoras de navio, não pela ação intencional de alguém. O que acontece de fato quando um cabo se rompe, por que alguns países nem sentem e outros ficam fora do ar, como o reparo funciona na prática e por que redundância no mapa não é redundância no mundo físico.
LerValidação de origem de rota, feita à mão: Valid, Invalid, NotFound
A validação de origem de rota compara o prefixo e o AS de origem de uma rota BGP com os Validated ROA Payloads que o roteador tem e dá à rota um de três estados. Depois da leitura, você consegue calcular à mão o estado de qualquer rota com os dois testes que a RFC 6811 define, dizer por que uma rota Invalid é Invalid (outro AS, ou um prefixo mais longo que o maxLength), ler AS 0 e maxLength como as RFCs leem e conferir a resposta na calculadora.
LerMonocultura de nuvem e CDN: o ponto de estrangulamento que ninguém escolheu
Ninguém decidiu que um erro de configuração numa empresa deveria tirar um quarto da web do ar por uma hora, e ainda assim é mais ou menos esse o arranjo. A concentração em regiões de nuvem, redes de entrega de conteúdo, provedores de DNS e serviços de identidade faz com que organizações sem relação nenhuma falhem no mesmo instante pelo mesmo motivo. Por que aconteceu, o que de fato falha, e por que a resposta óbvia — multinuvem — está quase sempre errada.
LerDesligamentos de internet: o ponto de estrangulamento que é um telefonema
Todo outro ponto de estrangulamento desta série exige um ataque, um acidente ou um ato de engenharia. Este exige uma instrução a um punhado de empresas que já têm licença. Desligamentos hoje são rotina em algum lugar do mundo quase toda semana — apagões completos, cortes regionais, bloqueio de plataformas, e a opção mais silenciosa do estrangulamento de banda — e o quadro técnico é menos interessante que quem precisa obedecer e quanto isso custa.
LerAltaVista: feito para quebrar um processador, e perdido ao virar portal
O AltaVista começou como benchmark. Um pesquisador queria uma carga caótica o bastante para estressar os novos chips Alpha da DEC, então apontou um rastreador para a web inteira. O resultado liderou a busca por anos e depois foi desmontado pelos próprios donos, o que faz dele o estudo de caso mais claro da indústria sobre perder um mercado que já se tem.
LerCGNAT: o que quebra quando mil assinantes dividem o mesmo endereço
O carrier-grade NAT (CGN) é um NAT na rede da operadora que divide um endereço IPv4 público entre muitos assinantes, com o shared address space 100.64.0.0/10 numerando o link atrás dele. Depois da leitura, você consegue dizer o que a RFC 6888 exige de um CGN, nomear o que os testes publicados viram quebrar, explicar por que um endereço sozinho já não identifica um assinante, calcular o volume de logging e um port block determinístico, situar o NAT444 entre o DS-Lite e os desenhos A+P e verificar se a sua própria conexão está atrás de um.
LerDijkstra: o algoritmo de vinte minutos que os seus roteadores rodam todo dia
Em 1956, Edsger W. Dijkstra criou um algoritmo de caminho mais curto no terraço de um café em Amsterdã, sem lápis e sem papel, para demonstrar um computador novo; todo roteador que roda Open Shortest Path First (OSPF) ou Intermediate System to Intermediate System (IS-IS) calcula a árvore que esse algoritmo produz. Depois da leitura, você consegue contar a história com as palavras dele, executar o algoritmo à mão em seis roteadores, explicar por que o custo de um link precisa ser positivo e por que custos iguais dão vários next hops, e encontrar o resultado e o throttle de SPF num roteador.
LerPort blocks e port sets: a aritmética de dividir um endereço IPv4
Quando um carrier-grade NAT ou um domínio MAP divide um endereço IPv4 público, o que ele reparte é o campo de porta de 16 bits, em blocos, por uma fórmula determinística ou por campos de bits. Depois da leitura, você consegue calcular quantos assinantes cabem em um endereço e em um pool, quanto o logging por bloco economiza, qual assinante estava com um endereço, uma porta e um horário pela RFC 7422 e quais portas pertencem a um PSID do MAP.
LerBalanceamento de carga: o que realmente decide para onde vai uma requisição
Todo load balancer responde às mesmas quatro perguntas: quais servidores estão vivos, qual deles recebe esta requisição, se este cliente precisa continuar indo para o mesmo lugar e o que acontece quando a resposta muda. Os algoritmos são a parte menos interessante. As quedas vêm do health check, da decisão de persistência e do comportamento no draining.
LerSegmentação de rede: de domínios de broadcast a identidade, e por que ela falha sempre no mesmo lugar
A segmentação começou como correção de desempenho para domínios de colisão, virou controle de segurança por acidente, e hoje é vendida como microssegmentação. Os mecanismos — VLANs, VRFs, VXLAN, zonas de firewall, agentes em host, grupos de segurança de nuvem — cada um resolveu o limite do anterior e herdou um novo modo de falha. A história, os padrões, as arquiteturas, o cenário de fabricantes, e a coisa que derrota toda geração: ninguém sabe o que fala com o quê.
LerWi-Fi: um meio compartilhado que se faz passar por cabo, e tudo o que vem disso
A Ethernet resolveu a disputa pelo meio dando a cada dispositivo um fio só dele. O Wi-Fi não tem como fazer isso, então usa o protocolo de rádio dos anos 1970 que a Ethernet abandonou, e desde então cada geração tenta recuperar a eficiência que se perde ao compartilhar o meio. Os padrões, o espectro, as arquiteturas, os fabricantes e por que o erro de implantação mais comum é tratar cobertura e capacidade como se fossem o mesmo problema.
LerGPON: como uma única fibra atende um bairro inteiro
Uma Gigabit Passive Optical Network (GPON) leva uma única fibra da central, divide a luz com splitters que funcionam como prismas, sem energia elétrica, e compartilha essa fibra entre dezenas de casas. Como a luz é dividida, por que o upstream precisa de uma agenda de transmissão e para onde vai o orçamento de decibéis.
LerBridges e switches: a mesma ideia, resolvida duas vezes
A bridge e o switch são a mesma ideia, com poucos anos de distância, e a história passa por duas pessoas que raramente são citadas juntas. Radia Perlman resolveu o problema dos loops na Digital numa única noite, em meados dos anos 1980, e escreveu a resposta na forma de um poema de doze linhas. A Kalpana colocou a mesma função em silício, em cada porta, em 1990, e vendeu o resultado para a Cisco quatro anos depois. No caminho: por que Perlman diz que tudo isso nasceu de um erro da indústria, por que o switch substituiu o hub sem que ninguém chamasse isso de ganho de segurança e o que acontece com uma camada que já foi dada como encerrada várias vezes.
LerJumbo frames: quando 1500 bytes não bastam mais
Por que a Ethernet ficou nos 1500 bytes, o que os jumbo frames de 9000 bytes realmente trazem de ganho, onde eles fazem diferença e como um MTU mismatch vira um black hole silencioso.
LerBits, bytes e os dois significados de quilo: por que um arquivo de 56k leva oito segundos num modem de 56k
A conta em que toda conversa sobre redes se apoia e que quase todo mundo erra por pouco: um byte tem oito bits, velocidade de link se mede em bits e tamanho de arquivo em bytes, e quilo quer dizer 1000 em todo lugar, menos onde quer dizer 1024; em 1998, o IEC deu prefixos próprios ao quilo de 1024. Por que um disco de 1 TB aparece como 931 sem faltar nada, por que um link de 100 Mbit/s entrega no máximo 11,87 MB/s de payload TCP (pela RFC 2544 e pelo tamanho mínimo dos headers) e o exemplo resolvido que uma calculadora do site deste autor já trazia em 2004. Com o NIST, a página do ls do GNU, as recomendações ITU-T V.90 e G.704, o IEEE 802.3-2022 e as RFCs.
LerHTTP QUERY: a leitura que finalmente carrega um corpo
A RFC 10008 (junho de 2026) deu ao HTTP seu primeiro método novo desde 2010: o QUERY é seguro, idempotente e cacheável como o GET, mas carrega um corpo de requisição como o POST. O que ele corrige, como funcionam seu cache e sua descoberta, por que 'seguro' não é 'inofensivo' e o que cada camada da infraestrutura precisa conferir antes de o tráfego QUERY chegar.
LerO roteador: de gateway a commodity, e os nomes que ficaram de fora
O roteador já foi reinventado pelo menos quatro vezes, e a função dele nunca mudou: ler o destino, escolher o next hop (o próximo salto) e encaminhar. Esta é a história da família: os IMPs de 1969; o primeiro roteador IP de verdade, escrito na BBN por Virginia Strazisar em 1975 e 1976; o roteador multiprotocolo, inventado duas vezes, de forma independente, em 1981, em Stanford e no MIT; a caixa azul que virou a Cisco; e a longa passagem do hardware especializado para o software rodando em máquinas de uso geral. E também por que as duas pessoas que resolveram os problemas mais difíceis do começo das camadas 2 e 3 quase nunca são lembradas.
LerF5 Distributed Cloud: uma requisição, de ponta a ponta
Dezesseis artigos sobre o F5 Distributed Cloud, na ordem em que uma requisição passa por eles: como um site entra na malha, onde a requisição chega, que rota ela segue, para onde é encaminhada, como é criptografada, se é permitida, quanto dela é tolerado, o que ela pode chamar, o rastro que deixa e o erro que passa despercebido na configuração que a tratou.
LerLoad balancers e ADCs: construídos contra a estimativa de mercado
No fim de 1995, um webmaster da Netscape disse a um engenheiro da Cisco que provavelmente havia dez clientes no mundo com um problema de balanceamento de carga. Eles começaram a desenvolver mesmo assim e lançaram o primeiro load balancer do mercado quatro meses depois. Esta é a história da família: o LocalDirector em abril de 1996, o BIG/ip da F5 em julho de 1997, com 200 mil dólares de receita no primeiro ano diante de um concorrente de cinco bilhões de dólares, a troca de nome para application delivery controller e o que acontece com um equipamento cuja função foi absorvida por todas as plataformas que vieram depois.
LerExtreme Fabric Connect: um serviço, de borda a borda
Dez artigos sobre a fabric da Extreme, na ordem em que um serviço passa a existir: qual sistema operacional usar, o que significam os termos, o que é a fabric, como os nós se conhecem, como um serviço atravessa o backbone, por que o multicast não precisa de configuração, como a borda pede o que precisa e como a borda ganha dual-homing sem spanning tree. A ideia que organiza tudo é a mesma sobre a qual a fabric foi construída: o serviço é provisionado na borda, e não levado em trunk de hop em hop.
LerComo ler uma resposta de DNS: o diagnóstico está na linha que você pulou
Uma resposta de DNS mostrada pelo dig ou pelo nslookup é a mensagem de resposta inteira: um header com flags e um código de resposta, a pergunta, um pseudorregistro OPT e até três seções de registros, nas quais o endereço é uma linha só. Depois da leitura, você consegue dizer quem respondeu e com que autoridade, ler as flags, a linha OPT, os TTLs e os códigos de falha, perguntar direto ao servidor autoritativo, seguir uma delegação com +trace e achar a parte desta série que aprofunda cada linha.
LerA indústria, por dentro: seis artigos sobre como este negócio de fato funciona
Quem funda as empresas, como um produto viaja de quem o constrói até quem depende dele, o que o papel no meio desse caminho faz o dia inteiro, o que um cliente está de fato comprando quando compra transformação, e o que todo equipamento do parque está rodando por baixo. Seis artigos que não são sobre fabricante nenhum, lidos na ordem em que uma carreira os encontra.
LerTransceivers: o artigo que foi ridicularizado e a parte da rede que cabe na mão
Em 1966, um engenheiro de 32 anos, num laboratório britânico, publicou um artigo defendendo que as perdas enormes da fibra óptica vinham de impurezas, e não de um limite da física, e foi amplamente ridicularizado por isso. Quatro anos depois, a Corning provou que ele estava certo, e ele recebeu o Nobel quarenta e três anos depois do artigo. Esta é a história da família dos transceivers: do artigo de Kao ao multi-source agreement, o caso de autocontenção deliberada mais bem-sucedido da indústria, e por que a menor peça substituível de uma rede é a que determina o que essa rede pode vir a ser.
LerRede definida por software: um protesto que virou categoria de produto
O trabalho inicial que virou SDN - Ethane, RCP, 4D - nasceu como protesto contra a ossificação das redes. Em sete anos o protesto tinha uma fundação com Cisco e Juniper entre os membros fundadores, e o autor dele tinha vendido a empresa para a VMware por 1,26 bilhão de dólares e virado investidor. Esta é a história da família: o que o movimento de fato pediu, o que a indústria deu em troca, e por que a ideia venceu completamente enquanto o protocolo que lhe deu nome, em boa medida, não.
LerDNS: um arquivo mantido em horário comercial
Antes de 1983, para ter um endereço na rede era preciso ligar para Elizabeth Feinler, no SRI, que incluía você num arquivo que a equipe atualizava umas duas vezes por semana, em horário comercial, exceto nos feriados, e que cada host depois buscava. Jon Postel passou o problema para um aluno de pós-graduação, que leu as propostas que já existiam, escreveu a sua própria e assinou sozinho a especificação do sistema que hoje resolve trilhões de consultas por dia. Esta é a história da família do DNS: o arquivo, o projeto, a segurança que ficou de fora e como um sistema de nomes virou o ponto de controle mais conveniente da internet.
LerVirtualização: resolvida em 1967, esquecida, depois provada impossível, e feita assim mesmo
A IBM colocou um hypervisor funcionando em uso de produção em janeiro de 1967. A indústria então passou quinze anos sem um, porque hardware pessoal barato removeu a razão para compartilhar máquina - e quando a razão voltou, uma análise formal dizia que o processador dominante não podia ser virtualizado. Um grupo de Stanford fez assim mesmo. Esta é a história da família de máquinas virtuais e contêineres: duas linhagens separadas, uma vinda do mainframe e outra de um comando Unix que nunca foi feito para segurança, encontrando-se na infraestrutura sobre a qual tudo hoje roda.
LerWireless: o problema das ilhas e o protocolo que virou domínio público
Em 1968, um professor no Havaí precisava ligar computadores espalhados por quatro ilhas e não tinha como passar cabo pelo Pacífico. A solução foi deixar cada estação transmitir sempre que tivesse algo a enviar e lidar com as colisões quando acontecessem. Essa solução entrou em operação em junho de 1971, foi colocada em domínio público porque não havia um escritório para comercializá-la e hoje está na base do Wi-Fi, das redes móveis, do cabo e da Ethernet. Esta é a história da família, incluindo a decisão regulatória que pesou mais que qualquer protocolo e a falha de criptografia que deu à indústria a sua lição mais cara.
LerObsolescência: o que morre de verdade, o que se recusa a morrer e como saber a diferença
A nossa indústria erra sobre obsolescência nas duas direções. Dá como encerradas coisas que sobrevivem décadas a esse anúncio e trata como permanentes coisas que somem num único ciclo de produto. Com base nas histórias de família e nos registros de empresas deste catálogo, este artigo tenta algo mais útil do que prever: os mecanismos concretos pelos quais uma tecnologia realmente morre, as razões concretas pelas quais outras não morrem de jeito nenhum e o que as duas coisas significam para quem está decidindo o que vale a pena aprender.
LerObservabilidade: o protocolo temporário que sobreviveu ao próprio substituto
Em 1988, um grupo de trabalho publicou um protocolo que fora instruído a manter simples, pensado como paliativo, autenticado por uma senha enviada em texto claro. Ele virou o jeito como o mundo observa suas redes e continua rodando. O sucessor mais seguro dele desabou sob a complexidade da própria segurança. Esta é a história da família - do SGMP e da RFC 1067 até o fracasso da versão 2 e a telemetria por fluxo - e o que ela diz sobre por que segurança ruim sobrevive.
LerTempo: a dependência que ninguém lista
Um mesmo homem projetou o primeiro roteador moderno em software e o protocolo que mantém os relógios da internet, e fragmentos do código escrito para ele em 1985 ainda estão rodando. Tempo não aparece em diagrama de arquitetura nenhum e está embaixo de certificados, tíquetes, registros, códigos de uso único e metade dos controles de segurança deste catálogo. Esta é a história da família do NTP - o Fuzzball, a RFC 958, os segundos bissextos especificados desde o primeiro documento, e o comando de depuração que virou arma.
LerO modelo OSI na prática: como mapear tráfego real nas sete camadas
O modelo Open Systems Interconnection vale menos como decoreba de prova e mais como uma linguagem comum para localizar problemas: endereço MAC é camada 2, endereço IP é camada 3, porta TCP ou UDP é camada 4, e a aplicação fica por cima. Como encaixar o que você vê na rede em cada camada, onde o modelo não bate com o TCP/IP real e por que o troubleshooting anda mais rápido quando todo mundo fala da mesma camada.
LerLAN, WAN e as palavras que deixaram de significar distância
A diferença entre rede local e WAN nunca foi, de fato, uma questão de geografia. O que importava era quem era dono do link e quanto custava transportar um byte, e todo protocolo escrito antes de 1995, mais ou menos, traz embutida uma suposição sobre o lado dessa linha em que ia rodar. Esta é a história da família do escopo de rede: por que as categorias foram inventadas, por que as VLANs e os overlays quebraram essas categorias e por que um setor que passou trinta anos insistindo que o perímetro era um lugar hoje usa a palavra local para dizer confiável.
LerSwitch, roteador e firewall: quem faz o quê no caminho do tráfego
Três tipos de equipamento ocupam a maior parte de qualquer diagrama de rede: o switch encaminha frames dentro de um domínio de camada 2, o roteador leva pacotes de uma rede para outra e o firewall decide o que pode passar. A função e o propósito de cada um, como um application delivery controller se relaciona com os três e como ler um diagrama de rede sem se perder.
LerARP e endereços MAC: como o IP descobre o endereço Ethernet
Numa rede local, todo pacote é entregue pelo endereço MAC, e o ARP é o serviço que descobre qual MAC corresponde a um IP. O mapeamento um para um entre IP e MAC, como ler a saída do ARP para provar que a resolução funcionou, o gratuitous ARP e o MAC masquerading: o truque de failover que muda um endereço de equipamento sem que os switches percebam.
LerTabelas de roteamento e o default gateway: como um pacote escolhe o próximo hop
Uma tabela de rotas responde à única pergunta que todo host e todo roteador fazem a um pacote: para onde ele vai agora. O host decide entre local e remoto pela máscara e entrega o resto a um default gateway; o roteador poda a tabela até sobrar uma entrada, por basic match e longest match, com a rota default de prefixo zero como entrada de último recurso. Depois da leitura, você consegue executar a decisão de longest match à mão, ler uma tabela Linux ou Windows linha a linha, dizer como um host aprendeu seu default (à mão, por DHCP, por Router Discovery ou por um Router Advertisement IPv6) e reconhecer um default ausente, morto ou falso pelos sintomas.
LerTeste e medição: a família que confere as outras
Toda outra família deste catálogo constrói alguma coisa. Esta existe para descobrir se o que as outras afirmam é verdade - e começou como ferramenta interna de engenharia cujos direitos alguém levou numa aquisição. Esta é a história: o TART numa subsidiária em 1982, o Sniffer vendendo novecentos e trinta e três milhões de dólares, um documento de padronização que abre acusando os fabricantes de fumaça e espelhos, e um analisador gratuito escrito porque uma empresa só tinha dinheiro para um instrumento.
LerComo ler ip route, netstat e route print, campo a campo
A impressão de uma tabela de roteamento é uma só decisão escrita em três dialetos: o iproute2 do Linux imprime pares de palavra-chave e valor, o net-tools e o netstat do BSD imprimem colunas com letras de flag, e o route print do Windows imprime uma tabela com máscara por família de endereços. Depois da leitura, você consegue nomear cada campo das três saídas, achar as rotas default e dizer qual vence, reconhecer as rotas que descartam tráfego ou que nunca são consultadas, e descobrir à mão qual linha um destino usa.
LerDHCP: o ciclo de vida do lease por trás do endereçamento automático
Um lease do Dynamic Host Configuration Protocol (DHCP) é um endereço IPv4 emprestado a um host por tempo fixo: concedido em quatro mensagens, estendido em T1 pelo mesmo servidor ou em T2 por qualquer servidor, e devolvido ao expirar. Depois da leitura, você consegue dizer quem envia cada mensagem a quem, calcular T1, T2 e a expiração de um lease real, explicar DHCPNAK, DHCPDECLINE, DHCPRELEASE e DHCPINFORM, prever o que o cliente faz quando o servidor desaparece, e reconhecer um servidor mudo, um endereço 169.254, um servidor rogue e um pool esgotado.
LerO ciclo de vida da conexão TCP: handshake, encerramento, e por que conexões falham
Toda conversa TCP tem três atos: o handshake de SYN que a cria, o fluxo de dados que a justifica, e o FIN ou RST que a encerra. A diferença entre o fechamento educado e o aborto, as possíveis razões de término de uma conexão, e a lista curta de causas quando uma nem chega a se estabelecer - a alfabetização por trás de toda captura que você vai ler.
LerFundamentos de VPN: o que túneis protegem, e o que não protegem
Uma virtual private network embrulha o tráfego num túnel cifrado para que ele cruze redes não confiáveis como se nunca tivesse saído de casa. O racional - privacidade, criptografia e os limites do anonimato -, os usos válidos de enlaces site-to-site ao acesso remoto, e as fronteiras honestas: o que um túnel genuinamente protege, e as promessas que ele não consegue manter.
LerA última milha: do POTS à conexão sempre ativa
A história da conectividade residencial é a história de um trecho teimoso de infraestrutura, a última milha, reinventado quatro vezes: a telefonia fixa tradicional, que levava voz; o truque do ADSL, que fez o mesmo par de cobre levar dados o tempo todo; a segunda vida da rede de TV a cabo com o DOCSIS; e a fibra até a casa. Por que os 256 kbps de 1999 importaram por muito mais que a velocidade, o que a conexão sempre ativa mudou de fato e como uma mesma casa pode acabar atendida, ao mesmo tempo, pelo fantasma do cobre, pelo coaxial, pela fibra e pelo céu.
LerPagers e redes de paging: alcançável antes do tempo real
Antes do telefone no bolso, havia o bip no cinto: um receptor de rádio unidirecional numa rede de broadcast em simulcast, alimentada - na sua forma clássica - por uma operadora humana que pegava as palavras de quem ligava e as digitava para o ar. Como as redes de paging de fato funcionavam, dos bipes two-tone ao POCSAG e ao FLEX, por que o modelo de retransmissão por operadora significava estranhos lendo a sua vida em voz alta, e por que hospitais mantiveram pagers muito depois de todo mundo seguir em frente.
LerConstelações LEO: por que a nova internet por satélite é outro animal
Satélites geoestacionários resolveram cobertura e perderam latência: estacionados a 35.786 km, a física sozinha cobra meio segundo de ida e volta. Constelações em órbita terrestre baixa invertem o negócio - satélites a poucas centenas de quilômetros, latência nas dezenas de milissegundos, ao preço de precisar de milhares de satélites em movimento, terminais phased-array que os rastreiam, e handoffs constantes. A geometria, a engenharia que ela força, os enlaces laser entre satélites, e as trocas honestas.
LerLoRa e LPWAN: quilômetros de alcance numa bateria de moeda
Há um canto do networking onde os requisitos invertem tudo que a banda larga otimiza: enviar poucos bytes, poucas vezes por hora, por quilômetros de cidade, de uma bateria que precisa durar anos. LPWAN é esse canto; LoRa é seu cidadão mais conhecido - o rádio de chirp spread spectrum da Semtech trocando taxa de bits por orçamentos de enlace espantosos, e o LoRaWAN, a camada de rede da LoRa Alliance, organizando gateways, classes de dispositivo e a etiqueta de duty cycle do espectro compartilhado.
LerMétodos HTTP: os verbos da web
GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS, TRACE, CONNECT - e agora QUERY. O que cada método promete, por que 'safe' e 'idempotente' são as duas propriedades que de fato importam (para caches, retentativas, proxies e crawlers), por que formulários HTML só aprenderam dois verbos, e como ler a alma de uma API pelos métodos que ela aceita.
LerCódigos de status HTTP: as cinco famílias
Três dígitos, e o primeiro faz a maior parte do trabalho: 1xx continua, 2xx tem sucesso, 3xx redireciona, 4xx culpa o cliente, 5xx confessa pelo servidor. A lógica das famílias, os códigos que um operador de fato encontra (200, 204, 301 vs 302 vs 307, a dança de cache do 304, 401 vs 403, 404 vs 410, 429, 500 vs 502 vs 503 vs 504), as curiosidades famosas, e por que o primeiro dígito de um código desconhecido sempre basta para agir.
LerHeaders HTTP: a anatomia dos metadados
Tudo o que o HTTP sabe sobre uma mensagem, e que não é a própria mensagem, viaja nos headers: linhas nome, dois-pontos, valor, com nomes que não diferenciam maiúsculas de minúsculas, organizadas em quatro papéis práticos: contexto da requisição, contexto da resposta, metadados da representação e, por fim, negociação e condicionais. A divisão entre end-to-end e hop-by-hop, que rege a vida dos proxies, o header Host, que tornou possível a hospedagem virtual, a negociação de conteúdo, as requisições condicionais e por que a ordem dos headers virou um fingerprint.
LerCookies HTTP: estado sobre um protocolo sem estado
O HTTP esquece você depois de cada requisição - por projeto. Cookies são o retrofit que o deixa lembrar mesmo assim: o servidor escreve um bilhete com Set-Cookie, o navegador o devolve com Cookie, e todo o resto - escopo, vida útil, segurança - são regras sobre quando esse bilhete viaja. Escopo por Domain e Path, vidas de sessão vs persistente, por que o servidor nunca vê o que o navegador sabe, e onde o artigo de flags de segurança assume.
LerAJAX, XHR e fetch: quando as páginas aprenderam a responder
Na primeira década, a web tinha um movimento só: clique, tela em branco, página nova. O XMLHttpRequest deu às páginas um segundo - pedir dados em segundo plano, atualizar no lugar - e 'AJAX' batizou a revolução (que prontamente trocou o X pelo JSON). Como o XHR funcionava, o que o fetch consertou (promises, streams, uma API sã), o que ficou igual por baixo (continua tudo HTTP), e a fronteira a que toda requisição de fundo responde: same-origin, com CORS como exceção negociada.
LerHTML, CSS e o DOM: a página como árvore viva
Três tecnologias, uma divisão de trabalho: HTML declara estrutura, CSS declara apresentação, e o DOM é o que de fato existe em tempo de execução - a árvore que o navegador construiu do seu HTML, a única coisa que scripts tocam, e a razão de 'ver código-fonte' e 'inspecionar elemento' mostrarem mundos diferentes. Como marcação vira árvore, como seletores a endereçam (os mesmos seletores com que o CSS estiliza e os scripts consultam), e por que o DOM é onde o XSS acontece e onde a CSP monta guarda.
LerO que é um algoritmo? Um primer de trabalho
Um algoritmo é uma receita finita e sem ambiguidade que transforma entrada em saída - e as perguntas de engenharia são sempre as mesmas três: está correto, como o custo cresce, e o que ele troca. Big-O como a gramática do crescimento, por que constantes e assíntotas importam, as famílias centrais que você já opera (busca, ordenação, hash, grafos, máquinas de estado), e onde cada uma já roda dentro das ferramentas deste site.
LerA família IEEE 802, grupo a grupo
O 802 não é um padrão só: é um comitê com vários grupos de trabalho, e cada um cuida de uma parte das duas camadas de baixo. Aqui está o mapa: quem cuida do Ethernet, quem cuida do Wi-Fi, o que querem dizer os números depois do ponto e quais grupos estão ativos, em hibernação ou extintos há muito tempo.
LerCabeamento estruturado: o sistema por trás do ponto de rede
A TIA-568 transforma a fiação de um prédio, antes improvisada, num sistema: cabeamento horizontal, salas de telecom, o canal de 100 metros, categorias, pinagens e as classificações de resistência ao fogo que a fiscalização realmente confere. O mapa completo, do espelho na parede até o backbone.
LerBGP: como a internet decide para onde o tráfego vai
O Border Gateway Protocol é o protocolo de roteamento entre sistemas autônomos: cada rede conta aos vizinhos quais prefixes alcança e por quais redes, e cada roteador guarda um best path por prefix, escolhido primeiro pela política local e depois por uma ordem fixa de desempate. Depois da leitura, você consegue situar um número de AS no seu registro, acompanhar uma session do TCP até Established, ler os path attributes, percorrer a escolha do best path numa saída real de roteador e dizer o que um AS path prova e o que não prova.
LerOSPF: o mapa, a matemática e a área 0
O OSPF é o protocolo de gateway interior link-state padronizado como Internet Standard: cada roteador faz o flooding da descrição dos próprios enlaces, todos os roteadores de uma área guardam o mesmo banco de dados e cada um calcula a própria árvore de caminhos mais curtos a partir dele. Depois da leitura, você consegue calcular uma rota à mão a partir dos costs, dizer por que dois roteadores não viram neighbors, explicar a eleição do designated router e as regras das áreas, definir costs sem cair na armadilha da reference bandwidth e ler a saída de neighbors, banco de dados, rotas e interfaces do FRRouting.
LerIS-IS: o protocolo de roteamento escondido sob a internet
O Intermediate System to Intermediate System (IS-IS) é o protocolo de roteamento link-state que a ISO escreveu para o OSI e que a RFC 1195 estendeu ao IP: inunda o estado dos enlaces como o OSPF, mas seus pacotes viajam direto na camada de enlace, fora do IP. Depois da leitura, você consegue montar um NET a partir de um endereço de loopback, distinguir o roteamento Level 1 do Level 2, prever qual roteador vira o DIS numa LAN, ler show isis neighbor e show isis database no FRRouting e dizer o que a autenticação protege e o que deixa aberto.
LerMPLS: rótulos, pilhas e o núcleo livre de BGP
O Multiprotocol Label Switching (MPLS) classifica o pacote uma única vez, na borda da rede, e dali em diante os roteadores o encaminham por um label curto, com swap, pop ou push, sem ler de novo o header IP. Depois da leitura, você consegue decodificar em hexadecimal uma entrada da pilha de labels, nomear os labels de uso especial, seguir um label-switched path numa tabela de bindings real do Label Distribution Protocol (LDP), dizer exatamente o que um núcleo livre de BGP mantém e descarta, e explicar os dois labels de um pacote de rede privada virtual (VPN) de camada 3.
LerPeer-to-peer, do Napster ao swarm: as arquiteturas que sobreviveram à pirataria
Napster, Gnutella, Kazaa, eMule, BitTorrent: em quatro anos, o compartilhamento de arquivos produziu cinco arquiteturas de rede diferentes, cada uma corrigindo a fraqueza que matou a anterior. O índice centralizado, o flooding não estruturado, o supernode, a tabela hash distribuída e o swarm: o que cada um era de verdade, como os tribunais moldaram a topologia e por que essas ideias continuam, sem alarde, por trás do Skype, das CDNs de streaming e das blockchains.
LerA reserva de mercado brasileira, na teoria e na prática
Por oito anos o Brasil reservou legalmente seu mercado de informática a empresas de capital nacional. A teoria era uma indústria nascente que cresceria e competiria. A prática foi clones, contrabando, uma guerra comercial com Washington e uma geração de engenheiros que aprendeu nas máquinas que a política criou. As duas metades são verdadeiras.
LerTransformação digital: o que mudou de fato, e como ler o que vem a seguir
Transformação não é a tecnologia chegando. É o momento em que uma capacidade deixa de ser notável e passa a ser pressuposta. Um olhar sobre o que realmente mudou em dinheiro, trabalho, saúde e Estado, e depois um método honesto para ler previsões, incluindo um prazo que é real e está em movimento ao mesmo tempo.
LerComo a internet é desligada, e quem de fato consegue fazer isso
Não existe um interruptor, mas existem pontos de estrangulamento: cabos, roteamento, trocas de tráfego e o pequeno número de empresas por onde a maior parte do tráfego passa. Um passeio pelos mecanismos, pelo que cada Estado realmente consegue fazer com eles, e pela conclusão incômoda de que vigiar tudo é mais fácil do que desligar qualquer coisa.
LerQuem de fato governa a internet no Brasil
O Brasil construiu um dos modelos de governança da internet mais distintos do mundo: multissetorial antes de a palavra existir, com uma fundação de pesquisa operando a primeira conexão do país e um comitê que não é ministério. Os órgãos, as leis, a espinha dorsal de computação estatal por baixo de tudo, e a decisão de 2025 que reescreveu a responsabilidade das plataformas.
LerA janela das comunicações de dados, 1968 a 1972
Um regulador abriu um mercado. A decisão Carterfone permitiu conectar à rede telefônica equipamentos que a AT&T não fabricara, e em quatro anos existia uma indústria de modems e multiplexadores que antes não podia existir. O gatilho, a janela, os produtos que a definiram e por que ela fechou.
LerRadioamadorismo: indicativos, modos, e por que ainda importa
Um indicativo é uma identidade emitida por tratado, legível em qualquer lugar do planeta. O que as letras e o dígito significam, como PY2 diz São Paulo, a diferença entre fonia, CW e digitais, o que uma repetidora de fato faz, e por que um hobby mais antigo que a radiodifusão ainda é o recurso final quando todo o resto falha.
LerA janela das redes locais, 1979 a 1982
As corporações vinham comprando computadores havia uma década e agora precisavam que eles conversassem dentro do prédio. A janela aberta por volta de 1979 produziu as redes locais e o data PBX, decidiu uma disputa entre duas respostas para o mesmo problema, e fechou quando a resposta ficou óbvia.
LerO espectro de rádio: até onde vai cada frequência, e por quê
Por que um sinal de ondas curtas atravessa um oceano com 100 watts, enquanto o seu Wi-Fi mal passa por uma parede. As faixas de VLF a EHF, os três modos de propagação que explicam quase tudo e o trade-off que define todo o rádio: alcance ou capacidade, nunca os dois.
LerA janela da interconexão de redes, 1984 a 1988
O sucesso da janela anterior criou o problema desta: prédios cheios de redes locais que não se alcançavam. Pontes e roteadores responderam, uma guerra de padrões correu em paralelo, e duas feiras em 1988 tornaram o desfecho visível antes de a discussão terminar formalmente.
LerAs duas feiras de 1988
Uma feira pôs equipamentos de fabricantes concorrentes numa única rede viva, em público, onde a falha seria vista. A outra mostrou um ecossistema em boa parte descrito, e não entregue. A discussão de padrões seguia formalmente aberta, e quem andasse pelos dois salões não precisava dela encerrada.
LerOs fundadores que não paravam de fundar
Ler esta indústria como uma sequência de empresas ignora que ela é, em boa medida, a mesma população de pessoas se recombinando. Ungermann saiu da Intel para a Zilog e da Zilog para a Ungermann-Bass; Metcalfe saiu da Xerox para a 3Com. O que esse padrão explica, e o que não explica.
LerBFD: quando um enlace está no ar e morto ao mesmo tempo
O Bidirectional Forwarding Detection (BFD) é um pequeno protocolo de hello entre dois planos de encaminhamento que percebe quando um caminho parou de levar pacotes, inclusive quando as duas interfaces continuam no ar, muito antes dos timers do próprio protocolo de roteamento. Depois da leitura, você consegue calcular um tempo de detecção a partir dos dois timers e do multiplicador, ler uma session no FRRouting campo a campo, escolher qual protocolo deve ser o cliente dela e dizer onde o próprio BFD pode ser enganado.
LerDimensionar timers do BFD: a aritmética da detecção
O Bidirectional Forwarding Detection (BFD) nunca envia o tempo de detecção: cada receptor o calcula a partir do multiplicador do outro lado e do intervalo que os dois acordam, separadamente em cada sentido. Depois da leitura, você consegue partir de uma meta de detecção e chegar a intervalos e a um multiplicador, prever os dois sentidos de uma sessão a partir dos seis números configurados e reconhecer o início lento, o jitter, o hardware e o Echo que esticam o resultado.
LerRedundância de first hop: VRRP, HSRP e o gateway que é uma ficção
Os protocolos de redundância de first hop, como o VRRP e o HSRP, fazem vários roteadores dividirem um único endereço de default gateway e um único MAC virtual, para que os hosts continuem encaminhando tráfego quando o roteador por trás desse endereço cai. Depois da leitura, você consegue dizer o que um host faz e o que não faz sozinho, calcular o tempo de failover do VRRPv3 a partir da prioridade e do intervalo, comparar os defaults do HSRP, reconhecer as falhas comuns e a superfície de ataque e encontrar os dois protocolos numa captura e na saída dos roteadores.
LerMulticast: o preço de não inundar
O multicast IP envia um datagrama a um endereço de grupo e deixa a rede fazer as cópias, e o preço é estado em cada switch e roteador que precisa saber onde estão os membros. Depois da leitura, você consegue mapear um endereço de grupo para o endereço MAC (media access control), calcular os timeouts do Internet Group Management Protocol (IGMP), explicar por que um switch inunda multicast e o que a falta de um querier provoca, ler o estado do Protocol Independent Multicast (PIM) no FRRouting e dizer o que o Source-Specific Multicast elimina.
LerResolvedores DNS públicos: o que você está de fato escolhendo
Um resolver público é um resolver recursivo que qualquer pessoa pode usar, e trocar para um deles entrega ao operador todo nome que o seu dispositivo consulta. O que separa 1.1.1.1, 8.8.8.8, 9.9.9.9 e 208.67.222.222 é política, não velocidade: o que é registrado e por quanto tempo, quais endereços filtram e como um bloqueio responde, se há validação DNSSEC, se a sua sub-rede é repassada aos servidores autoritativos e quais transportes cifrados são oferecidos. Depois da leitura, você consegue ler as páginas de um operador contra a lista que a RFC 8932 pede que ele publique, escolher por esses critérios e testar cada um com dig e curl.
LerPython como calculadora do engenheiro de redes: a biblioteca padrão já sabe a sua aritmética
Divisões de sub-rede, agregação de rotas, máscaras wildcard, EUI-64, um cabeçalho DNS em bytes, um HMAC, um p95 de amostras de latência, um tempo de transferência na taxa da linha: cada um é poucas linhas de Python sem instalar nada, porque ipaddress, struct, hmac, statistics e re vêm com o interpretador. Este artigo percorre os doze exemplos com que o playground de Python abre, diz qual módulo faz o trabalho em cada um e por que é o certo, aponta as armadilhas (hosts() em um /31, arredondamento para o par, o bit universal/local), e mostra onde as mesmas respostas saem à mão nas outras ferramentas deste site, para que você confira uma contra a outra.
LerHTTP a partir da linha de requisição: o que uma mensagem quer dizer e como ela viaja
Toda troca HTTP tem duas mensagens, uma requisição e uma resposta, e desde junho de 2022 o padrão descreve essas mensagens em duas camadas: o que a mensagem significa (métodos, códigos de status, campos de header), definido uma única vez para todas as versões, e como os bytes dela trafegam, definido separadamente para cada versão. É o mapa da série sobre HTTP: qual artigo lê qual parte da mensagem, e em que ordem.
LerAs histórias das famílias: vinte e três tecnologias, cada uma contada desde o primeiro dia
Vinte e três das tecnologias que formam uma rede e a segurança dela, do transceiver ao firewall de aplicação web, cada uma contada como a história de uma família: o momento, com data, em que ela começou e as pessoas envolvidas, a discussão que decidiu o que ela viria a ser, o que ela mudou nos empregos e nas práticas, e para onde ela vai. Como as histórias são contadas, o que procurar em cada uma e uma ordem de leitura.
LerO frame Ethernet campo a campo: do preâmbulo ao FCS, a tag 802.1Q e os tamanhos que importam
Todo frame Ethernet segue a mesma sequência curta de campos: um preâmbulo que prepara o receptor, dois endereços, um campo que indica um tamanho ou um tipo, o payload e um checksum. O que cada campo leva, por que o mínimo é de 64 octetos e o máximo de 1518, onde fica a tag 802.1Q e o que ela carrega, e por que os jumbo frames não fazem parte do padrão.
LerVLANs e trunking 802.1Q: tagged, untagged, VLAN nativa e VLAN de voz
Uma VLAN divide uma rede de switches em várias redes que não escutam os broadcasts umas das outras, e o 802.1Q é o que permite a um único cabo levar muitas delas ao mesmo tempo. Portas de acesso e portas trunk nos termos do próprio padrão, a VLAN nativa e o mismatch que coloca a rede em loop, os ataques de VLAN hopping e as configurações que os impedem, a VLAN de voz por trás de todo telefone IP de mesa e por que o tráfego entre VLANs sempre precisa de um roteador.
LerSpanning tree em um só artigo: por que a porta bloqueada não é defeito e como o RSTP e o MSTP deixaram o protocolo rápido
Links redundantes entre switches formam loops, e o header Ethernet não tem nada que impeça um frame de ficar circulando para sempre. O Spanning Tree Protocol resolve isso elegendo um root bridge e bloqueando todas as portas de que a árvore não precisa. O artigo explica a eleição, os custos e os timers, os 30 a 50 segundos que o STP clássico levava para se recuperar, o handshake que deixou o RSTP rápido, as regiões e instâncias do MSTP, as variantes por VLAN da Cisco e seus recursos de proteção, e conta a história da engenheira que escreveu em forma de poema o resumo do artigo em que apresentou o algoritmo.
LerLink aggregation e LACP: vários links funcionando como um só, e o protocolo que garante que as duas pontas estão de acordo
Um link aggregation group (LAG) junta links Ethernet paralelos num único link lógico, para ter mais banda e mais resiliência. O artigo mostra de onde veio o padrão (802.3ad, depois 802.1AX), como o LACP faz as duas pontas entrarem em acordo antes de qualquer frame ser enviado, os timers fast e slow, por que LAGs estáticos são arriscados, por que um fluxo nunca passa da velocidade de um link membro, as regras que os membros precisam seguir, os LAGs entre dois chassis e os modos de bonding do Linux.
LerCamadas físicas da Ethernet, do 10BASE-T ao 400GBASE: nomenclatura, autonegociação, duplex e o mismatch que arruína um link
A Ethernet é um único formato de frame rodando sobre dezenas de camadas físicas, de 10 Mb/s em cobre de padrão telefônico a 400 Gb/s em fibras paralelas. Como ler um nome como 100GBASE-SR4, as emendas que trouxeram cada velocidade, o que o cobre exige para chegar a 100 metros, como os bits viram sinal, por que o full duplex acabou com as colisões, o que a autonegociação define e como uma ponta fixada em full duplex, com a outra negociando, produz o clássico duplex mismatch.
LerFundamentos de fibra óptica: multimodo e monomodo, as categorias e suas cores, conectores e polaridade, o orçamento de perdas e por que a sujeira é a primeira suspeita
A fibra óptica leva os links Ethernet mais longos e mais rápidos. Os dois tipos de fibra e por que um núcleo largo limita o alcance; as categorias OM e OS e as cores de capa que identificam cada uma; até onde um mesmo transceiver chega em cada categoria; os conectores LC, SC e MPO; faces planas e anguladas, e por que uma nunca deve ser conectada à outra; a polaridade, com a transmissão de uma ponta ligada à recepção da outra; o orçamento de perdas calculado com números reais; sujeira, inspeção e limpeza; a luz que não se vê; e as leituras que o próprio transceiver informa sobre si.
LerRoteamento dinâmico: distance vector, link state e path vector comparados
Todo protocolo de roteamento dinâmico responde à mesma pergunta, para onde mandar o pacote a seguir, e as famílias de protocolos diferem no que cada roteador fica sabendo pelos outros e no que ele calcula por conta própria. No distance vector, os roteadores trocam suas tabelas com os vizinhos; no link state, cada roteador faz o flooding de um mapa da rede e calcula a própria árvore; no path vector, a rota carrega a lista das redes por onde passou; e o DUAL, do EIGRP, aperfeiçoa o distance vector até ele ficar livre de loops a todo instante. O que cada um sabe, como cada um evita loops, com que rapidez cada um se recupera e onde entram o RIP, o OSPF, o IS-IS, o BGP e o EIGRP, com base nas RFCs de cada um.
LerRedistribuição de rotas e os loops que ela pode criar
Na redistribuição, o roteador anuncia num protocolo de roteamento as rotas que aprendeu por outro, ou as próprias rotas estáticas e conectadas. Toda rede com mais de um protocolo precisa dela, e ela é o jeito mais comum de criar um loop de roteamento por configuração. O que o padrão exige, por que a métrica tem de ser inventada na entrada, como a administrative distance transforma dois pontos de redistribuição num loop de feedback e as soluções que funcionam: filtros, tags, redistribuição num sentido só e rota padrão, com base na RFC 1812, nas especificações do OSPF e do RIP e nos exemplos da própria Cisco.
LerOpções de BOOTP e DHCP: o que o cliente pede, e o que ele recebe
Nomear cada campo do pacote que o BOOTP definiu em 1985 e que o DHCP envia até hoje, e explicar como o DHCP transformou o último campo numa lista de opções. Decodificar uma opção do magic cookie até o marcador de fim, dizer o que as opções mais comuns carregam e que lado as envia, e usar o registro da IANA para distinguir um código padrão de um código privado quando uma captura ou um log de servidor mostra um número desconhecido.
LerO relay agent de DHCP: um servidor para muitas sub-redes
Um cliente DHCP que ainda não tem endereço faz broadcast da requisição, e o servidor de que ele precisa costuma estar em outra rede. O relay agent recebe esse broadcast, marca nele o endereço da sub-rede de origem, envia uma mensagem nova ao servidor e traz a resposta de volta. Depois da leitura você consegue acompanhar as duas mensagens passo a passo, explicar giaddr, o campo hops, a flag BROADCAST e a opção 82, configurar ip helper-address no Cisco IOS e diagnosticar uma sub-rede remota que não recebe lease.
LerPXE e boot pela rede: como uma máquina sem disco descobre o que executar
Uma máquina sem sistema operacional, ou sem disco nenhum, ainda consegue dar boot pedindo à rede um endereço e o nome de um programa para baixar e executar. Depois de ler, você vai conseguir acompanhar um boot PXE do primeiro DHCPDISCOVER até a primeira instrução executada, ler as opções que identificam o cliente, explicar por que o Proxy DHCP escuta na porta 4011, escolher o arquivo de boot certo para máquinas BIOS e UEFI e situar os sucessores do projeto de 1999 em IPv6 e HTTP.
LerTFTP: a transferência de arquivos mais simples, e onde ela ainda roda
O Trivial File Transfer Protocol move um arquivo sobre UDP em blocos de 512 bytes, um bloco em trânsito e um ACK para cada um, sem login e sem listagem de diretório. Depois da leitura, você consegue acompanhar uma transferência pacote a pacote, da porta 69 ao último bloco curto, explicar a Sorcerer's Apprentice Syndrome e as opções que negociam tamanho de bloco, timeout, tamanho de arquivo e janela, e dizer onde o protocolo ainda roda e o que verificar quando uma transferência trava.
LerTransferências de zona e NOTIFY: como os servidores secundários ficam em dia
Toda zona DNS precisa ser servida por pelo menos dois servidores autoritativos, e as cópias precisam concordar. Depois da leitura, você vai saber ler os timers do registro SOA de uma zona e prever quando o secondary faz polling, reconhecer uma troca AXFR, IXFR ou NOTIFY numa captura de pacotes, explicar por que as transferências são restringidas e cifradas, e conferir com o dig se os servidores de uma zona têm o mesmo serial.
LerDNSSEC de ponta a ponta: da chave da raiz à resposta validada
Depois de ler, você consegue acompanhar uma validação DNSSEC desde o trust anchor da raiz até a resposta assinada, nomear o registro que carrega cada elo e explicar por que um resolver devolveu SERVFAIL, uma flag ad ou nada de especial. Também vai saber qual chave da raiz está assinando hoje, quais algoritmos o registro da IANA ainda permite e como conferir uma validação com dig e delv.
LerDoT, DoH e DoQ comparados: como cifrar a pergunta
O DNS clássico manda toda pergunta às claras, e o trecho entre o stub resolver e o resolver recursivo é onde quem escuta aprende mais. DoT, DoH e DoQ cifram esse trecho de três maneiras diferentes. Depois da leitura você consegue dizer o que cada um esconde e o que nenhum deles esconde, ler suas portas e seu enquadramento, distinguir o perfil Strict do Opportunistic, explicar como um cliente descobre um resolver cifrado e escolher um transporte para uma rede com os argumentos dos próprios padrões.
LerAnycast: um endereço em muitos lugares
O anycast anuncia um mesmo endereço de serviço a partir de muitos lugares independentes e deixa o sistema de roteamento decidir qual deles cada cliente alcança. Depois de ler, você consegue defini-lo nas palavras da RFC 1546 e da BCP 126, explicar por que mais próximo quer dizer mais próximo na tabela de rotas e não no mapa, dizer por que o DNS sobre UDP se encaixa nele e o TCP sofre, ler a lista de servidores raiz do root-servers.org e rodar uma consulta dig que revela qual instância respondeu a você.
Ler