TCP/UDP 网络协议教程 / 01-TCP/UDP 概述
01 - TCP/UDP 概述
1.1 OSI 七层模型
OSI(Open Systems Interconnection)模型将网络通信划分为七层:
| 层级 | 名称 | 功能 | 典型协议 |
|---|---|---|---|
| 7 | 应用层 (Application) | 为应用提供网络服务 | HTTP, FTP, DNS, SMTP |
| 6 | 表示层 (Presentation) | 数据格式转换、加密 | SSL/TLS, JPEG, ASCII |
| 5 | 会话层 (Session) | 建立、管理、终止会话 | NetBIOS, RPC |
| 4 | 传输层 (Transport) | 端到端可靠传输 | TCP, UDP |
| 3 | 网络层 (Network) | 路由和寻址 | IP, ICMP, ARP |
| 2 | 数据链路层 (Data Link) | 帧传输、错误检测 | Ethernet, Wi-Fi |
| 1 | 物理层 (Physical) | 比特流传输 | 光纤、双绞线、无线电 |
┌─────────────────────────────────────────────────────────────┐
│ 应用层 (Layer 7) │
├─────────────────────────────────────────────────────────────┤
│ 表示层 (Layer 6) │
├─────────────────────────────────────────────────────────────┤
│ 会话层 (Layer 5) │
├─────────────────────────────────────────────────────────────┤
│ ★ 传输层 (Layer 4) - TCP/UDP ★ │
├─────────────────────────────────────────────────────────────┤
│ 网络层 (Layer 3) │
├─────────────────────────────────────────────────────────────┤
│ 数据链路层 (Layer 2) │
├─────────────────────────────────────────────────────────────┤
│ 物理层 (Layer 1) │
└─────────────────────────────────────────────────────────────┘
1.2 TCP/IP 协议栈
实际互联网使用的是 TCP/IP 四层模型:
OSI 七层 TCP/IP 四层
───────── ──────────
应用层 ─┐
表示层 ─┼──→ 应用层
会话层 ─┘
传输层 ───→ 传输层
网络层 ───→ 网络层 (Internet)
数据链路层─┐
物理层 ──┼──→ 网络接口层 (Network Interface)
1.3 TCP 与 UDP 核心对比
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接(三次握手) | 无连接 |
| 可靠性 | 可靠传输(确认、重传) | 不可靠 |
| 顺序性 | 保证顺序 | 不保证顺序 |
| 流量控制 | 有(滑动窗口) | 无 |
| 拥塞控制 | 有 | 无 |
| 头部大小 | 20-60 字节 | 8 字节 |
| 传输效率 | 相对较低 | 高 |
| 适用场景 | 文件传输、Web、邮件 | 视频、游戏、DNS |
1.4 TCP 特性详解
TCP 保证可靠传输的核心机制:
1. 序列号 (Sequence Number) → 保证数据顺序
2. 确认应答 (ACK) → 保证数据到达
3. 超时重传 → 丢失恢复
4. 流量控制 → 防止接收方溢出
5. 拥塞控制 → 防止网络拥塞
6. 校验和 → 检测数据错误
1.5 UDP 特性详解
UDP 的设计理念:最小化传输开销
优点:
✓ 头部开销小(8 字节 vs TCP 20+ 字节)
✓ 传输速度快(无握手、无确认)
✓ 支持一对多(广播、多播)
✓ 应用层可控性更强
缺点:
✗ 不保证可靠到达
✗ 不保证顺序
✗ 无流量/拥塞控制
1.6 适用场景对比
TCP 适用场景
# 场景:文件传输 - 数据完整性至关重要
# HTTP/HTTPS 文件下载
import urllib.request
response = urllib.request.urlopen('https://example.com/file.zip')
with open('file.zip', 'wb') as f:
f.write(response.read()) # TCP 保证每个字节都正确到达
| 场景 | 原因 |
|---|---|
| Web 浏览 (HTTP/HTTPS) | 需要完整加载页面 |
| 文件传输 (FTP) | 不能容忍数据丢失 |
| 电子邮件 (SMTP) | 邮件内容必须完整 |
| 数据库连接 | 数据一致性要求高 |
| SSH 远程登录 | 命令和响应必须可靠 |
UDP 适用场景
# 场景:实时视频 - 延迟比完整性更重要
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 视频帧丢失一帧没关系,但不能有延迟等待重传
sock.sendto(video_frame, ('192.168.1.100', 5004))
| 场景 | 原因 |
|---|---|
| 实时视频/音频 | 丢帧可接受,延迟不可接受 |
| 在线游戏 | 实时性要求高 |
| DNS 查询 | 简单的请求-响应模式 |
| DHCP | 局域网广播 |
| IoT 传感器数据 | 小数据包,高频发送 |
1.7 协议选择决策树
需要传输数据
│
├─ 需要可靠传输?
│ ├─ 是 → 数据量大?持续连接?
│ │ ├─ 是 → TCP(Web、文件传输)
│ │ └─ 否 → TCP 或 HTTP/2
│ └─ 否 → 实时性要求高?
│ ├─ 是 → UDP(视频、游戏)
│ └─ 否 → UDP(DNS、IoT)
│
└─ 需要广播/多播?
└─ 是 → UDP
1.8 数据封装过程
应用层数据
↓ + TCP/UDP 头部
传输层段 (Segment)
↓ + IP 头部
网络层包 (Packet)
↓ + 帧头 + 帧尾
数据链路层帧 (Frame)
↓
物理层比特流 (Bits)
# 演示数据封装大小计算
def calculate_overhead(app_data_size):
"""计算各层头部开销"""
tcp_header = 20 # TCP 头部最小 20 字节
ip_header = 20 # IPv4 头部最小 20 字节
ethernet_header = 14 # 以太网帧头 14 字节
ethernet_fcs = 4 # 以太网帧校验 4 字节
total = app_data_size + tcp_header + ip_header + ethernet_header + ethernet_fcs
efficiency = app_data_size / total * 100
return {
'app_data': app_data_size,
'tcp_header': tcp_header,
'ip_header': ip_header,
'ethernet': ethernet_header + ethernet_fcs,
'total': total,
'efficiency': f'{efficiency:.1f}%'
}
# 示例
print(calculate_overhead(1460))
# {'app_data': 1460, 'tcp_header': 20, 'ip_header': 20, 'ethernet': 18,
# 'total': 1518, 'efficiency': '96.2%'}
1.9 常见误区
⚠️ 误区1:UDP 一定比 TCP 快
在网络状况良好时,两者速度差异不大。UDP 的优势在于没有拥塞控制和重传机制带来的延迟。
⚠️ 误区2:TCP 完全可靠
TCP 保证数据按序、完整到达,但如果网络断开,数据仍然会丢失。TCP 的"可靠"是相对于 UDP 而言的。
⚠️ 误区3:UDP 不能用于可靠传输
可以在 UDP 之上实现应用层可靠性,如 QUIC 协议就是基于 UDP 实现的可靠传输。
1.10 业务场景
| 业务 | 协议选择 | 理由 |
|---|---|---|
| 网页浏览 | TCP (HTTP) | 页面完整性 |
| 视频会议 | UDP (RTP) | 低延迟 |
| 文件同步 | TCP (FTP/SCP) | 数据完整性 |
| 在线游戏 | UDP | 实时性 |
| 物联网 | UDP (CoAP) | 轻量级 |
| 邮件 | TCP (SMTP) | 可靠性 |
1.11 扩展阅读
- RFC 793 - TCP 协议规范
- RFC 768 - UDP 协议规范
- RFC 1122 - 主机要求
- 《TCP/IP 详解 卷1》 - W. Richard Stevens
下一章:02 - IP 协议基础 - 理解 TCP/UDP 运行的网络环境