范围请求、压缩与流式传输

从一次真实请求或故障开始

Web系统不是框架函数清单。本节围绕 范围请求、压缩与流式传输，先选一条可以回放的请求、发布或故障路径：用户从什么设备发起，经过哪些协议和组件，读写什么数据，在哪个信任与故障域内运行，最后用什么业务结果和SLO判定成功。只有边界写清，技术名词才有位置。

本节专属对象

Range允许分段获取；压缩改变表示长度；流式body需正确背压和结束语义。。请把每个对象标成客户端、网络/协议、边缘、应用、数据、平台或运维证据，并写owner、版本、生命周期和可观察量。同一个“成功”在TCP连接、HTTP响应、业务提交和用户任务四层含义不同，不能用下层绿色代替上层正确。

公式、协议或系统不变量

核心关系是：compression ratio=compressed/original。。先说明分母、单位、时间窗、并行/串行关系和成立假设，再逐项计算。若请求取消、依赖超时、消息重复、缓存过期、配置混版、权限变化或部分区域失效，应进入明确分支，不能让默认重试或最终200掩盖失败。

老师带着算完例子

原文件1000KB压到250KB，压缩后比例25%，节省75%。。这里给出了输入、中间计算和工程结论。现在只改变一个量，先预测延迟、吞吐、容量、一致性、成本或安全结果向哪个方向变化，再重新计算。方向不对时，检查单位、关键路径、缓存命中分母、fanout、重试次数、并发上限和故障独立假设。

把一次请求拆成可检查的行

围绕“范围请求、压缩与流式传输”至少写四行：第一行写请求/事件、身份、版本与deadline；第二行写每个组件的输入输出和本节不变量；第三行按“compression ratio=compressed/original。”计算关键中间量；第四行给用户可观察结果和系统证据。用“原文件1000KB压到250KB，压缩后比例25%，节省75%。”逐项代入，不允许只报最后状态码、截图或云控制台绿色。

完成正向推演后做两次反查。先从结果向后找响应、span、日志、指标、消息offset、数据库版本和源请求；再从用户输入向前重放解析、认证、路由、业务、数据、异步与返回。最后注入“对已压缩媒体重复gzip；Range偏移基于错误表示。”，确认首个偏差能被发现、隔离、降级和恢复。

落到代码和生产实验

测试206/Content-Range、不可满足范围、gzip与中途断流。。实现应输出协议字段、阶段时间、队列/池状态、版本、候选副本、数据提交点、重试/去重决定或资源使用。所有代码实验使用确定输入输出，并覆盖正常、最小、边界和失败输入；生产实验还要保存trace id、配置hash和回滚点。

复杂度、容量与边界

分析“范围请求、压缩与流式传输”主要受请求率、并发、body大小、连接/线程池、数据库扫描、缓存命中、消息积压、副本/分区、网络带宽或状态空间中的哪个量控制。小例确认语义，压测说明容量，故障注入说明边界。把结论接回浏览器—边缘—服务—数据—平台—运维的完整链路，不能单独优化某层却把瓶颈推给下一层。

本节报告至少保留请求/事件样本、代码与配置版本、环境拓扑、参数、中间证据、最终结果和运行成本。手算“原文件1000KB压到250KB，压缩后比例25%，节省75%。”校验监控与库配置，再以“对已压缩媒体重复gzip；Range偏移基于错误表示。”做负测。库、框架和云服务可以使用，但必须明确它提供的保证和仍由应用承担的责任。

最短失败反例

本节边界是：对已压缩媒体重复gzip；Range偏移基于错误表示。。构造最小请求、并发历史、数据或故障使问题出现，指出它破坏的协议、契约或不变量，并给可执行修正、回归测试、监控和回滚办法。只写“加强安全”“增加重试”或“扩容”不算修复。

在线练习与闭卷自检

本节绑定单选、多选、计算和严格系统题；章节另有真实Python协议/运维算法实验，每题至少四组测试。闭卷重建五项：对象“Range允许分段获取；压缩改变表示长度；流式body需正确背压和结束语义。”；核心关系“compression ratio=compressed/original。”；算完例题“原文件1000KB压到250KB，压缩后比例25%，节省75%。”；实验步骤；失败边界“对已压缩媒体重复gzip；Range偏移基于错误表示。”。五项缺一项，就还没有真正掌握《范围请求、压缩与流式传输》。