引言

在现代应用开发中，网络通信是绕不开的核心议题。无论是构建传统的 Web 应用，还是开发需要实时交互的系统（如在线协作工具、金融行情推送、多人游戏），我们总会与 TCP、HTTP、WebSocket 这些名词打交道。它们之间究竟是何种关系？为何有了 HTTP 之后还需要 WebSocket？

本文旨在从开发者的视角，深入剖析这三者之间的技术关联与演进逻辑。我们将逐层递进，从底层的传输协议到上层的应用规范，清晰地揭示它们各自的职责、设计哲学以及在不同场景下的技术选型考量。

第一层：基石 - TCP，一切可靠通信的源头

TCP (Transmission Control Protocol，传输控制协议) 是网络协议栈中的传输层协议。它的核心使命只有一个：提供一个可靠的、面向连接的、基于字节流的端到端通信服务。可以将其理解为网络世界的“可靠管道”，后续的应用层协议（如HTTP和WebSocket）都构建在这条管道之上。

TCP 的核心机制

为了实现“可靠性”，TCP 设计了几个关键机制：

1. 三次握手 (Three-Way Handshake)：在数据传输前，客户端与服务器必须建立连接。

   • SYN (Synchronize Sequence Numbers): 客户端发送一个SYN包，请求建立连接并同步初始序列号。
   • SYN-ACK: 服务器收到后，回复一个SYN-ACK包，确认客户端的请求，并发送自己的初始序列号。
   • ACK: 客户端收到后，再发送一个ACK包，表示确认收到服务器的同步信号。至此，一个双向可靠的连接建立完成。

   这个过程确保了双方都具备收发数据的能力，并就初始序列号达成了一致，为后续的数据包排序和确认奠定了基础。

2. 可靠数据传输：

   • 序列号 (Sequence Number): TCP 将发送的数据分割成块，并为每个块分配一个唯一的序列号。
   • 确认应答 (Acknowledgement, ACK): 接收方每收到一个数据块，都会发送一个ACK包，告知发送方“我已经收到了序列号为X的数据”。
   • 超时重传 (Timeout Retransmission): 如果发送方在一定时间内没有收到某个数据块的ACK，它会认为该数据包丢失，并重新发送。

3. 流量控制 (Flow Control)：通过滑动窗口 (Sliding Window) 机制，接收方可以告知发送方自己还有多少缓冲区空间可以接收数据，防止发送方过快发送数据导致接收方缓冲区溢出。

4. 拥塞控制 (Congestion Control)：通过慢启动、拥塞避免等算法，TCP 能够感知网络拥堵状况，动态调整发送速率，避免造成网络瘫痪。

开发者视角：我们通常不直接操作 TCP。操作系统内核的网络栈已经为我们处理了这一切复杂性。当我们使用高级语言（如Java, Go, Python）创建一个 Socket 时，我们得到的实际上就是一个封装好的 TCP 通道。我们只管往里写数据（write）和从里面读数据（read），可靠性由底层 TCP 保证。

第二层：规约 - HTTP，构建 Web 世界的无状态契约

HTTP (HyperText Transfer Protocol) 是一个应用层协议，它构建于 TCP 之上。它定义了客户端（通常是浏览器）和服务器之间请求和响应的格式与规则。

HTTP 的核心特性

1. 请求-响应模型 (Request-Response Model)：通信严格由客户端发起。客户端发送一个请求，服务器返回一个响应。服务器不能主动向客户端推送信息。

2. 无状态 (Stateless)：每个 HTTP 请求都是独立的。服务器不会记录前一个请求的任何信息。这种设计简化了服务器的实现，使其易于水平扩展。但对于需要维持登录状态等场景，则必须借助外部机制，如 Cookies 和 Session。

连接管理的演进

这是理解 HTTP 性能瓶颈与优化的关键：

• HTTP/1.0 - 短连接:
  最早的设计是“一次请求，一次连接”。每个 HTTP 请求都需要经历一次完整的 TCP握手 -> 数据传输 -> TCP挥手 流程。当一个网页包含大量图片、CSS、JS文件时，这种模式会产生巨大的连接建立开销。

• HTTP/1.1 - 持久连接 (Persistent Connection / Keep-Alive):
  为了解决短连接的低效问题，HTTP/1.1 默认启用持久连接。客户端和服务器在完成一次请求-响应后，不会立即关闭 TCP 连接，而是会保持一段时间（由 Keep-Alive-Timeout 控制）。后续的请求可以复用这个已建立的 TCP 通道，从而省去了多次握手的开销。

  请求头示例:

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

  Connection: keep-alive 明确告知服务器希望保持连接。尽管这是 HTTP/1.1 的默认行为，但显式声明是一种良好实践。

  开发者视角：持久连接极大地提升了 Web 页面加载性能。但其本质并未改变——依然是客户端发起，服务器响应。对于需要服务器主动、低延迟推送数据的场景（如聊天室），客户端只能通过轮询 (Polling) 或长轮询 (Long Polling) 等方式模拟，但这会带来延迟和资源浪费。

第三层：进化 - WebSocket，打破请求-响应枷锁的全双工通道

WebSocket 协议同样是构建于 TCP 之上的应用层协议。它的出现，正是为了解决 HTTP 在实时通信领域的根本性缺陷。

WebSocket 的诞生：协议升级

WebSocket 的巧妙之处在于，它通过一次标准的 HTTP 请求来完成“握手”和“协议升级”。

1. 客户端发起升级请求: 客户端发送一个特殊的 HTTP GET 请求。

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

   • Upgrade: websocket: 表明客户端希望将协议从 HTTP 升级到 WebSocket。
   • Connection: Upgrade: 一个标准的 HTTP/1.1 头，配合 Upgrade 使用。
   • Sec-WebSocket-Key: 一个 Base64 编码的随机字符串，用于简单的握手认证，防止意外的或恶意的连接。

2. 服务器响应升级: 如果服务器支持 WebSocket，它会返回状态码 101 Switching Protocols。

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

   • Sec-WebSocket-Accept: 服务器将客户端的 Sec-WebSocket-Key 与一个固定的“魔术字符串” (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) 拼接后，计算 SHA-1 哈希，再进行 Base64 编码得到。客户端会验证此值，以确认服务器确实理解 WebSocket 协议。

握手成功后，这个底层的 TCP 连接就不再用于传输 HTTP 数据了。它被“劫持”并升级为一个全双工、持久化的 WebSocket 通道。

WebSocket 的核心优势

1. 全双工通信 (Full-Duplex): 一旦连接建立，客户端和服务器的地位完全平等。任何一方都可以随时向对方主动发送数据，无需等待对方的请求。

2. 持久化连接: 连接会一直保持，直到某一方明确地关闭它。这避免了反复建立连接的开销，并保证了通信的即时性。

3. 更小的数据开销: WebSocket 的数据帧（Frame）格式非常轻量。每个数据帧只有很小的头部（2-10字节），相比每次请求都携带大量冗余信息的 HTTP 头部，其传输开销极低。

JavaScript 客户端代码示例:

// 1. 创建 WebSocket 连接 (URL 使用 ws:// 或 wss://)
const socket = new WebSocket('wss://example.com/chat');
// 2. 监听连接打开事件
socket.onopen = function(event) {
  console.log('Connection established!');
  // 连接建立后，可以立即发送消息
  socket.send('Hello Server!');
};
// 3. 监听消息接收事件
socket.onmessage = function(event) {
  // event.data 包含了从服务器接收到的数据
  console.log('Message from server: ', event.data);
};
// 4. 监听连接关闭事件
socket.onclose = function(event) {
  if (event.wasClean) {
    console.log(`Connection closed cleanly, code=${event.code}, reason=${event.reason}`);
  } else {
    console.error('Connection died');
  }
};
// 5. 监听错误事件
socket.onerror = function(error) {
  console.error(`[error] ${error.message}`);
};

总结与对比

结语

理解 TCP、HTTP 和 WebSocket 的关系，本质上是理解网络通信抽象层次的演进过程：

• TCP 是坚实可靠的地基，它不关心上层应用在“说什么”，只负责把话“可靠地”送到。
• HTTP 是建立在地基之上的标准化“问答亭”，规矩森严（一问一答），通用性极强，构建了整个 Web 世界。
• WebSocket 则是对“问答亭”的一次革命性改造，它保留了地基，但拆掉了亭子，换上了一部“对讲机”，实现了真正自由、高效的实时对话。

作为开发者，在进行技术选型时，清晰地认知每一层协议的边界与能力，才能为特定的业务场景选择最恰当的“通信工具”，从而构建出高效、稳健的应用程序。

​转自https://www.cnblogs.com/aisong/p/18957288