开篇¶
OSI & TCP/IP 模型¶
| 对比维度 | OSI模型 | TCP/IP 模型 | |
|---|---|---|---|
| 设计目标 | 标准化理论，理论协议为主 | 互联网的核心架构基础 | |
| 分层复杂度 | 7层，严格隔离 | 5层，简化并合并了高层功能 | |
| 现实影响力 | 教学和理论的分析工具，应用较少 | 实际工程实现 | |
| 分析视角 | 数据从应用层逐层封装，经过表示层加密、会话层建立连接，最终通过物理层传输 | 数据在应用层打包后，直接通过传输层（TCP/UDP）添加端口号，网络层（IP）添加IP地址，最后由数据链路层和物理层发送。 | |
| 具体分层上的区别 | |||
| 应用层 | 应用层 | OSI的应用层仅定义接口（即直接对外提供网络服务），而 TCP/IP 的应用层关注底层的协议转换，如 HTTP、 FTP 、 DNS 、 SMTF | |
| 表示层 | （合并至应用层） | OSI 独有的层，关注数据格式转换（如加密、转换、编码） | |
| 会话层 | （合并至应用层） | OSI 独有的层，OSI管理会话的建立/终止（RPC 协议），TCP/IP 将会话管理交给应用层自行处理 | |
| 传输层 | （合并至应用层） | 两者功能一直，负责端到端之间的传输，TCP（可靠传输）、 UDP（不可靠传输） | |
| 网络层 | 网络层 | 负责寻址和路由（IP 协议），如路由器、 ARP 、防火墙等 | |
| 数据链路层 | 数据链路层 | 负责相邻节点之间的帧传输（MAC 地址、以太网协议），如网卡、网桥、交换机（解析 MAC 地址，转发数据帧） | |
| 物理层 | 物理层 | 定义物理介质的特性，如集线器（广播物理信号）、中继器（放大物理信号） |
老生常谈 Tcp¶
Tcp 三次🤝？¶
tcp的三次握手是建立可靠网络连接的核心机制，确保通讯双方能够同步初始序列号并确认彼此的发送和接受能力。
流程如下：
TCP 四次👋¶
通过四次挥手，TCP 实现可靠的双向连接关闭，确保数据传输的完整性和资源的完整释放。 TCP 是全双工协议，双方可独立发送和接收数据。关闭连接时，需确保双方的数据均已传输完毕，且双向通道均安全释放，四次👋来保障这一点。
客户端 FIN：代表不再继续发送数据，但仍可接收数据。 服务端 FIN：代表已无要传输的数据，告知客户端可关闭通道，等待最终ACK 。
流程如下：
TIME_WAIT 的 2MSL等待： - 目的：确保最后一个 ACK 能被服务端重传的 FIN 正确处理（若 ACK 丢失，服务端 TCP 重传机制会重发 FIN） - 时长：通常为 2 倍报文最大生存时间（MSL）
关键点总结：
| 阶段 | 客户端行为 | 服务端行为 |
|---|---|---|
| ACK 丢失 | 出于 TIME_WAIT 状态，等待 2MSL | 未收到 ACK，出发超市重传 FIN |
| 收到重传的 FIN | 立刻回复 ACK，并重置 2MSL 计时器 | 收到 ACK后关闭连接 |
| 2MSL超时 | 关闭连接 | 若始终未接收到 ACK，达到最大重传次数后强制会强制关闭 |
不妨思考下¶
三次🤝真的是必须的么？¶
1 、防止历史🔗的建立 - 若网络中存在客户端延迟的旧 SYN 请求（如客户端重连后），三次握手能确保客户端在第三次握手时拒绝过期的连接请求，避免服务端资源浪费。
2 、同步双方的初始序列编号 - 序列号用于标识数据字节流，确保数据按需传输、完整性以及去重校验，三次握手确保双方交换并确认初始序列号。
3 、验证双向通信能力 - 三次握手验证通信双方均具备首发能力。
为什么需要四次挥手？¶
1 、双向通道独立关闭 - TCP 是全双工协议，客户端和服务端需分别关闭自己的独立通道。 - 客户端发送 FIN仅表示不再发送数据，但仍可接收数据；服务端需在发送剩余数据后再发送 FIN。 2 、确保数据完整性 - 第二次挥手的 ACK 确保客户端知道服务端已接收到关闭请求。 - 第四次挥手的 ACK 确保服务端知道客户端已确认关闭。
延伸问题¶
能否用两次握手替代？¶
两次握手并不能防止旧的 SYN 导致的连接错误，并且服务端不知晓客户端是否能接收到自己的 SYN-ACK信号。
初始序列编号为什么随机？¶
防止网络攻击（猜测序列号并伪造数据包），同时避免不同连接的序列号冲突。
SYN Flood 洪泛攻击？¶
攻击者发送大量 SYN 后不回复 ACK，导致服务器半开连接耗尽资源。常见的防御措施包限制半连接数以及 SYN Cookies。
SYN Cookies 是一种防御 SYN 洪泛攻击的技术，其基于无状态的方式来去验证 TCP 链接请求，避免服务端因维护大量半开连接（Half-Open Connection）耗尽资源。
SYN Flood 背后原理 在 TCP 的三次握手中，服务端在接收到客户端 SYN 包后，会分配内存保存连接的初始状态（如序列号、端口等），并进入 SYN_RECEIVED 状态等待客户端的 ACK 。 攻击者通过伪造大量虚假的 SYN 请求（不发送最终的 ACK）， 导致服务器内存被占满，无法处理合法请求，最终服务瘫痪。
核心思想： SYN Cookies 通过不保存连接状态的方式解决这一问题： 1 、无状态连接：服务器不存储半开连接的信息，而是通过加密哈希算法将连接信息编码到 SYN-ACK 包的初始序列号（基于无状态的方式）中。
2 、对客户端验证：只有当客户端返回合法的 ACK 包（携带正确确认号 ack = seq + 1），服务器才会分配资源建立连接。
通过 SYN Cookies，服务器在保障安全的同时，维持了对安全请求的高效处理能力。