從 Nginx 默認不壓縮 HTTP/1.0 說起

jopen 8年前發布 | 7K 次閱讀 Nginx

臨近年關，明顯變忙，博客也更新得慢了，以后盡量保證周更吧。今天這篇文章屬于計劃之外的更新，源自于白天看到的《一個基于 http 協議的優化》。在這篇文章中，作者描述了這樣一個現象：

在移動的 http 請求量和聯通不相上下的前提下，移動的 http response 帶來的網絡流量是聯通的 2.5 倍。移動大概有 3 成的請求都沒有做壓縮，而聯通幾乎都是經過壓縮的。那些沒有經過壓縮的 http 會話都是走了 1.0 的協議，相反經過壓縮的 http 會話都是走了 http1.1 協議。

也就是說在相同的服務端配置下，移動運營商過來的流量中有 30% 走了 HTTP/1.0，而作者所使用的 HTTP Server，不對 HTTP/1.0 響應啟用 GZip。

為什么在移動運營商網絡下會有這么高比例的 HTTP/1.0 請求，本文按下不表，總之這一定是移動的原因。直接看另外一個問題，也就是本文標題所寫：Nginx 為什么默認不壓縮 HTTP/1.0？

那篇文章的作者并沒有說明他用什么 HTTP Server，我這里直接當成 Nginx 好了。后面會發現這個問題跟 HTTP 協議有關，所有 HTTP Server 都會面臨。

在 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。于是，前面這種情況只能要么不壓縮，要么不啟用持久連接（對于非持久連接，TCP 斷開就可以認為 HTTP 報文結束），而 Nginx 默認選擇的是前者。

那么在 HTTP/1.1 中，這個問題解決了嗎？當然！我在之前的文章中講過，HTTP/1.1 新增的 Transfer-Encoding: chunked 所對應的分塊傳輸機制可以完美解決這類問題。有興趣的同學可以查看我的這篇文章：HTTP 協議中的 Transfer-Encoding。

理論知識先寫到這里，最后用實踐來驗證一下：

首先，不啟用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 請求報文測試：

可以看到，盡管我的請求報文中指明了可以接受 GZip，但是返回的內容依然是未壓縮的；同時服務端響應了 Content-Length 和 Connection: keep-alive，連接并沒有斷開。也就是說 Nginx 為了盡可能啟用持久連接，放棄了 GZip，這是 Nginx 的默認策略。

然后，啟用 Nginx 的 HTTP/1.0 GZip 功能，使用 HTTP/1.0 請求報文測試：