黑河市all2014年我还在做工业物联网相关的东西，第一次碰项目就是一块STM32板子通过RS485往主机传温湿度数据。当时抱着Modbus协议手册啃了好几天，才分清功能码03和寄存器地址到底怎么用。后来这十年，我换过几家公司，做过物联网平台、汽车电子、边缘网关，也帮朋友调过停车场道闸的车牌识别相机。回头一看，所有项目几乎都在围着同一个词转——协议。SPI、I2C、UART、CAN、Modbus、MQTT、TLS、RTSP、X11、DRM，每个词的背后，都是一整套设备之间怎么对话的规矩。
这十年里，协议世界有个特别有意思的规律：真正被彻底淘汰的协议很少，大多数只是在换角色、换位置。有的从台前退到幕后变成基础设施，有的被新协议包了一层壳，有的则因为业务形态变了而逐渐边缘化。这篇文章我打算按自己实际接触过的几条线，把这个故事串起来。不写学术论文，只写一个干了十几年的工程师眼里的观察和踩过的坑。
1. 低速总线“老三样”：UART、I2C、SPI的十年角色转变
1.1 为什么一块2014年的板子今天还能修
先说一个反常识的现象：芯片技术在飞速更新，但UART、I2C、SPI这三条最“古老”的板级总线，几乎没什么破坏性变化。我翻出自己2014年做的采集板，上面的MPU6050还是那个MPU6050，I2C地址还是0x68，主控从STM32F103换成了更现代的型号，但驱动代码稍作调整就能跑。
原因不复杂：这三种协议把“简单”和“便宜”做到了极致。I2C两根线就能挂一堆传感器，SPI四根线就能跑到几十兆，UART一根TX一根RX就能点对点通信。对绝大多数MCU应用来说，它们的速率和功能从来不是瓶颈，反而是“够用”和“稳定”变成了最大的优势。而且调试工具太成熟了——逻辑分析仪也好，示波器也好，甚至连几十块钱的调试器都能直接解析这些协议的时序。我以前用带fx2lafw固件的逻辑分析仪抓I2C波形，一眼就能看出设备地址是不是冲突，ACK位是不是被拉低。
还有一个被很多人忽略的细节：很多老设备升级固件用的还是YModem这种串口协议。YModem是XModem的改良版，支持批量传输和文件名传递，看起来像是上个时代的产物，但因为它实现简单、天然适配UART，到现在仍然大量出现在Bootloader里。哪怕某些新项目已经用上了OTA，首版烧录很多还是靠串口加YModem。这就是典型的老协议生命力——不会占据舞台中心，但永远有人需要它兜底。
1.2 外设变多之后，老三样被挤出了舒适区
这十年里，真正的变化不在协议本身，而在“挂东西的数量”。以前一块板子挂两个传感器就算复杂了，现在一个IoT节点要挂温湿度、气压、加速度、麦克风、屏幕、Flash，外设数量翻了几倍。这时候I2C和SPI各自的短板就开始暴露。
I2C最大的坑是地址冲突。7位地址最多128个设备，听起来不少，但很多同类芯片出厂地址一样，还只支持两三个可选地址。我见过一块板子上同时放两颗同一型号的传感器，芯片手册翻烂了也找不到改地址的办法，最后只能加一颗PCA9546这样的I2C多路选择器，把总线拆成多路。这个做法2014年就在用，现在还在用，换的只是芯片型号。
SPI的问题则是引脚。一主多从时每个从机需要一根独立的片选，外设一多，GPIO先不够用。更麻烦的是信号完整性问题，高速SPI在长排线上容易串扰，时钟频率稍微提上去就出现误码。所以SPI这十年的演进路线是往“专用化”走——显示屏用MIPI DSI，摄像头用MIPI CSI，Flash用QSPI/OSPI，STM32这类主控干脆把QS PI接口做进硬件，让通用SPI只接低速外设。
UART的情况稍微特殊。它本身没有时钟线，靠双方约定波特率来采样，所以字节对齐问题、波特率漂移问题一直是老生常谈。但UART生命力在于“什么都能转”——转RS485走工业总线，转TTL接蓝牙模块，转USB接调试口。这十年UART本身没变，但围绕它的“转接生态”越来越庞大，某种程度上也算是一种演进。
1.3 新协议补位：I3C和USB/PCIe的启示
这些年也不是没有新总线想取代它们。MIPI联盟推的I3C就是个典型，意图很明显：结合I2C的少引脚和SPI的高速率，顺便解决I2C的地址冲突问题，还加入带内中断、动态地址分配、热加入这些现代设备需要的能力。I3C最高速率能到12.5MHz，看起来确实比I2C漂亮很多。
但直到今天，I3C也没能大规模替代I2C。原因还是那个词：生态。I2C的传感器库、调试工具、工程师经验、IP核，积累了三十年，厂商和开发者都没动力为了“快一点”去换。I3C目前主要出现在高端手机、可穿戴设备里的传感器Hub等少数场景。这说明了一个特别重要的规律：协议演进的驱动力从来不是“技术更先进”，而是“迁移的性价比够不够高”。
同样的逻辑也适用于USB和PCIe。USB从3.0一路走到4.0，物理接口被Type-C统一了，但核心模型还是枚举、端点、传输描述符那一套。PCIe从3.0到5.0再到6.0，速率翻了好几倍，但配置空间、地址映射机制基本没变。芯片内部的总线也一样，ARM的AXI协议从AXI3到AXI4，做了通道调整，但读写通道的基本模型还在。老协议不是死不掉，而是变成了底层土壤，新协议在上面长出来，却不能把老根刨了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 工业现场总线的数字化跃迁：Modbus为何不退休，EtherCAT和OPC UA为何上位
2.1 Modbus是我见过的生命力最强的协议
如果只能选一个协议代表“工业十年不变”，我肯定投Modbus。1979年由Modicon公司提出，到现在四十多年了，工厂里的电表、温控器、PLC、变频器，几乎还能见到它的身影。
Modbus的核心思路就四个字：主从轮询。主机问，从机答，通过功能码区分操作——03是读保持寄存器，06是写单个寄存器，16是写多个寄存器。这个模型简单到什么程度？从机的固件可以用一个定时器加上串口中断就实现，不需要操作系统，不需要协议栈，MCU资源再紧张也能跑。这也是它能活四十年的根本原因。
但它的问题也一样突出。轮询机制决定了从机数量越多，实时性越差。我曾经给一个工厂做数据采集，现场挂了接近两百个Modbus从站，上位机轮询一圈下来要两三秒。对抄表、状态监测这种应用够用，但如果你想用它做运动控制或者设备联动，那就完全不行了。另外Modbus本身没有安全机制，没有认证、没有加密，这些年在OT网络里也越来越让人不放心。
国内还有一堆基于串口的行业规约，比如电表领域常见的DL/T645，数控机床的广数等国产系统也有自己的一套私有协议。它们的处境和Modbus差不多：稳定可靠，但封闭。这些年做工业数据平台，最痛苦的不是设备连不上，而是每种设备都要单独写驱动，每家厂商的寄存器表还不一样。所以工业界这十年真正解决的，不是怎么让设备更快，而是怎么让数据从设备里“长”出来变成统一的信息。
2.2 实时性和信息模型：数字化工厂带来的两道新考题
2014年前后，“工业4.0”“智能制造”这些概念开始灌进工厂，原来的数据采集模式不够用了。产线上需要的不再是“几秒采一次数据”，而是运动控制、机器视觉、多轴同步这种微秒级甚至纳秒级实时性。Modbus轮询做不到，于是EtherCAT这类实时以太网协议上位了。
EtherCAT的核心思路是“飞读飞写”：主站发送一帧报文，报文在从站之间像接力棒一样穿过，每个从站在报文经过时直接读写属于自己的那一段数据，整个过程不需要传统的“请求—应答”往返。再加上分布式时钟机制，所有从站可以共享同一个时间基准，多轴同步误差能控制在纳秒级别。我在接触它之前一直想不明白，为什么一套伺服系统能做得那么顺滑，后来看了EtherCAT的帧结构才明白，协议设计直接决定了控制系统的天花板。
不过实时性只是第一步。工厂数字化后面临的另一道题是：数据格式不一样，不同厂商的设备怎么在一个系统里对话？以前的思路是做网关，把A家的协议转成B家的协议，但转来转去容易丢信息。OPC UA的出现给出了另一种答案——不转协议，而是统一信息模型。OPC UA不光定义了“怎么传数据”，还定义了“传的数据长什么样”，比如一台电机不是一个冷冰冰的寄存器块，而是一个带温度、转速、状态属性的对象。这其实是把IT世界的建模思维搬到了OT世界里。
我自己的体会是，Modbus、EtherCAT、OPC UA并不是互相替代的三代产品，而是分层共存的三种角色。Modbus管简单设备，EtherCAT管实时控制，OPC UA管信息集成。工业协议这十年的演进，本质上就是不断往“既有系统上加新层”，而不是把旧的推倒重来。
2.3 半导体行业的SECS/GEM：一个“老协议”在高端制造里的坚持
在工业大环境里，有一个细分领域最容易被人忽略，但它对协议的执着程度远超其他行业，就是半导体制造。半导体设备之间、设备与工厂管理系统之间的通信，几十年来一直用SEMI标准定义的SECS/GEM协议。它定义了设备如何上报事件、如何接收远程命令、如何描述自身状态，还规定了消息格式（SECS-I/Hsms）和通信方式。
我一度不太理解，为什么半导体行业这么保守，不愿意换更现代的协议。后来做过半导体设备对接项目才明白，芯片产线的验证成本极高，任何协议变更都可能导致整个产线停摆，没人愿意冒这个风险。所以SECS/GEM这套标准从80年代用到现在，哪怕它报文可读性很差，哪怕它和现代IT系统对接需要写大量胶水代码，它依然稳坐钓鱼台。这给所有工程师上了一课：协议生命力最强的时刻，不是技术最好的时候，而是“大家都依赖它、没人敢动它”的时候。
3. 物联网关键词：MQTT如何靠发布/订阅统一了设备上云
3.1 2014年前后，设备上云为什么那么痛苦
把时间拨回2014年前后，那时的物联网还叫M2M（Machine to Machine）。设备上云的主流做法是什么？是设备端主动HTTP轮询，或者自己基于TCP写一个私有长连接协议。HTTP轮询的问题很直观：设备数量一多，服务器压力大，实时性差；私有TCP协议则各自为战，每个团队都有一套自己的报文格式，没有互通性可言。
我最早做物联网平台时，最大的感受就是要“伺候”各种各样的私有协议。今天接一个净水器，明天接一个充电桩，后天再来一个路灯控制器，每个设备都要单独写适配层。到最后平台里一半的代码是在做协议解析和转换，真正业务逻辑反而没多少。
然后MQTT出现了。它其实诞生得挺早——1999年IBM就发明了它，但真正在物联网领域爆发是2014年之后的事情。那一年MQTT 3.1.1版本提交给OASIS标准化，紧接着各大云厂商开始提供MQTT接入能力，整个设备上云的方式才第一次有了统一的底座。
3.2 MQTT的核心设计：发布/订阅、QoS和遗嘱消息
MQTT能统一物联网，靠的是一套简洁而完整的设计。它采用发布/订阅模型，设备不需要知道数据往哪去，只管往某个Topic上发一条消息，Broker（消息代理）负责把消息转发给订阅了这个Topic的其他人。这种解耦特别适合海量设备场景——设备上线、离线、断线重连，都不用关心对端是谁。
MQTT还解决了几个实际问题。QoS机制保证了消息至少送达一次、或者恰好一次；Last Will（遗嘱消息）可以在设备非正常离线时向其他订阅方广播离线状态；Keep Alive心跳则让Broker能及时发现死链接。这些机制在2014年之前，私有协议里常常要自己一行行实现，而且很容易出bug。
MQTT和CoAP是那几年常被放在一起比较的两个协议。CoAP走UDP，更轻量，适合非常受限的设备，但在NAT穿透、消息可靠性上麻烦一些。MQTT走TCP，天然适合长连接，而且在云平台生态上更成熟。事实上后面几年,MQTT的生态越滚越大，很多曾用CoAP的产品也逐渐提供了MQTT接入选项。结果就是MQTT几乎成了“物联网协议”的代名词。
3.3 Broker的演进：从单机到百万连接集群，MQTT变成了基础设施
MQTT早期是典型的“单机Broker”玩法。Mosquitto这样的轻量Broker一台服务器可以扛几万个连接，对小项目完全够用。后来物联网规模上去了，动辄百万级设备接入，单机的瓶颈就出来了——连接数、消息吞吐、持久化、集群扩展，每一项都是问题。
于是EMQX、VerneMQ这类分布式Broker开始成为主流。它们把大量设备连接分散到多个节点，靠集群内部的分布式主题树来转发消息，既支撑了大规模连接，又能做消息持久化和规则引擎。这个阶段，MQTT完成了从“技术组件”到“基础设施”的转变：它不再只是设备到服务器的管道，而是整个物联网平台的核心总线。
Broker集群化之后，很多新问题也随之而来。比如消息重复、消息乱序、客户端ID冲突，这些在单机时代不怎么出现，在集群里却成了日常。做物联网平台的工程师，几乎都会在这些问题上栽过跟头。
3.4 实战踩坑：用MQTT对接海康、大华车牌识别相机
我之前帮朋友处理过一个停车场项目，需求是用MQTT对接海康和大华的车牌识别相机。这类相机其实提供了多种对接方式，包括SDK、HTTP回调、MQTT上报，相比之下MQTT最轻量，让相机直接往Broker上发事件，停车场管理端订阅对应Topic就行，省掉了中间网关。
实际做下来有三个坑值得记录：
第一个是Topic设计。相机上报事件用的是厂商自定义的Topic，不同型号可能还不一致。如果对端系统直接硬编码Topic，后面换一台相机就崩了。我当时的做法是加一层内部Topic映射，把厂商Topic统一转换成业务Topic，比如parking/entry、parking/exit，这样上层系统完全不用关心具体厂商。
第二个是Payload格式变化。相机固件升级后，上报的JSON包字段有时会多几个或者改类型。做协议解析时一定要做字段容错，不能因为一个字段解析失败就把整条消息丢了。养成分层解析的习惯，把“解析成功”和“业务有效”分开处理。
第三个就是QoS选择。很多人在设备端默认使用QoS 1，但QoS 1的本质是“至少一次”，意味着同一事件可能重复到达。如果上层系统直接保存到数据库，就会出现重复记录。我最后是在应用层做了去重，用相机ID加事件序号当幂等键。这个教训很典型——协议的可靠性，永远不能替代业务应用的幂等设计。
4. 汽车总线格局之变：CAN还没老，Some/IP和DDS已经进场
4.1 CAN是汽车真正的基本盘
汽车电子这十年，我们听到最多的新词是“智能驾驶”“SOA”“车载以太网”，但打开任何一辆量产车，分布最多的总线依然是CAN。CAN总线1991年由Bosch发布，到今天三十多年，依然占据着车辆控制的绝对主力。
CAN的优势是它天生为可靠性设计。它用差分信号传输，抗干扰能力强；它是多主总线，任何节点都可以发起通信；最巧妙的是它的CSMA/CA + 仲裁机制——所有节点同时发送时，优先级高的报文（ID小的）自动获胜，低优先级的节点会自动退避。这种分布式仲裁机制让CAN在电磁环境恶劣的车内依然能保证确定性。
做汽车电子的人都听过一个老生常谈的坑：CAN总线两端必须接120欧姆终端电阻。但就是这么个基础问题，每年仍然能坑到人。终端电阻缺失时总线反射严重，报文偶尔丢帧；两个节点都接了120欧姆，总线等效电阻变成60欧姆对收发器来说反而是正常的（CAN收发器本来就是为了60欧姆负载设计的）。但很多人不知道的是，只有总线物理两端各接一个120欧姆才对，中间节点千万不要接。这个细节我在车规测试时见过太多次了。
4.2 带宽焦虑催生了CAN FD和车载以太网
CAN的短板也很明显：带宽太低。经典CAN最高也就1Mbps，对发动机控制、车窗控制这种场景够用，但放到360度环视、智能驾驶传感器数据融合这些场景，完全不够看。于是CAN FD出现了。CAN FD把数据段速率提升到5Mbps以上，单帧数据长度从8字节扩展到64字节，还改进了CRC机制，比经典CAN灵活很多。
但即便是CAN FD，本质上还是为“信号”设计的——报文里定义哪个bit代表什么信号，通信前需要全车统一定义好信号矩阵。这个设计在ECU数量相对少、功能相对固定的时代很合适。可智能汽车时代，ECU数量动辄上百个，软件功能一两个月就要OTA一次，信号矩阵的僵化就暴露了。车载以太网（如100BASE-T1）因此引入，它能提供百兆甚至千兆级带宽，为更现代的应用层协议铺了路。
4.3 从“信号”到“服务”：Some/IP与DDS凭什么上位
汽车EE架构向中央计算+区域控制器演进后，传统信号通信开始让位于面向服务的通信（SOA）。这里最常被提到的两个协议是Some/IP和DDS。
Some/IP是宝马主导的一套基于IP的中间件协议，核心理念是把ECU的能力抽象成“服务”。比如“打开车门”不再是发送一个特定ID的信号，而是调用一个远程服务，并带参数和返回值。它支持服务发现（SD），设备启动后动态发现网络上可用的服务，这让软件的部署和更新灵活了很多——你不需要在出厂时把所有信号矩阵全部固化。
DDS则出身于机器人领域，比Some/IP更强调实时性、灵活性和去中心化。它基于发布/订阅模型，搞了一套非常复杂的QoS策略，能控制消息的可靠性、时效性、资源占用。汽车行业在智能驾驶域控制器里经常用DDS来传输传感器数据流。
我自己的判断是，这两种协议很难说谁取代谁。Some/IP在AUTOSAR Adaptive平台里有明确位置，更适合整车级服务调用；DDS在高算力的自动驾驶域内更常见。未来的车载网络大概率是多协议共存的：底层控制依然是CAN FD，跨域服务走Some/IP，域内大数据走DDS或共享内存。
4.4 顺带说一句：机器人ROS2的DDS和UDP问题
很多做机器人的朋友会有类似的疑问：ROS2底层用DDS，那它分发消息是不是就是UDP？这个问题其实挺典型。ROS2的默认DDS实现（如Fast DDS）确实主要基于UDP传输，但在同一个节点里，它还会通过共享内存做零拷贝传输。UDP的好处是低延迟、支持多播发现，坏处是丢包时应用得自己处理。
为什么ROS2不像ROS1那样定义自己的TCP消息协议？就是因为DDS已经包含了发现、发布订阅、QoS、序列化这一整套中间件能力，ROS2没必要重复造轮子。协议演进到后期，拼的不是谁能写更多底层代码，而是谁能把通用能力沉淀成一个标准中间件，让上层应用专注于自己的问题。
5. 网络与安全协议的十年加固：TLS升级史和抓包排查思维
5.1 TLS/SSL版本换血：禁用SSLv3、TLS1.3落地
网络协议里这十年变化最明显的，可能不是TCP/IP本身，而是它上层的安全协议TLS。2014年是安全协议历史上值得记住的一年——OpenSSL爆出Heartbleed漏洞，紧接着SSLv3被POODLE攻击打得千疮百孔。从那之后，业界开始集体封禁SSLv3，很多老系统在升级过程中“被迫”向TLS1.2迁移。到了2018年，TLS1.3标准发布，握手从两轮RTT压缩到一轮RTT，同时删除了大量过时的密码套件，性能和安全性一起提升。
但现实的痛苦在于老设备。我见过不少2012、2013年出厂的工业设备，终端里只支持TLS1.0和TLS1.1，而现代操作系统默认已经禁用了这些版本。两边一相遇，就会出现“客户端看着正常，服务器日志里一堆握手失败”的诡异状态。这时候的协议升级已经不是技术问题，而是资产管理和替换周期的问题。
5.2 一次“TLS协议错误”排查：Windows Server 2012的代码70
这类问题里最有代表性的，是Windows Server 2012上经常出现的“严重警告代码70：协议错误”。很多人一看到“协议错误”就懵了，以为是网络坏了，其实代码70对应的TLS告警是protocol_version，翻译成人话就是：通信双方支持的TLS版本没有交集。
我之前处理过一个项目：一台老服务器跑IIS，部署着给老客户端程序用的接口服务。客户端基于老式组件，只懂TLS1.0；服务器端的Windows Server 2012虽然默认支持TLS1.0，但运维同事之前出于安全考虑，在注册表里把TLS1.0和1.1都关掉了。于是客户端一建立连接，服务器就回一个代码70的告警。表面上看是“协议错误”，实际是版本策略配置打架。
排查方式其实很朴素。先确定双方各自支持什么版本：服务端看注册表项或IIS的协议配置，客户端如果用Windows自带组件就看系统默认的Schannel配置。再用OpenSSL命令行或者抓包工具看一下ClientHello里带了什么版本、ServerHello回的是什么。通常问题就明朗了。这个案例提醒我一句话：协议报错时，不要凭印象猜，第一反应应该是抓包看协商过程。
5.3 抓包仍然是网络协议问题最有效的通用语言
这些年网络协议分析工具越来越强，但方法论一直没变：遇到问题先抓包。我在前面提到的Modbus、MQTT、TLS问题，最后定位靠的都是抓包。Wireshark能解析上百种协议，ARP、IP分片、TCP重传、TLS握手，每一个细节都能在报文里看个清清楚楚。
还有协议指纹识别。现在很多网关和防火墙产品会根据TCP/IP栈的特征、TLS ClientHello里的密码套件列表来识别设备类型，甚至能判断出哪款操作系统、哪个浏览器版本。这种“指纹”能力在设备接入管理和物联网安全里越来越常用。原理也不神秘，就是抓取了足够多的报文样本，把协议行为里的“签名”提出来做匹配。
另外，很多系统组件报的错误其实与网络协议本身无关。比如Windows的PNRP服务（对等名称解析协议）有时会报“云未启动，错误代码0x80630801”，这往往是服务依赖没起来或防火墙拦了端口，而不是协议本身坏了。排查时要先分清层次：是底层网络不通，是协议协商失败，还是上层服务没启动？分层定位，永远比堆猜词题高效得多。
6. 音视频与显示链路的换血：RTMP退场，SRT/WebRTC补位，显示协议栈走向DRM
6.1 流媒体这十年：RTMP从主角变成了“历史遗留”
如果经常做直播或推流，你一定听过RTMP。它诞生于Flash时代，由Adobe在2009年开放，优点是协议成熟、延迟可接受，很长一段时间里，它可以算是直播推流的默认选择。国内早年那批秀场直播、游戏直播，几乎全靠RTMP撑起来。
但这些年RTMP的地位一直在被稀释。首当其冲的是Flash的死亡——现代浏览器早就彻底移除了Flash支持，用户打开一个需要RTMP播放的网页，看到的往往是“协议不受支持”的提示。其次，RTMP基于TCP，弱网下延迟容易飙升，对手机直播这种移动场景并不友好。后来SRT出现了，它基于UDP，做了前向纠错和丢包重传，在弱网环境下的表现比RTMP稳定不少。更主流的方向是WebRTC，它天然被浏览器支持，把端到端延迟压到了几百毫秒级别。
所以现在做直播方案，我的建议通常是分层选型：推流到平台用RTMP或SRT，平台到观众直接拉流可以用HTTP-FLV或HLS，而实时互动场景优先考虑WebRTC。协议选型没有银弹，只有“你这个场景最在意什么”——延迟？画质？还是兼容性？
6.2 安防和摄像头行业的RTSP与ONVIF
安防行业则是另一套逻辑。摄像机互联长期依赖RTSP拉流和ONVIF协议。RTSP负责会话控制，RTP负责传输视频流，这套组合在上世纪90年代就定下来了，至今仍是IP摄像机最通用的能力。ONVIF则是一套设备互操作标准，定义了设备发现、媒体配置、PTZ控制这些接口，方便不同品牌的NVR和摄像机互通。
做一个对接多个品牌摄像机的平台时，我的体会是：ONVIF只解决“能不能找到设备、能不能取到流”，至于画面质量、编码参数、告警事件这些更深层的数据，各厂商还是留有私有扩展。所以安防协议这十年的演进，不像互联网那么激进，而是“标准保底、私有扩展”的渐进路线。前面提到的车牌识别相机项目也一样，ONVIF拿来发现和取流，具体事件数据最终还得走厂商接口。
6.3 显示链路：X11、Wayland、DRM和Qt的xcb插件
再看显示这块，这里有一个经典的依赖链常让不少人困惑：屏幕硬件在内核里由DRM管理，再往上X Server提供X11协议，应用层Qt通过xcb插件连接X Server，最终图形才渲染到屏幕上。这条链路看起来又长又绕，但它的沉淀极其深厚。
X11协议从1987年发展到现在，最大特点是“服务器客户端”模型：X Server管理显示硬件，所有应用都作为客户端通过X11协议和它通信。这个模型很灵活，但问题也不少：画面合成、输入事件、窗口管理都绕来绕去，性能也有额外开销。于是Wayland作为新一代显示协议出现了。Wayland把合成器直接放到显示服务器里，减掉了X11里的大量间接层，减少了延迟，也简化了渲染流程。这些年主流桌面环境都在向Wayland迁移，嵌入式设备上Wayland搭配DRM/KMS更是常见的组合。
Qt这些年也在跟随这个变化。它早年通过X11的Xlib接口连X Server，后来改用xcb插件，到了Wayland时代又提供了wayland插件。如果哪天你在开发板上发现Qt程序起不来，或者显示异常，第一件事应该确认系统当前跑的是X11还是Wayland会话，再看Qt加载的是哪个平台插件。这个坑我踩过不止一次——程序明明编译正常，界面就是出不来，最后发现是缺了Qt的xcb运行依赖，或者DISPLAY/WAYLAND_DISPLAY环境变量没设对。
6.4 协议生态比协议本身更重要
回看这十年来来往往的协议，有一个结论越来越清晰：决定一个协议能不能活下去的，从来不只是技术参数，而是它周围的生态链。MIPI在屏幕和摄像头接口上的份额，靠的是整个手机供应链的支撑；CAN在汽车里的地位，靠的是从芯片到诊断工具到工程师技能树的完整积累；ONVIF能成为安防默认标准，靠的是几乎所有主流厂商都在往里填设备。它们当然不是最优的协议，但它们是“大家都会用、都愿意用”的协议。
这种生态惯性也解释了蓝牙的演进。经典蓝牙协议存在了二十来年，后来BLE以低功耗姿态杀入IoT，再往后蓝牙Mesh又把组网能力补上。每一次升级都没有完全切断老设备，而是向下兼容地往既有的生态里塞新能力。协议演进最性感的时刻，不是某一天标准文档发布，而是整个产业链安静地、默契地跟着它走。
做技术这些年，我已经不太会为了某个协议“新”而兴奋了。我更关心的是：这个协议能不能在真实环境里稳定跑三年？出了问题有没有人接得住？周边的工具、库、人才够不够？
协议这东西，说到底是人与人、设备与设备之间的一种约定。十年之后回头看，真正留下来的不是那些最华丽的设计，而是那些足够简单、足够可靠、足够让所有人愿意遵守的约定。对工程师来说，学会一个新协议总是容易的，难的是搞清楚一个老协议为什么还站在这里，以及你该在它旁边搭一个什么样的新协议，让整个系统继续有序地往前走。