HTTP

HTTP定義

超文本傳輸協議(HyperText Transfer Protocol) 伴隨著計算機網絡和瀏覽器的誕生，HTTP1.0也隨之而來，處于計算機網絡中的應用層，HTTP是建立在TCP協議之上，所以HTTP協議的瓶頸及其優化技巧都是基于TCP協議本身的特性，例如tcp建立連接的3次握手和斷開連接的4次揮手以及每次建立連接帶來的RTT延遲時間。關于TCP相關可以單獨作為專題討論。

HTTP的發展歷程

早在HTTP建立之初，主要就是為了將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。也是說對于前端來說，我們所寫的HTML頁面將要放在我們的web服務器上，用戶端通過瀏覽器訪問url地址來獲取網頁的顯示內容，但是到了WEB2.0以來，我們的頁面變得復雜，不僅僅單純的是一些簡單的文字和圖片，同時我們的HTML頁面有了CSS，Javascript，來豐富我們的頁面展示，當ajax的出現，我們又多了一種向服務器端獲取數據的方法，這些其實都是基于HTTP協議的。同樣到了移動互聯網時代，我們頁面可以跑在手機端瀏覽器里面，但是和PC相比，手機端的網絡情況更加復雜，這使得我們開始了不得不對HTTP進行深入理解并不斷優化過程中。

http_timeline.png

HTTP1.0和HTTP1.1

HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用于現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。

區別

緩存處理

• 1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準
• 1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

帶寬優化及網絡連接的使用

• 1.0，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續傳功能
• 1.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每次請求都要創建連接的缺點。

現存的一些問題

• HTTP1.x在傳輸數據時，每次都需要重新建立連接，無疑增加了大量的延遲時間，特別是在移動端更為突出。
• HTTP1.x在傳輸數據時，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份，這在一定程度上無法保證數據的安全性。
• HTTP1.x在使用時，header里攜帶的內容過大，在一定程度上增加了傳輸的成本，并且每次請求header基本不怎么變化，尤其在移動端增加用戶流量。
• 雖然HTTP1.x支持了keep-alive，來彌補多次創建連接產生的延遲，但是keep-alive使用多了同樣會給服務端帶來大量的性能壓力，并且對于單個文件被不斷請求的服務(例如圖片存放網站)，keep-alive可能會極大的影響性能，因為它在文件被請求之后還保持了不必要的連接很長時間。

HTTP的基本優化

影響一個HTTP網絡請求的因素主要有兩個：帶寬和延遲。

帶寬

如果說我們還停留在撥號上網的階段，帶寬可能會成為一個比較嚴重影響請求的問題，但是現在網絡基礎建設已經使得帶寬得到極大的提升，我們不再會擔心由帶寬而影響網速，那么就只剩下延遲了。

延遲

• 瀏覽器阻塞（HOL blocking）
  瀏覽器會因為一些原因阻塞請求。瀏覽器對于同一個域名，同時只能有 4 個連接（這個根據瀏覽器內核不同可能會有所差異），超過瀏覽器最大連接數限制，后續請求就會被阻塞。

• DNS 查詢（DNS Lookup）：瀏覽器需要知道目標服務器的 IP 才能建立連接。將域名解析為 IP 的這個系統就是 DNS。這個通常可以利用DNS緩存結果來達到減少這個時間的目的。

  windows上快速清楚dns緩存的方法

   ipconfig/flushdns
  

• 建立連接（Initial connection）：HTTP 是基于 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連接，但是這些連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

  
  
  http_delay.png

HTTPS

網景在1994年創建了HTTPS，并應用在網景導航者瀏覽器中。 最初，HTTPS是與SSL一起使用的；在SSL逐漸演變到TLS時，最新的HTTPS也由在2000年五月公布的RFC 2818正式確定下來。它是由Netscape開發并內置于其瀏覽器中，用于對數據進行加密和解密操作，并返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安全套接層（SSL）作為HTTP應用層的子層。（HTTPS使用端口443，而不是像HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使用40 位關鍵字作為RC4流加密算法，這對于商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。
也就是說它的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性，凡是使用了 https 的網站，都可以通過點擊瀏覽器地址欄的鎖頭標志來查看網站認證之后的真實信息，也可以通過 CA 機構頒發的安全簽章來查詢。

HTTP和HTTPS的區別

超文本傳輸協議HTTP協議被用于在Web瀏覽器和網站服務器之間傳遞信息。HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協議不適合傳輸一些敏感信息，比如信用卡號、密碼等。
為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS。為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。
HTTPS和HTTP的區別主要為以下四點：
一、https協議需要到ca申請證書，一般免費證書很少，需要交費。
二、http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
三、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
四、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

HTTPS改造

如果一個網站要全站由HTTP替換成HTTPS，可能需要關注以下幾點：

• 安裝CA證書，一般的證書都是需要收費的，這邊推薦一個比較好的購買證書網站：1）Let's Encrypt，免費，快捷，支持多域名（不是通配符），三條命令即時簽署+導出證書。缺點是暫時只有三個月有效期，到期需續簽。2Comodo PositiveSSL，收費，但是比較穩定。
• 在購買證書之后，在證書提供的網站上配置自己的域名，將證書下載下來之后，配置自己的web服務器，同時進行代碼改造。
• HTTPS 降低用戶訪問速度。SSL握手，HTTPS 對速度會有一定程度的降低，但是只要經過合理優化和部署，HTTPS 對速度的影響完全可以接受。在很多場景下，HTTPS 速度完全不遜于 HTTP，如果使用 SPDY，HTTPS 的速度甚至還要比 HTTP 快。
• 相對于HTTPS降低訪問速度，其實更需要關心的是服務器端的CPU壓力，HTTPS中大量的密鑰算法計算，會消耗大量的CPU資源，只有足夠的優化，HTTPS 的機器成本才不會明顯增加。

使用SPDY加快網站速度

2012年google如一聲驚雷提出了SPDY的方案，大家才開始從正面看待和解決老版本HTTP協議本身的問題，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時就可以直接從緩存中獲取到，不用再發請求了

HTTP2.0

起源

HTTP2.0可以說是SPDY的升級版（其實原本也是基于SPDY設計的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，主要是以下兩點：

• HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
• HTTP2.0 消息頭的壓縮算法采用 HPACK，而非 SPDY 采用的 DEFLATE

新特性

• 新的二進制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基于這種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。

• 多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。多路復用原理圖：

  
  
  duolufuyong.png

• header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。

• 服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。

參考文獻

HTTP1.0: https://tools.ietf.org/html/rfc1945
HTTP1.1: https://tools.ietf.org/html/rfc2616
HTTP2: https://tools.ietf.org/html/rfc7540
HTTPS: https://tools.ietf.org/html/rfc2818