NTP

NTP é o protocolo tradicional para sincronizar relógios de computadores e dispositivos em redes IP. Ele não envia apenas “a hora”. O cliente e o servidor trocam timestamps que permitem estimar o offset entre relógios e o atraso de ida e volta. O algoritmo filtra amostras, seleciona fontes e disciplina o relógio gradualmente. NTPv4 é especificado na RFC 5905, publicada em 2010. Opera normalmente em UDP 123. A mensagem básica contém indicadores, version, mode, stratum, poll, precision, root delay, root dispersion, reference ID e timestamps de referência, origem, recepção e transmissão. O cliente envia um timestamp de origem; o servidor devolve. Com quatro instantes t1, t2, t3 e t4, calcula atraso e offset. O relógio não deve saltar para trás indiscriminadamente porque aplicações podem falhar. Daemons como chrony, ntpd, systemd-timesyncd e Windows Time escolhem step no início e slew depois. O comportamento varia. Stratum representa distância lógica da fonte, não qualidade absoluta. Uma referência como GNSS ou relógio atômico alimenta um servidor stratum 1; ele anuncia stratum 1. Clientes podem ser stratum 2. Stratum 16 significa não sincronizado. Um servidor stratum 1 mal configurado pode ser ruim. O cliente avalia dispersão, jitter, reachability e múltiplas fontes. Pools NTP distribuem. Em casa inteligente, tempo correto é essencial para certificados TLS, tokens JWT, logs de fechadura, gravações de câmera, tarifas, energia, cron, sunrise/sunset e correlação de eventos. Um dispositivo com relógio de 1970 pode rejeitar HTTPS porque o certificado parece futuro. Um sensor com deriva de 20 ppm erra cerca de 1,7 s por dia. NTP corrige. A rede deve permitir. Dispositivos IoT muitas vezes usam SNTP, uma forma simplificada definida em RFC 4330 e atualizações, que consulta servidor sem algoritmo completo. Para muitos dispositivos, é suficiente, mas pode reagir pior a fontes falhas. O fuso horário não vem do NTP. O protocolo fornece UTC-like time. A aplicação usa banco de fusos, como IANA tzdata, para America/Sao_Paulo e regras. Horário de verão muda por legislação e precisa de atualização. Não configurar UTC-3 fixo quando regra pode mudar. NTP lida com leap indicator e segundos intercalares conforme sua escala. Implementações precisam. A segurança do NTP clássico é limitada. Pacotes podem ser falsificados por atacante no caminho ou LAN. Autokey foi problemático e obsoleto. Network Time Security, RFC 8915, usa TLS para estabelecer cookies e autenticação eficiente de pacotes NTP, reduzindo spoofing. Suporte cresce em chrony e servidores. Dispositivos simples podem não ter. Nesse caso, usar servidor local confiável, firewall e múltiplas fontes. Um roteador pode servir NTP à IoT e sincronizar externamente. Não permitir que qualquer dispositivo consulte Internet diretamente. Isso reduz DNS e exposição. NTP foi usado em amplificação DDoS com comandos antigos como monlist. Servidores públicos devem ser atualizados, restringir consultas e não oferecer funções administrativas. Cliente atrás de firewall é normal. Porta 123 de entrada da WAN deve ser bloqueada, exceto servidor planejado. Kiss-o'-Death limita clientes abusivos. O polling varia em potências de dois segundos. O daemon ajusta de 64 s a 1024 s ou mais conforme estabilidade. Consultar a cada segundo é desnecessário. Para precisão sub-milissegundo em LAN industrial, PTP IEEE 1588 pode ser melhor, com hardware timestamping. NTP atende milissegundos a dezenas de milissegundos na Internet e melhor em LAN, dependendo. Wi‑Fi adiciona jitter. Não usar NTP para medir duração; usar relógio monotônico. O relógio de parede pode ajustar. Automação de timeout usa monotonic.