HTTP解析

時間 2019-11-16

標籤 http 解析欄目 HTTP/TCP 简体版

原文原文鏈接

1、 TCP/IP協議族

1.1. TCP/IP協議族概念

在說HTTP前，咱們先來了解一下TCP/IP協議族：不一樣的硬件、操做系統之間通訊都須要一種規則，這種規則稱爲協議(protocal)，而協議中存在各式各樣的內容。從電纜的規格到IP地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序，以及Web頁面顯示須要處理的步驟等等，像這樣把與互聯網相關聯的協議集合起來總稱爲TCP/IP協議族，咱們一般使用的網絡都是在TCP/IP協議族的基礎上運做的，而HTTP屬於它內部的一個子集。

1.2. TCP/IP協議族分層

應用層：提供應用服務，包含HTTP/DNS(域名系統)/FTP(文件傳輸)。
傳輸層：提供鏈接中的計算機間的數據傳輸(請求報文)，包含TCP(傳輸控制協議)和UDP(用戶數據報協議)。
網絡層：處理網絡上流動的數據包，數據包是網絡傳輸的最小數據單位，該層規定了經過怎樣的傳輸路線到達對方計算機，並把數據包傳送給對方，包含IP(Internet Protocol)網絡協議。
鏈路層：處理網絡鏈接的硬件部分。

利用TCP/IP協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，客戶端在應用層(HTTP協議)發出一個HTTP請求，傳輸層把接收到的請求報文進行分割，並在各個報文上打上標記號及端口號後轉發給網絡層，在網絡層增長做爲通訊目的地的的MAC地址後轉發給鏈路層，接收端的服務器在鏈路層接收到數據後從鏈路層往上走，走完以後纔算是一個完整的HTTP請求。

發送端通過每層都會加上對應的首部信息，含TCP首部、IP首部、以太網首部，接受端則每通過一層消去一個首部。這種將數據信息包裝起來的作法稱爲封裝。

1.3. 與HTTP關係密切的協議：DNS、TCP、IP

1. DNS協議

DNS協議位於應用層，負責將域名解析爲IP地址。

2. TCP協議

TCP協議位於傳輸層，提供可靠的字節流服務，它會將大快數據分割成以報文段爲單位的數據包進行管理，且能確認數據最終是否送達到對方。爲確保將數據準確傳送至對方，採用了三次握手策略，握手過程當中使用了TCP的標誌 ： SYN(synchronize/使同步)和ACK(acknowledgement/確認)。

發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，表明"握手"結束。若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。前端

3. IP協議

IP協議位於網絡層，做用是把各類數據包傳輸給對方，而傳輸就須要地址，而地址則須要IP地址(勿和IP協議混淆)和MAC地址(Media Access Control Address/媒體訪問控制地址)。IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址能夠和MAC地址進行配對，IP地址可變換，但MAC地址基本上不會更改。算法
IP地址間的通訊依賴MAC地址，通訊基本都須要進行中轉，而在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時會採用ARP協議(AddressResolution Protocol/地址解析協議)，ARP是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。在中轉過程當中，計算機和路由器等網絡設備只能獲悉粗略的傳輸路線，這種機制稱爲路由選擇(routing)。瀏覽器

4. 各類協議與HTTP協議的關係

2、HTTP協議

2.1. HTTP概念

HTPP(HyperText Transfer Protocol)是一種超文本傳輸協議，或者說是一種傳輸規則，用於客戶端和服務器，經過請求和響應的交換來達成通訊。

1. 無狀態

HTTP是無狀態協議，即HTTP協議自身不具有保存以前發送過的請求或響應的功能，也就是說，沒法根據以前的狀態進行本次的請求處理。優勢是不保存狀態可減小服務器的CPU及內存資源的消耗，但同時缺點也明顯，因此出現了使用Cookie來進行狀態管理。緩存
Cookie會根據從服務器端發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。服務器端發現客戶端發送過來的Cookie後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。安全
Set-Cookie字段屬性性能優化

2. 持久鏈接

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。因此若是當請求的資源不少時，會形成無謂的TCP鏈接創建和斷開，增長通訊量的開銷。爲解決TCP鏈接的問題，產生了keep-alive的方法，其特色是：只要任意一端沒有明確提出斷開鏈接，則保持 TCP鏈接狀態(在HTTP/1.1中，全部的鏈接默認都是持久鏈接)。

持久鏈接也是管線化成爲可能，即不用等待響應便可發送下一個請求，這樣就可以作到同時並行發送多個請求。

2.2. 客戶端

1. 請求報文

發送請求時會發送請求報文，其由請求行(含請求方法、請求URI、協議版本)、報文首部和報文實體構成的，且報文首部和報文實體以一空行(CR+LF)分隔，以下圖：

1. 請求行

請求方法

經常使用：服務器

GET: 獲取資源。
POST: 傳輸實體主體。

檢測查詢：網絡

OPTIONS: 詢問支持的方法或預檢請求。
HEAD: 得到報文首部，和GET方法同樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。
TRACE: 追蹤路徑。

文件相關：前端性能

PUT: 傳輸文件。
DELETE: 刪除文件。

安全：ide

CONNECT: 要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。

URI/URL

URI：統一資源標識符(Uniform Resource Identifier)，表明一種標識。
URL：統一資源定位符(Uniform/Universal Resource Locator)。
URI是資源的標識或頭銜，而URL更爲具體，包含了標識的同時還含有資源定位，平時咱們在瀏覽器地址欄內輸入的就是URL，由於咱們要找到這個資源，固然你輸入的也是URI，由於URL是更爲具體的URI而已。

協議版本

HTTP/1.0
HTTP/1.1 (目前經常使用)
HTTP/2.0

2. 報文首部

報文首部包含請求首部字段、通用首部字段、實體首部字段、其餘(可能包含HTTP的RFC裏未定義的首部(Cookie等))。

請求首部字段

Host

Host會告知服務器，請求的資源所處的互聯網主機名和端口號。在HTTP/1.1規範內是惟一一個必須被包含在請求內的首部字段。

Referer

Referer會告知服務器請求的原始資源的URI。

通用首部字段

請求報文和響應報文兩方都會使用的首部。

2.1 Cache-Control

請求值：

響應值：

2.2 Connection

做用：

① 控制再也不轉發給代理的首部字段

② 管理持久鏈接

HTTP/1.1版本的默認鏈接都是持久鏈接。爲此，客戶端會在持久鏈接上連續發送請求。當服務器端想明確斷開鏈接時，則指定Connection首部字段的值爲Close。

2.3 Date

代表建立 HTTP 報文的日期和時間

2.4 Pragma

Pragma是HTTP/1.1以前版本的歷史遺留字段，僅做爲與HTTP/1.0的向後兼容而定義。Pragma: no-cache：該首部字段屬於通用首部字段，但只用在客戶端發送的請求中。客戶端會要求全部的中間服務器不返回緩存的資源。

2.5 Trailer

首部字段Trailer會事先說明在報文主體後記錄了哪些首部字段。該首部字段可應用在HTTP/1.1版本分塊傳輸編碼時。

2.6 Transfer-Encoding

Transfer-Encoding規定了傳輸報文主體時採用的編碼方式。

2.7 Upgrade

首部字段Upgrade用於檢測HTTP協議及其餘協議是否可以使用更高的版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議。Upgrade對象僅限於客戶端和鄰接服務器之間。所以，使用首部字段Upgrade時，還須要額外指定Connection:Upgrade，再也不轉發給代理。服務器可用101 SwitchingProtocols狀態碼做爲響應返回。

3.8 Via

爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。

3.9 Warning

告知用戶一些與緩存相關的問題的警告。

實體首部字段

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

Allow

Allow用於通知客戶端可以支持Request-URI指定資源的全部HTTP方法。

Content-Location

Content-Location表示的是報文主體返回資源對應的URI，可能會和實際請求的對象不一樣。Location是令客戶端重定向至指定的URI

Content-MD5

Content-MD5是一串由MD5算法生成的值，其目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。服務器發往客戶端。

Expires

資源失效日期，Cache-Control:max-age優先級更高。

3. 報文實體

在相同的IP地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的Web網站，所以在發送HTTP請求時，必須在Host首部內完整指定主機名或域名的URI。

2.3. 服務器

1. 響應報文

1. 狀態行

協議版本
狀態碼：

狀態碼用於描述返回的請求結果：

1XX 信息性狀態碼——接收的請求正在處理
2XX 成功狀態碼——請求正常處理完畢
3XX 重定向狀態碼——須要附加操做以完成請求
4XX 客戶端錯誤狀態碼——服務器沒法處理請求
5XX 服務端錯誤狀態碼——服務器處理請求出錯

經常使用狀態碼：

200 OK——請求成功。表示從客戶端發來的請求在服務器端被正常處理了。
204 No Content——請求處理成功，但沒有資源可返回。即無實體返回，通常用於只需客戶端往服務器發送消息。
206 Partial Content——範圍請求。而服務器成功執行了這部分的GET請求。

301 Moved Permanently——永久重定向。該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI，當指定資源路徑的最後忘記添加斜槓"/"，就會產生 301 狀態碼。
302 Found——臨時重定向。URI未來還可能會變。
303 See Other——該狀態碼錶示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。相似302。
307 Temporary Redirect——臨時重定向。相似302，不會將POST變爲GET，但也視瀏覽器而定。

當 30一、30二、303 響應狀態碼返回時，幾乎全部的瀏覽器都會把POST改爲GET，並刪除請求報文內的主體，以後請求會自動再次發送。

304 Not Modified——資源無變化，不返回實體。

400 Bad Request——請求報文存在語法錯誤。
401 Unauthorized——請求須要有經過HTTP認證。認證方式有BASIC認證(基本認證)、DIGEST認證(摘要認證)、SSL客戶端認證、FormBase認證(（)基於表單認證)。
403 Forbidden——請求資源的訪問被服務器拒絕。未得到文件系統的訪問受權，訪問權限出現某些問題等會產生。
404 Not Found——服務器上沒法找到請求的資源。

500 Internal Server Error——服務器端在執行請求時發生了錯誤。
503 Service Unavailable——服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

狀態碼緣由短語

2. 報文首部

響應首部字段

3. 報文實體

報文實體可進行內容編碼，經常使用編碼有：

gzip (GNU zip)
compress (UNIX系統的標準壓縮)
deflate (zlib)
identity (不進行編碼)

分割發送的分塊傳輸編碼：

在 HTTP 通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。

2.4. 中間商

HTTP通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序：代理、網關、隧道

1. 代理

代理是一種有轉發功能的應用程序，它扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。代理不改變請求URI，會直接發送給前方持有資源的目標服務器，每次經過代理服務器轉發請求或響應時，會追加寫入Via首部信息，會標記出通過的主機信息。
緩存代理：

代理轉發響應時，緩存代理(Caching Proxy)會預先將資源的副本(緩存)保存在代理服務器上。當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將以前緩存的資源做爲響應返回。

透明代理：

轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理(Transparent Proxy)。反之，對報文內容進行加工的代理被稱爲非透明代理。

2. 網關

網關是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。有時客戶端可能都不會察覺，本身的通訊目標是一個網關。利用網關能夠由HTTP請求轉化爲其餘協議通訊。利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。

3. 隧道

隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保客戶端能與服務器進行安全的通訊。隧道自己不會去解析HTTP請求。請求保持原樣中轉給以後的服務器，隧道會在通訊雙方斷開鏈接時結束。

2.5. 緩存

瞭解了以上各個報文字段，下面來綜合理解緩存機制：

強緩存：是利用HTTP頭中的Expires和Cache-Control兩個字段來控制的。強緩存中，當請求再次發出時，瀏覽器會根據其中的Expires和Cache-Control判斷目標資源是否「命中」強緩存，若命中則直接從緩存中獲取資源，不會再與服務端發生通訊。

協商緩存：協商緩存依賴於服務端與瀏覽器之間的通訊，協商緩存機制下，瀏覽器須要向服務器去詢問緩存的相關信息，進而判斷是從新發起請求、下載完整的響應，仍是從本地獲取緩存的資源。其中涉及Last-Modifield與If-Modified-Since的配合，ETag與If-None-Match的配合。

1. Cache-Control

Cache-Control，這個字段在請求和響應中均可以使用，對應的值以下：

請求中使用的值：

響應中使用的值：

Cache-Control: public

響應獨有：緩存公有化。明確代表其餘用戶也可利用緩存，即瀏覽器和代理服務器均可進行緩存，默認值爲private，但當字段中出現s-maxage時表示當前值爲public。

Cache-Control: private

響應獨有：緩存私有化。代理服務器不能對資源進行緩存。

Cache-Control: no-cache

請求中含義：客戶端不使用緩存資源，繞開瀏覽器緩存確認，直接向源服務器上進行緩存資源的確認。
響應中含義：告知緩存代理在緩存資源時需向源服務器確認資源有效性後進行處理，指不緩存過時的資源。(若響應報文Cache-Control中對no-cache字段名具體指定參數值，如Cache-Control: no-cache=Location，那麼客戶端在接收到這個被指定參數值的首部字段對應的響應報文後，就不能使用緩存)

Cache-Control: no-store

請求中含義：不使用緩存，也不進行緩存確認，直接發送請求獲取資源。
響應中含義：告知緩存代理不能進行緩存。

Cache-Control: max-age=秒

請求中含義：規定緩存通過的最大時間，若是數值未超過緩存的時間則取緩存資源。若是爲0，則至關於想服務器請求資源。
響應中含義：規定緩存保存的時間。

Cache-Control: s-maxage=秒

響應獨有：僅在代理服務器中生效(生效則忽略Expires和max-age指令)，規定緩存的過時時間。

Cache-Control: max-stale=秒

請求獨有：指緩存過時了指定時間後依舊可以使用該緩存資源。如不指定時間，則無論過時了多久依舊使用緩存資源。

Cache-Control: min-fresh=秒

請求獨有：指緩存代理返回至少未通過指定時間的緩存資源。

Cache-Control: no-transform

請求中含義：在緩存代理中不能改變實體的媒體類型，可防止緩存或代理壓縮圖片等相似操做。
響應中含義：在緩存代理中不能改變實體的媒體類型，可防止緩存或代理壓縮圖片等相似操做。

Cache-Control: only-if-cached

請求獨有：只有緩存代理緩存了資源纔要求其返回資源。

Cache-Control: must-revalidate

響應獨有：緩存代理可緩存，但必須先向源服務器確認資源有效性。會忽略請求的max-stale指令。

Cache-Control: proxy-revalidate

響應獨有：要求全部的緩存代理在接收到客戶端帶有該指令的請求返回響應以前，必須再次驗證緩存的有效性。

Cache-Control: cache-extension

請求中含義：擴展新指令標記。
響應中含義：擴展新指令標記。

2. Expires

Expires: 時間戳
首部字段Expires會將資源失效的日期告知客戶端。緩存服務器在接收到含有首部字段Expires的響應後，會以緩存來應答請求，在Expires字段值指定的時間以前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。
優勢：與Cache-Control同時使用，爲了向下兼容。
缺點：依賴本地時間。

3. Last-Modifield與If-Modified-Since的配合

Last-Modifield: 時間戳在首次請求時伴隨着Response Headers返回，是一個時間戳，表示最近的一次資源改動時間:

Last-Modified: Fri, 27 Oct 2017 06:35:57 GMT
複製代碼

隨後咱們每次請求時，會帶上一個叫If-Modified-Since的時間戳字段，它的值正是上一次Response Headers返回給它的Last-Modifield值:

If-Modified-Since: Fri, 27 Oct 2017 06:35:57 GMT
複製代碼

服務器接收到這個時間戳後，會比對該時間戳和資源在服務器上的最後修改時間是否一致，從而判斷資源是否發生了變化。若是發生了變化，就會返回一個完整的響應內容，並在Response Headers中添加新的Last-Modified值；不然，返回304響應，同時Response Headers不會再添加Last-Modified字段。

4. ETag與If-None-Match的配合

對於Last-Modified的使用是存在弊端的：①服務器不能正確感知文件的變化，如編輯但未修改文件，也會被當成了修改，②文件修改過快也感知不到，由於精度是秒。因此出現了ETag，由服務器爲每一個資源生成的惟一的標識字符串，這個標識字符串是基於文件內容編碼的，只要文件內容不一樣，它們對應的ETag就是不一樣的。

ETag和Last-Modified相似，當首次請求時，咱們會在響應頭裏獲取到一個最初的標識符字符串：

ETag: W/"2a3b-1602480f459"
複製代碼

那麼下一次請求時，請求頭裏就會帶上一個值相同的、名爲if-None-Match的字符串供服務端比對了：

If-None-Match: W/"2a3b-1602480f459"
複製代碼

特色：ETag優先級更高，當ETag和Last-Modified同時存在時，以ETag爲準。
優勢：精確感應文件變化。
缺點：ETag的生成過程須要服務器額外付出開銷，會影響服務端的性能。

5. 緩存策略

瞭解了以上緩存，在面對一個具體的緩存需求時，咱們到底該如何決策？

根據以上Chrome官方給出的這張策略圖：①當咱們的資源內容不可複用時，直接爲Cache-Control設置 no-store，拒絕一切形式的緩存；②不然考慮是否每次都須要向服務器進行緩存有效確認，若是須要，那麼設 Cache-Control的值爲no-cache；③不然考慮該資源是否能夠被代理服務器緩存，根據其結果決定是設置爲 private仍是public；④而後考慮該資源的過時時間，設置對應的max-age和s-maxage值；⑤最後，配置協商緩存須要用到的Etag、Last-Modified等參數。

3、HTTPS

3.1. HTTP的不足

①身份被假裝
②報文被篡改
③內容被竊聽

因此針對以上問題須要進行身份驗證、通訊加密及內容加密。

HTTP協議中沒有加密機制，但能夠經過和SSL(Secure Socket Layer，安全套接層)或TLS(Transport Layer Security，安全層傳輸協議)的組合使用，加密HTTP的通訊內容。與SSL組合使用的HTTP被稱爲HTTPS(HTTPSecure，超文本傳輸安全協議)。

一般，HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊，因此HTTPS是身披SSL外殼的HTTP。SSL採用一種叫作公開密鑰加密(Public-key cryptography)的加密處理方式。

1. 通訊加密

公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰(private key)，另外一把叫作公開密鑰(public key)。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。

雖然這樣解決了加密的問題，但公開祕鑰加密處理速度相對比較慢，因此引入了一種共享祕鑰加密方式，就是通訊雙方都使用相同的祕鑰進行加密和解密，而使得雙方安全的獲得這個祕鑰就須要使用上述的公開祕鑰加密方式進行祕鑰的傳輸。HTTPS就是採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。

2. 身份驗證

通訊加密方式解決了，可是如何證實公開祕鑰是貨真價實的呢？

爲了解決這個問題，可以使用由數字證書認證機構和其相關機關頒發的公開密鑰證書。首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。公鑰證書也可叫作數字證書或直接稱爲證書。接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰，以便能將公開密鑰安全地轉交給客戶端。