如何压缩HTTP响应头？
在 Velocity 2010 会议上，Google 表示标头压缩可以带来巨大收益：
Hölzle 指出网页标头的处理效率明显低下，网页标头提供有关用户 IP 地址、浏览器和其他会话数据的信息。每个网页平均会对不同资源进行 44 次调用，其中许多请求都包含重复的标头数据。 Holzle 表示，压缩标头可以使一些领先网站的页面负载提高 88%。
如何确保 Web 服务器发送的响应标头经过压缩？以今天的技术来说这可能吗？
At the Velocity 2010 conference, Google said that header compression can yield big gains:
Hölzle noted a glaring inefficiency in the handling of web page headers, which provide information about a user’s IP address, browser and other session data. The average web page makes 44 calls to different resources, with many of those requests including repetitive header data. Holzle said compressing the headers produces an 88 percent page load improvement for some leading sites.
How does one ensure that the response headers sent by the web server are compressed? Is this even possible with today's technology?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
压缩 HTTP 请求标头或响应标头不符合 HTTP 1.1 标准。
话虽如此，这里是对如何制定这样的方案的一些分析：
1）也许它们意味着您可以使用其他一些自定义 http 方案来实现这一点，例如
httpc://。我还可以声称，以 5 个为一组向同一服务器发送请求和响应也可以提高网络速度。我将此方案称为
httpBrian://。2) 如果您假设它们仅意味着 HTTP 响应标头，则在请求标头中您可以有另一个标头，该标头指定您希望响应作为不兼容的 HTTP 响应。我想这会在代理等方面出现问题。
3) 如果您假设它们仅表示部分 HTTP 响应标头，则 HTTP 服务器可以将非代理标头（除了执行请求的 http 客户端之外）不立即重要的非代理标头压缩到另一个标头中。 HTTP 请求将启用这样的功能。这很可能就是他们想要实现的目标。
Having HTTP request headers or response headers compressed is not HTTP 1.1 standards compliant.
That being said here is some analysis into how such a scheme could be made:
1) Maybe they mean you can accomplish that using some other custom http scheme, like say
httpc://.I could also make a claim that sending requests and responses to/from the same server in batches of 5 increases the speed of the web as well. I call this scheme
httpBrian://.2) If you assume they mean only HTTP response headers, in the request headers you could have another header which specifies that you want the response in as a non compliant HTTP response. I imagine this would have problems with proxies and etc. though.
3) If you assume they mean only PARTIAL HTTP response headers, then the HTTP server could put the non proxy headers that are not immediately important except to the http client performing the request compressed into another header. The HTTP request would enable such a feature. This is most likely what they are trying to accomplish.
如果基础设施通过某种类型的自定义传输协议支持标头压缩，那么它将一直被压缩，直到它被移交给不支持该功能的实体。
最后，也许我们的浏览器也会支持它。所以我认为他们正在采取积极主动的方法，在服务器端启动它并看看它能走多远。
If the infrastructure supports header compression through some type of custom transport protocol, then it would be compressed all the way until it was handed off to an entity that didn't support that feature.
In the end, perhaps even our browsers would support it. So I think they're taking a proactive approach by starting it on the server end and seeing how far it goes.
仔细阅读该段落！ Hölzle 讨论的是网页标头，而不是http 标头。所以我们讨论诸如meta标签之类的东西。好吧，看起来，尽管我被（正确地）投票了很多次，但我是第一个找到 正确来源。这是关于 Google 名为 SPDY（SPeeDY 明白吗？）的新应用层协议，该协议提供 HTTP 标头压缩。
Read the paragraph more thoroughly! Hölzle talks about web page headers not http headers. So we talk about something likemetatag and so on.Ok, it seems, even though I've been downvoted (correctly) a lot, I am the first to find the correct sources. It's about a new application layer protocol named SPDY (SPeeDY get it?) by Google, which offers HTTP header compression.