http/2時代的web性能

2015年HTTP/2已經開始取代SPDY而登上歷史的舞臺。一直以來我們耳熟能詳的那些Web性能優化技術，很可能會成爲歷史。HTTP/2在Web性能優化方面有哪些優勢呢？與HTTP/1.1有什麼不同？

本文和本次分享參考：第二屆前端開發者大會講師Holger Bartel的ppt

本文是爲分享的PPT做準備的。敘述可能不具體和不到位。分享：Lecture 01 HTTP/2時代的Web性能

Slider: http://slides.com/wujiarong/deck#/

0 等待和延遲

生活中，我們經常處於各種各樣的等待狀態。

當我們打開瀏覽器。情況仍然得不到很好的改善。

loading…

沒有人願意等待。通常，等待都要等很長時間。

你應該聽朋友說過。請等我一下，結果等了十幾分鍾。
你應該聽女朋友說過。很快就好，結果等了將近1小時。

沒有人喜歡等待。

何爲等待：

直到某個時間點或者某個事件發生，才採取某些行動的延遲行爲。

等待即延遲

1 網頁性能

定義：wiki百科

Web performance refers to the speed in which web pages are downloaded and displayed on the user’s web browser.

由此可見。web性能分爲兩個部分：網頁加載的速度和網頁渲染出來的速度。

網頁加載的速度往往用時間來衡量。也就是網頁加載時間。我們通常說是，網頁性能。

一般來說，我們說網頁性能，說的其實是網頁加載時間：page loading time。顧名思義，這個時間當然是越短越好。

隨着互聯網和web技術的快速發展，我們想呈現給用戶的東西越來越多。從一開始的純文本、到少量圖片、到更多的圖片、甚至視頻。

爲了提升用戶體驗，使得呈現內容以更友好的形式呈現給用戶。我們開始添加大量的css改善效果，添加js動畫和css3動畫增加動態性。

用戶角度所謂的快：期待2-3秒加載一個網頁。

50%的用戶會關掉瀏覽器的tab，如果一個網頁加載時間超過4s。

無可厚非，動態性的增加和呈現優化，大大地提升了用戶體驗。但隨之而來的代價是，網頁加載時間越來越長。

研究表明，1s時間的網頁延遲，將導致：

減少11%的網頁瀏覽量
減少16%的用戶滿意度
減少7%的利潤轉化

我們來看一個用戶體驗表格。

From: Chapter 10. Primer on Web Performance

web性能社區的非官方公認：在250ms內，頁面加載完成或者能有儘可能多的可視化反饋，能留住用戶！

總結：越快越好！

2 web性能影響案例

亞馬遜：網頁加載速度增加100ms，銷售額減少1%（參考：Amazon）

Walmart: 每優化1s，增加2%的利潤轉化。

Akamai研究發現：

47%的用戶希望網頁在2s以內加載完成
40%的用戶會關閉網頁，如果網頁加載時間超過3秒
52%的網購者更願意到網頁加載速度更快的購物網站購物

3 全球帶寬情況

兩個數據

全球平均帶寬（下載）：21.3Mbps (21.3/8 MB/s)

全球手機平均下載速度：10.9Mbps (10.9/8 MB/s)

From: netindex

幾張圖片

全球下載帶寬情況：

歐洲：

北美：

南美洲：

非洲：

Bandwidth and Round-Trip Time

RTT(Round-Trip Time): 往返時延。在計算機網絡中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。

更大的帶寬不代表更快的網頁加載速度！More Bandwidth Doesn’t Matter(much)

相對帶寬，RTT對於網頁性能的影響更大。

結論：
增加帶寬對網頁加載速度的提升不會有很大的影響。相反，應該減少RTT，或者RTT的個數。

4 改善web性能

4.0 HTTP是如何工作的？

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。

1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法，並稱之爲超文本（hypertext）,這成爲了HTTP超文本傳輸協議標準架構的發展根基。

Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和互聯網工程工作小組（Internet Engineering Task Force ）共同合作研究，最終發佈了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。

短視頻視頻：Basic concepts of web applications, how they work and the HTTP protocol

Different types of HTTP requests

GET：This request is Used to get the Response header and the response body
HEAD：This request is used to get back The response header only (not the response body as returned by the GET request..)
POST：This request is used to submit data (eg : for to be used in HTML forms etc..)…
PUT：Used for uploading resource
PATCH：Is used to modify the resource
DELETE：Used for deleting resource
TRACE：simply echoes back the request sent by the client…This can be used for testing the servers and Checking weather the server is alive or not..

使用Telnet展現HTTP請求

Telnet www.baidu.com 80
GET / HTTP/1.1
TRACE / HTTP/1.1

4.1 HTTP/0.9 (1991)

HTTP 0.9作爲HTTP協議的第一個版本。是非常弱的。請求(Request)只有一行,比如:

GET www.cnblogs.com

從如此簡單的請求體，沒有POST方法，沒有HTTP 頭可以看出，那個時代的HTTP客戶端只能接收一種類型：純文本。並且，如果得不到所求的信息，也沒有404 500等錯誤出現。

雖然HTTP 0.9看起來如此弱，但已經能滿足那個時代的需求了。

4.2 HTTP/1.0 (1996)

由於萬維網需求激增，HTTP/0.9深感不能滿足需求。這時候，拓展了很多功能的HTTP/1.0出來了。

HTTP/1.1的變化包括：

引入了POST方法
引入了HTTP頭、狀態碼
HTTP傳輸內容不侷限於文本。可以是圖片、視頻、文檔等

4.3 HTTP/1.1 (1999)

HTTP/1.1相對於1.0的改變不算太大。

主要是：
1. 增加了host頭字段。
2. 增加了Range字段，使得客戶端通過HTTP下載時只下載內容的一部分，這使得多線程下載也成爲可能。

這裏對於HTTP/1.1及以前的幾個版本不做具體且深入的介紹。如果有興趣或者質疑，請自行google。

從1.1發佈到SPDY提出，中間11年時間。HTTP在這麼長的時間內沒有做任何更新。

我們知道HTTP/1.1在web性能方面存在着很多問題。

比如：

較爲龐大的HTTP Head，佔用較多的網絡流量。
明文傳輸，不安全。
非持久連接：每個請求都要建立TCP連接，耗時巨大。
持久連接：單個TCP連接，可以發送多次請求。但是多個請求之間是有先後順序的，後面發送的請求必須等待上一個請求返回才能發送響應。這會很容易導致後面的請求被阻塞，同樣耗時。

這些問題足以導致出現很多安全性問題，和很差的網頁性能，也就是很長的網頁加載時間。

爲了解決這些問題。關注web性能的社區或公司，就想出了很多的處理方案和誕生了一些針對改善web性能的技術。

比如：
雅虎14條網頁性能優化原則。參考：YaHoo Web優化的14條法則

減少HTTP請求次數
使用CDN(Content Delivery Network, 內容分發網絡)
增加Expires Header（web cache）
壓縮頁面元素
把樣式表放在頭上
把腳本文件放在底部
避免CSS表達式
把JavaScript和CSS放到外部文件中
減少DNS查詢次數
最小化JavaScript代碼
避免重定向
刪除重複的腳本文件
配置ETags
緩存Ajax

我們來分析一下什麼因素影響網頁性能，也就是會延長網頁的加載時間。

一個網頁，從瀏覽器請求，到服務器響應，返回數據或者資源，到瀏覽器接受完畢。其實宏觀來說涉及了三個對象。

瀏覽器：請求數量影響PLT
路由網絡：帶寬和RTT影響PTL
服務器：服務器響應時間、數據庫響應時間等影響PTL

我們暫時不討論服務器響應時間，因爲這個是人爲可控的，而且一般來說是後臺工程師的任務。

我們來看看瀏覽器和路由網絡對PTL的影響。

在瀏覽器端，請求數量多少取決於網頁結構和內容。如果圖片、小圖標、CSS文件、JS文件等太多，請求數量自然居高不下。這樣就大大增加了PTL。

因此，在瀏覽器這個對象的視角。我們應該儘可能減少請求次數、增加併發連接數、儘量避免阻塞加載。

這樣就產生了以上14條實踐中的：1、3、5、6、8、12、13、14

從路由網絡的視角。影響PTL的，是我們上面分析過的兩個指標：帶寬和RTT。

因此，在資源傳輸的中間環節，我們可以通過：增加帶寬、帶寬一定是減少數據量、減少RTT，這三個途徑來減少PTL。

也因此產生了14條實踐中的：2、4、9、10、11

把以上的內容再歸結起來，涉及到的技術就有：

文件拼接和壓縮
雪碧圖
Inline Image
Domain Sharding

爲了從根本上解決以上的問題，而不是需要前端後臺工程師做大量的性能優化工作，一個偉大的嘗試出現了。那就是SPDY。

4.4 SPDY (2010)

我們看看SPDY做了什麼。參考：SPDY 協議介紹

多路複用
允許在一個TCP連接裏面，允許無限併發流（在雙方資源可承受的情況下）。因爲請求是在一個單一的通道交錯傳輸，TCP的可以達到很高的效率，從而更少的網絡連接需要，可以以很高的數據密度做傳輸。
具備優先級的請求
雖然無限的並行數據流的解決了序列化的問題，但是它們引入了另一個問題：如果由於信道帶寬的限制，客戶端可能會阻止怕堵塞通道的要求。爲了克服這個問題，SPDY實現請求的優先次序：客戶端可以請求儘可能多的項目，每個請求分配一個優先級。這樣即使高優先級的請求仍處在pending狀態，通道也不會傳輸非關鍵的，低優先級的請求，這樣就有效地阻止了傳輸擁塞。
HTTP Header 壓縮
對於HTTP 請求，響應頭，SPDY都做了壓縮，這樣包更小，對於RESTFUL類型的WEB2.0 ,or OpenAPI 業務，將會有可觀的效率提升。
服務器端推送
SPDY通過X-Associated-Content 協議頭來向客戶端推送數據，頭通知客戶端，我要向你推送資源，準備接收好了。最近火爆的Google+ ,如果你用chrome瀏覽器，默認就採用SPDY技術，並且開啓了服務器推送技術。服務器的推技術，全面提升了用戶體驗，是G+ 產品很快佔據了足夠多的優勢，最近Facebook 開發自己的瀏覽器，也有擺脫現在技術限制的考慮
服務器暗示
不像上面提到的PUSH 技術，服務器會先告訴瀏覽器，你可以下載ABC資源了，這個ABC資源，可能就是下一個頁面的JS ,CSS ，或者內容。服務器不會主動推送的，仍舊等待客戶端請求，這對於低速網絡，是個很大的優化，有點類似於我們的預加載技術。

4.5 HTTP/2 (2015)

HTTP/2基於SPDY，優於SPDY。參考：HTTP/2 新特性淺析

不同點：

HTTP/2 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
HTTP/2 消息頭的壓縮算法採用 HPACK ，而非 SPDY 採用的 DELEFT

HTTP2優勢：

HTTP/2 採用二進制格式傳輸數據，而非 HTTP/1.x 的文本格式。二進制格式在協議的解析和優化擴展上帶來更多的優勢和可能。
HTTP/2 對消息頭採用 HPACK 進行壓縮傳輸，能夠節省消息頭佔用的網絡的流量。而 HTTP/1.x 每次請求，都會攜帶大量冗餘頭信息，浪費了很多帶寬資源。頭壓縮能夠很好的解決該問題。
多路複用，直白的說就是所有的請求都是通過一個 TCP 連接併發完成。HTTP/1.x 雖然能利用一個連接完成多次請求，但是多個請求之間是有先後順序的，後面發送的請求必須等待上一個請求返回才能發送響應。這會很容易導致後面的請求被阻塞，而 HTTP/2 做到了真正的併發請求。
同時，流還支持優先級和流量控制。
Server Push：服務端能夠更快的把資源推送給客戶端。例如服務端可以主動把 JS 和 CSS 文件推送給客戶端，而不需要客戶端解析 HTML 再發送這些請求。當客戶端需要的時候，它已經在客戶端了。