如何确定http响应头的大小？答案

【问题标题】：How to determine the size of a http response header?如何确定http响应头的大小？
【发布时间】：2026-02-16 13:00:01
【问题描述】：

我想确定响应标头的大小。我想我可以通过从使用 Chrome DevTools 导出的组合大小中减去响应主体的大小来做到这一点。

来自Chrome DevTools：

Size 是响应标头的组合大小（通常是几个百字节）加上响应正文，由服务器提供。

.js 文件的未压缩大小为 375 字节，由 Content 给出。 DevTools 给出的组合 size 为 701 字节。

另外，我有以下来自Apache access log的信息来记录同一个.js文件的传输：

%b = 273 bytes (Size of response in bytes, excluding HTTP headers)
%O = 842 bytes (Bytes sent, including headers, cannot be zero)

我应该使用%0 - %b、%0 - Content、Size - %b 还是Size - Content？另外，谁能告诉我为什么%0和Size有区别？

【问题讨论】：

标签： apache http-headers size google-chrome-devtools

【解决方案1】：

我不知道你需要什么工具，但它很容易使用 curl 实用程序在 shell 中计数，假设你有以下标题：

root@sup ~# curl -I  http://domain.com
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Thu, 05 Dec 2013 19:40:40 GMT
Content-Type: text/html
Content-Length: 199
Last-Modified: Sun, 15 Sep 2013 17:06:37 GMT
Connection: keep-alive
Accept-Ranges: bytes

数一数：

root@sup ~# curl -s -w \%{size_header} -o /dev/null http://domain.com 
215

结果：215 字节。

【讨论】：

上面的js文件返回0。似乎它在 https 上不起作用，尽管它在 http 上返回值 261。在任何情况下，从 curl 提供的 http 响应标头的大小都不会与从 apache 服务器提供给 Internet 上的用户的大小相同。
对于 https curl 有 -k 键：root@sup ~# curl -sk -w \%{size_header} -o /dev/null https://dom.net201
谢谢，它现在在 https 上返回 261。但是，在我原帖的最后一段中，你还没有回答我的两个问题。
哦，对不起，我误会了。所以我只是测试了它：在开发工具中：大小 - 显示标题+内容的总和内容 - 仅显示内容的大小，通过 curl 可以看到相同：# curl -s -w \%{size_header}:\%{size_download} -o /dev/null http://dom.com 193:943 至于 Apache 日志中的大小差异， - 看起来就像它将附加信息附加到标头一样，以查看您应该在服务器大小上使用tcpdump 实用程序来捕获该请求数据包并查看实际大小。
您可以根据客户端获得不同的响应标头，即浏览器可以请求影响响应标头的功能（gzip 压缩、保持活动等），因此您不能假设使用browser 和 curl 将为您提供与服务器完全相同的标头。

【解决方案2】：

Apache 中的 %O 日志记录包括任何 SSL 开销，因此您实际上在该图中具有 SSL-bytes + header_bytes +compressed_content，而 Chrome 的 Size 似乎只有header_bytes + 压缩内容。更难的是，Chrome 的 Content 是 未压缩内容 的大小。

根据我在网络上说的你的数据，你有 261 字节的标头 + 273 字节的压缩内容 + 308 字节的 SSL 字节，而 Chrome 只告诉你内容的未压缩大小使得无法确定大小仅来自 Chrome 中可用的数字的标题。

【讨论】：

如果你说的没错，那么 Chrome 的大小应该是261 (header) + 273 (compressed content) = 534。但它是701。
抱歉，我错过了 Chrome 的内容为 701 的信息（在多个地方有太多不同组合的数字太多 - 我完全忘记了它们）。我无法准确解释 Chrome 是如何计算这些东西的，但从我自己的实验中我可以清楚地看到，当使用 HTTP 压缩时，Size 可能比 Content 小很多，所以你只需不能减去这两个值，否则您会收到错误，具体取决于内容的压缩程度。
基于这些讨论，我们可以排除 %O（包括 SSL 数据）和 Chrome 的 Content（未压缩）。从给定的变量中，我认为最接近的结果应该是Size - %b，尽管在您的情况下结果（428）似乎有点大。您可以通过将 Chrome 的 DevTools 中看到的响应标头源复制粘贴到文件中来验证这一点，然后查看您获得的文件有多大。