当前位置：首页 > news >正文

计算机网络——协议

news 2025/8/14 8:45:59

1. 计算机网络分层

1.1 OSI 7层模型

应用层
表示层
会话层
传输层
网络层
数据链路层
物理层

1.2 TCP/IP 4 层模型

应用层
运输层
网际层
网络接口层

1.3 5层体系机构

应用层
传输层
网络层
数据链路层
物理层

2. 应用层协议

2.1 HTTP协议

2.1.1 基本介绍

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层的一种协议，用于客户端（如浏览器）与服务器之间传输超文本（如 HTML 页面、图片、视频等）。它是 Web 的基础，建立在 TCP 协议之上，确保数据的可靠传输。HTTP协议的默认端口是80。

特点	说明
无状态（Stateless）	每个请求之间相互独立，服务器不会记住前一个请求的状态。
基于请求-响应模型	客户端发送请求，服务器返回响应。
可扩展性强	支持多种数据类型（通过 `Content-Type` 指定）。
支持持久连接	HTTP/1.1 默认启用 `keep-alive`，可复用 TCP 连接。
明文传输	默认不加密（HTTP），安全性差；HTTPS 使用 SSL/TLS 加密。

2.1.2 工作流程

HTTP 的典型工作流程如下：

建立 TCP 连接
客户端与服务器通过 三次握手 建立 TCP 连接（默认端口 80）。
客户端发送 HTTP 请求
客户端构造请求报文，包含：请求行、请求头、空行、请求体（可选）。
服务器处理请求并返回响应
服务器解析请求，处理业务逻辑，生成响应报文（状态行、响应头、响应体）。
客户端接收并解析响应
浏览器渲染页面或应用程序处理数据。
关闭连接（可选）
- 若使用 Connection: close，则立即四次挥手断开。
- 若使用 Connection: keep-alive，连接保持，可复用。

✅ 现代浏览器通常使用连接池和持久连接，避免频繁建立/断开 TCP 连接。

HTTP 协议是应用层协议，它依赖于传输层的 TCP 协议 来保证可靠传输。而：

三次握手：是 TCP 建立连接的过程。
四次挥手：是 TCP 断开连接的过程。

从 HTTP/1.1 开始，默认使用持久连接（也叫长连接），这意味着：

一个 TCP 连接可以被复用来发送多个 HTTP 请求和响应，而不是每次请求都重新建立和关闭连接。

举个例子：

假设你访问一个网页，页面包含：

1 个 HTML 文件
2 个 CSS 文件
3 个 JavaScript 文件
4 张图片

在持久连接下：

客户端与服务器进行一次 三次握手，建立 TCP 连接。
复用这个连接，连续发送 10 个 HTTP 请求（获取资源）。
所有请求完成后，才通过 四次挥手 断开 TCP 连接。

2.1.3 HTTP请求

一个完整的 HTTP 请求由以下三部分组成：

1. 请求行（Request Line）

格式：方法资源路径协议版本

GET /index.html HTTP/1.1

常见方法：
- GET：获取资源
- POST：提交数据
- PUT：更新资源
- DELETE：删除资源
- HEAD：获取响应头（不返回体）
- OPTIONS：预检请求（CORS）

2. 请求头（Request Headers）

键值对形式，提供客户端信息和请求元数据。

常见请求头：

头部	作用
`Host`	指定服务器域名（必需）
`User-Agent`	客户端类型（如浏览器、操作系统）
`Accept`	客户端可接受的响应类型（如 `application/json`）
`Content-Type`	请求体的数据格式（如 `application/json`）
`Authorization`	认证信息（如 Bearer Token）
`Cookie`	发送存储在本地的 Cookie

3. 请求体（Request Body）

仅用于 POST、PUT 等方法。
数据格式由 Content-Type 决定：
- application/json：JSON 数据
- application/x-www-form-urlencoded：表单数据
- multipart/form-data：文件上传

⚠️ 请求头与请求体之间必须有一个空行（\r\n\r\n）。

2.1.4 HTTP响应

服务器返回的响应也由三部分组成：

1. 状态行（Status Line）

格式：协议版本状态码状态描述

HTTP/1.1 200 OK

常见状态码分类：

范围	类型	示例
1xx	信息响应	`100 Continue`
2xx	成功	`200 OK`, `201 Created`
3xx	重定向	`301 Moved Permanently`, `302 Found`
4xx	客户端错误	`400 Bad Request`, `404 Not Found`, `403 Forbidden`
5xx	服务器错误	`500 Internal Server Error`, `502 Bad Gateway`

2. 响应头（Response Headers）

提供服务器信息和响应元数据。

常见响应头：

头部	作用
`Content-Type`	响应体的数据类型（如 `text/html`）
`Content-Length`	响应体长度
`Set-Cookie`	设置 Cookie
`Location`	重定向目标地址（配合 3xx 状态码）
`Cache-Control`	缓存策略
`Server`	服务器类型（如 Nginx、Apache）

3. 响应体（Response Body）

服务器返回的实际数据，如：

HTML 页面
JSON 数据
图片、文件等二进制流

2.1.5 总结

HTTP 请求：
┌─────────────────────────────┐
│ GET /api/users HTTP/1.1     │ ← 请求行
│ Host: example.com           │
│ User-Agent: Chrome          │ ← 请求头
│ Content-Type: application/json │
│                             │ ← 空行
│ {"name": "Tom"}             │ ← 请求体（POST 时存在）
└─────────────────────────────┘HTTP 响应：
┌─────────────────────────────┐
│ HTTP/1.1 200 OK             │ ← 状态行
│ Content-Type: application/json │
│ Content-Length: 15          │ ← 响应头
│ Set-Cookie: session=abc     │
│                             │ ← 空行
│ {"id":1,"name":"Tom"}       │ ← 响应体
└─────────────────────────────┘

✅ 一句话总结：
HTTP 是一种基于 请求-响应模型 的应用层协议，通过 请求行、请求头、请求体 构成请求，通过 状态行、响应头、响应体 构成响应，是 Web 通信的核心。

2.2 HTTPS协议

2.2.1 基本介绍

HTTPS（超文本传输安全协议）是 HTTP 的安全版本，通过在 HTTP 和 TCP 之间加入 SSL/TLS 协议 来实现数据加密，确保通信过程中的 机密性、完整性、身份认证。

默认端口：443（HTTP 是 80）
协议基础：HTTP + SSL/TLS
目标：防止数据被窃听、篡改或冒充

✅ 简单理解：HTTPS = HTTP + 加密 + 认证 + 完整性保护

2.2.2 为什么需要 HTTPS

HTTP 的三大安全问题：

问题	说明
窃听风险	数据明文传输，第三方可监听内容（如密码、银行卡号）
篡改风险	中间人可修改传输内容（如插入广告）
冒充风险	无法确认对方是否是真正的服务器（钓鱼网站）

HTTPS 通过加密和数字证书解决这些问题。

2.2.3 SSL/TLS 协议

SSL（Secure Sockets Layer）和其升级版 TLS（Transport Layer Security）是用于加密通信的安全协议。

现代 HTTPS 使用的是 TLS（如 TLS 1.2、TLS 1.3）
加密过程发生在 TCP 连接建立之后、HTTP 通信之前

2.2.4 工作过程

HTTPS 的安全通信建立在 TLS 握手 的基础上，主要步骤如下：

1. 客户端发起请求（Client Hello）

客户端发送支持的 TLS 版本、加密套件（Cipher Suites）、随机数 Client Random

2. 服务器响应（Server Hello）

服务器选择 TLS 版本和加密套件
返回自己的 数字证书（包含公钥）
生成并发送随机数 Server Random

3. 客户端验证证书

客户端验证证书是否由可信 CA（证书颁发机构） 签发
验证域名是否匹配
验证证书是否过期
✅ 验证通过后，提取服务器公钥

4. 生成会话密钥（Pre-Master Secret）

客户端生成一个随机的 预主密钥（Pre-Master Secret）
使用服务器的 公钥加密 后发送给服务器

5. 服务器解密预主密钥

服务器使用自己的私钥解密，得到预主密钥

6. 双方生成会话密钥

客户端和服务器使用 Client Random、Server Random、Pre-Master Secret 通过算法生成相同的 会话密钥（Session Key）

7. 切换到加密通信

双方通知“握手完成”
后续所有通信（包括 HTTP 请求和响应）都使用 对称加密（会话密钥）进行加密

2.2.5 加密技术详解

HTTPS 结合了两种加密方式，发挥各自优势：

加密方式	用途	特点
非对称加密（如 RSA、ECC）	用于传输“预主密钥”	安全但慢，公钥加密，私钥解密
对称加密（如 AES）	用于加密实际数据（HTTP 报文）	快速高效，加密解密用同一密钥

✅ 优势：既保证了密钥传输的安全性，又提升了通信效率。

2.2.6 数字证书与 CA

数字证书：由可信第三方（CA）签发，包含：
- 域名
- 公钥
- 有效期
- CA 签名
CA（Certificate Authority）：如 Let's Encrypt、DigiCert、Symantec
浏览器内置了受信任的 CA 根证书列表，用于验证服务器证书

🔐 如果证书无效（如自签名、过期、域名不匹配），浏览器会显示“不安全”警告。

2.2.7 HTTPS 与 HTTP 的对比

对比项	HTTP	HTTPS
安全性	明文传输，不安全	加密传输，安全
端口	80	443
协议	应用层	应用层 + SSL/TLS
性能	快（无加密开销）	略慢（握手有开销，但可优化）
SEO	不利于搜索引擎排名	更受搜索引擎青睐
证书	不需要	需要 SSL 证书（可免费获取）

2.3.8 总结

HTTPS 通过 SSL/TLS 对 HTTP 进行加密和身份认证，是保障 Web 安全的基石，已成为现代互联网的标准配置。

2.3 WebSocket

2.3.1 基本介绍

WebSocket 是一种基于 TCP 的应用层协议（RFC 6455），它在客户端和服务器之间提供 全双工（full-duplex）、持久化、双向通信 的通道。与传统的 HTTP 请求-响应模式不同，WebSocket 允许服务器主动向客户端推送数据。

协议标识：
- ws://：非加密 WebSocket（对应 HTTP）
- wss://：加密 WebSocket（对应 HTTPS，基于 TLS）
默认端口：与 HTTP/HTTPS 一致（80 / 443）
设计目标：解决 HTTP 在实时通信场景下的性能瓶颈

✅ 简单理解：
WebSocket = 一次连接，双向通信，服务器可“主动说话”

2.3.2 为什么需要 WebSocket

HTTP 协议的局限性：

问题	说明
单向通信	只能客户端发起请求，服务器被动响应
频繁轮询开销大	实时应用（如聊天、股票）需不断发请求，浪费资源
延迟高	轮询间隔决定延迟，无法做到“即时”
头部开销大	每次请求都携带完整 HTTP 头部

WebSocket 通过持久连接 + 消息帧机制，解决了这些问题。

2.3.3 WebSocket 的工作过程

WebSocket 的建立过程依赖 HTTP，分为两个阶段：

阶段 1：HTTP 握手升级（Upgrade Handshake）

客户端发送一个特殊的 HTTP 请求：

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

服务器如果支持 WebSocket，返回 101 Switching Protocols：

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

✅ 此时，TCP 连接从 HTTP 协议“升级”为 WebSocket 协议。

阶段 2：双向通信

握手成功后，客户端和服务器可以随时互相发送数据帧（Frame），直到任意一方关闭连接。

数据可以是文本（UTF-8）或二进制
通信是全双工的，无需请求-响应模式

2.3.4 WebSocket 通信模型

特性	说明
连接建立	基于 HTTP 升级，仅一次
通信模式	全双工、双向、持久化
数据单位	消息（Message），由一个或多个帧（Frame）组成
消息类型	文本消息（String）、二进制消息（ArrayBuffer/Buffer）
连接保持	连接长期存活，可通过 `ping/pong` 心跳保活

2.3.5 WebSocket API（前端示例）

在浏览器中使用原生 WebSocket API：

// 1. 创建 WebSocket 连接
const socket = new WebSocket('ws://localhost:8080/chat');// 2. 监听连接打开
socket.onopen = function(event) {console.log('连接已建立');socket.send('Hello Server!');
};// 3. 监听消息
socket.onmessage = function(event) {console.log('收到消息:', event.data);
};// 4. 监听错误
socket.onerror = function(error) {console.log('发生错误:', error);
};// 5. 监听连接关闭
socket.onclose = function(event) {console.log('连接已关闭');
};// 发送消息
socket.send('这是一条客户端消息');

2.3.6 适用场景

WebSocket 特别适合需要低延迟、高频、双向通信的场景：

应用场景	示例
💬 实时聊天	微信网页版、在线客服
📈 实时数据推送	股票行情、天气更新、监控系统
🎮 在线游戏	多人互动、实时操作同步
🔔 通知系统	消息提醒、订单状态更新
🖥️ 远程控制	Web SSH、远程桌面

2.3.7 与 HTTP 的对比

对比项	HTTP	WebSocket
通信模式	请求-响应（单向）	全双工（双向）
连接状态	短连接或持久连接	持久化长连接
实时性	差（依赖轮询）	强（服务器可主动推送）
开销	每次请求带完整头部	帧头部小，效率高
建立方式	直接发送请求	先 HTTP 握手，再升级协议
安全性	HTTP / HTTPS	ws:// / wss://（加密）

2.3.8 总结

项目	说明
WebSocket 是什么	一种支持全双工通信的 Web 应用层协议
核心机制	基于 HTTP 升级，建立持久化双向连接
主要用途	实时通信、消息推送、在线互动
关键优势	低延迟、高效、服务器主动推送
发展趋势	已成为现代 Web 实时应用的标准技术

🌐 一句话总结：
WebSocket 通过一次连接实现客户端与服务器的双向实时通信，是构建现代实时 Web 应用的核心技术。

3. 传输层协议

3.1 TCP协议

3.1.1 基本介绍

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接、可靠、基于字节流的传输层协议（RFC 793），广泛用于对数据完整性要求高的应用，如网页浏览、文件传输、电子邮件等。

协议特点：可靠传输、流量控制、拥塞控制、全双工通信
默认端口示例：
- HTTP: 80
- HTTPS: 443
- FTP: 21
- SMTP: 25
设计目标：确保数据在不可靠网络中准确、有序、不丢失地送达

3.1.2 为什么需要 TCP

IP 协议本身不保证可靠性，存在以下问题：

问题	说明
数据丢失	网络拥堵可能导致数据包丢失
数据乱序	数据包可能通过不同路径到达，顺序错乱
数据重复	重传机制可能导致接收端收到重复数据
无连接状态	无法确认对方是否准备好接收数据

TCP 通过连接管理、确认机制、重传、排序、流量控制等机制解决这些问题。

3.1.3 TCP 的工作过程

TCP 通信分为三个阶段：连接建立、数据传输、连接释放。

阶段 1：三次握手（Three-way Handshake）

建立连接过程：

SYN：客户端发送 SYN=1, seq=x，进入 SYN-SENT 状态
SYN-ACK：服务器回复 SYN=1, ACK=1, seq=y, ack=x+1
ACK：客户端发送 ACK=1, ack=y+1，连接建立

✅ 目的：双方确认彼此具有发送和接收能力

阶段 2：数据传输

双方通过序列号（seq）和确认号（ack） 实现可靠传输
使用滑动窗口实现流量控制
通过慢启动、拥塞避免等机制进行拥塞控制

阶段 3：四次挥手（Four-way Wave）

断开连接过程：

FIN：主动方发送 FIN=1, seq=u
ACK：被动方确认 ACK=1, ack=u+1
FIN：被动方发送自己的 FIN=1, seq=v
ACK：主动方确认 ACK=1, ack=v+1，进入 TIME_WAIT 状态

✅ 为什么四次？因为 TCP 是全双工，两个方向需独立关闭。

3.1.4 TCP 通信模型

特性	说明
连接模式	面向连接（需先建立连接）
可靠性	高（通过确认、重传、校验和）
传输单位	字节流（无消息边界）
流量控制	滑动窗口机制
拥塞控制	慢启动、拥塞避免、快速重传、快速恢复
适用场景	文件传输、网页访问、邮件等要求可靠的应用

3.1.5 TCP 报文结构

字段	说明
源端口 / 目的端口	标识应用进程
序列号（seq）	当前数据第一个字节的编号
确认号（ack）	期望收到的下一个字节序号
数据偏移	TCP 头部长度（通常 20 字节）
控制位	`SYN`, `ACK`, `FIN`, `RST`, `PSH` 等
窗口大小	接收方当前可接收的字节数
校验和	用于检测数据错误

3.1.6 适用场景

应用场景	示例
🌐 网页浏览	HTTP/HTTPS 基于 TCP
📧 电子邮件	SMTP、POP3、IMAP
📂 文件传输	FTP、SFTP
💬 远程登录	SSH、Telnet
🗄️ 数据库访问	MySQL、Redis（默认）

3.1.7 与 UDP 的对比

对比项	TCP	UDP
连接性	面向连接	无连接
可靠性	可靠（确认、重传）	不可靠（尽最大努力交付）
传输方式	字节流	数据报（有边界）
速度	较慢（握手、确认开销）	快（无连接、无确认）
拥塞控制	有	无
适用场景	要求数据完整	要求低延迟

3.1.8 总结

项目	说明
TCP 是什么	一种面向连接、可靠的传输层协议
核心机制	三次握手、确认重传、滑动窗口、拥塞控制
主要用途	可靠数据传输（如网页、文件、邮件）
关键优势	可靠、有序、不重复、流量控制
发展趋势	仍是互联网最主流的传输协议，持续优化（如 TCP BBR）

✅ 一句话总结：
TCP 通过连接管理和确认机制，确保数据在网络中可靠、有序地传输，是互联网通信的“基石协议”。

3.2 UDP协议

3.2.1 基本介绍

UDP（User Datagram Protocol，用户数据报协议）是一种无连接、不可靠、基于数据报的传输层协议（RFC 768），强调传输效率和低延迟。

协议特点：无连接、尽最大努力交付、无重传、无拥塞控制
默认端口示例：
- DNS: 53
- DHCP: 67/68
- SNMP: 161
- 视频/语音：动态端口
设计目标：提供轻量级、低延迟的数据传输服务

3.2.2 为什么需要 UDP

TCP 的可靠性带来较大开销，不适合以下场景：

问题	说明
延迟敏感	实时音视频不能等待重传
高频小包	如游戏状态更新，重传反而造成混乱
广播/多播	TCP 不支持，UDP 支持
自定义可靠性	应用层可自行实现轻量级重传机制

UDP 通过“简单直接”的设计满足这些需求。

3.2.3 UDP 的工作过程

UDP 通信极简，无需握手或挥手：

发送方：构造 UDP 数据报，直接发送
接收方：收到数据报后处理，不发送确认
无连接状态维护，每个数据报独立处理

⚠️ 数据可能丢失、乱序、重复，但速度极快。

3.2.4 UDP 通信模型

特性	说明
连接模式	无连接（发送即走）
可靠性	不可靠（不保证送达）
传输单位	数据报（有明确边界）
传输开销	极小（仅 8 字节头部）
支持广播/多播	✅ 支持
适用场景	实时音视频、在线游戏、DNS 查询

3.2.5 UDP 报文结构

字段	说明
源端口 / 目的端口	标识应用进程（可选）
长度	数据报总长度（头部 + 数据）
校验和	可选，用于检测错误

✅ 头部仅 8 字节，非常轻量。

3.2.6 适用场景

应用场景	示例
🎵 实时音视频	视频会议（WebRTC）、直播
🎮 在线游戏	多人游戏状态同步
🔍 域名查询	DNS 查询响应
📡 广播/多播	局域网发现、流媒体分发
🛰️ 物联网	传感器数据上报

3.2.7 与 TCP 的对比

对比项	TCP	UDP
连接性	面向连接	无连接
可靠性	可靠	不可靠
传输方式	字节流	数据报
速度	较慢	快
拥塞控制	有	无
适用场景	要求完整	要求低延迟

3.2.8 总结

项目	说明
UDP 是什么	一种无连接、不可靠的传输层协议
核心机制	简单数据报传输，无握手、无确认
主要用途	实时通信、广播、轻量级传输
关键优势	低延迟、高效率、支持广播
发展趋势	在实时通信、物联网、QUIC（基于 UDP）中广泛应用

✅ 一句话总结：
UDP 以“简单高效”为核心，牺牲可靠性换取速度，是实时应用和轻量通信的理想选择。

4. 网络层协议

4.1 IP协议

4.1.1 基本介绍

IP（Internet Protocol，网际协议）是网络层的核心协议（IPv4: RFC 791，IPv6: RFC 2460），负责寻址和路由，将数据包从源地址传送到目的地址。

协议版本：
- IPv4：32 位地址（如 192.168.1.1），约 43 亿地址
- IPv6：128 位地址（如 2001:db8::1），地址空间极大
协议特点：无连接、不可靠、尽力而为（Best Effort）
设计目标：实现跨网络的主机间数据包传输

4.1.2 为什么需要 IP

数据通信需跨越多个网络，面临问题：

问题	说明
寻址混乱	需统一地址格式标识全球主机
路由选择	数据包需通过多跳路由器到达目标
分片与重组	不同网络 MTU 不同，需分片传输
异构网络互联	以太网、Wi-Fi、蜂窝网络需统一协议

IP 协议通过统一地址、路由算法、分片机制实现全球互联。

4.1.3 IP 的工作过程

封装：传输层数据（TCP/UDP 报文）封装为 IP 数据报
路由：路由器根据目标 IP 地址查找路由表，转发数据包
分片（IPv4）：若数据包大于链路 MTU，则分片
重组：目标主机重新组装分片
交付：将数据交付给上层协议（通过协议号）

✅ IPv6 不推荐在中间路由器分片，由源端通过 PMTUD 探测路径 MTU。

4.1.4 IP 通信模型

特性	说明
连接模式	无连接（每个数据包独立处理）
可靠性	不可靠（不保证送达、不重传）
传输单位	IP 数据报（Datagram）
寻址方式	IP 地址（IPv4/IPv6）
路由机制	动态路由协议（如 OSPF、BGP）
分片支持	IPv4 支持，IPv6 由源端处理

4.1.5 IP 报文结构

字段	说明
版本	4（IPv4）或 6（IPv6）
头部长度	通常 20 字节
总长度	数据报总长度
标识、标志、片偏移	用于分片与重组
生存时间（TTL）	防止无限循环，每经过一跳减 1
协议	上层协议类型（6: TCP, 17: UDP）
首部校验和	仅校验 IP 头部
源 IP 地址 / 目的 IP 地址	32 位（IPv4）或 128 位（IPv6）

4.1.6 适用场景

应用场景	说明
🌍 全球互联网通信	所有跨网络通信的基础
🖥️ 局域网通信	内网主机间通信（如 192.168.x.x）
📱 移动网络	4G/5G 网络中数据传输
🌐 网站访问	通过 IP 地址定位服务器
🔗 路由器转发	核心路由协议依赖 IP

4.1.7 与 TCP/UDP 的对比

对比项	IP	TCP	UDP
层级	网络层	传输层	传输层
功能	寻址与路由	可靠传输	高效传输
是否可靠	否	是	否
是否面向连接	否	是	否
传输单位	数据报	字节流 / 数据报	数据报

4.1.8 总结

项目	说明
IP 是什么	网络层核心协议，负责寻址与路由
核心机制	IP 地址、路由表、TTL、分片
主要用途	实现全球主机间的数据包传输
关键优势	统一寻址、支持异构网络互联
发展趋势	IPv6 逐步取代 IPv4，解决地址枯竭问题