Cloudflare 推出自動金鑰交換,讓後量子握手每天涵蓋 450 億次連線
blog.cloudflare.com · 2026-09-08
Cloudflare 於 2026 年 9 月 8 日在官方部落格宣布推出 Automatic Key Exchange 功能,讓 Cloudflare 與來源伺服器(origin)間的 TLS 交握自動偵測並優先選用後量子混合金鑰交換演算法,已預設對所有方案開啟,每天有 450 億次連線改用後量子金鑰交換完成握手。
原本的問題
TLS 1.3 交握要求客戶端(此處即 Cloudflare)必須在第一個封包 ClientHello 中先選定一組 key agreement group,此時尚不知對方支援哪些演算法。若猜錯首選,origin 就會回傳 HelloRetryRequest(HRR)要求重來,多花一次完整往返(RTT)。過去 Cloudflare 一律預設 X25519,但約 30% 的 origin 偏好 P-256、P-384 等曲線;貿然帶後量子 keyshare 首選,HRR 觸發率一度高達約 52%。
後量子部分採用 X25519MLKEM768,即古典曲線 X25519 與 NIST FIPS 203 標準化的 ML-KEM-768(前身 CRYSTALS-Kyber)混合而成。其 keyshare 長度達 1,216 位元組,近 X25519 單獨 32 位元組的 40 倍,猜錯被迫重試的延遲代價因此更明顯。
採用的方法
Automatic Key Exchange 的核心是持續且輕量的主動探測機制:對每個 TLS 1.3 origin 分別發起僅提供單一 key agreement group 的輕量交握,測試 X25519、P-256、P-384、P-521、X25519MLKEM768 五種選項,依流量加權後依優先序(有後量子支援者優先)決定各網域偏好。
- 每天重新掃描一次 origin,以偵測伺服器端設定的變動
- 新偏好先套用到 1% 流量,監控失敗率後再逐步擴大到 100%
- 站方可在 dashboard 的「SSL/TLS Overview → Origin connection & post-quantum encryption」中檢視與覆寫設定
有合規需求的站台可另設Compliance Requirements,強制交握只用特定演算法。若 origin 未支援 X25519MLKEM768 卻誤設僅限後量子混合,會導致該 origin 所有 TLS 1.3 連線失敗。
| 設定 | API 值 | 行為 |
|---|---|---|
| 無限制 | [] | 允許古典與後量子演算法 |
| Post-quantum hybrid | ["pqh"] | 僅接受後量子混合演算法 |
| FIPS | ["fips"] | 僅接受 FIPS 合規演算法 |
| Hybrid + FIPS | ["pqh", "fips"] | 同時滿足兩項要求 |
{
"compliance_requirements": ["pqh"]
}實際效果
上線後,HelloRetryRequest 發生率從約 52% 降至 3.7%,p90 交握延遲減少超過 150 毫秒。目前約 12.8% 的 origin 支援後量子金鑰交換(先前僅 0.5%);已掃描網域中 33% 優先選用 X25519MLKEM768,64% 仍留在 X25519,3% 用其他古典曲線。99.2% 的後量子 TLS 1.3 連線能一次完成交握、不需重試。
Rollout 平均每天約 9,000 個網域獲得新偏好設定,累計已逾 100 萬個網域被指派過偏好。Cloudflare 同步提供 Cloudflare Radar 後量子檢測頁面,可檢查任意伺服器的後量子支援狀態。下一步規劃包括偏好設定精細化到個別 origin、dashboard 手動重掃,以及防降級的自動後量子來源身份驗證。
Spotify 說明為何不採用貝氏 A/B 測試:框架選擇取決於實驗目標而非統計優劣
engineering.atspotify.com · 2026-09-08
Spotify 工程團隊於 2026 年 9 月 8 日發布部落格文章,回應外界對其實驗平台為何持續採用頻率學派(frequentist)而非貝氏(Bayesian)A/B 測試方法的提問。文章指出「貝氏 A/B 測試」並非單一方法,而是一整族統計保證各不相同的做法,框架選擇應取決於要控制哪一種風險。
原本的問題
外界常見誤解是貝氏方法天生能免除「偷看」(peeking,途中重複查看結果並提前喊停)造成的假陽性膨脹。Spotify 指出此說法只在特定條件下成立:若用平坦先驗(flat prior)後驗機率作停止規則,假陽性率其實與頻率學派裸偷看一致;真正能控制假陽性率的是貝氏因子(Bayes factor)停止規則,因其在虛無假設下具鞅(martingale)性質。
另一誤解與贏家詛咒(winner's curse)有關,即「顯著」效果估計常被誇大。資訊性先驗可透過收縮(shrinkage)降低此偏誤,但多數平台預設平坦先驗起不了保護作用;經驗貝氏(empirical Bayes)先驗若校準良好,誤差可優於傳統組序貫檢定,校準不良則反而更糟。
第三個誤解涉及多重指標檢定。要控制錯誤發現率(FDR),需同時具備貝氏因子停止規則、校準良好的經驗貝氏先驗、歷史實驗資料庫與一致的指標定義。Spotify 強調這是更精密的多重比較校正,而非外界誤解的「貝氏方法不做校正」。
採用的方法
文章將各種貝氏 A/B 測試配置整理成一套層級架構,說明各層提供的統計保證由弱到強:
| 層級 | 方法 | 提供的保證 |
|---|---|---|
| Tier 1 | 平坦先驗後驗機率停止 | 等同頻率學派偷看,不提供錯誤率控制 |
| Tier 2 | 貝氏因子(Bayes factor)停止 | 連續監控下的假陽性率控制 |
| Tier 3 | 經驗貝氏先驗 + 貝氏因子停止 | 錯誤發現率(FDR)控制 |
| Tier 4 | 決策理論(decision-theoretic)成本函數 | 結合抽樣、誤判成本後的最適策略 |
文章也指出一個數學事實:在平坦先驗與常態模型下,貝氏與頻率學派的輸出數值上完全相同——後驗平均值等於最大概似估計值,後驗機率等於一減 p 值。混合序貫機率比檢定(mSPRT)在相同先驗下與貝氏因子停止規則等價;將常見成本函數代入決策理論,得到的最適策略同樣是貝氏因子門檻值。
if BF10 >= threshold_win:
stop; declare treatment effect
elif BF10 <= threshold_lose:
stop; declare no effect
else:
continue collecting data文中引用一篇 2026 年 8 月掛上 arXiv 的論文 《Bayesian Inference Procedures for A/B Testing: An Overview》(Schultzberg 與 Frånberg 著)作為理論依據,以模擬驗證平坦先驗後驗停止「精確複製」裸偷看行為,校準良好的經驗貝氏方法則能達到最低估計誤差。
實際效果
Spotify 說明實驗平台的目標是降低錯誤商業決策、提供可信證據、產出不易被誤解的結果,並讓規劃簡單、難以誤用配置。要在全公司同時支援兩套框架,代表規劃工具、監控儀表板、結果解讀與輸出格式都須維護兩份,複雜度增加未必換來相稱效益。
經驗貝氏雖有實質優勢,代價是須在每項指標、每個方案上持續維護先驗品質。先驗可能因偏差語料庫(只封存贏的實驗)、跨方案不當共用、分布飄移或違反可交換性假設而失準,一旦失準,證據品質可能比單純頻率學派更差。Spotify 目前維持現有框架:先確認要控制的風險與目標,再判斷特定貝氏配置是否有足夠效益。
.NET 11 進入 Release Candidate 1,C# 15 聯合型別與容器發布同步收斂
devblogs.microsoft.com · 2026-09-08
背景
微軟於 2026 年 9 月 8 日發布 .NET 11 Release Candidate 1(RC1),為年度 11 月發布週期進入候選階段的第一版。RC1 附帶「go-live 授權」,代表可部署到正式環境,不必等正式版(GA);開發工具同步支援 Visual Studio 2026 Insiders 與搭配 C# Dev Kit 的 VS Code。依 .NET 慣例,奇數版屬於 Standard Term Support(STS),支援期較偶數版的 LTS 短,實際期限以正式公告為準。
| 類型 | 版本奇偶 | 典型支援期 |
|---|---|---|
| LTS(Long Term Support) | 偶數版,如 .NET 10 | 3 年 |
| STS(Standard Term Support) | 奇數版,如 .NET 11 | 18 個月 |
核心改動
執行環境(runtime)新增Unix 平台的行程內(in-process)當機回報機制,不外接除錯器也能取得完整診斷資訊;同時為半精度浮點數新增 FP16 硬體加速指令,讓 half 運算直接對應底層 CPU 指令。
基礎函式庫(BCL)本次涵蓋的主要異動如下:
- 訊號處理與行程終止狀態檢查 API
- 實驗性的 caller-driven TLS session 管理
- Linux 平台的 DNS 記錄解析範圍擴充
- JSON 支援新數值型別、二進位結構描述(binary schema)與封閉型別多型/聯合型別
- 非同步選項驗證(async options validation)
BitArray可直接由Span建構- 可重複使用的壓縮 encoder / decoder 實例;新增 AES Key Wrap 支援
SDK 與工具鏈更新聚焦於建置與發布流程的可重現性:dotnet test 為行動應用測試新增執行層級控制與結果版面選項;容器映像發布支援可重現建置(reproducible image)並消除重複上傳;Native AOT 的檔案式程式新增重用能力並支援格式化;dotnet format 的設定探索範圍收斂為僅涵蓋已納入的檔案。
語言層面,C# 15 正式收斂聯合型別(union)等實驗性特性,並持續精煉 unsafe 語法演進方向。F# 新增 record 展開語法(record spreads)與建構子支援、直接建構委派(delegate)、更有效率的字串插值,以及不依賴反射的 record/union 格式化輸出。
ASP.NET Core 定案 SignalR 的驗證更新(authentication refresh)API 並補上 TypeScript 用戶端支援;Blazor Server 電路能在驗證狀態更新後同步更新;OpenAPI 文件產生器會反映已標記 obsolete 的 API;Negotiate 驗證新增 TLS channel binding 支援。
影響範圍
其餘平台也有更新:.NET MAUI 在 Android、iOS 與 macOS 補強測試工具、控制項與 XAML 功能;Windows Forms 新增 kiosk 情境體驗控制,現代化視覺樣式趨於穩定;MSBuild 新增建立/解壓 tar 封存檔能力並開放 item glob 模式給工具鏈,NuGet 加強專案評估結果重用效率,並將弱點套件更新訊息設為 warnings-as-errors。
開發者可從 get.dot.net/11 取得 RC1 套件,完整發布記錄彙整在 dotnet/core 儲存庫的 11.0 release notes。對已用 .NET 10 的團隊而言,RC1 代表 C# 15 聯合型別語法已近定案,值得評估遷移;容器與 Native AOT 建置優化也有機會降低 CI/CD 成本。