http/2的重要特性完全源自spdy。
http/2是二進制（而文本）協定，是以更簡潔高效；
它針對每個域隻使用一個多路複用的連接配接，而不是每個檔案一個連接配接；
首部使用特制的hpack協定（而非spdy中使用的gzip）壓縮；
http/2設計了複雜的優先級排定規則，幫助浏覽器首先請求最急需的檔案，而nginx已經支援（spdy的方案要簡單一些）。
現在，你需要決定是否遷移到http/2，而其中關鍵是知道如何最大限度地利用它。這篇文章會帶你了解從性能角度考慮為什麼要做這個決定，以及如何實作。接下來我們要逐一讨論關于http/2性能的7個小建議。
現在是否需要遷移到http/2
終止http/2和tls
考慮從spdy開始
找出為http/1.x優化的代碼
部署http/2或spdy
再談http/1.x優化
實作智能分域
注意：嚴格來講，spdy和http/2都不需要tls，但它們在使用ssl/tls的時候用處最大，而且浏覽器隻在使用ssl/tls時才支援spdy或http/2。
<a target="_blank"></a>
如果你使用ssl/tls（以後簡稱tls），那麼http/2可以提升網站性能。如果你沒有，那在使用http/2之前要先支援tls。這時候，使用tls的性能損耗大緻可以被使用http/2的性能提升抵銷。不過還是建議你在實際應用之前先測試一下。
http/2有五大優勢。
每個伺服器隻用一個連接配接。http/2對每個伺服器隻使用一個連接配接，而不是每個檔案一個連接配接。這樣，就省掉了多次建立連接配接的時間，這個時間對tls尤其明顯，因為tls連接配接費時間。
加速tls傳遞。http/2隻需一次耗時的tls握手，并且通過一個連接配接上的多路利用實作最佳性能。http/2還會壓縮首部資料，省掉http/1.x時代所需的一些優化工作，比如拼接檔案，進而提高緩存使用率。
簡化web應用。使用http/2可以讓web開發者省很多事，因為不用再做那些針對http/1.x的優化工作了。
适合内容混雜的頁面。http/2特别适合混合了html、css、javascript、圖檔和有限多媒體的傳統頁面。浏覽器可以優先安排那些重要的檔案請求，讓頁面的關鍵部分先出現，快出現。
更安全。通過減少tls的性能損失，可以讓更多應用使用tls，進而讓使用者資訊更安全。
http/2的多路複用示意圖
相應地，http/2也有五個不足之處。
單連接配接開銷比較大。hpack資料壓縮算法會更新兩端的查找表。這樣可以讓連接配接有狀态，而破壞狀态就意味着要重建查找表，另外單連接配接占用記憶體較多。
你可能不需要ssl。如果你的資料不需要保護，或者已經使用drm或其他編碼進行保護了，那麼tls的安全性對你可能無所謂。
需要抛棄針對http/1.x的優化。http/1.x優化在支援http/2的浏覽器中會影響性能，是以可能需要花時間把它們推倒重來。
對下載下傳大檔案不利。如果你的應用主要提供大檔案下載下傳或者流媒體播放，那可能不想用tls，而且在隻有一個流的情況下，多路複用也展現不出什麼優勢。
你的客戶也許不在乎。你的客戶很可能不在乎他分享的自家貓咪的視訊是否受到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快。
首次渲染時間
這張圖顯示了首次渲染的時間，也就是使用者第一次在自己螢幕上看到網頁内容的時間。這個時間一般認為關系到使用者對網站響應速度的感覺。
然而，每個網頁都不相同，實際上每個使用者的會話也不一樣。如果你托管流媒體或提供大檔案下載下傳，那你的決定可能不一樣，甚至相反。
終止協定意味着用戶端使用期望的協定連接配接代理伺服器，比如tls或http/2，然後代理伺服器再去連接配接應用伺服器、資料庫伺服器等，但不需要使用相同的協定，如下圖所示。
終止 http/2 和 tls
配置了伺服器或者虛拟伺服器之後，很多事情都成為可能。新伺服器可以分擔其他伺服器的負載，可用于負載平衡、靜态檔案緩存和其他用途。另外，也可以讓添加和替換應用伺服器或其他伺服器更容易。
nginx和nginx plus經常被用來終止tls和http/2協定、負載平衡。已有環境不必改動，除非要把nginx伺服器挪到前端。
如果你着急采用新的web傳輸協定，又想盡可能覆寫更多使用者，可以先從spdy開始。然後到2016年初，即谷歌不再支援spdy的時候，再切換到http/2，很簡單，至少在nginx中如此。那時候，更多使用者會擁有支援http/2的浏覽器，而你已經為其中大部分使用者提供了很好的性能。
在決定采用http/2之前，首先得知道你的代碼有哪些是針對http/1.x優化過的。大概有四方面的優化。
分域存儲。為了實作并行請求檔案，你可能把檔案分散到了不同的域裡，cdn會自動這麼做。但分域存儲會影響http/2的性能，建議使用http/2友好的分域存儲（參見建議七），隻針對http/1.x使用者分域。
圖檔精靈sprites。圖檔精靈把很多圖檔拼成一個檔案，然後通過代碼按需取得每個圖檔。圖檔精靈在http/2的環境下沒太大用處，但還是有點用的。
拼接的代碼檔案。與使用圖檔精靈的原因類似，很多獨立的檔案也會被弄成一個，然後浏覽器再從其中找到并運作需要的檔案。
内聯檔案。css代碼、javascript代碼，甚至圖檔等被直接插到html檔案中的内容。這樣可以減少檔案傳輸，代價是初始html檔案較大。
後面三種優化都涉及把小檔案塞進一個較大的檔案裡，目的是減少建立連接配接的初始化和握手，這些操作對tls而言非常費時間。
第一種優化即分域存儲恰恰相反，強制打開多個連接配接，目的是并行地從不同的域擷取檔案。這兩種看似沖突的技術對于http/1.x下的站點卻十分有效。然而，要用好這兩種技術，必須投入大量時間、精力和資源，用于實作、管理和運維。
在采用http/2之前，需要找出應用了這些優化的代碼，分析一下它們會不會影響你的應用設計和工作流程。這樣在遷移到http/2之後，就可以着手改造它們，甚至撤銷某些優化。
配置完伺服器後，使用支援http/2浏覽器的使用者就會基于http/2運作你的應用，而使用舊版本浏覽器的使用者則會繼續使用http/1.x運作你的應用，如下圖所示。如果你的網站流量非常大，那麼應該監測改變前後的性能，對于性能降低的情況，可能就得撤銷更改。
在伺服器支援 http/2 和 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性能收益，而且從此你可以把注意力集中到編寫更快、更有效、更安全的應用上，讓自己的應用更容易維護和運維。
本文來自雲栖社群合作夥伴“linux中國”，原文釋出日期：2015-11-09