O protocolo invisível que faz bilhões de relógios baterem juntos

Todos os dias, o seu celular, o roteador de casa, o servidor que processa o cartão de crédito na padaria e o satélite que sustenta o GPS concordam, em silêncio, sobre que horas são. Essa concordância não é natural — relógios de computador, por conta própria, andam torto. Osciladores de quartzo baratos ganham ou perdem frações de segundo por hora, e depois de alguns dias sem correção um servidor pode estar minutos adiantado ou atrasado em relação ao resto do mundo. Ainda assim, bilhões de máquinas conectadas à internet mantêm seus relógios alinhados com precisão de milissegundos, o tempo todo, sem que ninguém perceba.

Quem faz esse trabalho é o NTP, o Network Time Protocol — um dos protocolos mais antigos da internet ainda em uso ativo, mais velho até que a web. Ele não aparece em nenhuma tela, não tem interface, não vira notícia quando funciona. Mas quando falha, os efeitos são desproporcionalmente grandes: certificados de segurança que deixam de validar, bancos de dados que se corrompem, sites inteiros que saem do ar porque um servidor, por um instante, achou que o tempo tinha andado para trás.

Este texto reconstrói três coisas: quem criou o NTP e por quê, como ele efetivamente resolve o problema de sincronizar relógios através de uma rede com atraso variável, e o que aconteceu nas vezes em que essa engenharia silenciosa deu errado — derrubando de companhias aéreas a serviços que milhões de pessoas usam todos os dias.

Um problema de doutorado que virou infraestrutura global

O NTP nasceu do trabalho de David L. Mills, professor da Universidade de Delaware, que começou a lidar com o problema de sincronização de relógios em redes ainda nos anos 1970, quando trabalhava com os primeiros computadores conectados à ARPANET, a rede precursora da internet. As primeiras formulações do problema aparecem em notas técnicas do início dos anos 1980, e a primeira especificação formal do protocolo foi publicada em 1985, como RFC 958 — um documento que já trazia o formato de pacote e o método de cálculo de atraso e offset que, décadas depois, ainda estruturam a versão atual do protocolo, o NTPv4.

O trabalho de referência que consolidou a arquitetura do NTP para a comunidade acadêmica é o artigo Internet Time Synchronization: the Network Time Protocol, publicado por Mills na IEEE Transactions on Communications em 1991 — um paper que, até hoje, acumula mais de duas mil citações e é tratado como a descrição canônica do funcionamento do protocolo. Mills continuou à frente do desenvolvimento do NTP por décadas, foi eleito Fellow do IEEE e da ACM, recebeu o IEEE Internet Award em 2013 “por liderança significativa e contribuições sustentadas” à sincronização de tempo na internet, e permaneceu associado ao projeto até morrer, em janeiro de 2024, aos 85 anos.

O que Mills resolveu não foi um problema teórico abstrato. Redes de computadores da época já dependiam de sequenciamento correto de eventos — logs, transações, protocolos de consenso — e sem um relógio comum, distinguir “o que aconteceu antes” de “o que aconteceu depois” em máquinas diferentes se torna, literalmente, impossível de garantir. O NTP resolveu isso criando não um relógio único, mas uma hierarquia de confiança capaz de propagar a hora certa através de uma rede imperfeita.

A hierarquia de estratos: como a hora se espalha pela rede

O NTP organiza as fontes de tempo em camadas chamadas de “estratos” (stratum), numeradas de 0 a 16. O estrato 0 não é, tecnicamente, parte da rede: são os relógios de referência físicos — relógios atômicos de césio, receptores de sinal GPS, rádios de tempo — que fornecem a hora com precisão de microssegundos ou melhor. Servidores que se conectam diretamente a esses relógios de referência, geralmente por uma ligação física dedicada, tornam-se estrato 1, e é esse pequeno conjunto de máquinas que efetivamente ancora a hora “verdadeira” na internet.

A partir daí, a hierarquia se ramifica: servidores de estrato 2 sincronizam com servidores de estrato 1, servidores de estrato 3 sincronizam com estrato 2, e assim sucessivamente, até o estrato 15. Cada número representa a “distância” em saltos até a fonte de referência original, e essa contagem serve a um propósito prático: evitar que servidores acabem se sincronizando uns aos outros em loop, sem nenhum deles ancorado a uma fonte real de tempo. O estrato 16, por convenção, marca um dispositivo que não está sincronizado com nada — sinal de que algo na cadeia falhou.

Na prática, quase nenhum usuário final fala diretamente com um servidor de estrato 1. O computador pessoal, o roteador doméstico e a maioria dos servidores de aplicação conversam com servidores de estrato 2 ou 3, geralmente operados por provedores de internet, universidades ou serviços públicos de tempo mantidos por instituições como institutos nacionais de metrologia. É uma estrutura de árvore, redundante e distribuída, desenhada para que a falha de um único servidor nunca derrube a sincronização de toda a rede — o mesmo princípio de resiliência descentralizada que orienta boa parte da arquitetura original da internet.

A matemática que compensa o atraso da rede

O desafio central que o NTP precisa resolver não é apenas “perguntar que horas são” — é fazer isso através de uma rede onde o tempo de ida e volta de um pacote nunca é fixo nem previsível. Se um cliente simplesmente copiasse o horário informado por um servidor, o atraso da própria mensagem viajando pela rede já introduziria um erro. A solução de Mills foi elegante: em vez de uma mensagem, usar quatro.

O protocolo registra quatro marcações de tempo em cada troca: o instante em que o cliente envia a solicitação (T1), o instante em que o servidor a recebe (T2), o instante em que o servidor envia a resposta (T3) e o instante em que o cliente a recebe de volta (T4). Com esses quatro valores, é possível calcular duas grandezas separadamente: o atraso de ida e volta da rede — (T4 − T1) − (T3 − T2) — e o offset, a diferença real entre os dois relógios — ((T2 − T1) + (T3 − T4)) / 2. A separação entre essas duas contas é o que permite ao NTP estimar quanto do intervalo medido foi causado por latência de rede e quanto foi causado por diferença real entre os relógios, mesmo quando o caminho de ida e o de volta não demoram exatamente o mesmo tempo.

Uma única troca de pacotes, porém, não é confiável o bastante — picos de tráfego, filas em roteadores e congestionamento momentâneo podem distorcer uma medição isolada. Por isso, implementações de NTP repetem essa troca com múltiplos servidores de referência, aplicam filtros estatísticos para descartar amostras com atraso anormalmente alto e comparam os resultados entre si antes de ajustar o relógio local — um processo desenhado para que nenhuma fonte isolada, contaminada por congestionamento ou por erro, consiga puxar o relógio da máquina para um valor errado.

Quando um segundo a mais derruba a internet

A fragilidade dessa engenharia silenciosa ficou visível de forma dramática em 30 de junho de 2012, quando um segundo bissexto — ajuste ocasional feito para compensar a desaceleração da rotação da Terra — foi inserido à meia-noite UTC. Um bug no kernel do Linux, disparado especificamente por essa inserção, fez processadores entrarem em “livelock”: presos girando sem realizar trabalho útil. O resultado foi uma onda de quedas simultâneas em serviços como Reddit, LinkedIn, Mozilla, StumbleUpon e Yelp, além de aplicações Java como Hadoop e ElasticSearch, que passaram a travar em várias empresas ao mesmo tempo. O impacto não ficou restrito a redes sociais: o sistema de reservas Amadeus Altea, usado por companhias aéreas para gerenciar cerca de um quarto dos voos diários do mundo, ficou fora do ar por cerca de uma hora, obrigando Qantas e Virgin Australia a fazer check-in manual de passageiros.

Cinco anos depois, um episódio diferente mostrou que o problema não tinha sido de fato resolvido — apenas mudado de forma. No segundo bissexto de 1º de janeiro de 2017, a infraestrutura de DNS da Cloudflare sofreu uma falha porque seu software assumia que o tempo nunca poderia “andar para trás”. Quando o ajuste do segundo bissexto fez uma medição de tempo interna produzir um valor negativo, o código de seleção de servidores DNS entrou em pane, e cerca de 0,2% das consultas DNS da empresa em 102 data centers foram afetadas no pico do incidente, até a correção ser distribuída globalmente, horas depois. Os dois casos, separados por cinco anos e por empresas diferentes, compartilham a mesma raiz: código que parte do pressuposto de que o tempo é uma linha estritamente crescente — um pressuposto que a própria engenharia da sincronização de tempo, ocasionalmente, precisa violar.

O lado sombrio: o mesmo protocolo usado como arma

A confiança embutida no NTP também o tornou um alvo — e uma ferramenta. Servidores NTP mais antigos aceitavam um comando de diagnóstico chamado “monlist”, que devolve a lista das últimas centenas de endereços IP que se conectaram àquele servidor. Um atacante podia enviar uma solicitação falsificada, forjando o endereço de origem para ser o da vítima, e o servidor NTP respondia diretamente a ela — com uma resposta muito maior do que a solicitação original. Essa técnica, batizada de amplificação NTP, foi catalogada oficialmente como CVE-2013-5211 e afetava, segundo alerta da CISA (a agência de segurança cibernética dos Estados Unidos), praticamente todas as versões do ntpd anteriores à 4.2.7 — um universo enorme de dispositivos legados que ainda tinham o monlist ativado por padrão.

O potencial destrutivo dessa técnica ficou evidente em fevereiro de 2014, quando um ataque de negação de serviço baseado em amplificação NTP atingiu a Cloudflare com um pico acima de 400 Gbps, superando o volume do já notório ataque à Spamhaus no ano anterior e sendo, na época, classificado como o maior ataque de DDoS já registrado publicamente. A gravidade não estava apenas no volume: como as respostas partiam de servidores NTP legítimos e mal configurados, o tráfego malicioso era indistinguível, do ponto de vista da rede, de tráfego real de sincronização de tempo — o que torna esse tipo de ataque particularmente difícil de filtrar sem também bloquear usuários legítimos.

Há ainda uma segunda categoria de risco, mais silenciosa: como o NTP tradicional não autentica criptograficamente suas respostas por padrão, um atacante posicionado entre o cliente e o servidor pode, em tese, forjar respostas de tempo. Isso importa porque boa parte da segurança da web moderna depende de relógios corretos — certificados HTTPS têm data de validade, e um sistema enganado sobre a hora pode aceitar um certificado expirado ou rejeitar um válido. É justamente para fechar essa lacuna que o IETF desenvolveu o NTS (Network Time Security), uma extensão que adiciona autenticação criptográfica às trocas de tempo, hoje cada vez mais recomendada em ambientes que exigem segurança reforçada.

Uma dependência que ninguém escolheu ter

O NTP nunca foi desenhado para ser notado. Ele foi desenhado para desaparecer — para que desenvolvedores, administradores de sistema e usuários finais pudessem simplesmente presumir que “que horas são” tem uma resposta confiável, em qualquer lugar da rede, sem precisar pensar no assunto. Na maior parte do tempo, essa promessa se cumpre de forma quase perfeita havendo décadas de refinamento incremental por trás dela.

Mas os episódios de 2012, 2014 e 2017 mostram o custo de uma dependência tão profunda e tão invisível: quando a sincronização de tempo falha, ela não falha discretamente. Ela derruba sistemas de reserva de voos, embaralha o DNS de uma das maiores redes de distribuição de conteúdo do planeta e oferece, a quem sabe explorá-la, uma arma de negação de serviço capaz de gerar centenas de gigabits por segundo de tráfego indesejado. É a definição exata de infraestrutura crítica: algo que só vira notícia no dia em que para de funcionar.

Fontes citadas neste artigo: