网站文本有没有启用压缩:用 curl 对照响应头与实际下载量

2026-10-23 / 0 评论 / 2 阅读

网站文本有没有启用压缩:用 curl 对照响应头与实际下载量 教程示意图

适用场景

本文整理日期为 2026-10-23,适用于有权检查的网站或测试环境。你部署了一份较大的样式表、脚本或文本页面,希望确认客户端是否真正收到了压缩响应,而不是仅凭服务器配置中出现压缩选项就判定成功。

本教程在 Linux 的 Bash 终端操作,使用 curl 发出少量只读请求。建议选择内容稳定、无需登录、没有自动跳转的文本资源。图片、压缩包和内容随请求变化的页面,不适合用作第一轮对照样本。

原理:请求表达能力,响应说明实际结果

HTTP 客户端通过 Accept-Encoding 请求头表达能够接受的内容编码,服务器再选择是否压缩以及使用何种编码。Content-Encoding 响应头说明正文采用的编码,Content-Type 则描述内容类型,两者不能混为一谈。

IETF 的 HTTP 语义标准定义了这些字段,也定义了 Vary 如何指出影响响应选择的请求字段。对按照编码协商返回不同版本的可缓存资源,需要检查缓存是否正确区分请求,否则可能把压缩版本错误地交给不支持它的客户端。

curl 的压缩选项还会自动解压正文。因此,保存到本地的文本可能已经恢复原始大小,而响应头仍然保留服务器发送的编码信息。这是判断压缩效果时最容易忽略的一点,具体行为见 curl 官方手册。

准备工作

先查看本机版本和编译能力:

curl --version

查看输出是否包含对应的解压支持。不同系统的软件包可能支持不同算法,不能仅凭版本号推断全部能力。准备一个新的空目录,下面会创建响应头和正文文件,同名文件会被覆盖。

通过交互输入设置资源地址,避免把示例域名误当成你的目标:

read -r -p '请输入获准检查的 HTTPS 文本资源地址:' resource_url

resource_url 保存完整 HTTPS 地址。应使用公开的静态文本文件,不要在地址中附带登录令牌、签名参数或其他敏感信息。

分步骤操作

第一步:请求不压缩的版本

curl --silent --show-error --max-time 30 \
  --header 'Accept-Encoding: identity' \
  --dump-header identity.headers \
  --output identity.body \
  --write-out '状态=%{http_code} 下载字节=%{size_download}\n' \
  "$resource_url"

identity 表示希望取得不使用内容压缩的表示。命令把响应头和正文分开保存,并显示 HTTP 状态和正文下载量。三十秒上限用于避免请求无限等待。先检查状态是否为预期的成功状态;错误页即使很小,也不能拿来证明业务资源压缩良好。

第二步:允许 curl 协商压缩

curl --silent --show-error --max-time 30 \
  --compressed \
  --dump-header compressed.headers \
  --output compressed.body \
  --write-out '状态=%{http_code} 下载字节=%{size_download}\n' \
  "$resource_url"

这次 curl 会请求自己能够处理的编码,并在收到受支持的压缩正文后自动解压。选项表达的是客户端能力,不能强迫服务器一定压缩。记录两次显示的下载字节数,作为后续比较依据。

第三步:检查响应头

cat identity.headers
cat compressed.headers

重点查看状态、内容类型、内容编码、缓存变化字段和资源校验标记。压缩请求中出现 gzip、br 等内容编码,才是服务器选择对应编码的直接线索;响应头名称不区分大小写。

如果存在内容长度字段,它通常描述编码后表示的长度。没有这个字段也不代表没有压缩,因为协议和传输方式可能不要求提前提供正文长度。

第四步:比较解压后的内容

wc -c identity.body compressed.body
cmp identity.body compressed.body

字节统计显示本地保存文件的大小。比较命令在两文件相同时通常不输出内容,并返回零。如果资源稳定、两次均成功,解压后的正文相同而压缩请求的下载量更小,就形成了比较完整的验证证据。

验证方法

把地址、检查时间、两次 HTTP 状态、内容编码和下载量记录在一起。节省比例可按未压缩下载量减去压缩下载量,再除以未压缩下载量计算;不要把本地解压文件大小代入压缩下载量。

可再交换请求顺序复查一次,观察是否存在缓存预热或资源更新影响。少量重复即可,不需要高频请求。若两次正文不同,先核实资源是否更新、是否返回错误页,不能直接得出压缩损坏的结论。

常见错误

只请求响应头而不下载正文,无法验证实际下载量。看到传输分块字段,也不能证明内容经过压缩。下载量较小还可能来自空正文、重定向页面或错误响应,所以状态与内容必须同时检查。

短文本可能低于服务器压缩阈值,已经压缩的媒体也可能不再压缩。经过内容分发网络时,结果只代表当前访问路径,不能直接推断源站配置。普通请求不使用浏览器缓存,但中间缓存仍可能影响结果。

安全与回退

保持 HTTPS 证书校验,不要为了完成检查而关闭验证。不要针对需要身份信息的响应随意开启压缩;生产配置调整应单独评估业务和缓存影响。

本教程只生成本地检查文件,不更改服务器。完成后可通过文件管理器确认并删除这些文件。如果随后修改了压缩配置,应保留修改前版本;出现异常时恢复配置,再按相同流程重新核验。

参考资料与转载说明

本文依据上述公开资料进行中文原创整理,不是逐句翻译,也不替代厂商手册。操作前请核对自己的版本、型号和备份。

评论一下?

OωO
取消