自從我這樣擼程式碼以後，公司網頁的瀏覽量提高了107%！
歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
本文由騰訊IVWEB團隊發表於雲+社群專欄
作者：yangchunwen
HTTP協議是前端效能乃至安全中一個非常重要的話題，最近在看《web效能權威指南(High Performance Browser Networking)》，把其中關於HTTP部分的內容拿出來分享一下，加了一點自己的想法，當然沒有《HTTP權威指南》講得詳細，但對於理解我們平常做的事情很有啟發。預計會有兩三篇文章，重點分別會涉及到HTTP 1.1、HTTPS、HTTP 2.0等內容，本篇主要涉及HTTP 1.1及其應用。
HTTP的歷史
HTTP 0.9
HTTP的第一個版本被官方稱為HTTP0.9，這是個只有一行的協議，例如：
GET /about/ (超文字響應……) (連線關閉……)
HTTP 0.9有幾個要點：
這個版本的HTTP主要用來傳輸 文字 ，並且沒有共用TCP連線。
HTTP 1.0
一個典型的HTTP 1.0請求過程如下：
GET /rfc/rfc1945.txt HTTP/1.0 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Accept: */* HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Expires: Thu, 01 Dec 1997 16:00:00 GMT Last-Modified: Wed, 1 May 1996 12:45:26 GMT Server: Apache 0.84 (超文字響應……) (連線關閉……)
相對前一個版本，HTTP 1.0主要有以下幾點變化：
- 請求和相應可以由於多行 首部 欄位構成
- 響應物件前面添加了一個響應 狀態 行
- 響應物件不侷限於 超文字
- 伺服器與客戶端之間的連線在每次請求之後都會 關閉
- 實現了Expires等傳輸內容的 快取 控制
- 內容 編碼 Accept-Encoding、 字符集 Accept-Charset等協商內容的支援
這時候開始有了請求及返回 首部 的概念，開始傳輸不限於 文字 （其他二進位制內容）
HTTP 1.1
HTTP 1.1是當前大部分應用所使用的協議版本。相對前面的1.0版本，HTTP 1.1語義格式基本保持不變，但是它加入了很多重要的效能優化： 持久 連線、 分塊 編碼傳輸、位元組範圍請求、增強的快取機制、傳輸編碼及請求 管道 。
實際上，持久連結在後來被反向移植到了HTTP1.0上
HTTP 2.0
HTTP 2.0 的主要目標是改進傳輸效能,實現低延遲和高吞吐量。HTTP 2.0作了很多效能角度的優化，另一方面，HTTP的高層協議語義並不會因為這次版本升級而受影響。所有HTTP首部、值,以及它們的使用場景都不會變。現有的任何網站和應用,無需做任何修改都可以在 HTTP 2.0 上跑起來。換句話說, 等以後我們的伺服器、客戶端（如瀏覽器）都支援HTTP 2.0的時候，我們不用為了利用 HTTP 2.0 的好處而修改標記，作很多額外的編碼，卻能享受到它帶來的更低的延遲和更高的網路連線利用率交付！
HTTP 2.0的內容將在下篇或下下篇放出，本文不對其做過多潤色
HTTP 1.1與前端效能
前面講到，HTTP 1.1這個版本引入了大量增強效能的重要特性，其中包括：
- 持久化連線以支援連線重用
- 分塊傳輸編碼以支援流式響應
- 請求管道以支援並行請求處理
- 位元組服務以支援基於範圍的資源請求
- 改進的更好的快取機制
這裡重點講一下持久化、管道在前端效能優化中的一些應用
持久連線
所謂 持久連線 ，就是重用 TCP連線，多個HTTP請求公用一個TCP連線。
HTTP 1.1 改變了 HTTP 協議的語義,預設使用持久連線。換句話說,除非明確告知(通過 Connection: close 首部),否則伺服器預設會保持TCP連線開啟。如果你使用的是 HTTP 1.1,從技術上說不需要 Connection: Keep-Alive 首部,但很多客戶端還是選擇加上它，比如我們的瀏覽器在發起請求的時候，一般會預設幫我們帶上 Connection: Keep-Alive 首部。
我們來看一下為什麼持久連線對我們來說這麼重要。
假設一個網頁僅包含一個HTML文件及一個CSS樣式檔案，伺服器響應這兩個檔案的時間分別為40ms及20ms，伺服器和瀏覽者分別在哈爾濱和深圳，兩者之間單向光纖延遲為28ms(假設的理想狀態，實際會比這個要大)。
- 首先是獲取HTML文件的請求過程：
HTML下載完畢後，TCP連線關閉。
- 其次，發起CSS資源的請求，再次經歷一次TCP握手
可以看到，兩個HTTP請求都分別需要經歷一次TCP的三次握手時間，另外，圖中沒有體現到的是，每一次TCP請求都有可能會經歷一次TCP慢啟動 過程，這是影響傳播效能的一個不可忽視的重要因素。
假如我們底層的TCP連線得到重用，這時候的情況會是這樣子：
很明顯，在獲取CSS的請求中，減少了一次握手往返。
一開始，每個請求要用兩個TCP連線，總延遲為284ms。在使用持久連線後，避免了一次握手往返,總延遲減少為228ms。這裡面兩次請求節省了56ms（一個 RTT ，Round-Trip Time）的時間
上面的例子還只是只有一個HTML和一個CSS的簡單假設情況，而現實世界的web的HTTP請求數量比這個要多得多，在啟用持久連線的情況下，N次請求節省的總延遲時間就是(N-1)×RTT。
現實情況中，延遲更高、請求更多，效能提升效果比這裡還要高得多。事實上,網路延遲越高,請求越多,節省的時間就越多。實際應用中，這個節省的總時間可按秒來算了。如果每一個HTTP都重啟一個TCP連線，可想而知要浪費多少時間！
HTTP管道
持久 HTTP 可以讓我們重用已有的連線來完成多次應用請求，但多次請求必須嚴格滿足先進先出(FIFO，first in first out)的佇列順序：傳送請求,等待響應完成,再發送客戶端佇列中的下一個請求。
舉一下上一節持久連線的那個例子，首先，伺服器處理完第一次請求後，會發生了一次完整的往返：先是響應回傳，接著是第二次請求，在第二次請求到達伺服器之間的這段時間裡，伺服器空閒。
如果伺服器能在處理完第一次請求後,立即開始處理第二次請求呢？甚至，如果伺服器可以並行處理兩個請求呢?
這時候HTTP管道就派上用場了，HTTP管道是一個很小但對上述工作流非常重要的一次優化。
有了HTTP管道，我們的HTTP請求在一定程度上不用再一個一個地序列請求，而是可以多個並行了，看起來好像很理想：
如上圖，HTML和CSS的請求同時到達伺服器，伺服器同時處理，然後返回。
這一次，通過使用HTTP管道，又減少了兩次請求之間的一次往返,總延遲減少為 172 ms。從一開始沒有持久連線、沒有管道的284ms，到優化後的172ms，這40%的效能提升完全拜簡單的協議優化所賜。
等一下，剛剛那個例子好像哪裡還不夠好：既然請求同時到達，同時處理，為什麼後面要先返回HTML，然後再返回CSS？兩者不能同時返回嗎？
理想很豐滿，現實卻有點骨感，這就是HTTP 1.1管道的一個很大的侷限性：HTTP請求無法很好地利用多路複用，不允許一個連線上的多個響應資料交錯返回(多路複用)。因而一個響應必須完全返回後，下一個響應才會開始傳輸。
這個管道只是讓我們把FIFO佇列從客戶端遷移到了伺服器。也就是說，請求可以同時到達伺服器，伺服器也可以同時處理兩個檔案，但是，兩個檔案還是得按順序返回給使用者，如下圖：
- HTML和CSS請求同時到達，但先處理的是HTML請求
- 伺服器並行處理兩個請求，其中處理 HTML 用時40ms，處理CSS用時20ms
- CSS請求先處理完成，但被緩衝起來以等候HTML響應先發送
- 傳送完HTML響應後，再發送伺服器緩衝中的CSS響應
可以看到，即使客戶端同時傳送了兩個請求,而且CSS資源先準備就緒，但是伺服器也會先發送 HTML 響應，然後再交付 CSS。
題外話 上面兩節舉的例子，說到了HTML和CSS請求同時到達，這是書中的例子，實際上，個人覺得這個例子舉得不是很恰當。 實際的web中，HTML及其包含的CSS一般不會同時到達伺服器，正常的瀑布圖也不是這樣的，往往是要先獲取HTML內容後瀏覽器才能發起其中的CSS等資源請求。我想作者只是為了闡述原理吧，個人認為換成同一個HTML文件中CSS和JS可能更加恰當。
這個問題的原理在於TCP層面的“ 隊首阻塞 ”，感興趣可以去複習下計算機網路的課程。其代價往往是：不能充分利用網路連線，造成伺服器緩衝開銷，有可能導致客戶端更大的延遲。更嚴重的時，假如前面的請求無限期掛起，或者要花很長時間才能處理完,所有後續的請求都將被阻塞,等待它完成。
所以，在HTTP 1.1中，管道技術的應用非常有限，儘管其優點毋庸置疑。實際上，一些支援管道的瀏覽器，通常都將其作為一個高階配置選項，但大多數瀏覽器都會禁用它。換句話說，作為前端工程師，開發的應用是面向普通瀏覽器應用的話，還是不要過多的指望HTTP管道，看來還是期待一下HTTP 2.0中對管道的優化吧。
不過，實際上還是有很好地利用HTTP管道的一些應用，例如在WWDC 2012上，有蘋果的工程師分享了一個針對HTTP優化取得巨大成效的案例：通過使用HTTP的持久連線和管道，重用iTunes中既有的TCP連線，使得低網速使用者的效能提升到原來的3倍！
實際上假如你想充分利用管道的好處，必須要保證下面這幾點條件：
- HTTP客戶端支援管道
- HTTP伺服器支援管道
- 應用可以處理中斷的連線並恢復
- 應用可以處理中斷請求的冪等問題
- 應用可以保護自身不受出問題的代理的影響
因為iTunes的伺服器和客戶端都受開發者控制的應用，所以他們能滿足以上的條件。這也許能給開發hybrid應用或者開發瀏覽器之外的web應用的前端工程師們一些啟發，如果你開發的網站面向的使用者是使用五花八門的瀏覽器，你可能就沒轍了。
使用多個TCP連線
因為HTTP 1.1管道存在上面的缺點，所以利用率不高。那麼問題來了：假設沒有使用HTTP管道，我們的所有HTTP請求都只能通過持久連線，一個接一個地序列返回，這得有多慢？
實際上，現階段的瀏覽器廠商採取了另外的辦法來解決HTTP 1.1管道的缺陷：允許我們並行開啟多個TCP會話。至於是多少個，大家可能已經似曾相識：4到8個不等。這就是前端工程師非常熟悉的 瀏覽器只允許從同一個伺服器並行載入4到8個資源 這一認識的真正來歷。
HTTP持久連線雖然幫我們解決了TCP連線複用的問題，但是現階段的HTTP管道卻無法實現多個請求結果的交錯返回，所以瀏覽器只能開啟多個TCP連線，以達到並行地載入資源的目的。
只能說，這是作為繞過應用協議（HTTP）限制的一個 權宜之計 。可以這樣打一個比喻，一個水管無法同時運輸多種液體，那就只能給每一種液體開通一條運輸管了，至於這個水管什麼時候可以智慧化到同時運輸不同的液體，又能保證各自完整不受干擾到達目的地並在目的地自行分類？還是那一句，期待HTTP 2.0吧。
這裡的連線數為什麼是4到8個，是多方平衡的結果：這個數字越大，客戶端和伺服器的資源佔用越多（在高併發訪問的伺服器中因為TCP連線造成的系統開銷不可忽視），每個主機4到8個連線只不過是大家都覺得比較安全的一個數字。
域名分割槽
前面說到，瀏覽器和伺服器之間只能併發4到8個TCP連線，也就是同時下載4到8個資源，夠嗎？
看看我們現在的大部分網站，動不動就幾十個JS、CSS，一次六個，會造成後面大量的資源排隊等待；另外，只下載6個資源，對頻寬的利用率也是很低的。
打個比喻，一個工廠裝了100根水管，每次卻只能用其中6根接水，既慢，又浪費水管！
所以，我們前端效能優化中有一個最佳實踐：使用 域名分割槽 ！
對啊，何必把自己只限制在一個主機上呢？我們可以手工將所有資源分散到多個子域名，由於主機名稱不一樣了，就可以突破瀏覽器的連線限制，實現更高的並行能力。
通過這種方式“欺騙”瀏覽器，這樣瀏覽器和伺服器之間的並行傳輸數量就變多了。
域名分割槽使用得越多，並行能力就越強！
但是，域名分割槽也是有代價的！
實踐中，域名分割槽經常會被濫用。
例如，假設你的應用面向的是2G網路的手機使用者，你分配了好幾個域名，同時載入十幾二十多個CSS、JS，這裡的問題在於：
- 每一個域名都會多出來的DNS查詢開銷，這是額外的機器資源開銷和額外的網路延時代價。2G網路的DNS查詢可不像你公司的電腦一樣，相反可能是好幾秒的延遲
- 同時載入多個資源，以2G網路那種小得可憐的頻寬來看，後果往往就是頻寬被佔滿，每一個資源都下載得很慢
- 手機的耗電加快
所以在一些低頻寬高延時的場景，例如2G手機網路，域名分割槽做過了的話，不光不會帶來前端效能的提升，反而會變成效能殺手。
域名分割槽是一種合理但又不完美的優化手段，最合適的辦法就是，從最小分割槽數目（不分割槽）開始，然後逐個增加分割槽並度量分割槽後對應用的影響，從而得到一個最優的域名數。
連線與拼合
我們前端效能優化中有這麼一個所謂的最佳實踐原則：合併打包JS、CSS檔案，以及做CSS sprite。
現在我們應該知道為什麼要這樣做了，實際上就是因為現在HTTP 1.1的管道太弱了，這兩種技術的效果就好像是隱式地啟用了HTTP 管道：來自多個響應的資料前後相繼地連線在一起，消除了額外的網路延遲。
實際上，就是把管道提高了一層，置入了應用中，也許到了HTTP 2.0時代，前端工程師就不用幹這樣的活了吧？(HTTP 2.0的內容下篇講)
當然，連線拼合技術同樣有代價的。
- 例如CSS sprite，瀏覽器必須分析整個圖片，即便實際上只顯示了其中的一小塊，也要始終把整個圖片都儲存在記憶體中。瀏覽器沒有辦法把不顯示的部分從記憶體中剔除掉。
- 再者，既然JS、CSS合併了，帶來的一般就是體積的增大，在頻寬有限的環境下（例如2G）下載時間就變長，一般導致的就是頁面渲染時間延後等後果。因為JavaScript 和CSS 處理器都不允許遞增式執行的，對於JavaScript 和CSS 的解析及執行，則要等到整個檔案下載完畢。
打包檔案到底多大合適呢？可惜的是，沒有理想的大小。然而，谷歌PageSpeed團隊的測試表明，30~50 KB（壓縮後）是每個JavaScript 檔案大小的合適範圍：既大到了能夠減少小檔案帶來的網路延遲，還能確保遞增及分層式的執行。具體的結果可能會由於應用型別和指令碼數量而有所不同。
資源內嵌
JavaScript 和CSS 程式碼， 通過適當的script 和style 塊可以直接放在頁面中，而圖片甚至音訊或PDF 檔案，都可以通過資料URI（data:mediatype,data）的方式嵌入到頁面中。
上面的這種方式我們稱為 資源內嵌 。
嵌入資源是另一種非常流行的優化方法， 把資源嵌入文件可以減少請求的次數。尤其在2G網路等情況中，內嵌資源可以有效地減少多次請求帶來的時延。可以參考這篇文章在2G中的一些實踐。
當然，有缺點：
- 內嵌方式的資源，不能被瀏覽器、CDN 或其他快取代理作為單獨的資源快取。如果在多個頁面中都嵌入同樣的資源，那麼這個資源將會隨著每個頁面的載入而被載入，從而增大每個頁面的總體大小。
- 如果嵌入資源更新，那麼所有以前出現過它的頁面都將被宣告無效，而由客戶端重新從服 務器獲取。
- 圖片等非文字性資源通過base64 編碼，會導致開銷明顯增大：編碼後的資源大小比原大小增大33%！
Google的磚家給出一些經驗：
- 只考慮嵌入1~2 KB 以下的資源，因為小於這個標準的資源經常會導致比它自身更高的HTTP 開銷
- 如果檔案很小，而且只有個別頁面使用，可以考慮嵌入。理想情況下，最好是隻用一次的資源
- 如果檔案很小，但需要在多個頁面中重用，應該考慮集中打包
- 如果小檔案經常需要更新，就不要嵌入了
- 通過減少 HTTP cookie 的大小將協議開銷最小化
小結
本文介紹了HTTP 1.1在前端效能優化中的一些應用，有些是為了繞過HTTP 1.1侷限性的一些不得不做的事情，比如資源合併、壓縮、內嵌等，這些都可以說是HTTP 2.0來臨前的一些解決問題的“黑魔法”。
HTTP 1.1及其利用當然遠遠沒有本文說得那麼簡單，我只是濃縮了一部分內容，有興趣可以去研究《HTTP權威指南》。
此文已由作者授權騰訊雲+社群釋出，更多原文請點選
搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社群！