一個 HTTP 標頭讓 time.gov 與 UTC 偏移：Connection: close 的計時陷阱
alexsci.com · 2026-05-07
技術部落格 alexsci 近日刊出一篇逆向工程文章，揭示 time.gov 的 JavaScript 時間同步實作因 Connection: close 標頭產生系統性計時誤差，讓瀏覽器顯示的時間持續比實際 UTC 偏慢數百毫秒，直至 NIST 在 2026 年 4 月 24 日左右修正伺服器 HTTP 設定才解決。
原本的問題
time.gov 的 JavaScript 以類似 NTP 的方式估計伺服器時間：發送 HTTP 請求、記錄請求前後的 performance.now()，假設伺服器在「半個 RTT」後生成時間戳，再以此校正本地顯示時間。NTP 客戶端假設每個時間戳對應一次網路來回，這在大多數情況下正確——但 Connection: close 打破了這個假設。
漏洞機制
Connection: close 迫使每個 HTTP 請求建立全新的連線，因此一次「請求→回應」實際涉及三次完整往返：
- TCP 三向交握：~1 RTT
- TLS 握手：~1 RTT
- HTTP 請求/回應：~1 RTT
伺服器在第三次往返結束後才生成時間戳，但 JavaScript 計算仍假設只有一個 RTT。實際情況是伺服器在 2.5 個 RTT 後生成時間戳，客戶端卻以 1.5 個 RTT 估算，造成整整一個 RTT 的系統性低估。以家用網路的 20ms RTT 計算，偏差約 20ms；跨地域連線的 100ms+ RTT 偏差更為明顯。
實際效果
NIST 的修復方案是在 HTTP 回應標頭加入 Connection: Keep-Alive，讓瀏覽器重用連線。重用後，後續請求不再需要 TCP 和 TLS 握手，每次時間戳請求只有一個 HTTP RTT，恢復了 NTP 時間估算模型所需的單輪迴假設。
這個案例說明了一件微妙的事：HTTP 的連線管理決策，看似只影響效能，實際上可以改變應用層協議中隱含的時間模型。任何依賴往返時間估算進行時鐘同步的 Web 應用，都需要確保底層連線模式符合估算假設，否則精度保證會在無聲無息中失效。
原始來源：alexsci.com — How an HTTP header caused time.gov to skew from UTC
2026 C++ 開發者年度調查結果：工具鏈現代化與建構系統碎片化問題浮現
isocpp.org · 2026-05-04
ISO C++ 基金會公布 2026 年 C++ 開發者年度調查 "Lite" 的完整結果，調查涵蓋數千名 C++ 開發者，結果已轉交 C++ 標準委員會及各主要工具鏈廠商。本次調查著重在工具鏈採用狀況、建構系統生態、模組（Modules）使用率以及開發者對 C++26 特性的期待。
工具鏈與編譯器現狀
調查顯示，MSVC、GCC、Clang 三大編譯器的市佔率趨於接近，跨平台開發比例持續上升，單一編譯器的主導地位在過去五年明顯稀釋。Clang 在非 Windows 開發者間的採用率尤其顯著，尤其是使用 macOS 和 Linux 的嵌入式開發者群體。
建構系統的碎片化
建構系統仍是社群最大的碎片化來源。CMake 維持最高佔有率，但不滿意度也最高——開發者批評其語法陳舊、文件難以查閱、跨平台行為不一致。Meson、Bazel、xmake 等替代方案的採用率逐年上升，但沒有一個替代工具達到接近主導的地位。對「有一個官方推薦的建構工具」的需求呼聲在開放評論區排名最高。
C++20 模組採用率仍低
儘管 C++20 已發布超過五年，模組（Modules）特性的實際採用率仍然偏低，主因是建構系統支援不完整和跨工具鏈的相容性問題。多數受訪者表示正在觀望，等待 CMake 和 IDE 支援成熟後才計畫遷移。import std 的標準函式庫模組在 C++23 引入後引起較多關注，但生產採用仍屬少數。
C++26 期待
開發者對 C++26 最期待的特性集中在反射（reflection）、pattern matching、以及 assert() 的改進（即本次調查同期 isocpp.org 刊出的 Sandor Dargo 文章所討論的 C++26 user-friendly assert 提案）。反射特性的呼聲尤其高，不少受訪者表示反射是他們在 C++ 中最希望看到的元程式設計改進，超過模板技術的進一步發展。
原始來源：isocpp.org — Results summary: 2026 Annual C++ Developer Survey "Lite"