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

1、七層網絡模型

• http協議運行在應用層
  

 

2、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