BGP 路由外洩防護規範 RFC 9234 上路：Cloudflare 揭露兩家一級網路仍抹除保護標記
Cloudflare Blog · 2026-08-18
背景
網際網路的骨幹路由長期仰賴「山谷無源」（valley-free）假設維持穩定：路由只能由 Provider 往 Customer 方向自由傳遞，往上游或橫向傳遞則必須受限。一旦有人誤將從某家 Transit Provider 學到的路由，轉發給另一家 Transit Provider，就會發生 路由外洩（route leak），也就是 RFC 7908 定義的問題類型，過去多起大型網路中斷事故都與此有關。長期以來，網路營運商只能靠人工撰寫的複雜路由政策來防堵，出錯機率高且難以稽核。
規格細節
2022 年發布的 RFC 9234 在 BGP 的 OPEN 訊息中新增 角色能力（BGP Role Capability，能力代碼 9），讓兩端路由器在建立 BGP 連線時協商彼此的關係角色，角色不一致時會以 OPEN Message Error（錯誤碼 2、子碼 11）拒絕連線。五種角色的傳遞規則如下：
| 角色 | 可轉發對象 |
|---|---|
| Provider | 可將任何已知路由發給 Customer |
| Customer | 只能把 Customer 或自家原生路由發給 Provider |
| Peer | 只能把 Customer 或自家原生路由發給其他 Peer |
| RS（Route Server） | 可將任何已知路由發給 RS-Client |
| RS-Client | 只能把 Customer 或自家原生路由發給 RS |
角色協商之外，規範另外定義 OTC（Only to Customer）路徑屬性（類型代碼 35），在對 Customer、Peer 或 RS-Client 廣播路由時自動附加；接收端若從 Customer 或 RS-Client 收到帶 OTC 的路由，即可判定為外洩並直接拒收，不需再靠人工政策比對。
影響範圍
Cloudflare 利用自身遍布全球的對等連線（peering）據點設計出量測方法，追蹤 OTC 屬性在真實網路中的存活狀況，結果發現 兩家大型一級網路會在轉發路由時把 OTC 屬性整個剝除，等於讓下游依賴此屬性的網路失去保護效果。這代表即使營運商已支援 RFC 9234，只要路徑上有一段不透傳屬性，防護鏈就會斷裂。Cloudflare 表示將持續與業界溝通，推動更多骨幹網路完整轉發 OTC，才能讓角色模型發揮全網防禦效果。
Dropbox 公開 AI 時代機房增效手法：五年將每 PB 耗電砍半
Dropbox.Tech · 2026-08-18
原本的問題
AI 相關工作負載讓 Dropbox 的儲存與運算需求同步成長，但資料中心端的電力、散熱、硬體供貨與機房空間都是有限資源，無法單靠持續擴建來因應。工程團隊因此把重心放在既有機隊的 使用效率，而非單純堆疊新硬體，目標是在不擴大能耗與空間需求的前提下承接更多負載。
採用的方法
文章列出四類具體措施，涵蓋硬體排程、資料佈局與機房設計：
- Deep Sleep 休眠機制：需求較低時將閒置伺服器關機或讓硬碟進入待機狀態，並由自動化機隊管理演算法在數分鐘內喚醒回應。
- 負載平衡：持續監控機隊的剩餘容量並重新分配工作，避免局部熱點，過程結合自動調整與工程師人工驗證。
- 儲存密度提升：導入疊瓦式磁記錄（SMR）技術，讓單顆硬碟可容納更多資料，連帶減少所需硬體數量、纜線與供電負擔。
- 硬體生命週期管理：改用年化故障率（AFR）而非固定汰換週期來決定硬體去留，效能穩定的設備會延長使用。
- 機架供電改造：將每機架的電源分配單元（PDU）數量加倍，以便在不大幅翻新機房的情況下容納第七代伺服器。
實際效果
Dropbox 表示自 2020 年起，其 儲存基礎設施每 PB 耗電量已改善超過五成，換算下來，支援等量儲存容量所需的電力已不到 2020 年的一半。文章將此歸功於休眠機制、密度提升與機房供電改造三項措施的疊加效果，而非單一技術突破。
原始來源：Dropbox.Tech
Azure SQL 用 RRF 合併全文檢索與向量檢索，打造原生混合搜尋
Azure SQL Dev Corner · 2026-08-18
背景
全文檢索擅長比對關鍵字與語意變化，例如查詢「run」可自動比對「ran」「running」「runs」；向量檢索則擅長抓取語意相近但字面不同的內容，但為了在大量向量中維持效能，多數實作採用 近似最近鄰（ANN） 而非逐一比對的精確 kNN。Azure SQL Dev Corner 文章說明，這兩種檢索各有盲點，單獨使用都無法同時兼顧字面精準與語意廣度，因此需要混合搜尋。
規格細節
全文檢索一側用的是奠基於 BM25 演算法 的 FREETEXTTABLE()，會自動做語言相關的斷詞與詞幹還原：
SELECT p.Name, ft.RANK
FROM FREETEXTTABLE(Product, (Description), 'running shoes') ft
JOIN Product p ON p.Id = ft.[KEY]
ORDER BY ft.RANK DESC;向量檢索一側則是建立在 DiskANN 技術上的 VECTOR_SEARCH()，支援對大量向量做近似最近鄰查找，並可加上 WITH APPROXIMATE 提示：
SELECT TOP (10) WITH APPROXIMATE
p.Id, p.Name, v.distance
FROM VECTOR_SEARCH(
TABLE = ProductEmbedding AS p,
COLUMN = Embedding,
SIMILAR_TO = @Embedding,
METRIC = 'cosine'
) AS v
ORDER BY v.distance;兩組排序結果最後透過 Reciprocal Rank Fusion（RRF） 合併成單一結果集，可選擇為其中一種排序加權，讓混合搜尋在同一次查詢內完成，不需外部服務二次合併。
影響範圍
文章也提到 SQL Server 可透過 sp_invoke_external_rest_endpoint 呼叫外部模型，並搭配內建的 AI_GENERATE_EMBEDDINGS 產生嵌入向量，意味著開發者能在 同一個資料庫內 完成從嵌入產生、向量索引到混合排序的完整流程，不必另外維運獨立的向量資料庫。這對已在 SQL Server 或 Azure SQL Database 上建置 RAG 應用的團隊而言，減少了跨系統同步資料的複雜度。
原始來源：Azure SQL Dev Corner