[[397802]]

本文轉載自微信公眾號「三分鐘學前端」，作者sisterAn。轉載本文請聯(lián)系三分鐘學前端公眾號。

引言

本文從 OSI 網(wǎng)絡分層(7 層) 開始探討 TCP 與 HTTP 的關系，包含以下幾個部分：

• OSI 網(wǎng)絡分層(7 層)
• TCP 協(xié)議(三次握手、四次揮手)
• HTTP
• TCP 與 HTTP 的區(qū)別與聯(lián)系

OSI 網(wǎng)絡分層(7 層)

Open Systems Interconncection 開放系統(tǒng)互聯(lián)：

1 物理層 -> 2 數(shù)據(jù)鏈路層 -> 3 網(wǎng)絡層(ip)-> 4 傳輸層(tcp) -> 5 會話層 --> 6 表示層 --> 7 應用層(http)

HTTP 是應用層協(xié)議，而 TCP 是傳輸層協(xié)議，接下來我們逐一詳細介紹??

TCP

TCP、UDP都是是傳輸層協(xié)議：

• 用戶數(shù)據(jù)報協(xié)議 UDP(User Datagram Protocol)：
  • 無連接;
  • 盡最大努力的交付;
  • 面向報文;
  • 無擁塞控制;
  • 支持一對一、一對多、多對一、多對多的交互通信;
  • 首部開銷小(只有四個字段：源端口、目的端口、長度、檢驗和)。
• 傳輸控制協(xié)議 TCP(Transmission Control Protocol)：
  • 面向連接;
  • 每一個TCP連接只能是點對點的(一對一);
  • 提供 可靠交付 服務;
  • 提供 全雙工 通信;
  • 面向字節(jié)流。

另外，UDP是面向報文的傳輸方式是應用層交給UDP多長的報文，UDP發(fā)送多長的報文，即一次發(fā)送一個報文。因此，應用程序必須選擇合適大小的報文

應用程序和 TCP 的交互是一次一個數(shù)據(jù)塊(大小不等)，但 TCP 把應用程序看成是一連串的無結構的字節(jié)流。TCP有一個緩沖，當應該程序傳送的數(shù)據(jù)塊太長，TCP就可以把它劃分短一些再傳送

當網(wǎng)絡通信時采用 TCP 協(xié)議時，在真正的讀寫操作之前，客戶端與服務器端之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接時可以釋放這個連接。連接的建立依靠“三次握手”，而釋放則需要“四次握手”，所以每個連接的建立都是需要資源消耗和時間消耗的

TCP連接過程(三次握手)

第一次握手

客戶端向服務端發(fā)送連接請求報文段。該報文段中包含自身的數(shù)據(jù)通訊初始序號。請求發(fā)送后，客戶端便進入 SYN-SENT 狀態(tài)。

第二次握手

服務端收到連接請求報文段后，如果同意連接，則會發(fā)送一個應答，該應答中也會包含自身的數(shù)據(jù)通訊初始序號，發(fā)送完成后便進入 SYN-RECEIVED 狀態(tài)。

第三次握手

當客戶端收到連接同意的應答后，還要向服務端發(fā)送一個確認報文。客戶端發(fā)完這個報文段后便進入 ESTABLISHED 狀態(tài)，服務端收到這個應答后也進入 ESTABLISHED 狀態(tài)，此時連接建立成功。

為什么需要三次握手，2次不行嗎?

喂喂喂，我是A，你聽的到嗎?B：在在在，我能聽到，我是B，你能聽到我嗎? A：(聽到了，老子不想理你) B：喂喂喂?聽不聽到?我X，對面死了，我掛了。。

如果只有 2 次的話，B 并不清楚 A 是否收到他發(fā)過去的信息。

TCP斷開鏈接(四次揮手)

第一次揮手

若客戶端 A 認為數(shù)據(jù)發(fā)送完成，則它需要向服務端 B 發(fā)送連接釋放請求。

第二次揮手

B 收到連接釋放請求后，會告訴應用層要釋放 TCP 鏈接。然后會發(fā)送 ACK 包，并進入 CLOSE_WAIT 狀態(tài)，此時表明 A 到 B 的連接已經(jīng)釋放，不再接收 A 發(fā)的數(shù)據(jù)了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發(fā)送數(shù)據(jù)給 A。

第三次揮手

B 如果此時還有沒發(fā)完的數(shù)據(jù)會繼續(xù)發(fā)送，完畢后會向 A 發(fā)送連接釋放請求，然后 B 便進入 LAST-ACK 狀態(tài)。

PS：通過延遲確認的技術(通常有時間限制，否則對方會誤認為需要重傳)，可以將第二次和第三次握手合并，延遲 ACK 包的發(fā)送。

第四次揮手

A 收到釋放請求后，向 B 發(fā)送確認應答，此時 A 進入 TIME-WAIT 狀態(tài)。該狀態(tài)會持續(xù) 2MSL(最長報文段壽命，指報文段在網(wǎng)絡中生存的時間，超時會被拋棄) 時間，若該時間段內沒有 B 的重發(fā)請求的話，就進入 CLOSED 狀態(tài)。當 B 收到確認應答后，也便進入 CLOSED 狀態(tài)。

HTTP

HTTP 是建立在 TCP 上的應用層協(xié)議，超文本傳送協(xié)議。

HTTP 連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

http1.0 :客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。

http1.1 ：可以在一次連接中處理多個請求，并且多個請求可以重疊進行，不需要等待一個請求結束后就可以再發(fā)送一個新的請求

http2.0 ：支持多路復用，一個 TCP 可同時傳輸多個 http 請求，頭部數(shù)據(jù)還做了壓縮

http3.0 ：使用了 QUIC，開啟多個 TCP 連接，在出現(xiàn)丟包的情況下，只有丟包的 TCP 等待重傳，剩余的 TCP 連接還可以正常傳輸數(shù)據(jù)

HTTP特點

• 無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力，比如訪問一個網(wǎng)站需要反復進行登錄操作。
• 無連接：HTTP/1.1之前，由于無狀態(tài)特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區(qū)別是否已經(jīng)響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
• 基于請求和響應：基本的特性，由客戶端發(fā)起請求，服務端響應。
• 簡單快速、靈活。
• 通信使用明文、請求和響應不會對通信方進行確認、無法保護數(shù)據(jù)的完整性。

Method

• GET 方法請求一個指定資源的表示形式. 使用GET的請求應該只被用于獲取數(shù)據(jù).
• HEAD 方法請求一個與GET請求的響應相同的響應，只返回請求頭，沒有響應體，多數(shù)由 JavaScript 發(fā)起
• POST 方法用于將實體提交到指定的資源，通常導致狀態(tài)或服務器上的副作用的更改.
• PUT 方法用請求有效載荷替換目標資源的所有當前表示。
• DELETE 方法刪除指定的資源。
• CONNECT 方法建立一個到由目標資源標識的服務器的隧道，多用于 HTTPS 和 WebSocket 。
• OPTIONS 方法，預檢，用于描述目標資源的通信選項。通過該請求來知道服務端是否允許跨域請求。
• TRACE 方法沿著到目標資源的路徑執(zhí)行一個消息環(huán)回測試，多數(shù)線上服務都不支持
• PATCH 方法用于對資源應用部分修改。

HTTP 與 TCP 區(qū)別

TCP 協(xié)議對應于傳輸層，而 HTTP 協(xié)議對應于應用層，從本質上來說，二者沒有可比性：

• HTTP 對應于應用層，TCP 協(xié)議對應于傳輸層
• HTTP 協(xié)議是在 TCP 協(xié)議之上建立的，HTTP 在發(fā)起請求時通過 TCP 協(xié)議建立起連接服務器的通道，請求結束后，立即斷開 TCP 連接
• HTTP 是無狀態(tài)的短連接，而 TCP 是有狀態(tài)的長連接
• TCP是傳輸層協(xié)議，定義的是數(shù)據(jù)傳輸和連接方式的規(guī)范，HTTP是應用層協(xié)議，定義的是傳輸數(shù)據(jù)的內容的規(guī)范

說明：從HTTP/1.1起，默認都開啟了Keep-Alive，保持連接特性，簡單地說，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件(如Apache)中設定這個時間。

來自：https://github.com/Advanced-Frontend/Daily-Interview-Question