1
muzuiget 2022-02-09 02:26:46 +08:00
Facebook 哪里惨了,混得更厉害好不好。zstd 都进 Linux 内核了,各种底层例如文件系统和包管理都已经使用了。
Chrome 不支持是因为未接受为 Web 标准而已。 |
2
timpaik 2022-02-09 02:33:23 +08:00 via Android
br 默认是针对 web 优化的(例如 html 标签),zstd 数据量大才有效果,web 这类小文件肯定选 br 啊
|
3
duke807 2022-02-09 02:48:59 +08:00 via Android
我嵌入式 linux 跑 busybox httpd 服務器,把所有文件壓縮成 gzip 格式,然後刪掉原始 html 、js 、css 、圖片 等數據,瀏覽器會自動下載壓縮版本的文件(原理是瀏覽器請求服務器文件的時候,會告訴服務器可以返回哪些格式的壓縮算法,只有所有算法服務器都不支持,才返回未壓縮的原文件)
其它壓縮格式主流瀏覽器默認不會都支持吧?一般都是 gzip 兼容性最好吧 至於通用壓縮,我一般用 3 種:tar 、tar.bz2 、tar.xz tar 其實沒有壓縮,只是打包 tar.bz2 兼顧壓縮率和壓縮解壓速度 tar.xz 是極致壓縮,壓縮解壓速度慢一些 你可以對比一下 tar.xz 的壓縮率和你說的 br ,看哪個更強 |
4
chutsetien 2022-02-09 03:18:35 +08:00
文本压缩的话,PPMd 还是最无敌的。
|
5
yyfearth 2022-02-09 03:52:35 +08:00
zstd 不适合 web zstd 主要的优势是快而不是压缩率
br 的速度肯定没办法和 zstd 比 但是压缩速度对 web 而言没那么重要 尤其是静态资源 br 就是专门为 web 优化的算法 @duke807 br 是压缩慢但是解压缩还是比较快的而且不太占资源 xz 如果是高压缩率的话 压缩和解压都太慢 而且太占资源了 不太适合浏览器 |
6
0ZXYDDu796nVCFxq 2022-02-09 07:58:40 +08:00 via Android
压缩速度和计算资源消耗是 web 压缩最重要的指标啊,远比压缩率重要
所以 xz bz2 都不适合 web 压缩 br 的优势在于两端有预置的字典,能在小文件(几十到几百 K )条件下的流压缩做到很高的压缩率 br 的优势也仅限于 web ,和 zstd 不是一个方向 |
7
tcp 2022-02-09 09:29:24 +08:00
个人感觉这个数据反而说明 7z 更厉害啊
|
8
3dwelcome OP @duke807 "一般都是 gzip 兼容性最好吧", 我搜了一下,浏览器对于 br 兼容性意外的好,可能是 br 算法出的早,是 2013 年出的。再过两年,就十周年了。
还有如果你真的喜欢 gzip ,那还是推荐用 google 家的 zopfli 。 我就没见过比 zopfli 更强的 gzip 压缩算法,在压缩率上面,可谓举世无双。 |
10
duke807 2022-02-09 11:42:10 +08:00 via Android
@3dwelcome 這裡說 ios 瀏覽器不支持 br:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding 服務器端,我提到的 busybox httpd 也只支持 gzip 還有,我想說的是,其實 web 壓縮有和無區別很大,用 br 取代 gzip 感覺額外帶來的好處也不多,譬如我一個項目,前段時間聽取了用戶建議,才知道把一個 3.5 MB 的 wasm 文件用 gzip 壓縮到 1.5M 左右,比一半還小,其它文件也全部壓縮了一下,改善很大,如果用 br 估計也不會小,就算壓縮到 1.4M ,改善也不大 |
11
3dwelcome OP |
12
duke807 2022-02-09 12:34:31 +08:00 via Android
@3dwelcome 上面有人說 br 是專門針對 html 等文本優化的,wasm 是二進制程序,用 br 沒有優勢
不知道 zopfli 是啥,我用 gzip 是直接用 gzip 命令,一個命令所有文件都壓縮好了,linux 環境 |
13
3dwelcome OP @duke807 “上面有人說 br 是專門針對 html 等文本優化的”
昨晚实测,br 能把 gzip 后的二进制文件都再压缩一大截。 按理说 gzip 已经是压缩格式,不能二次压缩,可就和 winrar 能压缩 zip 原理一样,br 也能。 zopfli 是 google 的 gzip 定制版压缩算法。压缩的时候,内部可以设置递归参数(iterator),能恒定减少生成 gzip 的体积。所谓恒定,就是对于任何 gzip 文件,用 zopfli 都能少个 10%。 |
14
linglin0924 2022-02-09 17:08:42 +08:00
这个测试图,怎么生成的
|
15
3dwelcome OP |
16
jim9606 2022-02-09 21:20:23 +08:00 1
我觉得 zstd 用的范围更广。目前可以用在 Linux 内核镜像压缩、ZFS/BtrFS 透明压缩、PKZIP ( zip 文件规范)可选编码算法、deb/Arch 软件包压缩算法。brotli 目前主要就浏览器和 Android OTA 包在用。
7z 默认算法是 LZMA/LZMA2 ,也就是 xz 用的算法。LZMA 是典型用于极限追求压缩率的场景,例如冷存储和路由器 ROM 之类需要极限紧凑无所谓慢的场合。要速度都不会用这个。zstd 在此的对比优势是在高压缩级别能达到 LZMA 近似的压缩率(通常还是大一丢丢)但解压更快。 brotli 有一个硬编码的静态字典,zstd 没有,但可以训练生成一个定制字典。也就是说 brotli 的高效是建立在对输入内容有偏向性假设的前提上的。所以我不否认 Web 内容上 brotli 是个好的选择。至于 brotli 和 zopfli 选哪个看你网站的客户端统计吧,或者全都要。 另外我不知道你图里的 zstd 是不是用默认的 3 级压缩,你有没有试过 19 级? @timpaik RFC8478/RFC8878 已经标准化 zstd 对应的 HTTP Content-Encoding 和 MIME ,想用都是能用的。 Chromium 拒绝支持竞争技术也不是一天两天的事了,到现在都没支持 HEVC 。 |
17
3dwelcome OP |