HTTP 协议中的Content-Encoding

Royal
2022-03-31 / 0 评论 / 1,123 阅读 / 正在检测是否收录...

最近在做拟态开发过程中,遇到lua脚本响应PHP返回接口的数据乱码问题,通过postman调试发现响应头部Content-Encoding算法为gzip,而其他接口如python则没有这个设置。
l1ee9qo7.png

首先来了解下什么是Content-Encoding?

Accept-Encoding 和Content-Encoding是HTTP中用来对采用哪种编码格式传输正文进行协定的一对头部字段。

工作原理如下:

  • 首先浏览器(也就是客户端)发送请求时,通过Accept-Encoding带上自己支持的内容编码格式列表;
  • 服务端在接收到请求后,从中挑选出一种用来对响应信息进行编码,并通过Content-Encoding来说明服务端选定的编码信息
  • 浏览器在拿到响应正文后,依据Content-Encoding进行解压。

    服务端也可以返回未压缩的正文,但这种情况不允许返回Content-Encoding

内容编码的目的是优化传输内容的大小,通俗的讲就是尽心压缩。一般经过gzip压缩过的文本响应,只有原始大小的1/4(这个数据我现在还不确定)。对于文本类响应是否开启了内容压缩,是我们做性能优化时首先要检查的重要项目;而对于JPG/PNG这类本身已经高度压缩过的二进制文件,不推介开启内容压缩,效果几乎微乎其微,还浪费cpu

内容的编码针对的只是传输正文。在HTTP/1中,头部始终是以ASCII文本传输,没有经过任何压缩。不过这个问题在HTTP/2中已经解决,详见HTTP/2 头部压缩技术介绍

内容编码使用特别广泛,理解起来也特别简单,但是要注意的是不要把它与HTPP中的另外一个概念:传输编码Transfer-Encoding搞混即可。

内容编码格式gzip 和deflate

开始之前,先来介绍三种数据压缩格式:

  • DEFLATE,是一种使用 Lempel-Ziv 压缩算法(LZ77)和哈夫曼编码的数据压缩格式。定义于 RFC 1951 : DEFLATE Compressed Data Format Specification;
  • ZLIB,是一种使用 DEFLATE 的数据压缩格式。定义于 RFC 1950 : ZLIB Compressed Data Format Specification;
  • GZIP,是一种使用 DEFLATE 的文件格式。定义于 RFC 1952 : GZIP file format specification;
    这三个名词有太多的含义,很容易让人晕菜。所以本文有如下约定:
  • DEFLATE、ZLIB、GZIP 这种大写字符,表示数据压缩格式;
  • deflate、gzip 这种小写字符,表示 HTTP 中 Content-Encoding 的取值;
  • Gzip 特指 GUN zip 文件压缩程序,Zlib 特指 Zlib 库;
    在 HTTP/1.1 的初始规范 RFC 2616 的「3.5 Content Codings」这一节中,这样定义了 Content-Encoding 中的 gzip 和 deflate:
  • gzip,一种由文件压缩程序「Gzip,GUN zip」产生的编码格式,描述于 RFC 1952。这种编码格式是一种具有 32 位 CRC 的 Lempel-Ziv 编码(LZ77);
  • deflate,由定义于 RFC 1950 的「ZLIB」编码格式与 RFC 1951 中描述的「DEFLATE」压缩机制组合而成的产物;

nginx中如何设置gzip

l1eerp62.png
在nginx.conf文件中 找到gzip 默认是on开启状态,改为off表示关闭
然后重启nginx服务

/usr/local/nginx/sbin/nginx -s stop
/usr/local/nginx/sbin/nginx

l1eeu489.png
发现Content-Encoding没有返回,OK,这样不同接口之间就是原样输出,方便lua脚本输出内容!

1

评论

博主关闭了当前页面的评论