Resumo

  • O NTP estima offset e atraso de ida e volta com quatro timestamps, filtra observações repetidas e disciplina o relógio do cliente; uma resposta isolada nunca basta.
  • Stratum expressa distância até uma referência e evita loops, não precisão ou autoridade. A seleção de falsetickers pode falhar, e muitas fontes podem esconder uma dependência comum.
  • O NTS autentica a troca cliente-servidor, mas não a correção da fonte upstream. Diversidade, permissão, monitoramento e política de ajuste continuam locais.

Quando milhares de relógios responderam errado

O RFC 1129 registrou, em 1989, uma consulta a 94.260 hosts e gateways por três protocolos de tempo. Responderam 20.758. Aproximadamente metade diferia mais de dois minutos da referência do estudo; cerca de dez por cento errava por mais de quatro horas; alguns estavam mais de duas semanas fora.

Não era um censo de toda a Internet, apenas dos respondentes alcançados pelo método. Mesmo assim, o resultado separou duas ideias que pareciam iguais: estar conectado e saber as horas. Um relógio errado pode responder com regularidade e alta resolução.

O NTP não resolveu isso nomeando uma máquina infalível. Criou um modo de comparar depoimentos, carregar a incerteza do caminho e recusar fontes incompatíveis.

Quatro instantes em torno de uma viagem incerta

Em 1981, o DCNET Internet Clock Service já reunia relógios de qualidades diferentes: o RFC 778 descreveu uma referência de rádio WWV na COMSAT e relógios de rede elétrica sujeitos a offset e deriva. Timestamps ICMP marcavam a ida e a volta.

Na notação moderna, o cliente envia em t1, o servidor recebe em t2, transmite em t3 e o cliente recebe em t4. O offset é estimado por [(t2 - t1) + (t3 - t4)] / 2; o atraso de ida e volta por (t4 - t1) - (t3 - t2).

O cálculo não mede separadamente os atrasos unidirecionais. Assimetria de rota aparece como erro de relógio. A precisão do campo numérico não elimina a incerteza do transporte.

Perder um pacote e continuar medindo

O RFC 958 especificou o NTP em setembro de 1985. O RFC 1059 descreveu a versão 1 em 1988, depois de cerca de dois anos de protótipos: várias referências primárias, servidores secundários em uma sub-rede hierárquica e auto-organizada, sem eleição global de um mestre único.

Uma mensagem perdida podia ser abandonada; a próxima medição renovava a evidência. Isso combinava com uma Internet de múltiplos gateways e entrega variável. A versão 1 já filtrava amostras, compensava deriva, removia glitches e ajustava o relógio progressivamente. Os resultados de dezenas de milissegundos citados no documento pertencem àquele ambiente, não a qualquer instalação futura.

Escolha não é adivinhação

Cada associação acumula estimativas de offset, atraso e erro. O filtro favorece amostras úteis, em especial as de menor atraso aparente, para que uma fila momentânea não governe o relógio. Em seguida, a seleção compara intervalos de correção possíveis e descarta como falsetickers os candidatos incompatíveis.

O RFC 1305 refinou filtro e seleção na versão 3. O RFC 5905 descreve, na versão 4, seleção, clustering dos sobreviventes e combinação. O algoritmo da Universidade de Delaware admite um resultado essencial: sem interseção suficiente, a escolha falha. “Não sincronizado” pode ser mais correto que um número fabricado.

Também não há garantia contra correlação. Servidores com nomes e redes distintos podem usar o mesmo receptor, operador ou leap smear. Aritmética de timestamps não descobre toda dependência administrativa.

Stratum mede distância, não nobreza

No NTPv4, stratum 1 associa-se diretamente a um relógio primário; 2 a 15 representam passos seguintes; 16 significa não sincronizado. A cadeia impede que um servidor derive tempo de um descendente e forme um loop.

Um número baixo não é certificado de qualidade. Um stratum 1 congestionado pode ser pior que um stratum 3 estável. O campo não prova propriedade nem mandato. O NTP tem hierarquia e referências primárias, mas também modos cliente-servidor, broadcast e peer simétrico. Não é uma pirâmide soberana nem uma malha sem confiança.

A parte que continua sendo trabalho humano

O RFC 8633 recomenda fontes realmente diversas e monitoramento contínuo. Quatro ou mais ajudam quando suas falhas são independentes. Diferentes endereços podem compartilhar uma referência; misturar leap smear e UTC sem smear cria desacordo intencional perto de um leap second.

Uso exige permissão. Um fabricante que grava um servidor público de terceiros em milhões de dispositivos pode impor tráfego e defesa por muitos anos. A exposição UDP e o histórico de amplificação também exigem limites e vigilância. Disponibilidade pública não é contrato ilimitado.

Autenticar o mensageiro não autentica o tempo

O RFC 8915 padronizou em 2020 o Network Time Security para cliente-servidor. NTS-KE usa TLS para estabelecer chaves e cookies; extensões autenticadas protegem as mensagens seguintes, e o servidor pode permanecer sem estado após a negociação.

O NTS protege origem e integridade. Não prova que a referência upstream está certa ou que as fontes são independentes. Um erro autenticado ainda é erro. O padrão tampouco cobre modos simétricos e de controle.

Tempo comum como evidência revisável

Logs, certificados, bancos e sistemas físicos dependem da ordem dos eventos. Por isso é tentador trocar análise por uma marca famosa de servidor. O NTP oferece uma solução mais responsável: medir várias fontes falíveis, descontar o caminho, rejeitar incompatíveis, combinar sobreviventes e manter a disciplina do oscilador no cliente.

A confiança não some; torna-se plural, observável e revogável. Referências cuidam do vínculo com o tempo civil, servidores cuidam de upstreams e acesso, redes moldam atraso, clientes escolhem fontes e decidem como o relógio se move. Da discordância surge convergência sem entregar todos os relógios a um mestre permanente.

Fontes e limites da evidência

O antecedente está no RFC 778; a primeira especificação no RFC 958; a versão 1 no RFC 1059; e a pesquisa de 1989 no RFC 1129. A versão 3 está no RFC 1305. O modelo maduro aparece no RFC 5905 e no Clock Select Algorithm. Práticas operacionais vêm do RFC 8633, e o escopo do NTS do RFC 8915.

Os números da pesquisa valem para seus respondentes. Recursos de versões posteriores explicam o NTP maduro e não são atribuídos retroativamente a 1985.