摘要:相比之前的傳輸協議,HTTP/2在底層方面做了很多優化。有安全、省時、簡化開發、更好的適應復雜頁面、提供緩存利用率等優勢,阿里云早在去年發布的CDN6.0服務就已正式支持HTTP/2,訪問速度最高可提升68%。
寫在前面
超文本傳輸協議(英文:HyperText Transfer Protocol,縮寫:HTTP)是互聯網上應用最為廣泛的一種網絡協議。設計 HTTP 最初的目的是為了提供一種發布和接收 HTML 頁面的方法。通過 HTTP 或者 HTTPS 協議請求的資源由統一資源標識符(URI)來標識。雖然HTTP/1.1穩定運行了十多年了,但HTTP/2來勢洶洶,作為技術工程師有必要學習一下HTTP/2。
1.Web始祖HTTP
處于計算機網絡中的應用層,HTTP是建立在TCP協議之上,所以HTTP協議的瓶頸及其優化技巧都是基于TCP協議本身的特性,例如tcp建立連接的3次握手和斷開連接的4次揮手以及每次建立連接帶來的RTT延遲時間。
(1)HTTP/0.9
最早的原型,1991年發布,該版本極其簡單,只支持 GET 方法,不支持 MIME 類型和各種 HTTP 首部等等。
(2)HTTP/1.0
1996年發布。HTTP/1.0在HTTP/0.9的基礎之上添加很多方法,各種 HTTP 首部,以及對多媒體對象的處理。
除了GET命令,還引入了POST命令和HEAD命令,豐富了瀏覽器與服務器的互動手段。
任何格式的內容都可以發送。這使得互聯網不僅可以傳輸文字,還能傳輸圖像、視頻、二進制文件。這為互聯網的大發展奠定了基礎。
HTTP請求和回應的格式也變了。除了數據部分,每次通信都必須包括頭信息(HTTP header),用來描述一些元數據。
可以說,HTTP/1.0是對HTTP/0.9做了革命性的改變,但HTTP/1.0依然有一些缺點,其主要缺點是每個TCP連接只能發送一個請求,發送數據完畢后連接就關閉,如果還要請求其他資源,就得再新建一個連接。雖然有些瀏覽器為了解決這個問題,用了一個非標準的Connection頭部,但這個不是標準頭部,各個瀏覽器和服務器實現有可能不一致,因此不是根本解決辦法。
(3)HTTP/1.1
1999年正式發布。HTTP/1.1是當前主流的 HTTP 協議。完善了之前 HTTP 設計中的結構性缺陷,明確了語義,添加和刪除了一些特性,支持更加復雜的的 Web 應用。
經過了十多年將近20年的發展,這個版本的HTTP協議已經很穩定了,跟HTTP/1.0相比,它新增了很多引人注目的新特性,比如Host協議頭、Range分段請求、默認持久連接、壓縮、分塊傳輸編碼(chunked)、緩存處理等等,至今都大量使用,而且很多軟件依賴這些特性。
雖然HTTP/1.1并不像HTTP/1.0對于HTTP/0.9那樣的革命性,但是也有很多增強,目前主流瀏覽器均默認采用HTTP/1.1。
(4) SPDY
SPDY(發音:speedy)協議由Google開發,主要解決 HTTP/1.1 效率不高的問題,于2009年公開,到2016年初結束使命。因為HTTP/2已經被IETF標準化了,以后各種新版瀏覽器都會支持HTTP/2,Google認為SPDY已經沒有存在的必要了,接下來的使命由HTTP/2去完成。
(5)HTTP/2
HTTP/2是最新的HTTP協議,已于2015年5月份正式發布, Chrome、 IE11、Safari以及Firefox 等主流瀏覽器已經支持 HTTP/2協議。
注意是HTTP/2而不是HTTP/2.0,這是因為IETF(Internet Engineering Task Force,互聯網工程任務組)認為HTTP/2已經很成熟了,沒有必要再發布子版本了,以后要是有重大改動就直接發布HTTP/3。
其實,HTTP/2的前身是SPDY,甚至它倆的目標、原理和基本實現都差不多。IETF組委會中有很多Google工程師,將SPDY推動成為標準也就不足為奇了。
HTTP/2不僅優化了性能而且兼容了HTTP/1.1的語義,其幾大特性與SPDY差不多,與HTTP/1.1有巨大區別,比如它不是文本協議而是二進制協議,而且HTTP頭部采用HPACK進行壓縮,支持多路復用、服務器推送等等。
2. HTTP與現代化瀏覽器
早在HTTP建立之初,主要就是為了將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。也是說對于前端來說,我們所寫的HTML頁面將要放在我們的web服務器上,用戶端通過瀏覽器訪問url地址來獲取網頁的顯示內容,但是到了WEB2.0以來,我們的頁面變得復雜,不僅僅單純的是一些簡單的文字和圖片,同時我們的HTML頁面有了CSS,Javascript,來豐富我們的頁面展示,當ajax的出現,我們又多了一種向服務器端獲取數據的方法,這些其實都是基于HTTP協議的。同樣到了移動互聯網時代,我們頁面可以跑在手機端瀏覽器里面,但是和PC相比,手機端的網絡情況更加復雜,這使得我們開始了不得不對HTTP進行深入理解并不斷優化過程中。
3.HTTP 的基本優化
影響一個HTTP網絡請求的因素主要有兩個:帶寬和延遲。
- 帶寬:如果說我們還停留在撥號上網的階段,帶寬可能會成為一個比較嚴重影響請求的問題,但是現在網絡基礎建設已經使得帶寬得到極大的提升,我們不再會擔心由帶寬而影響網速,那么就只剩下延遲了。
延遲:
- 瀏覽器阻塞(HOL blocking):瀏覽器會因為一些原因阻塞請求。瀏覽器對于同一個域名,同時只能有 4 個連接(這個根據瀏覽器內核不同可能會有所差異),超過瀏覽器最大連接數限制,后續請求就會被阻塞。
- DNS 查詢(DNS Lookup):瀏覽器需要知道目標服務器的 IP 才能建立連接。將域名解析為 IP 的這個系統就是 DNS。這個通常可以利用DNS緩存結果來達到減少這個時間的目的。
- 建立連接(Initial connection):HTTP 是基于 TCP 協議的,瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文,達到真正的建立連接,但是這些連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯,慢啟動則對文件類大請求影響較大。
4. HTTP/1.0和HTTP/1.1的一些區別
兩者的區別主要體現在:
- 緩存處理,在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準,HTTP1.1則引入了更多的緩存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
- 帶寬優化及網絡連接的使用,HTTP1.0中,存在一些浪費帶寬的現象,例如客戶端只是需要某個對象的一部分,而服務器卻將整個對象送過來了,并且不支持斷點續傳功能,HTTP1.1則在請求頭引入了range頭域,它允許只請求資源的某個部分,即返回碼是206(Partial Content),這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。
- 錯誤通知的管理,在HTTP1.1中新增了24個錯誤狀態響應碼,如409(Conflict)表示請求的資源與資源的當前狀態發生沖突;410(Gone)表示服務器上的某個資源被永久性的刪除。
- Host頭處理,在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址,因此,請求消息中的URL并沒有傳遞主機名(hostname)。但隨著虛擬主機技術的發展,在一臺物理服務器上可以存在多個虛擬主機(Multi-homed Web Servers),并且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域,且請求消息中如果沒有Host頭域會報告一個錯誤(400 Bad Request)。
- 長連接,HTTP 1.1支持長連接(PersistentConnection)和請求的流水線(Pipelining)處理,在一個TCP連接上可以傳送多個HTTP請求和響應,減少了建立和關閉連接的消耗和延遲,在HTTP1.1中默認開啟Connection: keep-alive,一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。
區別用一張圖來體現:
5. HTTP1.0和1.1現存的一些問題
- 上面提到過的,HTTP1.x在傳輸數據時,每次都需要重新建立連接,無疑增加了大量的延遲時間,特別是在移動端更為突出。
- HTTP1.x在傳輸數據時,所有傳輸的內容都是明文,客戶端和服務器端都無法驗證對方的身份,這在一定程度上無法保證數據的安全性。
- HTTP1.x在使用時,header里攜帶的內容過大,在一定程度上增加了傳輸的成本,并且每次請求header基本不怎么變化,尤其在移動端增加用戶流量。
- 雖然HTTP1.x支持了keep-alive,來彌補多次創建連接產生的延遲,但是keep-alive使用多了同樣會給服務端帶來大量的性能壓力,并且對于單個文件被不斷請求的服務(例如圖片存放網站),keep-alive可能會極大的影響性能,因為它在文件被請求之后還保持了不必要的連接很長時間。
6.HTTPS應聲而出
為了解決以上問題,網景在1994年創建了HTTPS,并應用在網景導航者瀏覽器中。 最初,HTTPS是與SSL一起使用的;在SSL逐漸演變到TLS時(其實兩個是一個東西,只是名字不同而已),最新的HTTPS也由在2000年五月公布的RFC 2818正式確定下來。簡單來說,HTTPS就是安全版的HTTP,并且由于當今時代對安全性要求更高,chrome和firefox都大力支持網站使用HTTPS,蘋果也在ios 10系統中強制app使用HTTPS來傳輸數據,由此可見HTTPS勢在必行。
這里簡單介紹一下HTTPS,接下來將會寫一篇有關于HTTPS詳解的文章。
7.HTTPS與HTTP的一些區別
- HTTPS協議需要到CA申請證書,一般免費證書很少,需要交費。
- HTTP協議運行在TCP之上,所有傳輸的內容都是明文,HTTPS運行在SSL/TLS之上,SSL/TLS運行在TCP之上,所有傳輸的內容都經過加密的。
- HTTP和HTTPS使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
HTTPS可以有效的防止運營商劫持,解決了防劫持的一個大問題。
8.使用SPDY加快你的網站速度
上文中提到了由Google開發,主要解決 HTTP/1.1 效率不高的問題的SPDY協議,SPDY可以說是綜合了HTTPS和HTTP兩者有點于一體的傳輸協議,主要解決:
- 降低延遲,針對HTTP高延遲的問題,SPDY優雅的采取了多路復用(multiplexing)。多路復用通過多個請求stream共享一個tcp連接的方式,解決了HOL blocking的問題,降低了延遲同時提高了帶寬的利用率。
- 請求優先級(request prioritization)。多路復用帶來一個新的問題是,在連接共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設置優先級,這樣重要的請求就會優先得到響應。比如瀏覽器加載首頁,首頁的html內容應該優先展示,之后才是各種靜態資源文件,腳本文件等加載,這樣可以保證用戶能第一時間看到網頁內容。
- header壓縮。前面提到HTTP1.x的header很多時候都是重復多余的。選擇合適的壓縮算法可以減小包的大小和數量。
- 基于HTTPS的加密協議傳輸,大大提高了傳輸數據的可靠性。
服務端推送(server push),采用了SPDY的網頁,例如我的網頁有一個sytle.css的請求,在客戶端收到sytle.css數據的同時,服務端會將sytle.js的文件推送給客戶端,當客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到,不用再發請求了。SPDY構成圖:
SPDY位于HTTP之下,TCP和SSL之上,這樣可以輕松兼容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式),同時可以使用已有的SSL功能。
兼容性:
9. HTTP/2新特性
(1)二進制協議
HTTP/2 采用二進制格式傳輸數據,而非HTTP/1.x的文本格式。消息頭和消息體均采用二進制格式,并稱之為”幀“(Frame)。Frame二進制基本格式如下:
之所以說是基本格式,是因為所有HTTP/2 Frame都是由該基本格式來封裝,類似于TCP頭,目前有10個Frame,由Type字段來區分,各個Frame都有自己的二進制格式,都封裝Frame Payload中。
其中有兩個重要的Frame:Headers Frame(Type=0x1)和Data Frame(Type=0x0),分別對應HTTP/1.1中的消息頭(Header)和消息體(Body),由此可見語義并沒有太大變化,而是文本格式變成二進制的Frame。二者的轉換和關系如下圖(摘自 《High Performance Browser Networking》):
此外,HTTP/2中還有流(Stream)和消息(Message)的概念:
- 流:流是連接中的一個虛擬信道,可以承載雙向的消息;每個流都有一個唯一的整數標識符(1、2…N);流中包含消息,這個消息對應HTTP/1.x的請求消息(Request Message)或者響應消息(Response Message)。
- 消息:是指邏輯上的 HTTP 消息,比如請求、響應等,由一或多個幀組成,消息是通過幀(Frame)來傳輸的,響應消息比較大,可能由多個Data Frame來傳輸。
- 幀:HTTP 2.0 通信的最小單位,每個幀包含幀首部,至少也會標識出當前幀所屬的流,承載著特定類型的數據,如 HTTP 首部、負荷,等等
(2)頭部壓縮
HTTP/1.x 每次請求和響應,都會攜帶大量冗余消息頭信息,比如Cookie和User Agent,基本一樣的內容,每次請求瀏覽器都會默認攜帶,這會浪費很多帶寬資源,也影響了速度。這是因為HTTP是無狀態協議,每次請求都必須附上所有信息,從而導致了每次請求都帶上大量重復的消息頭。
為此,HTTP/2做了優化,對消息頭采用HPACK格式進行壓縮傳輸,并對消息頭建立索引表,相同的消息頭只發送索引號,從而提高效率和速度。但付出的代價是客戶端和服務器均維護一個索引表,在如今內存不值錢的時代,這點空間換取時間還是非常值得的。
關于HPACK請參考RFC7541。
(3)多路復用
多路復用是指在一個TCP連接里,客戶端和服務器都可以同時發送多個請求或者響應,對HTTP/1.x來說各個請求和響應都是有嚴格的次序要求,而在HTTP/2中,不用按照次序一一對應,而且并發的多個請求或者響應中任何一個請求阻塞了不會影響其他的請求或者響應,這樣就避免了“隊頭堵塞”
(4)服務器推送
HTTP 2.0 新增的一個強大的新功能,就是服務器可以對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確地請求。
服務器推送(Server Push)是指在HTTP/2中服務器未經請求可以主動給客戶端推送資源。例如服務端可以主動把 圖片、JS 和 CSS 文件推送給瀏覽器,而不需要瀏覽器解析HTML后再發送這些請求。當瀏覽器解析HTML后這些需要的資源都已經在瀏覽器里了,大大提高了網頁加載的速度。
- HTTP 2.0 連接后,客戶端與服務器交換SETTINGS 幀,借此可以限定雙向并發的流的最大數量。因此,客戶端可以限定推送流的數量,或者通過把這個值設置為0 而完全禁用服務器推送。
- 所有推送的資源都遵守同源策略。換句話說,服務器不能隨便將第三方資源推送給客戶端,而必須是經過雙方確認才行。
PUSH_PROMISE:所有服務器推送流都由PUSH_PROMISE 發端,服務器向客戶端發出的有意推送所述資源的信號。客戶端接收到PUSH_PROMISE 幀之后,可以視自身需求選擇拒絕這個流。
幾點限制:
服務器必須遵循請求- 響應的循環,只能借著對請求的響應推送資源。
- PUSH_PROMISE 幀必須在返回響應之前發送,以免客戶端出現競態條件。
(5)安全
HTTP的安全是由SSL/TLS來保障,也就是HTTPS,其實HTTP/2并不強制要求依賴SSL/TLS,但是,當前主流瀏覽器均只支持基于SSL/TLS的HTTP/2,況且在網絡劫持日益猖獗的互聯網環境下,HTTPS將是未來的趨勢,HTTP/2基于HTTPS也是未來的趨勢,而各大主流瀏覽器在實現HTTP/2之初均只支持SSL/TLS的HTTP/2,可見安全也是HTTP/2的重要特性之一。
寫在最后
相比之前的傳輸協議,HTTP/2在底層方面做了很多優化。有安全、省時、簡化開發、更好的適應復雜頁面、提供緩存利用率等顯著的優勢,各大公司也已經紛紛開始使用HTTP/2協議了。
參考文章:
- http://www.alloyteam.com/2016/07/httphttp2-0spdyhttps-reading-this-is-enough/#prettyPhoto
- http://blog.csdn.net/zqjflash/article/details/50179235
- http://www.jianshu.com/p/748c7ca7c50f