第 1 章 為什麼更快：四大關鍵機制
FileBolt 的速度優勢來自傳輸層、平行分塊、全球拓撲與多來源排程的組合。 本章以可稽核的方式說明：哪些機制能提高峰值吞吐量，哪些機制能在封包遺失或網路切換時提升穩定性與可復原性。
1.1 設計目標（速度面向）
- 目標 A：逼近頻寬上限。在一般條件下，盡量把可用頻寬跑滿。
- 目標 B：穩定的吞吐量。在封包遺失、抖動、網路切換與高跨區域 RTT 下，維持可用的吞吐量，而不是驟然崩潰。
- 目標 C：失敗可復原。發生錯誤時，把代價限制在只需重傳少量資料，避免從 0% 重新開始。
1.2 傳輸層最佳化：HTTP/3（QUIC）
- 用戶端與邊緣入口 SHOULD 優先採用 HTTP/3（QUIC）。當瀏覽器、網路或中間設備不支援時，系統 MUST 自動回退到 HTTP/2／HTTP/1.1， 以維持可用性。
- 在封包遺失的情況下，QUIC 的傳輸與壅塞控制通常能降低佇列前端阻塞對端到端吞吐量的影響，提升穩定性（實際結果取決於網路狀況）。
- 0-RTT／更快的握手路徑是特定條件下的工作階段恢復能力：條件符合時系統 MAY 從中受益，但 MUST NOT 把它們當成唯一的效能手段。
如何驗證
- 在瀏覽器開發者工具中（例如 Network／Protocol；介面因瀏覽器而異），您可以觀察請求是使用 h3（HTTP/3），還是回退到 h2／h1。
- 在相同的網路條件下，比較 h3 與非 h3 的連線建立時間與吞吐量穩定性（尤其是在高 RTT／封包遺失時），差異可能相當明顯。
1.3 極致並行：分塊串流（Chunked Streaming）
- 系統 MUST 在邏輯上把大型檔案切分為多個區塊；每個區塊是上傳／重試／復原的最小單位（見第 2 章）。
- 用戶端 SHOULD 以受限的並行度（例如數條平行管線）傳輸多個區塊，以更接近頻寬上限，並降低對單一連線抖動的敏感度。
- 用戶端 MUST 支援可續傳的傳輸：復原時跳過已完成的區塊，只取得缺少的區塊，避免整個檔案重新傳輸（見第 2 章）。
- 並行與分塊能大幅減少單一請求阻塞造成的等待（包括佇列前端阻塞與重傳等待），但 SHOULD NOT 宣稱「完全消除」任何特定的網路現象； 目標是降低影響並提高吞吐量的穩定性。
如何驗證
- 在 Network 面板中，您可以同時看到多個平行的上傳／下載請求（區塊並行）。
- 斷開網路或重新整理頁面後，續傳不應從 0% 重新開始（只會補完缺少的區塊）。
1.4 拓撲優勢：Anycast 就近邊緣存取（邊緣網路）
- 系統 SHOULD 透過 Anycast／邊緣入口，把使用者請求路由到最近的節點，以降低 RTT，以及跨區域跳數所造成的延遲與抖動。
- 就近邊緣存取能提升平行分塊的整體效率：較低的 RTT 通常會提高每條並行連線的有效吞吐量上限，因此更容易把頻寬跑滿。
- 邊緣覆蓋範圍與節點數量可能隨基礎設施演進而變動；對外建議以「邊緣覆蓋／就近入口」來描述，並把數字視為參考，而非硬性保證。
如何驗證
- 使用 traceroute 或瀏覽器的連線資訊，通常可以觀察到連線終止於更近的入口（方法依環境而異）。
- 在跨區域比較中（例如美國↔歐洲／日本↔美國），RTT 的下降通常最為明顯。
1.5 多來源並行：智慧排程（Multi-Source）
- 系統 SHOULD 根據鏈路品質訊號（吞吐量、延遲、錯誤率等）動態選擇，使不同的區塊能分配到多個較佳的節點／位置， 降低單點壅塞對整體吞吐量的影響。
- 下載時，用戶端 MAY 同時從多個來源取得不同區塊，達到「多來源拉取」的加速效果；當多來源無法使用時，MUST 自動降級為單一來源下載， 以維持可用性（見第 3 章）。
- 如果要以「AI」作為行銷說法，最好把它定位為負責排程與決策的演算法系統，並清楚定義輸入／輸出與降級行為，以避免含糊不清的宣稱。
如何驗證
- 下載期間，您可能會觀察到來自不同來源／連線的並行請求（視實作方式與瀏覽器的可見度而定）。
- 在壅塞或封包遺失時，多來源並行通常能提供更平穩的吞吐量；條件不符時會自動降級，但仍可使用。
1.6 與後續章節的對應
- 第 2 章把「分塊、並行、冪等與可續傳上傳」展開為可實作的流程與限制（MUST／SHOULD／MAY），並說明它們為何直接決定上傳速度與穩定性。
- 第 3 章說明「平行下載、復原與重組」，以及如何避免弱網路下因重複下載而損失速度。
- 第 4 章僅保留與效能和可復原性相關的最小儲存模型（物件層與狀態層、TTL／刪除語意）。