带有 gzip 支持的预冲洗头标签 [英] Pre flush head tag with gzip support

查看:27
本文介绍了带有 gzip 支持的预冲洗头标签的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

http://developer.yahoo.com/performance/rules.html

在那里,最好预先刷新 head 标签.

There it is given it is good to preflush the head tag .

但是我有一个问题,它在使用 gzip 时会有帮助吗?(我正在使用 apache2).我认为完整的文档将被一次性压缩,然后发送给客户.

But I have a question will it help while using gzip ? (I am using apache2). I think full document will get gziped at one shot and then send to the client.

或者是否也可以使用 gzip 以及预刷新 head 标签

or is it also possible to have gzip as well as pre-flush the head tag

推荐答案

已编辑

这个问题的原始版本表明我们正在处理 HTTP 标头,而不是 HTML 文档中的 <head> 部分.我将在下面留下我的原始答案,但它实际上与这个特定问题无关.

The original version of this question suggested we were dealing with HTTP headers rather than the <head> section on an HTML document. I will leave my original answer below, but it actually has no relevance to this specific question.

要回答有关预先刷新文档的 部分的问题 - 虽然可以与 gzip 结合使用,但如果没有更细粒度的控制,这可能是不可能的超过 Apache 提供的 gzip 进程.可以将 gzipped 流分解为可以自行解压缩的块(参见此) 但如果有一种方法可以将 Apache 的 gzip 实现控制到这种程度,那么我不知道.

To answer the question about pre-flushing the <head> section of a document - while it would be possible to do this in combination with gzip, it is probably not possible without more granular control over the gzip process than Apache affords. It is possible to break a gzipped stream into chunks that can be decompressed on their own (see this) but if there is a way to control Apache's gzip implementation to such a degree then I am not aware of it.

这样做可能会降低 gzip 的效率,使压缩后的大小变大,并且只有在文档的 特别大时才值得这样做,例如,大于10KB(这是我通过阅读有关 gzip 在引擎盖下的工作原理而得出的一个有点随意的值,绝对被视为福音).

Doing so would likely decrease the efficacy of the gzip, making the compressed size larger, and would only be worth doing when the <head> of a document was particularly large, say, greater than 10KB (this is a somewhat arbitrary value I arrived at by reading about how gzip works under the bonnet, and should definitely not be taken as gospel).

与 HTTP 标头相关的原始答案:

Original answer, relating to the HTTP headers:

纯粹从 HTTP 协议的角度来看,而不是您将如何在基于 Apache 的服务器上实现它,我看不出为什么您不能预先刷新标头并使用 gzip 来压缩正文.请记住,标题从不 gzip 压缩(如果是,客户端如何知道它们已经压缩过?),内容的传输编码应该不会影响您何时发送标题.

Purely from the viewpoint of the HTTP protocol, rather than exactly how you would implement it on an Apache based server, I can't see any reason why you can't preflush the headers and also use gzip to compress the body. Keeping in mind that fact that the headers are never gzipped (if they were, how would the client know they had been?), the transfer encoding of the content should have no effect on when you send the headers.

不过,有几点需要牢记:

There are, however a couple of things to keep in mind:

  • 一旦发送了标头,您就无法改变对传输编码的看法.因此,如果您发送标明正文将被 gzip 压缩的标头,然后意识到您的正文只有 4 个字节,您仍然必须对其进行 gzip,这实际上会增加正文的大小.这可能不会成为问题,除非您省略了 Content-Length: 标头,虽然可能,这是不好的做法,因为这意味着您不能使用持久连接.这就引出了下一点......
  • 您不能在此场景中发送 Content-Length: 标头.这是因为在压缩之前您不知道正文的大小,到那时它已准备好发送,因此您实际上(从服务器的角度来看)并没有预先刷新标头,即使您在开始发送正文之前,请单独发送它们.
  • 如果压缩消息的正文需要很长时间(慢速/重载服务器、非常大的正文等),并且在发送标头之后才开始压缩,则有客户端可能会等待响应的其余部分超时的风险.这完全取决于客户端,但是有太多的 HTTP 客户端实现,不能完全排除这种可能性.
  • Once the headers have been sent, you can't change your mind about the transfer encoding. So if you send the headers which state that the body will be gzipped, then realise that your body is only 4 bytes, your would still have to gzip it anyway, which would actually increase the size of the body. This probably wouldn't be a problem unless you were omitting the Content-Length: header which while possible, is bad practice as it means you cannot use persistent connections. This leads on to the next point...
  • You cannot send a Content-Length: header in this secenario. This is because you don't know what the size of the body is until you have compressed it, by which time it is ready to send, so you are not really (from the server's point of view) preflushing the headers, even if you do send them seperately before you start to send the body.
  • If it takes you a long time time to compress the body of the message (slow/heavily loaded server, very large body etc etc), and you don't start the compression until after you have sent the headers, there is a risk the client may time out waiting for the rest of the response. This depends entirely on the client, but the are so many HTTP client implementations out there that this possibility cannot be totally discounted.

简而言之,是的,有可能做到,但没有包罗万象的是,做"或不,不要做"的答案——您是否会这样做取决于每个请求和其响应的性质.

In short, yes it is possible to do it, but there is no catch-all, "Yes, do it" or "No, don't do it" answer - whether you would do it depends on each request and the nature of it's response.

这篇关于带有 gzip 支持的预冲洗头标签的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆