有一段時(shí)間我在內(nèi)網(wǎng)批量跑同一組數(shù)值計(jì)算每臺(tái)機(jī)器裝完整運(yùn)行環(huán)境太不值當(dāng)就想著把計(jì)算邏輯收斂成一個(gè)常駐服務(wù)客戶端只負(fù)責(zé)發(fā)請求和收結(jié)果。這個(gè)小需求后來演變成了一個(gè)網(wǎng)絡(luò)計(jì)算器項(xiàng)目把自定義套接字、序列化、守護(hù)進(jìn)程三個(gè)點(diǎn)完整串了一遍也讓我把很多課本上似是而非的概念落到了實(shí)處。這篇內(nèi)容適合三類人剛學(xué)完 Socket API 想找一個(gè)完整項(xiàng)目練手的、工作中需要自己定義二進(jìn)制協(xié)議做服務(wù)間通信的、以及一直沒搞懂守護(hù)進(jìn)程到底是怎么脫離終端的人。我會(huì)從需求拆解講起給出協(xié)議設(shè)計(jì)、序列化代碼、socket 鏈路、daemon 化實(shí)現(xiàn)最后放上完整的驗(yàn)證過程和踩坑記錄。所有關(guān)鍵選擇我都會(huì)把理由說透而不是只貼一段能跑的代碼。1. 為什么要做一個(gè)網(wǎng)絡(luò)計(jì)算器三個(gè)技術(shù)點(diǎn)缺一不可1.1 從本地函數(shù)調(diào)用到遠(yuǎn)程請求難點(diǎn)換了位置本地計(jì)算器在代碼里就是個(gè)函數(shù)調(diào)用參數(shù)通過棧寄存器傳進(jìn)去返回值放寄存器里程序內(nèi)部天然共享內(nèi)存不存在數(shù)據(jù)怎么表達(dá)的問題。一旦變成網(wǎng)絡(luò)計(jì)算器客戶端和服務(wù)端是兩個(gè)獨(dú)立進(jìn)程中間只有一條字節(jié)流通道難點(diǎn)立刻從算法轉(zhuǎn)移到三件事上數(shù)據(jù)表示double、int 這些值在內(nèi)存里怎么排列換一臺(tái)機(jī)器還能不能解析錯(cuò)誤傳達(dá)除零、非法操作符這類錯(cuò)誤怎么從服務(wù)端回到客戶端而不是只能靠打印日志連接生命周期客戶端請求到一半斷開、服務(wù)端同時(shí)接多個(gè)連接時(shí)各自怎么收場。我當(dāng)時(shí)把這三件事分別對應(yīng)成了協(xié)議設(shè)計(jì)、錯(cuò)誤碼約定、并發(fā)模型一旦拆開想項(xiàng)目結(jié)構(gòu)就很清楚了。這也是我堅(jiān)持不用現(xiàn)成框架的最主要原因框架會(huì)把這些問題藏起來而藏起來的問題最終會(huì)在性能和可維護(hù)性上還債。1.2 項(xiàng)目拆解協(xié)議、服務(wù)端、客戶端三件套我按照關(guān)注點(diǎn)把代碼拆成了三塊目錄結(jié)構(gòu)大致如下calc/ ├── protocol.h # 協(xié)議頭結(jié)構(gòu)體、序列化接口聲明 ├── protocol.c # 序列化 / 反序列化實(shí)現(xiàn) ├── server.c # 套接字監(jiān)聽、連接處理、計(jì)算邏輯 ├── client.c # 客戶端套接字、請求發(fā)送與結(jié)果解析 ├── calc_daemon.c # 守護(hù)進(jìn)程化入口 └── Makefile協(xié)議單獨(dú)放一個(gè)文件就是為了以后傳輸層換掉比如換 UNIX Domain Socket或換 HTTP 包裝序列化和業(yè)務(wù)代碼都不用動(dòng)。服務(wù)端只關(guān)心如何接收協(xié)議、如何解析、如何回包客戶端只關(guān)心如何組裝協(xié)議、如何解釋響應(yīng)。這套解耦思路就算不用 C 實(shí)現(xiàn)換 Python、Go 也一樣成立。1.3 為什么不用現(xiàn)成 RPC 框架非要自己寫套接字當(dāng)時(shí)完全可以搭一個(gè) Nginx 后端或者用 gRPC但需求本身就是一個(gè)計(jì)算接口引入整套 RPC 框架的收益遠(yuǎn)小于成本。自己寫自定義套接字的價(jià)值在于協(xié)議里每個(gè)字節(jié)都是自己定通信過程中的粘包、半包、字節(jié)序、連接中斷這些問題都會(huì)真實(shí)地暴露出來而不是被框架藏起來。尤其在一些資源受限或者內(nèi)網(wǎng)極簡環(huán)境里一個(gè)裸 socket 服務(wù)能省掉 HTTP 頭部解析的開銷知識(shí)和收益都實(shí)在。還有一層原因今天看 gRPC、Thrift 這些成熟方案底層核心其實(shí)都是四件事——傳輸通道、序列化格式、消息調(diào)度、連接管理。把自定義套接字這一層親手打通再去看那些框架源碼就不會(huì)一頭霧水所以我強(qiáng)烈建議這個(gè)項(xiàng)目要自己寫不要一上來就套庫。2. 序列化協(xié)議把12變成字節(jié)流2.1 內(nèi)存里的結(jié)構(gòu)體不能直接扔進(jìn)網(wǎng)絡(luò)很多人第一步會(huì)想直接把 C 結(jié)構(gòu)體發(fā)出去不就行了還真不行。結(jié)構(gòu)體在內(nèi)存里有字節(jié)對齊比如一個(gè)結(jié)構(gòu)體里同時(shí)有 char 和 double編譯器會(huì)在中間插入 padding 字節(jié)不同平臺(tái)、不同編譯選項(xiàng)下的布局都可能不同。加上還有大小端字節(jié)序的問題同樣一個(gè) 0x12345678x86 小端機(jī)器和 ARM 大端機(jī)器在內(nèi)存里的排列完全相反。直接把結(jié)構(gòu)體指針交給 send()等于讓通訊雙方賭運(yùn)氣。序列化要做的事就是把內(nèi)存中的結(jié)構(gòu)化數(shù)據(jù)按一種雙方都認(rèn)可的規(guī)則變成一長串可靠的字節(jié)流接收端再按同一套規(guī)則還原。打個(gè)比方序列化是打包快遞你按固定尺寸裝箱并寫好物品清單反序列化是收快遞的人按清單拆箱驗(yàn)收中間任何一步少填或多填都會(huì)出問題。2.2 協(xié)議格式頭部和負(fù)載分開設(shè)計(jì)我給這個(gè)網(wǎng)絡(luò)計(jì)算器定了一個(gè)很小的二進(jìn)制協(xié)議頭部固定 12 字節(jié)字段長度字節(jié)說明magic4固定魔數(shù)用于校驗(yàn)傳輸對象防止錯(cuò)收垃圾數(shù)據(jù)version1協(xié)議版本方便未來演進(jìn)cmd10x01 請求0x02 響應(yīng)error1錯(cuò)誤碼0 成功非 0 表示失敗原因reserved1保留字段置 0payload_len4負(fù)載長度網(wǎng)絡(luò)字節(jié)序負(fù)載部分根據(jù) cmd 分兩種。請求負(fù)載字段長度字節(jié)說明x8double第一個(gè)操作數(shù)y8double第二個(gè)操作數(shù)op10加1減2乘3除reserved3對齊用保留位于是請求包總長 12 頭 20 負(fù)載 32 字節(jié)。響應(yīng)負(fù)載是 8 字節(jié)的 double 結(jié)果總長 20 字節(jié)。這樣設(shè)計(jì)的好處是按長度讀協(xié)議頭再用頭里的 payload_len 決定還要讀多少負(fù)載天然解決粘包問題后面會(huì)展開說。2.3 手寫序列化的核心代碼我用的 C協(xié)議結(jié)構(gòu)體如下typedef struct { uint32_t magic; uint8_t version; uint8_t cmd; uint8_t error; uint8_t reserved; uint32_t payload_len; } calc_header; typedef struct { double x; double y; uint8_t op; uint8_t reserved[3]; } calc_request; typedef struct { double result; } calc_response;序列化函數(shù)不再直接 memcpy 整個(gè)結(jié)構(gòu)體而是逐個(gè)字段寫入。整數(shù)用 htonl 轉(zhuǎn)網(wǎng)絡(luò)字節(jié)序浮點(diǎn)數(shù)我先把內(nèi)存復(fù)制成 64 位整數(shù)再轉(zhuǎn)成大端寫進(jìn)緩沖。這些 endian 轉(zhuǎn)換函數(shù)在 Linux glibc 的endian.h里都有macOS 上要換成NSSwapBigLongLongToHost那一套static void write_double(uint8_t **p, double value) { uint64_t v; memcpy(v, value, sizeof(v)); v htobe64(v); memcpy(*p, v, sizeof(v)); *p sizeof(v); } static double read_double(const uint8_t **p) { uint64_t v; memcpy(v, *p, sizeof(v)); v be64toh(v); double d; memcpy(d, v, sizeof(d)); *p sizeof(v); return d; }序列化請求時(shí)先寫頭部再寫負(fù)載int serialize_request(uint8_t *buf, size_t buf_size, const calc_request *req) { size_t need sizeof(calc_header) 20; if (buf_size need) return -1; uint8_t *p buf; calc_header hdr { .magic htonl(0xCAFE1234), .version CALC_VERSION, .cmd CMD_REQUEST, .error 0, .reserved 0, .payload_len htonl(20), }; memcpy(p, hdr, sizeof(hdr)); p sizeof(hdr); write_double(p, req-x); write_double(p, req-y); *p req-op; *p 0; *p 0; *p 0; return (int)(p - buf); }反序列化時(shí)最要緊的是先校驗(yàn)int deserialize_request(const uint8_t *buf, size_t len, calc_request *out) { if (len sizeof(calc_header)) return -1; const uint8_t *p buf; calc_header hdr; memcpy(hdr, p, sizeof(hdr)); uint32_t magic ntohl(hdr.magic); if (magic ! 0xCAFE1234) return -1; if (hdr.version ! CALC_VERSION) return -1; if (hdr.cmd ! CMD_REQUEST) return -1; uint32_t plen ntohl(hdr.payload_len); if (plen ! 20 || len sizeof(calc_header) plen) return -1; p sizeof(calc_header); out-x read_double(p); out-y read_double(p); out-op *p; return 0; }代碼里兩次 memcpy 繞開了浮點(diǎn)數(shù)類型雙關(guān)的未定義行為看起來多復(fù)制了幾次但十六字節(jié)的數(shù)據(jù)量對 CPU 來說完全可以忽略換來的是跨平臺(tái)安全。2.4 為什么不直接選 JSON 或現(xiàn)成序列化庫我也想過直接用 JSON請求體寫成{x:1,y:2,op:0}服務(wù)端用 json-c 解析。后來發(fā)現(xiàn)三個(gè)問題第一JSON 是文本協(xié)議double 轉(zhuǎn)字符串再轉(zhuǎn)回 double中間有精度損耗風(fēng)險(xiǎn)有些浮點(diǎn)值打印出來就是不定長小數(shù)第二每次都要完整解析 JSON 樹在計(jì)算服務(wù)這種高頻小請求場景解析開銷占比太大第三JSON 沒有天然的二進(jìn)制長度限制防御邊界要自己加反而更麻煩。至于 Redis 序列化方案或 Java/PHP 那套自帶序列化機(jī)制它們在其他場景當(dāng)然順手但基本都是語言相關(guān) 自帶元信息對固定結(jié)構(gòu)的計(jì)算請求來說太重了。像 Protocol Buffers 這種優(yōu)秀方案各方面都成熟但引入編譯器工具鏈和額外運(yùn)行時(shí)對一個(gè)想要吃透底層原理的教學(xué)項(xiàng)目來說反而成了負(fù)擔(dān)。手寫 32 字節(jié)的小協(xié)議每個(gè)字段都是自己定的未來想加校驗(yàn)和、加密、壓縮都能在一行代碼里看出來改在哪。3. 套接字鏈路從 socket() 到 recv() 的完整實(shí)現(xiàn)3.1 服務(wù)端主循環(huán)bind、listen、accept服務(wù)端流程是教科書式的但每個(gè)環(huán)節(jié)都有細(xì)節(jié)。第一個(gè)是SO_REUSEADDR如果服務(wù)剛被 kill 掉端口還在 TIME_WAIT 狀態(tài)不設(shè)置這個(gè)選項(xiàng) bind 會(huì)直接報(bào) Address already in use第二個(gè)是 listen 的 backlog 參數(shù)內(nèi)核會(huì)在 accept 之前幫你暫存建立好的連接這個(gè)值太小突發(fā)連接數(shù)上來會(huì)丟連接。我在主進(jìn)程里只做 accept每接到一個(gè)連接就用 fork 開一個(gè)子進(jìn)程去處理主進(jìn)程繼續(xù)等待新連接int srv_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(srv_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr {0}; addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(port); bind(srv_fd, (struct sockaddr*)addr, sizeof(addr)); listen(srv_fd, 16); while (1) { struct sockaddr_in cli_addr; socklen_t cli_len sizeof(cli_addr); int conn_fd accept(srv_fd, (struct sockaddr*)cli_addr, cli_len); if (conn_fd 0) continue; pid_t pid fork(); if (pid 0) { close(srv_fd); handle_connection(conn_fd); close(conn_fd); exit(0); } close(conn_fd); signal(SIGCHLD, SIG_IGN); }signal(SIGCHLD, SIG_IGN)是讓系統(tǒng)直接回收子進(jìn)程資源否則發(fā)起幾十次請求后進(jìn)程表里會(huì)堆積一堆僵尸進(jìn)程到時(shí)候ps看起來會(huì)非常詭異。3.2 客戶端請求路徑connect、send、recv客戶端更簡單但同樣有細(xì)節(jié)。connect 要等三次握手完成才能繼續(xù)如果目標(biāo)服務(wù)沒起來connect 會(huì)返回ECONNREFUSED。我遇到的坑是服務(wù)器啟動(dòng)慢客戶端立刻連接會(huì)失敗重試最好帶個(gè)退避間隔別死循環(huán)打日志?？蛻舳税l(fā)送序列化好的請求時(shí)不能指望一次 send 就把全部字節(jié)發(fā)出去。send 返回值表示實(shí)際寫入內(nèi)核發(fā)送緩沖的字節(jié)數(shù)大包或 TCP 窗口繁忙時(shí)可能只發(fā)一半。所以我封裝了一個(gè)循環(huán)發(fā)送int send_all(int fd, const void *buf, size_t len) { const uint8_t *p buf; size_t sent 0; while (sent len) { ssize_t n send(fd, p sent, len - sent, 0); if (n 0) { if (errno EINTR) continue; return -1; } sent n; } return 0; }同樣讀響應(yīng)時(shí)也要處理半包不能假設(shè)一次 recv 就把整個(gè)響應(yīng)拿回來。3.3 粘包、半包靠協(xié)議頭里的 payload_len 解決這是整個(gè)項(xiàng)目最有教學(xué)價(jià)值的部分。TCP 是字節(jié)流協(xié)議不保留應(yīng)用層的消息邊界?？蛻舳诉B續(xù)發(fā)兩個(gè) 32 字節(jié)請求服務(wù)端 recv 一次可能收到 64 字節(jié)反過來一個(gè) 32 字節(jié)請求也可能被拆成 16 16 兩次到達(dá)。所以代碼里永遠(yuǎn)不能假設(shè)一次 recv 等于一條消息。正確做法是先把 12 字節(jié)協(xié)議頭讀完整解析出 payload_len再按這個(gè)長度循環(huán)讀取剩余負(fù)載。我把讀取封裝成了 recv_fullint recv_full(int fd, uint8_t *buf, size_t len) { size_t got 0; while (got len) { ssize_t n recv(fd, buf got, len - got, 0); if (n 0) return -1; // 對端關(guān)閉 if (n 0) { if (errno EINTR) continue; return -1; } got n; } return 0; }處理連接時(shí)先把頭部整個(gè)收下來再從頭部里拿 payload_lenuint8_t hdr_buf[12]; if (recv_full(conn_fd, hdr_buf, sizeof(hdr_buf)) 0) return; calc_header hdr; memcpy(hdr, hdr_buf, sizeof(hdr)); uint32_t plen ntohl(hdr.payload_len); if (plen MAX_PAYLOAD_LEN) { /* 回錯(cuò)誤包并關(guān)閉 */ } uint8_t payload[MAX_PAYLOAD_LEN]; if (recv_full(conn_fd, payload, plen) 0) return;如果說 send_all 是照顧發(fā)送端recv_full 就是照顧接收端兩頭都對齊之后粘包和半包問題就不復(fù)存在了。3.4 并發(fā)模型的選擇進(jìn)程、線程還是 epoll這個(gè)項(xiàng)目我選了 fork 進(jìn)程模型一個(gè)重要原因是邏輯最簡單子進(jìn)程里就算把請求處理崩了主進(jìn)程和其他連接都不受影響。每個(gè)連接的處理流程是固定的接收請求、解析、計(jì)算、回包、關(guān)閉。但進(jìn)程模型不是萬能的。每次 fork 都要復(fù)制進(jìn)程表項(xiàng)連接數(shù)量上百后開銷明顯。如果進(jìn)一步擴(kuò)展我會(huì)改成單線程 epoll 事件循環(huán)把每個(gè)連接做成一個(gè)狀態(tài)機(jī)EPOLLIN 就繼續(xù)收包收完整條消息再發(fā)響應(yīng)。也可以用線程池但對計(jì)算量幾乎為零的加法和減法來說線程池的意義不在于加速而在于復(fù)用一個(gè)線程處理多個(gè)連接。這個(gè)選擇取決于你能容忍的復(fù)雜度如果只是學(xué)習(xí)自定義套接字fork 模型和 epoll 模型各跑一遍是最好的對比實(shí)驗(yàn)。4. 守護(hù)進(jìn)程化讓計(jì)算服務(wù)不再依賴終端4.1 為什么 nohup 也不行必須真正 daemon 化寫完 server直接./calc_server能跑但 SSH 一斷開會(huì)話結(jié)束shell 向進(jìn)程組發(fā) SIGHUP服務(wù)就沒了。這時(shí)候有人會(huì)想到nohup ./calc_server nohup 只是讓進(jìn)程忽略 SIGHUP可它仍然屬于當(dāng)前會(huì)話如果有其他信號(hào)或需要系統(tǒng)服務(wù)管理還是會(huì)出現(xiàn)各種奇怪關(guān)聯(lián)。要么寫 systemd unit要么在程序內(nèi)部做標(biāo)準(zhǔn) daemon 化。既然標(biāo)題是守護(hù)進(jìn)程我自然選擇后者自己把整條鏈敲一遍。4.2 daemon 化五步每一步都有防御目的我封了一個(gè) daemonize 函數(shù)核心步驟如下void daemonize(void) { pid_t pid fork(); if (pid 0) exit(1); if (pid 0) _exit(0); // 第一步父進(jìn)程退出 if (setsid() 0) exit(1); // 第二步創(chuàng)建新會(huì)話 pid fork(); if (pid 0) exit(1); if (pid 0) _exit(0); // 第三步二次 fork chdir(/); // 第四步工作目錄變成根目錄 umask(0); // 放開文件創(chuàng)建掩碼 int fd open(/dev/null, O_RDWR); // 第五步重定向標(biāo)準(zhǔn)三流 if (fd 0) { dup2(fd, 0); dup2(fd, 1); int logfd open(/var/log/calcd.log, O_WRONLY | O_CREAT | O_APPEND, 0644); if (logfd 0) dup2(logfd, 2); } }我來解釋每一步的意義第一次 fork 后讓父進(jìn)程退出是讓終端認(rèn)為命令已經(jīng)結(jié)束服務(wù)進(jìn)程被 1 號(hào)進(jìn)程收養(yǎng)不再受當(dāng)前 shell 的作業(yè)控制。setsid 會(huì)創(chuàng)建一個(gè)新會(huì)話調(diào)用進(jìn)程變成會(huì)話首進(jìn)程從而脫離原來進(jìn)程組的控制終端。第二次 fork 不是必須的但非常重要會(huì)話首進(jìn)程一旦重新打開終端設(shè)備是有可能重新獲得控制終端的而二次 fork 后的子進(jìn)程不是會(huì)話首進(jìn)程徹底杜絕了這種可能。chdir(/) 是為了進(jìn)程不占用原工作目錄避免文件系統(tǒng)的加載/卸載被這個(gè)進(jìn)程擋住。umask(0) 是為了讓后續(xù)創(chuàng)建日志、pid 文件時(shí)不被默認(rèn)掩碼裁剪權(quán)限避免明明設(shè)置了 0644 卻變成 0600這種怪事。重定向標(biāo)準(zhǔn)三流是為了讓程序內(nèi)的 printf/日志函數(shù)不會(huì)往已經(jīng)失效的終端寫。4.3 pid 文件和日志運(yùn)維不能靠猜daemon 進(jìn)程沒有終端想停掉它不能靠 CtrlC只能靠 kill 和 pid。我在啟動(dòng)參數(shù)里增加了一個(gè)-P /var/run/calc.pid寫入 pid 的位置。啟動(dòng)時(shí)先讀取舊 pid再用kill(pid, 0)探測進(jìn)程是否存在存在就直接拒絕啟動(dòng)防止兩個(gè)實(shí)例搶同一端口。日志方面很多初學(xué)者把 printf 留在代碼里結(jié)果 daemon 跑起來后什么都沒看到。我建議程序統(tǒng)一走日志函數(shù)比如log_msg(level, fmt, ...)寫到日志文件里。日志格式至少帶時(shí)間戳和連接來源排錯(cuò)的時(shí)候會(huì)舒服很多。4.4 守護(hù)進(jìn)程的常見坑位記錄坑一進(jìn)程被 kill 之后 pid 文件還留在那里。正確的做法是在信號(hào)處理函數(shù)里做清理我在 main 里注冊了 SIGTERM 和 SIGINTvoid signal_handler(int sig) { unlink(pid_file); _exit(0); }坑二daemon 服務(wù)和多進(jìn)程寫同一份日志時(shí)可能出現(xiàn)內(nèi)容交錯(cuò)。O_APPEND 能保證單次 write 原子追加但如果一條日志要兩次 write 才能寫完中間就可能被別的進(jìn)程插入。這時(shí)候要么每次日志組裝成單次 write要么加個(gè)簡單的互斥鎖?？尤高M(jìn)程_exit(0)而不是exit(0)。因?yàn)?exit 會(huì)刷新 stdio 緩沖區(qū)而 fork 時(shí)緩沖區(qū)可能被復(fù)制了一份父進(jìn)程刷新會(huì)導(dǎo)致子進(jìn)程的緩沖數(shù)據(jù)被清掉或重復(fù)輸出。用_exit直接退出內(nèi)核層面不做用戶態(tài)緩沖區(qū)清理更干凈?？铀呐挪闀r(shí)想在前臺(tái)跑一遍觀察輸出最好給程序加一個(gè)-f參數(shù)表示 foreground默認(rèn)才是 daemon 化。我在主函數(shù)里就是通過-f控制是否調(diào)用 daemonize否則每次測試都要翻日志效率很低。5. 端到端驗(yàn)證與調(diào)試復(fù)盤5.1 完整的測試鏈路編譯沒什么好說的Makefile 寫好make一把過。啟動(dòng)服務(wù)./calc_server -d -p 12345 -P /var/run/calc.pid參數(shù)含義是-d 表示 daemon 模式-p 指定監(jiān)聽端口-P 指定 pid 路徑。然后看日志確認(rèn) bind 成功tail -f /var/log/calcd.log # 輸出listening on port 12345, pid1234客戶端測試./calc_client 127.0.0.1 12345 3.5 2.5 0 # result 6.000000 ./calc_client 127.0.0.1 12345 10 0 3 # error: division by zero ./calc_client 127.0.0.1 12345 1 2 9 # error: unsupported operator注意這里是本機(jī)測的客戶端連的是回環(huán)地址 127.0.0.1數(shù)據(jù)沒有真正出網(wǎng)卡。要測網(wǎng)絡(luò)鏈路最好再找一臺(tái)同內(nèi)網(wǎng)的機(jī)器把 IP 換成服務(wù)端局域網(wǎng)地址同時(shí)看防火墻是否把 12345 擋了。5.2 調(diào)試工具與復(fù)盤三個(gè)真實(shí)案例案例一客戶端連上后立刻關(guān)閉。服務(wù)端 recv 返回 0handle_connection 里做了判斷并正常退出日志記了一條 connection closed by peer。這說明對端關(guān)閉這個(gè)分支處理對了。案例二服務(wù)端收到請求后回包但客戶端說包長度不夠。我拿抓包工具看負(fù)載只有 19 字節(jié)排查發(fā)現(xiàn)協(xié)議定義里請求負(fù)載是 20 字節(jié)但序列化函數(shù)寫 payload_len 固定寫 20實(shí)際寫入負(fù)載時(shí)因?yàn)樽侄伍L度計(jì)算錯(cuò)了一位少寫 1 字節(jié)。問題出在序列化函數(shù)和協(xié)議定義沒有完全對齊后來把序列化函數(shù)改為按字段逐個(gè)寫才徹底解決。案例三壓測時(shí)連發(fā) 1000 個(gè)同步請求出現(xiàn)請求處理錯(cuò)亂。日志顯示同一連接處理了多條請求這正是前面講的 TCP 粘包一次 recv 就拿回好幾個(gè)完整請求。后來加上按 payload_len 循環(huán)接收并在處理完一條后檢查緩沖區(qū)是否還有剩余字節(jié)。這個(gè)排查過程讓我真正明白了序列化只解決怎么編碼配合協(xié)議長度邊界才能解決怎么斷句。5.3 協(xié)議防御網(wǎng)絡(luò)計(jì)算器也要有輸入邊界自定義協(xié)議最怕的是信任一切輸入。我建議至少做四層防線第一層magic 校驗(yàn)。垃圾數(shù)據(jù)或串?dāng)?shù)據(jù)進(jìn)入?yún)f(xié)議解析前就直接丟棄。第二層長度校驗(yàn)。payload_len 超過預(yù)設(shè)上限直接回錯(cuò)誤碼并關(guān)閉連接防止惡意超長包把緩沖區(qū)撐爆。第三層類型和操作符枚舉校驗(yàn)。op 如果不是 0 到 3 的合法值就不能進(jìn)入 switch。第四層浮點(diǎn)數(shù)運(yùn)算結(jié)果檢查。x、y 里如果出現(xiàn) NaN 或無窮大運(yùn)算結(jié)果同樣要攔截。之所以反復(fù)強(qiáng)調(diào)這幾點(diǎn)是因?yàn)樾蛄谢举|(zhì)上是把外部輸入映射回內(nèi)存數(shù)據(jù)結(jié)構(gòu)這個(gè)入口一旦放松后面執(zhí)行什么邏輯都是不可控的。歷史上很多反序列化相關(guān)的安全事件歸根到底都是反序列化入口對輸入內(nèi)容、長度、類型缺乏嚴(yán)格校驗(yàn)這一件事。不是只有大型分布式系統(tǒng)才需要認(rèn)真做協(xié)議校驗(yàn)一個(gè)小型網(wǎng)絡(luò)計(jì)算服務(wù)同樣要守住輸入邊界這不算過度設(shè)計(jì)。6. 重寫時(shí)我肯定會(huì)換掉的幾處設(shè)計(jì)這個(gè)項(xiàng)目做完之后我復(fù)盤時(shí)列了幾個(gè)想改的方向也當(dāng)是給后面做同類項(xiàng)目的人一個(gè)參考。協(xié)議層面我會(huì)把現(xiàn)在的固定頭部改成更通用的 TLV 結(jié)構(gòu)再加上一個(gè) checksum 字段?，F(xiàn)在的校驗(yàn)只有 magic 和長度遇到數(shù)據(jù)在傳輸過程中被破壞的情況概率低但不是零毫無感知。加 checksum 之后接收端可以先算校驗(yàn)再解析壞包直接丟棄比到時(shí)候結(jié)果算出來不對再懷疑人生要舒服得多。傳輸層面epoll 非阻塞 IO 是必改的方向。fork 模型在連接數(shù)上來之后的成本和復(fù)雜度都有上限改成事件循環(huán)之后才能撐住更大的并發(fā)量。我會(huì)保持協(xié)議的接口不變只替換傳輸層的 accept/recv/send 包裝正好能驗(yàn)證當(dāng)時(shí)把協(xié)議獨(dú)立成文件的決定。加密方面如果服務(wù)要跨公網(wǎng)跑必須在 socket 之上加 TLS 層。TLS 對協(xié)議本身是透明的把 read/write 包裝一層就行但要注意握手階段的延遲和證書管理這已經(jīng)不是單純網(wǎng)絡(luò)編程的范疇了。最后如果真要把這套東西搬進(jìn)生產(chǎn)環(huán)境我會(huì)直接換成 Protocol Buffers 或 FlatBuffers。手寫協(xié)議的優(yōu)點(diǎn)是底層透明缺點(diǎn)是自己維護(hù)校驗(yàn)、字段擴(kuò)展、版本兼容的工作量不小。但從零手寫一遍的價(jià)值恰好在這里以后看到框架文檔里那些 schema、IDL、TAG 概念全都能對號(hào)入座知道自己正在解決什么問題。