01 - 网络基础：OSI模型与TCP/IP协议栈¶
本章核心: 理解网络通信的分层模型，掌握TCP/IP协议栈基础
📖 章节导航¶
前序章节: 无（本章为基础） 后续章节: 02-域名与DNS.md → 03-服务器与SSH.md 快速参考: 网络工具箱.md 第1章 故障排查: 故障排查手册.md 第3章
📚 引言：为什么需要理解网络分层模型¶
作为程序员，你可能每天都在使用网络：访问API、调用数据库、发送HTTP请求。但你是否想过：
- 为什么输入
www.google.com就能访问到网站？ - 为什么有时候网络请求会超时？
- TCP和UDP有什么区别？什么时候用哪个？
理解网络分层模型就像理解汽车引擎的构造一样，虽然开车不需要知道引擎原理，但作为工程师，理解底层机制能让你：
✅ 快速定位问题：网络连接失败时，知道从哪一层开始排查 ✅ 优化性能：理解TCP三次握手，就知道为什么连接池能提升性能 ✅ 安全防护：知道数据在哪一层加密，才能正确配置HTTPS ✅ 架构设计：选择合适的协议（TCP vs UDP）来满足业务需求
🏗️ OSI七层模型¶
OSI（Open Systems Interconnection）模型是国际标准化组织提出的网络通信参考模型，它将网络通信分为7层，从下到上依次是：
┌─────────────────────────────────────────┐
│ 7. 应用层 (Application Layer) │ ← 用户直接交互的层（HTTP、FTP、SSH）
├─────────────────────────────────────────┤
│ 6. 表示层 (Presentation Layer) │ ← 数据格式化、加密解密
├─────────────────────────────────────────┤
│ 5. 会话层 (Session Layer) │ ← 建立、管理、终止会话
├─────────────────────────────────────────┤
│ 4. 传输层 (Transport Layer) │ ← 端到端通信（TCP、UDP）
├─────────────────────────────────────────┤
│ 3. 网络层 (Network Layer) │ ← 路由选择、IP地址
├─────────────────────────────────────────┤
│ 2. 数据链路层 (Data Link Layer) │ ← MAC地址、帧传输
├─────────────────────────────────────────┤
│ 1. 物理层 (Physical Layer) │ ← 传输介质（光纤、网线、无线电波）
└─────────────────────────────────────────┘
每层的详细功能¶
| 层级 | 名称 | 主要功能 | 常见协议 |
|---|---|---|---|
| 7 | 应用层 | 为应用程序提供网络服务接口 | HTTP、FTP、SMTP、DNS、SSH |
| 6 | 表示层 | 数据格式化、加密压缩、字符编码 | SSL/TLS、JPEG、MPEG |
| 5 | 会话层 | 建立、管理、终止会话连接 | RPC、NetBIOS |
| 4 | 传输层 | 端到端的数据传输、可靠性保证 | TCP、UDP |
| 3 | 网络层 | 路由选择、逻辑地址寻址 | IP、ICMP、IGMP |
| 2 | 数据链路层 | 帧同步、差错控制、MAC地址 | Ethernet、Wi-Fi、ARP（IPv4地址解析） |
| 1 | 物理层 | 比特流传输、物理接口规范 | RJ45、光纤、无线电 |
补充：ARP 用于在同一二层网络内把 IPv4 地址解析为链路层地址，报文直接封装在链路层帧中，通常不被三层路由转发，因此常被视为数据链路层或“2.5 层”协议；IPv6 中对应功能由 NDP（Neighbor Discovery Protocol）提供。
数据在各层的变化（封装与解封装）¶
当数据从发送方传输到接收方时，会经历封装和解封装过程：
发送方（封装过程）：
┌─────────────────────────────────────────────────────────────┐
│ 应用数据 (HTTP请求) │
│ ↓ 添加TCP头部（端口号） │
│ TCP段 (TCP Header + Data) │
│ ↓ 添加IP头部（源IP、目的IP） │
│ IP数据报 (IP Header + TCP Header + Data) │
│ ↓ 添加以太网帧头（MAC地址） │
│ 以太网帧 (Ethernet Header + IP Header + TCP Header + Data) │
│ ↓ 转换为比特流 │
│ 010101010101... (物理层传输) │
└─────────────────────────────────────────────────────────────┘
接收方（解封装过程）：
┌─────────────────────────────────────────────────────────────┐
│ 010101010101... (物理层接收) │
│ ↓ 解析以太网帧 │
│ 以太网帧 → 提取IP数据报 │
│ ↓ 解析IP头部 │
│ IP数据报 → 提取TCP段 │
│ ↓ 解析TCP头部 │
│ TCP段 → 提取应用数据 │
│ ↓ 交给应用程序 │
│ HTTP请求 │
└─────────────────────────────────────────────────────────────┘
📦 生活化类比：寄快递¶
想象你要给朋友寄一封信：
📝 应用层：你写信的内容（"你好，最近怎么样？"）
↓
📦 会话层：决定什么时候寄、怎么确认对方收到
↓
📋 表示层：把信翻译成朋友能理解的语言，或者加密
↓
📮 传输层：选择快递公司（顺丰 vs 圆通），决定是否需要保价（可靠传输）
↓
🗺️ 网络层：填写地址（北京市朝阳区xxx路xxx号），规划路线
↓
🚚 数据链路层：快递员把信装进快递袋，贴上条形码
↓
🛣️ 物理层：货车、飞机、自行车等实际运输工具
🚀 TCP/IP四层模型¶
TCP/IP模型是实际互联网使用的模型，它将OSI的7层简化为4层：
┌─────────────────────────────────────────┐
│ 应用层 (Application Layer) │ ← 对应OSI的应用层、表示层、会话层
├─────────────────────────────────────────┤
│ 传输层 (Transport Layer) │ ← 对应OSI的传输层
├─────────────────────────────────────────┤
│ 网络层 (Internet Layer) │ ← 对应OSI的网络层
├─────────────────────────────────────────┤
│ 网络接口层 (Network Interface Layer) │ ← 对应OSI的数据链路层、物理层
└─────────────────────────────────────────┘
OSI与TCP/IP的对应关系¶
| TCP/IP四层 | 对应的OSI层级 | 核心协议 |
|---|---|---|
| 应用层 | 7、6、5层 | HTTP、HTTPS、FTP、SMTP、DNS、SSH |
| 传输层 | 4层 | TCP、UDP |
| 网络层 | 3层 | IP、ICMP、IGMP |
| 网络接口层 | 2、1层 | Ethernet、Wi-Fi、PPP、ARP（IPv4地址解析） |
为什么TCP/IP更实用？¶
🔹 简化设计：将功能相近的层合并，减少复杂性 🔹 实际应用：互联网就是基于TCP/IP构建的 🔹 灵活性强：应用层可以随时添加新协议（如HTTP/2、HTTP/3）
🔑 关键协议详解¶
1️⃣ IP协议（Internet Protocol）¶
IP协议是网络层的核心协议，负责数据包的路由和寻址。
IP地址¶
IP地址是网络设备的唯一标识，就像家庭地址：
IP地址分类： - 公网IP：全球唯一，可直接访问（如：8.8.8.8） - 私网IP：局域网内使用，不能直接访问 - 10.0.0.0 - 10.255.255.255 - 172.16.0.0 - 172.31.255.255 - 192.168.0.0 - 192.168.255.255
路由原理¶
路由器根据IP地址的网络部分决定数据包的转发方向：
假设你的IP是：192.168.1.100/24
↑
网络部分（前24位）
路由表示例：
目的地 网关 接口
192.168.1.0/24 - eth0 ← 直连网络
0.0.0.0/0 192.168.1.1 eth0 ← 默认网关（互联网）
实际场景： - 你访问 www.baidu.com，DNS解析出IP：110.242.68.66 - 你的电脑发现110.242.68.66不在192.168.1.0/24网段 - 数据包发送给默认网关（路由器） - 路由器根据路由表逐跳转发，最终到达百度服务器
2️⃣ TCP协议（Transmission Control Protocol）¶
TCP是面向连接的、可靠的传输层协议，保证数据不丢失、不重复、按序到达。
三次握手（建立连接）¶
TCP建立连接需要三次握手，确保双方都准备好通信：
客户端 服务器
│ │
│ ─── SYN=1, seq=x ──────────────> │ 第一次握手：客户端请求连接
│ │
│ <── SYN=1, ACK=1, seq=y, ack=x+1 │ 第二次握手：服务器确认并请求连接
│ │
│ ─── ACK=1, seq=x+1, ack=y+1 ──> │ 第三次握手：客户端确认连接
│ │
│ ✅ 连接建立成功 │
为什么需要三次握手？
想象打电话： - 📞 第一次握手：你问"你能听到吗？"（建立连接请求） - 📞 第二次握手：对方回答"我能听到，你能听到我吗？"（确认+反向请求） - 📞 第三次握手：你回答"我也能听到"（确认）
如果只有两次握手： - 你发送的连接请求延迟了，服务器误以为你要建立新连接 - 服务器准备好资源，但你其实已经关闭了连接 - 造成资源浪费
实际代码示例：
import socket
# 客户端
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(('127.0.0.1', 8080)) # 这里会执行三次握手
client.send(b'Hello Server')
四次挥手（断开连接）¶
TCP断开连接需要四次挥手，确保双方数据都传输完毕：
客户端 服务器
│ │
│ ─── FIN=1, seq=u ──────────────> │ 第一次挥手：客户端请求关闭
│ │
│ <── ACK=1, seq=v, ack=u+1 ───── │ 第二次挥手：服务器确认
│ │ （服务器可能还有数据要发送）
│ <── FIN=1, ACK=1, seq=w, ack=u+1 │ 第三次挥手：服务器请求关闭
│ │
│ ─── ACK=1, seq=u+1, ack=w+1 ──> │ 第四次挥手：客户端确认
│ │
│ ✅ 连接关闭成功 │
为什么四次挥手？
因为TCP是全双工的（双向通信）： - 客户端说"我不发数据了"，但可能还要接收数据 - 服务器确认后，可能还有数据要发送给客户端 - 服务器发送完数据后，才说"我也不发了" - 客户端最后确认，连接完全关闭
TCP的可靠传输机制¶
TCP通过以下机制保证可靠性：
- 序列号（Sequence Number）：每个字节都有编号，保证按序到达
- 确认应答（ACK）：收到数据后发送确认，超时未收到则重传
- 流量控制（滑动窗口）：根据接收方能力调整发送速度
- 拥塞控制：网络拥塞时降低发送速率
TCP拥塞控制状态机¶
TCP拥塞控制包含四个核心算法，通过 cwnd（拥塞窗口）和 ssthresh（慢启动阈值）两个变量控制发送速率：
TCP拥塞控制状态机：
┌──────────────┐ cwnd < ssthresh ┌──────────────────┐
│ 慢启动 │ ───────────────→ │ 慢启动 │
│ Slow Start │ 每收到1个ACK │ cwnd指数增长 │
│ │ cwnd += 1 MSS │ (每RTT翻倍) │
└──────┬───────┘ └──────┬───────────┘
│ cwnd >= ssthresh │ 超时丢包
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ 拥塞避免 │ 超时丢包 │ ssthresh=cwnd/2 │
│ Congestion │ ──────────→ │ cwnd = 1 MSS │
│ Avoidance │ │ 回到慢启动 │
│ 每RTT: cwnd += 1 │ └──────────────────┘
│ (线性增长) │
└──────┬───────────┘
│ 收到3个重复ACK
▼
┌──────────────────┐ ┌──────────────────┐
│ 快重传 │ ──→ │ 快恢复 │
│ Fast Retransmit │ │ Fast Recovery │
│ 立即重传丢失段 │ │ ssthresh=cwnd/2 │
│ 不等超时定时器 │ │ cwnd=ssthresh+3 │
└──────────────────┘ │ 收到重复ACK: │
│ cwnd += 1 │
│ 收到新ACK: │
│ cwnd=ssthresh │
│ 进入拥塞避免 │
└──────────────────┘
四个阶段详解： - 慢启动：连接初始 cwnd=1 MSS，每收到一个ACK cwnd += 1 MSS，由于一个RTT内收到cwnd个ACK，因此每RTT cwnd翻倍（指数增长），直到达到 ssthresh - 拥塞避免：cwnd >= ssthresh 后改为线性增长（每RTT加1 MSS），探测网络容量上限 - 快重传：收到3个重复ACK时立即重传（不等超时），判定为轻度丢包 - 快恢复（Reno算法）：快重传后 ssthresh = cwnd/2，cwnd = ssthresh + 3，跳过慢启动直接进入拥塞避免
💡 超时丢包 vs 3次重复ACK：超时表示严重拥塞（cwnd重置为1），3次重复ACK表示轻度拥塞（cwnd减半），这种区分使TCP对网络状态的响应更精确。
滑动窗口示例：
发送方：[已发送][已确认][窗口内可发送][不可发送]
↑ ↑ ↑
seq=0 seq=100 seq=200
接收方窗口大小：100字节
发送方一次性发送100字节，等待ACK
收到ACK=200后，窗口滑动，继续发送
实际应用场景： - 📧 邮件传输：使用SMTP（基于TCP），保证邮件不丢失 - 🌐 网页浏览：HTTP/1.1使用TCP，确保HTML、CSS、JS完整传输 - 📁 文件下载：FTP使用TCP，大文件分块传输，断点续传
3️⃣ UDP协议（User Datagram Protocol）¶
UDP是无连接的、不可靠的传输层协议，不保证数据到达，但速度快。
UDP vs TCP¶
| 特性 | TCP | UDP |
|---|---|---|
| 连接性 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠（重传、确认） | 不可靠（可能丢包） |
| 顺序 | 保证按序到达 | 不保证顺序 |
| 速度 | 较慢（头部20字节+开销） | 快（头部仅8字节） |
| 流量控制 | 有（滑动窗口） | 无 |
| 应用场景 | 文件传输、邮件、网页 | 直播、游戏、DNS |
UDP数据包格式¶
┌─────────┬─────────┬─────────────────────┐
│ 源端口 │ 目的端口│ 长度 │ 校验和 │
│ 2字节 │ 2字节 │ 2字节 │ 2字节 │
└─────────┴─────────┴─────────────────────┘
↓
应用数据
实际应用场景：
🎮 在线游戏： - 实时性要求高，丢几帧没关系 - 使用UDP，延迟低（<50ms） - 例如：王者荣耀、绝地求生
📺 视频直播： - 偶尔花屏可以接受，但卡顿不行 - 使用UDP，保证流畅 - 例如：抖音直播、B站直播
🔍 DNS查询： - 查询包很小，重传成本低 - 使用UDP，响应快 - 例如：nslookup www.baidu.com
代码示例：
import socket
# UDP客户端
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
client.sendto(b'Hello', ('127.0.0.1', 53)) # 不需要connect
data, addr = client.recvfrom(1024)
4️⃣ HTTP/HTTPS协议¶
HTTP是应用层协议，用于在客户端和服务器之间传输超文本数据。
HTTP请求流程¶
客户端 服务器
│ │
│ ─── DNS解析域名 ───────────────> │ www.baidu.com → 110.242.68.66
│ │
│ ─── TCP三次握手 ──────────────> │ 建立连接
│ │
│ ─── HTTP GET请求 ─────────────> │ GET / HTTP/1.1
│ │
│ <── HTTP响应 ────────────────── │ HTTP/1.1 200 OK
│ │
│ ─── TCP四次挥手 ──────────────> │ 关闭连接
│ │
HTTP请求示例¶
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive
HTTPS（HTTP + SSL/TLS）¶
HTTPS在HTTP基础上增加了加密层，保证数据传输安全：
HTTPS建立连接： 1. TCP三次握手 2. SSL/TLS握手（交换证书、协商加密算法） 3. 加密传输数据
实际场景： - 🔐 网上银行：必须使用HTTPS，保护账户安全 - 🛒 电商支付：支付宝、微信支付使用HTTPS - 🔑 登录接口：防止密码被窃取
🔌 端口的概念¶
什么是端口？¶
端口是传输层的概念，用于区分同一台主机上的不同进程。
类比： - IP地址 = 大楼地址（找到哪栋楼） - 端口 = 房间号（找到哪个房间）
常用端口号¶
| 端口号 | 协议 | 用途 | 实际场景 |
|---|---|---|---|
| 20/21 | FTP | 文件传输 | 上传下载文件 |
| 22 | SSH | 远程登录 | 服务器管理 |
| 23 | Telnet | 远程登录（不安全） | 旧设备管理 |
| 25 | SMTP | 发送邮件 | 邮件服务器 |
| 53 | DNS | 域名解析 | 将域名转为IP |
| 80 | HTTP | 网页浏览 | 访问网站 |
| 110 | POP3 | 接收邮件 | 邮件客户端 |
| 143 | IMAP | 接收邮件 | 邮件客户端 |
| 443 | HTTPS | 加密网页浏览 | 安全网站 |
| 3306 | MySQL | 数据库 | MySQL服务 |
| 5432 | PostgreSQL | 数据库 | PostgreSQL服务 |
| 6379 | Redis | 缓存数据库 | Redis服务 |
| 8080 | HTTP备用 | Web服务器 | 开发环境 |
端口范围¶
0 - 1023： 知名端口（Well-known Ports），需要管理员权限
1024 - 49151： 注册端口（Registered Ports）
49152 - 65535：动态端口（Dynamic Ports），临时使用
端口与进程的关系¶
一个进程可以监听多个端口，但一个端口同一时间只能被一个进程占用。
查看端口占用：
# Windows
netstat -ano | findstr :8080
# Linux/Mac
netstat -tulnp | grep :8080
# 或
ss -tulnp | grep :8080
实际场景：
# 启动一个Web服务器，监听8080端口
from http.server import HTTPServer, SimpleHTTPRequestHandler
server = HTTPServer(('0.0.0.0', 8080), SimpleHTTPRequestHandler)
print('Server running on port 8080...')
server.serve_forever()
# 访问：http://localhost:8080
🛠️ 实战练习¶
1️⃣ 使用ping命令测试网络连通性¶
ping命令使用ICMP协议，测试主机是否可达。
# 基本用法
ping www.baidu.com
# 输出示例：
# PING www.a.shifen.com (110.242.68.66): 56 data bytes
# 64 bytes from 110.242.68.66: icmp_seq=0 ttl=54 time=14.2 ms
# 64 bytes from 110.242.68.66: icmp_seq=1 ttl=54 time=13.8 ms
# 64 bytes from 110.242.68.66: icmp_seq=2 ttl=54 time=14.1 ms
# --- www.a.shifen.com ping statistics ---
# 3 packets transmitted, 3 packets received, 0.0% packet loss
# round-trip min/avg/max/stddev = 13.8/14.0/14.2/0.2 ms
参数说明： - icmp_seq：数据包序号 - ttl：生存时间（Time To Live），每经过一个路由器减1，防止无限循环 - time：往返时间（Round-Trip Time），越小越好
实用技巧：
# 只发送4个包（Windows默认）
ping -n 4 www.baidu.com
# 指定包大小
ping -s 1024 www.baidu.com
# 持续ping（Linux）
ping www.baidu.com
# 按Ctrl+C停止
2️⃣ 使用traceroute追踪路由¶
traceroute（Windows叫tracert）显示数据包经过的路由路径。
# Linux/Mac
traceroute www.baidu.com
# Windows
tracert www.baidu.com
# 输出示例：
# traceroute to www.baidu.com (110.242.68.66), 30 hops max, 60 byte packets
# 1 192.168.1.1 (192.168.1.1) 1.234 ms 0.987 ms 1.123 ms
# 2 10.0.0.1 (10.0.0.1) 5.432 ms 6.123 ms 5.876 ms
# 3 202.96.128.86 (202.96.128.86) 12.345 ms 11.234 ms 12.567 ms
# ...
# 10 110.242.68.66 (110.242.68.66) 14.123 ms 13.987 ms 14.234 ms
工作原理： 1. 发送TTL=1的数据包，第一个路由器返回超时 2. 发送TTL=2的数据包，第二个路由器返回超时 3. 依次增加TTL，直到到达目的地
实际应用： - 🔍 网络故障排查：发现哪个路由器出现问题 - 📊 性能分析：查看哪一跳延迟最高 - 🌍 了解网络拓扑：了解数据包的传输路径
3️⃣ 查看网络连接（netstat、ss）¶
netstat显示网络连接、路由表、接口统计等。
# 查看所有TCP连接
netstat -tuln
# 输出示例：
# Proto Recv-Q Send-Q Local Address Foreign Address State
# tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
# tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
# tcp 0 0 192.168.1.100:54321 110.242.68.66:443 ESTABLISHED
参数说明： - -t：TCP连接 - -u：UDP连接 - -l：监听状态的连接 - -n：显示数字地址（不解析域名） - -p：显示进程ID和名称（需要管理员权限）
常用命令：
# 查看所有监听端口
netstat -tuln
# 查看特定端口
netstat -tuln | grep :8080 # |管道：将前一命令的输出作为后一命令的输入
# 查看所有已建立的连接
netstat -tn | grep ESTABLISHED # grep文本搜索：按模式匹配行
# 查看进程占用的端口
netstat -tulnp | grep python
ss命令（更快，推荐使用）：
4️⃣ 抓包工具Wireshark入门¶
Wireshark是强大的网络协议分析工具，可以捕获和分析网络数据包。
安装Wireshark¶
# Ubuntu/Debian
sudo apt-get install wireshark
# macOS
brew install --cask wireshark
# Windows
# 从官网下载安装包：https://www.wireshark.org/download.html
基本使用¶
- 选择网卡：
-
启动Wireshark，选择要监听的网络接口（如eth0、Wi-Fi）
-
开始抓包：
-
点击"Start capturing packets"按钮（蓝色鲨鱼鳍图标）
-
应用过滤器：
Text Only# 只显示HTTP流量 http # 只显示特定IP的流量 ip.addr == 192.168.1.100 # 只显示TCP流量 tcp # 组合过滤 tcp.port == 8080 and ip.addr == 192.168.1.100 ``` 4. **分析数据包**： - 点击任意数据包，查看详细信息 - 可以看到每一层的数据（以太网帧、IP包、TCP段、HTTP请求） #### 实战：抓取HTTP请求 1. 启动Wireshark，选择网卡 2. 设置过滤器：`http` 3. 在浏览器访问：`http://www.baidu.com` 4. 在Wireshark中查看捕获的HTTP请求 **数据包详情**： ```yaml Frame 1: 686 bytes on wire Ethernet II, Src: aa:bb:cc:dd:ee:ff, Dst: 11:22:33:44:55:66 Internet Protocol Version 4, Src: 192.168.1.100, Dst: 110.242.68.66 Transmission Control Protocol, Src Port: 54321, Dst Port: 80, Seq: 1, Ack: 1 Hypertext Transfer Protocol GET / HTTP/1.1\r\n Host: www.baidu.com\r\n User-Agent: Mozilla/5.0 ...\r\n \r\n
实际应用： - 🐛 调试网络问题：查看请求是否发送成功 - 🔍 分析协议：学习协议的工作原理 - 🔐 安全审计：发现异常流量 - 📊 性能优化：分析网络延迟
❓ 常见问题¶
Q1：为什么需要三次握手？两次不行吗？¶
答案：三次握手是为了防止失效的连接请求突然传到服务器。
场景： 1. 客户端发送连接请求A，但网络拥塞，A延迟了 2. 客户端超时重发请求B，服务器收到B，建立连接 3. 连接完成后，断开连接 4. 此时，延迟的请求A到达服务器 5. 如果是两次握手，服务器误以为客户端要建立新连接 6. 服务器分配资源，但客户端已经关闭，造成资源浪费
三次握手的好处： - 服务器收到请求A，回复SYN+ACK - 客户端发现这不是自己期望的连接，发送RST（复位） - 连接未建立，资源未浪费
Q2：TCP和UDP的区别及使用场景？¶
| 特性 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠（重传、确认） | 不可靠（可能丢包） |
| 顺序 | 保证按序到达 | 不保证顺序 |
| 速度 | 较慢 | 快 |
| 头部开销 | 20字节 | 8字节 |
| 流量控制 | 有（滑动窗口） | 无 |
| 适用场景 | 文件传输、邮件、网页 | 直播、游戏、DNS |
使用场景对比：
✅ 使用TCP的场景： - 📁 文件传输：FTP、SFTP（不能丢数据） - 📧 邮件：SMTP、POP3、IMAP（邮件不能丢） - 🌐 网页浏览：HTTP/HTTPS（HTML、CSS、JS必须完整） - 💾 数据库：MySQL、PostgreSQL（数据一致性） - 📡 SSH远程登录：命令不能丢
✅ 使用UDP的场景： - 🎮 在线游戏：实时性要求高，丢几帧没关系 - 📺 视频直播：偶尔花屏可以接受，但卡顿不行 - 🔍 DNS查询：查询包小，重传成本低 - 📡 VoIP语音通话：延迟比可靠性更重要 - 📊 物联网传感器：数据量大，允许部分丢失
代码选择：
# 需要可靠传输 → TCP
socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 需要快速传输 → UDP
socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
Q3：什么是MTU？为什么重要？¶
MTU（Maximum Transmission Unit）是最大传输单元，指数据链路层能传输的最大数据包大小。
常见MTU值： - 以太网：1500字节 - PPPoE：1492字节 - Wi-Fi：通常1500字节
MTU组成：
MTU过大的问题： - 数据包超过MTU会被分片（Fragmentation） - 分片会增加延迟，降低性能 - 任何一片丢失，整个数据包都要重传
MTU过小的问题： - 数据包数量增加，头部开销增大 - 降低网络利用率
实际场景：
# 查看MTU
ifconfig eth0
# 或
ip link show eth0
# 输出示例：
# eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT
# 修改MTU（需要管理员权限）
sudo ifconfig eth0 mtu 1400
# 或
sudo ip link set eth0 mtu 1400
MTU与TCP MSS的关系： - MSS（Maximum Segment Size）是TCP层的最大段大小 - MSS = MTU - IP头部(20) - TCP头部(20) = 1460
实际应用： - 🌐 VPN：VPN会增加头部，需要降低MTU - 📡 卫星网络：延迟高，MTU通常较小 - 🔧 网络优化：调整MTU可以提升性能
📝 总结¶
核心知识点回顾¶
- OSI七层模型：理论参考模型，理解网络分层思想
- TCP/IP四层模型：实际互联网使用的模型
- 关键协议：
- IP：寻址和路由
- TCP：可靠传输（三次握手、四次挥手）
- UDP：快速传输（不可靠）
- HTTP/HTTPS：应用层协议
- 端口：区分同一主机上的不同进程
- 实战工具：ping、traceroute、netstat、Wireshark
学习建议¶
📚 循序渐进： 1. 先理解分层模型的思想 2. 掌握TCP和UDP的区别 3. 学会使用常用命令排查问题 4. 用Wireshark抓包，加深理解
🛠️ 动手实践： - 用ping测试网络连通性 - 用traceroute查看路由路径 - 用netstat查看端口占用 - 用Wireshark抓包分析HTTP请求
📖 进阶学习： - HTTP/2、HTTP/3（QUIC） - WebSocket协议 - 网络安全（SSL/TLS、防火墙） - 网络编程（Socket编程）
推荐资源¶
📖 书籍： - 《计算机网络：自顶向下方法》 - 《TCP/IP详解 卷1：协议》
🌐 在线资源： - Wireshark官方教程 - MDN Web Docs - HTTP — Mozilla权威网络协议参考
🎯 练习网站： - Packet Tracer：网络模拟器 - GNS3：网络仿真平台
记住：网络知识是程序员必备技能，掌握基础能让你在面试和工作中更加从容！🚀