引言

在現(xiàn)代應(yīng)用開(kāi)發(fā)中，網(wǎng)絡(luò)通信是繞不開(kāi)的核心議題。無(wú)論是構(gòu)建傳統(tǒng)的 Web 應(yīng)用，還是開(kāi)發(fā)需要實(shí)時(shí)交互的系統(tǒng)（如在線協(xié)作工具、金融行情推送、多人游戲），我們總會(huì)與 TCP、HTTP、WebSocket 這些名詞打交道。它們之間究竟是何種關(guān)系？為何有了 HTTP 之后還需要 WebSocket？

本文旨在從開(kāi)發(fā)者的視角，深入剖析這三者之間的技術(shù)關(guān)聯(lián)與演進(jìn)邏輯。我們將逐層遞進(jìn)，從底層的傳輸協(xié)議到上層的應(yīng)用規(guī)范，清晰地揭示它們各自的職責(zé)、設(shè)計(jì)哲學(xué)以及在不同場(chǎng)景下的技術(shù)選型考量。

第一層：基石 - TCP，一切可靠通信的源頭

TCP (Transmission Control Protocol，傳輸控制協(xié)議) 是網(wǎng)絡(luò)協(xié)議棧中的傳輸層協(xié)議。它的核心使命只有一個(gè)：提供一個(gè)可靠的、面向連接的、基于字節(jié)流的端到端通信服務(wù)。可以將其理解為網(wǎng)絡(luò)世界的“可靠管道”，后續(xù)的應(yīng)用層協(xié)議（如HTTP和WebSocket）都構(gòu)建在這條管道之上。

TCP 的核心機(jī)制

為了實(shí)現(xiàn)“可靠性”，TCP 設(shè)計(jì)了幾個(gè)關(guān)鍵機(jī)制：

1. 三次握手 (Three-Way Handshake)：在數(shù)據(jù)傳輸前，客戶端與服務(wù)器必須建立連接。

   • SYN (Synchronize Sequence Numbers): 客戶端發(fā)送一個(gè)SYN包，請(qǐng)求建立連接并同步初始序列號(hào)。
   • SYN-ACK: 服務(wù)器收到后，回復(fù)一個(gè)SYN-ACK包，確認(rèn)客戶端的請(qǐng)求，并發(fā)送自己的初始序列號(hào)。
   • ACK: 客戶端收到后，再發(fā)送一個(gè)ACK包，表示確認(rèn)收到服務(wù)器的同步信號(hào)。至此，一個(gè)雙向可靠的連接建立完成。

   這個(gè)過(guò)程確保了雙方都具備收發(fā)數(shù)據(jù)的能力，并就初始序列號(hào)達(dá)成了一致，為后續(xù)的數(shù)據(jù)包排序和確認(rèn)奠定了基礎(chǔ)。

2. 可靠數(shù)據(jù)傳輸：

   • 序列號(hào) (Sequence Number): TCP 將發(fā)送的數(shù)據(jù)分割成塊，并為每個(gè)塊分配一個(gè)唯一的序列號(hào)。
   • 確認(rèn)應(yīng)答 (Acknowledgement, ACK): 接收方每收到一個(gè)數(shù)據(jù)塊，都會(huì)發(fā)送一個(gè)ACK包，告知發(fā)送方“我已經(jīng)收到了序列號(hào)為X的數(shù)據(jù)”。
   • 超時(shí)重傳 (Timeout Retransmission): 如果發(fā)送方在一定時(shí)間內(nèi)沒(méi)有收到某個(gè)數(shù)據(jù)塊的ACK，它會(huì)認(rèn)為該數(shù)據(jù)包丟失，并重新發(fā)送。

3. 流量控制 (Flow Control)：通過(guò)滑動(dòng)窗口 (Sliding Window) 機(jī)制，接收方可以告知發(fā)送方自己還有多少緩沖區(qū)空間可以接收數(shù)據(jù)，防止發(fā)送方過(guò)快發(fā)送數(shù)據(jù)導(dǎo)致接收方緩沖區(qū)溢出。

4. 擁塞控制 (Congestion Control)：通過(guò)慢啟動(dòng)、擁塞避免等算法，TCP 能夠感知網(wǎng)絡(luò)擁堵?tīng)顩r，動(dòng)態(tài)調(diào)整發(fā)送速率，避免造成網(wǎng)絡(luò)癱瘓。

開(kāi)發(fā)者視角：我們通常不直接操作 TCP。操作系統(tǒng)內(nèi)核的網(wǎng)絡(luò)棧已經(jīng)為我們處理了這一切復(fù)雜性。當(dāng)我們使用高級(jí)語(yǔ)言（如Java, Go, Python）創(chuàng)建一個(gè) Socket 時(shí)，我們得到的實(shí)際上就是一個(gè)封裝好的 TCP 通道。我們只管往里寫(xiě)數(shù)據(jù)（write）和從里面讀數(shù)據(jù)（read），可靠性由底層 TCP 保證。

第二層：規(guī)約 - HTTP，構(gòu)建 Web 世界的無(wú)狀態(tài)契約

HTTP (HyperText Transfer Protocol) 是一個(gè)應(yīng)用層協(xié)議，它構(gòu)建于 TCP 之上。它定義了客戶端（通常是瀏覽器）和服務(wù)器之間請(qǐng)求和響應(yīng)的格式與規(guī)則。

HTTP 的核心特性

1. 請(qǐng)求-響應(yīng)模型 (Request-Response Model)：通信嚴(yán)格由客戶端發(fā)起。客戶端發(fā)送一個(gè)請(qǐng)求，服務(wù)器返回一個(gè)響應(yīng)。服務(wù)器不能主動(dòng)向客戶端推送信息。

2. 無(wú)狀態(tài) (Stateless)：每個(gè) HTTP 請(qǐng)求都是獨(dú)立的。服務(wù)器不會(huì)記錄前一個(gè)請(qǐng)求的任何信息。這種設(shè)計(jì)簡(jiǎn)化了服務(wù)器的實(shí)現(xiàn)，使其易于水平擴(kuò)展。但對(duì)于需要維持登錄狀態(tài)等場(chǎng)景，則必須借助外部機(jī)制，如 Cookies 和 Session。

連接管理的演進(jìn)

這是理解 HTTP 性能瓶頸與優(yōu)化的關(guān)鍵：

• HTTP/1.0 - 短連接:
  最早的設(shè)計(jì)是“一次請(qǐng)求，一次連接”。每個(gè) HTTP 請(qǐng)求都需要經(jīng)歷一次完整的 TCP握手 -> 數(shù)據(jù)傳輸 -> TCP揮手 流程。當(dāng)一個(gè)網(wǎng)頁(yè)包含大量圖片、CSS、JS文件時(shí)，這種模式會(huì)產(chǎn)生巨大的連接建立開(kāi)銷(xiāo)。

• HTTP/1.1 - 持久連接 (Persistent Connection / Keep-Alive):
  為了解決短連接的低效問(wèn)題，HTTP/1.1 默認(rèn)啟用持久連接。客戶端和服務(wù)器在完成一次請(qǐng)求-響應(yīng)后，不會(huì)立即關(guān)閉 TCP 連接，而是會(huì)保持一段時(shí)間（由 Keep-Alive-Timeout 控制）。后續(xù)的請(qǐng)求可以復(fù)用這個(gè)已建立的 TCP 通道，從而省去了多次握手的開(kāi)銷(xiāo)。

  請(qǐng)求頭示例:

  GET /style.css HTTP/1.1
  Host: example.com
  Connection: keep-alive 
  

  Connection: keep-alive 明確告知服務(wù)器希望保持連接。盡管這是 HTTP/1.1 的默認(rèn)行為，但顯式聲明是一種良好實(shí)踐。

  開(kāi)發(fā)者視角：持久連接極大地提升了 Web 頁(yè)面加載性能。但其本質(zhì)并未改變——依然是客戶端發(fā)起，服務(wù)器響應(yīng)。對(duì)于需要服務(wù)器主動(dòng)、低延遲推送數(shù)據(jù)的場(chǎng)景（如聊天室），客戶端只能通過(guò)輪詢 (Polling) 或長(zhǎng)輪詢 (Long Polling) 等方式模擬，但這會(huì)帶來(lái)延遲和資源浪費(fèi)。

第三層：進(jìn)化 - WebSocket，打破請(qǐng)求-響應(yīng)枷鎖的全雙工通道

WebSocket 協(xié)議同樣是構(gòu)建于 TCP 之上的應(yīng)用層協(xié)議。它的出現(xiàn)，正是為了解決 HTTP 在實(shí)時(shí)通信領(lǐng)域的根本性缺陷。

WebSocket 的誕生：協(xié)議升級(jí)

WebSocket 的巧妙之處在于，它通過(guò)一次標(biāo)準(zhǔn)的 HTTP 請(qǐng)求來(lái)完成“握手”和“協(xié)議升級(jí)”。

1. 客戶端發(fā)起升級(jí)請(qǐng)求: 客戶端發(fā)送一個(gè)特殊的 HTTP GET 請(qǐng)求。

   GET /chat HTTP/1.1
   Host: example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Sec-WebSocket-Version: 13
   

   • Upgrade: websocket: 表明客戶端希望將協(xié)議從 HTTP 升級(jí)到 WebSocket。
   • Connection: Upgrade: 一個(gè)標(biāo)準(zhǔn)的 HTTP/1.1 頭，配合 Upgrade 使用。
   • Sec-WebSocket-Key: 一個(gè) Base64 編碼的隨機(jī)字符串，用于簡(jiǎn)單的握手認(rèn)證，防止意外的或惡意的連接。

2. 服務(wù)器響應(yīng)升級(jí): 如果服務(wù)器支持 WebSocket，它會(huì)返回狀態(tài)碼 101 Switching Protocols。

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
   

   • Sec-WebSocket-Accept: 服務(wù)器將客戶端的 Sec-WebSocket-Key 與一個(gè)固定的“魔術(shù)字符串” (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) 拼接后，計(jì)算 SHA-1 哈希，再進(jìn)行 Base64 編碼得到。客戶端會(huì)驗(yàn)證此值，以確認(rèn)服務(wù)器確實(shí)理解 WebSocket 協(xié)議。

握手成功后，這個(gè)底層的 TCP 連接就不再用于傳輸 HTTP 數(shù)據(jù)了。它被“劫持”并升級(jí)為一個(gè)全雙工、持久化的 WebSocket 通道。

WebSocket 的核心優(yōu)勢(shì)

1. 全雙工通信 (Full-Duplex): 一旦連接建立，客戶端和服務(wù)器的地位完全平等。任何一方都可以隨時(shí)向?qū)Ψ街鲃?dòng)發(fā)送數(shù)據(jù)，無(wú)需等待對(duì)方的請(qǐng)求。

2. 持久化連接: 連接會(huì)一直保持，直到某一方明確地關(guān)閉它。這避免了反復(fù)建立連接的開(kāi)銷(xiāo)，并保證了通信的即時(shí)性。

3. 更小的數(shù)據(jù)開(kāi)銷(xiāo): WebSocket 的數(shù)據(jù)幀（Frame）格式非常輕量。每個(gè)數(shù)據(jù)幀只有很小的頭部（2-10字節(jié)），相比每次請(qǐng)求都攜帶大量冗余信息的 HTTP 頭部，其傳輸開(kāi)銷(xiāo)極低。

JavaScript 客戶端代碼示例:

// 1. 創(chuàng)建 WebSocket 連接 (URL 使用 ws:// 或 wss://)
const socket = new WebSocket('wss://example.com/chat');
// 2. 監(jiān)聽(tīng)連接打開(kāi)事件
socket.onopen = function(event) {
  console.log('Connection established!');
  // 連接建立后，可以立即發(fā)送消息
  socket.send('Hello Server!');
};
// 3. 監(jiān)聽(tīng)消息接收事件
socket.onmessage = function(event) {
  // event.data 包含了從服務(wù)器接收到的數(shù)據(jù)
  console.log('Message from server: ', event.data);
};
// 4. 監(jiān)聽(tīng)連接關(guān)閉事件
socket.onclose = function(event) {
  if (event.wasClean) {
    console.log(`Connection closed cleanly, code=${event.code}, reason=${event.reason}`);
  } else {
    console.error('Connection died');
  }
};
// 5. 監(jiān)聽(tīng)錯(cuò)誤事件
socket.onerror = function(error) {
  console.error(`[error] ${error.message}`);
};

總結(jié)與對(duì)比

結(jié)語(yǔ)

理解 TCP、HTTP 和 WebSocket 的關(guān)系，本質(zhì)上是理解網(wǎng)絡(luò)通信抽象層次的演進(jìn)過(guò)程：

• TCP 是堅(jiān)實(shí)可靠的地基，它不關(guān)心上層應(yīng)用在“說(shuō)什么”，只負(fù)責(zé)把話“可靠地”送到。
• HTTP 是建立在地基之上的標(biāo)準(zhǔn)化“問(wèn)答亭”，規(guī)矩森嚴(yán)（一問(wèn)一答），通用性極強(qiáng)，構(gòu)建了整個(gè) Web 世界。
• WebSocket 則是對(duì)“問(wèn)答亭”的一次革命性改造，它保留了地基，但拆掉了亭子，換上了一部“對(duì)講機(jī)”，實(shí)現(xiàn)了真正自由、高效的實(shí)時(shí)對(duì)話。

作為開(kāi)發(fā)者，在進(jìn)行技術(shù)選型時(shí)，清晰地認(rèn)知每一層協(xié)議的邊界與能力，才能為特定的業(yè)務(wù)場(chǎng)景選擇最恰當(dāng)?shù)摹巴ㄐ殴ぞ摺保瑥亩鴺?gòu)建出高效、穩(wěn)健的應(yīng)用程序。

?轉(zhuǎn)自https://www.cnblogs.com/aisong/p/18957288