知識梳理系列之四——網絡協議(TCP/IP、Http/Https)

網絡分層模型若干問題

本文是對基本知識的個人總結，旨在面試遇到時，能邏輯條理清晰。不是全面知識學習文本。

OSI七層模型和TCP/IP四層模型

1. OSI七層網絡模型和TCP/IP四層模型圖示
   
   TCP/IP是一組協議族，包含很多協議，常見的比如UDP、HTTP、S-HTTP(HTTPS)、SSL/TLS、FTP、SMTP、POP3、DHCP、SOCKS等等，其中HTTP/FTP/SMTP/POP3/SOCKS等屬於應用層協議。TCP/UDP協議是網絡層協議、IP協議是傳輸層協議。
   Socket網絡套接字是一個使用TCP/IP的接口，方便訪問和使用這些協議，本身不是協議。

2. 其中HTTPS協議就是HTTP + SSL/TLS
   SSL是Secure Sockets Layer的縮寫，由Netscap發佈，經IEEE標準化爲TLS，目前主流的是TLS 1.1、TLS 1.2版本。

3. TCP與UDP的區別：
   a. TCP保證數據在網絡中的正確性、順序性，而UDP不保證；
   b. UDP由於不保證上述性質，省去了校驗正確和順序收發，在傳輸上更快速。

TCP/IP的握手與揮手

三次握手：

如下圖所示：

說明：三次握手步驟：

• 客戶端服務端分別打開傳輸控制塊TCB，服務端進入LISTEN狀態，客服端發起請求，並帶數據SYN=1,seq=x（seq是一個序列數，序列數一般是發送數據的長度,握手時序列數都是+1不帶其他數據），發送後客戶端進入SYN_SEND狀態；
• 服務端收到請求，並向客戶端回覆數據：ACK=1,SYN=1,ack=x+1,seq=y（表示收到了客戶端的SYN=1,回覆確認ACK=1,並且客戶端的序列數+1,自己的數據序列數y），服務端進入SYN_RCVD狀態；
• 客戶端收到服務端的確認，併發送建立連接確認數據：ACK=1,ack=y+1,seq=x+1（表示客戶端收到了服務端的確認，並回復服務器建立連接），客戶端進入ESTABLISH，服務端收到客戶端的確認數據後也進入ESTABLISH狀態，此時連接建立。

爲什麼要三次握手？

可以看到完成第二次握手時，相當於服務端收到了客戶端的請求，並且客戶端也知曉的狀態，爲什麼還需要進行第三次握手呢？
答案：主要是爲了避免失效請求重複連接
一種常見場景：
一次客戶端請求發出後，網絡環境不暢，請求停留在網絡中，客戶端在長時間沒有收到回覆，嘗試重新請求，此時網絡暢通，併成功建立連接，完成數據交換並關閉連接，此時停留在網絡中的上次請求又到達了服務器。
此時，如果只有兩次握手將再次建立連接，這是不符合預期的！並且造成資源浪費。
那麼是三次握手時，服務端收到失效的請求後，向客戶端發送確認數據，但是客戶端發現自己並沒有請求，於是不做回覆，此時，避免了失效請求導致重複連接！！

---

四次揮手

說明：四次揮手步驟：

• 客戶端發起斷開連接請求，FIN=1,seq=u，客戶端進入FIN-WAIT-1狀態；
• 服務端收到此請求後，回覆客戶端：ACK=1,ack=u+1,seq=v(此時沒有回覆FIN=1，因爲服務端有可能有數據還沒有發送完，只告知客戶端我收到了你的FIN請求，我還有數據沒發完)，此時服務端進入CLOSE_WAIT狀態，客戶端進入FIN-WAIT-2狀態；
• 直到服務端把最後的數據全部發送完成，服務端會再次向客戶端發送：FIN=1,ACK=1,ack=u+1,seq=w（表示我最後的數據已經發完了），服務端進入LAST_ACK狀態，等待客戶端收到確認；
• 客戶端收到後，發送ACK=1,ack=w+1,seq=u+1（告知服務端我收到了），並進入TIME_WAIT狀態，服務端收到後就CLOSE了，客戶端在TIME_WAIT超時後進入CLOSE。

爲什麼要四次揮手？

分解成兩個問題：

1. 爲什麼服務端回覆客戶端的FIN請求，有兩次一次ACK，一次FIN/ACK?
   因爲服務端收到請求後，有可能還有客戶端請求的數據沒有發送完成，所以第一次ACK是告知客戶端我收到你的FIN請求了，第二次FIN/ACK是告知客戶端你要的數據我都發出去了。服務端等客戶端確認知曉其已經發送完了數據，如果期間超時沒有收到確認，服務端還會重發。
2. 爲什麼客戶端CLOSE之前有TIME_WAIT?
   因爲客戶端在收到FIN/ACK後需要給服務端ACK，告知我收到了，如果客戶端發完ACK，立即CLOSE，有可能服務端未收到ACK而關閉不了，TIME_WAIT保持客戶端未關閉，是的服務端沒有收到客戶端的ACK時還可以再重發FIN/ACK；
   另外一個作用是清除網絡中的無效報文。

Http協議與Https協議

HTTP是一種超文本傳輸協議，通常使用統一資源定位符URL來獲取網絡資源。

1. 請求報文格式
    
   請求頭： 請求方法(如GET/POST)     資源路徑或參數     HTTP協議版本
   請求行： 就是Request對象裏的一系列配置
         比如：Host、User-Agent、Content-Type、Content-Length、Content-Encoding、
         Content-Language、Accept-Type、Accept-Language、Connection(Keep-Alive)等等；
   空行
   請求體：(POST有/GET無)
    

2. 響應報文格式
    
   狀態行： 協議版本     狀態碼     狀態短語
   響應頭： Date 時間日期
         charset 、Content-Type
         Content-Length等等
   空行
   響應正文：比如 json 字符串等
    
   狀態碼：

   狀態碼	含義
   1xx	繼續執行
   2xx	成功
   3xx	重定向
   4xx	客戶端錯誤
   5xx	服務端問題

    

3. 與Https的區別
   區別在於在表示層使用了SSL/TLS，來進行身份校驗(服務器CA證書)，並使用密文傳輸請求數據。
   http使用的是明文傳輸。
   https會犧牲一部分速度，但總體影響不大；
   常用的加密方式非對稱加密、對稱加密；

4. 附：有趣的加密原理(離散對數方案)
   非對稱加密的離散對數方案：
   已知公鑰：p、alpha
   ALICE要和BOB加密通信，不希望被EVE竊密；
   希望有一種加密方式，用已知的加密算法，ALICE用私鑰a加密數據Data發送給BOB，BOB接收到密文用自己的私鑰b就能解密；

   EVE只能從網絡中拿到兩者加密後的數據，在一定時間內無法窮舉出密碼。

   ALICE： 將計算：y = alpha^a mod p 將計算結果發送到網絡中；BOB和EVE都可以收到

   BOB：將計算：z = alpha^b mod p 將計算結果發送到網絡中；ALICE和EVE都可以收到

   ALICE：將收到的z 進行計算：z^a mod p

   BOB：將收到的y 進行計算：y^b mod p

   此時發現ALICE和BOB算出了一致的結果，這樣就完成了加密通信的建立，確保兩個身份合法的人連接到了一起，而EVE由於算不出一致的結果而無法竊密。

其中mod就是取餘計算。