1. 项目背景：为什么要让PLC做socket从站
事情得从一条产线改造说起。现场有一台汇川EASY系列PLC，原本只走Modbus RTU和触摸屏通讯，但后来要接一套MES系统，上位机需要直接读PLC里的产量、故障码、设备状态。传统做法是加一个网关模块，或者让上位机通过Modbus TCP轮询。但问题是，MES这边是Java开发，他们只肯用JSON格式的数据，而且要求PLC主动推送，不想要轮询的通讯方式。
这就逼着PLC这边开一个socket服务端端口，做一个真正的"从站"——上位机连上来，PLC把数据打包成JSON发过去，或者接收上位机下发的配方参数。汇川EASY系列里的EASY521、EASY522这类带以太网口的CPU，自带socket库函数，支持TCP/UDP，完全能干这个活。
很多人一听"PLC做socket从站"就觉得高大上，其实落地说穿了就三件事：PLC监听端口、等待连接、收发数据。难的从来不是socket本身，而是怎么把PLC里几百个变量的读写逻辑安排好，怎么处理断线重连，怎么保证数据格式稳定。这篇博文就把我用EASY系列做socket从站的完整思路和踩坑记录写出来，从通讯原理到程序框架，再到排查问题。不管你是要把PLC数据推给MES，还是让两个品牌的PLC做以太网直连，这套思路都通用。
2. 底层原理：看懂socket通讯的数据流
2.1 用"打电话"理解socket机制
socket通讯初学者最容易卡在概念上。我给你打个比方，整个以太网通讯就像打电话。
服务器的IP地址就是电话号码，端口号就是分机号。你给总机拨号（连接IP），转接到分机（端口），通上话之后，两边就可以双向说话了。TCP协议就像打电话，接通后保持通话，谁都不挂断，数据有来有回，顺序不会乱；UDP协议就像发短信，编辑一条内容扔过去，对方收不收得到、什么时候收到，你没办法保证。
在EASY系列PLC里，我们的角色是接电话的那个人，也就是"从站"或者"服务端"。PLC先开机，然后在某个端口上守着，相当于把电话放在桌上等着响铃。上位机按IP和端口拨过来，PLC检测到有连接请求，同意接听（accept），这个通话就建立起来了。
关键点在于，socket通讯是全双工的，就跟打电话一样，能同时说和听。所以PLC可以在同一时刻既发送数据给上位机，也接收上位机下发的内容。这一点和Modbus这种半双工总线协议完全不同，因为Modbus的请求应答模式决定了同一时刻只有一个方向在传输。
2.2 TCP与UDP在实际工控场景中的选择
做PLC通讯选型，TCP还是UDP，这个决定直接影响后面程序的复杂度和稳定性。
TCP是面向连接的协议，有三次握手、确认应答、超时重传这些机制。数据发出去了，如果对方没收到，系统会自动重发，接收方收到错乱的数据包，系统会丢弃。对于PLC上报产量、设备状态、报警信息这些数据，一个都不能丢的场景，TCP是首选。
UDP就简单粗暴得多，它只负责把数据报发出去，不管对方收没收到。好处是快，没有握手和确认这些额外开销，但坏处也很明显：丢包、乱序、重复。纯UDP适合什么场景呢？广播类的应用，比如PLC把自己的状态每隔几秒发一次，上位机收到算幸运，收不到就等下一条。但如果你是做MES对接，人家那边要一条不多一条不少的数据，UDP就不合适了。
实际项目中，我还有第三种方案：TCP长连接加上自定义心跳。这个在4.2节里详细说，不属于UDP也不完全是TCP的默认行为，而是协议层的设计思路。
2.3 EASY系列PLC的网络硬件特性
聊完协议再来看硬件。汇川EASY系列分好几个子型号，EASY521、EASY522、EASY523这些是带以太网口的CPU，本体一般有1路以太网接口，支持10/100M自适应。EASY系列有的型号还支持EtherCAT总线，但要注意区分：EtherCAT是运动总线协议，socket通讯是普通TCP/IP协议栈的服务，两者不冲突，但功能定位完全不同。
EASY系列的以太网口支持两种工作方式：一种是编程口直连，就是你在INOTECH软件里在线监控程序用的；另一种是用户通讯口，就是我们做socket服务用的。这两个功能可以同时启用，IP地址也是同一个，也就是说，上位机既可以通过网口下载程序，也可以同时作为socket客户端连接PLC上的服务端口。
规格上有一点需要提前确认：EASY521的socket资源数量是有限的，我记得是支持多个同时连接，但具体要看固件版本。如果你的项目需要多个上位机同时连接同一台PLC，建议提前查一下对应型号的《用户手册》里socket通道数的说明，避免程序写完了才发现资源不够。
3. 方案设计：socket从站的整体架构与关键指标
3.1 从站模式的三层数据流设计
一个完整的PLC socket从站项目，绝不是简单地在PLC里面开个口子收发数据，而是要设计清晰的数据流。我通常分成三层来规划。
数据接入层：PLC采集现场的设备状态、传感器数据、工艺参数，这些数据分布在保持寄存器、内部继电器、定时器里。需要提前规划好哪些数据要往上传，映射到专门的通信变量区。
协议处理层：把通信变量区封装成特定的报文格式。如果你自己定了JSON格式的协议，这一层就要做字符串拼接和解析；如果你是走Modbus TCP，这一层就是标准的MBAP帧处理。
socket传输层：负责TCP连接管理、数据收发、断线重连、收发缓冲区的读写。这一层在EASY系列里是通过socket库函数完成的。
这么分层设计的好处是，每一层改动不会影响其他层。后期如果MES系统决定把JSON协议改成XML，你只需要把协议处理层换掉，socket层和变量映射层都不用动。
3.2 通信变量区规划：先定协议再写代码
我做过几个以太网通讯的项目，最深刻的体会就是：写socket程序之前，先把协议文档定义清楚，然后规划通信变量区。
以汇川EASY系列为例，我建议在PLC里专门开辟一段连续的保持寄存器作为通信映射区。比如你定义M区里的M0~M99作为协议解析后的内部标志，D区里的D1000~D1100作为通信数据映射区。上位机发送过来的配方数据，PLC解析后写入D1000开始的一段地址，程序内部再从这些地址读取使用；PLC要上传给上位机的数据，程序先把它们汇聚到D2000开始的地址区，socket发送函数直接从这个区域取值。
这种做法的优势非常明显。调试的时候，你在INOTECH软件的监控表里观察D1000和D2000这两个区域，一眼就能判断是"PLC程序的问题"还是"socket通讯的问题"。如果D1000里的数据到了，但上位机没收到，说明socket发送环节有bug；如果D1000里的数据本身就不对，问题就在PLC程序和上位机下发的协议上。
3.3 关键指标：响应时间、吞吐量与连接数
通讯方案需要量化指标。我建议在方案设计阶段就定下三个关键数值，后面做测试才有标准。
响应时间：从上位机发送请求到PLC返回应答的时间。这个受PLC扫描周期、socket处理频率和网络延迟共同影响。EASY系列CPU的扫描周期通常在毫秒级，加上socket库的处理，一般20ms内的响应时间基本都能达到。
吞吐量：单位时间内传输的数据量。PLC场景下，你不可能像PC那样跑大文件传输。一般的MES读取、配方下发，一帧数据几十到几百字节，一秒钟几十次交互就足够了。如果需求是每秒几兆字节的传输，那PLC做socket就不太合适了，得上专门的数据采集网关。
连接数：同一时刻支持多少个客户端连接。对于单台上位机的场景，1个连接就够。但如果你有多个MES节点同时连接，就需要注意EASY系列支持的socket通道数限制。一般支持2~4个是没有问题的，但建议加连接数监控，超过限制时主动拒绝新连接。
4. 实操实现：从零搭建EASY系列的socket从站程序
4.1 初始化配置：IP地址与端口设置
先做准备工作。用网线连接EASY系列PLC和电脑，在INOTECH软件的通讯设置里，给PLC分配一个固定IP地址。注意，这个IP必须是设备所在的局域网地址，不要用DHCP自动获取，因为PLC做socket服务端时，IP如果变了，上位机就永远连不上了。
举例说明，假设PLC的IP设置为192.168.1.10，子网掩码255.255.255.0，默认网关192.168.1.1。上位机电脑的IP要设成192.168.1.x网段内的地址，比如192.168.1.20，保证它们两个在同一个局域网里。
然后确定端口号。端口号的选型有个原则：避开知名端口和易冲突端口，一般选1024以上的高位端口。实际项目中我用过5020、8000、9000，都挺稳定的。避免用5000这类常见的开发端口，防止和现场其他软件的端口冲突。
在EASY系列的库函数里，socket初始化一般用Socket_Server_Init之类的指令，里面配置好本地端口号、TCP或UDP模式、最大连接数这些参数。
4.2 核心程序框架：完整状态机思维
PLC的程序和PC程序最大的不同在于，PLC没有main循环从main开始执行到结束这个概念，它的程序是按扫描周期不断重复执行的。所以socket服务程序必须用状态机的方式来组织。
我用一个程序块来管理整个socket服务端逻辑，用状态字来标识当前处于哪个阶段。状态机大致是这个流程：
状态0：关闭状态。程序初始化时进入这个状态，把socket关闭，标志位复位。
状态10：监听状态。PLC创建socket服务端并开始监听端口，相当于把电话放在桌上等铃响。如果监听成功，跳转到状态20；如果失败，记录错误码并返回状态0，等待重试。
状态20：等待连接状态。PLC一直在检查是否有新的客户端连接请求。这个检查是每扫描周期执行一次的，EASY系列的库函数会返回是否有连接建立。有连接来了，跳转到状态30。
状态30：通讯运行状态。这是核心工作状态。程序在这个状态里做三件事：接收上位机发来的数据、处理数据并执行相应逻辑、把回发数据打包发送出去。
状态40：断开处理状态。当TCP连接断开（对方关机、网线拔了、通讯超时），程序要能及时发现这个事件，然后清理缓冲区、释放连接资源，回到状态20继续等待新的连接。
这个状态机思路看着简单，但特别重要。如果你不用状态机，而是试图在程序里写一个while循环去等连接，PLC会卡死在那里，后面的程序全部不扫描了，这绝对是新手最爱犯的错误。
4.3 监听、等待连接与超时重连机制
具体到EASY系列的库函数，监听端口之后，需要自己写一个"查询是否有新连接"的逻辑。这个过程通常是每扫描周期调用一次Socket_Accept之类的函数，这个函数会返回一个布尔值或者错误码，告诉你当前有没有新的客户端连上来。
这里要特别注意超时处理。上位机可能连着连着突然崩了，或者网线松了，但TCP连接不会立刻断，要等TCP超时机制检测到。TCP默认的超时时间可能要几十秒甚至更久，这在工业现场没法接受，因为你需要快速判断连接状态，然后做出相应处理。
解决方法是自己加心跳机制。PLC作为从站，不需要上位机发什么，只需每5秒向上位机发送一个特定的心跳报文（比如字符串"PING"），上位机收到后回应一个"PONG"。如果PLC连续3次发送心跳都没收到上位机的回应，就认为这条连接已经死了，主动关闭socket，回到等待连接状态，重新等待新的客户端接入。
我在自己的项目里用过心跳方案，实测非常可靠。即使上位机程序崩溃，PLC最多15秒左右就能发现连接异常并恢复，比干等TCP默认超时靠谱得多。
4.4 数据接收的边界问题与缓冲区设计
socket通讯中，数据接收有一个天然的问题：你没办法保证一次接收就拿到完整的一帧数据。TCP是流式协议，它没有消息边界的概念，上位机发来的数据可能被分成好几个TCP包到达，也可能好几个数据帧合并成一个包到达你的接收缓冲区。
举例说明，上位机打算发送10字节的数据，但PLC的接收缓冲区可能第一轮只读到4字节，剩下的6字节要到下一轮扫描周期才读到。如果你在程序里假设"一次接收一定是一帧完整数据"，就会解析出错。
应对方法就一句话：接收缓冲区+帧完整性判定。
具体做法是：PLC每次调用socket接收函数，把读到的字节追加到一个自定义的缓冲区数组里，然后检查缓冲区中的数据长度是否达到一帧要求的长度，或者检查缓冲区中是否出现了帧尾字符（比如'\n'）。如果满足，就取出完整的一帧进行处理，剩余的数据留在缓冲区等待和下一轮收到的新数据拼成新帧。
我在项目中用的方法是定义帧尾。上位机每次发送的数据以固定字符结尾，比如用换行符'\n'或者回车符'\r\n'。PLC收到数据后往存储区里追加，然后搜索存储区里有没有这个帧尾字符。找到就从缓冲区开头到这个帧尾字符提取出来作为一帧完整请求，剩下的部分留在缓冲区，等待后续的数据来接上。同时要设置缓冲区上限，防止异常数据堆积导致内存溢出，比如缓冲区最多存256字节，如果超出还没找到帧尾，就强制清空，让上位机重新发。
4.5 数据发送的防阻塞与长度控制
数据发送看起来简单，就是一条发送指令，但同样有细节。
EASY系列的socket发送函数，通常需要指定发送数据的起始地址和数据长度。我在程序里定义了一个发送缓冲区和发送长度变量。需要发送的数据先组合好放入发送缓冲区，更新长度变量，然后触发发送标志，程序扫描到发送标志后调用一次发送函数。
需要注意的是，发送函数不会因为你指定了100字节就保证一次调用发出去100字节。TCP发送可能只发走部分数据，剩余的你要在下一次扫描周期继续发送。所以程序中要记录"还有多少字节没发完"，每次扫描都检查发送缓冲区中剩余的数据，直到全部发送出去才清除发送标志。这就是所谓的防阻塞发送。
还有一种常见情况是发送频率过高。比如上位机要求每秒更新一次产量数据，但PLC的扫描周期是10ms，如果你没做发送频率限制，就可能在10ms内发出去好几次数据，把上位机打懵。我的做法是，用定时器控制发送周期，数据更新标志位和发送动作解耦，第N次扫描到了发送时间点，才把当前最新的数据发出去。这样既保证了对上位机数据的时效性，又不至于把网络通道塞满。
5. 实战中的那些坑：问题排查与解决方案
5.1 启动失败的排查：bind: only one usage of each socket address
这是socket编程的经典错误，无论在PC端还是PLC端都会遇到。它的意思是：你想绑定的IP地址和端口号，已经被其他程序或者同机的另一个socket占用了，系统不允许你重复绑定。
在EASY系列PLC上遇到这个问题，最常见的原因是：PLC程序重启的时候，上一次程序运行建立的socket连接没有正常释放，TCP的TIME_WAIT状态还没结束，你又尝试在同一个端口上监听。或者程序里做了双实例——如果你不小心把socket初始化放在了一个每个扫描周期都执行的分支里，第一次执行打开了端口，第二次再执行的时候，就提示"端口已经被占用了"。
排查思路分两步：第一步，检查程序逻辑，确认socket初始化只执行一次，通常配合一个初始化完成标志位。第二步，如果程序逻辑没问题，那就是TIME_WAIT问题，需要在断开连接后延时一段时间再重新监听，或者在初始化时设置端口重用属性，让socket允许在相同地址和端口上重新绑定。
5.2 网络状态异常的排查：连接被重置与超时无响应
连接被重置就是上位机电脑那边关闭了socket，PLC这边还在发数据，系统会返回一个RST包，收到这个包的socket就会报错。处理办法很简单：程序里检测到这个错误码，就把当前连接关闭，清空缓冲区，回到等待连接状态。
超时无响应的问题稍微隐蔽一点。上位机明明连上了，PLC发数据它也没反馈，看起来连接还"活着"，但数据就是没回声。这种情况通常是防火墙的问题——上位机电脑的防火墙拦掉了PLC发来的数据包，PLC端以为连接正常，其实数据根本没到对方应用层。
如果你在现场调试遇到"连接建立但收不到数据"的情况，先别急着改PLC程序，去查上位机电脑的防火墙设置，把对应端口的入站规则打开，或者直接关闭防火墙测试一下，往往一下就通了。
5.3 跨设备通讯字节序问题：Modbus和自定义协议都要注意
工业以太网通讯绕不开字节序问题。不同架构的CPU在内存中存多字节数据的顺序可能不一样，有的用大端（高字节在前），有的用小端（低字节在前），两者不统一，数据解读出来就是天差地别。
汇川EASY系列PLC的寄存器是16位的，存储一个32位的浮点数或32位整数，通常占用两个连续的寄存器。这里就有寄存器顺序的问题——到底低地址放高16位还是低16位，不同品牌PLC的约定可能不一样。如果你和上位机自定义协议，必须明确约定字节序，否则就会出现"数字变成天文数字"这种经典bug。
处理方式：在协议文档里明确规定多字节数据的高低位存放顺序，通信双方严格按这个规则解析。EASY系列做多字节数据拼装，往往要写一个数据处理块来做高低位字节交换，注意不要用错指令。
5.4 通讯建立后偶尔数据错位的原因分析与解决
正常通讯中偶尔出现一条数据解析错误，这类问题在socket通讯里十有八九是缓冲区处理不当或者帧边界判定不够严格。
我遇到过这种情况：上位机每次发来25字节的请求，PLC每次都按25字节去解析，但偶尔解析出来的内容是乱的。后面排查发现，上位机发送间隔不固定，两个请求相隔太近时，PLC第一次接收的缓冲区里已经存了30字节，如果程序只取前25字节解析，剩下的5字节残留在缓冲区，时间长了缓冲区里面的"残留数据+新数据"就杂乱了。
解决方式就是我4.4节说的帧尾判定法，而不是固定长度判断。如果你坚持用固定长度，那就要在解析完后强制把缓冲区里该帧剩余部分清掉，确保下一帧从头开始。
5.5 上位机调试工具选择：建议全程抓包验证
调试环节我强烈推荐大家用好抓包工具。就算你用Modbus Poll、NetAssist这类现成的socket调试助手，也建议同时开一个Wireshark抓包看看。因为调试助手显示的往往是应用层数据，而抓到的包能看到TCP层的真实交互，包括握手、确认、重传、断电重连这些底层行为。
Wireshark里抓包，最重要是设置过滤条件。如果PLC是192.168.1.10，端口是5020，抓包过滤就写成：
tcp.port == 5020 && (ip.addr == 192.168.1.10 || ip.addr == 192.168.1.20)这样过滤出来的就是PLC和上位机之间的全部TCP流量。每个包展开看，就能确认交互是否正常，是在哪个环节出的问题。
顺手还推荐一个工具：如果是电脑端调试上位机连PLC，用NetAssist这类网络调试助手就够了，界面直观，支持TCP/UDP客户端和服务端，能直接收发字符串和十六进制数据。遇到连接问题，先在电脑上用调试助手连PLC，如果助手能连上，基本排除PLC侧问题，剩下的就是上位机软件的问题。
6. 工程化落地：从测试到上线的注意事项
6.1 通信稳定性测试方法论
技术实现完了，总得上线跑，上线前稳定性测试是关键。我见过不少项目，CP联调时一切正常，一上线就各种小问题冒出来。这就是测试环节没做到位。
我用过比较稳的测试方法是：连续连续运行至少72小时的可靠性测试。期间每隔一定时间（比如5分钟）上位机读取一次PLC的特定数据区，记录数据值和时间戳，同时PLC也记录每次通讯的交互时间。测试结束后对比两边的日志，检查有没有数据丢失、通讯断线、响应超时。
过程中要主动制造异常来做故障注入测试。拔网线模拟链路断开，然后重新插上，观察PLC能不能自动恢复连接并继续正常工作；重启上位机测试强制断开时PLC的状态恢复能力；修改上位机的请求频率，测试超负荷下PLC的响应是否还会在可接受范围内。这些故障注入测试能帮你提前发现重连机制和缓冲区处理上的薄弱点。
6.2 程序防错设计的几条铁律
写EASY系列的socket程序，有几条铁律我每次都会在开工前强调给团队的同事。
第一条，socket初始化绝对不能让它在每个扫描周期都执行。一定要用初始化标志位，确保只执行一次。否则第一次扫描打开的端口还没关，第二次扫描又来绑定，直接报占用错误。
第二条，所有socket库函数的调用，都要检查返回值。EASY系列的函数一般会返回错误码，别忽略它，每个调用都根据错误码做对应的处理逻辑。有了错误码，排查问题会快很多，而且很多异常状态可以在错误码层面被提前拦截。
第三条，程序的所有固定参数，比如端口号、IP地址、缓冲区大小、心跳时间，尽量集中放到一个配置文件或者程序头部的定义区统一管理。改一个端口号就要去程序里面翻几十处？这种设计太痛苦了，集中管理能节省大量维护时间。
第四条，保持程序模块化，把socket相关功能封装成独立的功能块，通讯逻辑和业务逻辑分离。调试时只看通讯块，业务改动只改业务块，两边互相不影响。
6.3 现场交付必须具备的技术文档
上线交付时，我不光给客户一套跑通的程序，还会额外准备三份文档，这对后期维护极其关键。
第一份是通讯协议文档。明确每个数据帧的命令字、数据域定义、字节序、心跳机制、故障码含义。这份文档如果写清楚了，不管是客户的MES工程师还是你团队里接手的其他人，都能快速上手排查问题。
第二份是IP地址和端口规划表。记录现场所有设备的IP、端口、用途，包括PLC、上位机、触摸屏、连接的其他IO设备。没有这张表，现场设备多了之后就是一场灾难。
第三份是操作手册。说明如何检查PLC通讯状态，如何重启程序重新初始化socket服务，如何查看通讯错误码对应的含义。别让客户遇到问题就打电话找你，给一份能自助排障的手册，大家都轻松。
7. 技术细节补充：从EASY扩展到其他PLC和场景
7.1 汇川其他系列PLC做socket从站的差异点
如果你之后在AM系列、AC系列这些更高端的汇川PLC上做socket从站，思路类似，但库函数名称和参数细节会有差异。高端系列的可视化调试能力更强，可以看到更详细的socket状态信息，而且支持的socket连接数和缓冲区大小都有提升。
另外，如果你要把EASY系列放到Modbus TCP的从站模式，其实不需要自己写socket——EASY系列本身支持Modbus TCP从站功能，在系统参数里启用即可，底层协议栈和socket对接是处理好的。但如果你要自定义协议，就需要自己用socket函数实现，这就是本文讲的内容。
7.2 触摸屏与PLC的以太网通讯参考
一些热搜词里提到了mt8072ie与fx5uj的以太网通讯，虽然那是威纶通触摸屏和三菱PLC的组合，但在做汇川EASY项目时也会遇到类似需求：需要触摸屏和PLC走以太网而不是传统的串口线。
触摸屏连接EASY系列，可以通过Modbus TCP：EASY系列开启Modbus TCP从站，威纶通触摸屏在设备列表里选择对应的驱动，填好PLC的IP地址，连接就建立了，不需要你在触摸屏端写任何socket脚本。如果触摸屏需要发的数据格式比较特殊，比如自定义协议，那就要在触摸屏的宏指令里写socket脚本，本质上和本文讲的socket编程是一样的思路。
7.3 多PLC数据汇聚与边缘网关
最后扩展一点我想特别提的：当现场有多台汇川EASY系列PLC时，你可以用socket通讯把数据汇聚到一个边缘计算网关或者一台工控机上，由网关统一处理和转发给MES。这种方式比每台PLC都直接对接MES更加灵活，也更符合现代工厂"边缘层集中采集、云端统一分析"的架构思路。
每台PLC作为socket从站，监听同一个端口，上位机（网关或工控机）作为socket客户端，主动去连接每一台PLC。采集程序里用多线程分别管理各条连接，把不同PLC采集到的数据打上标签后统一上传。这个架构的好处是，新增一台PLC，只需要在网关的配置文件中加一条IP记录就行，对现有系统的影响几乎为零。
8. 扩展思考：socket从站方案的边界与选型
写到这里，最后分享一点个人在项目选型时的心得。每次拿到通讯需求，我会先做一次"方案边界"评估，问自己三个问题：数据量多大？实时性要求多高？通讯拓扑是点对点还是多对多？
如果数据量小、交互次数少、对响应时间没有硬性要求（几十毫秒到百毫秒都可以接受），用EASY系列的socket从站是完全可行的，而且成本最低。如果响应时间要求苛刻，比如从站数据要在5ms以内送达到上位机，那建议升级到EtherCAT或者专门的数据采集网关，因为PLC的扫描周期和socket处理机制决定了它难以保证极低延迟。
如果有多台设备要协同通讯，比如两台PLC之间要做实时数据交换，EASY系列的socket通讯也够用，前提是你自己把通讯调度逻辑处理好。但如果实时性要求到了运动控制那种级别，那就要换EtherCAT总线方案了——这里顺便多说一句，EtherCAT和socket是两条完全不同的技术路线，千万别拿来做错误的替换。
工具选型对了，后面写程序省一半力气。我们这次选型时就是先做了需求评估，确认了是"低压量、低频率、点对点"的数据采集需求，才决定用EASY系列自身的socket能力实现。实际上线之后，稳定跑了几个月，一次通信故障都没发生，说明这条路是走得通的。
