絡(luò)通訊完整實(shí)現(xiàn)：拆包、心跳與斷線重連)
簡(jiǎn)介C# Socket網(wǎng)絡(luò)通訊完整源碼面向初學(xué)C#網(wǎng)絡(luò)編程或需要快速搭建通訊原型的開發(fā)者。代碼基于.NET Windows窗體實(shí)現(xiàn)包含服務(wù)端與客戶端兩個(gè)獨(dú)立工程直接打開解決方案即可運(yùn)行清晰演示了Socket建立連接、收發(fā)消息等核心流程便于理解基本原理并在此基礎(chǔ)上擴(kuò)展。資源共61個(gè)文件以C#源碼14個(gè).cs為主另含解決方案與工程文件.sln/.csproj、窗口界面資源.resx以及可執(zhí)行程序與調(diào)試符號(hào).exe/.pdb等壓縮包僅1.17MB。項(xiàng)目結(jié)構(gòu)簡(jiǎn)潔服務(wù)端與客戶端分目錄組織適合對(duì)照學(xué)習(xí)兩端交互機(jī)制。已有2914人瀏覽學(xué)習(xí)代碼由作者自寫思路直白如果對(duì)實(shí)現(xiàn)有疑問還可聯(lián)系作者交流適合初學(xué)者快速上手也可作為自定義通訊功能的起點(diǎn)。1. C# Socket 網(wǎng)絡(luò)通訊源碼先看懂“完整”這兩個(gè)字意味著什么我見過不少人從網(wǎng)上下載了所謂完整的 C# Socket 網(wǎng)絡(luò)通訊源碼跑起來很簡(jiǎn)單客戶端一連、發(fā)幾句字符串、再收回來以為這就完事了。等放上業(yè)務(wù)流量才發(fā)現(xiàn)粘包、半包、斷線、客戶端多了之后互相擠掉全來了。這篇就把“完整”拆開看你會(huì)得到一套結(jié)構(gòu)清楚、能直接改的 C# Socket 網(wǎng)絡(luò)通訊方案同步阻塞模型做連接管理4 字節(jié)大端長(zhǎng)度前綴做拆包心跳加斷線重連兜底。它不是什么萬兆高并發(fā)框架但適合上位機(jī)、設(shè)備網(wǎng)關(guān)和中小型通訊服務(wù)也適合剛把注意力從“能連通”轉(zhuǎn)移到“能穩(wěn)定跑”的人。2. 選型與最小實(shí)現(xiàn)TcpClient 和 Socket 到底用哪套2.1 為什么我用 TcpListener / TcpClient 而不是裸 Socket網(wǎng)上很多“完整源碼”喜歡直接 new Socket然后鋪滿 BeginReceive、EndReceive、回調(diào)嵌套看著很唬人實(shí)際上把新手能看懂的部分全藏進(jìn)了委托里。我用 TcpListener / TcpClient 是這么考慮的它們本身是對(duì) Socket 的封裝把抓包、綁定、監(jiān)聽這些臟活吃了同時(shí)你在需要時(shí)還能通過 client.Client 把底層 Socket 拿回來設(shè)置 NoDelay、Linger 這些關(guān)鍵參數(shù)并不會(huì)有功能損失。裸 Socket 的優(yōu)勢(shì)在需要精細(xì)控制介入點(diǎn)的時(shí)候比如實(shí)現(xiàn) IOCP、收原始包、控制收發(fā)粒度。而我見過的絕大多數(shù)上位機(jī)需求本質(zhì)上是“若干個(gè)客戶端連進(jìn)來交換定長(zhǎng)或變長(zhǎng)命令”這個(gè)負(fù)載用同步阻塞模型完全扛得住。有人說同步模型性能差得分場(chǎng)景。長(zhǎng)連接應(yīng)用的主要瓶頸往往不在阻塞讀而在業(yè)務(wù)處理線程的排隊(duì)策略。幾百個(gè)連接、每秒幾十上百個(gè)報(bào)文同步模型在可控范圍內(nèi)代碼卻比異步回調(diào)好維護(hù)一個(gè)量級(jí)。等真到了單機(jī)幾千連接再換 SocketAsyncEventArgs 不遲到時(shí)這些封幀、拆包、心跳代碼照樣能復(fù)用。至于 Task 異步接受客戶端我也只在第一層用 —— 一個(gè)專門 accept 循環(huán)每個(gè)客戶端進(jìn)來丟給線程池處理。這樣監(jiān)聽線程不會(huì)被阻塞新客戶端也能盡快接入而入站數(shù)據(jù)的讀取在各自任務(wù)里保持同步順序讀好調(diào)試多了。2.2 最小服務(wù)端監(jiān)聽、接客戶端、讀字節(jié)流先把最基礎(chǔ)的跑通。這段代碼是后面所有邏輯的地基先不要做幀解析只驗(yàn)證能連上、能讀數(shù)據(jù)。using System.Net; using System.Net.Sockets; using System.Text; var listener new TcpListener(IPAddress.Any, 9000); listener.Start(100); // backlog100允許排隊(duì)等待 accept 的連接數(shù) Console.WriteLine(listening on 0.0.0.0:9000); while (true) { TcpClient client await listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClientAsync(client)); } static async Task HandleClientAsync(TcpClient client) { using (client) using (NetworkStream stream client.GetStream()) { Console.WriteLine($client in: {client.Client.RemoteEndPoint}); var buffer new byte[4096]; int read; while ((read stream.Read(buffer, 0, buffer.Length)) 0) { string chunk Encoding.UTF8.GetString(buffer, 0, read); Console.WriteLine($recv: {chunk}); } Console.WriteLine(client disconnected); } }邏輯說明AcceptTcpClientAsync 每等到一個(gè)連接就返回一個(gè) TcpClient我把它丟給線程池處理。HandleClientAsync 里先拿 NetworkStream這是讀寫的核心對(duì)象注意 GetStream 返回的是包裝實(shí)例循環(huán)里復(fù)用本地變量不要每次調(diào)用。Read 是阻塞的沒有數(shù)據(jù)時(shí)線程就掛在那里來數(shù)據(jù)才繼續(xù)。Read 返回 0 表示對(duì)端正常關(guān)閉這是“連接結(jié)束”的信號(hào)不是錯(cuò)誤不做特殊處理循環(huán)退出后 using 自動(dòng)釋放連接。參數(shù)說明監(jiān)聽地址用 IPAddress.Any 表示綁定到本機(jī)所有網(wǎng)卡適合服務(wù)端。如果只希望本機(jī)訪問可以改成 IPAddress.Loopback。端口 9000 是測(cè)試端口實(shí)際部署避開常見端口沖突就行。backlog 寫 100很多源碼不填這個(gè)參數(shù)默認(rèn)值在不同操作系統(tǒng)上表現(xiàn)不一致填 100 能讓突發(fā)連接不被內(nèi)核直接拒絕。buffer 4096 是讀取緩沖不是單條報(bào)文上限實(shí)際報(bào)文可以比它大Read 只會(huì)返回當(dāng)前內(nèi)核緩沖里能拿到的一塊完整報(bào)文可能要分多次讀這就是后文要解決的半包問題。2.3 最小客戶端連接、發(fā)數(shù)據(jù)、優(yōu)雅關(guān)閉客戶端的重點(diǎn)是把 NoDelay 打開。Nagle 算法會(huì)把小數(shù)據(jù)包攢在一起發(fā)送交互式命令就會(huì)莫名慢個(gè)幾十毫秒。NoDelay 犧牲一點(diǎn)網(wǎng)絡(luò)利用率換來命令即時(shí)性上位機(jī)場(chǎng)景默認(rèn)打開。using System.Net.Sockets; using System.Text; using var client new TcpClient(); client.NoDelay true; client.SendTimeout 5000; client.ReceiveTimeout 5000; await client.ConnectAsync(127.0.0.1, 9000); await using NetworkStream stream client.GetStream(); byte[] body Encoding.UTF8.GetBytes(ping); byte[] frame new byte[4 body.Length]; Array.Copy(body, 0, frame, 4, body.Length); await stream.WriteAsync(frame, 0, frame.Length); Console.WriteLine(sent);這段只演示連接和發(fā)送注意 frame 前 4 個(gè)字節(jié)還沒填長(zhǎng)度值因?yàn)檎嬲捎玫姆鈳胚M(jìn)第 3 章協(xié)議里。SendTimeout 和 ReceiveTimeout 是同步讀寫時(shí)的超時(shí)時(shí)間單位毫秒。超過這個(gè)時(shí)間讀寫會(huì)拋 IOException線程得以退出而不是永遠(yuǎn)卡死。這個(gè)超時(shí)在斷線檢測(cè)里很重要配合心跳能兜住網(wǎng)絡(luò)異常。選型到這里已經(jīng)有了結(jié)論TcpListener/TcpClient 做殼NetworkStream 做讀寫NoDelay 必開超時(shí)必設(shè)。這套模型代碼直白讀線程就是一個(gè) while 循環(huán)加一個(gè) Read斷線時(shí)沿著調(diào)用棧往上翻就能看到原因比回調(diào)套回調(diào)的異步寫法容易排查多了。3. 數(shù)據(jù)幀設(shè)計(jì)與拆包粘包半包問題是分水嶺3.1 TCP 是字節(jié)流根本沒有報(bào)文邊界把上章的代碼丟到真實(shí)環(huán)境你會(huì)發(fā)現(xiàn)客戶端連續(xù)發(fā)三條消息服務(wù)端可能一次 Read 就全讀到也可能發(fā)一條 10KB 的消息服務(wù)端分四次才讀完。這不是 Bug是 TCP 的本質(zhì)。TCP 只保證字節(jié)有序到達(dá)不保證應(yīng)用層的“一條消息”完整地出現(xiàn)在一次 Read 里。多條消息被合并讀出來叫粘包一條消息被拆成多次讀叫半包兩者是同一個(gè)問題的兩面。很多入門源碼直接用 Read 的返回長(zhǎng)度去解析一條消息然后把解析邏輯寫在 while 循環(huán)里。半包時(shí)第一條消息沒讀全就被拿去解析了第二條消息開頭被切掉粘包時(shí)第二個(gè)包被錯(cuò)當(dāng)成第一個(gè)包的尾巴。表現(xiàn)就是本地調(diào)試偶爾正常一上局域網(wǎng)就亂碼、卡死、命令錯(cuò)亂而且不好復(fù)現(xiàn)。這種不穩(wěn)定是最影響信任感的。解決思路很統(tǒng)一應(yīng)用層自己定義幀格式接收端先把字節(jié)囤起來湊夠一幀再交給業(yè)務(wù)邏輯。這就是拆包器的職責(zé)。3.2 協(xié)議設(shè)計(jì)4 字節(jié)大端長(zhǎng)度 負(fù)載我用來降低理解成本又不短視的格式是字段長(zhǎng)度說明FrameLen4 字節(jié)大端表示后面負(fù)載的字節(jié)數(shù)不含這 4 字節(jié)本身Body變長(zhǎng)負(fù)載內(nèi)部第 1 字節(jié)可作命令字后續(xù)是數(shù)據(jù)區(qū)長(zhǎng)度字段用 4 字節(jié)而不是 2 字節(jié)是怕日后單條消息超過 64KB。2 字節(jié)上限 65535看起來夠用但你要是傳個(gè)固件包、傳段配置 JSON 超過這個(gè)數(shù)就得改協(xié)議所有客戶端跟著重發(fā)后悔藥都沒處買。4 字節(jié)上限 2GB對(duì)絕大多數(shù)場(chǎng)景等于沒有上限。字節(jié)序要統(tǒng)一用大端。C# 在 Windows 上默認(rèn)小端C/C 的 socket 實(shí)現(xiàn)、Java、PLC 網(wǎng)關(guān)、Modbus TCP 網(wǎng)關(guān)這類設(shè)備普遍按網(wǎng)絡(luò)字節(jié)序也就是大端理解整數(shù)。如果你只在 C# 之間通訊大小端無所謂一旦哪天對(duì)接西門子 OPC、第三方便攜式設(shè)備或網(wǎng)關(guān)小端直接讀成相反字節(jié)序數(shù)字就全錯(cuò)了。所以協(xié)議從第一天就按大端走。public static byte[] BuildFrame(byte command, byte[] payload) { int bodyLen payload null ? 0 : payload.Length; var frame new byte[4 bodyLen]; // 大端寫入長(zhǎng)度跨語(yǔ)言、跨平臺(tái)通用 byte[] lenBytes BitConverter.GetBytes(bodyLen); if (BitConverter.IsLittleEndian) { Array.Reverse(lenBytes); } Array.Copy(lenBytes, 0, frame, 0, 4); frame[4] command; // 第1字節(jié)命令字如 0x01PING if (payload ! null bodyLen 0) { Array.Copy(payload, 0, frame, 5, bodyLen); } return frame; }封幀時(shí)把長(zhǎng)度寫到前 4 字節(jié)然后直接放命令字和負(fù)載。用 BitConverter 加一次 IsLittleEndian 判斷是為了兼容 .NET Framework 4.x 老工程那里沒有 BinaryPrimitives。如果你在 .NET 6 環(huán)境可以換成 BinaryPrimitives.WriteInt32BigEndian(frame, bodyLen)代碼更干凈。拆包時(shí)我維護(hù)一個(gè)接收緩沖區(qū)可以用 List 簡(jiǎn)單清楚流量不大時(shí)完全夠用。核心邏輯是循環(huán)先看有沒有 4 字節(jié)長(zhǎng)度有就解析出 bodyLen再看緩沖區(qū)里的字節(jié)夠不夠一幀夠就取出、移除不夠就退出循環(huán)等下次讀到的字節(jié)。這一步同時(shí)解決了粘包和半包——粘包時(shí)循環(huán)能取出多幀半包時(shí)剩下的不足一幀就攢著。public Listbyte[] TryDecodeFrames(Listbyte buffer, out int offset) { var frames new Listbyte[](); offset 0; while (buffer.Count - offset 4) { byte[] lenBytes buffer.GetRange(offset, 4).ToArray(); if (BitConverter.IsLittleEndian) { Array.Reverse(lenBytes); } int bodyLen BitConverter.ToInt32(lenBytes, 0); // 協(xié)議破壞時(shí)直接斷開不能死等 if (bodyLen 0 || bodyLen 1024 * 1024 * 64) { throw new InvalidDataException($invalid frame length {bodyLen}); } if (buffer.Count - offset 4 bodyLen) { break; // 半包剩余字節(jié)不夠等下次 Read 追加 } byte[] body buffer.GetRange(offset 4, bodyLen).ToArray(); frames.Add(body); offset 4 bodyLen; } return frames; }調(diào)用處把 Read 到的字節(jié) Append 進(jìn)緩沖區(qū)再把 offset 之前的內(nèi)容移除避免 List 無限增長(zhǎng)。參數(shù)說明bodyLen 上限 64MB 是保護(hù)值防止對(duì)端異常時(shí)拋出一個(gè) 2GB 長(zhǎng)度值這里會(huì)一直等不到數(shù)據(jù)連接變成僵尸。凡是長(zhǎng)度不在合理區(qū)間一律按協(xié)議錯(cuò)誤斷開。注意拆包器返回的 body 第 1 字節(jié)是命令字。業(yè)務(wù)分發(fā)時(shí)先 switch 命令字再解析后續(xù)數(shù)據(jù)不要把命令字和數(shù)據(jù)區(qū)混在一起切。拆包器怎么做完把緩沖區(qū)移除邏輯補(bǔ)上Listbyte recvBuffer new(); int read await stream.ReadAsync(buffer, 0, buffer.Length); if (read 0) break; // 對(duì)端關(guān)閉 recvBuffer.AddRange(buffer.Take(read)); var frames TryDecodeFrames(recvBuffer, out offset); recvBuffer.RemoveRange(0, offset);參數(shù)和邊界offset 是本次成功解析出的總字節(jié)數(shù)沒解析完的半包保留在 recvBuffer 里繼續(xù)攢。這樣不管對(duì)端怎么粘包拆包上層拿到的都是完整幀。這一步做完通訊框架才算過了分水嶺。4. 避坑連接被強(qiáng)關(guān)、接收返回 0、跨線程 UI 等 5 個(gè)高頻問題4.1 遠(yuǎn)程主機(jī)強(qiáng)迫關(guān)閉了一個(gè)現(xiàn)有的連接現(xiàn)象發(fā)送或接收時(shí)拋出 SocketException錯(cuò)誤碼 10054 / WSAECONNRESET意思是“對(duì)端已經(jīng)把連接重置了”。常見于客戶端崩潰后服務(wù)端還在往這條連接上寫數(shù)據(jù)或者服務(wù)端收到了一個(gè)在連接關(guān)閉時(shí)已發(fā)出的 RST 包。原因TCP 連接在異常退出時(shí)內(nèi)核會(huì)發(fā)送 RST 而不是 FIN。RST 一旦發(fā)出連接立刻銷毀雙方緩沖區(qū)全部丟棄。發(fā)送方只要往這個(gè)已死連接上再碰一下馬上觸發(fā) 10054。解決發(fā)送邏輯不能只靠 TcpClient.Connected 判斷這個(gè)屬性在 RST 之后往往還是 true。真正可靠的是發(fā)送時(shí)捕獲 SocketException檢測(cè) ErrorCode 為 10054 或 10053然后觸發(fā)斷線重連流程把這條連接的所有資源釋放掉。像這樣try { await stream.WriteAsync(frame, 0, frame.Length); } catch (SocketException ex) when (ex.ErrorCode is 10054 or 10053 or 10060) { MarkDisconnected(); // 清理本地連接狀態(tài)進(jìn)入重連邏輯 }10060 是連接超時(shí)也一并歸入斷線。很多人把異常吞掉繼續(xù)下一個(gè)循環(huán)發(fā)送結(jié)果是每次發(fā)送都拋一次異常日志刷屏連接永遠(yuǎn)不恢復(fù)。正確的做法是任何 SocketException 都視為連接已損壞直接退出讀寫循環(huán)。4.2 Read 返回 0 當(dāng)成錯(cuò)誤處理現(xiàn)象服務(wù)端日志里莫名出現(xiàn) IOException“無法從傳輸連接中讀取數(shù)據(jù)”查代碼發(fā)現(xiàn)有人在 read 0 時(shí)直接拋了異常。原因TCP 對(duì)端正常關(guān)閉時(shí)Read 返回 0這是 EOF不是錯(cuò)誤。把 0 當(dāng)異常處理客戶端主動(dòng)斷開后服務(wù)端就要多拋一次無意義異常還可能掩蓋真正的斷線邏輯。解決recv 循環(huán)里 read 0 一律走正常斷開分支釋放資源、清理會(huì)話不打印堆棧。收到 0 就表示對(duì)方不會(huì)再發(fā)數(shù)據(jù)了后續(xù)也可以從業(yè)務(wù)狀態(tài)里標(biāo)記在線離線。這樣“對(duì)端正常退出”和“網(wǎng)絡(luò)異常中斷”兩個(gè)語(yǔ)義被分開前者靜默處理后者走重連。4.3 NetworkStream.Write 不一定一次全寫進(jìn)去現(xiàn)象發(fā)送大報(bào)文時(shí)對(duì)端收到的數(shù)據(jù)被截?cái)嗷蛘叱霎惓?“無法將數(shù)據(jù)寫入傳輸連接”。很多人以為 Stream.Write 和 Read 一樣能寫多少寫多少。實(shí)際上 NetworkStream.Write 會(huì)嘗試寫完所有字節(jié)但對(duì)于正處于限速或緩沖滿的 socket底層會(huì)出現(xiàn)部分寫入。原因套接字發(fā)送緩沖區(qū)滿、對(duì)端接收速度跟不上、Nagle 與延遲 ACK 相互作用都可能導(dǎo)致單次寫操作無法完全耗盡你的數(shù)據(jù)。解決自己實(shí)現(xiàn)一個(gè)發(fā)送全量數(shù)據(jù)的函數(shù)循環(huán)補(bǔ)寫直到所有字節(jié)都落進(jìn) socket 緩沖或者發(fā)生異常退出private static async Task WriteAllAsync(NetworkStream stream, byte[] frame) { int offset 0; while (offset frame.Length) { int written await stream.WriteAsync(frame, offset, frame.Length - offset); if (written 0) { throw new SocketException((int)SocketError.ConnectionReset); } offset written; } }如果只在 C# 里使用 TcpClientNetworkStream.Write 本身做了全量保證這個(gè)函數(shù)可作為防御層如果你改用 Socket.Send這個(gè)循環(huán)就是必須的。注意粘包、半包的工作交給第 3 章的幀解析發(fā)送端不要為了“省流量”而合并多條消息也不要為了“防粘包”故意把消息拆開發(fā)送。發(fā)送端只保證幀完整寫入接收端只負(fù)責(zé)按幀邊界解析各司其職。4.4 跨線程訪問 UI 控件現(xiàn)象WinForms / WPF 程序里Recv 線程處理完消息后直接給 TextBox 或日志控件賦值調(diào)試時(shí)拋“跨線程操作無效”或者控件顯示卡頓、閃退。原因UI 控件只能在創(chuàng)建它的線程主線程上操作。Socket 接收回調(diào)在 ThreadPool 線程上執(zhí)行直接訪問控件就是非法操作。網(wǎng)上的簡(jiǎn)單源碼大多數(shù)忽略了這層一放真實(shí)項(xiàng)目必然翻車。解決把要更新的內(nèi)容打包切換到同步上下文。WinForms 就用 BeginInvokeWPF 用 Dispatcherprivate void AppendLog(string message) { if (txtLog.InvokeRequired) { txtLog.BeginInvoke(new Action(() txtLog.AppendText(message Environment.NewLine))); } else { txtLog.AppendText(message Environment.NewLine); } }注意 BeginInvoke 是異步的接收線程不會(huì)停下來等 UI這樣高頻消息時(shí)也能流暢追加。如果消息量很大建議在接收線程只把原始幀塞進(jìn)隊(duì)列UI 用自己的 Timer 周期性取隊(duì)列消費(fèi)避免每條消息都跨線程這個(gè)模型放到 5.3 的生產(chǎn)者消費(fèi)者部分講。4.5 端口被占用或 backlog 設(shè)置錯(cuò)誤現(xiàn)象服務(wù)端重啟時(shí)報(bào) SocketException “通常每個(gè)套接字地址協(xié)議/網(wǎng)絡(luò)地址/端口只允許使用一次”或者客戶端連接被拒絕。多個(gè)實(shí)例同時(shí)監(jiān)聽同一個(gè)端口是最常見原因但還有個(gè)隱蔽場(chǎng)景上一次程序退出時(shí)連接沒釋放干凈端口進(jìn)入 TIME_WAIT。原因TCP 主動(dòng)關(guān)閉方會(huì)進(jìn)入 TIME_WAIT持續(xù) 2MSL約 1-4 分鐘期間端口不能立即復(fù)用。如果服務(wù)器在代碼里主動(dòng) Close 了監(jiān)聽 socket但沒有關(guān)閉所有客戶端連接重啟時(shí)監(jiān)聽端口就可能被占用。解決監(jiān)聽 socket 設(shè)置 ExclusiveAddressUse 為 false 并打開 ReuseAddress允許端口快速重用listener.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); listener.Server.ExclusiveAddressUse false; listener new TcpListener(IPAddress.Any, 9000);但注意這只解決監(jiān)聽端口復(fù)用不能解決客戶端連接復(fù)用?？蛻舳酥鲃?dòng)斷開前要調(diào)用 Shutdown(SocketShutdown.Both) 讓對(duì)端感知再關(guān)閉這樣 TIME_WAIT 留在客戶端側(cè)而不是服務(wù)端側(cè)。服務(wù)端被動(dòng)斷開不會(huì)產(chǎn)生 TIME_WAIT所以服務(wù)端要盡量避免作為主動(dòng)關(guān)閉方。5. 多客戶端接入與心跳?；畎淹婢咦兂赡苡每蚣?.1 ConcurrentDictionary 管理在線客戶端前面的 HandleClientAsync 處理完一個(gè)客戶端就結(jié)束了多個(gè)客戶端同時(shí)連接時(shí)任務(wù)之間互相不知道對(duì)方的存在。要支撐心跳檢查和廣播就需要一個(gè)全局字典把連接標(biāo)識(shí)映射到客戶端狀態(tài)。我一般這么組織public class ClientSession { public string Id { get; set; } public TcpClient Tcp { get; set; } public NetworkStream Stream { get; set; } public volatile int LastAliveTick; public CancellationTokenSource Cts { get; } new(); } ConcurrentDictionarystring, ClientSession _sessions new();客戶端接入時(shí)生成一個(gè)唯一 IdGuid.NewGuid().ToString(N)注冊(cè)進(jìn)字典。接收線程退出后從字典移除。用 ConcurrentDictionary 而不是普通 Dictionary是因?yàn)楸O(jiān)聽線程、業(yè)務(wù)線程、心跳巡檢線程會(huì)同時(shí)讀寫字典普通 Dictionary 在高并發(fā)下會(huì)內(nèi)部狀態(tài)損壞甚至死鎖。LastAliveTick 用 volatile int每次接收到任何字節(jié)就更新為 Environment.TickCount。為什么不用 DateTime.Now因?yàn)榄h(huán)境可能被校時(shí)機(jī)器時(shí)鐘往回跳會(huì)讓“最后活躍時(shí)間”倒退導(dǎo)致心跳超時(shí)誤判。Environment.TickCount 是開機(jī)以來的毫秒數(shù)單調(diào)遞增雖然 25 天左右會(huì)翻轉(zhuǎn)到負(fù)數(shù)但差值計(jì)算不受翻轉(zhuǎn)影響比如 now - lastAliveTick 只要注意用 int 運(yùn)算短連接場(chǎng)景完全夠。5.2 服務(wù)端心跳巡檢超時(shí)沒消息就斷開TCP 長(zhǎng)連接有一個(gè)問題客戶端斷電、網(wǎng)線拔掉、路由重啟時(shí)本端不會(huì)立刻收到 FIN 或 RST連接就像“假死”。要探測(cè)假死就得靠應(yīng)用層心跳。我通常在協(xié)議里加兩個(gè)命令字0x01 PING0x02 PONG?？蛻舳嗣扛?10 秒發(fā) PING服務(wù)端收到 PING 就回 PONG服務(wù)端同時(shí)記錄 LastAliveTick。巡檢線程每 2 秒掃一遍所有會(huì)話如果 now - LastAliveTick 超過 30 秒就強(qiáng)制斷開。這里參數(shù)不能隨便拍PING 10 秒、巡檢 2 秒、超時(shí) 30 秒。超時(shí)比 PING 間隔大 3 倍是為了容忍網(wǎng)絡(luò)瞬時(shí)抖動(dòng)和 GC 卡頓避免誤殺正?？蛻舳?。超時(shí)設(shè)成 6 秒局域網(wǎng)還有可能跨交換機(jī)稍微一擁塞就全斷。private async Task WatchdogLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { await Task.Delay(2000, token); foreach (var kv in _sessions.ToArray()) { ClientSession s kv.Value; if (Environment.TickCount - s.LastAliveTick 30_000) { s.Cts.Cancel(); // 中斷阻塞在 ReadAsync 的線程 } } } }這里的高頻操作是遍歷字典并檢查時(shí)間不涉及鎖。取消用的是 CancellationTokenSource不是因?yàn)?ReadAsync 必須用它而是因?yàn)樗芨蓛舻匕炎枞械慕邮昭h(huán)打斷。HandleClientAsync 里要把 s.Cts.Token 傳給 ReadAsyncint read await s.Stream.ReadAsync(buffer, 0, buffer.Length, s.Cts.Token);一旦 CancelReadAsync 拋 OperationCanceledException接收循環(huán)退出finally 里關(guān)閉連接并移出字典。注意不要直接調(diào)用 tcp.Close() 去打斷 ReceiveClose 同時(shí)會(huì)釋放 Socket 句柄接收線程可能還在操作一個(gè)已釋放的句柄導(dǎo)致 ObjectDisposedException 滿天飛。先 Cancel 讓接收線程自己退出再用 using 清理資源是這個(gè)方案的關(guān)鍵順序。5.3 客戶端斷線重連與生產(chǎn)者消費(fèi)者隊(duì)列客戶端側(cè)要做的和 Timing 無關(guān)只要記住斷線是常態(tài)重連要有退避。我常用的重連循環(huán)是int retry 1; while (true) { try { await tcp.ConnectAsync(ip, port); break; // 連上 } catch (SocketException) { int delay Math.Min(5000, 200 * (1 Math.Min(retry, 5))); await Task.Delay(delay); retry; } }退避從 200ms 起步每次翻倍封頂 5 秒。連上后 retry 重置為 1。不能做成每隔 5 秒固定重試因?yàn)榉?wù)器重啟那幾秒內(nèi)連接會(huì)密集失敗退避能避免把服務(wù)器日志刷爆。業(yè)務(wù)數(shù)據(jù)不直接塞給 NetworkStream而是放進(jìn)一個(gè)有界隊(duì)列由單一發(fā)送協(xié)程消費(fèi)。這就是生產(chǎn)者消費(fèi)者模型好處是削峰防止業(yè)務(wù)線程追趕網(wǎng)絡(luò)線程導(dǎo)致內(nèi)存無上限增長(zhǎng)。var queue new BlockingCollectionbyte[](boundedCapacity: 1024); async Task SendLoopAsync(CancellationToken token) { foreach (byte[] frame in queue.GetConsumingEnumerable(token)) { await WriteAllAsync(session.Stream, frame); } }boundedCapacity 設(shè)為 1024 時(shí)隊(duì)列滿后生產(chǎn)端會(huì)阻塞這是背壓機(jī)制業(yè)務(wù)方必須等網(wǎng)絡(luò)消費(fèi)完才能繼續(xù)生產(chǎn)而不是無限堆內(nèi)存。真實(shí)項(xiàng)目里遇到內(nèi)存暴漲先查這里是不是有界隊(duì)列。這樣一套組合下來服務(wù)端和客戶端都有了連接管理、幀解析、心跳、斷線重連、背壓保護(hù)。源碼不再是一坨演示代碼而是一個(gè)能撐住真實(shí)業(yè)務(wù)流量的骨架。6. 壓測(cè)與上線前檢查跑滿 50 連接 x 2000 次回顯再說寫個(gè)小壓測(cè)工具比嘴上說“沒問題”可靠得多。我習(xí)慣這樣驗(yàn)證50 個(gè)并發(fā)連接每個(gè)連接連續(xù)發(fā) 2000 條回顯消息每條消息帶 GUID 校驗(yàn)只要一條對(duì)不上就算失敗。Parallel.For(0, 50, i { using var tcp new TcpClient(); tcp.Connect(127.0.0.1, 9000); using NetworkStream stream tcp.GetStream(); for (int j 0; j 2000; j) { string body $msg-{i}-{j}-{Guid.NewGuid():N}; byte[] frame BuildFrame(0x10, Encoding.UTF8.GetBytes(body)); WriteAllAsync(stream, frame).GetAwaiter().GetResult(); byte[] reply ReadOneFrame(stream); if (Encoding.UTF8.GetString(reply) ! body) { throw new Exception($mismatch {i}-{j}); } } Console.WriteLine($conn {i} done); });壓測(cè)通過不代表上線無憂我再順手做三件事先用 netstat -an 確認(rèn)沒有大量 CLOSE_WAIT 堆積再觀察服務(wù)端內(nèi)存發(fā)送端隊(duì)列有沒有無限增長(zhǎng)最后把日志級(jí)別調(diào)到 Debug確認(rèn)沒有半包重組異常和重連風(fēng)暴。這套流程走完我心里才踏實(shí)。做上位機(jī)頭兩年我也迷信過異步高性能那一套后來發(fā)現(xiàn)通訊系統(tǒng)的坑從來不在 API 層級(jí)而在幀邊界、心跳時(shí)序、資源釋放這些基礎(chǔ)細(xì)節(jié)上。參數(shù)是死的網(wǎng)絡(luò)是活的這些底盤沒搭穩(wěn)換個(gè)框架照樣翻車。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 C# Socket網(wǎng)絡(luò)通訊完整實(shí)現(xiàn)：拆包、心跳與斷線重連
簡(jiǎn)介C# Socket網(wǎng)絡(luò)通訊完整源碼面向初學(xué)C#網(wǎng)絡(luò)編程或需要快速搭建通訊原型的開發(fā)者。代碼基于.NET Windows窗體實(shí)現(xiàn)包含服務(wù)端與客戶端兩個(gè)獨(dú)立工程直接打開解決方案即可運(yùn)行清晰演示了Socket建立連接、收發(fā)消息等核心流程便于理解基本原理并在此基礎(chǔ)上擴(kuò)展。資源共61個(gè)文件以C#源碼14個(gè).cs為主另含解決方案與工程文件.sln/.csproj、窗口界面資源.resx以及可執(zhí)行程序與調(diào)試符號(hào).exe/.pdb等壓縮包僅1.17MB。項(xiàng)目結(jié)構(gòu)簡(jiǎn)潔服務(wù)端與客戶端分目錄組織適合對(duì)照學(xué)習(xí)兩端交互機(jī)制。已有2914人瀏覽學(xué)習(xí)代碼由作者自寫思路直白如果對(duì)實(shí)現(xiàn)有疑問還可聯(lián)系作者交流適合初學(xué)者快速上手也可作為自定義通訊功能的起點(diǎn)。1. C# Socket 網(wǎng)絡(luò)通訊源碼先看懂“完整”這兩個(gè)字意味著什么我見過不少人從網(wǎng)上下載了所謂完整的 C# Socket 網(wǎng)絡(luò)通訊源碼跑起來很簡(jiǎn)單客戶端一連、發(fā)幾句字符串、再收回來以為這就完事了。等放上業(yè)務(wù)流量才發(fā)現(xiàn)粘包、半包、斷線、客戶端多了之后互相擠掉全來了。這篇就把“完整”拆開看你會(huì)得到一套結(jié)構(gòu)清楚、能直接改的 C# Socket 網(wǎng)絡(luò)通訊方案同步阻塞模型做連接管理4 字節(jié)大端長(zhǎng)度前綴做拆包心跳加斷線重連兜底。它不是什么萬兆高并發(fā)框架但適合上位機(jī)、設(shè)備網(wǎng)關(guān)和中小型通訊服務(wù)也適合剛把注意力從“能連通”轉(zhuǎn)移到“能穩(wěn)定跑”的人。2. 選型與最小實(shí)現(xiàn)TcpClient 和 Socket 到底用哪套2.1 為什么我用 TcpListener / TcpClient 而不是裸 Socket網(wǎng)上很多“完整源碼”喜歡直接 new Socket然后鋪滿 BeginReceive、EndReceive、回調(diào)嵌套看著很唬人實(shí)際上把新手能看懂的部分全藏進(jìn)了委托里。我用 TcpListener / TcpClient 是這么考慮的它們本身是對(duì) Socket 的封裝把抓包、綁定、監(jiān)聽這些臟活吃了同時(shí)你在需要時(shí)還能通過 client.Client 把底層 Socket 拿回來設(shè)置 NoDelay、Linger 這些關(guān)鍵參數(shù)并不會(huì)有功能損失。裸 Socket 的優(yōu)勢(shì)在需要精細(xì)控制介入點(diǎn)的時(shí)候比如實(shí)現(xiàn) IOCP、收原始包、控制收發(fā)粒度。而我見過的絕大多數(shù)上位機(jī)需求本質(zhì)上是“若干個(gè)客戶端連進(jìn)來交換定長(zhǎng)或變長(zhǎng)命令”這個(gè)負(fù)載用同步阻塞模型完全扛得住。有人說同步模型性能差得分場(chǎng)景。長(zhǎng)連接應(yīng)用的主要瓶頸往往不在阻塞讀而在業(yè)務(wù)處理線程的排隊(duì)策略。幾百個(gè)連接、每秒幾十上百個(gè)報(bào)文同步模型在可控范圍內(nèi)代碼卻比異步回調(diào)好維護(hù)一個(gè)量級(jí)。等真到了單機(jī)幾千連接再換 SocketAsyncEventArgs 不遲到時(shí)這些封幀、拆包、心跳代碼照樣能復(fù)用。至于 Task 異步接受客戶端我也只在第一層用 —— 一個(gè)專門 accept 循環(huán)每個(gè)客戶端進(jìn)來丟給線程池處理。這樣監(jiān)聽線程不會(huì)被阻塞新客戶端也能盡快接入而入站數(shù)據(jù)的讀取在各自任務(wù)里保持同步順序讀好調(diào)試多了。2.2 最小服務(wù)端監(jiān)聽、接客戶端、讀字節(jié)流先把最基礎(chǔ)的跑通。這段代碼是后面所有邏輯的地基先不要做幀解析只驗(yàn)證能連上、能讀數(shù)據(jù)。using System.Net; using System.Net.Sockets; using System.Text; var listener new TcpListener(IPAddress.Any, 9000); listener.Start(100); // backlog100允許排隊(duì)等待 accept 的連接數(shù) Console.WriteLine(listening on 0.0.0.0:9000); while (true) { TcpClient client await listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClientAsync(client)); } static async Task HandleClientAsync(TcpClient client) { using (client) using (NetworkStream stream client.GetStream()) { Console.WriteLine($client in: {client.Client.RemoteEndPoint}); var buffer new byte[4096]; int read; while ((read stream.Read(buffer, 0, buffer.Length)) 0) { string chunk Encoding.UTF8.GetString(buffer, 0, read); Console.WriteLine($recv: {chunk}); } Console.WriteLine(client disconnected); } }邏輯說明AcceptTcpClientAsync 每等到一個(gè)連接就返回一個(gè) TcpClient我把它丟給線程池處理。HandleClientAsync 里先拿 NetworkStream這是讀寫的核心對(duì)象注意 GetStream 返回的是包裝實(shí)例循環(huán)里復(fù)用本地變量不要每次調(diào)用。Read 是阻塞的沒有數(shù)據(jù)時(shí)線程就掛在那里來數(shù)據(jù)才繼續(xù)。Read 返回 0 表示對(duì)端正常關(guān)閉這是“連接結(jié)束”的信號(hào)不是錯(cuò)誤不做特殊處理循環(huán)退出后 using 自動(dòng)釋放連接。參數(shù)說明監(jiān)聽地址用 IPAddress.Any 表示綁定到本機(jī)所有網(wǎng)卡適合服務(wù)端。如果只希望本機(jī)訪問可以改成 IPAddress.Loopback。端口 9000 是測(cè)試端口實(shí)際部署避開常見端口沖突就行。backlog 寫 100很多源碼不填這個(gè)參數(shù)默認(rèn)值在不同操作系統(tǒng)上表現(xiàn)不一致填 100 能讓突發(fā)連接不被內(nèi)核直接拒絕。buffer 4096 是讀取緩沖不是單條報(bào)文上限實(shí)際報(bào)文可以比它大Read 只會(huì)返回當(dāng)前內(nèi)核緩沖里能拿到的一塊完整報(bào)文可能要分多次讀這就是后文要解決的半包問題。2.3 最小客戶端連接、發(fā)數(shù)據(jù)、優(yōu)雅關(guān)閉客戶端的重點(diǎn)是把 NoDelay 打開。Nagle 算法會(huì)把小數(shù)據(jù)包攢在一起發(fā)送交互式命令就會(huì)莫名慢個(gè)幾十毫秒。NoDelay 犧牲一點(diǎn)網(wǎng)絡(luò)利用率換來命令即時(shí)性上位機(jī)場(chǎng)景默認(rèn)打開。using System.Net.Sockets; using System.Text; using var client new TcpClient(); client.NoDelay true; client.SendTimeout 5000; client.ReceiveTimeout 5000; await client.ConnectAsync(127.0.0.1, 9000); await using NetworkStream stream client.GetStream(); byte[] body Encoding.UTF8.GetBytes(ping); byte[] frame new byte[4 body.Length]; Array.Copy(body, 0, frame, 4, body.Length); await stream.WriteAsync(frame, 0, frame.Length); Console.WriteLine(sent);這段只演示連接和發(fā)送注意 frame 前 4 個(gè)字節(jié)還沒填長(zhǎng)度值因?yàn)檎嬲捎玫姆鈳胚M(jìn)第 3 章協(xié)議里。SendTimeout 和 ReceiveTimeout 是同步讀寫時(shí)的超時(shí)時(shí)間單位毫秒。超過這個(gè)時(shí)間讀寫會(huì)拋 IOException線程得以退出而不是永遠(yuǎn)卡死。這個(gè)超時(shí)在斷線檢測(cè)里很重要配合心跳能兜住網(wǎng)絡(luò)異常。選型到這里已經(jīng)有了結(jié)論TcpListener/TcpClient 做殼NetworkStream 做讀寫NoDelay 必開超時(shí)必設(shè)。這套模型代碼直白讀線程就是一個(gè) while 循環(huán)加一個(gè) Read斷線時(shí)沿著調(diào)用棧往上翻就能看到原因比回調(diào)套回調(diào)的異步寫法容易排查多了。3. 數(shù)據(jù)幀設(shè)計(jì)與拆包粘包半包問題是分水嶺3.1 TCP 是字節(jié)流根本沒有報(bào)文邊界把上章的代碼丟到真實(shí)環(huán)境你會(huì)發(fā)現(xiàn)客戶端連續(xù)發(fā)三條消息服務(wù)端可能一次 Read 就全讀到也可能發(fā)一條 10KB 的消息服務(wù)端分四次才讀完。這不是 Bug是 TCP 的本質(zhì)。TCP 只保證字節(jié)有序到達(dá)不保證應(yīng)用層的“一條消息”完整地出現(xiàn)在一次 Read 里。多條消息被合并讀出來叫粘包一條消息被拆成多次讀叫半包兩者是同一個(gè)問題的兩面。很多入門源碼直接用 Read 的返回長(zhǎng)度去解析一條消息然后把解析邏輯寫在 while 循環(huán)里。半包時(shí)第一條消息沒讀全就被拿去解析了第二條消息開頭被切掉粘包時(shí)第二個(gè)包被錯(cuò)當(dāng)成第一個(gè)包的尾巴。表現(xiàn)就是本地調(diào)試偶爾正常一上局域網(wǎng)就亂碼、卡死、命令錯(cuò)亂而且不好復(fù)現(xiàn)。這種不穩(wěn)定是最影響信任感的。解決思路很統(tǒng)一應(yīng)用層自己定義幀格式接收端先把字節(jié)囤起來湊夠一幀再交給業(yè)務(wù)邏輯。這就是拆包器的職責(zé)。3.2 協(xié)議設(shè)計(jì)4 字節(jié)大端長(zhǎng)度 負(fù)載我用來降低理解成本又不短視的格式是字段長(zhǎng)度說明FrameLen4 字節(jié)大端表示后面負(fù)載的字節(jié)數(shù)不含這 4 字節(jié)本身Body變長(zhǎng)負(fù)載內(nèi)部第 1 字節(jié)可作命令字后續(xù)是數(shù)據(jù)區(qū)長(zhǎng)度字段用 4 字節(jié)而不是 2 字節(jié)是怕日后單條消息超過 64KB。2 字節(jié)上限 65535看起來夠用但你要是傳個(gè)固件包、傳段配置 JSON 超過這個(gè)數(shù)就得改協(xié)議所有客戶端跟著重發(fā)后悔藥都沒處買。4 字節(jié)上限 2GB對(duì)絕大多數(shù)場(chǎng)景等于沒有上限。字節(jié)序要統(tǒng)一用大端。C# 在 Windows 上默認(rèn)小端C/C 的 socket 實(shí)現(xiàn)、Java、PLC 網(wǎng)關(guān)、Modbus TCP 網(wǎng)關(guān)這類設(shè)備普遍按網(wǎng)絡(luò)字節(jié)序也就是大端理解整數(shù)。如果你只在 C# 之間通訊大小端無所謂一旦哪天對(duì)接西門子 OPC、第三方便攜式設(shè)備或網(wǎng)關(guān)小端直接讀成相反字節(jié)序數(shù)字就全錯(cuò)了。所以協(xié)議從第一天就按大端走。public static byte[] BuildFrame(byte command, byte[] payload) { int bodyLen payload null ? 0 : payload.Length; var frame new byte[4 bodyLen]; // 大端寫入長(zhǎng)度跨語(yǔ)言、跨平臺(tái)通用 byte[] lenBytes BitConverter.GetBytes(bodyLen); if (BitConverter.IsLittleEndian) { Array.Reverse(lenBytes); } Array.Copy(lenBytes, 0, frame, 0, 4); frame[4] command; // 第1字節(jié)命令字如 0x01PING if (payload ! null bodyLen 0) { Array.Copy(payload, 0, frame, 5, bodyLen); } return frame; }封幀時(shí)把長(zhǎng)度寫到前 4 字節(jié)然后直接放命令字和負(fù)載。用 BitConverter 加一次 IsLittleEndian 判斷是為了兼容 .NET Framework 4.x 老工程那里沒有 BinaryPrimitives。如果你在 .NET 6 環(huán)境可以換成 BinaryPrimitives.WriteInt32BigEndian(frame, bodyLen)代碼更干凈。拆包時(shí)我維護(hù)一個(gè)接收緩沖區(qū)可以用 List 簡(jiǎn)單清楚流量不大時(shí)完全夠用。核心邏輯是循環(huán)先看有沒有 4 字節(jié)長(zhǎng)度有就解析出 bodyLen再看緩沖區(qū)里的字節(jié)夠不夠一幀夠就取出、移除不夠就退出循環(huán)等下次讀到的字節(jié)。這一步同時(shí)解決了粘包和半包——粘包時(shí)循環(huán)能取出多幀半包時(shí)剩下的不足一幀就攢著。public Listbyte[] TryDecodeFrames(Listbyte buffer, out int offset) { var frames new Listbyte[](); offset 0; while (buffer.Count - offset 4) { byte[] lenBytes buffer.GetRange(offset, 4).ToArray(); if (BitConverter.IsLittleEndian) { Array.Reverse(lenBytes); } int bodyLen BitConverter.ToInt32(lenBytes, 0); // 協(xié)議破壞時(shí)直接斷開不能死等 if (bodyLen 0 || bodyLen 1024 * 1024 * 64) { throw new InvalidDataException($invalid frame length {bodyLen}); } if (buffer.Count - offset 4 bodyLen) { break; // 半包剩余字節(jié)不夠等下次 Read 追加 } byte[] body buffer.GetRange(offset 4, bodyLen).ToArray(); frames.Add(body); offset 4 bodyLen; } return frames; }調(diào)用處把 Read 到的字節(jié) Append 進(jìn)緩沖區(qū)再把 offset 之前的內(nèi)容移除避免 List 無限增長(zhǎng)。參數(shù)說明bodyLen 上限 64MB 是保護(hù)值防止對(duì)端異常時(shí)拋出一個(gè) 2GB 長(zhǎng)度值這里會(huì)一直等不到數(shù)據(jù)連接變成僵尸。凡是長(zhǎng)度不在合理區(qū)間一律按協(xié)議錯(cuò)誤斷開。注意拆包器返回的 body 第 1 字節(jié)是命令字。業(yè)務(wù)分發(fā)時(shí)先 switch 命令字再解析后續(xù)數(shù)據(jù)不要把命令字和數(shù)據(jù)區(qū)混在一起切。拆包器怎么做完把緩沖區(qū)移除邏輯補(bǔ)上Listbyte recvBuffer new(); int read await stream.ReadAsync(buffer, 0, buffer.Length); if (read 0) break; // 對(duì)端關(guān)閉 recvBuffer.AddRange(buffer.Take(read)); var frames TryDecodeFrames(recvBuffer, out offset); recvBuffer.RemoveRange(0, offset);參數(shù)和邊界offset 是本次成功解析出的總字節(jié)數(shù)沒解析完的半包保留在 recvBuffer 里繼續(xù)攢。這樣不管對(duì)端怎么粘包拆包上層拿到的都是完整幀。這一步做完通訊框架才算過了分水嶺。4. 避坑連接被強(qiáng)關(guān)、接收返回 0、跨線程 UI 等 5 個(gè)高頻問題4.1 遠(yuǎn)程主機(jī)強(qiáng)迫關(guān)閉了一個(gè)現(xiàn)有的連接現(xiàn)象發(fā)送或接收時(shí)拋出 SocketException錯(cuò)誤碼 10054 / WSAECONNRESET意思是“對(duì)端已經(jīng)把連接重置了”。常見于客戶端崩潰后服務(wù)端還在往這條連接上寫數(shù)據(jù)或者服務(wù)端收到了一個(gè)在連接關(guān)閉時(shí)已發(fā)出的 RST 包。原因TCP 連接在異常退出時(shí)內(nèi)核會(huì)發(fā)送 RST 而不是 FIN。RST 一旦發(fā)出連接立刻銷毀雙方緩沖區(qū)全部丟棄。發(fā)送方只要往這個(gè)已死連接上再碰一下馬上觸發(fā) 10054。解決發(fā)送邏輯不能只靠 TcpClient.Connected 判斷這個(gè)屬性在 RST 之后往往還是 true。真正可靠的是發(fā)送時(shí)捕獲 SocketException檢測(cè) ErrorCode 為 10054 或 10053然后觸發(fā)斷線重連流程把這條連接的所有資源釋放掉。像這樣try { await stream.WriteAsync(frame, 0, frame.Length); } catch (SocketException ex) when (ex.ErrorCode is 10054 or 10053 or 10060) { MarkDisconnected(); // 清理本地連接狀態(tài)進(jìn)入重連邏輯 }10060 是連接超時(shí)也一并歸入斷線。很多人把異常吞掉繼續(xù)下一個(gè)循環(huán)發(fā)送結(jié)果是每次發(fā)送都拋一次異常日志刷屏連接永遠(yuǎn)不恢復(fù)。正確的做法是任何 SocketException 都視為連接已損壞直接退出讀寫循環(huán)。4.2 Read 返回 0 當(dāng)成錯(cuò)誤處理現(xiàn)象服務(wù)端日志里莫名出現(xiàn) IOException“無法從傳輸連接中讀取數(shù)據(jù)”查代碼發(fā)現(xiàn)有人在 read 0 時(shí)直接拋了異常。原因TCP 對(duì)端正常關(guān)閉時(shí)Read 返回 0這是 EOF不是錯(cuò)誤。把 0 當(dāng)異常處理客戶端主動(dòng)斷開后服務(wù)端就要多拋一次無意義異常還可能掩蓋真正的斷線邏輯。解決recv 循環(huán)里 read 0 一律走正常斷開分支釋放資源、清理會(huì)話不打印堆棧。收到 0 就表示對(duì)方不會(huì)再發(fā)數(shù)據(jù)了后續(xù)也可以從業(yè)務(wù)狀態(tài)里標(biāo)記在線離線。這樣“對(duì)端正常退出”和“網(wǎng)絡(luò)異常中斷”兩個(gè)語(yǔ)義被分開前者靜默處理后者走重連。4.3 NetworkStream.Write 不一定一次全寫進(jìn)去現(xiàn)象發(fā)送大報(bào)文時(shí)對(duì)端收到的數(shù)據(jù)被截?cái)嗷蛘叱霎惓?“無法將數(shù)據(jù)寫入傳輸連接”。很多人以為 Stream.Write 和 Read 一樣能寫多少寫多少。實(shí)際上 NetworkStream.Write 會(huì)嘗試寫完所有字節(jié)但對(duì)于正處于限速或緩沖滿的 socket底層會(huì)出現(xiàn)部分寫入。原因套接字發(fā)送緩沖區(qū)滿、對(duì)端接收速度跟不上、Nagle 與延遲 ACK 相互作用都可能導(dǎo)致單次寫操作無法完全耗盡你的數(shù)據(jù)。解決自己實(shí)現(xiàn)一個(gè)發(fā)送全量數(shù)據(jù)的函數(shù)循環(huán)補(bǔ)寫直到所有字節(jié)都落進(jìn) socket 緩沖或者發(fā)生異常退出private static async Task WriteAllAsync(NetworkStream stream, byte[] frame) { int offset 0; while (offset frame.Length) { int written await stream.WriteAsync(frame, offset, frame.Length - offset); if (written 0) { throw new SocketException((int)SocketError.ConnectionReset); } offset written; } }如果只在 C# 里使用 TcpClientNetworkStream.Write 本身做了全量保證這個(gè)函數(shù)可作為防御層如果你改用 Socket.Send這個(gè)循環(huán)就是必須的。注意粘包、半包的工作交給第 3 章的幀解析發(fā)送端不要為了“省流量”而合并多條消息也不要為了“防粘包”故意把消息拆開發(fā)送。發(fā)送端只保證幀完整寫入接收端只負(fù)責(zé)按幀邊界解析各司其職。4.4 跨線程訪問 UI 控件現(xiàn)象WinForms / WPF 程序里Recv 線程處理完消息后直接給 TextBox 或日志控件賦值調(diào)試時(shí)拋“跨線程操作無效”或者控件顯示卡頓、閃退。原因UI 控件只能在創(chuàng)建它的線程主線程上操作。Socket 接收回調(diào)在 ThreadPool 線程上執(zhí)行直接訪問控件就是非法操作。網(wǎng)上的簡(jiǎn)單源碼大多數(shù)忽略了這層一放真實(shí)項(xiàng)目必然翻車。解決把要更新的內(nèi)容打包切換到同步上下文。WinForms 就用 BeginInvokeWPF 用 Dispatcherprivate void AppendLog(string message) { if (txtLog.InvokeRequired) { txtLog.BeginInvoke(new Action(() txtLog.AppendText(message Environment.NewLine))); } else { txtLog.AppendText(message Environment.NewLine); } }注意 BeginInvoke 是異步的接收線程不會(huì)停下來等 UI這樣高頻消息時(shí)也能流暢追加。如果消息量很大建議在接收線程只把原始幀塞進(jìn)隊(duì)列UI 用自己的 Timer 周期性取隊(duì)列消費(fèi)避免每條消息都跨線程這個(gè)模型放到 5.3 的生產(chǎn)者消費(fèi)者部分講。4.5 端口被占用或 backlog 設(shè)置錯(cuò)誤現(xiàn)象服務(wù)端重啟時(shí)報(bào) SocketException “通常每個(gè)套接字地址協(xié)議/網(wǎng)絡(luò)地址/端口只允許使用一次”或者客戶端連接被拒絕。多個(gè)實(shí)例同時(shí)監(jiān)聽同一個(gè)端口是最常見原因但還有個(gè)隱蔽場(chǎng)景上一次程序退出時(shí)連接沒釋放干凈端口進(jìn)入 TIME_WAIT。原因TCP 主動(dòng)關(guān)閉方會(huì)進(jìn)入 TIME_WAIT持續(xù) 2MSL約 1-4 分鐘期間端口不能立即復(fù)用。如果服務(wù)器在代碼里主動(dòng) Close 了監(jiān)聽 socket但沒有關(guān)閉所有客戶端連接重啟時(shí)監(jiān)聽端口就可能被占用。解決監(jiān)聽 socket 設(shè)置 ExclusiveAddressUse 為 false 并打開 ReuseAddress允許端口快速重用listener.Server.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true); listener.Server.ExclusiveAddressUse false; listener new TcpListener(IPAddress.Any, 9000);但注意這只解決監(jiān)聽端口復(fù)用不能解決客戶端連接復(fù)用?？蛻舳酥鲃?dòng)斷開前要調(diào)用 Shutdown(SocketShutdown.Both) 讓對(duì)端感知再關(guān)閉這樣 TIME_WAIT 留在客戶端側(cè)而不是服務(wù)端側(cè)。服務(wù)端被動(dòng)斷開不會(huì)產(chǎn)生 TIME_WAIT所以服務(wù)端要盡量避免作為主動(dòng)關(guān)閉方。5. 多客戶端接入與心跳?；畎淹婢咦兂赡苡每蚣?.1 ConcurrentDictionary 管理在線客戶端前面的 HandleClientAsync 處理完一個(gè)客戶端就結(jié)束了多個(gè)客戶端同時(shí)連接時(shí)任務(wù)之間互相不知道對(duì)方的存在。要支撐心跳檢查和廣播就需要一個(gè)全局字典把連接標(biāo)識(shí)映射到客戶端狀態(tài)。我一般這么組織public class ClientSession { public string Id { get; set; } public TcpClient Tcp { get; set; } public NetworkStream Stream { get; set; } public volatile int LastAliveTick; public CancellationTokenSource Cts { get; } new(); } ConcurrentDictionarystring, ClientSession _sessions new();客戶端接入時(shí)生成一個(gè)唯一 IdGuid.NewGuid().ToString(N)注冊(cè)進(jìn)字典。接收線程退出后從字典移除。用 ConcurrentDictionary 而不是普通 Dictionary是因?yàn)楸O(jiān)聽線程、業(yè)務(wù)線程、心跳巡檢線程會(huì)同時(shí)讀寫字典普通 Dictionary 在高并發(fā)下會(huì)內(nèi)部狀態(tài)損壞甚至死鎖。LastAliveTick 用 volatile int每次接收到任何字節(jié)就更新為 Environment.TickCount。為什么不用 DateTime.Now因?yàn)榄h(huán)境可能被校時(shí)機(jī)器時(shí)鐘往回跳會(huì)讓“最后活躍時(shí)間”倒退導(dǎo)致心跳超時(shí)誤判。Environment.TickCount 是開機(jī)以來的毫秒數(shù)單調(diào)遞增雖然 25 天左右會(huì)翻轉(zhuǎn)到負(fù)數(shù)但差值計(jì)算不受翻轉(zhuǎn)影響比如 now - lastAliveTick 只要注意用 int 運(yùn)算短連接場(chǎng)景完全夠。5.2 服務(wù)端心跳巡檢超時(shí)沒消息就斷開TCP 長(zhǎng)連接有一個(gè)問題客戶端斷電、網(wǎng)線拔掉、路由重啟時(shí)本端不會(huì)立刻收到 FIN 或 RST連接就像“假死”。要探測(cè)假死就得靠應(yīng)用層心跳。我通常在協(xié)議里加兩個(gè)命令字0x01 PING0x02 PONG?？蛻舳嗣扛?10 秒發(fā) PING服務(wù)端收到 PING 就回 PONG服務(wù)端同時(shí)記錄 LastAliveTick。巡檢線程每 2 秒掃一遍所有會(huì)話如果 now - LastAliveTick 超過 30 秒就強(qiáng)制斷開。這里參數(shù)不能隨便拍PING 10 秒、巡檢 2 秒、超時(shí) 30 秒。超時(shí)比 PING 間隔大 3 倍是為了容忍網(wǎng)絡(luò)瞬時(shí)抖動(dòng)和 GC 卡頓避免誤殺正?？蛻舳?。超時(shí)設(shè)成 6 秒局域網(wǎng)還有可能跨交換機(jī)稍微一擁塞就全斷。private async Task WatchdogLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { await Task.Delay(2000, token); foreach (var kv in _sessions.ToArray()) { ClientSession s kv.Value; if (Environment.TickCount - s.LastAliveTick 30_000) { s.Cts.Cancel(); // 中斷阻塞在 ReadAsync 的線程 } } } }這里的高頻操作是遍歷字典并檢查時(shí)間不涉及鎖。取消用的是 CancellationTokenSource不是因?yàn)?ReadAsync 必須用它而是因?yàn)樗芨蓛舻匕炎枞械慕邮昭h(huán)打斷。HandleClientAsync 里要把 s.Cts.Token 傳給 ReadAsyncint read await s.Stream.ReadAsync(buffer, 0, buffer.Length, s.Cts.Token);一旦 CancelReadAsync 拋 OperationCanceledException接收循環(huán)退出finally 里關(guān)閉連接并移出字典。注意不要直接調(diào)用 tcp.Close() 去打斷 ReceiveClose 同時(shí)會(huì)釋放 Socket 句柄接收線程可能還在操作一個(gè)已釋放的句柄導(dǎo)致 ObjectDisposedException 滿天飛。先 Cancel 讓接收線程自己退出再用 using 清理資源是這個(gè)方案的關(guān)鍵順序。5.3 客戶端斷線重連與生產(chǎn)者消費(fèi)者隊(duì)列客戶端側(cè)要做的和 Timing 無關(guān)只要記住斷線是常態(tài)重連要有退避。我常用的重連循環(huán)是int retry 1; while (true) { try { await tcp.ConnectAsync(ip, port); break; // 連上 } catch (SocketException) { int delay Math.Min(5000, 200 * (1 Math.Min(retry, 5))); await Task.Delay(delay); retry; } }退避從 200ms 起步每次翻倍封頂 5 秒。連上后 retry 重置為 1。不能做成每隔 5 秒固定重試因?yàn)榉?wù)器重啟那幾秒內(nèi)連接會(huì)密集失敗退避能避免把服務(wù)器日志刷爆。業(yè)務(wù)數(shù)據(jù)不直接塞給 NetworkStream而是放進(jìn)一個(gè)有界隊(duì)列由單一發(fā)送協(xié)程消費(fèi)。這就是生產(chǎn)者消費(fèi)者模型好處是削峰防止業(yè)務(wù)線程追趕網(wǎng)絡(luò)線程導(dǎo)致內(nèi)存無上限增長(zhǎng)。var queue new BlockingCollectionbyte[](boundedCapacity: 1024); async Task SendLoopAsync(CancellationToken token) { foreach (byte[] frame in queue.GetConsumingEnumerable(token)) { await WriteAllAsync(session.Stream, frame); } }boundedCapacity 設(shè)為 1024 時(shí)隊(duì)列滿后生產(chǎn)端會(huì)阻塞這是背壓機(jī)制業(yè)務(wù)方必須等網(wǎng)絡(luò)消費(fèi)完才能繼續(xù)生產(chǎn)而不是無限堆內(nèi)存。真實(shí)項(xiàng)目里遇到內(nèi)存暴漲先查這里是不是有界隊(duì)列。這樣一套組合下來服務(wù)端和客戶端都有了連接管理、幀解析、心跳、斷線重連、背壓保護(hù)。源碼不再是一坨演示代碼而是一個(gè)能撐住真實(shí)業(yè)務(wù)流量的骨架。6. 壓測(cè)與上線前檢查跑滿 50 連接 x 2000 次回顯再說寫個(gè)小壓測(cè)工具比嘴上說“沒問題”可靠得多。我習(xí)慣這樣驗(yàn)證50 個(gè)并發(fā)連接每個(gè)連接連續(xù)發(fā) 2000 條回顯消息每條消息帶 GUID 校驗(yàn)只要一條對(duì)不上就算失敗。Parallel.For(0, 50, i { using var tcp new TcpClient(); tcp.Connect(127.0.0.1, 9000); using NetworkStream stream tcp.GetStream(); for (int j 0; j 2000; j) { string body $msg-{i}-{j}-{Guid.NewGuid():N}; byte[] frame BuildFrame(0x10, Encoding.UTF8.GetBytes(body)); WriteAllAsync(stream, frame).GetAwaiter().GetResult(); byte[] reply ReadOneFrame(stream); if (Encoding.UTF8.GetString(reply) ! body) { throw new Exception($mismatch {i}-{j}); } } Console.WriteLine($conn {i} done); });壓測(cè)通過不代表上線無憂我再順手做三件事先用 netstat -an 確認(rèn)沒有大量 CLOSE_WAIT 堆積再觀察服務(wù)端內(nèi)存發(fā)送端隊(duì)列有沒有無限增長(zhǎng)最后把日志級(jí)別調(diào)到 Debug確認(rèn)沒有半包重組異常和重連風(fēng)暴。這套流程走完我心里才踏實(shí)。做上位機(jī)頭兩年我也迷信過異步高性能那一套后來發(fā)現(xiàn)通訊系統(tǒng)的坑從來不在 API 層級(jí)而在幀邊界、心跳時(shí)序、資源釋放這些基礎(chǔ)細(xì)節(jié)上。參數(shù)是死的網(wǎng)絡(luò)是活的這些底盤沒搭穩(wěn)換個(gè)框架照樣翻車。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取