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