一、常见协议头分析
1.1 TCP首部
| 字段 | 作用 |
|---|---|
| 源端口 | 发送端应用程序的端口号，用于接收方回传数据时定位发送方进程 |
| 目的端口 | 接收端应用程序的端口号，用于定位数据要交给哪个进程 |
| 序号 | 标识发送数据的字节流编号，用于数据重组、确认和重传 |
| 确认号 | 期望收到的下一个字节序号，表示之前的数据已成功接收 |
| 源IP地址 | 发送端的IP地址，在网络层标识数据包来源 |
| 数据偏移 | 表示TCP首部的长度（以4字节为单位），用于定位数据部分的起始位置 |
| 保留 | 预留字段，供未来使用，目前必须置为0 |
| URG | 紧急指针标志位，为1时表示紧急指针有效 |
| ACK | 确认标志位，为1时确认号字段有效（连接建立后必须为1） |
| PSH | 推送标志位，为1时要求接收方尽快将数据交给应用层 |
| RST | 复位标志位，为1时表示连接出现异常，强制断开 |
| SYN | 同步标志位，为1时表示请求建立连接（三次握手中的同步序号） |
| FIN | 结束标志位，为1时表示发送方数据已发送完毕，请求断开连接 |
| 窗口 | 告知对方自己的接收缓冲区剩余大小，用于流量控制，防止发送方发送过快 |
| 校验和 | 对整个TCP报文段（首部+数据）进行校验，检测传输错误 |
| 紧急指针 | 指向紧急数据的末尾位置（与序号字段配合使用），仅在URG=1时有效 |
| 选项 | 可选字段，如最大报文段长度（MSS）、窗口扩大因子、时间戳等 |
| 填充 | 用于保证TCP首部是4字节的整数倍（数据偏移字段的单位） |
| TCP数据部分 | 上层应用协议（如HTTP、FTP）的实际数据内容 |
1.2 IP首部
| 字段 | 长度 | 功能 |
|---|---|---|
| 版本号 | 4bit | 标识 IP 版本（IPv4=4，IPv6=6） |
| 首部长度 | 4bit | IP 头部的长度（单位：4字节，最小5=20字节，最大15=60字节） |
| 服务类型（TOS） | 8bit |
定义优先级、延迟、吞吐量；现用于区分服务（DSCP） 标记流量类别（如视频、语音优先级） |
| 总长度 | 16bit |
整个 IP 数据包总长度（头部+数据），最大 65535 字节 超过MTU时需要分片 |
| 标识 | 16bit |
唯一标识一个数据包，同一数据包的不同分片共享相同标识 便于重组 |
| 标志 | 3bit |
第一位保留为0； 第二位禁止分片（1=不分片，超过MTU则丢弃）； 第三位更多分片（1=后续还有分片，0=最后一个分片） |
| 片偏移 | 13bit | 指示当前分片在原始数据包中的位置（单位：8字节） |
| 生存时间（TTL） | 8bit |
防止数据包无限循环，每经过一个路由器减1 TTL=0时丢弃并发送 ICMP 超时消息 |
| 协议 | 8bit | 标识上层协议：6=TCP，17=UDP，1=ICMP |
| 首部检验和 | 16bit | 仅校验头部数据完整性，不包括数据部分 |
| 源IP地址 | 32bit | 发送方的 IPv4 地址 |
| 目的IP地址 | 32bit | 接收方的 IPv4 地址 |
| 选项字段 |
可变（最多40字节） | 扩展功能（如记录路由、时间戳），较少使用 |
| 填充 | 可变 | 确保头部长度为4字节的整数倍 |
| 数据 | 可变 | 上层协议数据（TCP段、UDP数据报等） |
版本号到目的IP地址总共占20字节
IP分片的原因：当IP数据报的大小超过网络链路所允许的MTU（最大传输单元）时，数据报会被拆分成多个较小的片段进行传输，接收端再重新组装。这是为了适应底层网络的物理限制，而不是为了提高效率（实际上分片会降低效率）
IP数据报的分片和重组都是由网络层（IP协议）完成的，发送端分片，接收端组装完成后才交给传输层。
| 位置 | 分片 | 重组 |
|---|---|---|
| 源主机 | ✅ 需要时进行分片 | ❌ 不重组 |
| 中间路由器 | ✅ 如果需要（收到大于出接口 MTU 的数据报）可再次分片 | ❌ 不重组（只转发分片） |
| 目标主机 | ❌ 不分片 | ✅ 负责重组所有分片 |
| 原因 | 说明 |
|---|---|
| 降低路由器负担 | 路由器只负责快速转发，不处理复杂的重组逻辑 |
| 分片可能走不同路径 | 同一数据报的不同分片可能经过不同路由器到达目标，中间路由器无法收到全部分片 |
| 端到端原则 | 复杂功能放在边缘（主机），核心（路由器）保持简单 |
1.3 TCP/IP协议数据封装过程
| 层级 | 数据单元 | 作用 |
|---|---|---|
| 应用层 | 用户数据 | 应用程序实际要发送的原始数据（如 HTTP 请求、文件内容等） |
| 应用层 | Appl首部 | 应用层协议添加的头部信息（如 HTTP 头、FTP 命令等），用于应用层解析 |
| 传输层 | TCP段 | 将应用数据加上 TCP 首部封装成段，负责端到端的可靠传输、流量控制、顺序保证 |
| 传输层 | TCP首部 | 包含源端口、目的端口、序号、确认号、标志位等，用于建立连接、确认、重传等机制 |
| 网络层 | IP数据报 | 将 TCP 段加上 IP 首部封装成数据报，负责跨网络的寻址和路由转发 |
| 网络层 | IP首部 | 包含源 IP、目的 IP、TTL、协议类型等，用于网络层路由选择和数据报转发 |
| 数据链路层 | 以太网帧 | 将 IP 数据报加上以太网首部和尾部封装成帧，负责同一网络内的物理传输 |
| 数据链路层 | 以太网首部 | 包含目的 MAC 地址、源 MAC 地址、帧类型等，用于局域网内标识设备 |
| 数据链路层 | 以太网尾部 | 通常包含帧校验序列（FCS），用于检测数据在传输过程中是否出错 |
二、wireshark抓包工具
| 项目 | 内容 |
|---|---|
| 解析数据包的作用 | 将网络中抓取的二进制原始数据包，按照 TCP/IP 协议栈逐层拆解，还原成人类可读的协议字段（如源IP、目的端口、标志位等），帮助分析网络通信细节。 |
| 常见使用场景 | ① 网络故障排查（如连接失败、丢包、延迟高） ② 协议分析与学习（观察 TCP 三次握手、HTTP 请求响应过程） ③ 网络安全分析（检测异常流量、恶意攻击、数据泄露） ④ 应用性能调试（分析 API 响应慢、重传过多等问题） ⑤ 开发调试网络程序（验证自己写的 socket 程序收发数据是否正确） |
| 一句话总结 | Wireshark 解析包就是把网络上的“天书”翻译成“人话”，用于排查网络问题、学习协议和调试程序。 |
win连接的是WLAN，linux是Loopback
三、TCP粘包问题及解决方案
3.1 粘包介绍
| 类型 | 现象 | 原因 |
|---|---|---|
| 正常包 | 发送一次，接收端一次收到完整的一条消息 | 数据大小合适，发送和接收时机匹配 |
| 粘包 | 发送多次，接收端一次收到了多条消息粘在一起 | 发送端多次小数据发送，接收缓冲区积累后一次性读取；或 Nagle 算法合并小包 |
| 拆包 | 发送一次，接收端分多次才收到完整消息 | 发送的数据大于接收缓冲区大小；或 TCP 分段传输（MSS 限制） |
3.2 TCP粘包问题原因
| 分类 | 具体原因 | 说明 |
|---|---|---|
| TCP协议特性 | 面向字节流 |
TCP 没有消息边界，数据像流水一样传输，不保留发送时的消息分隔 (根本原因) |
| 缓冲区机制 | 发送方和接收方都有缓冲区，数据在缓冲区中积累，可能导致多条消息合并或拆分 | |
| 发送方行为 | 数据写入方式 | 多次小数据写入，可能被合并成一个 TCP 段发送 |
| Nagle 算法 | 为减少小包数量，延迟发送并合并多个小数据包（默认开启） | |
| 接收方行为 | 读取粒度 | 应用程序一次 recv 读取的数据长度可能与发送长度不一致，可能读多或读少 |
| 缓冲区读取 | 接收缓冲区有数据时，应用程序可能一次读完所有积压的数据，导致粘包 | |
| 网络传输因素 | 分片与重组 | IP 层可能对大数据包分片传输，接收端再重组，导致应用层看到的数据边界变化 |
| MTU/MSS 限制 | 当发送数据超过 MSS，TCP 会自动分段，导致一条消息被拆成多个包发送 |
3.3 MTU与MSS
| 对比项 | MTU | MSS |
|---|---|---|
| 定义 |
网络接口层所能传输的最大数据包大小 （包含 IP 首部 + TCP 首部 + 数据） |
TCP 数据段中数据部分的最大大小 （不含 TCP 首部和 IP 首部） |
| 所在层级 | 网络接口层 / IP 层 | 传输层（TCP） |
| 典型值 | 以太网中通常为 1500 字节 | 通常为 1460 字节（1500 - 20 IP首部 - 20 TCP首部） |
| 计算关系 | MSS = MTU - IP首部大小 - TCP首部大小 | |
| 作用 | 限制单个网络帧能携带的总数据量 | 限制 TCP 段中数据部分的最大大小 |
| 双方协商 | 由网络链路决定，通常无需协商 | TCP 三次握手时双方协商，取较小值 |
| 超出后果 | 需要 IP 分片，降低传输效率 | 超出 MSS 的数据会被 TCP 分段 |
3.4 解决办法
| 方法 | 定义方式 | 实现原理 |
|---|---|---|
| 1. 固定长度法 | 每个消息的字节长度固定（如 128 字节） | 发送端每次发送固定大小数据，接收端每次读取固定大小；不足时用 \0 或空格填充补位 |
| 2. 分隔符法 | 在每个消息末尾添加特定分隔符（如 \n 或 \r\n） | 发送端在消息结尾加分隔符，接收端逐个字节读取，遇到分隔符则认为一条消息结束 |
| 3. 头部声明长度法 | 消息头部固定字节（通常 4 字节）存储消息体的长度 | 发送端先发送 4 字节长度值（网络字节序），再发送消息体；接收端先读 4 字节获取长度，再按长度读取消息体 |
| 方法 | 优点 | 缺点 |
|---|---|---|
| 固定长度法 | 实现简单，效率高 | 浪费空间（短消息填充多余字节），灵活性差 |
| 分隔符法 | 灵活，节省空间 | 需要遍历查找分隔符，效率较低；消息内部不能出现分隔符（需转义） |
| 头部声明长度法 | 灵活、高效、无空间浪费 | 实现稍复杂，需处理字节序和粘包问题 |
四、TFTP协议
4.1 TFTP协议格式
文本传输协议；用于网络设备配置；固件升级
基于UDP使用的
以块（512字节）为单位传输的，直到最后的组小于512
| 项目 | 说明 |
|---|---|
| netstat 模式 | 将数据看成由 ASCII 码字符串组成的行，以换行符（\n）作为行结束符 |
| octet 模式 | 将数据看成 8 比特为一组的字节流（原始二进制数据） |
| 块编号 | 用于确认数据分组，通过 DATA 数据包和 ACK 包的块编号来确认数据接收，从 0 开始编号 |
4.2 TFTP通讯流程
采用请求与响应的模式
9895
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
