簡介TCP/IP客戶端與服務(wù)端源碼是一份面向網(wǎng)絡(luò)編程初學(xué)者和進階開發(fā)者的可運行示例工程以C#語言實現(xiàn)完整的Socket通信流程覆蓋從套接字創(chuàng)建、地址綁定、監(jiān)聽連接到數(shù)據(jù)收發(fā)與關(guān)閉連接的全過程可用于理解TCP三次握手與四次揮手在實際代碼中的對應(yīng)實現(xiàn)。資源包共38個文件以cs源碼、config配置、exe可執(zhí)行程序、dll依賴庫和sln工程文件為主壓縮包僅73KB結(jié)構(gòu)緊湊打開工程即可編譯運行適合快速上手。目前已有1371人學(xué)習(xí)可見其內(nèi)容具有較高參考價值。通過閱讀這份代碼讀者能直接對照TCP/IP協(xié)議棧的關(guān)鍵步驟觀察客戶端與服務(wù)端如何通過bind、listen、accept、connect等接口協(xié)作并借此掌握網(wǎng)絡(luò)編程中的地址結(jié)構(gòu)初始化、字節(jié)序轉(zhuǎn)換等細(xì)節(jié)為后續(xù)開發(fā)實際網(wǎng)絡(luò)應(yīng)用打下扎實基礎(chǔ)。1. TCP/IP 客戶端與服務(wù)端源碼一份能直接跑通的 Socket 通信骨架寫網(wǎng)絡(luò)通信代碼最尷尬的不是算法難而是你打開一臺 Linux 機器想把兩個進程用 TCP/IP 連通卻發(fā)現(xiàn)自己卡在 socket() 和 accept() 的返回碼上。這份 TCP/IP 創(chuàng)建客戶端和服務(wù)端源碼就是一套拿來能跑的 Socket 通信骨架C 和 Java 兩套實現(xiàn)服務(wù)端、客戶端各一份完整代碼從 bind、listen、accept 到 connect、send、recv覆蓋 TCP 連接的全生命周期。它能幫你在一小時內(nèi)把通信鏈路建起來再把端口復(fù)用、粘包、斷線重連這些“玄學(xué)”問題逐個講透。適合做上位機、嵌入式或者課程設(shè)計的人也適合那些把 Socket 當(dāng)黑匣子、想拆開看一次真實握手的同學(xué)。2. 先把通信模型立起來Socket 流程、阻塞 IO 與源碼包結(jié)構(gòu)2.1 三次握手在代碼里長什么樣connect 與 accept 的配合關(guān)系理解這套源碼之前先弄清楚一件事TCP 的三次握手和系統(tǒng)調(diào)用不是一一對應(yīng)的很多人誤以為 accept 返回就是握手完成其實握手完成得更早?？蛻舳苏{(diào)用 connect() 時內(nèi)核發(fā)出 SYN服務(wù)端內(nèi)核在收到 SYN 后自動回 SYNACK這個過程根本不需要應(yīng)用層代碼干預(yù)客戶端收到后回 ACK連接進入 ESTABLISHED。服務(wù)端的 accept() 只是從內(nèi)核維護的已完成連接隊列里“取”一個連接出來。服務(wù)端這邊的調(diào)用順序是 socket() - bind() - listen() - accept()。listen() 傳入的 backlog 參數(shù)決定內(nèi)核里兩個隊列的上限一個是半連接隊列存只發(fā)了 SYN 的連接一個是全連接隊列存完成握手的連接。backlog 設(shè)得太小高并發(fā)下客戶端會連不進來表現(xiàn)是 connect 超時或連接被重置?？蛻舳诉@邊的順序更短socket() - connect()。connect() 是阻塞調(diào)用它要等到三次握手完成或者超時才返回。所以當(dāng)你看到 connect 返回 0不代表服務(wù)端應(yīng)用已經(jīng) accept只代表 TCP 層握手完成。這也是客戶端剛 connect 成功就立刻發(fā)數(shù)據(jù)偶爾會遇到服務(wù)端還沒 accept 的一個原因——TCP 層已經(jīng)就緒但應(yīng)用層還沒來得及創(chuàng)建處理線程。正是這種錯位讓很多人第一次調(diào) Socket 時摸不著頭腦。把這條時間線梳理清楚再看代碼就不慌了。2.2 為什么這套源碼選阻塞 IO可讀性優(yōu)先并發(fā)交給線程代碼里用的是最傳統(tǒng)的阻塞式 socket沒有上 epoll、select 或者 Reactor 模型。原因很實際這份資源的核心目標(biāo)是讓讀者一次看懂 TCP 通信的完整鏈路。阻塞模型下服務(wù)端 accept 阻塞等待連接recv 阻塞等待數(shù)據(jù)每一行代碼的意圖都非常直白適合做教學(xué)骨架和課程設(shè)計底子。阻塞模型的問題也很明顯一個線程同時只能處理一個連接的讀寫。如果服務(wù)端做成單線程 accept 再循環(huán) recv那第一個客戶端不發(fā)送數(shù)據(jù)第二個客戶端就永遠(yuǎn)等不到被 accept。這份源碼在 C 版里用“主循環(huán) accept 短連接處理”來規(guī)避這個問題Java 版則直接上了線程池每個連接一個任務(wù)。如果日后要處理高并發(fā)長連接正確路線是切到非阻塞 epoll或者直接用 Netty。但那是把模型吃透之后的事不建議一上來就從 epoll 寫起。選型方面我建議你按這個標(biāo)準(zhǔn)判斷聯(lián)調(diào)工具、課程設(shè)計、小型內(nèi)部服務(wù)阻塞 IO 完全夠用連接數(shù)上千、需要支撐長連接推送的業(yè)務(wù)再考慮非阻塞。下表把兩條路的差別列一下免得方向選錯對比項阻塞 IO 多線程非阻塞 IO epoll每連接資源開銷一個線程約 8MB 虛擬機內(nèi)存一個 fd幾個 KB 狀態(tài)支撐連接數(shù)幾百封頂上萬很輕松代碼可讀性線性邏輯容易理解回調(diào)驅(qū)動心智負(fù)擔(dān)大調(diào)試難度直接看棧就能定位狀態(tài)機錯誤非常隱蔽典型場景工具、課程設(shè)計、小型服務(wù)網(wǎng)關(guān)、游戲服、高并發(fā)推送2.3 源碼包的文件構(gòu)成C 和 Java 雙實現(xiàn)的分工與編譯入口這套資源里最重要的四個文件是 C 版服務(wù)端、C 版客戶端、Java 版服務(wù)端、Java 版客戶端。文件命名和用途如下表所示文件語言職責(zé)tcp_server.cC阻塞式服務(wù)端綁定 8080 端口收到消息原樣回寫tcp_client.cC阻塞式客戶端連接本機 8080發(fā)送消息并接收回顯TcpServer.javaJava線程池服務(wù)端帶消息長度頭解析TcpClient.javaJava客戶端帶連接超時與自動重連邏輯文件結(jié)構(gòu)本身也暗示了一條學(xué)習(xí)路線先用 C 版跑通一次最小的收發(fā)再用 Java 版體會線程池和消息定界。C 版的代碼量和系統(tǒng)調(diào)用最少方便對照《TCP/IP 詳解》里講的那幾個 socket API 逐個驗證Java 版則是把工程上常見的問題連接超時、粘包、重連直接塞進了代碼里。編譯入口很簡單C 版用 gcc 一把過Java 版用 javac 編譯兩個類即可具體的命令行在下一章操作。3. C 語言版實現(xiàn)從 socket() 到 close() 的四個關(guān)鍵步驟3.1 服務(wù)端主循環(huán)bind、listen、accept 的職責(zé)邊界服務(wù)端代碼第一版建議直接做成單連接的 echo 服務(wù)邏輯最清晰。下面這段是完整的 C 服務(wù)端源碼#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 8080 #define BACKLOG 16 // listen 隊列長度并發(fā)低時 16 足夠 #define MAX_BUF 1024 int main() { int server_fd, client_fd; struct sockaddr_in addr; socklen_t addr_len sizeof(addr); char buf[MAX_BUF]; // 1. 創(chuàng)建 IPv4 的 TCP socket server_fd socket(AF_INET, SOCK_STREAM, 0); if (server_fd 0) { perror(socket); exit(1); } // 2. 設(shè)置 SO_REUSEADDR防止重啟時 TIME_WAIT 導(dǎo)致 bind 失敗 int opt 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); // 3. 綁定 0.0.0.0:8080 memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(PORT); addr.sin_addr.s_addr htonl(INADDR_ANY); // 監(jiān)聽所有網(wǎng)卡 if (bind(server_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(server_fd); exit(1); } // 4. 進入被動監(jiān)聽狀態(tài) if (listen(server_fd, BACKLOG) 0) { perror(listen); close(server_fd); exit(1); } printf(listening on port %d\n, PORT); // 5. 主循環(huán)accept 返回新 fd原始 fd 繼續(xù)監(jiān)聽 while (1) { client_fd accept(server_fd, (struct sockaddr *)addr, addr_len); if (client_fd 0) { perror(accept); continue; } // 這里只處理一條消息就關(guān)閉連接便于觀察完整生命周期 int n recv(client_fd, buf, MAX_BUF, 0); if (n 0) { buf[n] \0; printf(recv: %s\n, buf); send(client_fd, buf, n, 0); // 原樣回顯 } close(client_fd); } close(server_fd); return 0; }這段代碼里有三個邊界要注意。第一個是 bind 只綁定一次后面 accept 返回的 client_fd 才是和數(shù)據(jù)收發(fā)綁定的 socket很多初學(xué)者誤以為要重新 bind 新端口那是完全沒有理解四元組的概念。第二個是 backlog 設(shè)成 16在局域網(wǎng)聯(lián)調(diào)里完全夠用如果用 wrk、ab 這類工具壓測建議先提到 128 并觀察連接失敗率。第三個是 recv 的返回值返回 0 表示對端關(guān)閉返回 -1 要結(jié)合 errno 判斷是 EINTR被信號中斷還是其他錯誤不要無腦把 n 當(dāng)數(shù)據(jù)長度。3.2 客戶端實現(xiàn)connect 超時控制與循環(huán)收發(fā)客戶端的難點不在打通而在超時和半包處理。很多教程里的客戶端直接阻塞 connect一旦對端 IP 不可達(dá)默認(rèn)要等一百多秒才返回這在聯(lián)調(diào)現(xiàn)場根本等不起。我一般會用非阻塞 connect select 的方式把超時控制在一到三秒做法如下#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include errno.h #include sys/socket.h #include sys/select.h #include netinet/in.h #include arpa/inet.h #define SERVER_IP 127.0.0.1 #define SERVER_PORT 8080 int main() { int sock; struct sockaddr_in server_addr; char buf[1024]; sock socket(AF_INET, SOCK_STREAM, 0); if (sock 0) { perror(socket); exit(1); } memset(server_addr, 0, sizeof(server_addr)); server_addr.sin_family AF_INET; server_addr.sin_port htons(SERVER_PORT); inet_pton(AF_INET, SERVER_IP, server_addr.sin_addr); // 將 socket 設(shè)為非阻塞用于控制 connect 超時 int flags fcntl(sock, F_GETFL, 0); fcntl(sock, F_SETFL, flags | O_NONBLOCK); int ret connect(sock, (struct sockaddr *)server_addr, sizeof(server_addr)); if (ret 0 errno EINPROGRESS) { fd_set wfds; struct timeval tv {3, 0}; // 3 秒超時 FD_ZERO(wfds); FD_SET(sock, wfds); ret select(sock 1, NULL, wfds, NULL, tv); if (ret 0) { fprintf(stderr, connect timeout\\n); close(sock); exit(1); } // 此時還需檢查 SO_ERROR確認(rèn)沒有連接失敗 int err 0; socklen_t len sizeof(err); getsockopt(sock, SOL_SOCKET, SO_ERROR, err, len); if (err ! 0) { fprintf(stderr, connect error: %s\\n, strerror(err)); close(sock); exit(1); } } // 恢復(fù)阻塞模式后續(xù)收發(fā)阻塞等待即可 fcntl(sock, F_SETFL, flags); const char *msg hello tcp; send(sock, msg, strlen(msg), 0); int n recv(sock, buf, sizeof(buf), 0); if (n 0) { buf[n] \\0; printf(recv: %s\\n, buf); } close(sock); return 0; }說幾個容易翻車的細(xì)節(jié)。connect 返回 -1 且 errno 是 EINPROGRESS說明連接正在建立中這時用 select 監(jiān)聽這個 fd 的可寫事件可寫不代表連接成功所以要再 getsockopt 一次拿 SO_ERROR 才能確認(rèn)有沒有真正連上。select 返回 0 是超時連接已經(jīng)沒戲了直接 close 走人。至于 send 和 recv循環(huán)發(fā)送和循環(huán)接收的寫法跟文件讀寫完全一樣我上面的精簡版只處理了一次收發(fā)真實業(yè)務(wù)里建議寫成 while 循環(huán)直到把數(shù)據(jù)收完。3.3 編譯與聯(lián)調(diào)gcc 命令、啟動順序和 nc 驗證C 版兩個文件編譯非常簡單不需要任何外部庫gcc -o tcp_server tcp_server.c gcc -o tcp_client tcp_client.c建議的啟動順序是先運行服務(wù)端再運行客戶端。如果服務(wù)端沒有先啟動客戶端 connect 會直接返回 ECONNREFUSED。還可以用 nc 命令做一個快速的冒煙測試nc 相當(dāng)于一個不寫協(xié)議的極簡客戶端./tcp_server nc -v 127.0.0.1 8080啟動服務(wù)端后先用ss -lntp | grep 8080確認(rèn)端口狀態(tài)是 LISTEN再跑 nc輸入一行字符回車服務(wù)端終端會打印 recv 并將內(nèi)容原樣回顯。nc 驗證通過后再跑./tcp_client這時候服務(wù)端終端應(yīng)該打印recv: hello tcp。如果 nc 能通而 tcp_client 連不上那問題基本在客戶端 bind 或防火墻和協(xié)議無關(guān)。兩段聯(lián)調(diào)都通過C 版就算完全跑通了。4. Java 版實現(xiàn)線程池、斷線重連與消息定界4.1 服務(wù)端線程池模型別再做 one thread per connectionJava 版和 C 版最大的差別在線程模型。如果按最直觀的寫法來一個客戶端就 new 一個 Thread單機上三百個連接就能把內(nèi)存吃出壓力。更穩(wěn)妥的是用固定線程池讓連接處理排隊import java.io.*; import java.net.*; import java.util.concurrent.*; public class TcpServer { private static final int PORT 8080; private static final int THREADS 4; public static void main(String[] args) throws IOException { ExecutorService pool Executors.newFixedThreadPool(THREADS); try (ServerSocket serverSocket new ServerSocket(PORT)) { System.out.println(listening on port PORT); while (true) { Socket socket serverSocket.accept(); pool.execute(new ClientHandler(socket)); } } } static class ClientHandler implements Runnable { private final Socket socket; ClientHandler(Socket socket) { this.socket socket; } Override public void run() { try (DataInputStream in new DataInputStream(socket.getInputStream()); DataOutputStream out new DataOutputStream(socket.getOutputStream())) { int len in.readInt(); // 先讀 4 字節(jié)長度頭 byte[] data new byte[len]; in.readFully(data); // 按長度精準(zhǔn)讀取 String msg new String(data, UTF-8); System.out.println(recv: msg); byte[] resp (echo: msg).getBytes(UTF-8); out.writeInt(resp.length); // 回包也帶長度頭 out.write(resp); out.flush(); } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException ignored) {} } } } }線程池大小選 4這是基于雙核四線程機器上的一個保守值?？釉?accept 和 execute 之間的銜接socket 一旦被 accept 出來就由線程池接管主循環(huán)立刻回到 accept 等待新連接千萬不能在主線程里做 recv否則一個慢客戶端會堵住整個服務(wù)端。DataInputStream 的 readInt 是網(wǎng)絡(luò)字節(jié)序readFully 會持續(xù)阻塞讀取直到填滿整個數(shù)組這兩行配合在一起就天然地規(guī)避了 C 版里 recv 一次可能只收到半條消息的問題。4.2 客戶端斷線重連繞過“地址已在使用”的 TIME_WAIT 坑服務(wù)端已經(jīng)用上了線程池客戶端這邊也得解決兩個工程問題連接超時和自動重連。直接看代碼import java.io.*; import java.net.*; public class TcpClient { private static final String HOST 127.0.0.1; private static final int PORT 8080; private static final int MAX_RETRY 5; public static void main(String[] args) throws Exception { Socket socket connectWithRetry(HOST, PORT, MAX_RETRY); if (socket null) { System.err.println(give up after MAX_RETRY retries); return; } try (DataOutputStream out new DataOutputStream(socket.getOutputStream()); DataInputStream in new DataInputStream(socket.getInputStream())) { byte[] msg hello tcp with java.getBytes(UTF-8); out.writeInt(msg.length); out.write(msg); out.flush(); int respLen in.readInt(); byte[] resp new byte[respLen]; in.readFully(resp); System.out.println(recv: new String(resp, UTF-8)); } } private static Socket connectWithRetry(String host, int port, int maxRetries) throws InterruptedException { Socket socket null; for (int i 1; i maxRetries; i) { try { Socket s new Socket(); s.connect(new InetSocketAddress(host, port), 3000); // 3 秒超時 return s; } catch (IOException e) { System.err.println(attempt i failed: e.getMessage()); Thread.sleep(1000); } } return null; } }這里有個 Java 特有的細(xì)節(jié)new Socket() 之后如果不綁定本地地址直接 connect內(nèi)核會自動分配一個臨時端口TIME_WAIT 只落在那個臨時端口上下次重連會自動換新端口所以教程里常見的“客戶端 Address already in use”在 Java 里很少碰到。真正會觸發(fā)這個錯的是客戶端自己也調(diào)用了socket.bind(new InetSocketAddress(8081))固定本地端口這時候就必須在 bind 之前調(diào)用socket.setReuseAddress(true)順序反了就不生效。如果你將來寫 C# 或者 Modbus TCP 客戶端重連策略和 TIME_WAIT 的處理思路是完全一致的。4.3 報文邊界為什么裸 Socket 必須自己定義長度頭TCP 是字節(jié)流協(xié)議它自己不認(rèn)識“消息”。你 send 一次 100 字節(jié)服務(wù)端 recv 可能只拿到 30 字節(jié)也可能一次性拿到兩次 send 的數(shù)據(jù)。正因為這樣業(yè)務(wù)代碼必須定義消息邊界。Java 版用的是最常見的方案4 字節(jié)長度頭 變長消息體。發(fā)送時先寫 int 長度再寫內(nèi)容接收時先讀 int 再讀對應(yīng)長度的字節(jié)一收一送嚴(yán)格配對粘包和半包問題在應(yīng)用層就被解決了。如果一定要把定界方案講透實際上就是三個套路一是固定長度每條消息都補齊到固定字節(jié)數(shù)實現(xiàn)簡單但浪費帶寬二是分隔符比如 HTTP 用 CRLF 分割頭部但消息體里出現(xiàn)分隔符要轉(zhuǎn)義三是長度頭最通用也最省流量。這套 Java 源碼采用的是方案三這也是主流 RPC 框架的通用做法。C 版雖然沒有顯式做長度頭但你完全可以把 C 服務(wù)端改成同樣的協(xié)議先 recv 4 字節(jié)轉(zhuǎn)成整數(shù)再循環(huán) recv 該長度個字節(jié)改完后 C 和 Java 兩端的程序就能互相通信了。這是這套源碼最有價值的一個驗證實驗因為跨語言互通才是協(xié)議設(shè)計是否合理的試金石。5. 避坑與排查TCP 通信最常見的五個翻車現(xiàn)場5.1 服務(wù)端重啟就崩bind: Address already in use現(xiàn)象服務(wù)端進程被 kill 后立刻重新啟動bind 報錯 Address already in use過幾十秒再啟動又正常。原因主動關(guān)閉連接的一端會進入 TIME_WAIT 狀態(tài)默認(rèn)等待 60 秒。服務(wù)端關(guān)閉監(jiān)聽 fd 時上一個連接的 socket 還占著端口內(nèi)核不允許立刻 bind 同一個端口。解決在 bind 之前對 server_fd 設(shè)置 SO_REUSEADDR代碼里已經(jīng)這么做了。注意這個選項只對 TIME_WAIT 有效如果端口被一個正常運行中的進程占用設(shè)了也白設(shè)。調(diào)試時想避開這個坑最快的辦法是改端口或者用ss -tlnp | grep 8080把舊的占用進程找出來殺掉。5.2 聯(lián)調(diào)時間歇性連不上半連接隊列溢出現(xiàn)象客戶端手動重試幾次后能連上但第一次幾乎必失敗服務(wù)端日志和 accept 都沒報錯。原因客戶端 connect 的 SYN 到達(dá)服務(wù)端后如果半連接隊列已滿內(nèi)核會直接丟棄 SYN客戶端只能等超時重傳。最常在壓測或頻繁快速重連時出現(xiàn)。解決把 listen 的 backlog 調(diào)大比如從 16 改成 128同時用ss -lnt看服務(wù)端的 Send-Q 和 Recv-Q 雙重隊列水位。內(nèi)核參數(shù)net.ipv4.tcp_max_syn_backlog只在隊列達(dá)到上限時起作用業(yè)務(wù)側(cè)優(yōu)先調(diào) backlog。5.3 recv 返回 0 不一定是對端斷開了現(xiàn)象客戶端收到 recv 返回 0就打印“對端關(guān)閉”并關(guān)閉 socket結(jié)果服務(wù)端還能正常收發(fā)兩邊狀態(tài)完全對不上。原因recv 返回 0 表示沒有更多數(shù)據(jù)可讀這既可能是對端調(diào)用了 close()也可能是對端只調(diào)用了 shutdown(SHUT_WR) 做了半關(guān)閉。半關(guān)閉時對端仍然可以接收數(shù)據(jù)。解決協(xié)議設(shè)計上必須區(qū)分“不能再收”和“不再發(fā)”。如果業(yè)務(wù)不需要半關(guān)閉要求對端必須有應(yīng)用層再見消息比如先發(fā)一條 BYE 再 close收到 BYE 才釋放本地資源。我在實際項目里就吃過這個虧后來所有內(nèi)部協(xié)議一律強制帶關(guān)閉碼絕不用 recv 返回值判斷連接生死。5.4 客戶端一次 send 服務(wù)端多次 recv粘包與半包現(xiàn)象客戶端 send 了 “hello” 和 “world”服務(wù)端第一次 recv 可能就收到 “helloworld”也可能只收到 “hel”。原因TCP 是流式協(xié)議包和包之間沒有分隔符。Nagle 算法會把小包合并網(wǎng)絡(luò)擁塞會把大包拆開recv 拿到的字節(jié)流和 send 的邊界沒有必然關(guān)系。解決應(yīng)用層自己劃邊界最穩(wěn)的是長度頭方案。C 版至少要改成“先 recv 4 字節(jié)長度再按長度循環(huán)讀”不能相信單次 recv 一次性拿完整條消息。Java 版已經(jīng)用了 DataInputStream 的 readInt readFully這個問題天然規(guī)避了。5.5 telnet 通了但程序聯(lián)調(diào)就是不行協(xié)議測試工具選錯現(xiàn)象telnet 到 8080 端口能進隨手敲的 abc 也有回顯換成自己寫的客戶端服務(wù)端解析出來的全是亂碼或者報錯。原因telnet 發(fā)送的是裸字節(jié)回車換行是它自己加的。如果服務(wù)端協(xié)議是“固定長度頭 消息體”telnet 敲進去的內(nèi)容缺了長度頭服務(wù)端自然拆不出來。解決不要用 telnet 測自定義二進制協(xié)議。我在聯(lián)調(diào)階段習(xí)慣直接用 nc 配合 printf 構(gòu)造帶長度頭的報文比如發(fā)一條長度 5 的字符串printf \x00\x00\x00\x05hello | nc -v 127.0.0.1 8080四個字節(jié)的前綴是按網(wǎng)絡(luò)字節(jié)序?qū)懙拈L度 5后面緊跟消息體。這樣測出來如果服務(wù)端還是解析失敗問題就在服務(wù)端長度解算邏輯上和工具無關(guān)了。測試工具選對能幫你省掉一半排障時間。6. 驗證與進階用 tcpdump 回放三次握手6.1 tcpdump 抓包把三次握手和回顯全流程看一遍代碼跑通之后建議做一次抓包驗證確認(rèn)你看到的代碼行為就是 TCP 層真實發(fā)生的事。抓本機回環(huán)口最簡單sudo tcpdump -i lo -nn -S tcp port 8080啟動 tcpdump 后再運行 tcp_client你會看到五類四元組報文客戶端發(fā)Flags [S]服務(wù)端回Flags [S.]客戶端再回Flags [.]這是三次握手。之后跟著的是Flags [P.]意思是帶數(shù)據(jù)的報文就是客戶端發(fā)的 “hello tcp”。最后的Flags [F.]出現(xiàn)兩次代表雙方各發(fā)了一次 FIN四次揮手也齊了。數(shù)一遍握手報文和揮手報文如果少了最后一個 ACK說明對端可能處于 TIME_WAIT 還沒完全釋放正好對應(yīng)避坑章節(jié)講過的現(xiàn)象。6.2 壓測與回歸驗證形成自己的聯(lián)調(diào)清單驗證做扎實之后我建議你固定的幾件事每次改完協(xié)議代碼先跑一遍 C 版客戶端到 C 版服務(wù)端的冒煙再跑 Java 客戶端到 Java 服務(wù)端最后做一次交叉驗證C 客戶端連 Java 服務(wù)端三層都通過才算協(xié)議沒破。壓測階段可以寫一個簡單的并發(fā)腳本用 nc 開啟多個連接同時發(fā)消息觀察服務(wù)端是否出現(xiàn) accept 失敗或者 CPU 飆升那能暴露線程池配置是否合理。從那以后我每次寫完一套 TCP 聯(lián)調(diào)都會先在另一終端把 tcpdump 掛上確認(rèn)握手?jǐn)?shù)量正確、報文邊界沒亂再進入業(yè)務(wù)邏輯調(diào)試這個習(xí)慣幫我省下了無數(shù)次抓耳撓腮。希望幫到你。本文還有配套的精品資源點擊獲取