喜欢这些老玩意儿
今日鸡汤：
一切伟大的行动和思想，都有一个微不足道的开始。没有对生活绝望，就不会爱生活。
最近因为项目要加gzip的缘故，认真的了解了一下gzip的周边，这篇来总结一下。
客户端和服务器端如何约定gzip？
在HTTP协议中，请求Request和响应Response都带有Header和Body。其中，Body就是服务器返回给你的资源信息，而Header是用来做一些约定。双方先读取Header了解对方的诉求，比如Content-Type是什么，Accept-Charset是什么， 然后再按照这个约定接收body并进行解析。
对于gzip来说也是同样，他们的对话大致是这样：
客户端：服务器，你给我传内容时能压缩下吗？我流量少。（发送Header: Accept-Encoding: gzip）
服务端：好的客户端，get。（发送Header: Content-Encoding: gzip）
服务端：我给你压缩了哈，开始传输压缩后的内容（发送Body：HC?l???0??:8@Vp)??|??9I????Op??）
客户端：还好现在大多数的客户端/浏览器都能自动解压，我能直接拿到解码后的body（收到Body：You are soo coool ）
这就是当客户端和服务端想要使用gzip时在HTTP层面进行的通话。
如何用Python Tornado模拟gzip？
什么是Tornado？
Tornado是python的轻量级Web框架，采用单进程单线程异步IO的网络模式，主要包括：
- Web框架
主要包括RequestHandler用于创建Web应用程序和各种支持类的子类 - HTTP服务器与客户端
主要包括HTTPServer和AsyncHTTPClient - 异步网络库
主要包括IOLoop和IOStream作为HTTP组件的构建块 - 协程库
如何用Tornado模拟C/S？
那么，接下来看一下如何使用Tornado来实现一个C/S通信的例子。
1. 使用Tornado创建一个Web Server：
# 第一步，创建一个Web应用，配置RequestHandler，在Handler中，定义传输的header，get/post等方法的处理逻辑
app = tornado.web.Application(handlers=handlers,
compress_response=True,
template_path=template_path)
# 第二步，初始化tornado的HTTP服务器
http_server = tornado.httpserver.HTTPServer(app)
# 第三步，开启服务，监听端口
http_server.listen(options.port)
tornado.ioloop.IOLoop.instance().start()
2. 使用Tornado创建一个Web Client：
# 第一步，初始化tornado的HTTPClient
http_client = HTTPClient()
# 第二步，组装HTTPRequest
request = HTTPRequest(url=url, method='POST', headers={'Accept-Encoding': 'gzip'},
body=req_body, decompress_response=False)
# 第三步，发送请求，拿到response
response = http_client.fetch(request)
Tornado对gzip的支持
Tornado作为一个Web应用服务器，也默认支持了gzip的功能，包括客户端和服务端请求压缩和响应解压。
| Client | Server | |
|---|---|---|
| 场景一：请求压缩 | headers={'Content-Encoding': 'gzip'} | |
| 场景一：请求解压 | decompress_request=True | |
| 场景二：响应压缩 | compress_response=True | |
| 场景二：响应解压 | decompress_response=True(默认)|False |
具体来说，关于压缩和解压，有两个场景：
场景一：Client发送压缩的请求，Server需要解压
Client：
# 对请求内容进行压缩
bytesio = BytesIO()
gzip_file = gzip.GzipFile(mode='w', fileobj=bytesio)
gzip_file.write(utf8(req_body))
gzip_file.close()
compressed_req_data = bytesio.getvalue()
# 发送压缩后的body
request = HTTPRequest(url=url, method='POST', headers={'Content-Encoding': 'gzip', body=compressed_req_data}
Server：
# 配置Server端在接受到Header包含Content-Encoding:gzip的请求时进行解压
http_server = tornado.httpserver.HTTPServer(app, decompress_request=True)
场景二：Sever发送压缩的请求， Client需要解压
Client：
# 设置Header Accept-Encoding:gzip
# 配置client对响应进行解压
request = HTTPRequest(url=url, method='POST', headers={'Accept-Encoding': 'gzip'},
body=req_body, decompress_response=True)
Server：
if 'Accept-Encoding' in self.request.headers.keys() and self.request.headers['Accept-Encoding'] == 'gzip':
# 设置Header Content-Encoding:gzip
self.set_header("Content-Encoding", 'gzip')
# 使用gzip压缩Response
gzip_compress = zlib.compressobj(9, zlib.DEFLATED, zlib.MAX_WBITS | 16)
response = gzip_compress.compress(str.encode(response)) + gzip_compress.flush()
compressed_content_length = len(response)
# 重新设置Content-Length为压缩后的body长度
self.set_header("Content-Length", compressed_content_length)
# 返回Response
self.write(response)
Nginx如何支持gzip？
在Nginx中，有HttpGzip模块用于支持在线实时压缩输出数据流，支持参数配置：
https://www.nginx.cn/doc/standard/httpgzip.html
gzip on|off; #是否开启gzip
gzip_buffers 32 4K| 16 8K #缓冲(压缩在内存中缓冲几块? 每块多大?)
gzip_comp_level [1-9] #压缩级别(级别越高,压的越小,越浪费CPU计算资源)
gzip_disable #正则匹配 什么样的Uri不进行gzip
gzip_min_length 200 # 设置允许压缩的页面最小字节数，页面字节数从header头中的Content-Length中进行获取。
gzip_http_version 1.0|1.1 # 开始压缩的http协议版本(可以不设置,目前几乎全是1.1协议)
gzip_proxied # 设置请求者代理服务器,该如何缓存内容，Nginx作为反向代理的时候启用，开启或者关闭后端服务器返回的结果，匹配的前提是后端服务器必须要返回包含"Via"的 header头。
gzip_types text/plain application/xml # 对哪些类型的文件用压缩 如txt,xml,html ,css
gzip_vary on|off # 是否传输gzip压缩标志，即增加响应头“Vary: Accept-Encoding"
在进行调研中，思考了几个问题，特来总结一下：
1) Server端有压缩，Nginx还会不会二次压缩？——不会
在Nginx官方文档，有这样的介绍，说明Nginx是不会对已经压缩的Response进行二次压缩的。
Compressing responses often significantly reduces the size of transmitted data. However, since compression happens at runtime it can also add considerable processing overhead which can negatively affect performance. NGINX performs compression before sending responses to clients, but does not “double compress” responses that are already compressed (for example, by a proxied server).
但什么是已经压缩的呢？看了网上的源码分析，找到了答案。具体条件大神已有所标注。
nginx源码说明
可以看出，是否进行gzip，是与Accept-Encoding、Content-Encoding、Content-Length这几个Header密切相关的。同时，是否解压，也与Content-Encoding这个Header密切相关。因此，在使用gzip时，一定要注意传输前配好Header，压缩后更新Content-Length。
2) 什么样的min_length比较合适?
min_len 太小，可能导致压缩后内容反而大，因此min_len不能设置的太小，我最后选定的是1K。
由于网上对于gzip压缩的大多是静态内容，我们的场景是对Response的文本进行压缩，因此抓包做了个实验。（gzip_comp_level为6）
| 原始Response | gzip后Response | 压缩率 | 结果 |
|---|---|---|---|
| 49 Bytes | 54 Bytes | 110% | 变大 |
| 50 Bytes | 31 Bytes | 62% | 变小 |
| 1116 Bytes | 38 Bytes | 3.4% | 变小 |
| 2641 Bytes | 329 Bytes | 12.4% | 变小 |
虽然实验样本比较少，但是能看到在低于1K的大小进行压缩，压缩率并不好，在1K左右，效果会比较好。因此最后选了1K，但是压缩率虽然越低越好，但意味着解压时间越长，具体效果如何，再观察观察是否需要进行调整。
3）不同语言客户端对gzip的支持
在使用gzip时，要注意不同client端对于gzip的默认设置。
python requests包：gzip默认true
nodejs request包：gzip默认false，如果设置为true，则nodejs会带上Accept-Encoding的请求头，并且对response进行解压。详情可参考github的request包
nodejs request包对gzip的支持
网友评论