简介一套基于 Windows 平台、使用 Visual Studio 2013 编写的 Socket TCP 通信示例工程面向具备 C 基础、希望从单机练习过渡到网络编程实战的开发者。它要解决的核心问题是服务端如何同时接入多个客户端并把一条消息广播给全部在线连接可对照实现类似 QQ 群聊的实时通讯场景。压缩包共 58 个文件、约 16.42MB除 cpp 与 h 源码以及 sln、vcxproj 工程配置外还保留了 exe 可执行文件、pdb 调试符号、obj 与 ilk 中间产物和 tlog 编译日志这些内容既能直接运行以观察效果也能在 IDE 中重新编译调试。已有 513 人学习。工程内含服务端监听与并发处理、客户端连接管理、消息群发以及文件二进制流传输等模块读者可据此理解 TCP 连接建立、多线程收发与广播逻辑也可在此基础上扩展加密传输和聊天室功能对课程设计与自学网络编程都有较直接的参考价值。1. 四十台机器同时在线这套 TCP 通信方案到底要解决什么一个机房四十台机器同时连上来服务端要在两秒内把一条通知推给所有人还得随时知道谁掉线了——这是「Windows 服务端 多客户端 Socket TCP 通信」最原始的需求描述也是大多数课程设计和毕业设计里真正卡人的地方。真正难的地方在于连接断了怎么发现、消息粘在一起怎么切开、群发时一个客户端卡住会不会拖垮整条广播链路Socket.Connect那一行从来不是难点。这套方案给出的做法是自定义长度前缀帧协议 服务端会话表 每会话独立发送队列 客户端收发分离与退避重连四个部分各自独立又互相呼应。它适合要交一份完整通信课设的学生也适合需要在局域网内做消息分发、设备状态上报、上位机广播的从业者直接改。2. 协议与并发模型长度前缀帧和每会话发送队列怎么定TCP 提供的是字节流不是消息流。这一条如果没在动手前想清楚后面写出来的代码一定会在某个下午突然出错本地跑得好好的一上真实网络中文消息就变成半句。所以协议和并发模型必须最先定定完再写业务这部分最终省下来的返工时间比什么都值。2.1 消息边界长度前缀帧怎么切三种常见切法里只有一种能长期使用。用\n或|做分隔符最省事但正文里只要出现同样的字符整条链路当场失效定长包不会串但一条“收到”也要占满 512 字节带宽浪费得离谱长度前缀把“这一帧有多长”明明白白写在帧头接收方按长度取取不够就等下一次Read多出来的留给下一帧。多客户端场景下这是唯一不需要额外约定的做法。using System; using System.Buffers.Binary; using System.Text; public static class Frame { // 帧头 4 字节正文长度大端 1 字节消息类型 public const int HeaderSize 5; public const int MaxBodyLength 64 * 1024; // 单帧正文上限挡住异常大包撑爆内存 public static byte[] Encode(byte type, string text) { byte[] body Encoding.UTF8.GetBytes(text ?? string.Empty); if (body.Length MaxBodyLength) throw new ArgumentException(正文超过单帧上限); byte[] frame new byte[HeaderSize body.Length]; BinaryPrimitives.WriteInt32BigEndian(frame.AsSpan(0, 4), body.Length); frame[4] type; // 消息类型放在长度之后 Buffer.BlockCopy(body, 0, frame, HeaderSize, body.Length); return frame; } // 从累积缓冲区里尝试取出一帧不够一帧返回 false等下次 Read public static bool TryDecode(byte[] buffer, ref int offset, int count, out byte type, out string text) { type 0; text null; if (count - offset HeaderSize) return false; // 帧头都没收全 int bodyLen BinaryPrimitives.ReadInt32BigEndian(buffer.AsSpan(offset, 4)); if (bodyLen 0 || bodyLen MaxBodyLength) throw new InvalidDataException(帧长度非法应主动断开该连接); if (count - offset - HeaderSize bodyLen) return false; // 正文还没收全 type buffer[offset 4]; text Encoding.UTF8.GetString(buffer, offset HeaderSize, bodyLen); offset HeaderSize bodyLen; // 游标前移支持一次读多帧 return true; } }offset是这个设计的核心它让一个缓冲区可以连续吐出多帧一次Read可能收到半帧也可能收到三帧半TryDecode循环调用直到返回false剩下的半帧原样留在缓冲区等下一轮。长度统一按字节算而不是按字符算string.Length在中文字符串上给出的是字符数用它当长度写进帧头接收方一定切错位这是乱码问题里最常见的一种。大端写入是为了跨语言调试时对照抓包数据不费劲自己两端都用 C# 其实小端也行但一旦以后要接个 Python 脚本做压测统一大端更省事。消息类型用一字节编码一张表定死就不要再改类型值名称方向正文格式说明1LoginC→S昵称上线首帧服务端绑定会话2BroadcastC→S→C聊天正文群发服务端转发给除发送者外所有人3PrivateC→S→C目标会话ID|正文点对点消息4HeartbeatC→S空15 秒一次不参与业务5OnlineListS→Cid,nick;id,nick有人上线或下线时群发6SystemS→C提示文字超时踢人、服务端关闭通知注意MaxBodyLength不是随便填的数字。它决定单条消息的上限也决定接收缓冲区的最小尺寸取值小于实际业务消息会在发送端抛异常取值过大一个异常连接就能让你内存增长。2.2 并发模型一线程一连接还是异步小规模局域网项目里这个选择其实没有标准答案但有明确的边界。一线程一连接写起来最直观四十个客户端就是四十个线程接收、处理、发送全在一个线程里顺着写调试时断点一打就知道卡在哪代价是每个线程默认占 1MB 栈空间且线程切换在连接数上去以后开始拖慢响应。Select模型在 Windows 上还有个历史限制FD_SETSIZE默认只有 64接第 65 个客户端直接失败这个坑不少人遇到过。异步模型是更耐久的选择。每个连接一个Task接收用ReadAsync发送交给独立的发送循环线程池负责调度四十个连接和四百个连接在代码形态上没有任何区别。代价是异常会被吞进Task里async void一用就等着排查一整晚。所以这套方案在异步的基础上再加一层每个会话配一个独立的发送队列和发送循环。这一层的价值在群发时才体现出来。如果所有连接共用一个发送逻辑某个客户端网络卡住WriteAsync迟迟不返回整条广播链路就堵在这里其余客户端全都收不到消息——这就是典型的“一个慢客户端拖垮全服”。改成每个会话一个容量 256 的有界队列群发只负责往队列里塞真正的WriteAsync由各自的发送循环执行谁慢谁自己慢队列满了就说明这个客户端已经跟不上直接摘掉不影响别人。2.3 心跳与超时别指望 TCP KeepAlive服务端的在线列表和真实连接对不上十有八九是这里没做。TCP 自带的 KeepAlive 在 Windows 上默认空闲两小时才开始探测对课堂演示来说等于没有更麻烦的是拔网线、断电、直接杀进程这几种情况对端根本发不出 FIN服务端看到的连接永远是“已建立”。应用层心跳是唯一可靠的办法客户端每 15 秒发一个类型 4 的空帧服务端每次收到任何帧就更新该会话的LastActiveUtc另起一个扫描任务每 10 秒跑一次超过 45 秒没动静的直接清理并群发新的在线列表。// 服务端每 10 秒扫一次超过 45 秒没有任何帧的会话直接清理 private void SweepIdleSessions() { DateTime deadline DateTime.UtcNow.AddSeconds(-45); Session[] snapshot; lock (_sync) { snapshot _sessions.Values.ToArray(); } // 锁内只做拷贝 foreach (Session s in snapshot) if (s.LastActiveUtc deadline) CloseSession(s, 心跳超时); // 锁外做关闭避免长时间持锁 }三个参数的关系要记住客户端心跳间隔必须明显小于服务端超时阈值一般取三分之一左右。15 秒发一次、45 秒判超时意味着允许连续丢两次心跳短暂网络抖动不会误踢如果心跳 30 秒发一次、超时也设 30 秒那每次网络稍微延迟一下就会误判用户会看到自己莫名其妙被踢下线然后重连再被踢。3. 服务端核心监听循环、会话表与群发链路的实现服务端要做的只有四件事接住连接、记住谁在线、把消息正确转出去、把断掉的连接清理干净。下面四小节按这个顺序拆开每一段都能直接放进项目里跑起来。3.1 监听与接入Accept 循环怎么写才不卡监听本身不复杂容易出问题的是“接住之后怎么办”。有人把业务处理直接写在 Accept 循环里第一个客户端连上以后发一条长消息服务端就再也接不了第二个人了。private async Task AcceptLoopAsync(CancellationToken token) { var listener new TcpListener(IPAddress.Any, 9527); listener.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); // 重启时避开 TIME_WAIT 导致的端口占用 listener.Start(backlog: 128); // 半连接队列客户端集中上线时别用默认值 while (!token.IsCancellationRequested) { TcpClient client; try { client await listener.AcceptTcpClientAsync(); } catch (ObjectDisposedException) { break; } // 正常停止监听 catch (SocketException ex) { Log($接入失败{ex.SocketErrorCode}); continue; } client.NoDelay true; // 关掉 Nagle控制类小消息不要攒 _ HandleClientAsync(client, token); // 每个连接一个独立任务绝不 await } listener.Stop(); }_ HandleClientAsync(...)这一行是整段的关键不await接入循环立刻回到AcceptTcpClientAsync等下一个连接。代价是这个任务的异常没人接所以HandleClientAsync内部必须整体包一层try/catch/finallyfinally里做会话清理。NoDelay打开是因为心跳和通知这类消息体很小Nagle 算法会攒着等凑够一定量再发表现为“消息发出去要等几百毫秒才到”在演示现场显得特别难解释。backlog: 128是半连接队列长度。四十台机器在开机脚本里同时连瞬时会有几十个 SYN 挤在队列里队列短了就会出现连接被拒。这个值不用调得特别大但默认值在集中上线时确实不够。3.2 会话表字典 单锁锁内不做网络 IO会话表用一个Dictionaryint, Session就够键用自增 ID 而不是昵称因为昵称会重名、会改ID 不会。所有对字典的增删查都用同一把锁保护这点不要图省事用ConcurrentDictionary然后到处TryGetValue——省下来的那点性能在几十个连接的量级上完全体现不出来反而会让“谁在什么时候改过这张表”变得难以追踪。public sealed class Session { public int Id { get; } public string UserName { get; set; } public DateTime LastActiveUtc { get; set; } private readonly TcpClient _client; private readonly NetworkStream _stream; // 每个会话一条有界发送队列满了说明这个客户端消费不过来直接丢弃并摘除 private readonly Channelbyte[] _sendQueue Channel.CreateBoundedbyte[]( new BoundedChannelOptions(256) { FullMode BoundedChannelFullMode.DropWrite }); public Session(int id, TcpClient client) { Id id; _client client; _stream client.GetStream(); LastActiveUtc DateTime.UtcNow; } public bool TryEnqueue(byte[] frame) _sendQueue.Writer.TryWrite(frame); // 整个会话只有这一个循环写 socket天然不会出现两条消息交错 public async Task SendLoopAsync(CancellationToken token) { await foreach (byte[] frame in _sendQueue.Reader.ReadAllAsync(token)) await _stream.WriteAsync(frame, token); } }“单写者”这个约束值得单独强调。Socket 的Send在多个线程同时调用时不能保证两条消息整体先后很可能出现 A 消息的前 10 字节接了 B 消息的后 20 字节客户端解出来就是一堆乱码——这种问题偶发、难复现属于典型的需要长时间排查的问题。把写操作收敛到一个循环里从结构上就不存在这个可能。BoundedChannelFullMode.DropWrite是明确的取舍队列满意味着这个客户端已经积压了 256 帧还没发完再往里塞只会让内存继续涨不如丢掉这一帧并把它标记为待清理。3.3 群发链路快照遍历、失败剔除与入队计数群发的代码只有十几行但几乎每一行都对应一个曾经出现过的问题。public void Broadcast(byte type, string text, int exceptSessionId -1) { byte[] frame Frame.Encode(type, text); // 编码一次所有人共用别在循环里重复编码 Session[] snapshot; lock (_sync) { snapshot _sessions.Values.ToArray(); } // 锁内只做拷贝锁外再做发送 int queued 0, dropped 0; foreach (Session s in snapshot) { if (s.Id exceptSessionId) continue; // 群发不回声给发送者本人 if (s.TryEnqueue(frame)) queued; else { CloseSession(s, 发送队列堆积); dropped; } } Log($群发 type{type}入队 {queued}剔除 {dropped}); }先ToArray()再遍历是为了避免在遍历过程中另一个线程登录或掉线导致抛出“集合已修改”异常——这个异常在压测时几乎必然出现而且抛出位置随机。拷贝的成本是几十个引用换来的是彻底的可重入性。编码只做一次也很重要。如果写在循环里五十个客户端就是五十次 UTF-8 编码外加五十个新数组群发一百条消息就多出几千次分配内存涨得快GC 也跟着频繁触发。queued和dropped这两个计数不要嫌麻烦它们是线上排查问题的第一手依据。群发后dropped一直在涨说明有客户端网络质量差或已经假死queued明显小于在线人数说明会话表里混进了已经关闭的会话。3.4 关闭顺序Shutdown 再 Close别上来就 Close关闭会话的顺序写错了最直接的表现是客户端偶尔收不到最后一条系统通知或者服务端报ConnectionReset。public void Close(string reason) { _sendQueue.Writer.TryComplete(); // 让发送循环自然退出已入队的帧还能发完 try { _client.Client.Shutdown(SocketShutdown.Both); } // 先发 FIN走正常四次挥手 catch (SocketException) { } try { _client.Close(); } catch { } }TryComplete()之后ReadAllAsync会把队列里剩下的帧读完再结束队列里已经排着的消息不会凭空消失。Shutdown的作用是告诉对端“我不再发了”对端读到 0 字节就知道是正常关闭而不是连接被重置直接Close则可能触发 RST接收方缓冲区里还没被应用层读走的数据会被丢弃。这条在发“服务端即将关闭”这种通知时尤其明显先Shutdown再Close客户端基本都能收到。4. 客户端实现收发分离、UI 线程安全与退避重连客户端代码量比服务端少但踩坑的种类一点不少主要集中在三个地方连接阶段的等待、接收过程的数据处理、断线之后的重连策略。4.1 连接与登录握手连接本身要加超时否则目标机器没开机时界面会卡住十几秒用户以为程序挂了。public async Taskbool ConnectAsync(string host, int port, string userName, CancellationToken token) { _client new TcpClient { NoDelay true }; using var cts CancellationTokenSource.CreateLinkedTokenSource(token); cts.CancelAfter(TimeSpan.FromSeconds(5)); // 连不上别让界面干等 try { await _client.ConnectAsync(host, port, cts.Token); } catch (OperationCanceledException) { return false; } catch (SocketException) { return false; } _stream _client.GetStream(); await _stream.WriteAsync(Frame.Encode(MsgType.Login, userName), token); // 首帧即登录 _ ReceiveLoopAsync(token); // 收和发从这里开始彻底分开 return true; }登录帧紧接着连接发出服务端收到类型 1 就把昵称绑到会话上同时把它加进在线表并广播类型 5 的在线列表。这样“连上”和“上线”是两个状态中间有个明确的握手点后面处理重连时逻辑会清楚很多。cts.CancelAfter(5秒)给的是连接阶段的硬超时。局域网里正常连接在毫秒级完成5 秒还没连上基本可以判定对方没开机、防火墙拦了或者 IP 填错了三种情况的处理方式对用户来说都是“重试”。4.2 接收循环缓冲区压缩与 UI 线程安全接收循环是全篇最容易写错的一段因为它同时要处理半包、粘包和跨线程更新界面三个问题。private async Task ReceiveLoopAsync(CancellationToken token) { byte[] buffer new byte[8 * 1024]; int offset 0, count 0; while (!token.IsCancellationRequested) { int n; try { n await _stream.ReadAsync(buffer.AsMemory(count), token); } catch (IOException) { break; } // 连接被重置 if (n 0) break; // 对端正常关闭 count n; // 一次 Read 可能带来多帧也可能只有半帧循环取干净 while (Frame.TryDecode(buffer, ref offset, count, out byte type, out string text)) OnMessage?.Invoke(this, new MessageEventArgs(type, text)); // 消费完整的部分把剩下的半帧挪到缓冲区开头 if (offset count) { offset 0; count 0; } else if (offset 0) { Buffer.BlockCopy(buffer, offset, buffer, 0, count - offset); count - offset; offset 0; } } OnDisconnected?.Invoke(this, EventArgs.Empty); }ReadAsync(buffer.AsMemory(count), token)里从count位置开始写是为了不覆盖上次剩下的半帧。循环结束后做一次压缩把残留数据挪到开头count更新为剩余字节数offset归零。不做这一步缓冲区里的数据会越攒越乱表现就是前几十条消息正常后面开始出现错位的乱码。OnMessage事件里绝对不要直接改控件属性。这个回调跑在线程池线程上WinForms 控件不是线程安全的直接赋值在某些情况下看起来没问题换个机器就抛InvalidOperationException: 线程间操作无效。正确做法是在窗体订阅事件时用BeginInvoke切回 UI 线程private void OnClientMessage(object sender, MessageEventArgs e) { if (IsDisposed) return; BeginInvoke(new Action(() { if (e.Type MsgType.Broadcast) AppendChat(e.Text); else if (e.Type MsgType.OnlineList) RefreshUserList(e.Text); })); }用BeginInvoke而不是Invoke是为了不阻塞接收线程。Invoke是同步等待 UI 线程处理完才返回界面一卡比如用户在拖窗口接收线程就跟着卡进而队列堆积最后被服务端判定为慢客户端踢掉。4.3 重连指数退避加随机抖动断线重连最直观的写法是while(true) { Thread.Sleep(1000); if (Connect()) break; }本地测试完全没问题一旦四十台机器同时掉线一秒钟后四十个连接同时涌向服务端backlog队列瞬间打满一部分连接被拒被拒的客户端等一秒再一起冲形成周期性的冲击。这就是为什么要加随机抖动。private async Task ReconnectLoopAsync(CancellationToken token) { int attempt 0; while (!token.IsCancellationRequested !_closedByUser) { // 1,2,4,8,16,30 秒封顶再叠加 0~500ms 抖动打散重连时刻 int delay Math.Min(30, (int)Math.Pow(2, attempt)) Random.Shared.Next(0, 500); try { await Task.Delay(TimeSpan.FromSeconds(delay), token); } catch (OperationCanceledException) { break; } if (await ConnectAsync(_host, _port, _userName, token)) { attempt 0; break; } attempt; } }重连成功后必须重新发登录帧不能只恢复 socket 就以为万事大吉。服务端那边的旧会话早就被扫描线程清掉了新连接是一个全新的会话对象ID 不同昵称也没绑上如果不重登这个客户端能收到群发消息但发出去的消息服务端找不到发送者处理时会直接丢掉。还有一个细节重连期间要禁用发送按钮或者让待发消息进一个本地队列。用户不知道底层在重连点发送没反应多半会连续点十几次恢复连接后这十几条一起涌向服务端看起来就像是有人频繁刷屏。5. 避坑与排查五类最容易翻车的问题和对应解法下面这五条都是实际联调时最常见、也最容易被误判成“不会影响系统正常工作”的问题。每条按现象、原因、解决三段写遇到时可以直接对照。5.1 消息与连接层现象客户端 A 发一句“明天下午三点在实验楼集合”客户端 B 收到的是“明天下午三点在实”后半句变成了下一条消息的前缀或者干脆整条消息变成一串问号。有时还表现为连续发十条第九条和第十条串成一条。原因把一次Read的返回值当成一条完整消息。TCP 不保证一次Read对应一次Write发送方Write了 30 字节接收方可能分三次拿到 101010也可能两次合并成 50 字节一次拿到。乱码的变体还有编码不一致一端用 UTF-8另一端用系统默认编码中文 Windows 上是 GBK同一条中文消息在两端的字节数都不一样长度前缀自然对不上。解决长度前缀 累积缓冲区只有count - offset HeaderSize bodyLen时才解码不够就等下一次Read两端统一 UTF-8所有长度计算用Encoding.UTF8.GetByteCount而不是string.Length。现象服务端重启控制台报SocketException (10048): 通常每个套接字地址只允许使用一次等一两分钟再启动又好了。原因上一次运行被强行结束直接关控制台窗口、任务管理器结束进程被接受的连接还处在TIME_WAIT状态本地端口仍被占用新的监听无法绑定。解决在listener.Start()之前调用SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true)代码见 3.1 节。更重要的是开发阶段养成优雅关闭的习惯按 CtrlC 或者点停止按钮时先停止 Accept 循环再逐个CloseSession别每次都强杀进程。5.2 并发与状态层现象群发时随机抛出InvalidOperationException: 集合已修改枚举操作可能无法执行堆栈指向foreach。原因在遍历_sessions.Values的过程中另一个线程执行了登录Add或超时清理Remove。字典在枚举期间被修改就会抛这个异常和是否用锁保护无关——锁保护的是写操作之间互斥如果遍历时不持锁同样会撞上。解决锁内ToArray()拿到快照锁外遍历快照。锁的持有时间控制在几十微秒以内绝对不要在锁内做WriteAsync、Thread.Sleep或日志落盘否则一个响应慢的客户端会把所有登录操作堵在外面。现象群发一百条消息大部分客户端正常但其中某一台从第二条开始就再也收不到了它自己还能发消息服务端也没报错。原因那台客户端所在的网络拥塞或者调试时挂起了接收线程。服务端对它的WriteAsync长时间不返回如果没有独立发送队列整条广播链路会一直堵在这个点上其余客户端一起受影响。解决每会话一个容量 256 的有界队列TryWrite返回false立即摘除该会话并记日志。这样广播链路永远只做内存入队耗时与客户端网络状况无关。排查时看dropped计数和具体是被哪个会话触发的基本能定位到机器。现象同一台客户端重连之后在线列表里出现两条同名记录私聊发给它时对方收不到。原因重连产生了一个新会话旧会话要等服务端扫描线程跑到才被清掉中间这几十秒里同一个昵称对应两个会话 ID私聊按昵称查找时命中的是已经死掉的那一条。解决登录处理时先按昵称查一遍现有会话有就先把旧的踢掉再绑定新的私聊一律按会话 ID 寻址昵称只用于显示。这条改完之后“对方明明在线却收不到私聊”这类问题基本绝迹。6. 验收与答辩用四组对照实验证明这套通信扛得住写完之后自己跑一遍“能连上、能发消息”不算验收那只能证明主流程通。真正要交出去的东西得能回答“五十个人同时在线会怎样”“网线拔了会怎样”这类问题。我一般会做四组对照实验每组都有明确的通过标准写进文档里也是一份像样的测试记录。验收项操作方法通过标准单连接完整性一个客户端连发 1000 条 1KB 随机中文含换行符与竖线一条不少、顺序不乱、无乱码服务端日志入队数与发送数一致并发上线用脚本 3 秒内拉起 50 个客户端同时连接全部登录成功服务端在线数等于 50无 10048 / 10061 错误群发时延50 个客户端在线服务端连续群发 100 次最慢一条端到端不超过 200ms局域网发送队列无堆积告警断线与重连拔掉其中一台的网线 20 秒后插回另一台直接结束进程超时的那台在 45 秒内从在线列表消失重连后只保留一份记录且能正常收发四组里最容易出问题的是第四组。拔网线这一步必须真的拔用禁用网卡模拟不算数——禁用网卡有时会发一个 RST 出去服务端立刻就知道连接没了测不出心跳超时的逻辑直接结束进程同样会走正常关闭流程。只有物理断开才能验证“服务端靠 45 秒心跳阈值发现掉线”这条链路是否真的生效。答辩时被问得最多的三个问题答案是现成的。为什么不用 UDP群发通知要求可靠性UDP 丢了就是丢了要做重传就相当于自己实现一遍 TCP 的确认机制这个项目里并不划算。为什么不用现成的框架框架能解决传输问题但解决不了“会话表怎么维护”“群发时慢客户端怎么办”这些真正要讲清楚的部分而这恰好是这套方案的重点。能撑多少人一线程一连接的模型在两百个连接以内问题不大异步模型加独立发送队列的形式瓶颈通常在心跳扫描和日志写入上不在网络层具体数字拿第四组实验的数据说话比口头估一个更有说服力。有一次联调前面三组测试都通过了第四组拔网线之后等了整整五分钟那台机器还在列表里显示在线。原因是我把心跳扫描的周期写成了TimeSpan.FromMinutes(1)超时阈值又设成 90 秒看代码觉得没问题实际跑起来才发现响应太慢。从那以后我每次做通信类项目都会先把这三件事放在同一张纸上核对一遍客户端多久发一次心跳、服务端多久扫一次、超时阈值是多少确认前两个加起来明显小于第三个才动手写业务逻辑。希望帮到你。本文还有配套的精品资源点击获取
简介一套基于 Windows 平台、使用 Visual Studio 2013 编写的 Socket TCP 通信示例工程面向具备 C 基础、希望从单机练习过渡到网络编程实战的开发者。它要解决的核心问题是服务端如何同时接入多个客户端并把一条消息广播给全部在线连接可对照实现类似 QQ 群聊的实时通讯场景。压缩包共 58 个文件、约 16.42MB除 cpp 与 h 源码以及 sln、vcxproj 工程配置外还保留了 exe 可执行文件、pdb 调试符号、obj 与 ilk 中间产物和 tlog 编译日志这些内容既能直接运行以观察效果也能在 IDE 中重新编译调试。已有 513 人学习。工程内含服务端监听与并发处理、客户端连接管理、消息群发以及文件二进制流传输等模块读者可据此理解 TCP 连接建立、多线程收发与广播逻辑也可在此基础上扩展加密传输和聊天室功能对课程设计与自学网络编程都有较直接的参考价值。1. 四十台机器同时在线这套 TCP 通信方案到底要解决什么一个机房四十台机器同时连上来服务端要在两秒内把一条通知推给所有人还得随时知道谁掉线了——这是「Windows 服务端 多客户端 Socket TCP 通信」最原始的需求描述也是大多数课程设计和毕业设计里真正卡人的地方。真正难的地方在于连接断了怎么发现、消息粘在一起怎么切开、群发时一个客户端卡住会不会拖垮整条广播链路Socket.Connect那一行从来不是难点。这套方案给出的做法是自定义长度前缀帧协议 服务端会话表 每会话独立发送队列 客户端收发分离与退避重连四个部分各自独立又互相呼应。它适合要交一份完整通信课设的学生也适合需要在局域网内做消息分发、设备状态上报、上位机广播的从业者直接改。2. 协议与并发模型长度前缀帧和每会话发送队列怎么定TCP 提供的是字节流不是消息流。这一条如果没在动手前想清楚后面写出来的代码一定会在某个下午突然出错本地跑得好好的一上真实网络中文消息就变成半句。所以协议和并发模型必须最先定定完再写业务这部分最终省下来的返工时间比什么都值。2.1 消息边界长度前缀帧怎么切三种常见切法里只有一种能长期使用。用\n或|做分隔符最省事但正文里只要出现同样的字符整条链路当场失效定长包不会串但一条“收到”也要占满 512 字节带宽浪费得离谱长度前缀把“这一帧有多长”明明白白写在帧头接收方按长度取取不够就等下一次Read多出来的留给下一帧。多客户端场景下这是唯一不需要额外约定的做法。using System; using System.Buffers.Binary; using System.Text; public static class Frame { // 帧头 4 字节正文长度大端 1 字节消息类型 public const int HeaderSize 5; public const int MaxBodyLength 64 * 1024; // 单帧正文上限挡住异常大包撑爆内存 public static byte[] Encode(byte type, string text) { byte[] body Encoding.UTF8.GetBytes(text ?? string.Empty); if (body.Length MaxBodyLength) throw new ArgumentException(正文超过单帧上限); byte[] frame new byte[HeaderSize body.Length]; BinaryPrimitives.WriteInt32BigEndian(frame.AsSpan(0, 4), body.Length); frame[4] type; // 消息类型放在长度之后 Buffer.BlockCopy(body, 0, frame, HeaderSize, body.Length); return frame; } // 从累积缓冲区里尝试取出一帧不够一帧返回 false等下次 Read public static bool TryDecode(byte[] buffer, ref int offset, int count, out byte type, out string text) { type 0; text null; if (count - offset HeaderSize) return false; // 帧头都没收全 int bodyLen BinaryPrimitives.ReadInt32BigEndian(buffer.AsSpan(offset, 4)); if (bodyLen 0 || bodyLen MaxBodyLength) throw new InvalidDataException(帧长度非法应主动断开该连接); if (count - offset - HeaderSize bodyLen) return false; // 正文还没收全 type buffer[offset 4]; text Encoding.UTF8.GetString(buffer, offset HeaderSize, bodyLen); offset HeaderSize bodyLen; // 游标前移支持一次读多帧 return true; } }offset是这个设计的核心它让一个缓冲区可以连续吐出多帧一次Read可能收到半帧也可能收到三帧半TryDecode循环调用直到返回false剩下的半帧原样留在缓冲区等下一轮。长度统一按字节算而不是按字符算string.Length在中文字符串上给出的是字符数用它当长度写进帧头接收方一定切错位这是乱码问题里最常见的一种。大端写入是为了跨语言调试时对照抓包数据不费劲自己两端都用 C# 其实小端也行但一旦以后要接个 Python 脚本做压测统一大端更省事。消息类型用一字节编码一张表定死就不要再改类型值名称方向正文格式说明1LoginC→S昵称上线首帧服务端绑定会话2BroadcastC→S→C聊天正文群发服务端转发给除发送者外所有人3PrivateC→S→C目标会话ID|正文点对点消息4HeartbeatC→S空15 秒一次不参与业务5OnlineListS→Cid,nick;id,nick有人上线或下线时群发6SystemS→C提示文字超时踢人、服务端关闭通知注意MaxBodyLength不是随便填的数字。它决定单条消息的上限也决定接收缓冲区的最小尺寸取值小于实际业务消息会在发送端抛异常取值过大一个异常连接就能让你内存增长。2.2 并发模型一线程一连接还是异步小规模局域网项目里这个选择其实没有标准答案但有明确的边界。一线程一连接写起来最直观四十个客户端就是四十个线程接收、处理、发送全在一个线程里顺着写调试时断点一打就知道卡在哪代价是每个线程默认占 1MB 栈空间且线程切换在连接数上去以后开始拖慢响应。Select模型在 Windows 上还有个历史限制FD_SETSIZE默认只有 64接第 65 个客户端直接失败这个坑不少人遇到过。异步模型是更耐久的选择。每个连接一个Task接收用ReadAsync发送交给独立的发送循环线程池负责调度四十个连接和四百个连接在代码形态上没有任何区别。代价是异常会被吞进Task里async void一用就等着排查一整晚。所以这套方案在异步的基础上再加一层每个会话配一个独立的发送队列和发送循环。这一层的价值在群发时才体现出来。如果所有连接共用一个发送逻辑某个客户端网络卡住WriteAsync迟迟不返回整条广播链路就堵在这里其余客户端全都收不到消息——这就是典型的“一个慢客户端拖垮全服”。改成每个会话一个容量 256 的有界队列群发只负责往队列里塞真正的WriteAsync由各自的发送循环执行谁慢谁自己慢队列满了就说明这个客户端已经跟不上直接摘掉不影响别人。2.3 心跳与超时别指望 TCP KeepAlive服务端的在线列表和真实连接对不上十有八九是这里没做。TCP 自带的 KeepAlive 在 Windows 上默认空闲两小时才开始探测对课堂演示来说等于没有更麻烦的是拔网线、断电、直接杀进程这几种情况对端根本发不出 FIN服务端看到的连接永远是“已建立”。应用层心跳是唯一可靠的办法客户端每 15 秒发一个类型 4 的空帧服务端每次收到任何帧就更新该会话的LastActiveUtc另起一个扫描任务每 10 秒跑一次超过 45 秒没动静的直接清理并群发新的在线列表。// 服务端每 10 秒扫一次超过 45 秒没有任何帧的会话直接清理 private void SweepIdleSessions() { DateTime deadline DateTime.UtcNow.AddSeconds(-45); Session[] snapshot; lock (_sync) { snapshot _sessions.Values.ToArray(); } // 锁内只做拷贝 foreach (Session s in snapshot) if (s.LastActiveUtc deadline) CloseSession(s, 心跳超时); // 锁外做关闭避免长时间持锁 }三个参数的关系要记住客户端心跳间隔必须明显小于服务端超时阈值一般取三分之一左右。15 秒发一次、45 秒判超时意味着允许连续丢两次心跳短暂网络抖动不会误踢如果心跳 30 秒发一次、超时也设 30 秒那每次网络稍微延迟一下就会误判用户会看到自己莫名其妙被踢下线然后重连再被踢。3. 服务端核心监听循环、会话表与群发链路的实现服务端要做的只有四件事接住连接、记住谁在线、把消息正确转出去、把断掉的连接清理干净。下面四小节按这个顺序拆开每一段都能直接放进项目里跑起来。3.1 监听与接入Accept 循环怎么写才不卡监听本身不复杂容易出问题的是“接住之后怎么办”。有人把业务处理直接写在 Accept 循环里第一个客户端连上以后发一条长消息服务端就再也接不了第二个人了。private async Task AcceptLoopAsync(CancellationToken token) { var listener new TcpListener(IPAddress.Any, 9527); listener.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); // 重启时避开 TIME_WAIT 导致的端口占用 listener.Start(backlog: 128); // 半连接队列客户端集中上线时别用默认值 while (!token.IsCancellationRequested) { TcpClient client; try { client await listener.AcceptTcpClientAsync(); } catch (ObjectDisposedException) { break; } // 正常停止监听 catch (SocketException ex) { Log($接入失败{ex.SocketErrorCode}); continue; } client.NoDelay true; // 关掉 Nagle控制类小消息不要攒 _ HandleClientAsync(client, token); // 每个连接一个独立任务绝不 await } listener.Stop(); }_ HandleClientAsync(...)这一行是整段的关键不await接入循环立刻回到AcceptTcpClientAsync等下一个连接。代价是这个任务的异常没人接所以HandleClientAsync内部必须整体包一层try/catch/finallyfinally里做会话清理。NoDelay打开是因为心跳和通知这类消息体很小Nagle 算法会攒着等凑够一定量再发表现为“消息发出去要等几百毫秒才到”在演示现场显得特别难解释。backlog: 128是半连接队列长度。四十台机器在开机脚本里同时连瞬时会有几十个 SYN 挤在队列里队列短了就会出现连接被拒。这个值不用调得特别大但默认值在集中上线时确实不够。3.2 会话表字典 单锁锁内不做网络 IO会话表用一个Dictionaryint, Session就够键用自增 ID 而不是昵称因为昵称会重名、会改ID 不会。所有对字典的增删查都用同一把锁保护这点不要图省事用ConcurrentDictionary然后到处TryGetValue——省下来的那点性能在几十个连接的量级上完全体现不出来反而会让“谁在什么时候改过这张表”变得难以追踪。public sealed class Session { public int Id { get; } public string UserName { get; set; } public DateTime LastActiveUtc { get; set; } private readonly TcpClient _client; private readonly NetworkStream _stream; // 每个会话一条有界发送队列满了说明这个客户端消费不过来直接丢弃并摘除 private readonly Channelbyte[] _sendQueue Channel.CreateBoundedbyte[]( new BoundedChannelOptions(256) { FullMode BoundedChannelFullMode.DropWrite }); public Session(int id, TcpClient client) { Id id; _client client; _stream client.GetStream(); LastActiveUtc DateTime.UtcNow; } public bool TryEnqueue(byte[] frame) _sendQueue.Writer.TryWrite(frame); // 整个会话只有这一个循环写 socket天然不会出现两条消息交错 public async Task SendLoopAsync(CancellationToken token) { await foreach (byte[] frame in _sendQueue.Reader.ReadAllAsync(token)) await _stream.WriteAsync(frame, token); } }“单写者”这个约束值得单独强调。Socket 的Send在多个线程同时调用时不能保证两条消息整体先后很可能出现 A 消息的前 10 字节接了 B 消息的后 20 字节客户端解出来就是一堆乱码——这种问题偶发、难复现属于典型的需要长时间排查的问题。把写操作收敛到一个循环里从结构上就不存在这个可能。BoundedChannelFullMode.DropWrite是明确的取舍队列满意味着这个客户端已经积压了 256 帧还没发完再往里塞只会让内存继续涨不如丢掉这一帧并把它标记为待清理。3.3 群发链路快照遍历、失败剔除与入队计数群发的代码只有十几行但几乎每一行都对应一个曾经出现过的问题。public void Broadcast(byte type, string text, int exceptSessionId -1) { byte[] frame Frame.Encode(type, text); // 编码一次所有人共用别在循环里重复编码 Session[] snapshot; lock (_sync) { snapshot _sessions.Values.ToArray(); } // 锁内只做拷贝锁外再做发送 int queued 0, dropped 0; foreach (Session s in snapshot) { if (s.Id exceptSessionId) continue; // 群发不回声给发送者本人 if (s.TryEnqueue(frame)) queued; else { CloseSession(s, 发送队列堆积); dropped; } } Log($群发 type{type}入队 {queued}剔除 {dropped}); }先ToArray()再遍历是为了避免在遍历过程中另一个线程登录或掉线导致抛出“集合已修改”异常——这个异常在压测时几乎必然出现而且抛出位置随机。拷贝的成本是几十个引用换来的是彻底的可重入性。编码只做一次也很重要。如果写在循环里五十个客户端就是五十次 UTF-8 编码外加五十个新数组群发一百条消息就多出几千次分配内存涨得快GC 也跟着频繁触发。queued和dropped这两个计数不要嫌麻烦它们是线上排查问题的第一手依据。群发后dropped一直在涨说明有客户端网络质量差或已经假死queued明显小于在线人数说明会话表里混进了已经关闭的会话。3.4 关闭顺序Shutdown 再 Close别上来就 Close关闭会话的顺序写错了最直接的表现是客户端偶尔收不到最后一条系统通知或者服务端报ConnectionReset。public void Close(string reason) { _sendQueue.Writer.TryComplete(); // 让发送循环自然退出已入队的帧还能发完 try { _client.Client.Shutdown(SocketShutdown.Both); } // 先发 FIN走正常四次挥手 catch (SocketException) { } try { _client.Close(); } catch { } }TryComplete()之后ReadAllAsync会把队列里剩下的帧读完再结束队列里已经排着的消息不会凭空消失。Shutdown的作用是告诉对端“我不再发了”对端读到 0 字节就知道是正常关闭而不是连接被重置直接Close则可能触发 RST接收方缓冲区里还没被应用层读走的数据会被丢弃。这条在发“服务端即将关闭”这种通知时尤其明显先Shutdown再Close客户端基本都能收到。4. 客户端实现收发分离、UI 线程安全与退避重连客户端代码量比服务端少但踩坑的种类一点不少主要集中在三个地方连接阶段的等待、接收过程的数据处理、断线之后的重连策略。4.1 连接与登录握手连接本身要加超时否则目标机器没开机时界面会卡住十几秒用户以为程序挂了。public async Taskbool ConnectAsync(string host, int port, string userName, CancellationToken token) { _client new TcpClient { NoDelay true }; using var cts CancellationTokenSource.CreateLinkedTokenSource(token); cts.CancelAfter(TimeSpan.FromSeconds(5)); // 连不上别让界面干等 try { await _client.ConnectAsync(host, port, cts.Token); } catch (OperationCanceledException) { return false; } catch (SocketException) { return false; } _stream _client.GetStream(); await _stream.WriteAsync(Frame.Encode(MsgType.Login, userName), token); // 首帧即登录 _ ReceiveLoopAsync(token); // 收和发从这里开始彻底分开 return true; }登录帧紧接着连接发出服务端收到类型 1 就把昵称绑到会话上同时把它加进在线表并广播类型 5 的在线列表。这样“连上”和“上线”是两个状态中间有个明确的握手点后面处理重连时逻辑会清楚很多。cts.CancelAfter(5秒)给的是连接阶段的硬超时。局域网里正常连接在毫秒级完成5 秒还没连上基本可以判定对方没开机、防火墙拦了或者 IP 填错了三种情况的处理方式对用户来说都是“重试”。4.2 接收循环缓冲区压缩与 UI 线程安全接收循环是全篇最容易写错的一段因为它同时要处理半包、粘包和跨线程更新界面三个问题。private async Task ReceiveLoopAsync(CancellationToken token) { byte[] buffer new byte[8 * 1024]; int offset 0, count 0; while (!token.IsCancellationRequested) { int n; try { n await _stream.ReadAsync(buffer.AsMemory(count), token); } catch (IOException) { break; } // 连接被重置 if (n 0) break; // 对端正常关闭 count n; // 一次 Read 可能带来多帧也可能只有半帧循环取干净 while (Frame.TryDecode(buffer, ref offset, count, out byte type, out string text)) OnMessage?.Invoke(this, new MessageEventArgs(type, text)); // 消费完整的部分把剩下的半帧挪到缓冲区开头 if (offset count) { offset 0; count 0; } else if (offset 0) { Buffer.BlockCopy(buffer, offset, buffer, 0, count - offset); count - offset; offset 0; } } OnDisconnected?.Invoke(this, EventArgs.Empty); }ReadAsync(buffer.AsMemory(count), token)里从count位置开始写是为了不覆盖上次剩下的半帧。循环结束后做一次压缩把残留数据挪到开头count更新为剩余字节数offset归零。不做这一步缓冲区里的数据会越攒越乱表现就是前几十条消息正常后面开始出现错位的乱码。OnMessage事件里绝对不要直接改控件属性。这个回调跑在线程池线程上WinForms 控件不是线程安全的直接赋值在某些情况下看起来没问题换个机器就抛InvalidOperationException: 线程间操作无效。正确做法是在窗体订阅事件时用BeginInvoke切回 UI 线程private void OnClientMessage(object sender, MessageEventArgs e) { if (IsDisposed) return; BeginInvoke(new Action(() { if (e.Type MsgType.Broadcast) AppendChat(e.Text); else if (e.Type MsgType.OnlineList) RefreshUserList(e.Text); })); }用BeginInvoke而不是Invoke是为了不阻塞接收线程。Invoke是同步等待 UI 线程处理完才返回界面一卡比如用户在拖窗口接收线程就跟着卡进而队列堆积最后被服务端判定为慢客户端踢掉。4.3 重连指数退避加随机抖动断线重连最直观的写法是while(true) { Thread.Sleep(1000); if (Connect()) break; }本地测试完全没问题一旦四十台机器同时掉线一秒钟后四十个连接同时涌向服务端backlog队列瞬间打满一部分连接被拒被拒的客户端等一秒再一起冲形成周期性的冲击。这就是为什么要加随机抖动。private async Task ReconnectLoopAsync(CancellationToken token) { int attempt 0; while (!token.IsCancellationRequested !_closedByUser) { // 1,2,4,8,16,30 秒封顶再叠加 0~500ms 抖动打散重连时刻 int delay Math.Min(30, (int)Math.Pow(2, attempt)) Random.Shared.Next(0, 500); try { await Task.Delay(TimeSpan.FromSeconds(delay), token); } catch (OperationCanceledException) { break; } if (await ConnectAsync(_host, _port, _userName, token)) { attempt 0; break; } attempt; } }重连成功后必须重新发登录帧不能只恢复 socket 就以为万事大吉。服务端那边的旧会话早就被扫描线程清掉了新连接是一个全新的会话对象ID 不同昵称也没绑上如果不重登这个客户端能收到群发消息但发出去的消息服务端找不到发送者处理时会直接丢掉。还有一个细节重连期间要禁用发送按钮或者让待发消息进一个本地队列。用户不知道底层在重连点发送没反应多半会连续点十几次恢复连接后这十几条一起涌向服务端看起来就像是有人频繁刷屏。5. 避坑与排查五类最容易翻车的问题和对应解法下面这五条都是实际联调时最常见、也最容易被误判成“不会影响系统正常工作”的问题。每条按现象、原因、解决三段写遇到时可以直接对照。5.1 消息与连接层现象客户端 A 发一句“明天下午三点在实验楼集合”客户端 B 收到的是“明天下午三点在实”后半句变成了下一条消息的前缀或者干脆整条消息变成一串问号。有时还表现为连续发十条第九条和第十条串成一条。原因把一次Read的返回值当成一条完整消息。TCP 不保证一次Read对应一次Write发送方Write了 30 字节接收方可能分三次拿到 101010也可能两次合并成 50 字节一次拿到。乱码的变体还有编码不一致一端用 UTF-8另一端用系统默认编码中文 Windows 上是 GBK同一条中文消息在两端的字节数都不一样长度前缀自然对不上。解决长度前缀 累积缓冲区只有count - offset HeaderSize bodyLen时才解码不够就等下一次Read两端统一 UTF-8所有长度计算用Encoding.UTF8.GetByteCount而不是string.Length。现象服务端重启控制台报SocketException (10048): 通常每个套接字地址只允许使用一次等一两分钟再启动又好了。原因上一次运行被强行结束直接关控制台窗口、任务管理器结束进程被接受的连接还处在TIME_WAIT状态本地端口仍被占用新的监听无法绑定。解决在listener.Start()之前调用SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true)代码见 3.1 节。更重要的是开发阶段养成优雅关闭的习惯按 CtrlC 或者点停止按钮时先停止 Accept 循环再逐个CloseSession别每次都强杀进程。5.2 并发与状态层现象群发时随机抛出InvalidOperationException: 集合已修改枚举操作可能无法执行堆栈指向foreach。原因在遍历_sessions.Values的过程中另一个线程执行了登录Add或超时清理Remove。字典在枚举期间被修改就会抛这个异常和是否用锁保护无关——锁保护的是写操作之间互斥如果遍历时不持锁同样会撞上。解决锁内ToArray()拿到快照锁外遍历快照。锁的持有时间控制在几十微秒以内绝对不要在锁内做WriteAsync、Thread.Sleep或日志落盘否则一个响应慢的客户端会把所有登录操作堵在外面。现象群发一百条消息大部分客户端正常但其中某一台从第二条开始就再也收不到了它自己还能发消息服务端也没报错。原因那台客户端所在的网络拥塞或者调试时挂起了接收线程。服务端对它的WriteAsync长时间不返回如果没有独立发送队列整条广播链路会一直堵在这个点上其余客户端一起受影响。解决每会话一个容量 256 的有界队列TryWrite返回false立即摘除该会话并记日志。这样广播链路永远只做内存入队耗时与客户端网络状况无关。排查时看dropped计数和具体是被哪个会话触发的基本能定位到机器。现象同一台客户端重连之后在线列表里出现两条同名记录私聊发给它时对方收不到。原因重连产生了一个新会话旧会话要等服务端扫描线程跑到才被清掉中间这几十秒里同一个昵称对应两个会话 ID私聊按昵称查找时命中的是已经死掉的那一条。解决登录处理时先按昵称查一遍现有会话有就先把旧的踢掉再绑定新的私聊一律按会话 ID 寻址昵称只用于显示。这条改完之后“对方明明在线却收不到私聊”这类问题基本绝迹。6. 验收与答辩用四组对照实验证明这套通信扛得住写完之后自己跑一遍“能连上、能发消息”不算验收那只能证明主流程通。真正要交出去的东西得能回答“五十个人同时在线会怎样”“网线拔了会怎样”这类问题。我一般会做四组对照实验每组都有明确的通过标准写进文档里也是一份像样的测试记录。验收项操作方法通过标准单连接完整性一个客户端连发 1000 条 1KB 随机中文含换行符与竖线一条不少、顺序不乱、无乱码服务端日志入队数与发送数一致并发上线用脚本 3 秒内拉起 50 个客户端同时连接全部登录成功服务端在线数等于 50无 10048 / 10061 错误群发时延50 个客户端在线服务端连续群发 100 次最慢一条端到端不超过 200ms局域网发送队列无堆积告警断线与重连拔掉其中一台的网线 20 秒后插回另一台直接结束进程超时的那台在 45 秒内从在线列表消失重连后只保留一份记录且能正常收发四组里最容易出问题的是第四组。拔网线这一步必须真的拔用禁用网卡模拟不算数——禁用网卡有时会发一个 RST 出去服务端立刻就知道连接没了测不出心跳超时的逻辑直接结束进程同样会走正常关闭流程。只有物理断开才能验证“服务端靠 45 秒心跳阈值发现掉线”这条链路是否真的生效。答辩时被问得最多的三个问题答案是现成的。为什么不用 UDP群发通知要求可靠性UDP 丢了就是丢了要做重传就相当于自己实现一遍 TCP 的确认机制这个项目里并不划算。为什么不用现成的框架框架能解决传输问题但解决不了“会话表怎么维护”“群发时慢客户端怎么办”这些真正要讲清楚的部分而这恰好是这套方案的重点。能撑多少人一线程一连接的模型在两百个连接以内问题不大异步模型加独立发送队列的形式瓶颈通常在心跳扫描和日志写入上不在网络层具体数字拿第四组实验的数据说话比口头估一个更有说服力。有一次联调前面三组测试都通过了第四组拔网线之后等了整整五分钟那台机器还在列表里显示在线。原因是我把心跳扫描的周期写成了TimeSpan.FromMinutes(1)超时阈值又设成 90 秒看代码觉得没问题实际跑起来才发现响应太慢。从那以后我每次做通信类项目都会先把这三件事放在同一张纸上核对一遍客户端多久发一次心跳、服务端多久扫一次、超时阈值是多少确认前两个加起来明显小于第三个才动手写业务逻辑。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
