一、网络模型（OSI vs TCP/IP）
1. OSI七层模型
- 应用层（HTTP、FTP、SMTP）
- 表示层（数据格式转换、加密/解密）
- 会话层（建立、管理、终止会话）
- 传输层（TCP、UDP）
- 网络层（IP、ICMP、IGMP、ARP）
- 数据链路层（MAC地址、交换机）
- 物理层（网线、光纤、无线信号）
2. TCP/IP四层模型
- 应用层（HTTP、FTP、DNS）
- 传输层（TCP、UDP）
- 网络层（IP、ICMP、IGMP）
- 网络接口层（ARP、RARP、MAC）
关系：
- OSI 是理论模型，TCP/IP 是实际使用的协议栈。
- 程序员重点关注：应用层（HTTP） 和 传输层（TCP/UDP）。
二、TCP协议
1. TCP特点
- 面向连接（需三次握手建立连接）
- 可靠传输（确认应答、超时重传、滑动窗口）
- 全双工通信（双方可同时收发数据）
- 流量控制（滑动窗口）
- 拥塞控制（慢启动、拥塞避免、快重传）
2. TCP三次握手（建立连接）
- Client → Server：
SYN=1, seq=x（Client进入SYN_SENT） - Server → Client：
SYN=1, ACK=1, seq=y, ack=x+1（Server进入SYN_RCVD） - Client → Server：
ACK=1, ack=y+1（双方进入ESTABLISHED）
为什么需要三次？
- 确保双方发送和接收能力正常，防止历史连接干扰。
3. TCP四次挥手（断开连接）
- Client → Server：
FIN=1, seq=u（Client进入FIN_WAIT_1） - Server → Client：
ACK=1, ack=u+1（Server进入CLOSE_WAIT，Client进入FIN_WAIT_2） - Server → Client：
FIN=1, seq=v, ACK=1, ack=u+1（Server进入LAST_ACK） - Client → Server：
ACK=1, ack=v+1（Server关闭，Client进入TIME_WAIT后关闭）
为什么需要四次？
- TCP是全双工的，必须分别关闭发送和接收通道。
TIME_WAIT的作用：确保最后一个ACK到达，防止旧数据干扰新连接。
4. TCP的可靠性机制
| 机制 | 作用 |
|---|---|
| 确认应答（ACK） | 接收方确认收到数据 |
| 超时重传 | 未收到ACK时重发数据 |
| 滑动窗口 | 动态调整发送速率，避免接收方缓冲区溢出 |
| 流量控制 | 通过窗口大小限制发送速率 |
| 拥塞控制 | 避免网络拥塞（慢启动、拥塞避免、快重传） |
三、UDP协议
1. UDP特点
- 无连接（无需握手，直接发送）
- 不可靠（不保证数据到达）
- 高效（无确认、无重传、无流量控制）
- 面向报文（数据包边界清晰，不会粘包）
2. UDP适用场景
- 实时性要求高（视频通话、直播）
- 允许少量丢包（DNS查询、游戏数据）
- 广播/组播（如DHCP）
3. UDP报文结构
| 源端口（2字节） | 目的端口（2字节） |
| 长度（2字节） | 校验和（2字节） |
| 数据（可变长度） |
四、HTTP协议
1. HTTP特点
- 无状态（每次请求独立，需Cookie/Session维持状态）
- 基于TCP（默认端口80）
- 请求-响应模型（Client发起请求，Server返回响应）
2. HTTP报文结构
请求报文
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Chrome
Accept: text/html
- 请求行：
方法（GET/POST） + URI + HTTP版本 - 请求头：
Host, User-Agent, Accept - 请求体（POST请求携带数据）
响应报文
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<html>...</html>
- 状态行：
HTTP版本 + 状态码（200/404） + 状态描述 - 响应头：
Content-Type, Content-Length - 响应体（HTML/JSON数据）
3. HTTP方法
| 方法 | 作用 |
|---|---|
| GET | 获取资源 |
| POST | 提交数据 |
| PUT | 更新资源 |
| DELETE | 删除资源 |
| HEAD | 获取响应头（无Body） |
4. HTTP状态码
| 状态码 | 含义 |
|---|---|
| 200 | 成功 |
| 301/302 | 重定向 |
| 400 | 客户端错误 |
| 403 | 无权限 |
| 404 | 资源不存在 |
| 500 | 服务器错误 |
五、关键协议对比
| 协议 | 连接方式 | 可靠性 | 效率 | 适用场景 |
|---|---|---|---|---|
| TCP | 面向连接 | 可靠 | 较低 | 文件传输、Web请求 |
| UDP | 无连接 | 不可靠 | 高 | 视频流、游戏、DNS |
| HTTP | 基于TCP | 依赖TCP | 中等 | Web应用 |
六、常见问题
1. TCP粘包问题
- 原因：TCP是流式传输，无边界，多个数据包可能合并。
- 解决方案：
- 固定长度（如每个包100字节）
- 分隔符（如
\n） - 自定义协议（如
[长度][数据]）
2. TCP vs UDP如何选择？
- 用TCP：需要可靠传输（如文件下载、HTTP请求）。
- 用UDP：需要低延迟（如视频通话、游戏）。
七、TCP三次握手的漏洞与防御措施
1. SYN洪泛攻击（SYN Flood）
攻击原理：
- 攻击者伪造大量虚假IP，向目标服务器发送
SYN包（第一次握手）。 - 服务器响应
SYN-ACK（第二次握手），但伪造的IP不会回复ACK（第三次握手）。 - 服务器维护半连接队列（SYN_RCVD状态），等待超时（默认30秒~2分钟），导致队列耗尽，无法处理正常请求。
影响：
- 服务器资源（内存、CPU）被占满，拒绝服务（DoS/DDoS）。
防御方案：
| 方法 | 说明 |
|---|---|
| SYN Cookie | 服务器不保存半连接状态，而是通过哈希计算验证ACK合法性。 |
| 缩短超时时间 | 减少半连接队列的等待时间（如从2分钟降至10秒）。 |
| 防火墙/IP限流 | 过滤高频SYN请求，或限制单个IP的连接数。 |
| TCP代理（如Cloudflare） | 在边缘节点完成握手，过滤恶意流量。 |
2. 伪造初始序列号（ISN）攻击
攻击原理：
- TCP依赖**序列号（ISN）**确保数据顺序，早期实现中ISN可预测。
- 攻击者预测ISN，伪造合法用户的
ACK包，劫持会话（Session Hijacking）。
防御方案：
- 使用随机化ISN（现代操作系统已实现）。
3. Land攻击（自攻自防）
攻击原理：
- 攻击者发送
SYN包，源IP和目的IP均为目标服务器。 - 服务器向自己发送
SYN-ACK，陷入死循环，消耗资源。
防御方案：
- 防火墙过滤源IP=目标IP的包。
4. 半开放连接耗尽（半连接队列溢出）
攻击原理：
- 类似SYN洪泛，但攻击者部分完成握手（发送
ACK但不发送数据），占用服务器连接资源。
防御方案：
- 启用TCP Fast Open（TFO）：允许在SYN包中携带数据，减少握手延迟。
- 限制单个IP的最大半连接数。
5. 总结
| 漏洞类型 | 关键点 | 防御措施 |
|---|---|---|
| SYN洪泛 | 伪造IP耗尽半连接队列 | SYN Cookie、IP限流 |
| ISN预测 | 序列号可预测导致会话劫持 | 随机化ISN |
| Land攻击 | 源IP=目标IP的自攻 | 防火墙过滤 |
| 半开放连接 | 占用连接但不传输数据 | TFO、连接数限制 |
实际应用建议：
- 服务器配置：启用
SYN Cookie，调整net.ipv4.tcp_max_syn_backlog（半连接队列大小）。 - 网络层防护：部署DDoS防护设备（如AWS Shield、阿里云Anti-DDoS）。
扩展思考：
- 为什么QUIC（HTTP/3）选择UDP+加密？避免TCP握手漏洞，同时提供可靠性。
全文总结
- TCP：可靠、面向连接，适合文件传输、Web请求。
- UDP：高效、无连接，适合实时应用（视频、游戏）。
- HTTP：基于TCP，无状态，是Web开发的基础。
- 关键机制：三次握手、四次挥手、滑动窗口、ACK确认。
后续学习建议：
- 深入 Socket编程（TCP/UDP实战）
- 研究 HTTP/2、WebSocket（现代Web通信）
- 理解 DNS、HTTPS、WebRTC（扩展协议）
扫一扫
2024
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
