做了這么多年的后端開發(fā)我?guī)缀趺扛魩滋炀蜁煌禄蛘咦x者問同一個問題TCP/IP協(xié)議到底該怎么學(xué)socket網(wǎng)絡(luò)編程又該怎么寫說真的這兩件事從來就不是割裂的——TCP/IP 是網(wǎng)絡(luò)通信的規(guī)則socket 是代碼里握住這套規(guī)則的那只手。誰先理解了這兩者的關(guān)系誰就已經(jīng)繞開了大半的網(wǎng)絡(luò)編程坑。今天我把從原理到代碼的完整套路拆出來不講廢話只講實(shí)操適合正在學(xué) TCP/IP、socket或者已經(jīng)被“端口被占用”這類報錯折磨過的人。這份內(nèi)容會覆蓋三個層面先講原理幫你把 TCP/IP 和 socket 的對應(yīng)關(guān)系焊死在腦子里再講代碼用 C# 和 Python 寫一套最小可用的服務(wù)端和客戶端然后講排錯把熱詞里反復(fù)出現(xiàn)的幾個報錯逐個拆解。最后我還會補(bǔ)充 C 語言的實(shí)現(xiàn)要點(diǎn)和 VBA 調(diào) Winsock 的另類玩法這也是很多人實(shí)際項(xiàng)目中會遇到的需求。1. 先理清 TCP/IP 和 socket 到底是干嘛的1.1 網(wǎng)絡(luò)分層不是八股文是排查問題的地圖很多人一看到“TCP/IP 四層模型”就頭大覺得這是面試題跟寫代碼沒關(guān)系。其實(shí)完全不是這樣。你寫 socket 代碼時遇到的每一個參數(shù)、每一個報錯都能在分層模型里找到位置。我習(xí)慣用一個寄快遞的類比來講應(yīng)用層你寫的內(nèi)容比如一段 JSON 數(shù)據(jù)。傳輸層快遞單上面寫著“從哪個端口來到哪個端口去”——TCP 端口就是干這個的。網(wǎng)絡(luò)層物流路線規(guī)劃決定包裹怎么從 A 城市到 B 城市——IP 地址就是干這個的。鏈路層快遞車實(shí)際跑的公路和高速公路。你寫 socket 的時候其實(shí)是在傳輸層和應(yīng)用層的交界處工作。你不需要關(guān)心數(shù)據(jù)怎么走物理鏈路那是 IP 層和鏈路層的事你要關(guān)心的是數(shù)據(jù)怎么可靠地到達(dá)對方應(yīng)用的某個端口這是 TCP 負(fù)責(zé)的事。而 socket 就是操作系統(tǒng)提供給你的一扇門你往門里扔數(shù)據(jù)TCP 會幫你打包好、按序發(fā)送、丟失重傳你從門里取數(shù)據(jù)TCP 已經(jīng)把對方發(fā)來的字節(jié)流按順序放在了門口。這就能解釋為什么很多人學(xué) socket 一開始痛苦你明明只是想發(fā)一條消息結(jié)果要寫 bind、listen、accept、connect、recv、send 一堆函數(shù)。其實(shí)每個函數(shù)對應(yīng)的是 TCP 狀態(tài)機(jī)的一個階段理解了這個映射代碼就不再是死記硬背。1.2 端口占用的本質(zhì)四元組決定了誰能用這個地址熱詞里有一個非常經(jīng)典的報錯Windows Socket Error: 通常每個套接字地址(協(xié)議/網(wǎng)絡(luò)地址/端口)只允許使用一次。這個報錯出現(xiàn)的原因一點(diǎn)都不神秘。TCP 連接是由一個四元組唯一確定的也就是源 IP、源端口、目的 IP、目的端口。而你要啟動一個服務(wù)必須綁定一個 IP 和端口相當(dāng)于在自己家門前掛一個門牌號。如果這個門牌號已經(jīng)被別人掛了你就掛不上去。端口是一個 16 位的整數(shù)范圍是 0 到 65535。其中 0 到 1023 是特權(quán)端口一般需要管理員權(quán)限才能綁定1024 到 49151 是注冊端口49152 到 65535 是動態(tài)端口是客戶端臨時連接時用的。你在本地開發(fā)時8080、443、3306 這些端口太常用了稍微不留神就會沖突。我之前遇到過一種特別隱蔽的情況服務(wù)明明已經(jīng)退出了但端口還是被占著。原因就是 TCP 的 TIME_WAIT 狀態(tài)。主動關(guān)閉連接的一方在發(fā)送最后一個 ACK 之后并不會立刻釋放連接而是要等 2MSL最大報文段生存時間的時間確認(rèn)網(wǎng)絡(luò)上殘留的數(shù)據(jù)包都已經(jīng)消失。這個狀態(tài)下的端口看起來還是被占用的但其實(shí)是協(xié)議棧自己在“打掃衛(wèi)生”。這也是為什么很多服務(wù)端程序在 bind 之前都要先設(shè)置SO_REUSEADDR。它告訴系統(tǒng)如果 TIME_WAIT 狀態(tài)占了端口不用擔(dān)心可以復(fù)用。1.3 三次握手和四次揮手在代碼里對應(yīng)什么TCP 三次握手是所有教材都會講的內(nèi)容但很少有人告訴你握手不是你在代碼里寫出來的而是內(nèi)核幫你完成的。你調(diào)用connect()時內(nèi)核開始發(fā)起三次握手。你調(diào)用accept()時內(nèi)核已經(jīng)完成了握手把建立好的連接放在隊(duì)列里等著你取。你調(diào)用close()時內(nèi)核開始四次揮手。所以說白了socket API 不是 TCP 本身而是 TCP 狀態(tài)的“遙控器”。你按一下 connectTCP 開始握手你按一下 closeTCP 開始揮手。你在代碼里看不到 SYN、SYN-ACK、ACK 這些報文除非你用 Wireshark 抓包。但是理解握手對排查問題非常有用。比如你發(fā)現(xiàn)客戶端 connect 卡了很久才失敗那很可能是網(wǎng)絡(luò)不通SYN 發(fā)出去沒人回如果客戶端 connect 直接返回“連接被拒絕”那說明目標(biāo)主機(jī)收到了 SYN但那個端口根本沒有進(jìn)程在 listen。這兩種情況在現(xiàn)象上都是“連不上”但排查方向完全不同。前者查路由、防火墻、丟包后者查服務(wù)端進(jìn)程到底有沒有啟動。四次揮手里最值得關(guān)注的也是 TIME_WAIT。每次主動關(guān)閉連接的一方都要等 2MSL。如果服務(wù)端頻繁主動斷開連接你會發(fā)現(xiàn)大量 TIME_WAIT 狀態(tài)的連接堆積端口被暫時占滿新連接就進(jìn)不來了。后面講排錯的時候我會再展開。2. 從零寫一個最簡 TCP 服務(wù)端和客戶端2.1 為什么我用 C# 寫服務(wù)端用 Python 寫客戶端寫 TCP 示例語言選擇其實(shí)很講究。我選了 C# 和 Python 的組合原因有三個第一熱詞里出現(xiàn)了“C# socket receiving receive 回調(diào)”說明很多人確實(shí)在用 C# 做網(wǎng)絡(luò)服務(wù)尤其是做桌面工具、上位機(jī)、內(nèi)部服務(wù)的人特別多。C# 的 socket API 封裝得比較順手寫起來不像 C 語言那么繁瑣但底層模型又能看得清。第二Python 的 socket 模塊是標(biāo)準(zhǔn)庫三行代碼就能起一個連接。它非常適合快速驗(yàn)證服務(wù)端的行為不用編譯、不用 NuGet 包適合初學(xué)者做實(shí)驗(yàn)。第三這兩個語言的 API 幾乎能一對一對應(yīng)上。你把 Python 的socket.socket()換成 C# 的new Socket()把bind換成Bind把recv換成Receive概念完全一致。語言差異不會成為理解 TCP 的障礙反而能讓你看清楚哪些東西是 socket 共通的。2.2 C# 服務(wù)端同步阻塞版完整代碼我用的是 .NET 8控制臺項(xiàng)目核心代碼就這么一段using System.Net; using System.Net.Sockets; using System.Text; TcpListener listener new TcpListener(IPAddress.Any, 8080); listener.Start(5); Console.WriteLine(服務(wù)端已啟動監(jiān)聽端口 8080 ...); while (true) { TcpClient client await listener.AcceptTcpClientAsync(); Console.WriteLine($客戶端接入{client.Client.RemoteEndPoint}); _ HandleClientAsync(client); } async Task HandleClientAsync(TcpClient client) { using (client) using (NetworkStream stream client.GetStream()) { byte[] buffer new byte[1024]; while (true) { int length await stream.ReadAsync(buffer, 0, buffer.Length); if (length 0) { Console.WriteLine(客戶端斷開連接。); break; } string message Encoding.UTF8.GetString(buffer, 0, length); Console.WriteLine($收到{message}); byte[] resp Encoding.UTF8.GetBytes(服務(wù)器已收到: message); await stream.WriteAsync(resp); } } }這里有幾個點(diǎn)值得解釋。IPAddress.Any表示監(jiān)聽本機(jī)所有網(wǎng)卡地址。這在本地開發(fā)時看著無所謂但如果你只監(jiān)聽127.0.0.1那局域網(wǎng)里的其他機(jī)器就永遠(yuǎn)連不進(jìn)來如果你監(jiān)聽IPAddress.Any那所有網(wǎng)卡 IP 都能連。生產(chǎn)環(huán)境里這是第一個要明確的參數(shù)。listener.Start(5)里的數(shù)字是 accept 隊(duì)列的長度不是最大連接數(shù)。它的意思是TCP 完成握手但還沒被AcceptTcpClientAsync取走的連接最多能排幾個隊(duì)。隊(duì)列滿了之后新的連接請求就會被內(nèi)核拒絕。這個參數(shù)對高并發(fā)服務(wù)有影響但對本文的測試場景5 已經(jīng)夠用。2.3 Python 客戶端三行連上去import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 8080)) client.sendall(你好我是 Python 客戶端.encode(utf-8)) resp client.recv(1024) print(resp.decode(utf-8)) client.close()注意sendall和send的區(qū)別。send可能只發(fā)送了一部分?jǐn)?shù)據(jù)就返回了它返回的是實(shí)際發(fā)送的字節(jié)數(shù)sendall會循環(huán)發(fā)送直到所有數(shù)據(jù)都發(fā)出去。在 TCP 這種字節(jié)流協(xié)議里永遠(yuǎn)不要假設(shè)“一次 send 就發(fā)完了所有數(shù)據(jù)”這是新手最容易踩的坑之一。2.4 一次完整的調(diào)試過程我最推薦的試驗(yàn)順序是先啟動 C# 服務(wù)端再運(yùn)行 Python 客戶端。服務(wù)端會打印出客戶端的 IP 和端口客戶端會收到回顯。這里有個非常直觀的體驗(yàn)?zāi)銜l(fā)現(xiàn)客戶端connect()連接成功的瞬間服務(wù)端才打印“客戶端接入”。但實(shí)際上三次握手在connect()返回之前就已經(jīng)完成了。也就是說connect 成功 握手完成 服務(wù)端 accept 隊(duì)列里已經(jīng)有這個連接了。如果你在服務(wù)端收到了客戶端的數(shù)據(jù)但代碼里ReadAsync讀出來的卻是亂碼那 99% 是編碼問題。我習(xí)慣全鏈路統(tǒng)一 UTF-8。C# 里是Encoding.UTF8Python 里是encode(utf-8)/decode(utf-8)。兩邊不一致中文幾乎必亂。3. 別在 recv 里死等BeginReceive 回調(diào)的標(biāo)準(zhǔn)寫法3.1 同步接收為什么會讓程序“卡死”如果你是做 WinForms、WPF 客戶端程序的一定體驗(yàn)過界面卡死的痛苦。原因很簡單你在 UI 線程里調(diào)用了Receive()或者ReadAsync()但那個線程又沒有真的異步操作它只能在那里等數(shù)據(jù)。UI 線程被占住界面自然就動不了了。就算你用了async/await只要上下文是在 UI 線程上恢復(fù)的也會出現(xiàn)類似的問題。最穩(wěn)妥的做法是用回調(diào)模型你告訴 socket “數(shù)據(jù)到了你就叫我”然后 UI 線程繼續(xù)該干嘛干嘛數(shù)據(jù)到了之后系統(tǒng)在后臺線程池里執(zhí)行你的回調(diào)函數(shù)。這也是熱詞里“C# socket receiving receive 回調(diào)”指向的核心內(nèi)容。下面我給出一個實(shí)戰(zhàn)中常用的模式。3.2 BeginReceive 回調(diào)的標(biāo)準(zhǔn)套路public class TcpEchoClient { private Socket _socket; private byte[] _buffer new byte[4096]; private readonly StringBuilder _receivedData new StringBuilder(); public void Start(Socket socket) { _socket socket; ReceiveLoop(); } private void ReceiveLoop() { try { _socket.BeginReceive(_buffer, 0, _buffer.Length, SocketFlags.None, ReceiveCallback, null); } catch (SocketException ex) { Console.WriteLine($接收啟動失敗{ex.SocketErrorCode}); } } private void ReceiveCallback(IAsyncResult ar) { int length; try { length _socket.EndReceive(ar); } catch (SocketException ex) { Console.WriteLine($連接異常{ex.SocketErrorCode}); return; } if (length 0) { string data Encoding.UTF8.GetString(_buffer, 0, length); _receivedData.Append(data); Console.WriteLine($收到{data}); ReceiveLoop(); } else { Console.WriteLine(對端關(guān)閉連接。); _socket.Close(); } } }這個模式有三個關(guān)鍵點(diǎn)。第一_buffer必須是類的字段不能是局部變量。因?yàn)锽eginReceive是異步的你傳入的緩沖區(qū)如果被垃圾回收了回調(diào)執(zhí)行時會出大問題。把它放在類字段里等于告訴 GC這塊內(nèi)存我還用著。第二回調(diào)結(jié)束前必須啟動下一次BeginReceive。TCP 是持續(xù)流你收完一包數(shù)據(jù)后如果不馬上再掛一次接收回調(diào)后續(xù)的數(shù)據(jù)就沒人接收了。這里最容易踩的坑是忘記在回調(diào)里繼續(xù)調(diào)用ReceiveLoop()結(jié)果只能收到第一段數(shù)據(jù)。第三用EndReceive獲取實(shí)際長度。很多人錯誤地直接用_buffer.Length作為有效數(shù)據(jù)的長度這是不行的。緩沖區(qū)長度是 4096但實(shí)際收到的可能只有 200 字節(jié)。EndReceive的返回值才是真實(shí)數(shù)據(jù)長度。3.3 粘包和半包繞不過去的坎寫 TCP 程序永遠(yuǎn)會遇到粘包和半包。我在給新同事培訓(xùn)時總喜歡用一個比喻來解釋TCP 是字節(jié)流不是消息流。它就像一條水管你在 A 端往里面扔了三個乒乓球在 B 端拿到的可能是兩個球、一個球、半顆球、三顆球粘在一起……總之TCP 不保證消息邊界。解決方案有很多我推薦最通用的一種長度頭。也就是在發(fā)送消息之前先發(fā)一個 4 字節(jié)的整數(shù)告訴對端這條消息有多長然后再發(fā)消息本身。接收端先讀 4 字節(jié)算出消息長度再讀對應(yīng)長度的數(shù)據(jù)。這個方案的代碼并不復(fù)雜但它是所有 RPC 框架、消息中間件的基石。理解它之后你再看 Redis RESP 協(xié)議、HTTP 的 Content-Length會發(fā)現(xiàn)全都是一個套路。4. 進(jìn)階Python/C#/C 三語言對照與 VBA 的另類玩法4.1 Python 寫 TCP 服務(wù)端最適合快速復(fù)現(xiàn)問題如果你不想每次測試都編譯一次 C# 程序Python 的socketserver模塊能讓你在 30 秒內(nèi)起一個多線程 TCP 服務(wù)from socketserver import ThreadingTCPServer, StreamRequestHandler class Handler(StreamRequestHandler): def handle(self): data self.rfile.readline() print(f收到{data.decode(utf-8).strip()}) self.wfile.write(bpong\n) server ThreadingTCPServer((0.0.0.0, 9000), Handler) server.serve_forever()這段代碼天然支持多客戶端并發(fā)。每次有客戶端連進(jìn)來ThreadingTCPServer都會起一個新的線程處理。它特別適合用來驗(yàn)證我的協(xié)議設(shè)計(jì)到底合不合理粘包問題到底出在客戶端還是服務(wù)端4.2 C 語言實(shí)現(xiàn)從原理到字節(jié)熱詞里出現(xiàn)了“tcp ip sockets 編程 c語言實(shí)現(xiàn)”如果你把 C# 和 Python 都跑通了再看 C 語言其實(shí)就那幾步。我用最精簡的方式列一下核心骨架#include stdio.h #include string.h #include unistd.h #include arpa/inet.h int main() { int server_fd; struct sockaddr_in addr; server_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr INADDR_ANY; addr.sin_port htons(8080); bind(server_fd, (struct sockaddr*)addr, sizeof(addr)); listen(server_fd, 5); while (1) { struct sockaddr_in client_addr; socklen_t len sizeof(client_addr); int client_fd accept(server_fd, (struct sockaddr*)client_addr, len); char buffer[1024] {0}; int n read(client_fd, buffer, sizeof(buffer)); printf(收到: %s\n, buffer); write(client_fd, pong, 4); close(client_fd); } return 0; }C 語言最大的特點(diǎn)是所有參數(shù)都暴露在你面前。sockaddr_in結(jié)構(gòu)體里的sin_family、sin_addr.s_addr、sin_port對應(yīng)著你在 C# 里寫的AddressFamily、IPAddress、Port。htons這個函數(shù)也特別有意思它把主機(jī)字節(jié)序轉(zhuǎn)成網(wǎng)絡(luò)字節(jié)序。因?yàn)椴煌?CPU 的字節(jié)序不一樣TCP/IP 協(xié)議規(guī)定網(wǎng)絡(luò)上統(tǒng)一用大端所以你在手動填充端口號時必須轉(zhuǎn)換。很多人覺得 C 語言難其實(shí)難的不是 API而是內(nèi)存和指針。但正因?yàn)殡y寫過一次 C 版本之后你再看任何語言的 socket 接口都會覺得非常輕松。4.3 VBA 用 Winsock 調(diào) Telnet別笑真有這種需求熱詞里還有一條非常罕見的“VBA 代碼實(shí)現(xiàn) telnet 的 window socket 調(diào)用”。你可能覺得 VBA 都是用來寫 Excel 宏的怎么會跟網(wǎng)絡(luò)編程扯上關(guān)系實(shí)際情況是有些老舊的工控系統(tǒng)、路由器管理接口、儀器設(shè)備只提供 Telnet 或者裸 TCP 接口。企業(yè)里又沒有專門的 IT 團(tuán)隊(duì)業(yè)務(wù)人員只能用 Excel 做數(shù)據(jù)收集。這時候有人會用 VBA 的 Winsock 控件來實(shí)現(xiàn) TCP 通信。思路是這樣在 VBA 工程里插入MSWinsock.Winsock控件然后Winsock1.RemoteHost 192.168.1.100 Winsock1.RemotePort 23 Winsock1.Connect 在 DataArrival 事件中接收數(shù)據(jù) Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long) Dim strData As String Winsock1.GetData strData Debug.Print strData End Sub你會發(fā)現(xiàn)控件的Connect、DataArrival、GetData本質(zhì)上就是 socket 的connect、recv、read。它的事件驅(qū)動模型和 C# 的BeginReceive回調(diào)是同一個思路。所以我一直覺得socket 編程不局限于語言理解了模型走到哪個平臺都認(rèn)得它。5. 故障排查綁定失敗、防火墻、連接被重置5.1 端口被占用failed to create server shutdown socket 報錯實(shí)戰(zhàn)記錄熱詞里有一整條錯誤信息格式是“failed to create server shutdown socket on address [localhost] and port [802…]”。這個報錯看起來很長很嚇人但本質(zhì)上就一句話這個地址和端口已經(jīng)被占用了操作系統(tǒng)不讓你重復(fù)綁定。我在本機(jī)復(fù)現(xiàn)過這個錯誤。我先起了一個 Java 應(yīng)用監(jiān)聽 8020 端口然后在沒有停掉它的情況下又啟動 Tomcat日志里就出現(xiàn)了failed to create server shutdown socket on address [localhost] and port [8020]。為什么叫 shutdown socket因?yàn)?Tomcat 默認(rèn)會開一個本地 socket用來監(jiān)聽 shutdown 命令。它綁定失敗只影響關(guān)閉指令但應(yīng)用還能正常啟動所以很多人會忽略這個警告。不過后面你真正想關(guān)閉服務(wù)時就會發(fā)現(xiàn)關(guān)不掉——因?yàn)槟莻€監(jiān)聽 shutdown 的 socket 根本沒起來。遇到端口占用不要猜直接用命令查系統(tǒng)查端口命令查進(jìn)程命令殺進(jìn)程命令Windowsnetstat -ano | findstr 8080tasklist | findstr PIDtaskkill /F /PID PIDLinuxss -lntp | grep 8080或lsof -i:8080ps -ef | grep PIDkill -9 PID查出來之后如果那個進(jìn)程確實(shí)沒用了直接殺掉再重啟你的服務(wù)問題立刻解決。5.2 連接還活著但端口報錯TIME_WAIT 和 SO_REUSEADDR還有一種情況比上面的更隱蔽。服務(wù)端代碼里有個 bug導(dǎo)致連接釋放不正?；蛘邷y試腳本頻繁地 connect、close你會看到 error 信息是“通常每個套接字地址(協(xié)議/網(wǎng)絡(luò)地址/端口)只允許使用一次”。這時候用netstat -ano查看端口狀態(tài)你可能會看到一堆TIME_WAIT。這些連接還沒有完全死透端口暫時被占。這個問題有兩個解決方向。第一在代碼里設(shè)置SO_REUSEADDR。C 語言里就是setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt))C# 里用SocketOptionName.ReuseAddressPython 里就是s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。這個選項(xiàng)告訴內(nèi)核如果端口上殘留的是 TIME_WAIT 狀態(tài)的連接可以復(fù)用。第二在客戶端也盡量避免頻繁地創(chuàng)建和關(guān)閉連接。我見過有些測試程序在循環(huán)里對同一個服務(wù)不斷 connect/close壓測沒做多少先把端口搞滿了。這種場景下要么用持久連接要么把 TIME_WAIT 的回收參數(shù)調(diào)快。5.3 服務(wù)明明啟動了外部卻連不上監(jiān)聽地址和防火墻很多人本地測試一切正常一到部署就給客戶報“連不上”。我排查這類問題有固定順序。先確認(rèn)監(jiān)聽地址。netstat -ano看服務(wù)端監(jiān)聽的本地地址。如果監(jiān)聽的是127.0.0.1:8080那只有本機(jī)能連如果監(jiān)聽的是0.0.0.0:8080才是所有網(wǎng)卡都可以連。多網(wǎng)卡服務(wù)器上這個區(qū)別尤其明顯。再看防火墻。Windows 上第一次啟動 TCP 服務(wù)時系統(tǒng)通常會彈窗詢問是否允許通信。如果你點(diǎn)了取消或者部署時根本沒注意到這個彈窗外部連接就會被 Windows 防火墻靜默阻斷。Linux 服務(wù)器則要檢查firewalld或ufw的規(guī)則。最后看云服務(wù)商的安全組。這是個特別容易被人忽略的點(diǎn)。很多云服務(wù)器默認(rèn)只開放少數(shù)端口你在服務(wù)器內(nèi)部怎么測都通但外部就是進(jìn)不來問題就在安全組規(guī)則里沒有放行對應(yīng)的端口。5.4 連接被重置Recv 返回 0 和 SocketException 的區(qū)別還有一個經(jīng)驗(yàn)分享想寫出來。TCP 斷開有兩種情況如果對端正常關(guān)閉recv/Receive會返回 0。在 C# 的BeginReceive回調(diào)里EndReceive返回 0 就是正常關(guān)閉。如果對端異常退出、斷電、程序崩潰你這邊會收到一個SocketException錯誤碼通常是ConnectionReset。它的含義是對端發(fā)了一個 RST 報文把連接強(qiáng)行重置了。這兩種情況在業(yè)務(wù)代碼里一定要區(qū)別處理。前者是“對方說再見了”后者是“對方突然消失”。如果你不區(qū)分把 RST 也當(dāng)作正常斷開那你的服務(wù)端可能永遠(yuǎn)不知道對端已經(jīng)異常退出還會繼續(xù)占著資源和內(nèi)存。6. 最后聊點(diǎn)實(shí)際的寫到這里核心內(nèi)容已經(jīng)講完了。最后說幾句經(jīng)驗(yàn)之談。我調(diào)網(wǎng)絡(luò)程序有個習(xí)慣服務(wù)端代碼里第一件事就加上 SO_REUSEADDR不管什么語言先把這個“端口復(fù)用”選項(xiàng)打開。它不會帶來副作用但在你頻繁重啟服務(wù)、遇到 TIME_WAIT 時能幫你省掉一晚上排查時間。第二個習(xí)慣是寫代碼前先用 Python 把協(xié)議跑通再換 C# 或 C 去落地。Python 足夠快足夠簡單能讓你把精力聚焦在協(xié)議本身上而不是被語言特性絆住腳。我做的很多項(xiàng)目都是先用 Python 腳本模擬客戶端再拿 C# 寫正式服務(wù)端這套流程非常穩(wěn)。最后一個建議一定要學(xué)會看抓包。Wireshark 裝上不難難的是你肯不肯在“為什么收不到數(shù)據(jù)”的時候打開抓包軟件看一眼。三次握手有沒有完成SYN 有沒有發(fā)出ACK 有沒有回來這些問題的答案全在數(shù)據(jù)包里。代碼不會騙你報文更不會騙你。TCP/IP 和 socket 這條路說難也難說簡單也簡單。難在你如果只看理論就永遠(yuǎn)隔著一層紗簡單在你只要動手寫過一兩個服務(wù)端和客戶端很多概念自然就通了。希望這篇能幫你把那層紗捅破。