以太网短报文为什么也要填充？最小帧、Padding与抓包长度科普

01先分清消息、IP包和以太网帧

应用程序关心的是状态、命令或测量值，网络传输却需要加上沿途设备能识别的信息。把业务消息想成一张便条，IP包像装便条的信封，以太网帧则像本段运输使用的外包装。类比只帮助分层，不表示真的存在三只物理盒子；线上传输的仍是一串连续比特。

在本文采用的未带VLAN标签的普通以太网示例中，MAC帧从目的地址开始，到帧校验序列FCS结束。MAC地址是本段链路识别收发对象的地址；FCS是接收方用于检查帧内容是否发生传输错误的校验值。前导码在帧前帮助接收，帧间隔是两次发送之间的空闲，都不算进这里的64字节。

以太网的最小帧要求说的是外层MAC帧，并不是要求每条PLC指令都写满64字节。读产品资料或抓包记录时，先问“这个长度从哪里数到哪里”。如果把应用数据、帧头或FCS混着数，就会把正常封装误认为多发了业务内容。

02短了怎么办：在尾部补齐，再形成校验

当上层交给发送端的数据太短时，以太网发送处理会在数据后面追加填充，英文叫Padding。它位于上层数据之后、FCS之前。可以把它理解为为了满足外包装规格而加的衬垫：衬垫占位置，却不是便条上新写的字。具体由哪个软硬件环节完成，要看网卡、驱动或嵌入式设备的实现。

举一个边界清楚的例子：未带标签的以太网帧，帧头14字节，承载一个28字节的IPv4包。这个IP包可以由普通IPv4头和UDP头构成，不再带UDP应用数据。发送时补18字节填充，再加4字节FCS，形成64字节MAC帧。这是说明结构的示例，不是某台飞畅设备的实测数据。

填充也在以太网校验所覆盖的内容里，不能在形成FCS之后随意改动。接收端校验的是收到的这一帧，而不是仅仅检查业务消息。这里无需手算CRC公式，记住先形成符合要求的帧内容，再配套生成校验，就能理解为什么填充区也不能被任意修改。

03补齐的字节，为什么不该当成新业务

对于IPv4，IP头里的总长度告诉接收方这个IP包有多长，包含IP头和IP数据，不包含外层以太网填充。接收方把属于IP包的部分交给上层，再由相应协议继续解释。RFC 894明确区分了填充与IP包，规定所述封装需要补齐时用零字节填充。

因此，写上层解析程序时不能把“捕获到的以太网帧剩余多少字节”直接当成业务消息长度。程序应检查本协议的长度字段及边界，不把外层衬垫附到命令末尾。反过来，也不能简单把所有结尾的零都删掉：零可能恰好是合法数据，判断依据应是协议，而不是字节看起来像不像空白。

其他二层协议需要依据自己的封装说明确定有效数据范围，不能把IPv4总长度的做法机械套过去。填充字节也不应该承载私有控制命令或未经初始化的内存内容。对用户而言，最实用的习惯是分开核对外层帧边界与内层消息边界。

04为什么软件会显示60字节，甚至更少

抓包工具并不一定看到线缆上的完整原貌。许多网卡在接收时检查FCS，却不把这4字节交给操作系统；软件得到的记录因此可能是60字节，线上对应的却是完整64字节MAC帧。Wireshark官方资料提醒了这一点，所以“显示60”本身不能证明网络传输了欠长帧。

发送侧还有另一种观察位置：软件可能在网卡完成填充和校验之前抓到数据。此时记录可以比60字节更短，但硬件随后仍可能补齐再发送。发送端屏幕、接收端屏幕与线上的观察点不是同一位置，不能只对照两个长度数字，就断言中间设备删除了内容。

还要区分原始长度和捕获长度。采集程序可能只保存每帧的前一部分，界面上显示的字节不一定全部被保存。先看捕获设置、是否交付FCS、抓包方向和网卡卸载方式，再结合对端记录判断。需要证明物理线上帧形态时，使用能说明采集条件的合适测试方法。

05VLAN与转发：不要套一个固定补齐数

前面的18字节填充只属于给定示例，并不是所有工业报文都固定补18字节。原始数据长短不同、是否有标签、接口如何处理封装，都会改变需要补齐的部分。VLAN标签位于帧头区域，不能在已经含标签的长度上再重复加一次，也不能把最小帧和最大传输单元MTU混为一谈。

交换机收帧、识别转发对象，并在输出链路形成相应帧。涉及标签增删的设备，需要保持输出帧符合该链路的要求。Cisco关于特定平台的排障资料展示了移除标签后需要重新补齐的情形；这是帮助理解处理边界的案例，不能据此宣称所有交换机都使用同一内部流程。

对于完整的短报文，正常填充不是故障；真正欠长、线路损坏产生的异常，或采集时被截短的记录，则要分别分析。端口错误计数的名称和统计条件也有设备差异。把设备计数与抓包时间、方向对应起来，比看到“短”字就立即换交换机更可靠。

06放进真实工业交换机场景怎样理解

飞畅官网mini工业轨式5路百兆电交换机列有五路以太网电接口与10/100M自适应等说明，可作为PLC、HMI等设备接入场景的产品依据。本文借此解释普通以太网封装，不给它补写未核实的抓包、端口镜像、特殊填充控制或检测门限功能。所选配置仍应查具体资料。

例如一个终端不断发送很短的状态，另一个终端同时传送较长文件，不能仅用应用字节数评价端口负载。每帧还要占用封装和发送间隔等资源，小报文多了也会消耗处理与传输机会。这不需要先算复杂公式；先同时记录每秒帧数、实际流量和业务周期，更容易看出负载特征。

若透明传输的业务出现尾部多余字节，优先确认应用协议边界与解析程序，再查看源端、转换设备和目的端各自看到的内容。不要直接把Padding当成串口消息的一部分，也不要为“消除填充”随意改变网络设备工作方式。先确认问题发生在哪一层。

07现场检查按三个问题逐步收敛

第一，记录自己看见的是哪个观察点：源端发送前、对端接收后，还是交换机提供的观察副本。第二，记录长度口径：包含哪些头部、有没有FCS、保存的是否是完整帧。第三，把同一业务的协议长度、载荷和错误计数对应起来，避免只截取一张“60字节”的截图下结论。

需要对比时，在独立测试环境或批准的维护窗口使用已知的短报文，保存两端原始抓包及采集参数。确认应用确实只取有效数据，普通通信也能持续完成。测试只验证当时的配置和路径，不把一个工具的显示方式推广为所有网卡和交换机的共同特性。

最后再看异常是否随着端口、线缆或采集方式改变。保留原始证据，避免只保留解释后的截图。短报文填充的核心很简单：外层帧有自己的最小规格，内层业务有自己的长度边界，而抓包软件看到的是某个环节的记录。这三件事分开，才能判断哪里真的出了问题。

资料与产品依据

Wireshark：Ethernet；IETF RFC 894，1984年4月；Cisco填充处理排障资料，2021年7月16日更新。采用通用机制，不移植特定平台命令或缺陷结论。

真实产品：飞畅mini工业轨式5路百兆电交换机。能力以所选版本为准。图片由AI辅助制作，为通用原理示意。