İnternet Saati: Doğru Zamanın Ağdan Geçerken Değişen Hikâyesi

Bir uygulamanın iki ayrı bilgisayardaki kayıtlarını yan yana getirdiğinizde, yanıtın isteğinden önce yazılmış gibi göründüğünü düşünün. Olayların gerçekten ters sırada yaşanması gerekmeyebilir. Bilgisayarların saatleri arasında küçük bir fark, düzgün işleyen bir alışverişin zaman çizelgesini bozabilir. Bu, burada konuyu anlatmak için kurulmuş bir örnektir. Böyle bir kayıt uyuşmazlığını çözmenin ilk adımı, ekranda görülen saat ile olayın gerçekleştiği anın birbirine nasıl bağlandığını sormaktır. Ağ üzerinden saat eşitleme, bu bağı kurmaya çalışır; yalnızca başka bir ekrandaki sayıyı kopyalamaz.

Network Time Protocol, yani NTP, bilgisayarlar arasında zaman bilgisi taşımak için geliştirilmiş bir protokoldür. NIST'in Internet Time Service açıklaması, işletim sistemlerindeki eşitlemenin çoğu kez arka planda çalıştığını anlatır. Kullanıcının her gün saati elle düzeltmesi gerekmez. Ancak otomatik çalışması, işlemin gecikmesiz ya da hatasız olduğu anlamına gelmez. İstemci bir zaman kaynağına başvurur, gelen bilgiyi değerlendirir ve kendi yerel saatinin referansla ilişkisini düzenler. Bu yazı, 13 Ekim 2026 bilgi kesim tarihinden önce yayımlanmış standartlar ve NIST belgeleri üzerinden bu sürecin mantığını inceler. [1]

Zaman kaynağı ile saat dilimi aynı şey değildir

NIST, stratum-1 sunucularının doğrudan UTC(NIST) zaman ölçeğine bağlı olduğunu belirtir. Buradaki bağlantı, hizmetin referansının nereden geldiğini anlatır. Stratum etiketi, paketin sizin bilgisayarınıza ne kadar sürede ulaştığının ölçüsü değildir. Referansa doğrudan bağlı bir sunucuya ulaşan ağ yolunuz dalgalıysa, istemcide görülen sonucun belirsizliği yine büyüyebilir. NIST, kullanıcı tarafındaki doğruluğun ağ bağlantısının kararlılığı ve iki yöndeki gecikmelerin karşılıklılığı tarafından önemli ölçüde belirlendiğini özellikle açıklar. [1]

Saat dilimi farklı bir katmandır. UTC cinsinden belirlenen aynı an, yerel gösterim için farklı bir saat ve tarihe çevrilebilir. Varsayımsal olarak UTC'ye üç saat ekleyen bir gösterim kullandığınızda, bir saat dilimini seçmiş olursunuz; bilgisayarın zaman referansını üç saat ileri kaydırmış olmazsınız. Bu ayrım, yanlış bölge ayarını eşitleme arızası sanmayı önler. Ülkeye ait güncel saat kuralları ise ayrı bir yapılandırma konusudur. Bu makale belirli bir ülkenin yürürlükteki kurallarını veya bir işletim sistemi sürümünün menülerini tarif etmiyor.

Dört anı kaydetmek, tek anı kopyalamaktan farklıdır

Bir sunucu “saat şimdi budur” dediğinde yanıtın yolculuğu henüz bitmemiştir. İstemci yanıtı aldığı sırada sunucuda yazılı an geçmişte kalmıştır. Daha yararlı bir alışveriş, istemcinin isteği gönderdiği anı, sunucunun onu aldığı anı, sunucunun yanıtı gönderdiği anı ve istemcinin yanıtı aldığı anı birlikte kullanır. Bu dört zaman damgası iki ayrı saatten gelir. NIST'in 2002 tarihli teknik yayını, ağ üzerinden saat karşılaştırmasında gidiş-dönüş hesabını ve sunucunun işlem süresinin ayrılmasını açıklar. NTPv4 standardının sekizinci bölümü de aynı temel hesabı belirtir. [2][3]

Hesabı görmek için varsayımsal, milisaniye cinsinden dört değer kullanalım. İstemci isteği sıfırda göndersin. Sunucu kendi saatinde 30'da alsın ve 35'te yanıtlasın. İstemci yanıtı kendi saatinde 45'te alsın. İstemcinin toplam bekleme süresi 45, sunucunun isteği alması ile yanıtlaması arasındaki süre ise 5 milisaniyedir. İkincisini birinciden çıkarınca ağın gidiş ve dönüş için harcadığı toplam süre 40 milisaniye olarak tahmin edilir. Sunucunun cevap hazırlamak için harcadığı beş milisaniyeyi ağ yolculuğuna katmak farklı bir sonuç üretirdi.

Sunucu saatinin istemciye göre farkını hesaplamak için iki uçtaki karşılaştırma kullanılır: 30 eksi sıfır ile 35 eksi 45. Bunların toplamının yarısı 10 milisaniyedir. Gidiş ve dönüş gecikmeleri eşitse bu örnekte sunucu saati istemciden 10 milisaniye ileridedir. Bu değerler gerçek bir ağda ölçülmedi; yöntemi anlaşılır kılmak için seçildi. Formül ağ gecikmesini ortadan kaldırmaz. Gecikmenin nasıl dağıldığı hakkında bir varsayım kullanarak saat farkını tahmin eder.

Uzun yolun değil, eşitsiz yolun sorunu

NIST'in teknik açıklaması, iki yönün eşit gecikmesi varsayımından sapmanın saat farkı tahminine hata eklediğini gösterir. İstek ve yanıt aynı toplam sürede gidip gelebilirken, bu sürenin yönler arasındaki paylaşımı değişebilir. Örneğin, dışarı giden yol biraz daha uzun sürüyor ve dönüş daha kısa sürüyorsa, hesap aradaki farkın bir kısmını saat farkı gibi yorumlar. Dört zaman damgası, tek başına, iki yönün gerçek gecikmesini bağımsız olarak ölçmeye yetmez. [2]

Bu nedenle daha fazla sorgu göndermek her sorunu otomatik olarak çözmez. Değişken dalgalanmalar ile sürekli bir yön eşitsizliği aynı sorun değildir. Birçok örneği değerlendirmek geçici sıra dışı yanıtları ayırt etmeye yardım edebilir; sürekli sistematik farkı ortalama almakla yok olmuş kabul edemeyiz. İstemcinin hangi ölçümleri kabul ettiği, kaynakları nasıl karşılaştırdığı ve kendi saatini nasıl düzenlediği sonuç üzerinde etkilidir. NIST'in hizmet sayfası, tam NTP istemcilerinin yanlış zaman gönderiyor gibi görünen yanıtları dışlayıp uygun kaynakları değerlendirmesini, tek yanıtla çalışan basit SNTP davranışından ayırır. İkisinin aynı mesaj biçimini kullanması bütün istemcilerin aynı analizi yaptığı anlamına gelmez. [1]

Yerel saatin davranışı da ölçüm zincirinin parçasıdır. NIST yayını saat farkı ile frekans farkını ayrı değişkenler olarak ele alır: İlki belirli bir anda ne kadar önde veya geride olunduğunu, ikincisi bu farkın zamanla nasıl değiştiğini anlatır. Bir kez eşitlemek, yerel saatin daha sonra referanstan uzaklaşmayacağını kanıtlamaz. Belgedeki eski donanım ve deney performansları bugünkü bütün bilgisayarların performansına çevrilemez; burada kullanılan şey bu iki değişkeni ayıran ölçüm mantığıdır. [2]

Doğru gönderici, gecikmesiz yol demek değildir

Zaman paketinin kimden geldiği de önemlidir. NIST'in kimlik doğrulamalı NTP hizmeti, paylaşılan gizli anahtar ve mesaj doğrulama koduyla iletinin kaynağını ve bütünlüğünü denetlemeyi açıklar. Fakat hizmetin sık sorulan sorular bölümünde kimlik doğrulamanın zaman aktarımını daha doğru yapmadığı açıkça belirtilir. Kaynağı doğrulamak ile yolculuğu ölçmek ayrı işlerdir. Sunucuda doğrulama için gereken ek işlem, zaman damgası kaydedildikten sonra gerçekleştiğinde küçük bir gecikme bile ekleyebilir. [4]

RFC 8915'teki Network Time Security, anahtar kurulumu için TLS ve ardından korunmuş NTP alışverişi kullanır. Aynı standart, paket içeriği değiştirilmeden yaratılan asimetrik gecikmenin şifreleme ile giderilemeyeceğini açıklar. Bu, kimlik doğrulamanın yararsızlığı değil, koruduğu özelliğin sınırıdır. NIST'in Eylül 2026 tarihli hizmet sayfasında NTS anahtar kurulumunun henüz desteklenmediği yazılıdır; standart bulunması her hizmette uygulanmış olması demek değildir. [4][5]

Güvenilir bir saat değerlendirmesi bu parçaları birlikte tutar: referansın kaynağı, ağın davranışı, istemcinin ölçüm işlemleri, yerel saatin değişimi ve iletinin doğrulanması. Ekrandaki ondalık basamak sayısı bu zincirin toplam doğruluğunu tek başına anlatmaz. Başlangıçtaki kayıt örneğine dönersek, zaman damgaları arasındaki küçük farkı olay sırası hakkında kesin hükme çevirmeden önce saatlerin nasıl eşitlendiğini bilmek gerekir. NTP'nin temel katkısı, uzaktaki saati erişilebilir kılarken aradaki yolun da hesabın bir parçası olduğunu kabul etmesidir. Doğru zamanı dağıtmak, sayıyı göndermekle değil, bu ilişkinin belirsizliğini yönetmekle tamamlanır.

Kaynaklar

1. NIST. Internet Time Service: referans, istemciler, protokoller ve ağ bağlantısı. Güncelleme: 9 Haziran 2026.
2. Levine, J., Lombardi, M. A. ve Novick, A. N. NIST Computer Time Services, Special Publication 250-59, Mayıs 2002. Teknik yayın, özellikle basılı sayfa 16–18: saat modeli, gidiş-dönüş ölçümü ve asimetri. Eski sistem performansları güncel ürün iddiası olarak kullanılmamıştır.
3. Mills ve diğerleri. RFC 5905: NTPv4, bölüm 8, Haziran 2010. Formül doğrulaması; kaynak kod veya standart metni kopyalanmamıştır.
4. NIST. Authenticated NTP Service: doğrulama ve doğruluk ayrımı. Güncelleme: 17 Eylül 2026.
5. RFC 8915: Network Time Security, Eylül 2020; protokol akışı ve bölüm 8.6'daki gecikme saldırısı sınırı.

Kaynak erişimi: 14 Ekim 2026. Teknoloji bilgi kesim tarihi: 13 Ekim 2026. Sayısal alışveriş ve kayıt senaryoları açıklama için oluşturulmuştur; cihaz testi veya hizmetin kesintisiz çalıştığına dair canlı ölçüm yapılmamıştır.