第 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 不将其作为唯一性能依赖。
可验证点
- 在浏览器开发者工具 Network/Protocol（不同浏览器显示略有差异）中，可观察请求是否使用 h3（HTTP/3）或回落到 h2/h1。
- 在同一网络条件下，对比 h3 与非 h3 的连接建立与吞吐稳定性（尤其高 RTT/丢包环境），可感知差异。
1.3 极致并发：分块流式传输（Chunked Streaming）
- 系统 MUST 将大文件逻辑拆分为多个 chunk，chunk 为上传/重试/恢复的最小单位（详见第 2 章）。
- 客户端 SHOULD 以“有限并发”传输多个 chunk（例如若干并发管道），以更接近带宽上限并降低单连接抖动影响。
- 客户端 MUST 支持断点续传：恢复时跳过已完成 chunk，仅补齐缺失 chunk，避免整文件重传（详见第 2 章）。
- 并发与分片会显著降低单请求阻塞造成的等待（包括队头等待/重传等待），但不应宣称“完全消除”任何特定网络现象； 系统目标是“降低影响并提升稳定吞吐”。
可验证点
- 在 Network 面板可观察同一时间存在多条并行上传/下载请求（chunk 并发）。
- 中断网络或刷新页面后恢复传输，可观察已完成部分不会从 0% 重来（仅补齐缺失 chunk）。
1.4 拓扑优势：Anycast 全球就近接入（边缘网络）
- 系统 SHOULD 通过 Anycast/边缘接入将用户请求路由到就近节点，从而降低 RTT 与跨洲跳数带来的延迟与抖动。
- 就近接入能提升并发分片的整体效率：RTT 更低意味着每条并发流的有效吞吐上限更高，更容易“跑满链路”。
- 节点数量与覆盖范围可能随基础设施调整而变化；对外描述应以“边缘网络覆盖/就近接入”为主，数值可作为参考而非硬承诺。
可验证点
- 通过 traceroute / 浏览器连接信息等方式，可观察连接通常落到更接近的接入点（具体方法随环境而异）。
- 跨洲对比（例如 US↔EU/JP↔US）时，RTT 的降低通常最明显。
1.5 多源并发：智能调度（Multi-Source）
- 系统 SHOULD 基于链路质量信号（吞吐、延迟、错误率等）进行动态选择，使不同 chunk 可以分配到多个更优的节点/落点， 以降低单点拥塞对整体吞吐的影响。
- 下载侧客户端 MAY 并发从多个源拉取不同 chunk，形成“多源拉取”的加速效果；当多源不可用时 MUST 自动退化为单源下载， 以保证可用性（详见第 3 章）。
- 若对外使用“AI”表述，建议将其限定为“用于调度与决策的算法系统”，并明确输入/输出与降级策略，避免模糊宣传。
可验证点
- 在下载过程中可观察来自不同源/不同连接的并发请求（取决于实现与浏览器显示能力）。
- 在拥塞或丢包时，多源并发通常能表现出更稳的吞吐；当条件不满足时会自动降级，但仍保持可用。
1.6 与后续章节的关系
- 第 2 章会把“分片、并发、幂等、断点续传”展开为可实现的流程与约束（MUST/SHOULD/MAY），解释为什么它直接决定上传速度与稳定性。
- 第 3 章会说明“并发下载、恢复与组装”，以及如何在弱网下避免重复下载造成的速度损失。
- 第 4 章仅保留与性能与可恢复性相关的最小存储说明（对象与状态分层、TTL/删除语义）。