亚洲情色快播：字节范围如何断点续传

适用范围与例子性质

依据2026年10月25日核对的RFC 9110（2022）及MDN文档，讨论普通HTTP单一字节范围，不描述任何历史产品内部实现。16字节样本与响应字段为本站教学构造，没有执行网络实测，不涉及实际影片或下载地址。

字节范围不是播放时间

RFC 9110第14节定义的bytes范围按表示的数据字节计数，从0开始，末端也包含在内。它不直接表示第几秒或第几帧；媒体时间与文件位置如何对应，需要另有媒体索引。不能把进度条拖到一半等同于请求文件后半所有字节。

把16字节例子逐个数清

图中假设完整表示长度为16字节，位置为0到15，已可靠保存0到5共6字节。下一段从6开始至15，总数为15−6＋1＝10。六字节前缀与十字节后缀相接才是16字节；若从5开始追加，会重复一个位置。

• 请求写成Range: bytes=6-，在本题假设下响应范围为Content-Range: bytes 6-15/16。另一个写法bytes=-6表示最后6字节，对应10到15。两种短写法的连字符位置不同，不能凭肉眼把它们当同一个起点。

先读响应状态，再决定如何存放

按MDN范围请求指南，206表示部分响应，应核对返回范围；200可能是完整响应，不能继续按预期后缀追加；416表示请求范围无法满足，需核对长度和起点。收到响应并不等于已验证整个文件完整可用。

• 在原创样本中，若请求从位置16开始，已经越过最后位置15，应回查是否其实已有完整文件或本地记录过时。不要把范围问题一律解释成网络中断，更不要反复发相同请求期待它自动变成有效范围。

同一路径的文件也可能已变

假设旧版本前6字节为ABCDEF，网站后来把同一路径内容更换，新版本前缀是UVWXYZ。即使新后缀的长度仍为10，也不能直接接在旧ABCDEF之后；长度凑成16并不保证它属于某个完整版本。这个样本只演示混合版本风险，不使用真实文件。

• If-Range可让范围请求附带验证条件：匹配时处理范围，不匹配则改取完整表示。按RFC和MDN的该字段说明，使用ETag时不能使用W/开头的弱标签。具体客户端如何保存、核对和恢复，应依据其实现，不能只看到一个续传按钮便推断已正确处理。

为什么收到200不能就地追加

用纸条练习最直观：已有六格旧前缀，新的完整纸条有十六格；把整条接在后面会得到二十二格，显然不再是题设的十六格文件。正确行为应由客户端按完整响应策略重新保存或替换工作副本，保留必要错误记录。

• 因此排查时至少记录请求范围、响应状态、返回范围、表示验证信息和保存方式。展示给他人的记录应去掉不必要的访问令牌或私密路径，本篇只使用自制字符串说明逻辑。

限定这次检查能证明什么

核对区间连续与总长度，只解决传输拼接的一部分。内容是否能解码、来源是否可信、是否有权使用，以及片长如何对应字节位置，需要另外检查。本文的一手文档解释协议；原创图和算例不证明某个具体平台使用了该机制。

把方法变成行动

1. 先记录完整表示长度、已保存范围与版本验证信息。
2. 计算下一起点，逐个检查端点是否包含，区分前缀与后缀短写法。
3. 读取真实响应状态和Content-Range，不假定服务器必按请求返回。
4. 确认同一表示后再按客户端流程合并；完整响应不得盲目追加。
5. 另行检查完整性和可用性，并保存本次范围与限制。

延伸阅读与支持范围

以下链接提供相关领域资料。本站的问题拆解、解释和练习为编辑设计，不表示外部机构认可本站全部内容。

关于这个问题的问答

对应学习卡片

继续阅读