进程间通信与网络通信选型：管道与TCP实战

1. 进程间通信与网络通信的选型思考

进程间通信和网络通信这两个话题，乍一看像是教科书里的老生常谈，但真正在项目里落地的时候，坑一点都不少。我最近在做一个本地数据处理工具，需要让主控进程和几个工作进程之间高效交换数据，同时还要让同一局域网内的另一台机器能够远程查看处理进度。这个需求拆开来看其实很清晰：本机内部走进程间通信，跨机器走网络通信。但具体用什么方案，我前后试了三种组合，最后才定下来用管道加TCP这套搭配。

先说为什么不用共享内存。共享内存确实是本机进程间通信里速度最快的方式，没有之一，数据不需要在用户态和内核态之间来回拷贝。但它的问题也很明显：同步机制得自己实现。你得配一套信号量或者互斥锁来防止读写冲突，稍不注意就是数据竞争，调试起来非常痛苦。我之前的项目里就踩过这个坑，两个进程同时往同一块共享内存写数据，结果读出来的内容一半是A的一半是B的，排查了大半天才发现是同步没做好。对于我这种数据量不算特别大、但对开发效率要求高的场景来说，共享内存的复杂度有点得不偿失。

再说为什么不用消息队列。消息队列的好处是解耦彻底，发送方和接收方完全不需要知道对方的存在，通过一个中间层来传递消息。但它的开销比管道大，每条消息都要经过内核的队列管理，而且消息大小有限制。更关键的是，消息队列的API相对繁琐，要管理消息类型、优先级这些东西。我的场景里数据流向很固定，就是主进程分发任务、工作进程回传结果，用消息队列有点杀鸡用牛刀的意思。

最后选管道，核心原因是它足够简单直接。管道本质上就是内核里的一块缓冲区，两个进程各拿一端，一个写一个读，天然就是流式的。匿名管道用于有亲缘关系的进程之间，命名管道可以让任意两个本机进程通信。我的场景里主进程fork出工作进程，正好是父子关系，匿名管道完美适配。数据像水流一样从一端到另一端，不需要关心消息边界，读多少写多少都很灵活。

至于局域网通信选TCP而不是UDP，这个决策相对直接。UDP虽然快，但它不保证送达、不保证顺序，对于进度查看这种场景来说，丢一个包可能就意味着进度显示卡住不动了。TCP有重传机制、有流量控制、有拥塞控制，虽然开销大一点，但可靠性有保障。而且TCP是面向连接的，建立连接之后就是一条稳定的字节流通道，编程模型比UDP简单得多。局域网内延迟本来就低，TCP的那些额外开销在这个场景下几乎可以忽略不计。

提示：选型的时候不要只看性能指标，要把开发成本、维护成本、调试难度都算进去。一个跑得快但天天出bug的方案，不如一个跑得稳但稍慢的方案。

这套组合方案的整体思路是这样的：主进程创建管道，fork出工作进程，工作进程通过管道把处理结果传回主进程；主进程同时监听一个TCP端口，局域网内的客户端连上来之后，主进程把汇总的进度信息通过TCP连接推送出去。整个架构里，管道负责本机内部的高效数据流转，TCP负责跨机器的可靠传输，各司其职，互不干扰。

2. 管道通信的核心原理与实操细节

2.1 匿名管道的工作机制

匿名管道是Unix/Linux系统里最古老的进程间通信方式之一，但它的设计思路至今仍然非常实用。管道在内核中表现为一个环形缓冲区，通常大小是64KB，这个值可以通过fcntl的F_SETPIPE_SZ来调整。两个进程分别持有读端和写端的文件描述符，写进程往写端fd里写数据，数据进入内核缓冲区，读进程从读端fd里读数据，数据从缓冲区里出来。

这里有一个关键点很多人一开始会搞混：管道是单向的。也就是说，如果两个进程需要双向通信，你得创建两个管道，一个负责A到B，另一个负责B到A。我第一次用管道的时候就犯过这个错误，以为一个管道可以双向读写，结果发现数据全乱了。后来才明白，管道的读端和写端是固定的，你不能拿写端去读数据。

管道的读写行为有几个重要的特性需要记住。第一，当读端关闭而写端还在写的时候，写进程会收到SIGPIPE信号，默认行为是进程终止。这个信号很讨厌，因为如果你的程序没有处理它，整个进程就悄无声息地挂了。我一般会在程序开头加上signal(SIGPIPE, SIG_IGN)来忽略这个信号，然后在写操作返回EPIPE错误的时候再做相应处理。第二，当写端关闭而读端还在读的时候，读操作会返回0，表示文件结束。这个特性可以用来通知读进程数据已经发完了。第三，如果管道缓冲区满了，写操作会阻塞，直到有空间可写；如果缓冲区空了，读操作会阻塞，直到有数据可读。这种阻塞特性在大多数场景下是好事，因为它天然实现了流量控制，你不需要自己去实现等待逻辑。

2.2 创建和使用管道的完整流程

创建匿名管道的系统调用是pipe()，它接收一个包含两个整数的数组，调用成功后数组的第一个元素是读端fd，第二个元素是写端fd。这个调用必须在fork之前执行，这样父子进程才能共享这两个文件描述符。

int pipefd[2]; if (pipe(pipefd) == -1) { perror("pipe"); exit(EXIT_FAILURE); } pid_t pid = fork(); if (pid == 0) { // 子进程：关闭读端，只负责写 close(pipefd[0]); // 往pipefd[1]写数据 write(pipefd[1], "hello", 5); close(pipefd[1]); exit(EXIT_SUCCESS); } else { // 父进程：关闭写端，只负责读 close(pipefd[1]); char buf[256]; ssize_t n = read(pipefd[0], buf, sizeof(buf)); // 处理读到的数据 close(pipefd[0]); wait(NULL); }

这段代码看起来简单，但有几个细节值得展开说。首先是关闭不需要的文件描述符。子进程不需要读端，父进程不需要写端，如果不关闭的话，会导致文件描述符泄漏，更严重的是会影响管道的EOF判断。因为管道的读端只有在所有持有该fd的进程都关闭之后才会返回0，如果父进程不关闭自己的写端，那么即使子进程写完了并关闭了它的写端，父进程的读操作仍然不会返回0，会一直阻塞下去。这个坑我在早期项目中踩过，程序卡死在那里，查了半天才发现是fd没关干净。

其次是write和read的返回值处理。write可能只写入部分数据，特别是在数据量大的时候。你不能假设一次write调用就能把所有数据写完，必须在一个循环里反复写，直到所有数据都写出去。read同理，可能只读到部分数据，需要循环读取直到满足需求或者遇到EOF。

// 可靠的写入函数 ssize_t write_all(int fd, const void *buf, size_t count) { const char *ptr = (const char *)buf; size_t remaining = count; while (remaining > 0) { ssize_t n = write(fd, ptr, remaining); if (n == -1) { if (errno == EINTR) continue; // 被信号中断，重试 return -1; } ptr += n; remaining -= n; } return count; }

2.3 命名管道解决非亲缘进程通信

匿名管道只能用于有亲缘关系的进程，比如父子进程或者兄弟进程。如果两个进程完全没有关系，比如一个是系统服务，另一个是用户手动启动的工具，那就需要用命名管道，也叫FIFO。

命名管道在文件系统里表现为一个特殊文件，用mkfifo()创建。创建之后，任何进程都可以像打开普通文件一样打开它，然后进行读写。但要注意，打开FIFO的时候会阻塞，直到另一端也被打开。比如一个进程以只读方式打开FIFO，它会阻塞在那里，直到另一个进程以只写方式打开同一个FIFO。这个特性有时候很有用，可以当作进程间的同步点，但如果不注意的话也会导致程序卡住。

// 创建命名管道 if (mkfifo("/tmp/my_fifo", 0666) == -1) { if (errno != EEXIST) { perror("mkfifo"); exit(EXIT_FAILURE); } } // 写入端 int fd = open("/tmp/my_fifo", O_WRONLY); write(fd, "data", 4); close(fd); // 读取端 int fd = open("/tmp/my_fifo", O_RDONLY); char buf[256]; read(fd, buf, sizeof(buf)); close(fd);

命名管道的一个常见用途是作为简单的任务队列。多个工作进程同时从FIFO里读任务，内核会保证每个任务只被一个进程读到，天然实现了负载均衡。不过这种方式的灵活性有限，任务的分发策略没法精细控制，适合对调度要求不高的场景。

注意：命名管道文件在程序退出后不会自动删除，需要在程序里显式调用unlink()清理，或者在启动脚本里做清理。否则下次启动时mkfifo会返回EEXIST错误。

2.4 管道在实际项目中的性能表现

我在项目里做了一个简单的性能测试，对比管道和本地socket的吞吐量。测试方法是父进程通过管道向子进程发送1MB的数据块，重复100次，测量总耗时。测试环境是一台普通的开发机，Linux内核版本5.x。

从数据可以看出，管道的吞吐量明显高于Unix域socket和TCP回环。原因在于管道的内核实现更简单，没有socket层的协议处理开销。当然这个测试比较粗糙，实际性能还会受到缓冲区大小、数据块大小、系统负载等因素的影响。但趋势是明确的：在本机进程间通信这个场景下，管道是性能最好的选择之一。

不过管道也有它的局限性。管道是字节流，没有消息边界的概念。如果你发送了两条消息，接收端可能一次读到两条消息的内容，也可能分两次读到一条消息的一半。解决这个问题通常有两种做法：一种是在消息前面加长度前缀，接收端先读长度再读内容；另一种是约定一个分隔符，比如换行符，接收端按分隔符切分。我一般用长度前缀的方式，更可靠，也不怕消息内容里包含分隔符。

3. TCP局域网通信的实现要点

3.1 TCP服务端的设计与实现

TCP服务端的基本流程是：创建socket、绑定地址、监听端口、接受连接、收发数据、关闭连接。这个流程看起来简单，但每个步骤都有不少细节需要注意。

创建socket的时候，socket()函数的第一个参数是地址族，局域网通信用AF_INET；第二个参数是套接字类型，用SOCK_STREAM表示TCP；第三个参数是协议，通常传0让系统自动选择。返回的是一个文件描述符，后续所有操作都通过这个fd来进行。

绑定地址的时候，bind()函数需要一个sockaddr_in结构体，里面包含地址族、端口号和IP地址。这里有一个关键选择：绑定到哪个IP。如果绑定到INADDR_ANY，也就是0.0.0.0，表示监听所有网络接口，局域网内任何机器都可以连接。如果绑定到具体的IP，比如192.168.1.100，那就只监听那个接口。我一般用INADDR_ANY，这样更灵活，不需要关心机器具体是哪个IP。

int server_fd = socket(AF_INET, SOCK_STREAM, 0); if (server_fd == -1) { perror("socket"); exit(EXIT_FAILURE); } // 设置SO_REUSEADDR，避免重启时端口被占用 int opt = 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(8888); if (bind(server_fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) { perror("bind"); exit(EXIT_FAILURE); } if (listen(server_fd, 5) == -1) { perror("listen"); exit(EXIT_FAILURE); }

SO_REUSEADDR这个选项非常重要。没有它的话，服务器程序退出后，端口会处于TIME_WAIT状态，通常要等几十秒才能重新绑定。加上这个选项之后，可以立即重用端口，开发调试的时候能省不少时间。

listen()的第二个参数是backlog，表示等待accept的连接队列的最大长度。这个值不需要设得太大，一般5到10就够了。设太大反而会占用不必要的内存。当队列满了之后，新的连接请求会被拒绝或者忽略，具体行为取决于系统实现。

3.2 处理多个客户端连接

服务端需要同时处理多个客户端的连接，这就涉及到并发模型的选择。最简单的做法是每来一个连接就fork一个子进程，子进程专门负责和这个客户端通信。这种模型简单可靠，一个客户端出问题不会影响其他客户端。但进程的开销比较大，如果客户端数量多的话，系统资源会吃紧。

另一种做法是用多线程，每个连接一个线程。线程比进程轻量，创建和切换的开销都小很多。但线程共享地址空间，一个线程崩溃可能导致整个进程挂掉，需要更小心地处理错误。而且多线程编程本身就有一定的复杂度，数据竞争、死锁这些问题都需要注意。

我最终选的是I/O多路复用，具体来说是epoll。epoll是Linux特有的机制，可以同时监控大量的文件描述符，当某个fd上有事件发生时，内核会通知应用程序。这样只需要一个线程就能处理所有连接，没有进程或线程切换的开销，效率非常高。

int epfd = epoll_create1(0); struct epoll_event ev, events[64]; ev.events = EPOLLIN; ev.data.fd = server_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev); while (1) { int nfds = epoll_wait(epfd, events, 64, -1); for (int i = 0; i < nfds; i++) { if (events[i].data.fd == server_fd) { // 有新连接 int client_fd = accept(server_fd, NULL, NULL); ev.events = EPOLLIN; ev.data.fd = client_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev); } else { // 客户端有数据可读 char buf[1024]; ssize_t n = read(events[i].data.fd, buf, sizeof(buf)); if (n <= 0) { // 连接关闭或出错 epoll_ctl(epfd, EPOLL_CTL_DEL, events[i].data.fd, NULL); close(events[i].data.fd); } else { // 处理数据 } } } }

epoll的使用有几个要点。epoll_create1()创建一个epoll实例，返回一个fd。epoll_ctl()用来添加、修改或删除要监控的fd。epoll_wait()阻塞等待事件发生，返回事件的数量。事件数组的大小决定了每次最多返回多少个事件，设得太小会导致频繁调用，设得太大浪费内存，一般64到1024之间比较合适。

提示：epoll有两种触发模式，水平触发（LT）和边缘触发（ET）。默认是LT模式，只要fd上有数据可读，每次epoll_wait都会返回。ET模式只在状态变化时通知一次，必须一次把数据读完，否则会丢失事件。ET模式效率更高但编程更复杂，新手建议先用LT模式。

3.3 TCP数据收发的可靠性处理

TCP虽然保证了数据的可靠传输，但应用程序层面的读写仍然需要处理一些边界情况。最典型的就是粘包和拆包问题。TCP是字节流协议，不保留消息边界。发送端连续发送两条消息，接收端可能一次收到两条消息的全部内容，也可能第一条消息只收到一半。这不是TCP的bug，而是它的设计特性。

解决粘包问题的标准做法是在消息前面加一个固定长度的头部，头部里包含消息体的长度。接收端先读固定长度的头部，解析出消息体长度，然后再读相应长度的消息体。这样就能准确地把字节流切分成一条条独立的消息。

// 发送消息：4字节长度前缀 + 消息体 void send_message(int fd, const char *msg, uint32_t len) { uint32_t net_len = htonl(len); write_all(fd, &net_len, 4); write_all(fd, msg, len); } // 接收消息 int recv_message(int fd, char *buf, uint32_t buf_size) { uint32_t net_len; ssize_t n = read_all(fd, &net_len, 4); if (n != 4) return -1; uint32_t len = ntohl(net_len); if (len > buf_size) return -1; n = read_all(fd, buf, len); if (n != (ssize_t)len) return -1; return len; }

这里用htonl和ntohl来做网络字节序和主机字节序的转换。网络协议规定使用大端字节序，而x86架构的机器是小端字节序，所以必须转换。如果不转换的话，在不同架构的机器之间通信就会出错。虽然局域网内通常都是同一种架构，但养成转换的习惯没坏处。

read_all和write_all这两个辅助函数是必须的，因为read和write系统调用都可能返回部分结果。特别是在网络环境下，数据包可能被分片，一次read调用很可能读不到完整的数据。必须循环读取，直到读满需要的字节数或者遇到错误。

3.4 局域网连接的建立与维护

局域网内两台机器要建立TCP连接，客户端需要知道服务端的IP地址和端口号。IP地址可以通过ifconfig或者ip addr命令查看，端口号是服务端程序自己指定的。客户端调用connect()函数发起连接请求，服务端accept()接受连接，三次握手完成后连接就建立了。

// 客户端连接 int sock = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in serv_addr; serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(8888); inet_pton(AF_INET, "192.168.1.100", &serv_addr.sin_addr); if (connect(sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) == -1) { perror("connect"); exit(EXIT_FAILURE); }

inet_pton函数把点分十进制的IP地址字符串转换成二进制形式。相比老旧的inet_addr函数，inet_pton支持IPv6，而且错误处理更清晰。

连接建立之后，需要处理连接断开的情况。TCP连接可能因为网络故障、对方程序退出、超时等原因断开。应用程序需要能够检测到这些情况并做出相应处理。检测的方法通常是看read或write的返回值：返回0表示对方关闭了连接，返回-1且errno是ECONNRESET表示连接被重置，返回-1且errno是EPIPE表示对方已经关闭了读端。

为了保持连接活跃，可以设置SO_KEEPALIVE选项，让内核定期发送探测包。但内核默认的探测间隔是2小时，对于实时性要求高的场景来说太长了。更好的做法是在应用层实现心跳机制，客户端定期发送心跳包，服务端如果在指定时间内没有收到心跳就认为连接已断开。

// 设置TCP keepalive参数 int keepalive = 1; setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive)); int keepidle = 60; // 60秒没有数据往来就开始探测 int keepintvl = 10; // 探测间隔10秒 int keepcnt = 3; // 连续3次探测无响应就断开 setsockopt(sock, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle)); setsockopt(sock, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl)); setsockopt(sock, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));

这几个参数需要根据实际场景调整。如果网络环境比较稳定，可以放宽一些；如果网络抖动比较大，可以收紧一些。但也不要太激进，否则正常的网络波动可能导致连接被误判断开。

4. 管道与TCP的协同工作与问题排查

4.1 整体架构的数据流设计

把管道和TCP放在一起用的时候，数据流的设计需要仔细考虑。我的项目里，主进程负责协调所有工作，它同时管理着管道和TCP连接。工作进程通过管道把处理结果发给主进程，主进程汇总之后通过TCP推送给远程客户端。

具体的数据流是这样的：主进程启动时创建管道和TCP监听socket，然后fork出N个工作进程。每个工作进程继承管道的写端，关闭读端。主进程保留管道的读端，关闭写端。工作进程处理完一个任务后，把结果写入管道。主进程通过epoll同时监控管道读端和TCP连接，当管道有数据可读时，读取数据并更新内部状态；当TCP连接有数据可读时，处理客户端的请求。

这里有一个关键的设计决策：主进程用同一个epoll实例来监控管道和TCP socket。这样做的好处是只需要一个事件循环，代码结构清晰，不会出现多个线程竞争的问题。管道读端和TCP socket在epoll眼里没有区别，都是文件描述符，都可以注册事件。

// 把管道读端加入epoll struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = pipefd[0]; epoll_ctl(epfd, EPOLL_CTL_ADD, pipefd[0], &ev); // 把TCP监听socket加入epoll ev.data.fd = server_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);

这种统一事件循环的设计让代码简洁了很多。不需要为管道单独开一个线程去读，也不需要为TCP单独开一个线程去accept。所有的事件都在一个循环里处理，逻辑清晰，调试也方便。

4.2 数据格式的统一与转换

管道里传的是二进制数据，TCP上传的也是二进制数据，但两者的格式可能不一样。管道是本机通信，可以直接传结构体的二进制形式，不需要考虑字节序问题。TCP是网络通信，必须考虑字节序，而且不同平台的类型长度可能不同，需要做序列化。

我的做法是在管道里传一个简单的结构体，包含任务ID、状态码和结果数据。在TCP上则用JSON格式，因为JSON是文本协议，跨平台兼容性好，调试的时候也方便看。主进程收到管道里的二进制数据后，转换成JSON格式再通过TCP发出去。

// 管道里传输的结构体 struct task_result { uint32_t task_id; int32_t status; char data[256]; }; // 转换成JSON发送 void send_result_as_json(int client_fd, struct task_result *result) { char json[512]; snprintf(json, sizeof(json), "{\"task_id\":%u,\"status\":%d,\"data\":\"%s\"}", result->task_id, result->status, result->data); send_message(client_fd, json, strlen(json)); }

这个转换过程看起来多了一步，但带来的好处是远程客户端可以用任何语言来解析数据，不限于C语言。而且JSON格式人类可读，出问题的时候直接看日志就能定位。

4.3 常见问题与排查技巧

在实际开发和运行过程中，我遇到了一些典型问题，这里整理成速查表，方便遇到类似情况时快速定位。

除了这些常见问题，还有一些不那么明显但很坑的情况。比如管道缓冲区满了导致写阻塞，如果读端处理速度跟不上写端，写端就会一直阻塞在那里。这种情况下需要检查读端的处理逻辑是否有性能瓶颈，或者考虑增大管道缓冲区。

另一个坑是TCP的Nagle算法。这个算法会把小数据包攒起来一起发，减少网络上的小包数量。听起来是好事，但在某些交互式场景下会导致明显的延迟。比如客户端发一个请求，服务端回一个响应，如果响应数据很小，Nagle算法可能会等一会儿再发，导致客户端感觉卡顿。解决办法是设置TCP_NODELAY选项禁用Nagle算法。

int nodelay = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &nodelay, sizeof(nodelay));

注意：禁用Nagle算法会增加网络上的小包数量，如果应用本身发送大量小数据包，可能会加重网络负担。需要根据实际场景权衡。

4.4 性能调优与稳定性保障

性能调优方面，管道的缓冲区大小是一个可以调整的参数。默认的64KB对于大多数场景够用，但如果数据量特别大，可以适当增大。在Linux上可以用fcntl的F_SETPIPE_SZ来设置，但要注意这个操作需要相应的权限，而且设置的值会被系统向上取整到页大小的整数倍。

int pipe_size = fcntl(pipefd[1], F_SETPIPE_SZ, 1024 * 1024); if (pipe_size == -1) { perror("fcntl F_SETPIPE_SZ"); }

TCP方面，可以调整发送缓冲区和接收缓冲区的大小。SO_SNDBUF和SO_RCVBUF这两个选项分别控制发送和接收缓冲区。增大缓冲区可以提高吞吐量，特别是在高延迟的网络环境下。但也不是越大越好，缓冲区太大会增加内存占用，而且可能导致延迟增加。

int sndbuf = 256 * 1024; int rcvbuf = 256 * 1024; setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &sndbuf, sizeof(sndbuf)); setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));

稳定性方面，最重要的是错误处理。每一个系统调用都可能失败，不能假设它们总是成功。socket可能因为文件描述符耗尽而失败，bind可能因为端口被占用而失败，accept可能因为连接队列满而失败。这些错误都需要妥善处理，该重试的重试，该报错的报错，该清理的清理。

资源泄漏也是常见问题。每个打开的fd都需要在不再使用时关闭，每个分配的内存都需要释放。在长时间运行的服务里，哪怕每次只泄漏一点点，积累下来也会导致严重问题。我一般会用valgrind来检查内存泄漏，用lsof来检查fd泄漏。

# 检查进程的fd数量 ls /proc/<pid>/fd | wc -l # 用valgrind检查内存泄漏 valgrind --leak-check=full ./my_program

日志记录也很重要。关键的操作、错误、状态变化都应该记日志。日志不用太详细，但至少要能看出程序在做什么、哪里出了问题。我习惯在日志里加上时间戳和进程ID，这样多进程环境下也能分清楚是哪个进程打的日志。

这套管道加TCP的方案，我在项目里跑了几个月，整体表现很稳定。管道的吞吐量足够应付本机的数据交换，TCP的可靠性也经受住了局域网环境的考验。中间遇到过几次连接断开的情况，都是网络波动引起的，心跳机制检测到之后自动重连，没有影响到整体功能。后来我又把TCP部分加上了TLS加密，虽然局域网内安全性要求没那么高，但多一层保护总归是好的。