寫 Linux 網(wǎng)絡(luò)編程的代碼最先卡住人的往往不是多路復(fù)用也不是高性能模型而是 bind 返回失敗、連接超時(shí)、對端收到的數(shù)據(jù)是一串亂碼這三件小事。這三個(gè)現(xiàn)象背后分別對應(yīng)著端口、地址和字節(jié)序——也就是Linux 網(wǎng)絡(luò)編程里**套接字socket**這套機(jī)制最基礎(chǔ)的那層預(yù)備知識(shí)。很多人一上手就抄一個(gè) TCP 回顯服務(wù)器的模板代碼跑通了就以為會(huì)了等真正要改端口、要跨機(jī)器、要自己定協(xié)議的時(shí)候立刻原形畢露。這篇內(nèi)容想做的事很明確把套接字這層抽象下面壓著的基本概念一個(gè)個(gè)翻出來講清楚包括 IP 與端口怎么組合成一個(gè)可尋址的通信端點(diǎn)、字節(jié)序?yàn)槭裁幢仨氜D(zhuǎn)換、TCP 和 UDP 的取舍到底在取舍什么、sockaddr這一族結(jié)構(gòu)體為什么要繞這么一圈。它適合剛接觸 Linux 系統(tǒng)編程的同學(xué)也適合寫了幾年業(yè)務(wù)代碼、但一直沒系統(tǒng)梳理過網(wǎng)絡(luò)基礎(chǔ)的人。文中會(huì)給出可直接編譯運(yùn)行的示例、參數(shù)計(jì)算過程和我在實(shí)際調(diào)試中踩過的坑你可以當(dāng)成一份動(dòng)手前的檢查清單來用。1. 先把地圖畫清楚套接字在整個(gè)網(wǎng)絡(luò)通信里站在哪一層1.1 從一次文件傳輸說起網(wǎng)絡(luò)編程到底在折騰什么假設(shè)你在本機(jī)寫了一個(gè)程序要把一個(gè)文件的內(nèi)容發(fā)給另一臺(tái)機(jī)器上的程序。最樸素的想法是我打開網(wǎng)卡、把字節(jié)一個(gè)個(gè)推出去。但這件事在用戶態(tài)根本做不了網(wǎng)卡是硬件訪問它要走驅(qū)動(dòng)而驅(qū)動(dòng)屬于內(nèi)核。所以真實(shí)的路徑是你的進(jìn)程調(diào)用一組系統(tǒng)調(diào)用把我要發(fā)這些字節(jié)給某個(gè)目標(biāo)這個(gè)意圖告訴內(nèi)核內(nèi)核里的協(xié)議棧負(fù)責(zé)封裝、校驗(yàn)、重傳、路由最后交給網(wǎng)卡。這組系統(tǒng)調(diào)用對外暴露的接口就是套接字。理解這一點(diǎn)非常重要因?yàn)樗鼪Q定了套接字 API 的性格它不是一個(gè)函數(shù)調(diào)用就完成通信而是你去內(nèi)核里登記一個(gè)通信端點(diǎn)然后對這個(gè)端點(diǎn)做讀寫。所以你會(huì)看到socket()創(chuàng)建一個(gè)東西、bind()給它掛地址、listen()讓它能接客、accept()從它身上取新連接這一串動(dòng)作本質(zhì)是在內(nèi)核里維護(hù)一份數(shù)據(jù)結(jié)構(gòu)而不是在用戶態(tài)算什么東西。判斷一個(gè)概念屬不屬于預(yù)備知識(shí)我的標(biāo)準(zhǔn)很簡單如果不搞清楚它你寫出來的代碼能跑但一改環(huán)境就崩。IP、端口、字節(jié)序、協(xié)議類型、地址結(jié)構(gòu)體全部符合這個(gè)標(biāo)準(zhǔn)。1.2 套接字的本質(zhì)一層被操作系統(tǒng)抽象出來的文件在 Linux 上socket()的返回值是一個(gè)int和open()返回的東西是同一類——文件描述符。這不是巧合而是有意為之的設(shè)計(jì)把網(wǎng)絡(luò)通信抽象成文件讀寫用戶態(tài)就能復(fù)用同一套 I/O 模型阻塞、非阻塞、select/poll/epoll、O_NONBLOCK等。于是你可以在 socket fd 上做read()/write()也可以用send()/recv()還能把它塞進(jìn)epoll的監(jiān)聽集合里。但這層像文件的抽象并不完全幾個(gè)地方會(huì)露餡。文件有偏移量可以lseek到任意位置讀socket 不行它是流讀過就沒了文件有明確長度stat一下就知道多大socket 不知道對端還會(huì)發(fā)多少只能一直讀到對端關(guān)閉或按協(xié)議自己定邊界文件關(guān)閉通常沒有副作用socket 的close()會(huì)觸發(fā)四次揮手關(guān)閉時(shí)機(jī)不對會(huì)留下TIME_WAIT。這幾個(gè)差異點(diǎn)恰恰是后面所有坑的源頭。我個(gè)人的建議是初學(xué)時(shí)把 socket 當(dāng)文件用完全沒問題能快速跑通但一旦開始調(diào)性能或者排查異常就必須切換到這是一個(gè)有狀態(tài)的雙向字節(jié)通道的心智模型。1.3 預(yù)備知識(shí)清單為什么這些概念繞不開把要講的東西列個(gè)清單后面的章節(jié)就按這個(gè)骨架展開通信端點(diǎn)怎么唯一標(biāo)識(shí)IP 端口、數(shù)據(jù)在內(nèi)存里怎么排字節(jié)序、通道提供什么保證TCP / UDP、內(nèi)核用什么結(jié)構(gòu)描述端點(diǎn)sockaddr家族、以及這些 API 之間靠什么約定串起來返回值、錯(cuò)誤碼、阻塞語義。這份清單不是憑空列的。你回頭看那三個(gè)典型故障bind失敗八成是端口被占或者地址填錯(cuò)落在清單第一項(xiàng)連接超時(shí)可能是 IP 不可達(dá)、防火墻攔了、也可能是監(jiān)聽端bind在127.0.0.1上只收了本機(jī)連接還是落在第一項(xiàng)數(shù)據(jù)亂碼幾乎必然是字節(jié)序或者結(jié)構(gòu)體對齊落在第二項(xiàng)。換句話說套接字編程里絕大多數(shù)看起來詭異的問題都能在這份清單里找到歸屬。把清單吃透調(diào)試就從猜變成查。2. IP 與端口給通信雙方一個(gè)能寄到的地址2.1 IP 地址定位到哪臺(tái)機(jī)器IP 地址解決的是哪臺(tái)主機(jī)的問題。IPv4 是 32 位寫成點(diǎn)分十進(jìn)制是為了人看比如192.168.1.10本質(zhì)上就是四個(gè)字節(jié)。理解這一點(diǎn)很關(guān)鍵因?yàn)榇a里sin_addr.s_addr存的就是這 32 位整數(shù)不是字符串。你要么用inet_pton()把字符串轉(zhuǎn)成整數(shù)要么用htonl()把主機(jī)序的整數(shù)轉(zhuǎn)成網(wǎng)絡(luò)序絕不能直接把字符串memcpy進(jìn)去。幾個(gè)必須分清的特殊地址0.0.0.0INADDR_ANY作為bind的參數(shù)時(shí)表示綁定本機(jī)所有網(wǎng)卡的所有 IP。服務(wù)端幾乎都用它因?yàn)橐慌_(tái)機(jī)器可能有回環(huán)、有線、無線多個(gè)地址寫死某一個(gè)會(huì)導(dǎo)致?lián)Q網(wǎng)就收不到連接。127.0.0.1回環(huán)地址只在本機(jī)內(nèi)部有效數(shù)據(jù)不出網(wǎng)卡。作為bind參數(shù)時(shí)只有本機(jī)進(jìn)程能連上作為connect目標(biāo)時(shí)只能連本機(jī)的服務(wù)。255.255.255.255受限廣播地址只有開啟SO_BROADCAST才能發(fā)。私有地址段10/8、172.16/12、192.168/16內(nèi)網(wǎng)使用跨網(wǎng)段需要轉(zhuǎn)換。這里有個(gè)經(jīng)典誤解很多人以為bind到0.0.0.0就等于對外開放。實(shí)際上它只決定監(jiān)聽哪個(gè)地址能不能被外部連上還取決于路由和鏈路上的訪問控制。反過來如果你在開發(fā)機(jī)上把服務(wù)bind到127.0.0.1然后用另一臺(tái)機(jī)器去連會(huì)一直超時(shí)——這不是代碼 bug是本就沒打算讓你連。2.2 端口號定位到哪個(gè)進(jìn)程IP 只到機(jī)器機(jī)器上跑著幾十上百個(gè)進(jìn)程數(shù)據(jù)到了該交給誰靠端口。端口是 16 位無符號整數(shù)范圍 0 到 65535和 IP 組合成IP:Port這個(gè)二元組才能唯一標(biāo)識(shí)一個(gè)通信端點(diǎn)。不過嚴(yán)格來說標(biāo)識(shí)一個(gè) TCP 連接的完整四元組是源IP : 源端口 : 目的IP : 目的端口。這也是為什么同一臺(tái)服務(wù)器可以同時(shí)接受成千上萬個(gè)連接目的 IP 和目的端口相同但客戶端的源 IP 和源端口不同四元組依然唯一。理解這個(gè)四元組你就明白了為什么服務(wù)端只監(jiān)聽一個(gè)端口卻能服務(wù)大量客戶端這件事在邏輯上是成立的也就不容易被一個(gè)端口只能一個(gè)連接這種錯(cuò)誤直覺誤導(dǎo)。端口在 Linux 上分三段用途和權(quán)限完全不同范圍名稱典型用途權(quán)限要求0 - 1023知名端口HTTP(80)、SSH(22)、DNS(53)傳統(tǒng)上需要特權(quán)Linux 可通過net.ipv4.ip_unprivileged_port_start放寬1024 - 49151注冊端口各類中間件、數(shù)據(jù)庫默認(rèn)端口普通用戶可用49152 - 65535動(dòng)態(tài)/臨時(shí)端口客戶端connect時(shí)內(nèi)核自動(dòng)分配普通用戶可用寫代碼時(shí)有一個(gè)細(xì)節(jié)容易被忽略bind的端口傳 0表示讓內(nèi)核幫我挑一個(gè)空閑端口內(nèi)核挑完后可以用getsockname()讀出來。這個(gè)技巧在寫測試用例、寫需要?jiǎng)討B(tài)端口的服務(wù)時(shí)特別有用能徹底避免端口沖突導(dǎo)致測試隨機(jī)失敗這種情況。2.3 IP 與端口的組合方式以及結(jié)構(gòu)體里為什么要留一個(gè)sin_zero在代碼層面IPv4 的地址信息裝在struct sockaddr_in里核心三個(gè)成員sin_family地址族填A(yù)F_INET、sin_port16 位端口網(wǎng)絡(luò)字節(jié)序、sin_addr32 位 IP網(wǎng)絡(luò)字節(jié)序。這三個(gè)字段的填法幾乎決定了bind和connect能不能成功。struct sockaddr_in里還有個(gè)sin_zero[8]很多人不知道它是干嘛的。原因是歷史上的struct sockaddr總長 16 字節(jié)而sockaddr_in的實(shí)質(zhì)內(nèi)容只占 8 字節(jié)剩 8 字節(jié)用它填充對齊保證兩者大小一致這樣bind(sockfd, (struct sockaddr *)addr, sizeof(addr))這種強(qiáng)制轉(zhuǎn)換才安全。這個(gè)字段必須清零標(biāo)準(zhǔn)做法是定義后立刻memset(addr, 0, sizeof(addr))否則殘留的棧上垃圾數(shù)據(jù)在某些實(shí)現(xiàn)上會(huì)引起地址比較異常。我見過有人省略 memset 之后在bind時(shí)偶發(fā)EINVAL排查了很久最后就是這 8 個(gè)字節(jié)沒清干凈。2.4 端口相關(guān)的三個(gè)高頻坑端口被占用EADDRINUSE。最常見的原因是上一個(gè)進(jìn)程沒退干凈或者進(jìn)程重啟太快、舊連接還處于TIME_WAIT。TIME_WAIT是主動(dòng)關(guān)閉方才會(huì)進(jìn)入的狀態(tài)持續(xù) 2MSLLinux 上約 60 秒目的是保證最后一個(gè) ACK 能被對端收到、并讓舊連接的殘留報(bào)文在網(wǎng)絡(luò)中消散。服務(wù)端頻繁重啟時(shí)幾乎必然撞上解決辦法是給監(jiān)聽 socket 設(shè)置SO_REUSEADDRint on 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, on, sizeof(on));注意SO_REUSEADDR解決的是地址處于 TIME_WAIT 時(shí)仍可綁定不是兩個(gè)進(jìn)程同時(shí)綁同一個(gè)端口。后者在 Linux 上需要SO_REUSEPORT語義完全不同不要混用。綁定地址寫死。開發(fā)時(shí)圖省事寫inet_addr(127.0.0.1)上線后容器內(nèi)其他服務(wù)連不上。這類問題在容器化環(huán)境里尤其常見因?yàn)槿萜鞯幕丨h(huán)和其他容器的網(wǎng)絡(luò)命名空間是隔離的。用inet_addr()判斷錯(cuò)誤。這個(gè)函數(shù)轉(zhuǎn)換失敗時(shí)返回INADDR_NONE而INADDR_NONE的值恰好是255.255.255.255也就是說你無法區(qū)分輸入非法和輸入就是廣播地址。新代碼一律用inet_pton()它的返回值語義清晰1 成功、0 格式不對、-1 地址族不支持。3. 字節(jié)序跨機(jī)器傳數(shù)據(jù)繞不過去的第一個(gè)坑3.1 大端與小端到底差在哪一個(gè) 32 位整數(shù)0x01020304在內(nèi)存里占四個(gè)字節(jié)。如果低地址存01、高地址存04叫大端Big-Endian如果低地址存04、高地址存01叫小端Little-Endian。x86 和大部分 ARM 是小端部分嵌入式平臺(tái)和網(wǎng)絡(luò)協(xié)議規(guī)定的是大端。這件事在單機(jī)程序里毫無存在感因?yàn)樽x取和寫入用的是同一套規(guī)則自己跟自己永遠(yuǎn)對得上。但一旦跨機(jī)器發(fā)送方按小端把0x01020304鋪到內(nèi)存里發(fā)出去接收方按大端解讀得到的就是0x04030201——數(shù)字完全變了。這也是收到的數(shù)據(jù)是亂碼最常見的成因之一而且它很陰險(xiǎn)數(shù)據(jù)長度對得上、校驗(yàn)也能過只是數(shù)值錯(cuò)了排查時(shí)容易往業(yè)務(wù)邏輯上想?？梢赃@樣驗(yàn)證自己機(jī)器的字節(jié)序#include stdio.h #include stdint.h #include arpa/inet.h int main(void) { uint32_t host 0x01020304; uint32_t net htonl(host); unsigned char *p; p (unsigned char *)host; printf(host: %02x %02x %02x %02x\n, p[0], p[1], p[2], p[3]); p (unsigned char *)net; printf(net : %02x %02x %02x %02x\n, p[0], p[1], p[2], p[3]); return 0; }在小端機(jī)上輸出是host: 04 03 02 01和net: 01 02 03 04兩個(gè)結(jié)果不一樣說明轉(zhuǎn)換確實(shí)發(fā)生了在大端機(jī)上兩者相同。這段代碼我建議每個(gè)初學(xué)網(wǎng)絡(luò)編程的人都親手跑一遍比看十遍文字描述管用。3.2 為什么網(wǎng)絡(luò)字節(jié)序規(guī)定為大端協(xié)議在設(shè)計(jì)時(shí)需要一個(gè)統(tǒng)一約定否則每個(gè)實(shí)現(xiàn)都要在運(yùn)行時(shí)協(xié)商成本太高。選大端有歷史和工程上的原因早期參與制定規(guī)范的主流機(jī)器多為大端架構(gòu)而且大端在抓包和人工閱讀十六進(jìn)制時(shí)更符合直覺——高位在前和書寫順序一致。這個(gè)選擇一旦定下來就成了硬約定后來無論本機(jī)是什么字節(jié)序網(wǎng)絡(luò)上傳輸?shù)臄?shù)值一律按大端解釋。落實(shí)到代碼就是四個(gè)函數(shù)htonshost to network short16 位、htonl32 位、ntohs、ntohl。規(guī)律很好記端口是 16 位用sIP 和大多數(shù)整型字段是 32 位用l。這些函數(shù)在同類字節(jié)序的機(jī)器上會(huì)被編譯成空操作所以不用擔(dān)心性能。3.3 轉(zhuǎn)換邊界在哪里只轉(zhuǎn)數(shù)值不轉(zhuǎn)字節(jié)流這是最容易被搞混的一點(diǎn)。字節(jié)序轉(zhuǎn)換只對多字節(jié)數(shù)值類型有意義對字節(jié)數(shù)組沒有意義。你發(fā)一個(gè)字符串hello它就是五個(gè)字節(jié)逐字節(jié)發(fā)送接收方逐字節(jié)接收順序天然一致不需要任何轉(zhuǎn)換。你發(fā)一個(gè)uint32_t長度字段就必須轉(zhuǎn)換。由此推出一條實(shí)操原則自定義協(xié)議時(shí)把所有多字節(jié)字段明確用固定寬度類型uint16_t、uint32_t、uint64_t聲明并在序列化時(shí)逐個(gè)轉(zhuǎn)換。不要圖省事把整個(gè)結(jié)構(gòu)體memcpy進(jìn)緩沖區(qū)發(fā)出去原因有兩個(gè)一是結(jié)構(gòu)體里可能有字節(jié)序不同的字段二是編譯器會(huì)在成員之間插入對齊填充填充內(nèi)容是不確定的接收方按同樣的結(jié)構(gòu)體解析可能對得上換編譯器、換優(yōu)化等級、換平臺(tái)就可能錯(cuò)位。htons/htonl只覆蓋 16 位和 32 位64 位沒有標(biāo)準(zhǔn)函數(shù)?？缙脚_(tái)項(xiàng)目里常見的做法是自己寫一對#include stdint.h static uint64_t hton64(uint64_t v) { #if __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ return ((uint64_t)htonl((uint32_t)(v 0xFFFFFFFF)) 32) | htonl((uint32_t)(v 32)); #else return v; #endif }或者干脆在協(xié)議設(shè)計(jì)階段避開 64 位字段用兩個(gè) 32 位拼省掉這一層。我在實(shí)際項(xiàng)目里更傾向后者協(xié)議越簡單跨語言實(shí)現(xiàn)時(shí)出錯(cuò)概率越低。3.4 浮點(diǎn)數(shù)和長時(shí)間戳的額外注意點(diǎn)浮點(diǎn)數(shù)不要直接發(fā)二進(jìn)制。IEEE 754 的位模式雖然也是定長的但不同平臺(tái)的實(shí)現(xiàn)細(xì)節(jié)、NaN 表示、擴(kuò)展精度都可能不同直接傳字節(jié)在不同編譯器之間不一定可靠。穩(wěn)妥做法是轉(zhuǎn)成定點(diǎn)整數(shù)比如金額用分為單位存int64_t或者轉(zhuǎn)成十進(jìn)制字符串發(fā)送犧牲一點(diǎn)帶寬換確定性。時(shí)間戳同理。推薦統(tǒng)一用自紀(jì)元起的秒數(shù)或毫秒數(shù)作為int64_t轉(zhuǎn)換后傳輸避免傳struct timeval、struct timespec這類結(jié)構(gòu)體——它們的成員寬度和布局在各平臺(tái)上并不一致。這一點(diǎn)在寫跨平臺(tái)通信協(xié)議時(shí)值得單獨(dú)列一條規(guī)范比事后調(diào)試省事得多。4. 協(xié)議的選擇TCP 和 UDP 的取舍不是在選技術(shù)是在選責(zé)任4.1 TCP面向連接、可靠、字節(jié)流SOCK_STREAM對應(yīng)的就是 TCP。它提供的保證可以概括成四條連接是有狀態(tài)的三次握手建立、四次揮手關(guān)閉、數(shù)據(jù)不丟不重不亂序、有流量控制和擁塞控制、傳輸?shù)氖亲止?jié)流而非消息。字節(jié)流這三個(gè)字是理解 TCP 的關(guān)鍵也是后面所有粘包討論的根源。TCP 只保證你寫進(jìn)去的字節(jié)會(huì)按順序到達(dá)不保證邊界。你在發(fā)送端write了兩次每次 100 字節(jié)接收端可能一次read到 200 字節(jié)也可能分三次讀到 60、60、80。這不是 bug是設(shè)計(jì)如此——TCP 把自己定位成一根可靠的水管水管不負(fù)責(zé)告訴你這一杯水到哪里結(jié)束。所以任何基于 TCP 的應(yīng)用層協(xié)議都必須自己定義邊界常見三種做法方案做法適用場景缺點(diǎn)固定長度每條消息定長消息長度恒定的場景不靈活浪費(fèi)帶寬長度前綴先發(fā) 4 字節(jié)長度再發(fā)內(nèi)容通用二進(jìn)制協(xié)議需要處理長度字段本身的字節(jié)序分隔符用\r\n或\0結(jié)束文本協(xié)議、命令行內(nèi)容里出現(xiàn)分隔符需要轉(zhuǎn)義長度前綴是我最常用的方案簡單、高效、無歧義。實(shí)現(xiàn)上有兩個(gè)細(xì)節(jié)長度字段必須用htonl轉(zhuǎn)換讀取時(shí)必須循環(huán)讀滿因?yàn)閞ead可能只返回部分?jǐn)?shù)據(jù)。static int read_full(int fd, void *buf, size_t n) { size_t got 0; while (got n) { ssize_t r read(fd, (char *)buf got, n - got); if (r 0) return 0; /* 對端關(guān)閉 */ if (r 0) { if (errno EINTR) continue; /* 被信號打斷重試 */ return -1; } got (size_t)r; } return 1; }這段代碼短但包含了三個(gè)新手經(jīng)常漏掉的點(diǎn)處理短讀、處理EINTR、區(qū)分讀滿和對端關(guān)閉兩種情況。漏掉任何一個(gè)在高負(fù)載或者有信號的環(huán)境下就會(huì)出現(xiàn)隨機(jī)失敗而且極難復(fù)現(xiàn)。4.2 UDP無連接、不可靠、數(shù)據(jù)報(bào)SOCK_DGRAM對應(yīng) UDP。它沒有連接、不保證送達(dá)、不保證順序、可能重復(fù)但保留了消息邊界你發(fā)一個(gè)數(shù)據(jù)報(bào)接收方要么收到完整的一個(gè)要么收不到不會(huì)出現(xiàn)半截。這一點(diǎn)和 TCP 正好相反。UDP 的優(yōu)勢在于開銷小、延遲低、沒有隊(duì)頭阻塞。一個(gè)數(shù)據(jù)報(bào)丟了只影響它自己不會(huì)卡住后面的數(shù)據(jù)TCP 則因?yàn)橐ＷC順序前面一個(gè)包丟了后面全得等重傳。所以在實(shí)時(shí)性優(yōu)先、能容忍少量丟包的場景里UDP 是更合理的選擇。另外 UDP 天然支持一對多廣播、組播TCP 做不到。需要注意的是UDP 的簡單只體現(xiàn)在協(xié)議層應(yīng)用層的復(fù)雜度一點(diǎn)沒少要自己做超時(shí)重傳、自己做序號去重、自己做擁塞控制否則一旦網(wǎng)絡(luò)擁塞就是災(zāi)難。很多人在 UDP 上重新實(shí)現(xiàn)了一遍 TCP 的可靠性機(jī)制結(jié)果比直接用 TCP 還差。這不是說不能做而是要有清醒判斷——如果你的需求是可靠傳輸先問問自己為什么不用 TCP。4.3 選型不是選技術(shù)是選你要承擔(dān)哪部分責(zé)任我判斷的方式是問三個(gè)問題丟一個(gè)包會(huì)怎樣如果業(yè)務(wù)上完全不能接受比如轉(zhuǎn)賬指令用 TCP讓協(xié)議棧幫你扛。延遲敏感嗎如果晚到不如不到比如實(shí)時(shí)語音、游戲位置同步UDP 更合適應(yīng)用層做有限的補(bǔ)償。是不是一對多廣播、組播只能用 UDP。其余情況默認(rèn)選 TCP把精力放在業(yè)務(wù)上。選 UDP 通常是經(jīng)過權(quán)衡后的主動(dòng)決策而不是因?yàn)樗臁?.4 粘包這個(gè)詞其實(shí)起錯(cuò)了名字社區(qū)里常說TCP 粘包嚴(yán)格講這個(gè)說法不準(zhǔn)確TCP 沒有粘它本來就是流從未承諾過邊界。真正的問題是應(yīng)用層沒有定義消息邊界。所以解決粘包的正確姿勢不是去調(diào)什么 socket 參數(shù)而是在協(xié)議設(shè)計(jì)階段就把邊界規(guī)則寫清楚然后在接收端按規(guī)則切分。理解了這一點(diǎn)你就不會(huì)再去找關(guān)閉粘包的選項(xiàng)——那東西不存在。4.5 一個(gè)常被忽略的細(xì)節(jié)send返回值和發(fā)完了不是一回事send()返回的是成功拷貝進(jìn)內(nèi)核發(fā)送緩沖區(qū)的字節(jié)數(shù)不等于對端已經(jīng)收到。緩沖區(qū)滿了它會(huì)阻塞阻塞模式下或者返回EAGAIN非阻塞模式下。所以正確寫法同樣是循環(huán)直到全部寫完static int write_full(int fd, const void *buf, size_t n) { size_t sent 0; while (sent n) { ssize_t w send(fd, (const char *)buf sent, n - sent, 0); if (w 0) { if (errno EINTR) continue; if (errno EAGAIN || errno EWOULDBLOCK) { /* 非阻塞模式下應(yīng)交給事件循環(huán)處理此處僅示意 */ continue; } return -1; } sent (size_t)w; } return 0; }在非阻塞模式下EAGAIN的處理不能靠死循環(huán)必須回到事件循環(huán)里等可寫事件。這段邏輯在寫高性能服務(wù)時(shí)是繞不開的但在預(yù)備知識(shí)階段先建立send 不代表送達(dá)這個(gè)認(rèn)知就夠了。5. 地址結(jié)構(gòu)體與 socket API 的整體輪廓5.1sockaddr家族的三個(gè)成員很多人第一次看 socket 代碼最困惑的就是為什么要在一堆結(jié)構(gòu)體之間來回強(qiáng)轉(zhuǎn)struct sockaddr_in addr; bind(fd, (struct sockaddr *)addr, sizeof(addr));原因是設(shè)計(jì)上做了一層通用殼。struct sockaddr是抽象的地址表示只有一個(gè) 16 位的地址族字段和一段通用的地址數(shù)據(jù)struct sockaddr_in是 IPv4 的具體表示struct sockaddr_in6是 IPv6 的struct sockaddr_un是本地 Unix 域的。所有 API 的參數(shù)統(tǒng)一收struct sockaddr *這樣一套接口能同時(shí)支持多種地址族代價(jià)是調(diào)用方必須自己強(qiáng)轉(zhuǎn)并把真實(shí)大小通過第三個(gè)參數(shù)傳進(jìn)去。這個(gè)設(shè)計(jì)的用意是擴(kuò)展性代價(jià)是類型安全為零——強(qiáng)轉(zhuǎn)錯(cuò)了編譯器不會(huì)報(bào)錯(cuò)運(yùn)行時(shí)bind直接返回EINVAL。所以我寫這類代碼時(shí)有個(gè)習(xí)慣結(jié)構(gòu)體變量名統(tǒng)一加后綴addr4、addr6強(qiáng)轉(zhuǎn)的地方一眼能看出對應(yīng)關(guān)系減少誤用。三層結(jié)構(gòu)之間還有一個(gè)細(xì)節(jié)sin_addr的類型是struct in_addr里面只有一個(gè)s_addr成員。多套一層純粹是歷史原因?qū)嶋H用時(shí)直接操作sin_addr.s_addr就行。IPv6 那邊sin6_addr是 16 字節(jié)的聯(lián)合體轉(zhuǎn)換要用inet_pton(AF_INET6, ...)inet_ntop也需要傳AF_INET6用錯(cuò)了會(huì)靜默失敗。5.2 一份能跑起來的最小骨架把前面所有概念串起來一個(gè)最小的服務(wù)器骨架長這樣#include stdio.h #include string.h #include unistd.h #include errno.h #include arpa/inet.h #include netinet/in.h #include sys/socket.h int main(void) { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); return 1; } int on 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, on, sizeof(on)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(8080); addr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); return 1; } if (listen(lfd, 128) 0) { perror(listen); return 1; } for (;;) { struct sockaddr_in peer; socklen_t len sizeof(peer); int cfd accept(lfd, (struct sockaddr *)peer, len); if (cfd 0) { if (errno EINTR) continue; perror(accept); break; } char ip[INET_ADDRSTRLEN]; inet_ntop(AF_INET, peer.sin_addr, ip, sizeof(ip)); printf(client %s:%u\n, ip, ntohs(peer.sin_port)); char buf[1024]; ssize_t n read(cfd, buf, sizeof(buf)); if (n 0) write(cfd, buf, (size_t)n); close(cfd); } close(lfd); return 0; }三十來行但每一行都能對應(yīng)上前面的概念socket的第一個(gè)參數(shù)是地址族第二個(gè)是套接字類型決定 TCP 還是 UDPSO_REUSEADDR解決TIME_WAITmemset清sin_zerohtons/htonl處理字節(jié)序INADDR_ANY監(jiān)聽所有地址listen的第二個(gè)參數(shù)是等待隊(duì)列長度accept返回的是新的fd和監(jiān)聽 fd 是兩個(gè)東西peer里的地址是網(wǎng)絡(luò)字節(jié)序打印前必須ntohs。編譯命令記一下gcc -Wall -Wextra -o srv srv.c然后另開一個(gè)終端用nc 127.0.0.1 8080連上去試試。這段代碼只處理一個(gè)連接就關(guān)閉不是完整的服務(wù)器但足夠用來驗(yàn)證環(huán)境、驗(yàn)證端口、驗(yàn)證字節(jié)序轉(zhuǎn)換是否正確。5.3listen的 backlog 到底影響什么listen(fd, 128)里的 128 不是最大連接數(shù)而是未完成連接隊(duì)列 已完成連接隊(duì)列的上限參考值。未完成隊(duì)列放的是收到 SYN、還沒完成三次握手的連接已完成隊(duì)列放的是握手完成、等待accept取走的連接。如果服務(wù)端accept太慢已完成隊(duì)列滿了后續(xù)新連接的行為取決于tcp_abort_on_overflow的配置默認(rèn)是靜默丟棄客戶端表現(xiàn)為連接超時(shí)或重試。實(shí)際取值不用太糾結(jié)Linux 上還會(huì)被net.core.somaxconn限制最終生效的是兩者較小值。我一般寫 128 或 512配合及時(shí)accept就夠了。真正的瓶頸幾乎從來不是這個(gè)數(shù)字而是accept之后每個(gè)連接的處理邏輯是不是阻塞的。5.4read/write與send/recvclose與shutdownsocketfd 可以用read/write也可以用send/recv。前者是通用文件接口后者多了個(gè)flags參數(shù)能指定MSG_NOSIGNAL避免對端關(guān)閉時(shí)觸發(fā) SIGPIPE 直接殺掉進(jìn)程、MSG_PEEK窺探不取走、MSG_WAITALL盡量讀滿。生產(chǎn)代碼里我強(qiáng)烈建議用send并帶上MSG_NOSIGNAL或者干脆在啟動(dòng)時(shí)signal(SIGPIPE, SIG_IGN)否則對端異常斷開就可能導(dǎo)致整個(gè)服務(wù)進(jìn)程退出這類事故非常典型。close和shutdown的區(qū)別也值得單獨(dú)說。close減少引用計(jì)數(shù)減到 0 才真正關(guān)閉而且它是全雙工的——讀寫一起斷。shutdown(fd, SHUT_WR)只關(guān)閉寫方向?qū)Χ藭?huì)收到 EOF但仍然可以繼續(xù)發(fā)數(shù)據(jù)過來這在我發(fā)完了等你回復(fù)的場景里是必需的。用close替代shutdown會(huì)導(dǎo)致你再也讀不到對端的回復(fù)很多人調(diào)試時(shí)遇到發(fā)完就收不到響應(yīng)原因就在這里。5.5 阻塞與非阻塞預(yù)備階段至少要建立的直覺默認(rèn)創(chuàng)建的 socket 是阻塞的accept沒連接就卡住、read沒數(shù)據(jù)就卡住、write緩沖區(qū)滿就卡住。單連接場景沒問題一旦要同時(shí)處理多個(gè)連接就必須改。兩條路一是每連接一個(gè)線程簡單但線程開銷大、連接數(shù)上千就撐不住二是非阻塞 事件循環(huán)epoll一個(gè)線程管成千上萬個(gè)連接。預(yù)備知識(shí)階段不需要把epoll吃透但必須理解阻塞語義是怎么來的以及EAGAIN意味著什么。因?yàn)椴还苣愫竺嬗媚姆N模型這兩個(gè)概念都會(huì)反復(fù)出現(xiàn)。我的建議是先寫一個(gè)阻塞版本跑通邏輯再改成非阻塞觀察錯(cuò)誤碼的變化這個(gè)對比過程比直接抄epoll模板有收獲得多。6. 常見問題與排查技巧實(shí)錄6.1 一份能直接對著查的速查表現(xiàn)象最可能原因排查動(dòng)作bind返回EADDRINUSE端口被占或處于TIME_WAITss -lntp看占用加SO_REUSEADDRbind返回EINVAL結(jié)構(gòu)體沒清零 / 地址族填錯(cuò) / 長度傳錯(cuò)檢查memset、sin_family、第三個(gè)參數(shù)connect一直超時(shí)目標(biāo)不可達(dá)、被防火墻攔、服務(wù)bind在回環(huán)ping、telnet ip port、檢查bind地址connect返回ECONNREFUSED目標(biāo)端口沒有監(jiān)聽確認(rèn)服務(wù)是否啟動(dòng)、端口是否寫錯(cuò)收到的數(shù)值不對字節(jié)序沒轉(zhuǎn)檢查htonl/htons/ntohl/ntohs收到的結(jié)構(gòu)體錯(cuò)位直接memcpy結(jié)構(gòu)體含對齊填充改為逐字段序列化大流量下偶發(fā)讀不完整沒處理短讀包一層read_full循環(huán)進(jìn)程莫名退出對端關(guān)閉觸發(fā)SIGPIPE用MSG_NOSIGNAL或忽略SIGPIPE端口傳 0 后不知道實(shí)際端口沒調(diào)getsockname綁定后用getsockname讀回重啟服務(wù)立刻報(bào)端口占用TIME_WAITSO_REUSEADDR或等待 2MSL這張表覆蓋了我實(shí)際調(diào)試中八成以上的情況遇到問題先對一遍能省掉大量瞎猜的時(shí)間。6.2 幾個(gè)只有踩過才知道的細(xì)節(jié)用ss而不是netstat。ss -lntp看監(jiān)聽、ss -antp看所有 TCP 連接、ss -s看匯總統(tǒng)計(jì)比netstat快得多字段也更清楚。排查連接狀態(tài)分布時(shí)ss輸出的State列能直接告訴你有多少連接卡在SYN-SENT、多少在TIME_WAIT。strace是定位 socket 調(diào)用的利器。strace -f -e tracenetwork ./srv能把所有網(wǎng)絡(luò)相關(guān)的系統(tǒng)調(diào)用和返回值打出來bind到底傳了什么地址、accept返回了哪個(gè) fd、read返回了幾個(gè)字節(jié)一目了然。我第一次搞不清為什么bind失敗就是靠它看到sin_port傳的是主機(jī)序直接定位。地址打印一定要在轉(zhuǎn)換之后。printf(%s, inet_ntoa(addr.sin_addr))這種寫法在單線程里能用但inet_ntoa返回的是靜態(tài)緩沖區(qū)多線程下會(huì)互相覆蓋。老老實(shí)實(shí)用inet_ntop加自己的char buf[INET_ADDRSTRLEN]雖然多寫一行但省掉的是那種日志里 IP 隨機(jī)變化的詭異問題。測試用固定端口遲早出事。CI 環(huán)境里并發(fā)跑多個(gè)測試用例固定端口必然沖突。全部改成綁定端口 0 再getsockname拿實(shí)際端口這個(gè)改動(dòng)很小收益很大。超時(shí)一定要設(shè)。connect默認(rèn)超時(shí)可能長達(dá)一分鐘以上recv默認(rèn)永不超時(shí)。生產(chǎn)代碼里SO_RCVTIMEO、SO_SNDTIMEO或者非阻塞 事件循環(huán)的超時(shí)機(jī)制至少要有一種。我見過因?yàn)槿背瑫r(shí)導(dǎo)致工作線程被一個(gè)僵死連接永久占住最后整個(gè)服務(wù)雪崩的案例代價(jià)非常大。跨機(jī)器自測要趁早。別總在127.0.0.1上測。兩個(gè)終端在本機(jī)互通會(huì)掩蓋掉地址綁定、防火墻、路由、MTU 等一系列問題。哪怕只是拿另一臺(tái)同網(wǎng)段的機(jī)器連一下也能提前暴露不少東西。6.3 我個(gè)人建議的學(xué)習(xí)路徑我的體會(huì)是套接字這層?xùn)|西不適合先學(xué)完理論再動(dòng)手也不適合抄完模板就完事比較舒服的節(jié)奏是三輪。第一輪跑通寫一個(gè)阻塞的 TCP 回顯服務(wù)用nc連通確認(rèn)端口、地址、收發(fā)都正常。第二輪加約束自己定義一個(gè)帶長度前綴的協(xié)議收發(fā)結(jié)構(gòu)體強(qiáng)制做字節(jié)序轉(zhuǎn)換用tcpdump或者strace驗(yàn)證字節(jié)層面的樣子。第三輪改模型把阻塞改成非阻塞觀察EAGAIN然后引入epoll理解事件驅(qū)動(dòng)下的收發(fā)循環(huán)。這三輪走下來再去看那些高性能框架的代碼會(huì)發(fā)現(xiàn)它們做的事情無非是把這三輪的細(xì)節(jié)做到極致緩沖區(qū)管理、零拷貝、批量收發(fā)、連接復(fù)用?；A(chǔ)概念打牢了上層的東西就只是工程取舍不再是黑魔法。最后分享一個(gè)我常用的自查習(xí)慣寫完任何一段 socket 代碼我都會(huì)問自己四個(gè)問題——這個(gè)數(shù)值轉(zhuǎn)字節(jié)序了嗎這個(gè)read會(huì)不會(huì)短讀這個(gè)send失敗我能處理嗎對端關(guān)閉時(shí)我會(huì)不會(huì)崩四個(gè)問題全過代碼基本就能在真實(shí)環(huán)境里扛住了。