使用HTTP/2提升效能的7個建議

w3ctech發表於2015-11-10

  歷史悠久的超文字傳輸協議,即HTTP標準,最近版本升級了。HTTP/2在2015年5月被批准,目前已經在很多Web瀏覽器和伺服器中得到實現(包括NGINX Plus開源NGINX)。大約有三分之二的瀏覽器已經支援HTTP/2,而且這個比例每月都在增加。

  HTTP/2構建在Google SPDY協議基礎之上,Chrome將在2016年年初停止對後者的支援。NGINX是最早支援SPDY的,如今同樣率先支援了HTTP/2。為此,我們還發布了詳盡的白皮書(PDF),介紹了HTTP/2以及它如何基於SPDY構建,並展示瞭如何實現這個新協議。

  HTTP/2的重要特性完全源自SPDY。

  • HTTP/2是二進位制(而文字)協議,因此更簡潔高效;
  • 它針對每個域只使用一個多路複用的連線,而不是每個檔案一個連線;
  • 首部使用特製的HPACK協議(而非SPDY中使用的gzip)壓縮;
  • HTTP/2設計了複雜的優先順序排定規則,幫助瀏覽器首先請求最急需的檔案,而NGINX已經支援(SPDY的方案要簡單一些)。

  現在,你需要決定是否遷移到HTTP/2,而其中關鍵是知道如何最大限度地利用它。這篇文章會帶你瞭解從效能角度考慮為什麼要做這個決定,以及如何實現。接下來我們要逐一討論關於HTTP/2效能的7個小建議。

  1. 現在是否需要遷移到HTTP/2
  2. 終止HTTP/2和TLS
  3. 考慮從SPDY開始
  4. 找出為HTTP/1.x優化的程式碼
  5. 部署HTTP/2或SPDY
  6. 再談HTTP/1.x優化
  7. 實現智慧分域

  注意:嚴格來講,SPDY和HTTP/2都不需要TLS,但它們在使用SSL/TLS的時候用處最大,而且瀏覽器只在使用SSL/TLS時才支援SPDY或HTTP/2。

 建議一:現在是否需要遷移到HTTP/2

  實現HTTP/2很簡單,看看我們的白皮書就明白了(PDF)。不過,HTTP/2並不是萬能的銀彈,它只對某些Web應用有用,對另外一些則沒那麼有用。

  如果你使用SSL/TLS(以後簡稱TLS),那麼HTTP/2可以提升網站效能。如果你沒有,那在使用HTTP/2之前要先支援TLS。這時候,使用TLS的效能損耗大致可以被使用HTTP/2的效能提升抵銷。不過還是建議你在實際應用之前先測試一下。

  HTTP/2有五大優勢。

  1. 每個伺服器只用一個連線。HTTP/2對每個伺服器只使用一個連線,而不是每個檔案一個連線。這樣,就省掉了多次建立連線的時間,這個時間對TLS尤其明顯,因為TLS連線費時間。
  2. 加速TLS交付。HTTP/2只需一次耗時的TLS握手,並且通過一個連線上的多路利用實現最佳效能。HTTP/2還會壓縮首部資料,省掉HTTP/1.x時代所需的一些優化工作,比如拼接檔案,從而提高快取利用率。
  3. 簡化Web應用。使用HTTP/2可以讓Web開發者省很多事,因為不用再做那些針對HTTP/1.x的優化工作了。
  4. 適合內容混雜的頁面。HTTP/2特別適合混合了HTML、CSS、JavaScript、圖片和有限多媒體的傳統頁面。瀏覽器可以優先安排那些重要的檔案請求,讓頁面的關鍵部分先出現,快出現。
  5. 更安全。通過減少TLS的效能損失,可以讓更多應用使用TLS,從而讓使用者資訊更安全。

  HTTP/2的多路複用示意圖

  相應地,HTTP/2也有五個不足之處。

  1. 單連線開銷比較大。HPACK資料壓縮演算法會更新兩端的查詢表。這樣可以讓連線有狀態,而破壞狀態就意味著要重建查詢表,另外單連線佔用記憶體較多。
  2. 你可能不需要SSL。如果你的資料不需要保護,或者已經使用DRM或其他編碼進行保護了,那麼TLS的安全性對你可能無所謂。
  3. 需要拋棄針對HTTP/1.x的優化。HTTP/1.x優化在支援HTTP/2的瀏覽器中會影響效能,因此可能需要花時間把它們推倒重來。
  4. 對下載大檔案不利。如果你的應用主要提供大檔案下載或者流媒體播放,那可能不想用TLS,而且在只有一個流的情況下,多路複用也體現不出什麼優勢。
  5. 你的客戶也許不在乎。你的客戶很可能不在乎他分享的自家貓咪的視訊是否受到TLS和HTTP/2的保護。

  總之,一切要看效能。這方面,有好訊息也有壞訊息。

  好訊息是我們在內部對NGINX做過測試,結果從理論上能夠得到印證:對於要通過典型網路延遲請求的混合內容網頁,HTTP/2的效能好於HTTP/1.x和HTTPS。基於連線的RTT,結果可以分三種情況。

  • 很低的RTT(0-20ms):HTTP/1.x、HTTP/2和HTTPS基本無差別。
  • 典型網路RTT(30-250ms):HTTP/2比HTTP/1.x快,而且它們都比HTTPS快。美國兩個相鄰城市間的RTT約為30 ms,而東西海岸間(約3000英里)則約為70 ms。東京到倫敦間最短路徑的RTT大約240 ms。
  • 高RTT(300ms及以上):HTTP/1.x比HTTP/2快,後者又比HTTPS快。

First painting graph for HTTP, HTTP/2, and HTTPS

  這張圖顯示了首次渲染的時間,也就是使用者第一次在自己螢幕上看到網頁內容的時間。這個時間一般認為關係到使用者對網站響應速度的感知。

  要想了解我們測試的更多內容,請看這個HTTP/2的介紹視訊,來源是nginx.conf 2015。

  然而,每個網頁都不相同,實際上每個使用者的會話也不一樣。如果你託管流媒體或提供大檔案下載,那你的決定可能不一樣,甚至相反。

  你最終可能發現投入產出比並不明顯。如果是這樣,那你得多學習一下,針對自己的內容多做一些測試,然後我們們可以聊一聊。(想找點資料?可以看看NGINX網路研討:What’s New in HTTP/2?)。

 建議二:終止HTTP/2和TLS

  終止協議意味著客戶端使用期望的協議連線代理伺服器,比如TLS或HTTP/2,然後代理伺服器再去連線應用伺服器、資料庫伺服器等,但不需要使用相同的協議,如下圖所示。

Terminate HTTP/2 and TLS with NGINX diagram

  使用獨立的伺服器終止協議意味著使用多伺服器架構。多伺服器可能是多個物理伺服器、多個虛擬伺服器,或者AWS這樣的雲環境中的多個虛擬伺服器例項。多伺服器就比單伺服器複雜,或者比應用伺服器/資料庫伺服器的組合複雜。不過,多伺服器架構有很多好處,而且很多流量大的網站也必須用這種架構。

  配置了伺服器或者虛擬伺服器之後,很多事情都成為可能。新伺服器可以分擔其他伺服器的負載,可用於負載平衡、靜態檔案快取和其他用途。另外,也可以讓新增和替換應用伺服器或其他伺服器更容易。

  NGINX和NGINX Plus經常被用來終止TLS和HTTP/2協議、負載平衡。已有環境不必改動,除非要把NGINX伺服器挪到前端。

 建議三:考慮從SPDY開始

  SPDY是HTTP/2的上一代,總體效能相同。因為它已經出現好幾年了,所以有很多瀏覽器支援SPDY不支援HTTP/2。不過,在本文寫作時,這個支援上的差距正在縮小。具體來說,有三分之二的瀏覽器支援HTTP/2,而有五分之四的瀏覽器支援SPDY。

  如果你著急採用新的Web傳輸協議,又想盡可能覆蓋更多使用者,可以先從SPDY開始。然後到2016年初,即谷歌不再支援SPDY的時候,再切換到HTTP/2,很簡單,至少在NGINX中如此。那時候,更多使用者會擁有支援HTTP/2的瀏覽器,而你已經為其中大部分使用者提供了很好的效能。

 建議四:找出為HTTP/1.x優化的程式碼

  在決定採用HTTP/2之前,首先得知道你的程式碼有哪些是針對HTTP/1.x優化過的。大概有四方面的優化。

  1. 分域儲存。為了實現並行請求檔案,你可能把檔案分散到了不同的域裡,CDN會自動這麼做。但分域儲存會影響HTTP/2的效能,建議使用HTTP/2友好的分域儲存(建議七),只針對HTTP/1.x使用者分域。
  2. 雪碧圖。雪碧圖把很多圖片拼成一個檔案,然後通過程式碼按需取得每個圖片。雪碧圖在HTTP/2的環境下沒太大用處,但還是有點用的。
  3. 拼接的程式碼檔案。與使用雪碧圖的原因類似,很多獨立的檔案也會被弄成一個,然後瀏覽器再從其中找到並執行需要的檔案。
  4. 插入行內的檔案。CSS程式碼、JavaScript程式碼,甚至圖片等被直接插到HTML檔案中的內容。這樣可以減少檔案傳輸,代價是初始HTML檔案較大。

  後面三種優化都涉及把小檔案塞進一個較大的檔案裡,目的是減少新建連線的初始化和握手,這些操作對TLS而言非常費時間。

  第一種優化即分域儲存恰恰相反,強制開啟多個連線,目的是並行地從不同的域獲取檔案。這兩種看似矛盾的技術對於HTTP/1.x下的站點卻十分有效。然而,要用好這兩種技術,必須投入大量時間、精力和資源,用於實現、管理和運維。

  在採用HTTP/2之前,需要找出應用了這些優化的程式碼,分析一下它們會不會影響你的應用設計和工作流程。這樣在遷移到HTTP/2之後,就可以著手改造它們,甚至撤銷某些優化。

 建議五:部署HTTP/2或SPDY

  事實上,部署HTTP/2或SPDY並不難。如果你使用NGINX,只要在配置檔案中啟動相應的協議就可以了,參見這裡瞭解如何啟用HTTP/2(PDF)。瀏覽器和伺服器會協商採用什麼協議,如果瀏覽器支援HTTP/2(而且也在使用TLS),就會使用HTTP/2。

  配置完伺服器後,使用支援HTTP/2瀏覽器的使用者就會基於HTTP/2執行你的應用,而使用舊版本瀏覽器的使用者則會繼續使用HTTP/1.x執行你的應用,如下圖所示。如果你的網站流量非常大,那麼應該監測改變前後的效能,對於效能降低的情況,可能就得撤銷更改。

HTTP/2 implemented at server level supports browsers for both HTTP/2 and HTTP/1.x

  注意:使用HTTP/2及其單連線之後,NGINX某些配置的重要性會很明顯,特別要注意的是output_buffers、proxy_buffers和ssl_buffer_size等指令,多測試一下。參見general configuration notes,特定的SSL建議(在這裡 and here),以及NGINX關於SSL效能的白皮書(PDF)。

  注意:使用HTTP/2傳輸密文要格外注意。HTTP/2的RFC中有一個長長的列表,列出了要避免的加密套件。建議你自己也搞一個表格,啟用ssl_buffer_size,然後在所有常用的瀏覽器版本下測試你想用的加密套件。

 建議六:再談HTTP/1.x優化

  你說奇怪不,撤銷和修改針對HTTP/1.x優化的程式碼居然是實現HTTP/2最有創意的部分。這裡面有幾個問題要注意,因為很多事怎麼做都是可以的。

  在開始運作之前,必須考慮舊版本瀏覽器使用者是否好過。之後,可以採取三個策略撤銷和修改HTTP/1.x的優化。

  • 什麼也不用做。假如你並沒有針對HTTP/1.x做過優化,或者只做過少量優化,那麼你幾乎什麼也不用做,就可以直接遷移到HTTP/2。
  • 有選擇地去做。第二種情況是減少合併某些檔案,而不是完全不合並。比如,牽扯到很多場景的雪碧圖就不用動,而被塞得滿滿的HTML可能就要分離出來一些。
  • 完全撤銷HTTP/1.x優化(不過請先參考建議七中關於分域儲存的建議)。可以不再做以前做過的任何優化。

  快取還是普適的。理論上,快取操作非常適合小檔案特別多的情況。但是,小檔案多也意味著檔案I/O多。因此一些相近檔案的合併還是必要的,一方面要考慮工作流程,另一方面要考慮應用效能。建議多關注一下其他人在過渡到HTTP/2過程中的一些經驗。

 建議七:實現智慧分域

  分域儲存可能是最極端但也最成功的HTTP/1.x優化策略。它能夠提升HTTP/1.x下的應用效能,但在HTTP/2之下,其效能提升可以忽略不講(因為只有一個連線。)

  對HTTP/2友好的分域,要保證以下兩點。

  • 讓多個域名解析到同一個IP。
  • 確保證照包含萬用字元,以便所有分域名都可以使用,適當的多域證照當然也可以。

  具體細節,請參考這裡

  有了這些保障,分域還會繼續對HTTP/1.x有效,即域名仍然可以觸發瀏覽器建立更多連線,但對HTTP/2則無效,因為這些域名會被看成同一個域,一個連線就可以訪問所有域名了。

 小結

  HTTP/2和TLS組合可以提升你的站點效能,並且讓使用者覺得你的網站很安全。無論你是率先在自己的應用裡實現HTTP/2,還是要趕超競爭對手,都可以又快又好地實現對HTTP/2的支援。

  希望這篇文章能讓你以最少的努力獲得最大的HTTP/2效能收益,而且從此你可以把注意力集中到編寫更快、更有效、更安全的應用上,讓自己的應用更容易維護和運維。

 參考資源

  原文:https://www.nginx.com/blog/7-tips-for-faster-http2-performance/

相關文章