为什么nginx转发后端默认使用1.0而不是1.1
在 Nginx 的官网文档中，有这样一个指令：
Syntax: gzip_http_version 1.0 | 1.1;
Default: gzip_http_version 1.1;
Context: http, server, location
Sets the minimum HTTP version of a request required to compress a response.
很明显，这个指令是用来设置 Nginx 启用 GZip 所需的 HTTP 最低版本，默认是 HTTP/1.1。
也就是说 Nginx 默认不压缩 HTTP/1.0 是因为这个指令，将它的值改为 1.0 就能解决问题。
对于文本文件，GZip 的效果非常明显，开启后传输所需流量大约会降至 1/4 ~ 1/3。这么好的事情，Nginx 改一下配置就可以支持，为什么它默认不开启？
Nginx 对于满足条件（请求头中有 Accept-Encoding: gzip，响应内容的 Content-Type 存在于 gzip_types 列表）的请求会采用即时压缩（On-The-Fly Compression），整个压缩过程在内存中流式完成。也就是说，Nginx 不会等文件 GZip 完成再返回响应，而是边压缩边响应，这样可以显著提高 TTFB（Time To First Byte，首字节时间，WEB 性能优化重要指标）。这样唯一的问题是，Nginx 开始返回响应时，它无法知道将要传输的文件最终有多大，也就是无法给出 Content-Length 这个响应头部。
我们还知道，HTTP/1.1 默认支持 TCP 持久连接（Persistent Connection），HTTP/1.0 也可以通过显式指定 Connection: keep-alive 来启用持久连接。HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性，要想提高 HTTP 性能，启用持久连接就显得尤为重要。
明白以上两点，马上就能水落石出了：对于 TCP 持久连接上的 HTTP 报文，客户端需要一种机制来准确判断结束位置。而在 HTTP/1.0 中，这种机制只有 Content-Length。于是，对于本文前面提出的情况，HTTP Server 只能要么不压缩，要么不启用持久连接（对于非持久连接，TCP 断开就可以认为 HTTP 报文结束），而 Nginx 默认选择的是前者。
不启用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 请求报文测试：
请求报文中指明了可以接受 GZip，但是返回的内容依然是未压缩的；
同时服务端响应了 Content-Length 和 Connection: keep-alive，连接并没有断开。
也就是说对于 HTTP/1.0 请求，Nginx 为了尽可能启用持久连接，放弃了 GZip，这是 Nginx 的默认策略。
启用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 请求报文测试：
返回的内容被压缩了，连接也被断开了，服务端返回了 Connection: close。原因就是之前说过的，动态压缩导致无法事先得知响应内容长度，在 HTTP/1.0 中只能依靠断开连接来让客户端知道响应结束了。
使用 HTTP/1.1 请求报文测试：
请求报文是 HTTP/1.1 的，Nginx 能知道这个客户端支持 HTTP/1.1 的 Transfer-Encoding: chunked，于是通过分块传输解决了所有问题：既启用了压缩，也启用了持久连接。
那么，对于 HTTP/1.0 请求，我们是让 Nginx 放弃持久连接好，还是放弃 GZip 好呢？
实际上，由于 HTML 文档或 JSON 接口一般都是用 PHP、Node.js 等服务端语言动态输出，即使不压缩，Nginx 也无法事先得知它的 Content-Length，在 HTTP/1.0 中无论如何都无法启用持久连接，这时还不如启用 GZip 省点流量。
)
