第 1 章 為什麼它更快：四個關鍵機制
FileBolt 的速度優勢來自於傳輸、平行分塊、全域拓撲和多來源調度的組合。 本章以可審計的方式解釋了哪些機制可以提高峰值吞吐量，哪些機制可以提高丟包或網路切換下的穩定性和可恢復性。
1.1 設計目標（速度視圖）
- 目標 A：接近頻寬上限。 在典型條件下，嘗試使可用頻寬飽和。
- 目標B：穩定的吞吐量。 在遺失、抖動、網路切換和高跨區域 RTT 的情況下保持可用吞吐量，而不是突然崩潰。
- 目標 C：可恢復的故障。 當發生錯誤時，將成本限制為僅重新傳輸少量數據，避免從 0% 重新啟動。
1.2 傳輸層優化：HTTP/3（QUIC）
- 客戶端和邊緣入口應該首選 HTTP/3 (QUIC)。當瀏覽器、網路或中間件不支援時，系統必須自動回退到 HTTP/2/HTTP/1.1 以保持可用性。
- 在丟包情況下，QUIC的傳輸和擁塞控制往往可以減少隊頭阻塞對端到端吞吐量的影響，並提高穩定性（結果取決於網路狀況）。
- 0-RTT/更快的握手路徑是特定條件下的會話恢復功能：系統在滿足條件時可能會受益，但不得依賴它們作為唯一的效能槓桿。
如何驗證
- 在瀏覽器 DevTools（例如網頁/協定；UI 會因瀏覽器而異）中，您可以觀察請求是使用 h3 (HTTP/3) 還是回退到 h2/h1。
- 在相同的網路條件下，比較 h3 與非 h3 連線設定和吞吐量穩定性（特別是在高 RTT/遺失情況下）可能會有明顯不同。
1.3 極限並發：分塊流（Chunked Streaming）
- 系統必須在邏輯上將大檔案分割成多個區塊；每個區塊是上傳/重試/恢復的最小單位（請參閱第2章）。
- 客戶端應該以有限的並發性（例如，幾個並行管道）傳輸多個區塊，以接近頻寬上限並降低對單連接抖動的敏感度。
- 客戶端必須支援可恢復傳輸：在復原時，跳過已完成的區塊並僅取得遺失的區塊，避免整個檔案重新傳輸（請參閱第 2 章）。
- 並發和分塊顯著減少了單一請求阻塞造成的等待（包括隊頭等待和重傳等待），但你不應該聲稱「完全消除」任何特定的網路現象； 目標是減少影響並提高穩定的吞吐量。
如何驗證
- 在「網路」面板中，您可以同時觀察多個並行上傳/下載請求（區塊並發）。
- 斷開網路或重新整理頁面後，恢復傳輸不應從 0% 重新開始（僅完成遺失的區塊）。
1.4 拓樸優勢：Anycast 最近邊緣接取（邊緣網路）
- 系統應該透過任播/邊緣入口將使用者請求路由到最近的節點，以減少 RTT 和跨區域跳躍引起的延遲/抖動。
- 最近邊緣存取提高了平行分塊的整體效率：較低的 RTT 通常會提高每個同時流的有效吞吐量上限，從而更容易使鏈路飽和。
- 邊緣覆蓋和位置計數可能會隨著基礎設施的發展而變化；在外部，將此描述為“邊緣覆蓋/最近入口”，並將數字視為指導而不是硬性保證。
如何驗證
- 使用追蹤路由或瀏覽器連接訊息，您通常可以觀察到連接在更近的入口處終止（方法因環境而異）。
- 在跨區域比較中（例如，美國↔歐盟/日本↔美國），RTT 的降低通常最為明顯。
1.5 多源並發：智慧調度（Multi-Source）
- 系統應該根據鏈路品質訊號（吞吐量、延遲、錯誤率等）做出動態選擇，因此可以將不同的區塊分配給多個更好的節點/位置， 減少單點擁塞對整體吞吐量的影響。
- 下載時，用戶端可以同時從多個來源取得不同的區塊，以實現「多源拉取」加速效果；當多源不可用時，它必須自動降級為單源下載 以保持可用性（請參閱第 3 章）。
- 如果你將其作為「人工智慧」進行行銷，最好將其建構成用於調度和決策的演算法系統，並明確定義輸入/輸出和退化行為，以避免模糊的聲明。
如何驗證
- 在下載過程中，您可能會觀察到來自不同來源/連線的並發請求（取決於實作和瀏覽器可見性）。
- 在擁塞或遺失的情況下，多源並發通常可以提供更穩定的吞吐量；當不滿足條件時，它將自動降級但仍然可用。
1.6 這如何映射到後續章節
- 第 2 章將「分塊、並發、冪等性和可斷點上傳」擴展為可實現的流程和約束（必須/應該/可以），並解釋了為什麼它們直接決定上傳速度和穩定性。
- 第3章解釋了“並行下載、恢復和重組”，以及如何避免在弱網路下冗餘下載造成的速度損失。
- 第 4 章僅保留與效能和可恢復性相關的最小儲存模型（物件與狀態層、TTL/刪除語意）。