Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

GZIP 的局限性

  我曾经天真地以为只要开启了 GZIP 就不会在有冗余传输,但实际上 GZIP 的使用场景也存在很大的局限性。通常只有服务器端通过 HTTP 给客户端传输数据时,GZIP 才会默认启用。其它情况,无论是协议不同或是端不同甚至传输方向不同都会导致难以使用 GZIP。
  GZIP 本身只是一种编码形式而已,是算法级的东西。但在 Web 上,如果平台没有自带实现,要手动实现的话代码量和性能都会成为问题。也就是说,手动实现 GZIP 的成本太高,如果 GZIP 作为一种优化就应该得是平台提供的,否则很难真正起到优化作用。然而,GZIP 的使用有这么几个阻碍:

协议局限

  浏览器自带的 GZIP 支持仅限于 HTTP(这里说的是协议,不是 scheme),或者 Web 本身就是一种基于 HTTP 的东西,如果使用其它协议就未必有原生的 GZIP 支持。这个坑的最大受害者应该是 WebSocket 了,因为 WebSocket 就没有自带 GZIP 支持(至少我读过的那个版本没有,不代表今后也没有),导致我需要传输大量易压缩数据(比如文章、页面模板)时总是会忌惮这个点。甚至有时还是会换回 HTTP 传输。

端局限

  大部分浏览器都支持 GZIP,这是非常好的。但确实也存在一些操蛋的平台不支持 GZIP,所以服务器端总是要根据请求头的 Accept-Encoding 为某些奇怪的平台输出一份不开启 GZIP 的版本。这个做法在我看来还算正常,而且现在确实很少有这样的设备存在。但我们换一个角度看这个问题又如何呢?服务器端的 HTTP 服务器未必支持 GZIP,比如早期的 nginx 在 GZIP 的处理上是有坑的(只要升级到新版就没问题)。

传输方向局限

    我觉得传输方向局限才是最大的坑。GZIP 通常都只是在从服务器端往客户端传输内容才启用。对于 HTTP 请求的 payload,浏览器并不会自动开启 GZIP。虽然大部分情况下请求的 payload 很小(比如一个简单的登录表单),开启 GZIP 反而得不偿失。然而表单中也确实可能存在一些文章编辑之类的易压缩内容,这些内容要是不压缩,传输起来一定是非常浪费资源的。
  普通的文本类型数据上传也许真不会大到离谱,那么如果是媒体类型呢?比如一个前端图片裁剪的场景,Canvas 裁剪图片后最方便的方式是直接 toDataUrl 吧?可要是没有 GZIP,base64 上传就非常浪费(此时使用 Uint8Array 之类的原始类型也许可以解决问题)。

  突然觉得自己扯了一堆有的没的,貌似对现实没有任何帮助。其实很早以前我就想去造 GZIP 这个轮子,只是感觉自己造的肯定会被性能坑,所以一直没动。现在更是完全不想动也没时间动了 = =。如果以后真有什么奇怪的需求的话再考虑吧。。

网名:
54.226.58.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^