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