压缩 Http 标头答案

【问题标题】：Compacting Http Headers压缩 Http 标头
【发布时间】：2009-09-07 19:53:49
【问题描述】：

我的实际数据是 HTTP 请求标头大小（以字节为单位）的 1/4。
有没有办法减少 HTTP 标头的大小或任何其他相关的方法来处理这种情况？
我正在通过 GPRS 从移动设备向服务器发送数据，并且不想承受大量请求数据包的负担，这些数据包会占用我的 $$ 和带宽。

【问题讨论】：

+1 好问题，在你描述的环境中
您能否扩展“我正在从移动设备发送数据”？听起来您正在使用一些定制的应用程序（也是因为 java 和 j2me 标签）？如果是这样，如果您确定您的服务器端应用程序不需要它们，您也许可以摆脱像 Accept-* 甚至 Host 这样的请求标头。您可以使用 User-Agent 发送一些版本信息，以防您的服务器在未来版本中需要更多详细信息。响应标头也可能受到限制。那么：客户端和服务器都在您的控制之下吗？ HTTP 规范对您来说有多重要？
@KLE，“在你描述的环境中”对不起，我不明白这个说法？
@Arjan：是的，客户端和服务器都在我的控制之下。 HTTP 规范，我想只要服务器和客户端通信正常，就没有那么重要了。

【解决方案1】：

嗯，是什么占据了您的大部分标题？例如，Stack Overflow 最近将大部分静态内容移至另一个域，这样 SO cookie 就不会包含在对静态内容的请求中（无论如何也不会使用 cookie）。

但是，如果大多数标头只是浏览器将始终发送的内容（用户代理等），那么您无能为力。

【讨论】：

我在这里 (stackoverflow.com/questions/1378476/…) 提出了一个关于 HTTP 请求标头大小的问题。这让我震惊！我的数据肯定会比那篇文章中提到的数字低得多
@Kevin，没有什么令人震惊的。服务器需要该 tcpdump 提取中的大多数请求标头，以决定如何准备响应。
@Vineet，有什么办法可以解决吗？还是头上的行李是不可避免的。
@Kevin，这是不可避免的。我还没有看你的应用程序。但是从您在 SO 提出的上一个问题来看，您应该考虑使用 Fiddler 来查看问题所在。如果 GET 请求过多，我不会感到惊讶，在这种情况下，解决方案不是减少标头大小，而是减少此类 GET 的数量，并删除任何不需要发送的信息。
@Kevin，neXpert 性能优化工具可以与 Fiddler 一起安装，让您快速报告问题所在。我将其称为性能冒烟测试。您可以在 neXpert 博客@blogs.msdn.com/nexpert 中找到更多详细信息

【解决方案2】：

我从来不需要通过删除标题来优化网站性能。也就是说，大多数问题与：

大量不需要的 GET 请求。这通常是由于服务器没有将适当的到期和缓存标头发送回客户端。有时它是一个写得很糟糕的应用程序。
大量 TCP 连接正在打开。当您能够保持连接活动并重用它来服务多个请求时，性能会提高。我不确定移动客户端是否支持保活。
使用压缩或没有压缩。如果有什么可以减少开支的，那就是压缩的使用。但是，我不太确定移动客户端是否能够支持压缩。顺便说一句，通常对响应进行压缩，而不是对请求进行压缩（我所知道的所有浏览器都从不压缩请求，尽管 HTTP 规范允许这样做）。

如果您在 #3 之后仍需要更好的性能，则您的应用程序需要某种形式的性能设计审查。

【讨论】：

【解决方案3】：

我将标题视为“架构”，即：“根据要求，它们的确切内容因应用程序而异”。

获得确切的当前列表后，请使用this post 中提供的链接，
你可以看到你需要哪些，并避免发送其他的。

谁知道这是否会产生重大影响，但至少您可以放心，您在该主题上已尽力而为。

【讨论】：

【解决方案4】：

好吧，这可能不受欢迎和/或实际上无法回答您的问题，但您是否考虑过您的数据粒度？

一旦您尽可能地减少 HTTP 标头，我怀疑您仍然希望进一步降低标头/数据比率。显而易见的方法是在每个 http 请求中发送/接收多个数据项。

在客户端或服务器端增加一层逻辑（或更改您的数据模型）将允许您请求更大块的数据，基于测量您在请求时可能需要的其他数据单项。

重点是在每个请求中传输更多数据，以减少请求数量。带宽（和客户端存储）的浪费 - 来自传输您实际上不需要的数据 - 最终可能比 HTTP 标头足迹更容易接受。

【讨论】：