1. 先把12种协议归个类思路一下就通了接到这个需求的时候我第一反应是不慌反而有点兴奋。很多人听到“12种工控协议”就头皮发麻觉得每种都是全新的、复杂的、互相不挨着的技术栈。实际上你真正接触下来会发现工控协议这个圈子远没有想象中那么天马行空它的演进路径其实是收敛的所有协议从根上都能找到血缘关系。我接触的12种协议包括Modbus RTU、Modbus TCP、S7comm、DL/T645、OPC UA、MQTT、BACnet、CANopen、EtherNet/IP、PROFINET、三菱MC协议、欧姆龙FINS。乍一看种类五花八门但你如果把它们按照“出生时代”和“传输载体”两条线拆开会发现剩下的工作就是逐个击破而已。先看传输载体这条线特别关键。老一代协议诞生于串口和现场总线时代典型代表是Modbus RTU、DL/T645、CANopen。它们报文短、结构紧凑、讲究实时性因为当年的CPU和带宽都有限。到了以太网普及之后新一代协议基本都是基于TCP/IP的变体比如Modbus TCP、S7comm、FINS、MC协议、EtherNet/IP它们只是把原先的应用层数据封装进了TCP/UDP的载荷里本质上还是请求-响应模型。再往后是异构集成时代OPC UA和MQTT这种跨平台、跨厂商、面向信息化的协议开始流行它们更多是解决“数据怎么往上走”的问题而不是“怎么读一个寄存器”的问题。按这个分类法去看你的学习难度其实是降低的。因为“串口系”学会一个“以太网系”就学了一半因为无非是把CRC校验换成TCP头把物理层从RS485换成了网线和交换机。信息集成系则更偏向概念理解协议本身的数据结构反而比Modbus简单难点在服务模型和信息模型的设计思想。我建议你把协议先画一个矩阵横轴是传输介质串口/以太网/现场总线纵轴是通信模式主从/对等/发布订阅。画完你就知道Modbus RTU是串口主从Modbus TCP是以太网主从FINS和MC协议是以太网主从的变体EtherNet/IP是以太网上的对等通信CANopen是现场总线主从广播OPC UA和MQTT是服务端-客户端和发布-订阅。这个矩阵能帮你决定先学哪个、后学哪个以及哪些可以放到一起对比着看。1.1 串口时代的“老法师”们串口协议是入门首选原因是它们简单得可爱。Modbus RTU一个报文就四段地址码、功能码、数据区、CRC校验。地址码告诉从站“我在叫谁”功能码告诉从站“我要干什么”数据区告诉从站“具体参数”CRC校验保证数据没串扰。你不需要理解任何服务模型不需要会话管理就是一问一答干净利落。DL/T645同理它的结构是一个起始符0x68开头然后是6字节表地址、控制码、数据长度、数据、校验和、结束符0x16这个结构比Modbus要绕一点因为多了“帧起始和结束”的概念但基本思路也是请求-响应。CANopen稍微特殊它跑在CAN总线上有SDO和PDO的区分SDO用于配置参数PDO用于周期性的实时数据交换。但核心概念还是那个对象字典你通过索引去访问设备里的某个对象跟Modbus的寄存器地址本质上是同一回事。所以我的建议是串口系你只要把Modbus RTU吃透再花半天看DL/T645的帧结构差异再花一天理解CANopen的SDO/PDO概念这块就算拿下了。重点不是死记每个协议的报文模板而是理解它们都是在“一根线上解决多点访问、多数据类型、可靠性校验”这三个问题。1.2 以太网时代的“新贵族”以太网系协议可以分成两拨。一拨是“老协议的新容器”典型的Modbus TCP、S7comm、FINS、MC协议它们的老祖宗原来都是串口协议后来为了上车间网络直接在TCP/IP上做了封装。这类协议学习成本最低因为你已经把它的应用层看明白了只需要额外学一下传输层的握手方式和报文边界处理就好。另一拨则是从骨子里就是为以太网设计的比如EtherNet/IP和PROFINET。EtherNet/IP基于CIP协议栈它既有TCP上的显式消息用于参数配置也有UDP上的隐式消息用于周期性的实时I/O数据交换这里引入了连接、会话、消费/产生模型学习曲线明显更陡。PROFINET则分为NRT、RT、IRT三个等级IRT需要在交换机层面做时间同步和带宽预留所以单看协议报文其实是不完整的你得把整个工业以太网架构的思维一起带上。如果要从实用性排序我个人建议先攻S7comm、FINS、MC协议、Modbus TCP因为它们在设备接入、产线改造、上位机开发中出镜率最高EtherNet/IP和PROFINET可以放到后期遇到具体项目再深入。2. 个人开发者的底层套路从抓包到写库聊完了分类下面是重头戏具体怎么下手。我个人核心方法论就四个字——工具驱动。一个人要同时啃12种协议千万别闭门啃文档一定要找能直接看到报文的工具把你和协议之间的“黑盒”打穿。我最早接触Modbus RTU时用了好几天读PDF所有字节格式都背下来了可一到现场还是不知道为啥读不到数据。后来一个老师傅扔给我一句话别背了去抓包看。我当时的反应是串口怎么抓包后来用了虚拟串口工具加串口监视器真真切切看到主站发出的报文和从站返回的报文那一瞬间所有的文档记忆都活了。从那时候起我对任何新协议干的第一件事就是想尽一切办法抓到真实报文让协议自己“开口说话”。2.1 工具链准备先把工具链列清楚个人开发不用上什么高大上的商业平台一套开源组合拳足够覆盖我前面说的12种协议。串口类协议我推荐用“虚拟串口软件串口调试助手Wireshark的外接串口支持”。具体做法是用虚拟串口把两个物理串口对接起来一个接设备仿真器一个接你的调试脚本中间通过串口监视器看所有经过的数据。Modbus RTU和DL/T645都可以这么玩。Wireshark本身也能打开串口抓包不过现场环境下一般没有那么多串口给折腾所以我更习惯先用串口调试助手确认物理链路再用脚本去模拟完整的请求-响应过程。以太网类协议Wireshark是绝对主力。抓包过滤器里把IP和端口号一填当前通信的所有报文就都在屏幕上了。我特别建议大家使用Wireshark的“Follow TCP Stream”功能它能帮你把一段TCP会话里所有应用层数据拼成完整的字节流一眼就能看出请求和响应的对应关系。S7comm、Modbus TCP、FINS、MC协议都能靠这个功能快速摸清报文结构。协议仿真器也是必备。Modbus有Modbus Poll和Modbus SlaveS7comm有S7-PLCSIM和第三方的snap7模拟服务OPC UA有官方的UA Reference ServerMQTT有Eclipse Mosquitto和MQTTXCANopen可以用CANopenNode或者CANfestivalEtherNet/IP也有开源的模拟器。你没必要把所有仿真器都下载下来而是学哪个协议就装哪个最多花十分钟把默认参数跑起来重点是拿到“可控”的报文而不是随时断线、地址随机的真实设备。2.2 从抓包开始的逆向拆解流程拿到抓包之后我有一套固定的拆解流程。第一件事是判断传输层是什么。如果是串口就先找帧边界也就是每一帧从哪里开始、到哪里结束、有没有固定的起始符或结束符。Modbus RTU是没有起始符的它靠帧间隔时间来分帧所以实际抓包时要在报文之间看到明显的间隔DL/T645有固定的0x68起始符和0x16结束符帧边界一清二楚。以太网协议简单一些TCP本身就帮你把字节流切好了你需要关心的是应用层自己有没有长度字段以及这个长度字段包含的是从哪个字节到哪个字节。第二件事是画报文结构图。我的习惯是把第一次看到的请求报文和响应报文并排放在笔记本上然后一行一行地标注前几个字节是地址、接下来是功能码、再接下来是数据长度数据部分又分成哪几段。比如S7comm的报文大概结构是TPKT头3字节、COTP头4字节、ROSCTR1字节、参数区若干字节、数据区若干字节。这样标一遍之后你对这个协议的印象会非常深刻远比反复读文档有效。第三件事是验证。把报文结构弄清楚了之后写一个最小脚本手工拼出请求报文发给仿真器看响应对不对。不对就调整字段直到完全匹配。这一步能逼着你去处理所有边角料问题比如字节序、字交换、地址偏移而不是停留在“看起来理解了”的程度。2.3 搭一个属于自己的协议速查库学完一个协议之后一定要把成果沉淀下来否则三个月后你就忘干净了。我的做法是在GitHub上维护一个私有仓库里面每个协议一个文件夹包含协议速查笔记Markdown、抓包样例pcapng或者十六进制文本、最小可运行的Python示例代码。这个仓库不一定要开源但一定要坚持记录。笔记里固定几个章节报文结构图、功能码或指令类型表、常用数据类型映射、典型请求响应示例、踩坑记录。踩坑记录这个特别重要比如“三菱MC协议3E帧的子帧头固定为0x5000”、“欧姆龙FINS的地址计算要加1才能对应PLC内的地址”、“S7comm某个功能码对于200PLC无法直接访问V区”之类的这些都是你以后复用协议时最值钱的资产。顺手写一个通用的CRC工具集把CRC16-Modbus、CRC16-CANopen、DL/T645的CRC8、BACnet的CRC全部集中在一个文件里后面写任何串口协议都能直接调比每次翻文档重新算高效太多。这些琐碎的小工具累积起来之后后续接入新协议的速度会越来越快。3. 核心协议速通我在这几个协议上踩过的坑方法论说了那么多终究要落回具体协议。我不打算把12种全部摊开写一遍那太像API文档了读者看完也记不住。这里挑几个代表性最强、也是我耗费精力最多的协议聊聊带你看看速通时需要盯住哪些关键点。其余的协议其实都是“同构异形”理解了这些之后你再去看新协议会非常快。3.1 Modbus系一切工控协议的起点Modbus是整个工控协议的敲门砖建议所有初学者都从它起步。RTU模式下请求报文的格式是从站地址1字节、功能码1字节、起始地址2字节、寄存器数量2字节、CRC低字节、CRC高字节。功能码最核心的就几个0x03读保持寄存器、0x04读输入寄存器、0x06写单寄存器、0x10写多寄存器。就这么点东西覆盖了90%的PLC和仪表通信场景。但Modbus有个特别容易踩的坑是字节序。以32位浮点数为例有的设备是ABCD字节序也就是大端模式有的设备是CDAB也就是字内交换。同一个设备测出来的数据格式如果你用错解析顺序数值就完全是天文数字。我在一个流量计项目上就栽过跟头表端显示3.5立方米我读出来一个8千多万后来查了半天才发现是字交换的问题。这种问题几乎只能靠抓包和实测对比去解决所以我建议你在接入任何Modbus从站时第一步先读已知数值的寄存器把字节序测出来再往上层写逻辑。Modbus TCP要简单很多它在RTU报文基础上增加了MBAP头事务处理标识2字节、协议标识2字节固定为0、长度2字节、单元标识1字节。需要注意RTU的CRC校验在TCP版本中去掉了因为TCP自己会保证可靠性。长度字段是“从单元标识开始到报文结束的字节数”也就是说它等于PDU长度加1。这个细节如果你没看准Wireshark解析会报错设备那边也不会给你正常响应。3.2 S7comm西门子PLC的“黑话”S7comm是西门子PLC的原生协议比Modbus复杂在两个地方一是它有多层封装二是它有一个专门的Job/ACK机制。报文整体结构是TPKT3字节固定为0x03 0x00 长度、COTP4字节其中0x02表示DT-TPDU类型长度一般为2字节、ROSCTR1字节0x01表示连接请求0x02表示确认0x07表示用户数据、然后才是真正的S7comm PDU。PDU里面参数区会定义功能码常用的有0x04读、0x05写、0x1A请求会话、0xF0设置通信等。我最早被S7comm折磨到崩溃的就是“请求会话”这个环节。第一次连上PLC后如果没有发送请求会话数据包后续的读写请求会被直接拒绝响应里面会带一个错误代码。后来我理清了连接建立后需要先发一个带0xF0参数的会话请求拿到确认之后再发0x04读请求。这个流程用snap7库的话已经被封装好了但你要是不理解底层逻辑遇到在线状态切换、连接重连等问题时就会一头雾水。调试S7comm最大的好处是可以直接用PLCSIM仿真不需要真实PLC硬件。建议你在PLCSIM里准备好一块DB块、一个M区和一组I/O地址然后用抓包工具把读写过程完整记录下来对照文档逐字节理解。这个过程走通之后你再去看西门子官方手册脑子里的地图就已经成形了。3.3 OPC UA不要把它当成一个普通协议学OPC UA是我认为这12种里思维模型最不一样的一个。它不只是“发一个请求、收一个响应”的报文协议而是一个完整的分布式服务框架。你学它的时候如果还抱着“把这几个字节拼出来”的想法会非常痛苦因为UA的起手式就是建安全信道、建会话、读节点、订阅数据每一步都有复杂的握手过程。我建议你用OPC UA官方提供的UA Reference Server配合UA Expert客户端先走一遍把整个交互流程摸清。然后看一遍Wireshark抓包理解它的TCP封装格式和二进制协议结构。最关键的是要建立“信息模型”的概念OPC UA里的数据是以节点Node为单位组织的每个节点有节点ID、属性、引用和类型一个PLC的某个变量可能对应一个Variable节点一个设备可能对应一个Object节点。这个模型比Modbus里“寄存器号”先进了不止一个时代。实际操作上用Python的opcua-asyncio库可以快速上手这个库的API设计得很贴近协议本身你写代码的过程本身就是在加深对信息模型的理解。比如client.nodes.objects、get_children()、read_value()这些接口能让你直观地感受到OPC UA是把“数据的语义”和“数据的传输”分开处理的。3.4 其他协议的公共心法剩下的一堆协议我真的是用“求同法”啃的。三菱MC协议和欧姆龙FINS都是典型的以太网请求-响应协议核心是搞懂它们的子帧头、网络号、PC编号、站号这些寻址字段以及数据区里地址的计算规则。三菱的地址计算尤其麻烦D寄存器的编号和协议里的地址值相差很大需要套公式换算欧姆龙相对直观一些但FINS的地址是基于CIO/DM区块的换回PLC地址时要加偏移。BACnet这个协议一定要分清它跑在什么网络上BACnet/IP用的是UDP 47808端口但它还有MS/TP、PTP等串口变体。楼宇自控里最常用的是读AI/AO/BI/BO对象的当前值本质上是ReadProperty请求PICS文件会告诉你设备支持哪些对象和服务这个文件比协议文档重要得多。CANopen作为CAN总线的应用层必须先弄清楚对象字典和PDO映射的关系。在真实项目中往往不是让你去拼帧而是配置好一个EDS文件然后由协议栈自动完成SDO/PDO的转换。所以学CANopen的时候时间要花在理解PDO映射参数和对象字典索引上而不是死记帧格式。DL/T645则是典型的国家标准型协议它最让人头疼的是数据格式的BCD编码和字节反转。比如表码值是12.34协议里可能传的是0x34 0x33 0x12 0x31之类的需要按BCD规则重新组合。还有07版新增的扩展报文和97版不完全兼容实际项目中要先明确表计支持哪个版本。4. 实操全过程从零搞定一个新协议接入有了前面3章的功底你就可以走一遍从接到需求到现场验收的完整闭环。这里我拿一个实际案例来讲某一天接到个任务现场有一台仪表只支持Modbus RTU串口需要把它的实时数据采集上来再通过MQTT上报到云端平台。这个需求看着简单但把“串口采集”和“云端接入”串起来正好能覆盖协议学习的大部分关键节点。4.1 明确硬件链路和参数先看硬件连接。仪表有RS485接口需要走USB转485适配器接到电脑或者边缘网关。你要确认串口参数最常见的是9600波特率、8数据位、1停止位、无校验9600-8-N-1但千万不能想当然有些仪表是19200有些是偶校验参数错了是收不到任何响应的。我一般的做法是先用串口调试助手轮询测试把所有可能的波特率和校验组合都试一遍凡是设备有回帧的就说明参数对了。然后是确认仪表从站地址。Modbus RTU允许同一总线上挂多个从站地址范围是1到247。如果不知道仪表地址可以用广播地址0发功能码0x08的诊断请求但很多仪表不支持实际的笨办法是翻阅设备说明书或者用仪表面板设置查看。4.2 抓包验证协议解析拿到正确的串口参数之后别急着写代码先把数据抓下来看。我的做法是串口线经过一个串口监控工具一端接仪表一端接调试软件。发送一个读保持寄存器请求例如请求从站1读取地址0开始的5个寄存器原始报文是01 03 00 00 00 05 85 C9。其中01是地址03是功能码00 00是起始寄存器地址00 05是寄存器数量85 C9是CRC校验。如果设备回帧正常会返回类似01 03 0A ... ...这样的报文。0A是返回的数据字节数5个寄存器10个字节后面跟着的就是数据。我在这个时候会重点检查两点一是寄存器数量和返回字节数是否一致二是数据能不能和设备面板显示的值对得上。如果对不上先怀疑字节序再怀疑地址偏移。4.3 写一个最小可运行的采集脚本把报文结构验证清楚后我会用Python写一套最精简的采集代码。一个是自己实现的Modbus RTU读写函数一个是用paho-mqtt上报数据到云。自己实现Modbus RTU的请求函数不是为了重复造轮子而是为了让你掌握四个关键动作拼接请求、计算CRC、解析响应、错误处理。import time import serial def crc16_modbus(data: bytes) - bytes: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return bytes([crc 0xFF, (crc 8) 0xFF]) def read_holding_registers(ser, slave_id, start_addr, quantity): request bytes([slave_id, 0x03]) start_addr.to_bytes(2, big) quantity.to_bytes(2, big) request crc16_modbus(request) ser.write(request) time.sleep(0.05) response ser.read(5 quantity * 2) if len(response) 5 or response[0] ! slave_id or response[1] ! 0x03: raise RuntimeError(fillegal response: {response.hex()}) byte_count response[2] values [] for i in range(quantity): offset 3 i * 2 values.append(int.from_bytes(response[offset:offset2], big)) return values这段代码非常直白CRC计算直接用查表法演算版也不需要额外依赖gzip或pymodbus自己写完一遍你基本就懂CRC的原理了。实际项目里我会用pymodbus库因为它已经把超时、重发、异常码都处理好了但学习阶段亲手拼一次报文是绝对必要的。紧接着是MQTT上报部分用paho-mqtt库import paho.mqtt.client as mqtt client mqtt.Client() client.connect(broker.emqx.io, 1883, 60) payload {temperature: 25.6, pressure: 1.02} client.publish(factory/equipment/device01, payload, qos1)这里要注意MQTT的Topic设计。尽量采用层级结构比如factory/line01/equipment01/analog_values而不是平铺的名字。因为订阅端可以按层级匹配云平台的规则引擎也能直接按Topic前缀转发。QoS一般用1保证至少送达一次比QoS0更可靠又比QoS2更简单且不会造成阻塞。4.4 现场联调时最容易翻车的几个瞬间联调阶段才是真正检验协议理解的地方。我简单总结几个高频“翻车点”都是我自己踩过的泥坑。第一是RS485的A/B线接反。接反之后最典型的现象是设备完全无响应或者偶发乱码。这不是协议问题是物理层问题。用万用表量一下电压就能发现正常工作的时候A线相对B线是2~5V的正压。遇到无响应先查接线和波特率不要急着看报文。第二是Modbus地址偏移。很多PLC或仪表手册上标注的寄存器地址是“1起始”的也就是40001、40002这种协议地址但在报文中实际传的是40000对应的偏移也就是0、1这种。如果你照着手册地址原样填入读出来的是下一个寄存器。这个坑在S7comm里更严重因为西门子PLC里的DB地址、M地址需要转换成实际字节偏移转换不对会报“地址越界”。第三是时间同步和超时设置。串口请求发出去之后有些设备响应很慢可能要几百毫秒尤其是它同时还在处理PLC轮询时。如果你的串口超时设置太短就会频繁读到半截报文然后错误地进入重试循环导致总线拥堵。我建议把Modbus RTU的超时时间设置在500毫秒以上重试次数控制在3次以内并且重试前要先清空串口缓冲区防止残留数据干扰解析。5. 常见问题与排查技巧协议开发做到后期真正比速度的往往不是谁记得更多报文模板而是谁能在现场更快定位问题。这里我把个人项目里遇到频率最高的几个问题整理成一张排查表同时分享一些你平时在文档里搜不到的土办法。5.1 解析类问题字节序永远是排名第一的坑。不同PLC对多字节数据的排布习惯不同我用过的设备里既有标准大端的也有字内交换的还有把32位整数的高16位和低16位反过来传输的。排查技巧是找一个已知数值试试如果读出的值和预期差很远先怀疑字节序再用一次对已知数据的回归测试确认。浮点解析的问题紧随其后。IEEE754格式大家都懂但每个厂商在存储器里的排列真的五花八门。我有个取巧的办法在设备侧设置一个容易识别的浮点数值比如1.0或100.0它的十六进制是固定的0x3F800000、0x42C80000然后看抓包报文里这个值出现在哪些字节位置就能一目了然地判断出实际字节序。数据长度和解包边界问题也不少。有些协议在数据区里塞了多个数据项每一项前面有长度字段或类型字段。用切片解析时我习惯先按固定的“协议头长度”定位到数据区起点再循环按“字段类型字段长度”读取而不是按固定偏移去取。这样哪怕协议升级多了一个字段代码也能自适应。解析异常还有一个高频原因你把响应里的事务ID和请求里的搞混了。Modbus TCP和FINS里都有事务ID或序列号有的设备会把请求中的序列号原样返回有的则会自己生成新序列号。如果你在代码里假设“响应的序列号必须和请求一致”就会在部分设备上报错。正确做法是只校验协议标识和功能码以及必要的长度字段。5.2 通信类问题多主站冲突是串口协议的一大痛点。Modbus总线上一旦挂了两个主站它们同时发请求就会把报文冲垮。排查现象是通信时好时坏偶尔连上偶尔全断。解决方式要么是改造成单主站架构要么是让多个主站通过时间片分时访问决不能同时抢占总线。TCP连接层面的问题也很多。S7comm和欧姆龙FINS有一个共同点它们是长连接协议默认会保持连接状态。如果上位机程序崩溃后没有正常关闭连接PLC那边会在一个超时周期内维持旧会话导致新的连接请求被拒绝。遇到这种情况不要反复重连等十几秒或者直接重启设备侧通信模块连接就恢复了。序列化连接数的问题同样值得警惕。有的PLC通信模块限制同时会话数比如西门子S7-200 SMART最多只能有8个连接。如果你的云平台、HMI、调试工具同时各占几个连接很快就满了。这时候要么关掉不用的调试工具要么将上层数据采集统一收口到一个网关再对外分发避免多个应用直接抢PLC的连接数。5.3 工控协议排查速查表问题现象可能原因优先排查方向串口完全无响应接线错误、波特率不匹配万用表量A/B电压逐个试波特率报文有回帧但长度不对数据位/停止位设置错误检查8-N-1配置试偶校验CRC校验总是失败地址码或数据区拼接错误不要发送广播地址0单独验证CRC函数读寄存器值异常大字节序或浮点格式错误写入已知值用抓包比对原始字节能连接但读不了数据PLC通信密码或访问权限限制查看PLC保护和连接限制设置TCP能连但发请求无响应应用层握手缺步骤检查是否有会话建立请求等前置流程断线重连后一直失败旧连接未释放或序列号未同步等待旧连接超时或者重启通信模块Wireshark解析为“不识别”端口或报文格式判断错误直接看16进制字节按长度字段手动解析排查时还有两个通用心法一是永远先看原始字节不要依赖Wireshark帮你的解析结果二是每改动一个变量都要做对照测试不要同时改两个东西否则出了问题根本不知道是谁引起的。我在这里还要特别强调一个容易忽略的“软坑”协议文档版本和你手里的设备固件版本不一致。特别是很多老设备固件升级后原本不支持的扩展功能码就支持了或者原本正常的某个功能被默认关掉了。所以遇到“文档上讲得通但现场就是不行”的场景优先去查固件版本更新日志和官方兼容性说明这比折腾代码效率高得多。6. 我啃完这12种协议后的真正心得写到这里如果你问我要一个最核心的总结我不会去复述哪个协议的具体报文格式而是想聊聊心态层面的转变。第一不要被数字吓住。12种协议听上去很多但真把它们的底层脉络理清了你会发现80%都是“请求-响应”的变体真正全新的思维模型只有OPC UA的信息模型、MQTT的发布订阅、CANopen的对象字典这几个。其余的差异只在寻址方式、CRC算法、字节序和头部字段上这些是可以批量突击的。第二工具使用能力比记忆力更重要。我啃完这么多协议真正记住的报文格式其实没多少因为每次写代码之前我都可以翻笔记、翻抓包文件。但对每种协议我都能在十分钟内拿到一份真实的报文样本这是更值钱的能力。第三尽量做“一次性的深度投入”。每个协议第一次接触时花时间把可运行的示例代码和抓包样本沉淀下来以后遇到类似项目直接复用。我现在做新项目从拿到需求到跑通一个最小会话Modbus大概十分钟S7comm大概半小时OPC UA需要一小时左右。这个速度不是因为我脑袋里装下了所有协议而是因为我的笔记和脚本仓库里已经存好了每类协议的“起手式”。最后分享一个我每次接新协议时都会做的小动作在纸上画一遍协议分层的示意图从物理层一直到应用层标清楚每一层负责什么。虽然这事看着很“老派”但它在梳理协议脉络时尤其管用。你在画的过程中很快就会意识到很多让你头痛的数据错乱问题其实只是某一层的某个边界条件没有处理好而已。画完之后把这张纸存下来三个月后再翻出来看你会发现自己对这套协议的理解已经不在一个层次上了。