TCP/IP協議以及HTTP解讀

對TCP/IP以及HTTP的知識實在太混亂，有些方面存在盲點，故整理了相關知識點。

TCP/IP協議

TCP/IP協議模型：

對端傳輸：

TCP三次握手四次揮手

注：SYN: 同步序列號；Seq：發送序號；ACK：確認字符

三次握手過程：

一握手 : 客戶端向服務端發送請求報文段,SYN爲1，Seq 爲X，隨後進入SYN_SEND

二握手 : 服務的接收請求報文，發送ACK：x+1，SYN：1，Seq ： Y。隨後進入SYN_RECV

三握手 : 向服務器發送Seq+ACK報文，發送完畢後客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

爲何須要第三次握手？

第三次握手在理論上是能夠徹底省略的，在第二次握手服務器詢問客戶端是否準備好時就應該創建鏈接。那爲何要存在第三次握手呢？

爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。產生緣由主要是由於客戶端第一次握手請求在某種狀況下延誤到鏈接釋放後纔到達服務段，若是隻使用兩次握手這時鏈接已經創建，但這個鏈接永遠不會使用，也不會釋放，server的不少資源就白白浪費掉了。

第一次揮手： 主機1（可使客戶端，也能夠是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

第二次揮手： 主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；

第三次揮手： 主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次揮手： 主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

爲何要四次揮手？

TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經所有發送完畢了；可是，這個時候主機1仍是能夠接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，可是主機2仍是能夠發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，以後彼此就會愉快的中斷此次TCP鏈接。

簡單的 HTTP 協議

請求行

請求行（Request line）分爲三個部分：請求方法、請求地址和協議版本

請求頭

Cache-Control

• no-cache 指客戶端不緩存過時資源
• no-store 指不進行緩存
• max-age 指緩存資源的緩存時間比指定的值小，那麼客戶端就接受緩存資源，且緩存服務器不對資源有效性進行再次確認

Connection 指控制再也不轉發給代理的首部字段（Hop-by-hop），管理持久鏈接

• close 指服務器像明確斷開鏈接
• Keep-Alive 指保存持久鏈接，HTTP/1.1前默認鏈接是非持久性的，如須要保存持久鏈接，須要增長此字段

Upgrade 能夠用來指定一個徹底不一樣的通訊協議，對於這個字段，服務器能夠返回101狀態碼

請求體

Post 和 Get 的區別

先引入反作用和冪等的概念。

反作用指對服務器上的資源作改變，搜索是無反作用的，註冊是反作用的。

冪等指發送 M 和 N 次請求（二者不相同且都大於1），服務器上資源的狀態一致。註冊10個和11個賬號是不冪等的，對文章進行更改10次和11次是冪等的。

在規範的應用場景上說，Get 多用於無反作用，冪等的場景，例如搜索關鍵字。Post 多用於反作用，不冪等的場景，例如註冊。

在技術上說：

• Get 請求能緩存，Post 不能
• Post 相對 Get 安全一點點，由於Get 請求都包含在 URL 裏，且會被瀏覽器保存歷史紀錄，Post 不會，可是在抓包的狀況下都是同樣的。
• Post 能夠經過 request body來傳輸比 Get 更多的數據，Get 沒有這個技術
• URL有長度限制，會影響 Get 請求，可是這個長度限制是瀏覽器規定的，不是 RFC 規定的
• Post 支持更多的編碼類型且不對數據類型限制

參考文檔

juejin.im/post/587230…

juejin.im/post/598ba1…