网页 gzip 为何不会被代替？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3543 天前的主题，其中的信息可能已经有所发展或是发生改变。

随时时间推移和技术更新，ie678 之类的老一代浏览器也化为尘土。但为什么网页压缩却没有被革新呢？gz 这格式算法，并不是十分优秀，7z 默认算法比他强的不少。

那么为什么chrome等各大领航浏览器都不关注这些新一代的压缩算法呢？

压缩

ie678

浏览器

13 条回复 • 2015-03-21 16:35:26 +08:00

FrankFang128

2015-03-21 12:16:18 +08:00 via Android

不是瓶颈吧，能再降低多少体积？

zealic

2015-03-21 12:23:33 +08:00

现有的压缩算法的压缩率一般时以时间为代价换来的，如 7z。
换用这些算法很有可能会导致压缩时间增多，影响网页加载时间，总体来说得不偿失。
gzip 算是时间和空间上都比较均衡的压缩算法，因此也就一直沿用下来。

binux

2015-03-21 12:35:31 +08:00

7z 压缩慢，服务器撑不住

155

2015-03-21 12:47:12 +08:00

chrome有sdch.

kmvan

2015-03-21 13:14:03 +08:00

@FrankFang128 不是瓶颈吧，能再降低多少体积？
这想法不对啊。网页都是纯文本，这种状态下，7z 可以比gz少10%左右的体积，意味着网页能快10%加载显示。我认为不是瓶颈的问题，你看http1对于一般网民来说不是也够用吗，为啥还去开发http2呢？这是一种技术更新。

@zealic 现有的压缩算法的压缩率一般时以时间为代价换来的……因此也就一直沿用下来
@binux 7z 压缩慢，服务器撑不住
实际上7z没你们想的这么慢，刚刚测试压缩一个100kb的网页，7z格式还没显示出进度ui就生成文件了，但gz至少会显示进度ui。7z的算法，压缩html文本，还是十分快速的，体积更小。

不过估计没有任何浏览器和服务端敢尝试，应该是因为这不是兼容的问题，而是导致网页能不能访问的问题。

ryd994

2015-03-21 13:23:28 +08:00 via Android

marginal utility
gzip哪怕最快的参数，随便压压都有一半
7z高参数用的时间是gz百倍不止，就算压到30%，成本收益比一比

sujin190

2015-03-21 14:19:42 +08:00

服务器面对十万百万的访问量的时候这个时间cpu的消耗就不是小数了，况且你从10kb压到9kb 8kb有意义么？对于用户感觉来说都一样

FrankFang128

2015-03-21 14:36:09 +08:00 via Android

@kmvan HTTP 2 相当解决瓶颈问题。尤其是网页外部资源很多的时候

muzuiget

2015-03-21 15:43:22 +08:00

@kmvan 拿桌面的GUI程序和主观来做评定「快」…… 比就应该比算法本身，而不是各种GUI前端（冷启动热启动文件系统等等各种方面都有影响）

glasslion

2015-03-21 16:03:10 +08:00

@ryd994 如果压缩时间百倍能换来30%的压缩比，那是赚翻了。Google 2013年公布的 Zopfli 算法，相比于zlibc，压缩时间也是百倍，只比zlibc 减少了3%

otakustay

2015-03-21 16:30:38 +08:00

更大的压缩比往往伴随着更多的CPU使用，而服务器是以万、十万、百万QPS来计算的，每个资源多10%的CPU使用，服务器的QPS是否就直接下降了，硬件成本要如何平衡，都是很麻烦的事情

兼容问题本就不是问题，从没有gzip到有gzip怎么过来的，就能gzip到7z怎么过来，Accept-Encoding和Content-Encoding都给你设计好放在那了，完全不会出现兼容的问题

HTTP/2里针对Header弄了个特殊的压缩格式来着

jasontse

2015-03-21 16:32:28 +08:00 via iPad

lzma 算法压缩慢，消耗的内存太多。

em70

2015-03-21 16:35:26 +08:00 via Android

7z极限压缩经常要用到几个G的内存，高压缩比是用计算时间作为代价的，对服务器来说cpu,内存资源也同样珍贵