Quando a maioria das pessoas aprende sobre o Network Time Protocol (NTP), imagina algo simples:
Meu computador pergunta a um servidor de horário qual é a hora atual, recebe uma resposta e atualiza seu relógio.
Infelizmente, essa abordagem produziria relógios imprecisos.
O Network Time Protocol (NTP) é um protocolo de rede que sincroniza os relógios de computadores e dispositivos de rede em redes IP. Em vez de simplesmente solicitar a hora atual, o NTP estima o atraso de rede, compensa a deriva do relógio e ajusta continuamente o relógio do sistema para manter os computadores sincronizados com a maior precisão possível.
O verdadeiro desafio não é obter a hora. É determinar quanto a latência da rede afetou a resposta. Resolver esse problema é o que torna o NTP um dos protocolos mais elegantes e amplamente utilizados em sistemas distribuídos.
Neste guia abrangente, você aprenderá como o NTP funciona, por que a hora precisa é importante, como o NTP calcula o offset do relógio e o atraso de rede usando quatro timestamps.
Além disso, você também aprenderá por que o NTP consulta vários servidores de horário e como ele mantém os relógios sincronizados apesar de hardware imperfeito e redes imprevisíveis.
Primeiro, começaremos com o que exatamente é o NTP.
O que é o Network Time Protocol (NTP)?
O Network Time Protocol (NTP) é um protocolo de rede usado para sincronizar os relógios de computadores e outros dispositivos em redes IP. Ele estima o atraso de rede, compensa a deriva do relógio e ajusta continuamente o relógio do sistema para que os dispositivos participantes mantenham uma noção comum de tempo.
Em vez de simplesmente perguntar a um servidor pela hora atual, o NTP troca múltiplos timestamps, filtra medições imprecisas e disciplina gradualmente o relógio local. Isso permite que computadores na Internet permaneçam sincronizados dentro de milissegundos em condições normais.
Por que a Hora Precisa é Importante
Os computadores modernos dependem de hora precisa para muito mais do que exibir a data e hora corretas. Quase todo sistema distribuído assume que as máquinas participantes têm relógios razoavelmente sincronizados.
Mesmo uma diferença de alguns segundos pode causar falhas de autenticação, ordenação incorreta de logs, tarefas agendadas com falha ou dados inconsistentes entre servidores.
A hora precisa é essencial para muitas tecnologias do dia a dia, incluindo:
- Segurança web: Certificados HTTPS e TLS têm períodos de validade. Se o relógio do sistema estiver significativamente incorreto, navegadores e aplicativos podem rejeitar certificados que seriam válidos.
- Registro de logs: Administradores usam timestamps para solucionar problemas e investigar incidentes de segurança. Relógios não sincronizados dificultam reconstruir a sequência correta de eventos em vários sistemas.
- Sistemas distribuídos: Bancos de dados, filas de mensagens e aplicações distribuídas frequentemente dependem de timestamps para coordenar operações, detectar conflitos e ordenar eventos.
- Tarefas agendadas: Cron jobs, backups automatizados, atualizações de software e janelas de manutenção dependem de hora precisa do sistema.
- Protocolos de autenticação: Mecanismos de segurança como Kerberos usam timestamps para evitar ataques de repetição. Grandes diferenças de horário podem fazer com que solicitações de autenticação falhem.
- Sistemas financeiros: Bancos, bolsas de valores e processadores de pagamento exigem timestamps precisos para auditoria, conformidade regulatória e ordenação de transações.
- Monitoramento e observabilidade: Plataformas de monitoramento correlacionam métricas, logs e traces coletados de muitas máquinas. Timestamps consistentes permitem identificar a causa raiz de interrupções.
Embora a sincronização perfeita seja impossível em uma rede, o NTP mantém os relógios suficientemente próximos para a maioria das aplicações, estimando continuamente o atraso de rede, corrigindo a deriva do relógio e ajustando gradualmente o relógio do sistema local.
Principal conclusão: Hora precisa é um requisito fundamental para computação distribuída confiável e segura. O NTP existe porque manter relógios sincronizados em redes imperfeitas é muito mais difícil do que simplesmente perguntar a outro computador pela hora atual.
O NTP Usa Relógios Atômicos?
Não diretamente.
A maioria dos computadores nunca se comunica com um relógio atômico. Em vez disso, o tempo é distribuído através de uma hierarquia.
Atomic clock / GPS reference
│
▼
Stratum 1 servers
│
▼
Stratum 2 servers
│
▼
Stratum 3 servers
│
▼
Your Linux system
Um servidor Stratum 1 está conectado a um relógio de referência autoritativo, como um receptor GPS ou outra fonte de tempo de precisão. Seu computador normalmente sincroniza com Stratum 2 ou Stratum 3 servers, que herdam seu tempo de servidores mais altos na hierarquia.
Principal conclusão: Seu computador não precisa de um relógio atômico. Ele só precisa de uma cadeia confiável que leve a um.
Clock Skew vs. Clock Drift
Esses dois termos são frequentemente confundidos.
Clock skew é a diferença entre dois relógios em um momento específico.
Por exemplo:
Computer A: 10:00:05
Computer B: 10:00:00
Clock skew = 5 seconds
Clock drift descreve a rapidez com que um relógio ganha ou perde tempo porque seu oscilador de hardware é imperfeito.
Mesmo osciladores de quartzo de alta qualidade derivam alguns partes por milhão, fazendo com que os relógios divirjam lentamente se não forem sincronizados.
Por que Simplesmente Perguntar pela Hora Não Funciona
Imagine que seu computador envia esta solicitação:
"Que horas são?"
O servidor responde:
"14:30:00"
Mas quando a resposta chega ao seu computador:
- O atraso de rede foi de 2 ms?
- 20 ms?
- 200 ms?
Sem saber esse atraso, o timestamp sozinho é insuficiente.
Este é o problema fundamental de sincronização em sistemas distribuídos.
Como o NTP Estima o Atraso de Rede
Em vez de trocar um único timestamp, o NTP troca quatro.
Client Server
t1 ---------------------->
receives at t2
replies at t3
<----------------------- t4
Onde:
- t1 = cliente envia solicitação
- t2 = servidor recebe solicitação
- t3 = servidor envia resposta
- t4 = cliente recebe resposta
Usando esses quatro timestamps, o cliente estima dois valores chave:
Atraso de ida e volta (round-trip delay)
δ = (t4 − t1) − (t3 − t2)
Offset do relógio
θ = ((t2 − t1) + (t3 − t4)) / 2
Essas equações permitem que o cliente estime tanto o atraso de comunicação quanto o quanto seu relógio difere do servidor.
Como o NTP Seleciona o Melhor Servidor de Horário
Um dos maiores equívocos sobre o Network Time Protocol (NTP) é que ele simplesmente contata o servidor mais próximo ou de menor Stratum e confia no horário que ele informa.
Na realidade, o NTP é muito mais cauteloso.
Redes de computadores são inerentemente não confiáveis. Pacotes podem ser atrasados por congestionamento, servidores podem ser mal configurados, relógios de hardware podem derivar, e mesmo servidores de horário altamente precisos podem fornecer medições ruins temporariamente devido a condições de rede.
Para alcançar sincronização confiável, o NTP avalia múltiplas fontes de horário e determina continuamente qual é a mais confiável.
Passo 1: Consultar Múltiplos Servidores de Horário
Em vez de confiar em um único servidor, um cliente NTP é tipicamente configurado para se comunicar com vários servidores de horário independentes.
Cada servidor retorna sua hora atual, permitindo que o cliente compare múltiplas medições em vez de confiar cegamente em uma única fonte.
Server A
\
Server B -----> Your Computer
/
Server C
Usar múltiplos servidores melhora tanto a precisão quanto a tolerância a falhas. Se um servidor ficar indisponível ou começar a reportar horário incorreto, o cliente pode continuar sincronizando com os servidores restantes.
Passo 2: Medir Atraso de Rede e Offset do Relógio
Para cada servidor que contata, o NTP calcula dois valores importantes:
- Atraso de rede: o tempo estimado necessário para as mensagens viajarem entre o cliente e o servidor.
- Offset do relógio: a diferença estimada entre o relógio do cliente e o relógio do servidor.
Essas medições ajudam o cliente a determinar não apenas que horas o servidor reporta, mas também quão confiável é essa medição.
Um servidor com um atraso de rede muito grande ou altamente variável é geralmente menos adequado para sincronização do que um com uma conexão estável e de baixa latência.
Passo 3: Rejeitar Fontes de Horário Não Confiáveis
Nem todo servidor deve ser confiável.
Um servidor pode reportar horário incorreto devido a:
- Falhas de hardware
- Erros de configuração
- Congestionamento excessivo de rede
- Problemas temporários de rede
- Perda de sincronização com sua própria fonte de horário upstream
Suponha que um cliente NTP receba os seguintes offsets de relógio:
- Servidor A: +2 ms
- Servidor B: +3 ms
- Servidor C: +1 ms
- Servidor D: +500 ms
Como três servidores concordam de perto enquanto um difere significativamente, o NTP identifica o Servidor D como um outlier e o exclui do processo de sincronização.
Esse processo de filtragem ajuda a evitar que um único servidor defeituoso faça o cliente definir um horário de sistema incorreto.
Passo 4: Selecionar a Melhor Fonte de Sincronização
Após filtrar medições não confiáveis, o NTP seleciona o servidor com maior probabilidade de fornecer horário preciso e estável.
A decisão é baseada em vários fatores, incluindo:
- Baixo atraso de rede
- Medições consistentes ao longo do tempo
- Comportamento estável do relógio
- Nível de Stratum
- Qualidade geral da sincronização
Um equívoco comum é que um servidor Stratum 1 é sempre a melhor escolha.
Na prática, isso não é necessariamente verdade.
Por exemplo, um servidor Stratum 2 próximo, conectado por uma rede rápida e de baixa latência, pode fornecer sincronização mais precisa do que um servidor Stratum 1 distante, alcançado por uma conexão de Internet lenta ou congestionada.
O NTP, portanto, avalia a qualidade geral de cada fonte de sincronização em vez de simplesmente escolher o servidor com o menor número de Stratum.
Por que Isso Importa
Sem esses mecanismos de seleção e filtragem, um único servidor defeituoso poderia fazer milhares de computadores adotarem um horário de sistema incorreto.
Ao comparar múltiplas fontes de horário independentes, rejeitar medições inconsistentes e reavaliar continuamente a qualidade da sincronização, o NTP permanece resiliente mesmo quando servidores individuais ou caminhos de rede se tornam não confiáveis.
Principal conclusão: O NTP não simplesmente escolhe o servidor mais próximo ou de menor Stratum. Ele compara continuamente múltiplas fontes de horário, filtra medições não confiáveis e sincroniza com o servidor que fornece o horário mais preciso e estável sob as condições de rede atuais.
Por que o NTP Geralmente Não Pula o Relógio
Suponha que seu computador descubra que está cinco segundos adiantado.
Uma implementação ingênua moveria imediatamente o relógio para trás.
Infelizmente, isso pode causar problemas para:
- bancos de dados
- tarefas agendadas
- arquivos de log
- certificados TLS
- aplicações distribuídas
Em vez disso, o NTP geralmente ajusta gradualmente (slew) o relógio.
Em vez de mudar o horário exibido instantaneamente, ele acelera ou desacelera ligeiramente o relógio do sistema até convergir para o horário correto.
Erros grandes ainda podem exigir um salto (step), mas a operação normal depende de ajuste gradual através de algoritmos de disciplina de relógio.
Quão Preciso é o NTP?
Em uma rede local (LAN) estável, o NTP pode frequentemente sincronizar relógios dentro de alguns milissegundos ou melhor.
Pela Internet pública, a precisão é tipicamente de dezenas de milissegundos, dependendo da latência da rede, congestionamento, qualidade do servidor e hardware.
O NTP Pode Funcionar Sem a Internet?
Sim. O NTP não requer uma conexão com a Internet.
Organizações frequentemente implantam sua própria infraestrutura NTP interna para confiabilidade e segurança. Um servidor NTP interno pode sincronizar com:
- Um receptor GPS
- Um relógio atômico de referência
- Outro servidor NTP interno confiável
Redes isoladas (air-gapped), sistemas de controle industrial, ambientes militares e laboratórios de pesquisa comumente usam servidores NTP locais para manter horário preciso sem acesso à Internet.
Por que Sistemas Distribuídos Tratam a Sincronização de Horário como um Problema Difícil
À primeira vista, uma arquitetura mestre-escravo parece suficiente.
Master
/ | \
A B C
No entanto, a realidade introduz várias complicações:
- cada cliente experimenta latência de rede diferente
- a latência de rede muda constantemente
- os relógios derivam continuamente
- servidores podem falhar
- alguns servidores podem reportar horário incorreto
O NTP aborda esses problemas combinando estimativa de atraso, filtragem estatística, múltiplas fontes de horário e disciplina contínua do relógio, em vez de confiar cegamente em um único mestre.
É por isso que livros didáticos dedicam capítulos inteiros à sincronização de relógios. O protocolo está resolvendo muito mais do que "perguntar a um servidor pela hora".
Por que o NTP Não Faz Todos os Computadores Mostrarem Exatamente a Mesma Hora?
Sincronização perfeita em uma rede é impossível.
Cada pacote NTP experimenta atrasos ligeiramente diferentes devido a:
- Congestionamento de rede
- Filas de roteadores
- Tempos de transmissão variáveis
- Atrasos de processamento
- Deriva do relógio dentro de cada computador
O NTP minimiza esses erros usando filtragem estatística e ajustes contínuos do relógio, mas não pode eliminar a incerteza completamente. Em vez de alcançar sincronização perfeita, seu objetivo é manter os relógios suficientemente próximos para operação confiável.
Equívocos Comuns Sobre o NTP
Perguntas Frequentes (FAQ)
P: O que é o Network Time Protocol (NTP)?
R: O Network Time Protocol (NTP) é um protocolo de rede que sincroniza os relógios de computadores e dispositivos de rede em redes IP. Ele estima o atraso de rede, compensa a deriva do relógio e ajusta continuamente o relógio local para que os sistemas mantenham uma noção comum de tempo.
P: Como o NTP sincroniza os relógios dos computadores?
R: O NTP troca quatro timestamps entre um cliente e um servidor de horário. Usando esses timestamps, ele estima o atraso de rede de ida e volta e a diferença entre os relógios do cliente e do servidor (offset do relógio). O cliente então ajusta gradualmente seu relógio para minimizar o erro.
P: O Linux usa NTP?
R: Sim. A maioria das distribuições Linux modernas sincroniza o horário usando software compatível com NTP, como chronyd (Chrony) ou systemd-timesyncd. Ambos mantêm automaticamente o horário preciso do sistema sincronizando com servidores NTP confiáveis, embora o Chrony geralmente ofereça melhor desempenho em sistemas com conectividade de rede intermitente ou deriva de relógio variável.
P: O NTP usa relógios atômicos?
R: A maioria dos computadores nunca se comunica diretamente com um relógio atômico. Em vez disso, eles sincronizam com servidores NTP que, em última análise, rastreiam seu tempo até relógios de referência altamente precisos, como relógios atômicos ou relógios disciplinados por GPS. Essa hierarquia permite que o horário preciso seja distribuído eficientemente pela Internet.
P: Qual é a diferença entre clock skew e clock drift?
R: Clock skew é a diferença entre as leituras atuais de dois relógios em um momento específico.
Clock drift descreve a rapidez com que um relógio ganha ou perde tempo porque seu oscilador de hardware não é perfeitamente preciso. A deriva faz com que o skew aumente ao longo do tempo se os relógios não forem periodicamente sincronizados.
P: Por que o NTP usa quatro timestamps em vez de um?
R: Um único timestamp não pode distinguir entre a hora atual e o atraso de rede necessário para entregá-lo. Ao trocar quatro timestamps, o NTP estima tanto o atraso de comunicação quanto o offset do relógio, permitindo sincronização muito mais precisa.
P: Quais são os quatro timestamps do NTP?
R: Os quatro timestamps são:
- T1: Cliente envia a solicitação.
- T2: Servidor recebe a solicitação.
- T3: Servidor envia a resposta.
- T4: Cliente recebe a resposta.
Esses timestamps permitem que o cliente calcule o atraso de rede e o offset do relógio.
P: Por que o NTP não altera imediatamente o relógio do sistema?
R: Mover repentinamente o relógio do sistema para trás ou para frente pode interromper aplicações, bancos de dados, tarefas agendadas e arquivos de log. Em vez disso, o NTP geralmente ajusta gradualmente (slew) o relógio, alterando ligeiramente sua velocidade até que corresponda ao horário correto. Erros grandes ainda podem exigir um salto (step) do relógio.
P: Por que o NTP consulta múltiplos servidores de horário?
R: Atrasos de rede, falhas de hardware e configurações incorretas de servidor podem produzir medições de horário imprecisas. O NTP compara respostas de vários servidores, filtra resultados não confiáveis e seleciona a fonte de horário mais confiável para melhorar a precisão e a resiliência.
P: O que é um servidor Stratum?
R: Um Stratum indica a distância de um servidor de um relógio de referência autoritativo:
- Stratum 0: Relógios de referência como relógios atômicos ou receptores GPS (não acessíveis diretamente pela rede).
- Stratum 1: Servidores diretamente conectados a relógios de referência Stratum 0.
- Stratum 2: Servidores sincronizados com Stratum 1 servers.
- Stratum 3 e abaixo: Servidores sincronizados com servidores de stratum superior.
Um stratum mais baixo geralmente indica menos saltos de sincronização, mas não garante automaticamente melhor precisão. As condições de rede e a qualidade do servidor também desempenham papéis importantes.
P: Qual é a diferença entre NTP e PTP?
R: O NTP é projetado para sincronização de horário de uso geral em redes IP e é adequado para a maioria dos servidores, desktops e dispositivos de rede.
O Precision Time Protocol (PTP) é projetado para ambientes que exigem precisão muito maior, frequentemente na faixa de microssegundos ou nanossegundos, como telecomunicações, automação industrial, pesquisa científica e negociação de alta frequência. O PTP geralmente requer timestamping por hardware e suporte de rede especializado.
P: O que acontece se o NTP parar de funcionar?
R: Se o NTP estiver indisponível, o relógio do sistema continua funcionando usando seu oscilador de hardware local. Como nenhum oscilador é perfeitamente preciso, o relógio gradualmente se desvia do horário correto.
Com o tempo, isso pode levar a:
- Falhas de autenticação (como Kerberos)
- Erros de validação de certificado HTTPS
- Timestamps incorretos em arquivos de log
- Tarefas agendadas perdidas
- Problemas ao correlacionar eventos entre vários servidores
- Inconsistências de dados em sistemas distribuídos
Quanto mais tempo a sincronização estiver indisponível, maior o erro do relógio tipicamente se torna.
P: O NTP leva em conta a latência da rede?
R: Sim. Estimar a latência da rede é uma das funções primárias do NTP.
Em vez de confiar em um único timestamp, o NTP troca quatro timestamps entre o cliente e o servidor. Esses timestamps permitem que o cliente estime tanto o atraso de rede de ida e volta quanto a diferença entre seu próprio relógio e o relógio do servidor.
Como a latência da rede muda continuamente, o NTP realiza esse processo repetidamente e refina continuamente sua estimativa, em vez de assumir que o atraso é constante.
P: O NTP usa UDP ou TCP?
R: O NTP usa o User Datagram Protocol (UDP) em vez de TCP.
O UDP é adequado para sincronização de horário porque tem menor overhead e evita retransmissões que poderiam introduzir atrasos adicionais e imprevisíveis. Como o NTP troca periodicamente pacotes pequenos, a perda ocasional de pacotes tem pouco impacto, pois o próximo ciclo de sincronização atualiza rapidamente o relógio.
P: Qual porta de rede o NTP usa?
R: O NTP usa a porta UDP 123 para comunicação tanto do cliente quanto do servidor.
Ao configurar firewalls ou políticas de segurança de rede, a porta UDP 123 deve ser permitida entre clientes NTP e seus servidores de horário. Bloquear esta porta impede que os sistemas sincronizem seus relógios.
P: Qual é a diferença entre Chrony e ntpd?
R: Tanto o Chrony quanto o ntpd implementam o Network Time Protocol, mas são otimizados para ambientes diferentes.
Chrony geralmente fornece:
- Sincronização mais rápida após a inicialização
- Melhor desempenho em laptops e máquinas virtuais
- Melhor tratamento de conexões de rede intermitentes
- Melhor compensação para sistemas com deriva de relógio instável
ntpd é o daemon NTP tradicional usado em sistemas Unix e Linux por décadas. Embora ainda seja amplamente suportado, muitas distribuições Linux modernas agora usam Chrony como serviço de sincronização de horário padrão devido ao seu desempenho melhorado em condições do mundo real.
P: Por que o GPS é usado para NTP?
R: Os satélites GPS transmitem continuamente informações de horário altamente precisas derivadas de relógios atômicos a bordo.
Um receptor GPS conectado a um servidor NTP pode usar esses sinais como um relógio de referência altamente preciso. Isso permite que o servidor opere como um servidor de horário Stratum 1 e distribua horário preciso para outros sistemas na rede.
Embora muitas pessoas associem o GPS à navegação, a distribuição precisa de horário é uma de suas funções primárias.
P: O que é um segundo bissexto (leap second)?
R: Um segundo bissexto é um ajuste de um segundo ocasionalmente adicionado ao Tempo Universal Coordenado (UTC) para mantê-lo alinhado com a rotação ligeiramente irregular da Terra.
Como a rotação da Terra não é perfeitamente constante, o UTC ocasionalmente requer ajuste para permanecer sincronizado com o tempo astronômico.
O NTP inclui mecanismos para notificar os clientes sobre um próximo segundo bissexto para que eles possam lidar com o ajuste corretamente.
Algumas organizações também usam técnicas como leap smearing, que espalha gradualmente o ajuste por um período mais longo para evitar saltos repentinos de um segundo que poderiam interromper aplicações distribuídas.
Conclusão
Uma das maiores lições do estudo de sistemas distribuídos é que o tempo é surpreendentemente difícil.
O NTP é bem-sucedido não porque tem acesso a relógios atômicos, mas porque estima cuidadosamente a incerteza, filtra medições não confiáveis e corrige continuamente imperfeições de hardware.
Essa combinação permite que milhões de computadores mantenham relógios notavelmente precisos apesar de redes não confiáveis e hardware imperfeito.
- Como Configurar Sincronização de Horário no Ubuntu
- Como Definir Data e Hora pela Linha de Comando no Linux
- Monitore Latência de Rede no Linux Usando Ping, Mtr e Smokeping
Recurso:




