压缩Http头 [英] Compacting Http Headers

问题描述

它发生了这样的情况，我的实际数据是HTTP请求标头大小的1/4（以字节为单位）。

是否有减少HTTP标头大小或其他相关方式的方法处理这种情况？

我通过GPRS将数据从移动设备发送到服务器，并且不希望承受巨大的请求数据包，这些数据包会占用我的$$和带宽。

解决方案

我从来没有通过砍掉标题来优化网站性能。也就是说，大部分问题都与此有关：

1. 大量不需要的 GET请求。这通常是由于服务器没有将适当的过期和缓存头发送回客户端。有时它是一个写得不好的应用程序。


2. 打开大量TCP连接。如果能够保持连接处于活动状态并重新使用它以服务多个请求，性能会得到改善。我不确定移动客户端是否支持保持活动状态。


3. 压缩的使用，或者缺少它。如果有什么可以减少费用的话，那就是压缩的用法。但是，我不确定移动客户端能够支持压缩。顺便说一句，通常会对响应进行压缩，而不是对请求进行压缩（我知道的所有浏览器都不会压缩请求，尽管HTTP规范允许）。
   

如果您在＃3之后仍然需要更好的性能，那么您的应用程序需要进行某种形式的性能设计审查。

Its so happening that my actual data is 1/4 that of the HTTP request header size in bytes.
Is there a way to cut down on the size on the HTTP headers or any other relevant way to deal with this situation?
I am sending data from a mobile device over GPRS to the server and dont want to be burdened with huge request packets that will eat into my $$ and also bandwidth.

解决方案

I've never had to optimize site performance by chopping off headers. That said, most of the issues had to do with:

1. Large number of unwanted GET requests. This was often due to the server not sending the appropriate expiry and caching headers back to the client. Sometimes it is a poorly written application.
2. Large number of TCP connections being opened. Performance improves when you are able to keep the connection alive and reuse it to serve multiple requests. I'm unsure on whether mobile clients support keep alive.
3. Usage of compression, or the lack of it. If there is anything that can cut down on expenses, it is the usage of compression. However, I'm not so sure of mobile clients being able to support compression. By the way, one normally does compression for responses, and not for requests (all browsers that I know of, never compress the request although the HTTP spec allows for it).

If you still need better performance after #3, your application needs some form of performance design review.

这篇关于压缩Http头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！