O problema antes do NTP
Antes de a internet aprender a ver as horas, cada computador estava por conta própria. Um servidor em Nova Iorque podia adiantar-se três minutos ao longo de uma semana. Uma réplica de base de dados em São Francisco podia atrasar-se dois minutos. Um terminal de negociação em Chicago podia discordar de ambos. Ninguém reparava quando as máquinas trabalhavam isoladamente, mas no momento em que começaram a comunicar entre si, o caos tornou-se impossível de ignorar.
O tempo importa mais do que a maioria das pessoas imagina. As bolsas financeiras precisam de saber qual transação chegou primeiro. Quando dois servidores de base de dados replicam dados entre si, usam carimbos temporais para decidir qual escrita prevalece. Ficheiros de registo de diferentes máquinas precisam de ser fundidos por ordem cronológica para que os engenheiros possam diagnosticar falhas. Sistemas de controlo de tráfego aéreo, dispensadores de medicamentos hospitalares, sincronizadores de redes elétricas, autoridades de certificação que emitem as chaves de encriptação por trás de cada ligação HTTPS — todos dependem de relógios que estejam de acordo.
No início dos anos 1980, a internet ainda era um conjunto de redes universitárias e governamentais, mas o problema já era grave. As máquinas sincronizavam os seus relógios ligando para serviços de hora por linhas de modem, um processo lento, caro e terrivelmente impreciso. Alguns administradores acertavam os relógios manualmente, olhando para um relógio de pulso e digitando a hora. O erro podia ser de segundos, minutos ou pior. O que a rede em crescimento precisava era de um protocolo — uma forma automática e autocorretiva de todas as máquinas na internet concordarem sobre que horas eram.
David Mills e o nascimento do NTP
A pessoa que resolveu este problema foi David L. Mills, professor de ciência da computação na Universidade de Delaware. Mills pensava na sincronização de tempo em rede desde o final dos anos 1970, e em 1985 publicou o RFC 958, a primeira especificação formal do Network Time Protocol. Não foi a sua primeira tentativa — já tinha concebido protocolos anteriores chamados DCNET e Internet Clock Service — mas o NTP foi aquele que vingou.
O RFC 958 delineou uma arquitetura simultaneamente elegante e prática. Em vez de exigir que cada computador acedesse diretamente a um relógio atómico, o NTP organizou as fontes de tempo numa hierarquia. Utilizava matemática engenhosa para compensar atrasos de rede imprevisíveis. E foi concebido para ser robusto: se uma fonte de tempo falhasse, os clientes passavam automaticamente para outra. O protocolo conseguia sincronizar relógios através da caótica e pouco fiável internet dos anos 1980 com uma precisão de dezenas de milissegundos — uma façanha que na época parecia quase mágica.
Mills manteve e fez evoluir o NTP durante quase três décadas, praticamente sozinho. Escreveu a implementação de referência. Respondeu a perguntas em listas de correio eletrónico. Publicou RFCs atualizados à medida que o protocolo amadurecia nas versões 2, 3 e 4. Quando se reformou, o NTP tinha-se tornado um dos protocolos de internet mais antigos ainda em uso diário ativo, mais antigo que o HTTP, mais antigo que o SSL, mais antigo que o DNS tal como o conhecemos hoje. Mills faleceu em janeiro de 2024, aos 85 anos, deixando um protocolo que sincroniza silenciosamente milhares de milhões de dispositivos todos os dias. A maioria das pessoas que dependem do seu trabalho nunca ouviu o seu nome.
Como funciona o sistema de estratos
O NTP organiza as fontes de tempo em camadas chamadas estratos. No topo está o Estrato 0: o hardware de cronometragem propriamente dito. São relógios atómicos de césio, masers de hidrogénio, recetores GPS e outros instrumentos de precisão que produzem um sinal horário com exatidão de milionésimos de segundo. Não é possível ligar-se a um dispositivo de Estrato 0 pela rede — são instrumentos físicos, frequentemente aparafusados em bastidores de laboratórios nacionais ou montados em satélites a orbitar 20 200 quilómetros acima da Terra.
Os servidores de Estrato 1 são computadores diretamente ligados a hardware de Estrato 0, tipicamente através de um cabo série, uma antena GPS dedicada no telhado ou uma ligação direta a um relógio de césio no corredor. Estas máquinas leem o sinal de tempo atómico e disponibilizam-no pela rede. Existem cerca de mil servidores públicos de Estrato 1 no mundo, operados por laboratórios nacionais de metrologia, universidades e empresas de tecnologia.
Os servidores de Estrato 2 sincronizam-se a partir do Estrato 1. Os de Estrato 3 a partir do Estrato 2. Cada camada acrescenta uma pequena quantidade de erro e um pequeno atraso. A hierarquia continua até ao Estrato 15. O Estrato 16 é um valor especial que significa "não sincronizado" — um servidor no Estrato 16 está a anunciar que não tem uma fonte de tempo fiável e não deve ser considerado de confiança.
A genialidade deste desenho em camadas é a distribuição de carga. Existem milhares de milhões de dispositivos na internet que precisam de hora exata, mas apenas algumas centenas de relógios atómicos. Se todos os smartphones da Terra tentassem sincronizar-se diretamente a partir de uma fonte de césio no National Institute of Standards and Technology em Boulder, Colorado, o sistema colapsaria instantaneamente. Em vez disso, o seu telemóvel sincroniza-se com um servidor de Estrato 2 ou 3, que sincroniza com um de Estrato 1, que sincroniza com o relógio atómico. A carga distribui-se por milhões de servidores intermédios, e os relógios atómicos permanecem imperturbáveis.
A matemática engenhosa por trás do NTP
O desafio fundamental da sincronização de tempo em rede é que não se pode simplesmente perguntar a um servidor "que horas são?" e usar a resposta. A pergunta demora tempo a percorrer a rede. A resposta demora tempo a voltar. E esses dois tempos de viagem não são necessariamente iguais — um pacote pode levar 20 milissegundos a cruzar o Atlântico para oeste e 35 milissegundos a regressar para leste, dependendo do encaminhamento, do congestionamento e da fase da lua.
O NTP resolve isto com uma troca de quatro carimbos temporais. O cliente regista a hora a que envia um pedido (T1). O servidor regista a hora a que recebe esse pedido (T2). O servidor regista a hora a que envia a sua resposta (T3). E o cliente regista a hora a que recebe essa resposta (T4). A partir destes quatro números, o NTP calcula dois valores importantes.
O atraso de ida e volta é (T4 - T1) - (T3 - T2). Isto indica quanto tempo o pacote passou em trânsito, excluindo o tempo que o servidor demorou a processar o pedido. O desvio do relógio é ((T2 - T1) + (T3 - T4)) / 2. Esta é a diferença estimada entre o relógio do cliente e o relógio do servidor, assumindo que o atraso da rede é aproximadamente simétrico em ambas as direções.
Essa suposição de simetria nem sempre é verdadeira, e o NTP sabe disso. O protocolo não depende de uma única troca. Consulta múltiplos servidores, recolhe muitas amostras ao longo do tempo, aplica filtragem estatística para descartar valores aberrantes e usa algoritmos com nomes como "algoritmo de seleção de relógio" e "algoritmo de agrupamento de relógio" para escolher as melhores fontes e combiná-las. O resultado, na internet pública com toda a sua imprevisibilidade, é uma sincronização com precisão de poucos milissegundos. Numa rede local, onde os atrasos são curtos e estáveis, o NTP atinge rotineiramente uma precisão abaixo de 100 microssegundos.
De onde vem realmente a hora
Na base da pirâmide de cronometragem estão os laboratórios nacionais de metrologia do mundo. O National Institute of Standards and Technology (NIST) em Boulder, Colorado, opera um conjunto de relógios de fonte de césio — dispositivos que lançam nuvens de átomos de césio para cima através de uma cavidade de micro-ondas e medem as transições de estado quântico à medida que caem de volta. A frequência de oscilação do césio-133, exatamente 9 192 631 770 ciclos por segundo, define o segundo do SI desde 1967.
O Physikalisch-Technische Bundesanstalt (PTB) da Alemanha em Braunschweig, o National Physical Laboratory (NPL) do Reino Unido em Teddington, o LNE-SYRTE de França em Paris e cerca de 80 outros laboratórios nacionais em todo o mundo mantêm os seus próprios relógios atómicos. Cada laboratório produz a sua própria realização do segundo, e estas realizações não concordam perfeitamente. Um relógio de césio em Boulder pode diferir de um em Braunschweig por alguns nanossegundos ao longo de um mês.
É aqui que entra o Bureau International des Poids et Mesures (BIPM) em Paris. O BIPM não mantém um relógio. Em vez disso, recolhe dados de temporização de cerca de 450 relógios atómicos em aproximadamente 80 laboratórios em todo o mundo, aplica um algoritmo de média ponderada e publica uma escala de tempo documental chamada Tempo Universal Coordenado, ou UTC. Este processo de cálculo da média acontece após o facto — o BIPM publica correções semanas depois — pelo que o UTC não está disponível em tempo real. Aquilo com que efetivamente se sincroniza via NTP é a aproximação em tempo real de cada laboratório ao UTC, chamada UTC(NIST), UTC(PTB) ou similar. O papel do BIPM é impedir que todas estas aproximações divirjam entre si.
Depois há os satélites GPS. Cada um dos 31 satélites GPS operacionais transporta múltiplos relógios atómicos — de rubídio e de césio — e transmite sinais horários como parte da sua mensagem de navegação. O tempo GPS não é idêntico ao UTC (divergiu em 1980 e não inclui segundos intercalares), mas a diferença é transmitida na mensagem de navegação, pelo que um recetor GPS pode calcular o UTC. Muitos servidores NTP de Estrato 1 usam o GPS como relógio de referência porque um recetor de 50 dólares e uma antena no telhado conseguem fornecer tempo com precisão de 10 nanossegundos, muito mais barato do que comprar um relógio de césio.
O NTP em grande escala
O NTP Pool Project, alojado em pool.ntp.org, é uma das grandes histórias de infraestrutura voluntária da internet. Iniciado em 2003 por Adrian von Bidder, o pool é um conjunto de milhares de servidores NTP operados por voluntários e distribuídos pelo globo. Quando o seu computador está configurado para usar pool.ntp.org, o sistema DNS devolve um conjunto diferente de endereços de servidores a cada vez, distribuindo a carga pelo pool voluntário. Em 2025, o pool serve cerca de 50 milhões de clientes por segundo e trata das necessidades de sincronização horária da maioria das distribuições Linux, de muitos dispositivos IoT e de inúmeros outros sistemas que usam pool.ntp.org como fonte NTP predefinida.
As grandes empresas de tecnologia operam as suas próprias infraestruturas de tempo em enorme escala. A Google opera uma frota de servidores sincronizados com relógios atómicos e recetores GPS nos seus centros de dados. O serviço de tempo da Google está disponível publicamente em time.google.com e implementa uma particularidade interessante: em vez de inserir segundos intercalares de forma abrupta, a Google usa uma técnica chamada "leap smear", distribuindo gradualmente o segundo extra ao longo de uma janela de 24 horas. Isto evita as falhas de software que inserções abruptas de segundos intercalares historicamente causaram, mas significa que durante um evento de leap smear, o tempo da Google discorda deliberadamente do UTC até meio segundo.
A Meta (anteriormente Facebook) opera um serviço de tempo interno semelhante e publicou artigos detalhados de engenharia sobre a sua utilização do Precision Time Protocol (PTP) nos seus centros de dados, assente em relógios mestres disciplinados por GPS. A Amazon opera o Amazon Time Sync Service, disponível para todas as instâncias AWS. A Cloudflare opera um serviço NTP público e tem sido defensora do Roughtime, um protocolo desenvolvido pela Google que acrescenta prova criptográfica às respostas de tempo para que os clientes possam verificar que não estão a ser enganados.
Quando o NTP falha
A 30 de junho de 2012, um segundo intercalar foi inserido no UTC à meia-noite. O segundo extra — 23:59:60 — fez com que o código de cronometragem do kernel Linux entrasse num bug que descontrolou o temporizador de alta resolução do sistema. Processos que dependiam destes temporizadores passaram subitamente a consumir 100 por cento dos seus núcleos de CPU, girando em ciclos apertados. O Reddit caiu. A Mozilla caiu. O Gawker caiu. O sistema de check-in da Qantas Airlines falhou, deixando passageiros retidos. O StumbleUpon, o FourSquare, o Yelp e o LinkedIn também reportaram perturbações. A solução era reiniciar os sistemas afetados ou acertar manualmente o relógio, o que parecia irónico dado que o problema começou com uma tentativa de manter os relógios precisos.
A falsificação de GPS representa uma ameaça mais insidiosa. Como os sinais GPS chegam com potência extremamente baixa — cerca de 10^-16 watts à superfície da Terra — podem ser dominados por um transmissor relativamente barato que emita sinais falsos. Um sinal GPS falsificado pode alimentar tempo errado a qualquer servidor NTP de Estrato 1 que use GPS como referência. Em 2013, investigadores da Universidade do Texas em Austin demonstraram que conseguiam falsificar um recetor GPS a um quilómetro de distância usando equipamento que custava cerca de 3000 dólares, deslocando gradualmente a hora reportada sem acionar quaisquer alarmes.
Em 2016, a Cloudflare sofreu um incidente amplamente noticiado em que alguns dos seus servidores devolveram brevemente datas de 2026 ou 1970 aos clientes devido a um bug no tratamento do NTP. Falhas mais subtis acontecem constantemente. Servidores NTP mal configurados que se anunciam como Estrato 1 quando na verdade estão em funcionamento livre causam imprecisão em cascata em qualquer cliente que confie neles. Firewalls que bloqueiam tráfego NTP deixam as máquinas a derivar silenciosamente. Máquinas virtuais em ambientes de nuvem são notórias pela deriva dos relógios porque o escalonamento de CPU do hipervisor introduz atrasos imprevisíveis na cronometragem do sistema operativo convidado.
Estes modos de falha explicam por que a autenticação NTP é importante. O protocolo NTP original não tinha forma de um cliente verificar se uma resposta de tempo vinha realmente do servidor que alegava ser. Um atacante no caminho de rede podia alterar respostas de tempo em trânsito. O Network Time Security (NTS), especificado no RFC 8915 e publicado em 2020, acrescenta autenticação baseada em TLS ao NTP. A adoção tem sido lenta — a maior parte do tráfego NTP na internet continua sem autenticação — mas grandes fornecedores como a Cloudflare já suportam NTS, e a tendência é para a adoção universal.
Tempo GPS vs. NTP
O seu smartphone quase de certeza não usa o NTP como fonte de tempo primária. Em vez disso, usa a hora transmitida pela rede celular, que por sua vez é derivada do GPS. Os satélites GPS transportam relógios atómicos a bordo e transmitem a hora atual como parte de cada sinal de navegação. O recetor no seu telemóvel, além de calcular a sua latitude e longitude, extrai a hora dos sinais do satélite e usa-a para acertar o relógio do telefone.
O tempo GPS e o UTC não são a mesma coisa. Quando o GPS foi lançado em 1980, estava sincronizado com o UTC. Mas o UTC insere ocasionalmente segundos intercalares para se manter alinhado com a rotação cada vez mais lenta da Terra, e o GPS não o faz. Em 2025, o tempo GPS está 18 segundos adiantado em relação ao UTC. A mensagem de navegação GPS inclui a diferença atual, pelo que os recetores podem converter entre os dois, mas a distinção é importante para engenheiros que trabalham com dados GPS brutos.
Os smartphones modernos usam uma abordagem híbrida. O sinal de tempo GPS ou celular fornece uma sincronização grosseira, tipicamente com precisão de algumas dezenas de nanossegundos. Mas a receção GPS é intermitente — o telefone pode estar dentro de casa, no metro ou em modo de avião. O NTP preenche as lacunas. A Apple, a Google e a maioria dos fabricantes de telemóveis configuram os seus dispositivos para também consultarem servidores NTP (a Apple usa time.apple.com, os dispositivos Android usam time.android.com) para manter a precisão quando os sinais de satélite não estão disponíveis. Os dois sistemas complementam-se: o GPS fornece precisão absoluta quando o céu está visível, e o NTP fornece correção contínua quando não está.
O problema do ano 2038
O tempo Unix, o sistema usado por praticamente todos os servidores, telemóveis e dispositivos embebidos do planeta, conta o número de segundos decorridos desde a meia-noite UTC de 1 de janeiro de 1970. Durante décadas, esta contagem foi armazenada como um número inteiro de 32 bits com sinal, que pode conter valores até 2 147 483 647. Esse número de segundos após a época Unix corresponde às 03:14:07 UTC de 19 de janeiro de 2038. Um segundo depois, o contador transborda, e os sistemas que ainda usem carimbos temporais de 32 bits interpretarão a data como 13 de dezembro de 1901.
O NTP tem a sua própria versão deste problema. O formato de carimbo temporal do NTP usa um valor de 64 bits: 32 bits para os segundos desde 1 de janeiro de 1900 e 32 bits para a fração de segundo. O campo dos segundos recomeça a 7 de fevereiro de 2036 — dois anos antes do prazo do Y2038 do Unix. O NTPv4, a versão atual do protocolo, lida com isto definindo "números de era" que desambiguam a qual ciclo de 136 anos um carimbo temporal pertence, mas ambos os extremos da comunicação devem implementar corretamente a lógica de era.
A maioria dos servidores, computadores de secretária e telemóveis modernos já usa sistemas operativos de 64 bits com representações de tempo de 64 bits, que não transbordarão durante aproximadamente 292 mil milhões de anos. O perigo reside na longa cauda de sistemas embebidos: controladores industriais, sistemas de automação de edifícios, dispositivos médicos, ECUs automóveis e os milhares de milhões de dispositivos IoT que executam firmware de 32 bits que pode nunca receber uma atualização. Muitos destes dispositivos usam NTP para acertar os seus relógios. O trabalho silencioso e pouco glamoroso de identificar e atualizar sistemas vulneráveis está em curso, mas ao contrário do Y2K, não existe um prazo único que concentre a atenção pública. A transição do NTP em 2036 e a transição do Unix em 2038 chegarão independentemente de todos os termóstatos e controladores de semáforos embebidos terem sido corrigidos ou não.
Quarenta anos e a contar
O NTP sincroniza os relógios da internet há quatro décadas. Sobreviveu à transição da ARPANET para a internet comercial, do acesso por modem à fibra ótica, dos mainframes aos smartphones. David Mills concebeu um protocolo tão robusto e tão adequado à sua tarefa que sobreviveu a quase tudo para o qual foi originalmente construído. As máquinas mudaram, as redes mudaram, as velocidades aumentaram por um fator de um milhão, e o NTP continua a funcionar.
Mas as exigências de cronometragem estão a crescer. As redes celulares 5G requerem sincronização com precisão de dezenas de nanossegundos entre estações base. Os veículos autónomos precisam de temporização precisa para fundir dados de lidar, radar e câmaras. As empresas de negociação de alta frequência medem a latência em nanossegundos e pagam milhões por alguns microssegundos de vantagem. Para estas aplicações, a precisão de milissegundos do NTP não é suficiente. O Precision Time Protocol (PTP), definido na norma IEEE 1588, consegue atingir sincronização ao nível do nanossegundo em hardware de rede dedicado. O PTP já é padrão em telecomunicações, radiodifusão e redes de negociação financeira.
No entanto, para os milhares de milhões de dispositivos quotidianos — o portátil na sua secretária, o servidor num centro de dados, o termóstato na sua parede, a câmara na sua campainha — o NTP continua a ser a espinha dorsal invisível do tempo sincronizado. É um daqueles protocolos fundamentais da internet que funciona tão bem que quase ninguém pensa nele. Sempre que olha para o relógio do seu telemóvel e ele concorda com o relógio do seu portátil, que concorda com o relógio na parede do aeroporto, que concorda com a hora de partida no painel de voos, está a ver o trabalho de um protocolo concebido por um professor em Delaware há quatro décadas, a tiquetaquear sem reclamar, mantendo o mundo sincronizado.