国产高清在线免费观看-国产高清在线免费无码-国产高清在线男人的天堂-国产高清在线视频-国产高清在线视频精品视频-国产高清在线视频伊甸园

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

一直以來，操作系統(tǒng)的「時間、日期、時區(qū)」，是讓很多程序員在開發(fā)程序時比較敏感與特別關注的問題。

還記得即將步入 2000 年的“千年蟲”（Year 2000 Problem，簡稱“Y2K”）事件，由于早期的計算機配置比較低，那時為了節(jié)省空間就把年份只用后兩位數(shù)表示，如 1999 就表示為 99，導致新千年時電腦把 2000 年認為是 1900 年，出現(xiàn) Bug，進而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至崩潰。

2012 年，有用戶發(fā)現(xiàn)低內核版 Linux 開啟 NTP 服務器會遇到閏秒 Bug，導致服務器重啟。

2016 年，很多網友“作了一把”，將 iPhone 的日期設置到 1970 年 1 月 1 日，無意中觸發(fā)系統(tǒng) Bug，一時間導致 iPhone 重啟失敗，手機直接變板磚。

就在近日，一個新的關于時間 Bug 出現(xiàn)在 Windows 系統(tǒng)中。據(jù) Ars Technica 報道，有一位挪威數(shù)據(jù)中心的工程師 Simen 遇到了一個令人費解的時間 Bug， 它會導致 Windows Server 突然將系統(tǒng)時鐘重置到未來 55 天。

時間 Bug 帶來的混亂

事實上，這并不是 Simen 第一次遇到這個問題。

在去年 8 月，Simen 曾遇到過類似的錯誤，當時一臺運行 Windows Server 2019 的機器將時鐘重置到了 2023 年 1 月，但過了沒多久又自動跳回來了。

后來，直到事件日志被清除后才發(fā)現(xiàn)這一問題，但那時無法分析具體是什么原因導致的。

現(xiàn)在，他又在一臺運行 Windows Server 2016 的機器上遇到了這個問題。

對于普通用戶而言，時間的錯亂帶來的短暫影響也許可以忽略不計。但是對于工程師而言，卻是一個讓人崩潰的存在。

Simen 的主要工作是在 Windows Server 維護一個路由表（存儲在聯(lián)網計算機中的電子表格（文件）或類數(shù)據(jù)庫），這個路由表實時跟蹤手機號碼從一個運營商轉到另一個運營商的過程。

當服務器出現(xiàn)時間 Bug 時，系統(tǒng)時鐘跳到八周后，這就帶來一個不可估量的后果，譬如，此前尚未遷移的號碼被列入已經遷移、已經轉移的號碼被列為待處理狀態(tài)，整個都亂掉了。

無獨有偶

本來以為這只是一個特例，但是搜索一下，網絡上遇到這個問題的工程師不在少數(shù)。

去年，有一位名叫 Ken 的工程師也發(fā)現(xiàn)了類似的“時間跳躍”現(xiàn)象，當時在 2-3 臺服務器上，時鐘時不時會跳躍到幾周后，甚至有一次直接跳到了 2159 年。

據(jù) Ars Technica 披露，Ken 在一封郵件中寫道：“受此影響的服務器呈指數(shù)增長，越來越多。在 5000 臺服務器（虛擬機）中，我們總共有 20 臺左右的服務器（虛擬機）遇到過這種情況。這種情況通常發(fā)生在數(shù)據(jù)庫服務器上。當數(shù)據(jù)庫服務器在時間上發(fā)生跳躍時，就會造成嚴重破壞，只要服務器在時間上有如此大的偏移，備份也就無法運行。對于我們的客戶來說，這一點至關重要。”

除了 Simen 和 Ken 之外，追溯到 2017 年，一位 Reddit 用戶 zanatwo 發(fā)帖稱他在一所大學工作，某一天，其發(fā)現(xiàn)校園內的幾臺 Windows 10 計算機開始出現(xiàn)錯誤的時間。這些計算機上顯示的時間 Bug 完全是隨機的，在某些情況下，他的設備時間直接跳到了 31 個小時之前。

通過深入分析，當時 Reddit 用戶發(fā)現(xiàn)，時間變化與 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits 中的 Windows 注冊表鍵相關。進一步的調查顯示，當一些人試圖訪問大學網站時，這些錯誤報告稱網站使用的有效 SSL 證書無效。

Windows 官方發(fā)布的功能惹了禍？

經過排查之后，以上幾位工程師將罪魁禍首統(tǒng)一定位到了 Windows 上一個鮮為人知的功能—— Secure Time Seeding（簡稱 STS）中。

這是微軟在 2016 年引入 Windows 的功能，主要作用就是在 Windows 設備無法通過安全連接與時間服務器通信的情況下，改進對正確時間的記錄。簡單來看，這也是設備在斷電情況下也能保證準確的時間。默認情況下，這一功能在 Windows 系統(tǒng)及服務器下是打開的。

從工作原理來看，為確定當前時間，STS 會調用 SSL（Secure Sockets Layer）握手過程中包含的一組元數(shù)據(jù)。具體來說，這些數(shù)據(jù)包括：

ServerUnixTime，日期和時間表示法，顯示自 1970 年 1 月 1 日 00:00:00 UTC 時起已過去的秒數(shù)。

從遠程服務器 SSL 證書中獲取的加密簽名數(shù)據(jù)，顯示該證書是否已根據(jù)所謂的 "在線證書狀態(tài)協(xié)議 "機制被撤銷。

在發(fā)布這一功能時，微軟工程師在官方文檔中寫道，他們使用 ServerUnixTime 數(shù)據(jù)是 "假定它在一定程度上是準確的"，但在同一句話中又承認它 "也可能是不正確的"。

為了防止 STS 根據(jù)單個不同步遠程服務器提供的數(shù)據(jù)重置系統(tǒng)時鐘，STS 會隨機穿插 SSL 連接到多個服務器，以得出當前時間的可靠范圍。

然后，該機制會將 ServerUnixTime 與 OCSP（Online Certificate Status Protocol，在線證書狀態(tài)協(xié)議 ）有效期合并，以產生盡可能小的時間范圍，并為其分配置信度分數(shù)。

當分數(shù)達到足夠高的閾值時，Windows 就會將數(shù)據(jù)歸類為 STSHC（Secure Time Seed of High Confidence，高置信度安全時間種子）。然后，STSHC 用于監(jiān)控系統(tǒng)時鐘是否存在 "嚴重錯誤"，并對其進行糾正。

盡管 STS 內建了檢查和平衡機制，以確保其提供準確的時間估計，但長期以來工程師遇到的“時間跳躍”事件表明，該功能有時會做出誤差數(shù)天、數(shù)周、數(shù)月甚至數(shù)年的胡亂猜測。

在 Ars Technica 報道的文章中，其分享了來自工程師 Ken 遇到時間跳躍時的具體截圖。

第一張圖片中的選定行上方的 "預計安全時間 "條目顯示，Windows 預計當前日期為 2023 年 10 月 20 日，比系統(tǒng)時鐘顯示的時間晚四個多月。然后，STS 會更改系統(tǒng)時鐘，使其與"目標系統(tǒng)時間 "中顯示的錯誤的預計安全時間相匹配。

第二張圖片顯示了類似的情況，其中 STS 將日期從 2023 年 6 月 10 日改為 2023 年 7 月 5 日。

 

在遇到這一問題后，Ken 和 Simen 都向微軟進行了反饋，遺憾的是，他們并沒有得到實質性的回應與解決方案。

微軟工程師個人曾發(fā)出警告：主動關閉 STS 功能

那要問有沒有解決方法，其實去年一位微軟 Windows 高級工程師 Ryan Ries 發(fā)過推文提供過用戶，其寫到“大家好，如果你們管理 Active Directory 域控制器，我想給你們一些非官方的建議，這完全是我的個人意見：在您的 DC 上禁用 w32time 的 STS。”

當有網友進一步詢問原因時，Ryan Ries 表示，「因為在它咬你的屁股之前，這只是一個時間問題」。

這也不禁讓人好奇，連微軟自家工程師都覺得這個功能有問題，為什么官方還有做保留。

就在眾人存疑時，微軟在給 Ars Technica 的一份聲明中寫道：

STS 功能是一種基于啟發(fā)式的計時方法，在某些軟件/固件/硬件計時失效的情況下也有助于校正系統(tǒng)時間。該功能已在所有默認 Windows 配置中默認啟用，并已證明在默認配置中發(fā)揮了預期功能。

每次部署的時間分配都是獨一無二的，客戶通常會根據(jù)自己的特殊需求來配置機器。鑒于 "STS"的啟發(fā)式性質以及客戶可能使用的各種部署，我們提供了禁用該功能的選項，以滿足客戶的需求。我們的理解是，在客戶遇到 STS 問題的部署中，很可能存在獨特、專有、復雜的因素，而這些客戶并不能從目前實施的這一功能中受益。在這些個別情況下，我們只能建議在部署中禁用該功能。

具體來看，要禁用 STS，可以在受影響的機器上設置一個注冊表項。這是 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 目錄中的 UtilizeSslTimeData 密鑰，其類型為 REG_DWORD。如果設置為 0，則停用 STS。如果設置為 1，則可以重新激活該功能。

STS 的異常，有沒有解決方案？

截至目前，似乎除了關閉此功能之外，并沒有太過合適的解決方案，因此，很多人對于微軟的回應并不買賬。在 HN 上，網友也展開了激烈的討論，甚至有人吐槽：是時候應該買塊手表來核對服務器上的時間了！

另外，有網友 @theqmann 分析認為，「這聽起來像是一種統(tǒng)計方法，如果在給定時間內收到 N 個時間戳相似的數(shù)據(jù)包/連接，就會改變時鐘。我可以看到這樣一個問題：一臺 Windows Server 每分鐘全天候提供數(shù)千或數(shù)百萬個 OpenSSL 數(shù)據(jù)包，而它恰好隨機接收到 N 個數(shù)據(jù)包，這些數(shù)據(jù)包彼此非常接近，足以滿足統(tǒng)計閾值的要求。通過隨機跳轉，連續(xù)跳轉十多次時間都是有可能的」。

@jmuguy 則表示：

在我做 IT 人員的這些年里，Windows Time 是我處理過的最煩人的事情之一。注冊和取消注冊 w32time，嘗試不同的 NTP 服務器。試圖弄明白為什么域系統(tǒng)無法從 DC 獲取時間。這總讓人感覺很......愚蠢。在設備上設置正確的時間肯定沒那么復雜。事實證明，并不復雜，除非你使用的是 Windows 系統(tǒng)。有點諷刺的是，如今我唯一需要處理的 Windows 系統(tǒng)就是我的游戲電腦。它拒絕與 time.windows.com 同步。

除了 Windows 系統(tǒng)之外，還有人稱在 Linux 中也遇到了同樣的問題。

@nicolaslem 表示： 

我的 Linux 筆記本電腦有時也會遇到類似的問題，把電腦從睡眠中喚醒時，時間會跳到 2077 年。我猜這是硬件故障，因為它并不經常發(fā)生，但一旦發(fā)生就會造成很大影響。我無法想象在生產服務器上發(fā)生類似情況會有多大影響。

你是否遇到過類似的問題？

原文鏈接：https://blog.csdn.net/csdnnews/article/details/132373095

————————————————

版權聲明：本文為CSDN博主「CSDN資訊」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/csdnnews/article/details/132373095