前端階段性總結（一）： HTTP 協議，從1.0到2.0

引言： 轉前端一年了，期間工做較忙，也沒時間整理一些知識體系，此係列文章是對前端基礎的一些回顧與總結。

1、前置知識

咱們知道，HTTP是基於TCP/IP協議的。屬於TCP/IP 協議的一個子集，TCP/IP是互聯網通訊相關聯的協議族的總稱。瞭解TCP/IP協議族有助於咱們更好的理解HTTP協議。

1. 分層管理

TCP/IP協議族主要分爲:

• 應用層 :向用戶提供應用服務時通訊的活動。
• 傳輸層 :提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。
• 網絡層 :網絡層用來處理在網絡上流動的數據包。
• 數據鏈路層 ：用來處理鏈接網絡的硬件部分。

2.TCP/IP傳輸流

盜用《圖解HTTP》中的一張圖：

舉個栗子，客戶端在應用層按規範發起了一個HTTP請求，而後由傳輸層（TCP）負責將報文分片，編序發給網絡層，再由網絡層增長目標服務器的mac地址，最終由鏈路層將請求發往目標機器。服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP請求。

3. URL 和 URI

• URI：統一資源標識符
• URL：統一資源定位符

URI是一個用於標識互聯網資源名稱的字符串，最多見的形式是統一資源定位符（URL），常常指定爲非正式的網址。更罕見的用法是統一資源名稱（URN），其目的是經過提供一種途徑。用於在特定的命名空間資源的標識，以補充網址。
即URL和URN 都是 URI的子集，URI是一種抽象的概念，URL是URI的一種常見的具象表達形式。

4. 代理、網關、隧道的概念

a. 代理

簡介

代理是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時
也接收服務器返回的響應並轉發給客戶端。每次經過代理服務器轉發請求或響應時，會追加寫入 Via 首部信息。

代理的分類：

• 透明代理： 直接轉發請求，不對請求作任何加工，反之則是非透明代理
• 緩存代理： 將請求的資源緩存在代理服務器上，用於下次請求。

代理的方式:

• 正向代理 ：簡單來講，正向代理就是對服務器透明，將不一樣用戶的請求代理到某臺服務器，服務器並不知道請求來自哪一個用戶。
• 反向代理 ：反之，反向代理就是對用戶透明，將用戶的請求轉發到服務器集羣的某一臺服務器，用戶不知道本身訪問的具體是哪臺服務器。

使用代理的好處：

• 利用緩存技術減小網絡帶寬的流量。
• 組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的

b. 網關

網關的工做機制和代理十分類似，可是它可使用非http協議與服務器、數據庫進行通訊，便是說，網關在收到來自客戶端的http請求以後，能夠直接與數據庫鏈接，使用sql查詢數據庫。

c. 隧道

隧道的目的是確保客戶端能與服務器進行安全的通訊，自己不會去解析 HTTP 請求，也就是說，請求保持原樣中轉給以後的服務器，隧道會在通訊雙方斷開鏈接時結束。隧道多用於相隔較遠的兩臺服務器的安全通訊。

2、 HTTP協議

一. 什麼是HTTP？

1. 簡介

HTTP是一種屬於應用層通訊協議，它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。

2. 報文的結構

HTTP請求的報文通常是由 協議行、可選的請求頭部、請求體組成

請求：
Request line
包括：請求方法、請求的資源、HTTP協議的版本號
Request header
包括：Cache頭域、Client頭域、Cookie/Login頭域、Entity頭域、Miscellaneous頭域、Transport頭域等
空行
Request body
Response響應

回包：
Response line
包括：HTTP協議的版本號、狀態碼、消息
Response header
包括：Cache頭域、Cookie/Login頭域、Entity頭域、Miscellaneous頭域、Transport頭域、Location頭域等
空行
Response body

3. 請求的過程

一個完整的HTTP請求過程以下：

1. 用戶在瀏覽器輸入URL
2. 域名解析（DNS的尋址）
3. TCP三次握手
4. 握手成功後創建TCP通道，發起HTTP請求
5. 服務器響應HTTP請求，返回對應的響應報文
6. 客戶端開始解析渲染

4. 狀態碼

• 1XX 提示信息：請求正在處理中
• 2XX 成功錯誤碼：請求已被接受處理
• 3XX 重定向：完成請求須要附加操做
• 4XX 客戶端錯誤：請求資源有誤或者請求不合法，服務器沒法處理
• 5XX 服務器錯誤：服務器處理請求出錯

常見狀態碼：
200 OK
302 Found 暫時重定向
301 Move Permanently永久重定向
304 Not Modified 沒有內容更新，使用緩存
400 Bad Request 客戶端請求與語法錯誤
403 Forbidden 服務器拒絕提供服務
404 Not Found 請求資源不存在
500 Internal Server Error服務器發生了不可預期的錯誤
503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

5. 首部字段

首部字段通常分爲4類：

• 通用字段（connection、via、cache-control、data等）
• 請求首部字段（accept-charset、accept-encoding、If-Modified-Since、Referer、User-Agent等）
• 響應首部字段（Age、ETag 、Server、Location 等）
• 實體首部字段（Allow 、Content-Type 、Expires 、Last-Modified等）

二. 特性

HTTP被設計之初，就以簡易、靈活爲目的。它的主要特性就是簡易、靈活 、 無狀態 、無鏈接、支持B/S模式。

1. 無狀態的HTTP。

a. 簡介

• 無狀態是指：協議自己不保存狀態，即每次請求，HTTP這一層都不對請求和響應之中的狀態進行保存，後一次請求沒法得知前一次請求的信息。
• 優勢是：因爲不須要保存狀態，對CPU和內存的資源消耗減小，協議能夠更快的處理大量事務，可伸縮性也更強。
• 存在的問題: 隨着web應用的快速發展，web變得愈來愈複雜，這樣的設計卻對一些業務形成了嚴重的阻礙，好比說，一個購物網站，登錄後，每一個頁面都須要保持當前的登陸態。而不是讓用戶每次發起請求都去登陸一下。顯然，HTTP無狀態的特性沒法實現狀態的保留。因而，爲了解決這個問題，cookie 和 session 技術應運而生。

b. Cookie技術

• 概念：Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。
• 如何工做：Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前狀態信息。
• 缺點： Cookie存在長度和數量的限制，每一個domian不能超過20條，每條不能超過4kb，從安全性的角度來講，cookie容易被盜用，偷盜者無需知道Cookie中每一個字段的意義，只須要透傳cookie就能達到目的。

c. Session 技術

• 概念： Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中。
• 如何工做：session 由服務端存儲，在一次登錄操做後，服務器將登錄的帳戶信息等做爲一個session 寫入在特定等文件裏，在回包報文中使用set-cookies爲客戶端設置sessionId，最終，客戶端在發送下一次請求的時候，會帶上session信息，從而達到狀態保存的目的。因此，當客戶端禁用了cookie，sessoin也沒法工做。

d. 其餘的認證技術-token

• token驗證的大體過程是：客戶端和服務器端約定了一種特定的加密方式，好比以cookie中的某個字段經過特定的位運算，加密編碼成一串字符串。最終在請求中做爲參數傳遞給服務器，服務器在收到請求時，再使用一樣的加密方式，獲取加密串，與傳過來的參數進行對比。從而達到身份認證的關係。因爲同源的關係，cookie沒法被盜取，而加密手段也是自定義的，從而保證了安全性。

2. 無鏈接的HTTP

a.簡介：

無鏈接是指每一次請求結束後都會斷開TCP鏈接。在web技術高速發展的今天，每一個頁面須要請求的資源都日益增多，而每次請求都須要從新創建TCP鏈接，這顯然極大的增長了無心義的通訊開銷。因而，Keep-Alive 被提出，以解決TCP沒法複用的問題。

b. Keep-Alive:

a.簡介：

Keep-Alive 其實就是在協議頭裏面設置 Connection： Keep-Alive , 表示當前鏈接是持久化的，持續時間有服務器控制，在沒有接收到關閉信號時，TCP鏈接不會斷開，這樣避免了重複創建TCP請求的無用耗時。

b.問題仍然沒有解決：

keep-Alive 對應PC端的幫助很大，但在APP端，請求比較分散，且時間跨度大，將keep-Alive的時間設置爲很大顯然是不合理的。因此，通常會尋求其餘的長鏈接方案和僞長鏈接方案。這個下文會詳細介紹。

3. 存在的缺陷：

HTTP是一個優秀的協議，可是仍然存在着一些缺陷：

• 數據明文傳輸，容易被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改

可是，程序員的智慧是無窮的，既然不安全，那就讓它安全，因而，HTTPS就誕生了。

3、HTTPS

1. 什麼是HTTPS？

HTTPS是 HTTP+ SSL +TLS 的產物，用於對通訊的加密、認證、完整性保護。它並非一種新的協議，而是HTTP的某些部分由SSL和TLS代理。

2. HTTPS如何保證通訊安全（原理）？

a. 原理

咱們先來了解一下經常使用的兩種加密方式：

• 對稱加密： 加密和解密都是用同一把密鑰。
• 非對稱加密： 加密和解密是兩把不一樣的密鑰。

HTTPS 使用混合加密機制，即先經過非對稱加密交換通訊密鑰，拿到密鑰後再使用對稱加密的方式進行後續的通訊。可是如何保證第一步中，客戶端獲取到的公共密鑰是正確的呢？這時候，就須要用到咱們的數字證書了。

證書是由第三方機構提供認證的，服務器先去第三方機構申請公共密鑰，而後會得到公共密鑰和使用第三方數字簽名，在非對稱加密的過程當中，將數字證簽名和包含的公共密鑰一塊兒發給客戶端，客戶端經過第三方機構的公共密鑰對證書上的簽名進行驗證，一旦經過，則說明公共密鑰是正確的。

b. 請求過程

下面看看具體的安全通訊創建過程：

1. 客戶端發起client hello 報文， 攜帶客戶端支持的ssl版本、加密相關的約定（密鑰長度和加密算法）。
2. 服務器響應 server hello 報文， 表示能夠進行ssl通訊，並攜帶相關加密約定。
3. 服務器發送 certificate 報文, 攜帶了公共密鑰的證書。
4. 服務器發送 server hello done，表示最初的ssl協商部分結束。
5. 客戶端發起 Client Key Exchange 報文，並攜帶使用第一階段協商以後獲得的Pre-master

secret加密隨機串（對稱密鑰）。

1. 客戶端發起 Change Cipher Spec 報文，表示以後的請求將使用Pre-master secret進行加密通訊
2. 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。
3. 服務器發送 Change Cipher Spec 報文，表示解密成功，下面將使用協商的密鑰進行安全通訊。
4. 服務器發送 Finished 報文，至此，一個安全的通訊已經簡歷。
5. 應用層協議通訊，即發送 HTTP 響應。
6. 最後由客戶端發送 close_notify 報文斷開鏈接。

3. HTTPS存在的缺陷

1. SSL加密緻使的速度的下降和服務器負載的增大。
2. 申請證書須要的開銷

4、 HTTP2協議

1. 歷史痛點

a. HTTP1.0 時代最大的兩個問題就是：

• 鏈接沒法複用 : 每次請求都須要從新創建tcp通道，經歷三次握手的過程。
• 隊頭阻塞：請求通道如一個獨木橋，多個請求一塊兒發出，只能先等第一個請求得到回包以後才能開始第二個請求，不然就只能排隊等候。

b. 那些年的解決之道：

1. 解決鏈接沒法複用：

基於tcp的長連接:

通常APP會基於TCP造一個長鏈接的通訊協議，門檻較高，可是一旦完成，帶來的回報也是很是大的。信息的推送和更新變得及時，且在一些請求爆發點，相較於傳統HTTP重複創建請求的耗時，也能減輕服務器的壓力。如今業界的成熟方案如：google的protobuf。

http long-polling:

long-polling請求就是在客戶端初始化的時候發起一個polling請求到服務器，而後請求一直等待中，當服務器有資源更新的時候，再返回數據，數據放回時，再次發起一個polling請求繼續監聽。固然，polling請求也有一些缺陷，好比 長時間的鏈接會增長服務器壓力，複雜的業務場景下須要考慮如何才能創建健康的請求通道等。此外，這種方式有個致命的缺陷是：數據通訊是單向的，主動權在服務端這邊，客戶端只能根據服務端被動的接受數據，有新的業務請求的時候沒法及時傳送。

http streaming:

與http-polling 不一樣的是， http-streaming 在初始化的的時候就發起一個不會斷開的請求，持續監聽服務器的回包，服務器有數據更新時就經過這個請求通道返回數據。此種方式跟http-polling同樣是單向的，streaming是經過在server response的頭部裏增長」Transfer Encoding: chunked」來告訴客戶端後續還會有新的數據到來。固然，streaming 也有缺陷: 業務數據沒法按照請求來作分割，因此客戶端沒收到一塊數據都須要本身作協議解析，也就是說要作本身的協議定製。

websocket:

WebSocket和傳統的tcp socket鏈接類似，也是基於tcp協議，提供雙向的數據通道。WebSocket優點在於提供了message的概念，比基於字節流的tcp socket使用更簡單，同時又提供了傳統的http所缺乏的長鏈接功能。websocket 通常在數據須要實時更新的場景中使用。

2. 解決隊頭阻塞:

http pipelining（管線化）

管線化的前提是長鏈接的創建，keep-alive的多個請求使用同一個tcp鏈接使請求並行成爲可能，pipelining與傳統的請求能夠形象的比喻爲 串行和並行 ， 多個請求同時發起，無需等待上一個請求的回包。可是它並非救世主，也存在着缺陷：

• pipelining只適用與HTTP1.1，而且須要服務器端支持
• 隊頭阻塞的問題並無根本的解決，由於服務端要響應要遵循先進先出的原則，第一個請求的回包發出以後，纔會響應第二個請求。

2. 新的改變(HTTP2)

HTTP1.0和1.1的普及程度使得HTTP2必須得在不改變原有方式的狀況下解決上述問題，即HTTP2 並不能像angular2那樣放飛自我。因此，HTTP2的使用方式和原來的差很少，HTTP2的改變至關之多，這裏主要講一下對咱們影響較大的幾點：

a. 二進制

http2.0的協議解析決定採用二進制格式，實現方便且健壯。每個請求都有這些公共字段：Type, Length, Flags, Steam Identifier和frame payload。http2.0的格式定義更接近tcp層的方式，length定義了整個frame的開始到結束，type定義frame的類型（一共10種），flags用bit位定義一些重要的參數，stream id用做流控制，剩下的payload就是request的正文了。

b. 多路複用

多路複用是HTTP2.0主要解決的一個問題，一個request對應一個stream並分配一個id，這樣一個鏈接上能夠有多個stream，每一個stream的frame能夠隨機的混雜在一塊兒，接收方能夠根據stream id將frame再歸屬到各自不一樣的request裏面。

c. 頭部壓縮

無狀態的HTTP致使每次請求都須要攜帶服務器所須要的參數，而一些頭部信息基本上是固定的，這部分重複的信息恰好能夠用於壓縮，減小報文體積。

d. 鏈接重置

HTTP 1.1的有一個缺點是：當一個含有確切值的Content-Length的HTTP消息被送出以後，你就很難中斷它了。固然，一般你能夠斷開整個TCP連接（但也不老是能夠這樣），但這樣致使的代價就是須要從新經過三次握手創建一個新的TCP鏈接。一個更好的方案是隻終止當前傳輸的消息並從新發送一個新的。在http2裏面，咱們能夠經過發送RST_STREAM幀來實現這種需求，從而避免浪費帶寬和中斷已有的鏈接。

e. 依賴與優先級

每一個流都包含一個優先級，優先級被用來告訴對端哪一個流更重要。從而實現資源的有效分配。

f. 服務器推送

當一個客戶端請求資源X，而服務器知道它極可能也須要資源Z的狀況下，服務器能夠在客戶端發送請求前，主動將資源Z推送給客戶端。這個功能幫助客戶端將Z放進緩存以備未來之需。

g. 流量控制

http2上面每一個流都擁有本身的公示的流量窗口，它能夠限制另外一端發送數據。

5、總結：

HTTP 雖然只有2個版本，可是每一個版本所包含的改動是很是之大的。所作出的突破和嘗試也是很是多的，固然，HTTP也有競爭者，好比在HTTP2還未提出時，由google提出並推行的SPDY協議，它的優點在於解決了HTTP1.0的不能多路複用的問題，對資源請求速度有極大的提高，目前在市場上仍然有許多的使用量，HTTP2也是借鑑了不少SPDY的特性。再好比quic協議，是號稱比HTTP2更快的協議。這個在下一篇文章中會重點介紹~ 哈！主要是這篇有點長了。

參考文獻

https://www.zhihu.com/questio...
http://wiki.jikexueyuan.com/p...