徹底解析http1,2,3

先來簡介

什麼是HTTP？

HyperText Transfer Protocol，超文本傳輸協議，是目前互聯網上應用最普遍的一種網絡協議，全部的www文件都必須遵照該標準。而Http又使用了可靠的數據傳輸協議TCP協議，不會產生數據丟失和損壞。

什麼又是TCP?

計算機和網絡設備相互通訊，必須知足的一種規則，咱們稱之爲協議（ protocal）

與HTTP密切關聯的TCP、IP以及DNS

IP協議，位於網絡層，做用是把各類數據包發送給對方，經過IP地址和MAC地址來保證數據傳達。怎麼保證呢？IP地址指明瞭節點被分配的地址，MAC地址是網卡所屬的固定地址，彼此可進行配對，IP地址可變，但MAC地址基本不變。

ARP（Address Resolution Protocol）協議是一種解析地址的協議，可根據IP地址解析出對應的MAC地址。

TCP協議是如何作到可靠的數據傳輸的？
首先，TCP位於傳輸層，爲了方便傳輸，將大塊的數據分割成以報文爲單位的數據包進行管理，即所謂的字節流服務。

三次握手策略（three-way handshaking）。TCP協議將數據發送出去後，必定會向對方確認數據是否送達，不然會按順序從新發送相同的數據包。

字段	含義
URG	緊急指針是否有效。爲1，表示某一位須要被優先處理
ACK	確認號是否有效，通常置爲1。
PSH	提示接收端應用程序當即從TCP緩衝區把數據讀走。
RST	對方要求從新創建鏈接，復位。
SYN	請求創建鏈接，並在其序列號的字段進行序列號的初始值設定。創建鏈接，設置爲1
FIN	但願斷開鏈接。

三次握手流程

四次揮手流程

在HTTP1.1中，默認鏈接是持久鏈接的（即http keep-alive），特色是隻要任意一端沒有明確斷開鏈接，則保持TCP鏈接狀態。這樣就能夠作到同時並行的發送多個請求，而不須要一個個的等待響應。

DNS(Domain Name System)也位於應用層的協議，它提供域名到IP地址的解析服務。

HTTP/1.1

URL與URI

URL(Uniform Resource Locator)，網頁地址
URI(Uniform Resource Identifier),統一資源標識符

HTTP的工做流程

1. 瀏覽器與服務器創建TCP鏈接，即三次握手
2. TCP鏈接成功，瀏覽器發送HTTP請求命令
3. 服務接收到請求並返回HTTP響應
4. 服務器關閉鏈接，即四次揮手
5. 瀏覽器解析請求的資源

Connection:keep-alive可讓TCP鏈接保持打開，瀏覽器可繼續經過相同的鏈接發送請求。其實HTTP1.1全部的請求都是默認保持持續鏈接的

HTTP報文

分爲請求和響應報文。由多行（CR+LF做爲換行符）數據結構構成的字符串文本，大體可分爲報文首部和報文主體兩部分。

1. 請求行：包含請求方法，請求的URI和HTTP版本
2. 狀態行：包含響應結果的狀態碼
3. 首部字段：包含請求和響應的各類條件、屬性的各種首部；
4. 其餘：包含未定義的首部如Cookie等

內容協商

請求格式

# 請求方法 URL 協議/版本
GET /u013870094/article/details/79098628 HTTP/1.1
# 用於指定被請求資源的Internet主機和端口號
Host: blog.csdn.net
# 表示是否須要持久鏈接。
Connection: keep-alive
# 防止頁面被緩存,只有一個用法， Pragma: no-cache
Pragma: no-cache
# 這個用來指定Response-Request遵循的緩存機制
#   Cache-Control:Public    能夠被任何緩存所緩存,多用戶間共享
#   Cache-Control:Private   內容只緩存到私有緩存中,不能在用戶間共享
#   Cache-Control:no-cache   全部內容都不會被緩存
#   Cache-Control: max-age=x：緩存時間 以秒爲單位
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
# 覽器的名稱和版本等信
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
# 瀏覽器能夠接受的媒體類型（MIME類型）
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
# 提供了Request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的，
Referer: https://blog.csdn.net/u013870094/article/details/79098628
# 瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate）
Accept-Encoding: gzip, deflate, br
# 瀏覽器申明本身接收的語言。
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: xxxxx

響應格式

HTTP/1.1 200 OK
Date: Wed, 23 Oct 2019 02:14:16 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: openresty
Vary: Accept-Encoding
Content-Encoding: gzip
Strict-Transport-Security: max-age=86400

瀏覽器緩存

先簡單介紹下，後續有必要仔細研究下原理。

1. 第一次請求，瀏覽器經過HTTP的header報文頭部，附帶Expires,Cache-Control,Last-Modified/Etag向服務器請求，此時服務器記錄第一次請求的Last-Modified/Etag
2. 再次請求，附帶頭部信息Expires，Cache-Control，If-Modified-Since/Etag
3. 服務器比對兩次的Last-Modified/Etag與If-Modified-Since/Etag判斷資源未發生變化，返回304響應

缺陷

高延遲，隊頭阻塞，帶寬沒法充分利用

隊頭阻塞是指當順序發送的請求序列中的一個請求由於某種緣由被阻塞時，在後面排隊的全部請求也一併被阻塞，會致使客戶端遲遲收不到數據。

Chrome默認在同一個域名下，容許同時創建6個TCP持久鏈接，在當前請求沒有結束以前，其餘的請求只能處於被阻塞的狀態；

解決辦法：

1. 將資源分配在不一樣的域名下
2. Spriting合併多張小圖爲一張大圖
3. 將多個體積較小的Javascript合併成一個較大的文件；但當其中一個文件改變時，會致使整個文件從新被下載。

無狀態特性帶來巨大的頭部

1. 攜帶過多的header信息，如user-agent,cookie,accept等；
2. 請求報文有過多的重複字段，資源浪費；

明文傳輸的不安全性

不支持服務推送

HTTP/2

SPDY協議

HTTP/2是現行HTTP協議（HTTP/1.x）的替代，但它不是重寫，HTTP方法/狀態碼/語義都與HTTP/1.x同樣。HTTP/2基於SPDY，專一於性能，最大的一個目標是在用戶和網站間只用一個鏈接（connection）。

二進制傳輸

HTTP/2 將請求和響應數據分割爲更小的幀，而且它們採用二進制編碼。

它把TCP協議的部分特性挪到了應用層，把原來的"Header+Body"的消息"打散"爲數個小片的二進制"幀"(Frame),用"HEADERS"幀存放頭數據、"DATA"幀存放實體數據。HTP/2數據分幀後"Header+Body"的報文結構就徹底消失了，協議看到的只是一個個的"碎片"。

HTTP/2 中，同域名下全部通訊都在單個鏈接上完成，該鏈接能夠承載任意數量的雙向數據流。每一個數據流都以消息的形式發送，而消息又由一個或多個幀組成。多個幀之間能夠亂序發送，根據幀首部的流標識能夠從新組裝。

Header壓縮

採用HPACK算法壓縮頭部，壓縮率50%-90%；
同時，同一個域名下的兩個請求，只會發送差別數據，減小冗餘的數據傳輸，下降開銷。

多路複用

• 同一個域名下的全部通訊都在單個鏈接上完成；
• 單個鏈接能夠承載任意數量的雙向數據流；
• 數據流以消息的形式發送，而消息由一個或多個幀組成，能夠亂序發送，由於根據幀首部的流標識能夠從新組裝。

這樣作直觀的好處是：

1. 同一個頁面，只須要一個TCP慢鏈接的過程；
2. 能夠並行交錯的發送請求，請求之間互不影響；

服務端推送

指的是服務端能夠新建「流」主動向客戶端發送消息，提早推送客戶端須要的靜態資源，減小等待的延遲。

提升安全性

爲了兼容，HTTP2也是明文的，只不過格式是二進制的，但HTTP2都是https協議的，跑在TSL上面。

缺陷

TCP+TLS創建鏈接的時間是主要瓶頸

沒有從根本上解決頭阻塞問題，一旦遇到丟包，那麼TCP協議仍是會從新發送數據。

Future:HTTP/3

QUIC

• 基於UDP協議改造，實現了快速的握手；
• 集成了TLS的加密功能；
• 多路複用，完全解決了頭阻塞問題；
• 實現了相似TCP的流量控制、傳輸可靠性的功能；

延伸出的幾個問題

1. 網頁中的圖片資源爲何放在不一樣的域名下？
2. 瀏覽器與服務器創建一個TCP鏈接後，是否會在完成一個http請求後斷開？什麼條件會斷開？
3. 一個TCP鏈接能夠同時發送幾個HTTP請求？
4. 瀏覽器http請求的併發性是如何體現的？併發請求的數量有限制麼？

參考

1. https://blog.csdn.net/u013870094/article/details/79098628
2. http://www.fly63.com/article/detial/5974
3. http://www.javashuo.com/article/p-ewzpmicf-dz.html
4. https://http2.akamai.com/demo
5. http://www.javashuo.com/article/p-zqmaiqar-kb.html
6. http://www.javashuo.com/article/p-cklkuykr-kc.html