1. 從一個抓包現(xiàn)場說起為什么你的數(shù)據(jù)包看起來“不完整”很多人第一次用抓包工具看TCP流量的時候都會有一種困惑明明應(yīng)用層發(fā)出去的是完整的一條消息怎么到了網(wǎng)絡(luò)層就變成了一堆零零散散的片段更讓人抓狂的是有些片段看起來只有幾十個字節(jié)有些卻接近一千五百字節(jié)毫無規(guī)律可言。如果你正好在做協(xié)議解析、流量還原或者自定義通信中間件這個問題不搞清楚后面的活兒基本沒法干。我自己最早接觸這個概念是在做一個設(shè)備數(shù)據(jù)采集網(wǎng)關(guān)的時候。設(shè)備端通過TCP往上送數(shù)據(jù)服務(wù)端收到的卻總是“半截”消息有時候兩條消息粘在一起有時候一條消息被切成三段。當(dāng)時第一反應(yīng)是代碼寫錯了查了半天緩沖區(qū)讀寫邏輯最后才發(fā)現(xiàn)根子不在應(yīng)用層而在TCP本身的傳輸機(jī)制上。TCP組包這件事說白了就是搞清楚TCP在發(fā)送數(shù)據(jù)時是怎么把應(yīng)用層交下來的字節(jié)流切成一段一段發(fā)出去的以及接收端又該怎么把這些段重新拼回一條完整的消息。這篇文章適合三類人看第一類是正在做網(wǎng)絡(luò)編程、協(xié)議解析的開發(fā)者你遲早會碰到粘包和拆包的問題第二類是做流量分析、安全審計方向的朋友不理解組包邏輯抓到的包你根本還原不出原始語義第三類是對底層網(wǎng)絡(luò)感興趣、想弄明白“數(shù)據(jù)從A到B到底經(jīng)歷了什么”的技術(shù)愛好者。我會從為什么需要組包講起把MSS、MTU、滑動窗口、Nagle算法這些繞不開的概念串起來再落到實際代碼里怎么處理最后分享幾個我踩過的坑和排查技巧。整篇內(nèi)容基于常見的TCP協(xié)議實現(xiàn)和工程實踐來寫具體參數(shù)以你實際環(huán)境為準(zhǔn)。2. 組包這件事到底在解決什么問題2.1 先搞清楚TCP是字節(jié)流不是消息流這是理解組包的第一道門檻也是最容易被忽略的一點。TCP協(xié)議在設(shè)計上只保證一件事你發(fā)出去的字節(jié)序列對方能按同樣的順序收到。注意它保證的是字節(jié)序列不是消息邊界。也就是說應(yīng)用層調(diào)用兩次send每次發(fā)100字節(jié)接收端可能一次recv就收到200字節(jié)也可能分四次每次收50字節(jié)。TCP根本不關(guān)心你應(yīng)用層是怎么劃分消息的它只負(fù)責(zé)把字節(jié)按順序搬過去。這個特性帶來的直接后果就是接收端必須自己想辦法判斷“一條完整消息到哪里結(jié)束”。而這個判斷的前提是你得先理解發(fā)送端是怎么把字節(jié)流切成一個個TCP段的。切的方式不同接收端看到的片段分布就不同處理策略也得跟著調(diào)整。用一個生活化的類比TCP就像一條傳送帶你把一堆零件放上去傳送帶只保證零件按順序到達(dá)對面但它不會告訴你“這一批是訂單A的零件下一批是訂單B的”。對面的人收到的是一堆混在一起的零件得自己根據(jù)零件上的標(biāo)記來分組。組包就是研究傳送帶是怎么把零件分批送出去的以及對面該怎么分組。2.2 不組包行不行IP層的硬性限制有人可能會想既然切來切去這么麻煩那我不切了應(yīng)用層給多少我就一次發(fā)多少不行嗎理論上可以但物理網(wǎng)絡(luò)不允許。TCP段最終要交給IP層封裝成IP數(shù)據(jù)報發(fā)出去而IP數(shù)據(jù)報有一個硬性上限MTUMaximum Transmission Unit最大傳輸單元。以太網(wǎng)環(huán)境下這個值通常是1500字節(jié)。超過這個大小的數(shù)據(jù)報要么被分片要么根本發(fā)不出去。IP分片這件事本身是有代價的。一個IP數(shù)據(jù)報被分片后只要其中任何一片丟失整個數(shù)據(jù)報都得重傳效率極低。而且很多中間設(shè)備對分片的處理策略不一致有的直接丟棄有的重組超時。所以TCP寧愿自己在傳輸層就把數(shù)據(jù)切好讓每個TCP段封裝成IP數(shù)據(jù)報后不超過MTU從源頭上避免IP分片。這就是組包最原始的驅(qū)動力在傳輸層主動切分規(guī)避網(wǎng)絡(luò)層的分片風(fēng)險。2.3 MSSTCP段大小的天花板TCP切分?jǐn)?shù)據(jù)時依據(jù)的核心參數(shù)叫MSSMaximum Segment Size最大報文段長度。它指的是一個TCP段中數(shù)據(jù)部分的最大字節(jié)數(shù)注意不包括TCP頭部和IP頭部。MSS的取值不是隨便定的它和MTU有直接關(guān)系MSS MTU - IP頭部長度 - TCP頭部長度以標(biāo)準(zhǔn)以太網(wǎng)為例MTU是1500字節(jié)IP頭部最小20字節(jié)不含選項TCP頭部最小20字節(jié)不含選項那么MSS就是1500 - 20 - 20 1460字節(jié)。這就是為什么你抓包時經(jīng)?？吹絋CP段的數(shù)據(jù)部分最大就是1460字節(jié)這個數(shù)字不是拍腦袋來的是算出來的。MSS在TCP三次握手階段通過SYN報文協(xié)商。雙方各自在SYN里帶上自己能接受的最大MSS值最終取兩者中的較小值作為實際使用的MSS。這個協(xié)商過程很重要因為通信兩端可能處在不同網(wǎng)絡(luò)環(huán)境里MTU不一樣。比如一端是以太網(wǎng)1500另一端是某種隧道環(huán)境可能只有1400協(xié)商后就會用較小的那個值避免發(fā)出去的數(shù)據(jù)包在中間被丟棄。2.4 組包和粘包一對孿生問題理解了發(fā)送端的切分邏輯接收端的問題就清晰了。接收端面對的是一個連續(xù)的字節(jié)流它需要回答一個問題從哪個字節(jié)到哪個字節(jié)算一條完整消息如果判斷錯了就會出現(xiàn)兩種典型錯誤粘包兩條或多條消息被當(dāng)成一條處理了。比如發(fā)送端連續(xù)發(fā)了消息A和消息B接收端一次recv把A和B的數(shù)據(jù)都讀出來了如果程序沒做邊界判斷就會把AB當(dāng)成一條消息解析直接解析失敗或者產(chǎn)生錯誤結(jié)果。拆包一條消息被拆成多次recv才讀完。比如消息有5000字節(jié)但MSS是1460發(fā)送端至少切成4個段發(fā)出去接收端第一次recv可能只讀到1460字節(jié)如果程序認(rèn)為這就是全部就會丟掉后面的數(shù)據(jù)。這兩個問題的根源都在于TCP不保留消息邊界。解決思路無非兩種要么在應(yīng)用層協(xié)議里自己定義邊界比如長度字段、分隔符要么用固定長度的消息。具體選哪種取決于你的業(yè)務(wù)場景和性能要求。3. 發(fā)送端是怎么決定“怎么切”的3.1 發(fā)送緩沖區(qū)的角色應(yīng)用層調(diào)用send的時候數(shù)據(jù)并不是直接飛到網(wǎng)卡上的而是先進(jìn)入發(fā)送緩沖區(qū)send buffer。這個緩沖區(qū)是內(nèi)核維護(hù)的大小可以通過SO_SNDBUF選項調(diào)整。TCP發(fā)送數(shù)據(jù)時是從這個緩沖區(qū)里取數(shù)據(jù)來組包的。理解這一點很關(guān)鍵因為它意味著應(yīng)用層的一次send和底層的一個TCP段之間沒有一一對應(yīng)關(guān)系。舉個例子應(yīng)用層連續(xù)調(diào)了三次send每次發(fā)100字節(jié)總共300字節(jié)進(jìn)入發(fā)送緩沖區(qū)。如果當(dāng)前MSS是1460且沒有其他限制TCP完全可能把這300字節(jié)合并成一個TCP段發(fā)出去。反過來應(yīng)用層一次send了5000字節(jié)緩沖區(qū)里有了5000字節(jié)TCP會根據(jù)MSS、擁塞窗口、接收窗口等因素決定一次發(fā)多少可能切成4個段分批發(fā)。所以組包的第一層邏輯是TCP從發(fā)送緩沖區(qū)取數(shù)據(jù)取多少由多個因素共同決定。這些因素包括MSS、擁塞窗口cwnd、接收端通告的接收窗口rwnd、以及Nagle算法等。3.2 擁塞窗口和接收窗口的雙重約束發(fā)送端一次能發(fā)多少數(shù)據(jù)不是它自己說了算的要同時滿足兩個窗口的限制接收窗口rwnd接收端在ACK里通告自己還有多少緩沖區(qū)空間能收數(shù)據(jù)。如果接收端處理慢緩沖區(qū)滿了rwnd就會變小甚至變成0發(fā)送端就得停下來等。擁塞窗口cwnd發(fā)送端根據(jù)網(wǎng)絡(luò)狀況自己維護(hù)的一個值用來避免把網(wǎng)絡(luò)壓垮。剛開始慢啟動階段cwnd很小每收到一個ACK就翻倍增長遇到丟包就減半。實際能發(fā)送的數(shù)據(jù)量取兩者的較小值。這意味著即使MSS是1460如果當(dāng)前cwnd只有3000那一次最多也就發(fā)3000字節(jié)左右可能切成3個段。抓包時看到段的大小參差不齊很多時候就是窗口在動態(tài)變化導(dǎo)致的。3.3 Nagle算法小包合并的功與過Nagle算法的核心思想很簡單如果發(fā)送端還有未被ACK確認(rèn)的小數(shù)據(jù)就先攢著等收到ACK或者攢夠一個MSS再發(fā)。目的是減少網(wǎng)絡(luò)上的小包數(shù)量提高帶寬利用率。這個算法在早期網(wǎng)絡(luò)帶寬緊張的時候很有價值但在很多現(xiàn)代場景下反而成了麻煩。我做過一個實時控制類的項目指令包都很小幾十字節(jié)。開了Nagle算法之后指令發(fā)出去要等前一個的ACK回來才發(fā)下一個延遲明顯增加。后來通過設(shè)置TCP_NODELAY選項關(guān)掉了Nagle算法延遲立刻降下來了。所以Nagle算法不是好不好的問題是適不適合的問題場景類型是否建議開啟Nagle原因大批量文件傳輸建議開啟合并小包減少頭部開銷提升吞吐實時交互/控制指令建議關(guān)閉小包需要立即發(fā)送延遲優(yōu)先請求-響應(yīng)模式視情況如果請求包很小且頻繁關(guān)閉更好游戲/音視頻信令建議關(guān)閉延遲敏感小包合并會引入額外等待關(guān)閉Nagle算法的方法很簡單在socket上設(shè)置int flag 1; setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *)flag, sizeof(int));注意關(guān)閉Nagle算法后小包會立即發(fā)送網(wǎng)絡(luò)上的包數(shù)量會增加。如果你的場景既需要低延遲又擔(dān)心包太多可以考慮應(yīng)用層自己做批量合并而不是依賴Nagle。3.4 一個組包過程的完整推演假設(shè)應(yīng)用層要發(fā)送一條2000字節(jié)的消息當(dāng)前MSS為1460cwnd足夠大rwnd也足夠Nagle關(guān)閉。發(fā)送端的處理過程大致如下應(yīng)用層調(diào)用send2000字節(jié)進(jìn)入發(fā)送緩沖區(qū)。TCP從緩沖區(qū)取數(shù)據(jù)第一個段取1460字節(jié)受MSS限制加上TCP頭部和IP頭部封裝成IP數(shù)據(jù)報發(fā)出。緩沖區(qū)還剩540字節(jié)TCP繼續(xù)取這540字節(jié)封裝成第二個段發(fā)出。接收端收到兩個段分別ACK確認(rèn)。如果發(fā)送端在等ACK期間又有新數(shù)據(jù)進(jìn)入緩沖區(qū)會繼續(xù)組包發(fā)送。這個例子里一條2000字節(jié)的消息被切成了1460540兩個段。接收端如果第一次recv只讀了1460字節(jié)就必須繼續(xù)讀第二次才能拿到完整的2000字節(jié)。這就是拆包的典型場景。4. 接收端怎么把碎片拼回完整消息4.1 接收緩沖區(qū)的合并行為接收端的情況和發(fā)送端對稱。TCP收到段之后先把數(shù)據(jù)放進(jìn)接收緩沖區(qū)receive buffer然后應(yīng)用層調(diào)用recv從緩沖區(qū)里讀數(shù)據(jù)。關(guān)鍵點在于TCP協(xié)議棧在把數(shù)據(jù)放入接收緩沖區(qū)時會按序列號排序并合并連續(xù)的數(shù)據(jù)。也就是說如果先收到序列號1000-2459的段再收到2460-2999的段緩沖區(qū)里就是連續(xù)的1000-2999應(yīng)用層一次recv可能把這兩段的數(shù)據(jù)都讀出來。這個合并行為是粘包問題的直接來源。發(fā)送端明明分兩次發(fā)的接收端一次就讀出來了如果應(yīng)用層沒有邊界判斷邏輯就會把兩條消息當(dāng)成一條。4.2 應(yīng)用層定義邊界的三種主流方案既然TCP不提供邊界應(yīng)用層就得自己定義。常見的方案有三種各有適用場景方案一固定長度消息。每條消息長度固定比如都是128字節(jié)。接收端每次讀128字節(jié)就是一條消息。優(yōu)點是實現(xiàn)簡單解析快缺點是靈活性差消息長度不一時會浪費帶寬。適合定長指令、定長狀態(tài)上報這類場景。方案二分隔符。用特殊字符或字符串作為消息結(jié)束標(biāo)記比如換行符、特定字節(jié)序列。接收端不斷讀取直到遇到分隔符就算一條完整消息。HTTP的頭部、很多文本協(xié)議都用這種方式。缺點是分隔符本身不能出現(xiàn)在消息內(nèi)容里否則需要轉(zhuǎn)義處理起來麻煩。方案三長度字段。在消息頭部放一個固定長度的字段標(biāo)明消息體有多少字節(jié)。接收端先讀固定長度的頭部解析出長度再讀對應(yīng)長度的消息體。這是最通用、最可靠的方案二進(jìn)制協(xié)議基本都用這種。缺點是解析邏輯稍復(fù)雜需要處理頭部和體分開讀的情況。方案優(yōu)點缺點適用場景固定長度實現(xiàn)最簡單解析快不靈活浪費帶寬定長指令、心跳包分隔符可讀性好文本友好需轉(zhuǎn)義解析效率低文本協(xié)議、日志傳輸長度字段通用性強(qiáng)效率高實現(xiàn)稍復(fù)雜二進(jìn)制協(xié)議、RPC框架4.3 長度字段方案的完整實現(xiàn)思路以長度字段方案為例接收端的處理邏輯需要分兩步先讀頭部再讀體。但這里有個坑recv不保證一次能讀滿你想要的字節(jié)數(shù)。你可能想讀4字節(jié)的頭部結(jié)果只讀到2字節(jié)。所以必須用一個循環(huán)來確保讀滿。下面是一個簡化的處理框架用偽代碼表示def read_exact(sock, n): 確保從socket讀滿n字節(jié) buf b while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: raise ConnectionError(連接斷開) buf chunk return buf def read_message(sock): 讀取一條完整消息 # 第一步讀4字節(jié)頭部解析出消息體長度 header read_exact(sock, 4) body_len int.from_bytes(header, big) # 第二步讀消息體 body read_exact(sock, body_len) return body這個框架的核心是read_exact函數(shù)它保證了“讀滿指定字節(jié)數(shù)”這個語義。不管底層TCP怎么切分應(yīng)用層看到的都是完整的頭部和完整的體。這就是解決拆包問題的標(biāo)準(zhǔn)做法。實操心得read_exact里的循環(huán)條件是len(buf) n不是len(buf) ! n。雖然在這個場景下兩者等價但用更符合語義也更安全。另外recv返回空字節(jié)串表示對端關(guān)閉了連接必須處理否則會死循環(huán)。4.4 緩沖區(qū)大小對組包的影響接收緩沖區(qū)的大小會影響recv一次能讀到的數(shù)據(jù)量。如果緩沖區(qū)設(shè)得很大而發(fā)送端發(fā)得快一次recv可能讀到多條消息的數(shù)據(jù)粘包概率增加。如果緩沖區(qū)設(shè)得很小可能一條消息要分很多次才能讀完拆包次數(shù)增加。我的經(jīng)驗是接收緩沖區(qū)不要設(shè)得過大一般設(shè)為MSS的幾倍就夠了。更重要的是應(yīng)用層的讀取邏輯必須能正確處理“一次讀到多條”和“一條分多次讀”這兩種情況。只要read_exact這類函數(shù)寫對了緩沖區(qū)大小的影響就被屏蔽了。5. 抓包分析實戰(zhàn)從Wireshark看組包過程5.1 抓包前的準(zhǔn)備工作要觀察TCP組包過程最直接的工具就是抓包軟件。在開始之前有幾個設(shè)置需要確認(rèn)選擇正確的網(wǎng)卡。如果有多塊網(wǎng)卡要選實際承載流量的那塊。設(shè)置合適的抓包過濾器。比如只想看某個端口的流量可以用tcp port 8080避免抓到無關(guān)數(shù)據(jù)干擾分析。關(guān)閉網(wǎng)卡的分載功能如果條件允許。某些網(wǎng)卡的TSO、LRO等分載功能會讓抓到的包和實際發(fā)出的包不一致影響判斷。5.2 識別組包行為的關(guān)鍵字段抓到包之后重點看這幾個字段Sequence Number序列號標(biāo)識這個段的數(shù)據(jù)在字節(jié)流中的起始位置。通過相鄰段的序列號差值可以算出每個段攜帶了多少字節(jié)數(shù)據(jù)。Acknowledgment Number確認(rèn)號接收端期望收到的下一個字節(jié)的序列號。Flags看PSH標(biāo)志。發(fā)送端設(shè)置PSH表示希望接收端盡快把數(shù)據(jù)交給應(yīng)用層但這不是強(qiáng)制的接收端可以忽略。Window Size接收端通告的接收窗口大小反映接收緩沖區(qū)的剩余空間。TCP Segment LenWireshark直接給出的段數(shù)據(jù)長度最直觀。5.3 一個真實的組包分析案例假設(shè)我們抓到了一段流量應(yīng)用層發(fā)送了一條3000字節(jié)的消息MSS為1460。抓包結(jié)果可能長這樣包序號序列號段長度標(biāo)志說明111460PSH,ACK第一個段攜帶1460字節(jié)214611460ACK第二個段攜帶1460字節(jié)3292180PSH,ACK第三個段攜帶剩余80字節(jié)4-0ACK接收端確認(rèn)收到2921803001字節(jié)從序列號可以看出第一個段從1開始長度1460所以下一個段從1461開始。第二個段長度1460下一個從2921開始。第三個段長度80總共3000字節(jié)和消息長度吻合。這就是一次典型的組包過程3000字節(jié)被切成了1460146080三個段。注意第一個和第三個段帶了PSH標(biāo)志中間那個沒有。這是因為發(fā)送端在發(fā)送第一個段時緩沖區(qū)里可能只有部分?jǐn)?shù)據(jù)設(shè)置了PSH希望對方盡快處理發(fā)送第二個段時數(shù)據(jù)還在陸續(xù)寫入沒設(shè)PSH第三個段是最后一部分又設(shè)了PSH。PSH的設(shè)置和發(fā)送端的寫入節(jié)奏有關(guān)不是固定的。5.4 從抓包結(jié)果反推應(yīng)用層行為有經(jīng)驗的開發(fā)者能從抓包結(jié)果反推出不少應(yīng)用層的信息。比如如果看到大量小段幾十字節(jié)且間隔規(guī)律可能是應(yīng)用層在頻繁發(fā)送小消息且沒關(guān)Nagle算法。如果看到段大小總是1460的整數(shù)倍附近說明發(fā)送端在盡量填滿MSS可能是批量數(shù)據(jù)傳輸。如果看到接收窗口頻繁變小說明接收端處理速度跟不上發(fā)送速度應(yīng)用層可能有性能瓶頸。如果看到重傳說明有丟包需要檢查網(wǎng)絡(luò)質(zhì)量或擁塞控制參數(shù)。這些推斷不是百分百準(zhǔn)確但能給你排查問題提供方向。我排查過一個吞吐上不去的問題抓包發(fā)現(xiàn)發(fā)送端一直在等接收端的窗口更新接收窗口長期只有幾百字節(jié)。后來查出來是接收端應(yīng)用層讀取太慢緩沖區(qū)一直滿著。把接收端的處理邏輯優(yōu)化后窗口恢復(fù)正常吞吐立刻上去了。6. 常見問題與排查技巧實錄6.1 粘包拆包問題速查表現(xiàn)象可能原因排查方法解決思路收到半截消息拆包一次recv沒讀滿打印每次recv的字節(jié)數(shù)用read_exact確保讀滿多條消息混在一起粘包一次recv讀了多條檢查消息邊界判斷邏輯加長度字段或分隔符解析偶發(fā)解析失敗粘包拆包交替出現(xiàn)抓包看段分布完善應(yīng)用層緩沖和解析小包特別多Nagle關(guān)閉或消息本身小抓包看段長度視場景決定是否開Nagle吞吐上不去窗口太小或緩沖區(qū)不足抓包看Window Size調(diào)大緩沖區(qū)或優(yōu)化處理速度延遲忽高忽低擁塞控制或Nagle影響對比開關(guān)Nagle的延遲延遲敏感場景關(guān)Nagle6.2 幾個容易踩的坑坑一以為一次send對應(yīng)一次recv。這是新手最常見的誤解。TCP不保證send和recv的一一對應(yīng)任何依賴這個假設(shè)的代碼都是不可靠的。我見過有人寫測試代碼客戶端send一次服務(wù)端recv一次就認(rèn)為收完了結(jié)果在本地測試沒問題一上真實網(wǎng)絡(luò)就出各種詭異bug。本地回環(huán)接口MTU很大通常65535很少觸發(fā)拆包所以問題被掩蓋了?？佣胹leep來等數(shù)據(jù)收完。有人為了等一條消息的所有片段到達(dá)在recv之間加sleep。這種做法極其不可靠網(wǎng)絡(luò)延遲不可預(yù)測sleep短了不夠長了浪費性能。正確做法是用長度字段或分隔符來判斷消息邊界而不是靠時間。坑三忽略recv返回0的情況。recv返回0表示對端正常關(guān)閉了連接不是錯誤。如果不處理循環(huán)會一直轉(zhuǎn)CPU跑滿。處理方式很簡單recv返回0時跳出循環(huán)關(guān)閉連接?？铀木彌_區(qū)開得過大。有人覺得緩沖區(qū)越大越好直接開到幾MB。實際上過大的緩沖區(qū)會占用大量內(nèi)存而且可能讓粘包問題更嚴(yán)重。合理的做法是根據(jù)消息大小和并發(fā)連接數(shù)來估算一般幾十KB到幾百KB就夠了?？游寤煜齅SS和MTU。MSS是TCP數(shù)據(jù)部分的最大長度MTU是整個IP數(shù)據(jù)報的最大長度兩者差了40字節(jié)IP頭TCP頭。設(shè)置參數(shù)時搞混了會導(dǎo)致包大小不對。記住那個公式MSS MTU - 40無選項時。6.3 一個排查粘包問題的完整過程分享一個我實際排查過的案例。某服務(wù)端偶爾報“消息解析失敗”頻率不高但一直存在。排查過程如下第一步在解析失敗的地方加日志打印收到的原始字節(jié)和長度。發(fā)現(xiàn)失敗時收到的數(shù)據(jù)長度比預(yù)期的一條消息長明顯是兩條消息粘在一起了。第二步檢查應(yīng)用層解析邏輯。發(fā)現(xiàn)代碼是這么寫的recv一次然后直接按一條消息解析。沒有循環(huán)沒有邊界判斷。這就是根因。第三步抓包確認(rèn)。抓包顯示發(fā)送端確實分兩次發(fā)了消息但接收端一次recv把兩條都讀出來了。因為兩條消息都很小加起來也沒超過接收緩沖區(qū)TCP合并后一起交給了應(yīng)用層。第四步修復(fù)。引入長度字段用read_exact先讀頭部再讀體循環(huán)處理直到緩沖區(qū)沒有完整消息為止。修復(fù)后再沒出現(xiàn)過解析失敗。這個案例的教訓(xùn)是不要假設(shè)recv的行為要用協(xié)議來定義邊界。只要邊界定義清楚了TCP怎么切、怎么合都不影響應(yīng)用層的正確性。6.4 性能優(yōu)化的小技巧如果你已經(jīng)正確處理了組包拆包但性能還是不滿意可以試試這幾個方向調(diào)整SO_SNDBUF和SO_RCVBUF適當(dāng)增大緩沖區(qū)可以減少系統(tǒng)調(diào)用次數(shù)提升吞吐。但別太大夠用就行。使用writev/readv如果需要發(fā)送多個不連續(xù)的內(nèi)存塊用writev可以一次系統(tǒng)調(diào)用發(fā)出去減少開銷?？紤]TCP_CORK和Nagle類似但更激進(jìn)可以強(qiáng)制攢夠一定數(shù)據(jù)再發(fā)。適合批量發(fā)送場景但要注意別把延遲敏感的數(shù)據(jù)也攢進(jìn)去了。批量ACK接收端可以延遲發(fā)送ACK攢幾個段一起確認(rèn)減少ACK包數(shù)量。Linux下有TCP_QUICKACK選項可以控制。這些優(yōu)化都要在正確性有保障的前提下做。如果組包拆包邏輯本身有問題優(yōu)化只會讓問題更難排查。7. 我個人在實際操作中的幾點體會組包這個話題看文檔覺得簡單真到代碼里全是細(xì)節(jié)。我最大的體會是永遠(yuǎn)不要相信“一次send對應(yīng)一次recv”這個假設(shè)。不管你的測試環(huán)境多穩(wěn)定真實網(wǎng)絡(luò)里什么情況都可能發(fā)生。把邊界判斷做扎實比什么都重要。另一個體會是抓包工具要會用但不能全信。網(wǎng)卡分載、抓包點位置、時間戳精度都會影響你看到的結(jié)果。最好結(jié)合應(yīng)用層日志一起分析兩邊對照才能定位準(zhǔn)確。我一般會在關(guān)鍵路徑上打日志記錄每次recv的字節(jié)數(shù)和解析結(jié)果出問題時和抓包結(jié)果對照很快就能找到根因。最后分享一個小技巧如果你在寫自定義協(xié)議長度字段建議用固定長度的大端序整數(shù)比如4字節(jié)。大端序是網(wǎng)絡(luò)字節(jié)序跨平臺不會出問題固定長度讓解析邏輯簡單4字節(jié)能表示4GB的長度絕大多數(shù)場景都夠用。這個設(shè)計看起來不起眼但能省掉后面很多麻煩。