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