一文走進 HTTP 與 TCP 協議
本文轉載自微信公眾號「三分鐘學前端」，作者sisterAn。轉載本文請聯系三分鐘學前端公眾號。
引言
本文從 OSI 網絡分層(7 層) 開始探討 TCP 與 HTTP 的關系，包含以下幾個部分：
- OSI 網絡分層(7 層)
- TCP 協議(三次握手、四次揮手)
- HTTP
- TCP 與 HTTP 的區別與聯系
OSI 網絡分層(7 層)
Open Systems Interconncection 開放系統互聯：
1 物理層 -> 2 數據鏈路層 -> 3 網絡層(ip)-> 4 傳輸層(tcp) -> 5 會話層 --> 6 表示層 --> 7 應用層(http)
| 協議 | 描述 | |
|---|---|---|
| 第七層 | 應用層 | 支持網絡應用，應用協議僅僅是網絡應用的一個組成部分，運行在不同主機上的進程則使用應用層協議進行通信。主要的協議有：http、ftp、dns、telnet、smtp、pop3等。 |
| 第六層 | 表示層 | 把數據轉換為合適、可理解的語法和語義 |
| 第五層 | 會話層 | 維護網絡中的連接狀態，即保持會話和同步，有 SSL |
| 第四層 | 傳輸層 | 負責為信源和信宿提供應用程序進程間的數據傳輸服務，這一層上主要定義了兩個傳輸協議，即傳輸控制協議TCP和用戶數據報協議UDP。 |
| 第三層 | 網絡層 | 負責將數據報獨立地從信源發送到信宿，主要解決路由選擇、擁塞控制和網絡互聯等問題。IP 在這一層 |
| 第二層 | 數據鏈路層 | 負責將IP數據報封裝成合適在物理網絡上傳輸的幀格式并傳輸，或將從物理網絡接收到的幀解封，取出IP數據報交給網絡層。 |
| 第一層 | 物理層 | 負責將比特流在結點間傳輸，即負責物理傳輸。該層的協議既與鏈路有關也與傳輸介質有關。 |
HTTP 是應用層協議，而 TCP 是傳輸層協議，接下來我們逐一詳細介紹??
TCP
TCP、UDP都是是傳輸層協議：
- 用戶數據報協議 UDP(User Datagram Protocol)：
- 無連接;
- 盡最大努力的交付;
- 面向報文;
- 無擁塞控制;
- 支持一對一、一對多、多對一、多對多的交互通信;
- 首部開銷小(只有四個字段：源端口、目的端口、長度、檢驗和)。
- 傳輸控制協議 TCP(Transmission Control Protocol)：
- 面向連接;
- 每一個TCP連接只能是點對點的(一對一);
- 提供 可靠交付 服務;
- 提供 全雙工 通信;
- 面向字節流。
另外，UDP是面向報文的傳輸方式是應用層交給UDP多長的報文，UDP發送多長的報文，即一次發送一個報文。因此，應用程序必須選擇合適大小的報文
應用程序和 TCP 的交互是一次一個數據塊(大小不等)，但 TCP 把應用程序看成是一連串的無結構的字節流。TCP有一個緩沖，當應該程序傳送的數據塊太長，TCP就可以把它劃分短一些再傳送
當網絡通信時采用 TCP 協議時，在真正的讀寫操作之前，客戶端與服務器端之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接時可以釋放這個連接。連接的建立依靠“三次握手”，而釋放則需要“四次握手”，所以每個連接的建立都是需要資源消耗和時間消耗的
TCP連接過程(三次握手)
第一次握手
客戶端向服務端發送連接請求報文段。該報文段中包含自身的數據通訊初始序號。請求發送后，客戶端便進入 SYN-SENT 狀態。
第二次握手
服務端收到連接請求報文段后，如果同意連接，則會發送一個應答，該應答中也會包含自身的數據通訊初始序號，發送完成后便進入 SYN-RECEIVED 狀態。
第三次握手
當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文?？蛻舳税l完這個報文段后便進入 ESTABLISHED 狀態，服務端收到這個應答后也進入 ESTABLISHED 狀態，此時連接建立成功。
為什么需要三次握手，2次不行嗎?
喂喂喂，我是A，你聽的到嗎?B：在在在，我能聽到，我是B，你能聽到我嗎? A：(聽到了，老子不想理你) B：喂喂喂?聽不聽到?我X，對面死了，我掛了。。
如果只有 2 次的話，B 并不清楚 A 是否收到他發過去的信息。
TCP斷開鏈接(四次揮手)
第一次揮手
若客戶端 A 認為數據發送完成，則它需要向服務端 B 發送連接釋放請求。
第二次揮手
B 收到連接釋放請求后，會告訴應用層要釋放 TCP 鏈接。然后會發送 ACK 包，并進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連接已經釋放，不再接收 A 發的數據了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發送數據給 A。
第三次揮手
B 如果此時還有沒發完的數據會繼續發送，完畢后會向 A 發送連接釋放請求，然后 B 便進入 LAST-ACK 狀態。
PS：通過延遲確認的技術(通常有時間限制，否則對方會誤認為需要重傳)，可以將第二次和第三次握手合并，延遲 ACK 包的發送。
第四次揮手
A 收到釋放請求后，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL(最長報文段壽命，指報文段在網絡中生存的時間，超時會被拋棄) 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答后，也便進入 CLOSED 狀態。
HTTP
HTTP 是建立在 TCP 上的應用層協議，超文本傳送協議。
HTTP 連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。
http1.0 :客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。
http1.1 ：可以在一次連接中處理多個請求，并且多個請求可以重疊進行，不需要等待一個請求結束后就可以再發送一個新的請求
http2.0 ：支持多路復用，一個 TCP 可同時傳輸多個 http 請求，頭部數據還做了壓縮
http3.0 ：使用了 QUIC，開啟多個 TCP 連接，在出現丟包的情況下，只有丟包的 TCP 等待重傳，剩余的 TCP 連接還可以正常傳輸數據
HTTP特點
- 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作。
- 無連接：HTTP/1.1之前，由于無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
- 基于請求和響應：基本的特性，由客戶端發起請求，服務端響應。
- 簡單快速、靈活。
- 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性。
Method
- GET 方法請求一個指定資源的表示形式. 使用GET的請求應該只被用于獲取數據.
- HEAD 方法請求一個與GET請求的響應相同的響應，只返回請求頭，沒有響應體，多數由 JavaScript 發起
- POST 方法用于將實體提交到指定的資源，通常導致狀態或服務器上的副作用的更改.
- PUT 方法用請求有效載荷替換目標資源的所有當前表示。
- DELETE 方法刪除指定的資源。
- CONNECT 方法建立一個到由目標資源標識的服務器的隧道，多用于 HTTPS 和 WebSocket 。
- OPTIONS 方法，預檢，用于描述目標資源的通信選項。通過該請求來知道服務端是否允許跨域請求。
- TRACE 方法沿著到目標資源的路徑執行一個消息環回測試，多數線上服務都不支持
- PATCH 方法用于對資源應用部分修改。
HTTP 與 TCP 區別
TCP 協議對應于傳輸層，而 HTTP 協議對應于應用層，從本質上來說，二者沒有可比性：
- HTTP 對應于應用層，TCP 協議對應于傳輸層
- HTTP 協議是在 TCP 協議之上建立的，HTTP 在發起請求時通過 TCP 協議建立起連接服務器的通道，請求結束后，立即斷開 TCP 連接
- HTTP 是無狀態的短連接，而 TCP 是有狀態的長連接
- TCP是傳輸層協議，定義的是數據傳輸和連接方式的規范，HTTP是應用層協議，定義的是傳輸數據的內容的規范
說明：從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件(如Apache)中設定這個時間。
來自：https://github.com/Advanced-Frontend/Daily-Interview-Question
