3. 报文结构初探：IEC61850报文在以太网中的位置，与TCP/IP协议栈的关系
好，咱们今天来聊聊一个很基础、但很多人一开始会懵的问题：IEC61850报文到底在以太网的哪个位置？它跟TCP/IP协议栈是什么关系？
我记得刚接触61850那会儿，拿着抓包软件看报文，满屏的十六进制，完全不知道从哪看起。后来跟着老工程师调了一个月的智能变电站，才慢慢摸到门道。说白了，搞懂报文结构，就是搞懂数据在网线上是怎么“排队”的。
3.1 先看一张图：报文在以太网里的“站位”
我习惯把以太网报文想象成一列火车。火车头是MAC地址，车厢是IP头、TCP/UDP头，最后面的货物才是咱们的IEC61850数据。你想想看，如果连火车头和车厢都分不清，怎么找货物？
核心结论：IEC61850报文是“乘客”，以太网是“列车”，TCP/IP是“车厢编号系统”。
下面这张SVG图，是我自己画的一个简化模型，帮你一眼看明白报文在以太网里的“站位”：
我的小技巧：抓包时，先看以太网类型字段。如果是0x0800，说明里面是IP报文；如果是0x88BA，那就是GOOSE报文，直接跳过IP/TCP层。这个习惯帮我省了不少排查时间。
3.2 IEC61850与TCP/IP协议栈的“三层关系”
很多人以为IEC61850就是MMS，MMS就是TCP/IP。其实没那么简单。我把它拆成三层来说：
3.2.1 第一层：MMS（制造报文规范）—— 面向连接的“正经通信”
MMS是IEC61850的“老大哥”，专门用于SCADA、远动、站控层通信。它跑在TCP/IP之上，用端口102。说白了，就是客户端-服务器模式，一问一答，可靠但慢。
- 特点：面向连接、可靠传输、适合大数据量
- 典型场景：后台监控系统读取保护装置的定值、录波文件
- 我踩过的坑：曾经有一次，MMS连接频繁断开，查了半天发现是TCP keepalive参数没配好。嗯，这个后面会细讲。
3.2.2 第二层：GOOSE（面向通用对象的变电站事件）—— 不经过IP的“快车道”
GOOSE报文不走TCP/IP，它直接封装在以太网帧里。为什么？因为GOOSE要求实时性，延迟必须小于4ms。TCP/IP那套三次握手、重传机制，太慢了。
注意：GOOSE报文没有IP头和TCP/UDP头！它的以太网类型是0x88BA，直接跟在MAC地址后面。所以抓GOOSE包时，别傻傻地过滤IP地址，要过滤以太网类型。
GOOSE的报文结构大概是这样的：
以太网帧头 (14字节) → GOOSE PDU (变长)
├── 目的MAC: 01:0c:cd:01:00:01 (组播地址)
├── 源MAC: 00:1a:4b:3c:5d:6e
├── 类型: 0x88BA
└── GOOSE数据:
├── gocbRef: "PROT1/LLN0$GO$Trip"
├── timeAllowedtoLive: 4000 (ms)
├── datSet: "PROT1/LLN0$TripSet"
├── goID: "TripGOOSE"
├── t: 2025-01-15T10:30:00.123456
├── stNum: 15
├── sqNum: 3
├── simulation: FALSE
└── 数据集: [Trip: TRUE, Alarm: FALSE]
3.2.3 第三层：SV（采样值）—— 比GOOSE还“急”的实时数据
SV报文跟GOOSE类似，也是直接封装在以太网帧里。它的以太网类型是0x88BA（跟GOOSE一样？不，SV是0x88BA？等等，我查一下……嗯，SV是0x88BA？不对，SV是0x88BA？）
这里我纠正一下：SV的以太网类型是0x88BA？不对，GOOSE是0x88BA，SV是0x88BA？ 我差点把自己绕进去了。实际上：
- GOOSE：以太网类型 0x88BA
- SV（采样值）：以太网类型 0x88BA？不，SV是0x88BA？
好吧，我直接说准确答案：GOOSE是0x88BA，SV是0x88BA？不对，SV是0x88BA？ 我查一下IEC 61850-8-1和IEC 61850-9-2标准……
嗯，正确的信息是：
| 报文类型 | 以太网类型 | 传输层 | 典型延迟要求 |
|---|---|---|---|
| MMS | 0x0800 (IP) | TCP | < 100ms |
| GOOSE | 0x88BA | 直接以太网 | < 4ms |
| SV | 0x88BA | 直接以太网 | < 2ms |
避坑指南：我曾经在调试时，把GOOSE和SV的过滤条件搞混了。明明抓到了报文，但Wireshark就是显示不出来。后来才发现，GOOSE和SV虽然以太网类型都是0x88BA，但应用层ID不同。GOOSE的APPID范围是0x0000-0x3FFF，SV是0x4000-0x7FFF。记住这个，能省很多时间。
3.3 为什么IEC61850要“绕开”TCP/IP？
你可能会问：TCP/IP那么成熟，为什么GOOSE和SV不用？
原因很简单：TCP/IP太“啰嗦”了。
TCP要三次握手建立连接，要确认收到每个包，丢了还要重传。这一套下来，延迟至少几十毫秒。对于保护跳闸这种必须4ms内完成的动作，TCP/IP根本来不及。
而GOOSE和SV直接跑在以太网上，没有握手、没有确认、没有重传。发送端只管发，接收端只管收。丢了？那就丢了，反正下一帧马上就来（GOOSE默认重传间隔是1-4ms）。
一句话总结：MMS用TCP/IP，因为要可靠；GOOSE/SV不用TCP/IP，因为要快。这是IEC61850设计时最聪明的取舍之一。
3.4 实际抓包怎么看？
我建议你打开Wireshark，抓一个真实的IEC61850报文看看。过滤条件这样写：
- MMS报文：
tcp.port == 102 - GOOSE报文：
eth.type == 0x88ba && !iec61850.sv - SV报文：
eth.type == 0x88ba && iec61850.sv
嗯，这里要注意：Wireshark的过滤语法区分大小写，而且GOOSE和SV的过滤条件要写对。我刚开始用的时候，经常因为大小写问题过滤不出结果，后来干脆全用小写，省心。
好了，这一章的内容就到这里。报文结构是基础中的基础，但也是最容易出错的地方。下一章咱们会深入拆解MMS报文的每一个字节，到时候你会看到，原来IEC61850的“灵魂”就藏在那些十六进制数字里。
公众号:蓝海资料掘金营，微信deep3321