在当今互联网世界中，数据通信是所有应用运行的基础。无论是打开网页、发送消息还是视频通话，背后都依赖于各种网络协议的协同工作。其中，TCP/IP、UDP、HTTP、HTTPS 和 WebSocket 是最为核心的几种协议。本文将围绕它们的概念、特性和适用场景，进行一次系统而通俗的讲解。
一、TCP/IP：互联网的基础通信协议
1.1 什么是 TCP/IP？
TCP/IP 是“Transmission Control Protocol/Internet Protocol”的缩写，中文翻译为“传输控制协议/网际协议”。它不仅仅是两个协议，而是一个协议族（Protocol Suite），由一系列用于计算机之间通信的协议构成。
我们可以将 TCP/IP 理解为“互联网的语言”，它定义了数据如何从一台计算机传输到另一台计算机，是现代互联网通信的基础架构。
1.2 TCP/IP 的四层模型
TCP/IP 协议族采用的是一种四层模型（不同于 OSI 七层模型），每一层都承担不同的通信职责：
| TCP/IP 层次 | 对应 OSI 层 | 功能简介 |
|---|---|---|
| 应用层 | 应用层、表示层、会话层 | 提供网络服务接口（如 HTTP、FTP、DNS） |
| 传输层 | 传输层 | 提供端到端的数据传输（如 TCP、UDP） |
| 网络层 | 网络层 | 实现寻址与路由（如 IP、ICMP） |
| 网络接口层 | 数据链路层、物理层 | 管理物理网络接口（如 Ethernet、Wi-Fi） |
1.3 各层协议详解
1.3.1 应用层
-
功能：与用户直接交互，提供应用服务。
-
常见协议：
-
HTTP/HTTPS：浏览网页
-
FTP：文件传输
-
SMTP/POP3/IMAP：电子邮件
-
DNS：域名解析
-
1.3.2 传输层
-
功能：实现不同主机之间的数据传输控制，确保完整性。
-
代表协议：
-
TCP（传输控制协议）：面向连接、可靠传输、有序、校验等特性
-
UDP（用户数据报协议）：无连接、快速、不可靠但效率高
-
1.3.3 网络层
-
功能：确定数据从源地址到目标地址的路径。
-
代表协议：
-
IP（网际协议）：提供逻辑地址（如 IPv4、IPv6）
-
ICMP：用于错误检测和网络诊断（如 ping 命令）
-
1.3.4 网络接口层
-
功能：处理物理网络硬件和信号传输细节。
-
协议/技术：Ethernet、Wi-Fi、光纤、PPP 等
1.4 TCP/IP 的核心协议机制
（1）IP：定位和传输
IP（Internet Protocol）是互联网协议的缩写，是网络中用于标识设备地址的协议。就像每个人有身份证，每台联网的设备都有一个唯一的 IP 地址。
-
作用：为每台设备分配一个唯一地址（如 192.168.0.1），负责寻找最优路径，将数据包从源地址传输到目标地址。
-
特点：不保证数据可靠性、不保证顺序，需配合传输层使用。
🌐IPv4 与 IPv6 (IP地址的两种格式）
| 项目 | IPv4 | IPv6 |
|---|---|---|
| 地址长度 | 32 位 | 128 位 |
| 表示方式 | 点分十进制（如 192.168.1.1） | 十六进制冒号分隔（如 2001:0db8::1） |
| 地址数量 | 约 42 亿（2³²） | 几乎无限（2¹²⁸） |
| 是否枯竭 | ✅ 已经枯竭 | ❌ 尚未枯竭 |
| 是否需要 NAT | 需要（私网转公网） | 不需要（每台设备都有全球地址） |
| 安全性 | 较弱，需要额外协议（如 IPsec） | 内置 IPsec，安全性更强 |
| 速度 | 一般 | 理论上更快（依赖网络设施支持） |
（2）TCP：可靠传输的基石
2.1连接建立：三次握手（Three-way Handshake）
重点：为啥需要三次握手？目的是客户端和服务端需要确保对方的接收和发送能力都正常。
✅ 第一次握手（Client → Server）
-
客户端 A 向服务器 B 发送一个 SYN 报文（序列号 seq = x），表示请求建立连接。(SYN指Synchronize同步)
✅ 第二次握手（Server → Client）
-
服务器 B 收到后，向客户端 A 返回一个 SYN + ACK 报文（序列号 seq = y，确认号 ack = x + 1），表示“我收到你的请求，并同意建立连接”。
✅ 第三次握手（Client → Server）
-
客户端 A 收到确认后，再发送一个 ACK 报文（确认号 ack = y + 1），表示“我也确认建立连接”，至此连接建立完成。
2.2连接断开：四次挥手（Four-way Handshake）
✅ 第一次挥手（Client → Server）
-
客户端发送 FIN 报文，表示自己不再发送数据了，进入 FIN_WAIT_1 状态。(FIN:Finish)
-
表示：我这边要关闭连接了，不再发送数据。（仍然可以接收消息）
✅ 第二次挥手（Server → Client）
-
服务器收到后发送 ACK 确认，进入 CLOSE_WAIT 状态，客户端此时进入 FIN_WAIT_2。
-
表示：我知道了，但我还有数据没发完。
✅ 第三次挥手（Server → Client）
-
服务器数据发完后，发送 FIN 报文，进入 LAST_ACK 状态。
-
表示：我这边也要断开连接了。
✅ 第四次挥手（Client → Server）
-
客户端收到 FIN 后，发送 ACK 确认，进入 TIME_WAIT 状态，等待一段时间后完全关闭。
-
表示：我知道了，咱俩断了！
🔚 最后服务器收到 ACK 后，进入 CLOSED 状态，连接彻底关闭。
2.3 核心功能：
-
重传机制：数据包丢失时自动重发
-
有序传输：接收端按顺序组装数据
-
流量控制：防止接收方处理不过来
-
拥塞控制：避免网络阻塞
1.5 TCP/IP 的现实意义与作用
-
构建互联网通信基础：所有 Web、邮件、FTP 等网络应用都基于 TCP/IP 协议运行。
-
跨平台通信协议：不同操作系统、不同硬件设备只要遵守 TCP/IP 协议，就能互联互通。
-
可扩展、可演化：随着 IPv6、QUIC 等新技术发展，TCP/IP 协议体系也在不断演进。
二、UDP：轻量级通信的利器
UDP（User Datagram Protocol）用户数据报协议
它是 TCP/IP 协议族中的一员，和 TCP 并列，都是传输层协议。
2.1 UDP 的特点：
2.1.1 无连接
-
发送数据前不需要建立连接
-
只管发，像寄快递不用打电话确认你在不在家
2.1.2 头部开销小
-
UDP 报文头部只有 8 个字节, 对比 TCP 的 20 字节，整整轻了 60%
-
UDP 报文结构：
源端口号（2字节）
目的端口号（2字节）
长度（2字节）
校验和（2字节）
2.1.3 不保证可靠
-
不重传、不排序、不校验顺序，收不收得到看运气
-
简洁快速，但可靠性需上层协议自己处理
2.1.4 更快更实时
-
没有三次握手和挥手，发就完了
-
适合对实时性要求高的应用（如语音、视频、直播、在线游戏）
2.2 UDP描述
🔧 UDP 的利器用途（应用场景）
| 应用场景 | 原因 |
|---|---|
| 🎮 在线游戏 | 快速响应、低延迟比可靠性更重要 |
| 📞 VoIP电话 | 一点点丢包可以容忍，不能容忍延迟 |
| 📺 视频直播 | 流畅 > 完整，允许偶尔丢帧 |
| 🔁 DNS 解析 | 请求短小（UDP 512字节足够），失败再发一遍就行 |
| 📶 局域网广播 | 可同时向多个设备发送数据，UDP 支持广播和多播 |
| 📤 自定义协议 | 一些系统（如 QUIC）底层使用 UDP，自建可靠机制 |
📌 UDP vs TCP 对比总结：
| 特性 | TCP | UDP |
|---|---|---|
| 是否连接 | ✅ 面向连接（需要三次握手） | ❌ 无连接 |
| 是否可靠 | ✅ 保证顺序/无重传/无丢包 | ❌ 不保证，可能丢包/乱序 |
| 开销大小 | ❌ 头部大（20 字节） | ✅ 头部小（8 字节） |
| 传输速度 | 慢（有确认、拥塞控制） | 快（无确认、无控制） |
| 实时性 | ❌ 比较差 | ✅ 非常好 |
| 应用场景 | 文件传输、网页浏览等 | 视频、语音、游戏、DNS等 |
🧠 补充：UDP 不可靠，那怎么用？
UDP 本身是不可靠，但你可以自己“加料”，比如：
-
加序号字段，自己排序；
-
加 ACK 字段，自己确认；
-
加超时重传逻辑；
-
这就是很多协议（如 RTP、QUIC）采用的策略。
总结一句话，UDP是“不可靠的快递”，快得起飞，用好了就是搞实时通信的神奇！
三、HTTP：网页通信的核心协议
HTTP（HyperText Transfer Protocol），超文本传输协议，是浏览器和服务器之间进行数据通信的规则。
它基于客户端-服务器（C/S）模型，是 Web 世界中最基础的协议，几乎所有网页请求（HTML、图片、视频、接口）都依赖它。
3.1 请求和响应报文格式
HTTP 请求报文的格式如下：
请求行 （请求方法、URL、协议版本）
请求头 （多个字段，键值对格式，描述客户端信息）
空行
请求体 （仅在POST、PUT等请求方法中有，包含实际提交的数据）
✅ 示例：
POST 127.0.0.1:8080/login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
username=admin&password=123
HTTP 响应报文的格式如下：
状态行 （协议版本、状态码、状态描述）
响应头 （多个字段，键值对格式，描述服务端信息和相应内容）
空行
响应体 （HTML、JSON、文件等）
✅ 示例：
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 137
<html>
<head><title>Example</title></head>
<body><h1>Hello, world!</h1></body>
</html>
3.2 常见的HTTP方法
| 方法 | 作用 |
|---|---|
| GET | 获取资源（最常用） |
| POST | 提交数据（如表单） |
| PUT | 更新资源 |
| DELETE | 删除资源 |
| HEAD | 获取响应头，不返回正文 |
| OPTIONS | 查询服务器支持哪些方法 |
| PATCH | 局部更新（比 PUT 灵活） |
3.3 常见状态码
| 状态码 | 含义 |
|---|---|
| 200 | OK，请求成功 |
| 301 | 永久重定向 |
| 302 | 临时重定向 |
| 400 | 请求错误（客户端问题） |
| 401 | 未授权（需登录） |
| 403 | 禁止访问 |
| 404 | 找不到资源 |
| 500 | 服务器内部错误 |
| 503 | 服务不可用（服务器超载等） |
3.4 HTTP的特点
-
无状态：每次请求独立不记录身份，需要 Cookie / Session 补充身份识别
-
明文传输：数据裸奔，容易被窃听（用 HTTPS 加密解决）
-
基于 TCP：通信底层依赖 TCP 三次握手
3.5 HTTP版本演进
| 版本 | 特点 |
|---|---|
| HTTP/1.0 |
|
| HTTP/1.1 |
|
| HTTP/2 |
|
| HTTP/3 |
|
👉 现在主流已是 HTTP/2 和 HTTP/3，但服务器和浏览器需同时支持。
四、HTTPS：更安全的 HTTP
HTTPS（HyperText Transfer Protocol Secure） 是 HTTP + SSL/TLS 的组合。
简单来说：
HTTPS = 用 SSL/TLS 加密的 HTTP
4.1 HTTP的三大问题（安全隐患）
| 问题 | 风险举例 |
|---|---|
| 明文传输 | 密码、隐私数据容易被窃听 |
| 无法校验身份 | 容易遭受中间人攻击（MITM） |
| 无完整性保护 | 数据可被篡改 |
4.2 HTTPS握手流程
4.3 HTTPS 的核心技术组成
1. 对称加密
-
双方使用相同密钥
-
加解密速度快
-
用于实际数据传输
2. 非对称加密（公钥/私钥）
-
用公钥加密，用私钥解密（或反过来）
-
安全但效率低
-
用于传递对称密钥
3. 数字证书
-
证明服务器身份的“身份证”
-
由权威机构（CA）颁发
4.4 HTTPS 与 HTTP 的区别总结
| 对比项 | HTTP | HTTPS |
|---|---|---|
| 安全性 | ❌ 明文传输 | ✅ 加密传输、防篡改 |
| 端口 | 默认 80 | 默认 443 |
| 协议 | 基于 TCP | 基于 TLS + TCP |
| 性能 | 快（无加密） | 稍慢（握手 & 加解密） |
| 证书 | 不需要 | 需要 SSL 数字证书 |
| 浏览器标志 | 普通，易受攻击 | 🔒 小锁图标，安全连接 |
HTTPS 是 HTTP 的加密安全版，通过加密通信、身份认证和数据完整性保护，让你的网络传输更安全、更可信！
五、WebSocket：实时双向通信的新标准
WebSocket 是 HTML5 提出的网络通信协议，它建立在 TCP 协议之上，可以在客户端和服务器之间建立长连接，并支持全双工通信（双向同时收发）。
1. 单工通信（Simplex）
-
定义：数据只能沿着 单一方向 传输。
-
特点：一方只能发，另一方只能收。
-
例子：
-
广播电台（电台发 → 听众收，听众不能回传）。
-
键盘输入（键盘 → 电脑）。
-
2. 半双工通信（Half-Duplex）
-
定义：数据可以在两个方向传输，但 同一时刻只能单向或者交替传输。
-
特点：发送和接收需要轮流切换。
-
例子：
-
对讲机（你说的时候对方只能听，对方要回复就得等你说完再切换）。
-
老式的无线电通信。
-
3. 全双工通信（Full-Duplex）
-
定义：数据可以在两个方向 同时传输。
-
特点：发送和接收互不影响，实时性强。
-
例子：
-
电话（你说话的同时也能听到对方说话）。
-
WebSocket 连接（客户端与服务端可以同时发送和接收消息）。
-
5.1 WebSocket 通信流程
1️⃣ 初始握手（仍是 HTTP 请求）
客户端发起连接：
GET /chat HTTP/1.1 # 请求方法 GET，请求路径 /chat，使用 HTTP/1.1 协议
Host: server.com # 目标服务器地址（域名或IP）
Upgrade: websocket # 请求协议升级为 WebSocket
Connection: Upgrade # 告诉服务器当前连接要升级（配合 Upgrade 使用）
Sec-WebSocket-Key: xxxxxxxxxx== # 客户端随机生成的 Base64 编码字符串，服务端用它计算握手响应
Sec-WebSocket-Version: 13 # WebSocket 协议版本，目前标准是 13
服务器响应（同意升级协议）：
HTTP/1.1 101 Switching Protocols # 状态码 101：协议切换成功
Upgrade: websocket # 确认升级协议为 WebSocket
Connection: Upgrade # 确认连接升级
Sec-WebSocket-Accept: yyyyyyyyyy== # 服务端返回的验证字符串：
# 取客户端的 Sec-WebSocket-Key
# 拼接固定 GUID "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
# 做 SHA-1 哈希，再进行 Base64 编码
握手成功后，协议升级，正式进入 WebSocket 通信阶段！
2️⃣ 建立连接后，通信如下：
双向实时数据流（不再重复握手）
客户端 <================================> 服务器
5.2 WebSocket 数据帧格式
WebSocket 不再传输完整 HTTP 报文，而是按帧发送，格式更紧凑。
-
数据帧类型（Opcode）：
-
0x1: 文本 -
0x2: 二进制 -
0x8: 关闭连接 -
0x9: Ping（心跳） -
0xA: Pong（回应心跳）
-
-
WebSocket 内建心跳机制，可自动维持连接活性。
5.3 HTTP vs WebSocket 的核心区别
| 对比项 | HTTP | WebSocket |
|---|---|---|
| 连接方式 | 请求-响应，短连接 | 单次握手，后续保持连接 |
| 通信方向 | 单向/半双工（客户端请求，服务器响应） | 双向/全双工（客户端和服务器随时通信） |
| 建立过程 | 每次通信都重新连接 | 一次连接后持续保持 |
| 实时性 | 差 | 很好 |
| 协议端口 | 80 / 443 | 默认也是 80（ws）或 443（wss） |
| 协议名称 | http / https | ws / wss（加密） |
5.4 WebSocket 常见应用场景
| 场景 | 描述 |
|---|---|
| 聊天室 | 多人实时消息推送 |
| 实时通知系统 | 用户登录、支付提醒等 |
| 在线游戏 | 快速同步玩家状态 |
| 股票/币价推送 | 实时数据流展示 |
| 协同编辑 | Google Docs 等实时文档协作 |
| 在线客服 | 人机聊天 |
代码示例（Spring Boot + 前端原生 JS）
👉 服务端（Spring Boot WebSocket）
import jakarta.websocket.*;
import jakarta.websocket.server.ServerEndpoint;
import org.springframework.stereotype.Component;
import java.io.IOException;
import java.util.concurrent.CopyOnWriteArraySet;
@ServerEndpoint("/ws/chat")
@Component
public class ChatWebSocket {
// 存放连接的客户端
private static final CopyOnWriteArraySet<ChatWebSocket> clients = new CopyOnWriteArraySet<>();
private Session session;
@OnOpen
public void onOpen(Session session) {
this.session = session;
clients.add(this);
System.out.println("新连接加入，总数：" + clients.size());
}
@OnClose
public void onClose() {
clients.remove(this);
System.out.println("连接关闭，总数：" + clients.size());
}
@OnMessage
public void onMessage(String message, Session session) throws IOException {
System.out.println("收到消息：" + message);
// 群发消息
for (ChatWebSocket client : clients) {
client.session.getBasicRemote().sendText(message);
}
}
@OnError
public void onError(Session session, Throwable error) {
error.printStackTrace();
}
}
👉 前端（HTML + 原生 JS）
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>WebSocket 聊天室</title>
</head>
<body>
<h2>聊天室</h2>
<input id="msg" placeholder="输入消息..."/>
<button onclick="sendMsg()">发送</button>
<div id="chat"></div>
<script>
let ws = new WebSocket("ws://localhost:8080/ws/chat");
ws.onopen = () => {
console.log("连接成功");
};
ws.onmessage = (event) => {
let chatDiv = document.getElementById("chat");
chatDiv.innerHTML += "<p>" + event.data + "</p>";
};
ws.onclose = () => {
console.log("连接关闭");
};
function sendMsg() {
let msg = document.getElementById("msg").value;
ws.send(msg);
}
</script>
</body>
</html>
WebSocket 是一种轻量、高效的实时通信协议，适用于需要快速响应和持续连接的现代 Web 应用场景，是 HTTP 的有力补充！
扫一扫
7355
到【灌水乐园】发言
