網絡七層模型及TCP、UDP，一次HTTP請求都發生了什么

一、七層網絡模型

• http協議運行在應用層
  

 

二、TCP-UDP

1. TCP、UDP協議的區別

2. 一次Http 請求，這個過程都發生了什么

3. TCP 協議如何保證可靠傳輸

4. HTTP和HTTPS的區別

5. TCP三次握手和四次揮手、

6. 常見的狀態碼。

 

2.1 TCP-UDP 區別

• UDP及UDP使用場景
  傳送數據之前不需要先建立連接，直接向目標機器發送數據。遠地主機在收到 UDP 報文后，不需要給出任何確認。UDP 報文可能丟失，但是在視頻流、直播流 等場景下 UDP 工作非常有效率（即時通信，不在乎數據丟失，和安全）如 視頻 、直播等

• TCP 及TCP 使用場景
  面向連接的服務。先連接再傳數據，數據傳送結束后要釋放連接。 TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的，面向連接的運輸服務（TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完后，還會斷開連接用來節約系統資源），這一難以避免增加了許多開銷，如確認，流量控制，計時器以及連接管理等。這不僅使協議數據單元的首部增大很多，還要占用許多處理機資源。TCP 一般用於文件傳輸、發送和接收郵件、遠程登錄等場景。（信息安全比較重要的數據傳輸）

 

2.2 一次Http請求都發生了什么

1. 用戶瀏覽器輸入網址

2. 瀏覽器拿到網址去請求IP

3. 向目標IP 發送TCP連接 3次握手

4. 服務器解析請求，並返回處理好的 html 頁面（字符串）

5. 瀏覽器按照規則解析渲染畫面

6. 連接結束

第一點：無

 

第二點：瀏覽器解析用戶輸入網址的過程順序為：

先檢查本地是否有對應的IP地址，找到就返回。找不到向上一級DNS服務器請求，直到找到或 根節點。   瀏覽器緩存--> 系統緩存--> 路由器緩存--> ISP DNS緩存--> 從根域名服務器遞歸搜索 都沒找到就返回錯誤

第三點：三次握手

   第一次握手：發送端先發送一個帶SYN (synchronize) 同步標志的數據包給 Server，在一定時間內等待接收回復   第二次握手：服務端接收到SYN數據包后，返回一個帶 SYN/ACK (acknowledgement charactor) 確認字符 標志的數據包來表示確認收到消息。   第三次握手：接收方接收到Server的確認消息后，再發送一個帶ACK標志的數據包給接收端，表示握手成功   注意：上述過程都有一個等待時間，如果在等待時間內Server、或者Client 沒有回復，本次請求視作失敗，再次請求。Server沒有回復的原因可能是棧滿了

- 建立連接成功后，瀏覽器向WEB服務器發送一個HTTP請求

三次握手的作用：

• 目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

1. 第一次握手：Client 什么都不能確認；Server 確認了對方發送正常

2. 第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己接收正常，對方發送正常

3. 第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送接收正常

• Server傳回發送端所發送的 SYN 是為了告訴發送端，接收到的信息確實就是你發送的信號。

• 雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方到Server的通道沒有問題，Server到發送方的通道就通過 ACK 信號來進行驗證。

第四步：ngimx + uwsgi (Django) 為列 （未完成）

1. Nginx 部分（未完成）

2. Django部分：
   根據請求的 URL。來到Django 的路由關系映射，
   然后通過一系列 Middleware 中間件（process_request(request,)）如CSRF IP黑名單過濾，爬蟲過濾等中間件驗證
   來到url 對應的 Views 視圖函數處理。根據請求內容。去數據庫、Templates 拿到數據回來進行渲染，並返回 response 結果
   response 再次通過一系列中間件驗證。（process_response(request, response)）最后返回給Client

第五步：瀏覽器渲染

瀏覽器拿到結果按照HTML CSS JS 進行渲染

第六步：四次揮手，斷開連接


• 客戶端-發送一個 FIN，用來關閉客戶端到服務器的數據傳送

• 服務器-收到這個 FIN，它發回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將占用一個序號

• 服務器-關閉與客戶端的連接，發送一個FIN給客戶端

• 客戶端-發回 ACK 報文確認，並將確認序號設置為收到序號加1