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

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

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

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

在 Nginx 的官網(wǎng)文檔中，有這樣一個指令：

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，響應內(nèi)容的 Content-Type 存在于 gzip_types 列表)的請求會采用即時壓縮(On-The-Fly Compression)，整個壓縮過程在內(nèi)存中完成，是流式的。也就是說，Nginx 不會等文件 GZip 完成再返回響應，而是邊壓縮邊響應，這樣可以顯著提高 TTFB(Time To First Byte，首字節(jié)時間，WEB 性能優(yōu)化重要指標)。這樣唯一的問題是，Nginx 開始返回響應時，它無法知道將要傳輸?shù)奈募罱K有多大，也就是無法給出 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 所對應的分塊傳輸機制可以完美解決這類問題。

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

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

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

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

可以看到，這次的請求報文與上次完全一樣，但是結果截然不同：雖然返回的內(nèi)容被壓縮了，但是連接也被斷開了，服務端返回了 Connection: close。原因就是之前說過的，動態(tài)壓縮導致無法事先得知響應內(nèi)容長度，在 HTTP/1.0 中只能依靠斷開連接來讓客戶端知道響應結束了。

最后，使用 HTTP/1.1 請求報文測試：

可以看到，由于請求報文是 HTTP/1.1 的，Nginx 能知道這個客戶端可以支持 HTTP/1.1 的 Transfer-Encoding: chunked，于是通過分塊傳輸解決了所有問題：既啟用了壓縮，也啟用了持久連接。

那么，對于 HTTP/1.0 請求，我們是讓 Nginx 放棄持久連接好，還是放棄 GZip 好呢?

實際上，由于 HTML 文檔一般都是使用 PHP、Node.js 等動態(tài)語言輸出，即使不壓縮，Nginx 也無法事先得知它的 Content-Length，在 HTTP/1.0 中橫豎都無法啟用持久連接，這時還不如啟用 GZip 省點流量。

對于 JS、CSS 等事先可以知道大小的靜態(tài)文本文件，我的建議是，移動端首次訪問把重要的 JS、CSS 都內(nèi)聯(lián)在 HTML 中，然后存在 localStorage 里，后續(xù)不輸出;不重要的 JS、CSS 外鏈并啟用 GZip，犧牲 keep-alive 來達到減少流量的目的。