带有gzip支持的预冲头标签

时间:2011-09-09 09:45:22

标签: http apache2 gzip

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

有人预先给头标签预先冲洗是好的。

但是我在使用gzip时有一个问题吗? (我正在使用apache2)。 我认为完整的文档将一次性gziped然后发送给客户端。

或是否也可以使用gzip以及预先刷新头标记

1 个答案:

答案 0 :(得分:1)

<强> EDITED

此问题的原始版本建议我们处理HTTP标头而不是HTML文档上的<head>部分。我将在下面留下我的原始答案,但它实际上与这个具体问题无关。

要回答有关预先刷新文档的<head>部分的问题 - 虽然可以与gzip结合使用,但如果没有比Apache更精细的gzip进程控制可能是不可能的得到。可以将一个压缩的流分解为可以自己解压缩的块(see this),但是如果有一种方法可以将Apache的gzip实现控制到这种程度,那么我就不知道了。

这样做可能会降低gzip的效率,使压缩的大小更大,并且只有当文档的<head>特别大(例如,大于10KB)时才值得做(这有点通过阅读关于gzip如何在引擎盖下工作而得到的任意值,并且肯定被视为福音书。)


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

纯粹从HTTP协议的角度来看,而不是在基于Apache的服务器上如何实现它,我看不出任何理由为什么你不能预先冲洗标头并使用gzip来压缩主体。请记住,标题从不 gzip(如果它们是,客户端如何知道它们是什么?)这一事实,内容的传输编码应该对发送标题时没有影响

但有几点要记住:

  • 发送标题后,您无法改变对传输编码的看法。因此,如果你发送标题表明身体将被gzip压缩,然后意识到你的身体只有4个字节,你仍然需要gzip它,这实际上会增加身体的大小。这可能不会成为问题,除非您省略Content-Length:标题,尽管这可能是不好的做法,因为这意味着您无法使用持久连接。这导致了下一点......
  • 您无法在此方案中发送Content-Length:标头。这是因为你不知道身体的大小是什么,直到你压缩它,这时它已准备好发送,所以你不是真的(从服务器的角度来看)预刷头,即使你在你开始发送身体之前,分别发送它们。
  • 如果需要花费很长时间来压缩邮件正文(缓慢/重载服务器,非常大的主体等等),并且在发送邮件头之后才开始压缩,那么客户可能会等待其余响应的风险。这完全取决于客户端,但是有很多HTTP客户端实现,这种可能性不能完全打折。

简而言之,是的,有可能做到这一点,但没有全能,“是的,做到”或“不,不做”的答案 - 你是否会这样做取决于每个请求和它的反应性质。