近七成 BGP 路徑遭竄改：Cloudflare 揭露 ORIGIN 屬性操縱規模
Cloudflare Blog · 2026-07-24
背景
BGP 的 ORIGIN 屬性是一個強制性路徑屬性，用來標示一條路由當初是「如何」被注入 BGP 的，只有三種合法值：IGP（0）、已廢棄的 EGP（1）、以及 INCOMPLETE（2）。在 RFC 4271 定義的路由選擇流程中，ORIGIN 的比較發生在路徑選擇的早期階段，IGP 的優先序高於 INCOMPLETE，這使得竄改這個欄位成為操縱流量走向的低成本手段。Cloudflare 這篇研究要回答的問題很直接：網路上到底有多少路由的 ORIGIN 屬性，在傳遞過程中被轉手的 ISP 動過手腳。
核心改動/規格細節
研究團隊從自己的 anycast 節點宣告帶有不同 ORIGIN 值的 IPv4 與 IPv6 測試前綴，確認在全球完成傳播後再撤回，藉此逼出額外的路徑重新探索行為；再用 BGPKIT 工具鏈比對 RIPE RIS、RouteViews 收集器與自家邊界路由器蒐集到的 BGP Update 訊息。對於較長的 AS Path，團隊採用演算法方式：先以自身 AS（AS13335）為信任種子，再逐層判斷哪些 AS 保留了原始 ORIGIN 值、哪些動過手腳。統計結果顯示竄改規模相當可觀：
| 觀察對象 | 比例 |
|---|---|
| IPv4 AS 路徑 ORIGIN 被重設為 IGP | 約 70% |
| IPv6 AS 路徑遭遇同類竄改 | 67% |
| 直連 peer 中把 ORIGIN 改成 IGP（IPv4） | 約 10% |
| Top 50 大型 AS 涉及竄改 | 26% |
| Top 100 大型 AS 涉及竄改 | 20% |
竄改者因此額外多拿下 18% 的 IPv4 路徑與 40% 的 IPv6 路徑——這正是動機所在：轉手 ISP 把 ORIGIN 改成 IGP，讓自己的路由在下游眼中看起來優先序更高，藉此贏得競爭對手手上的流量與隨之而來的營收。
影響範圍
這種竄改的直接後果，是把流量從原本可能經過的其他路徑，重新導向大型 Tier-1 ISP，造成遵守協定慣例的網路與刻意竄改的網路之間出現不對等競爭。文中也提到 RFC 904（已廢棄的 EGP 協定）與 RFC 1997（BGP community）作為背景參照。由於 ORIGIN 屬性缺乏完整性保護機制，任何轉手的 AS 都能悄悄修改它而不會被下游直接發現，這是文章點出業界需要正視的核心問題。
原始來源：Cloudflare Blog - BGP ORIGIN attribute manipulation and its impact on the Internet
Podcast 影片延遲數小時：Spotify 揭露內容擷取管線四重故障疊加
Spotify Engineering Blog · 2026-07-20
原本的問題
2026 年 6 月 24 日，Spotify 的 Podcast 創作者發現新上傳的影片類 Podcast 集數，原本應該在幾分鐘內完成處理並上架，卻延遲了數小時才出現。更麻煩的是，當時的內容擷取管線缺乏確認上傳是否已被系統接收並排入佇列的機制，創作者甚至無法確認自己的上傳是否遺失。監控在 13:30 UTC 就已發出警報，但一開始並未被辨識為容量問題，一直到 17:34 UTC 事件應變才正式啟動，中間存在將近四小時的落差。
採用的方法
事後調查發現這是四個因素同時疊加造成的：轉碼基礎設施本身缺乏足夠餘裕來吸收內容遞送的尖峰流量；一個排程中的批次任務，在處理既有集數的例行重新處理工作時，額外佔用了運算容量；近期針對影片畫質的提升，增加了每一集所需的處理量，卻沒有同步調整容量；以及一次硬體遷移之後留下的軟體臭蟲，讓資源使用率下降了約 10%。
- 13:30 UTC——監控率先發出警報，但未被判定為容量問題
- 15:00 UTC——影片遞送量尖峰，系統逼近最大容量
- 16:35 UTC——批次任務被停止
- 17:34 UTC——事件應變正式啟動
- 20:49 UTC——軟體修復上線
- 00:14 UTC（6/25）——追加處理叢集啟用
- 01:02 UTC——堆積的佇列清空
- 07:30 UTC——確認系統完全恢復正常運作
實際效果
Spotify 之後把轉碼容量提升了 67%，同時修掉造成資源使用率下降的排程臭蟲，並強化監控讓容量問題能更早觸發告警。除了針對這次事故的修補，團隊也提到更廣泛的可靠性計畫，包括改善任務的優先序排定與流量的速率限制，避免單一批次任務或畫質升級再次在沒有預留餘裕的情況下擠壓即時內容的處理管線。
原始來源：Spotify Engineering Blog - Content Ingestion & Podcast Video Incident Report
沒有網頁工程師，LINE Planet 兩人靠 AI 做出群組視訊通話
LY Corp Tech Blog · 2026-07-21
背景
LINE 想在 LINE 官方帳號（OA）之上，替使用者加開一個群組視訊通話功能，但團隊手上沒有專職的網頁工程師。最後接下這個專案的，是LINE Planet 團隊裡的一位產品經理與一位 Android 工程師——兩人都不是網頁開發背景，卻在借助 AI 輔助開發的情況下完成了整個功能。文章標題裡「without a web engineer」指的正是這件事：不是完全不寫網頁程式碼，而是靠既有的抽象層與 AI 輔助，讓非網頁背景的人也能把網頁那塊補起來。
核心改動/規格細節
整體架構由五塊組成：使用者從 LINE OA 進入，透過 LIFF（LINE Front-end Framework）在 LINE App 內開啟 webview；webview 裡跑的是一個 React + Vite 打造的 Web App，負責畫面與商業邏輯；App Server（文章建議用 Firebase Cloud Functions）負責核發 access token；實際的視訊通話則交給 LINE Planet SDK 處理 WebRTC 媒體與全球網路基礎設施。實作上，先用 LIFF 取得使用者的 userId、displayName，向 App Server 換取 token 後，呼叫 joinConference() 加入會議；預覽畫面則用 PlanetKit 的 MediaStreamManager 避免在行動裝置上重複跳出權限請求。畫面會依參與人數動態調整成不同網格佈局，一般 2×2 網格採用 vga 解析度，邀請好友則透過 shareTargetPicker 分享房間連結。
影響範圍
文章認為這個案例之所以成立，關鍵在於 TypeScript/React 的元件模式，和 Android 慣用的 View/ViewModel 架構在概念上是相通的，讓 Android 工程師的學習曲線變得可控；而 LIFF 與 LINE Planet 已經把最困難的部分——LINE 身分驗證、WebRTC 媒體處理與全球網路基礎設施——都封裝掉了，團隊只需要專注在業務邏輯與介面上。虛擬背景等進階功能則透過 MediaPipe 實作。這說明當底層 SDK 抽象層夠完整時，產品交付不必然要綁定特定領域的專職工程師。