作爲前端開發者，你應該要懂的 http協議

經典的五層模型

低三層

1. 物理層主要做用是定義物理設置如何傳輸數據
2. 數據鏈路層在通訊的實體間創建數據鏈路鏈接
3. 網絡層爲數據在結點之間傳輸建立邏輯鏈路

傳輸層

• 向用戶提供可靠的端到端(End-to-End)服務
• 傳輸層向高層屏蔽了下層的數據通訊的細節

應用層

• 爲應用軟件提供了不少服務
• 構建於 TCP 協議之上
• 屏蔽網絡傳輸相關細節

http協議的發展歷史

HTTP/0.9

• 只有一個命令 GET
• 沒有HEADER等描述數據的信息
• 服務器發送完畢，就關閉 TCP 鏈接

HTTP/1.0

• 增長了不少命令
• 增長 status code 和 header
• 多字符集支持、多部分發送、權限、緩存等

HTTP/1.1

• 持久鏈接
• pipeline
• 增長 host 和其餘一些命令

HTTP2

• 全部數據以二制傳輸
• 同一個鏈接裏面發送多個請求再也不須要按照順序來
• 頭信息壓縮及推送等提升效率的功能

HTTP 的三次握手

第一次握手：主機 A 發送位碼爲 syn = 1,隨機產生seq number=1234567的數據包到服務器，主機 B 由 syn=1知道， A要求創建聯機。

第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包。

第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功。

CORS 解決瀏覽器跨域限制

什麼是 CORS

CORS（Cross-Origin Resource Sharing 跨源資源共享），當一個請求url的協議、域名、端口三者之間任意一與當前頁面地址不一樣即爲跨域。

CORS是解決瀏覽器跨域限制的W3C標準，詳見：https://www.w3.org/TR/cors/。

根據 CORS 標準的定義，在瀏覽器中訪問跨域資源時，須要作以下實現：

• 服務端在響應消息頭中包含消息頭：Access-Control-Allow-Origin,
  值爲服務器容許訪問資源的域名稱，同時瀏覽器會根據該值與發起的請求消息頭 Origin
  值進行匹配，以確認服務端是否容許訪問跨域資源。
• 瀏覽器在發送非「簡單方法」 (GET,HEAD請求被定義爲簡單方法)以前，會發送一個預檢請求（一般是一個 OPTIONS
  請求），瀏覽器根據響應消息驗證服務端是否容許訪問跨域資源，從而決定是否須要發送"實際請求"。
• 在服務端根據請求消息頭Origin值以決定是否容許瀏覽器訪問跨域資源，返回相應的消息頭

具體來講，在實現時一般須要設置以下幾個響應消息頭：

1. Access-Control-Allow-Origin：「origin-list」 | 「null」 |
   「*」，容許訪問跨域資源的域名列表，對於預檢請求來講，決定是否會發送實際請求。
2. Access-Control-Allow-Credentials：true | false，代表實際請求中是否能夠包含用戶憑證信息。
3. Access-Control-Allow-Methods：「method」，服務端容許訪問的實際請求方法名列表。
4. Access-Control-Allow-Headers：「field-name」，在「實際」請求中能夠包含的消息頭名稱列表。
5. Access-Control-Max-Age：seconds，預檢請求結果緩存時間，單位：秒。在該時間範圍內，發送實際請求以前再也不會發送預檢請求。

HTTP 緩存 Cache-Control頭域

Cache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置Cache-Control並不會修改另外一個消息處理過程當中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義以下：

Public指示響應可被任何緩存區緩存。

• Private指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這容許服務器僅僅描述當用戶的部分響應消息，此響應消息對於其餘用戶的請求無效。
• no-cache指示請求或響應消息不能緩存
• no-store用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。
• max-age指示客戶機能夠接收生存期不大於指定時間（以秒爲單位）的響應。
• min-fresh指示客戶機能夠接收響應時間小於當前時間加上指定時間的響應。
• max-stale指示客戶機能夠接收超出超時期間的響應消息。若是指定max-stale消息的值，那麼客戶機能夠接收超出超時期指定值以內的響應消息。

Cache-Control: no-cache：這個很容易讓人產生誤解，令人誤覺得是響應不被緩存。實際上Cache-Control：no-cache是會被緩存的，只不過每次在向客戶端（瀏覽器）提供響應數據時，緩存都要向服務器評估緩存響應的有效性。

Cache-Control: no-store：這個纔是響應不被緩存的意思

HTTP 緩存 ETAG 和 Last-Modified 資源驗證

緩存是如何操做的：

瀏覽器建立了一個請求，首先到達的地方是本地緩存（這個是前提是你開啓 Cache-Control 緩存）， 若是命中，就直接返回給瀏覽器，若是沒有命中 就會往互聯網進行發送，在發送過程當中有可能進入代理緩存，若是命中 通過本地緩存返回給瀏覽器，若是沒有命中才會真正到源服務器，這個就是從瀏覽器發出一個請求到查找緩存的一個過程。

本地緩存文件一般是有過時時間（Http協議頭中的expire字段）的，一旦過時，須要重新向服務端發起請求，此時一般會有兩種狀況：

• 服務器的文件或者內容沒有更新，能夠繼續使用瀏覽器本地緩存
• 服務器的文件或者內容已經更新，須要從新請求，經過網絡傳輸新的文件或者內容

如何判斷文件的內容是否過時，能夠經過HTTP協議來控制。請求服務器時，比對Last-Modified或Etag來判斷內容是否發生變化，它們都是上一次請求是服務端生成並返回給瀏覽器的，緩存過時後再次請求時，會把它們包含在HTTP請求中和服務端進行比對，若是比對一致，說明內容沒有變動，服務器會返回 304 Not Modified，不然從新發起資源請求，這樣的話，就不須要每次訪問服務器都經過網絡傳輸一個比較大的文件或者數據包，只要簡單的http應答就能夠達到相同的請求文件效

什麼是Last-Modified

在瀏覽器第一次請求某一個URL時，服務器端的返回狀態會是200，內容是你請求的資源，同時有一個Last-Modified的屬性標記此文件在服務期端最後被修改的時間，格式相似這樣：

Last-Modified: Fri, 12 May 2006 18:53:33 GMT

客戶端第二次請求此URL時，根據 HTTP 協議的規定，瀏覽器會向服務器傳送 If-Modified-Since 報頭，詢問該時間以後文件是否有被修改過：

If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT

若是服務器端的資源沒有變化，則自動返回 HTTP 304 （Not Changed.）狀態碼，內容爲空，這樣就節省了傳輸數據量。 當服務器端代碼發生改變或者重啓服務器時，則從新發出資源，返回和第一次請求時相似。從而保證不向客戶端重複發出資源，也保證當服務器有變化時，客戶端能 夠獲得最新的資源。

什麼是 Etag

HTTP 協議規格說明定義ETag爲「被請求變量的實體值」。另外一種說法是，ETag是一個能夠與Web資源關聯的記號（token）。典型的Web資源能夠一個Web頁，但也多是JSON或XML文檔。服務器單 獨負責判斷記號是什麼及其含義，並在HTTP響應頭中將其傳送到客戶端，如下是服務器端返回的格式：

ETag: "50b1c1d4f775c61:df3"

客戶端的查詢更新格式是這樣的：

If-None-Match: W/"50b1c1d4f775c61:df3"

若是ETag沒改變，則返回狀態304而後不返回，這也和Last-Modified同樣。本人測試Etag主要在斷點下載時比較有用。

Last-Modified和Etags如何幫助提升性能?

聰明的開發者會把Last-Modified 和ETags請求的http報頭一塊兒使用，這樣可利用客戶端（例如瀏覽器）的緩存。由於服 務器首先產生 Last-Modified/Etag標記，服務器可在稍後使用它來判斷頁面是否已經被修改。本質上，客戶端經過將該記號傳回服務器要求服 務器驗證其（客戶端）緩存。

1. 客戶端請求一個頁面（A）。
2. 服務器返回頁面A，並在給A加上一個Last-Modified/ETag。
3. 客戶端展示該頁面，並將頁面連同Last-Modified/ETag一塊兒緩存。
4. 客戶再次請求頁面A，並將上次請求時服務器返回的Last-Modified/ETag一塊兒傳遞給服務器。
5. 服務器檢查該Last-Modified或ETag，並判斷出該頁面自上次客戶端請求以後還未被修改，直接返回響應304和一個空的響應體。

HTTPS

HTTPS是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

HTTP與HTTPS有什麼區別

HTTP協議傳輸的數據都是未加密的，也就是明文的，所以使用HTTP協議傳輸隱私信息很是不安全，爲了保證這些隱私數據能加密傳輸，因而網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。簡單來講，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。

HTTPS和HTTP的區別主要以下：

1. https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。
2. http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
3. http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
4. 四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

HTTP2.0

HTTP2.0的新特性

• 新的二進制格式（Binary
  Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在自然缺陷，文本的表現形式有多樣性，要作到健壯性考慮的場景必然不少，二進制則不一樣，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
• 多路複用（MultiPlexing），即鏈接共享，即每個request都是是用做鏈接共享機制的。一個request對應一個id，這樣一個鏈接上能夠有多個request，每一個鏈接的request能夠隨機的混雜在一塊兒，接收方能夠根據request的
  id將request再歸屬到各自不一樣的服務端請求裏面。
• header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，並且每次都要重複發送，HTTP2.0使用encoder來減小須要傳輸的header大小，通信雙方各自cache一份header
  fields表，既避免了重複header的傳輸，又減少了須要傳輸的大小。
• 服務端推送（server push），同SPDY同樣，HTTP2.0也具備server
  push功能。目前，有大多數網站已經啓用HTTP2.0，例如YouTuBe，淘寶網等網站

關於HTTP2和HTTP1.x的區別大體能夠看下圖：

願你成爲終身學習者