粘包問(wèn)題

我們知道，TCP 協(xié)議是面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。其實(shí)，TCP作為面向流的協(xié)議，不存在“粘包問(wèn)題”。

什么是粘包

其實(shí)這里面有兩種含義：

其一是指，由于TCP是面向流的協(xié)議，不會(huì)按照應(yīng)用開(kāi)發(fā)者的期望保持send輸入數(shù)據(jù)的邊界，導(dǎo)致接收側(cè)有可能一下子收到多個(gè)應(yīng)用層報(bào)文，需要應(yīng)用開(kāi)發(fā)者自己分開(kāi)。

其二是指，用戶數(shù)據(jù)被TCP發(fā)出去的時(shí)候，存在多個(gè)小尺寸數(shù)據(jù)被封裝在一個(gè)TCP報(bào)文中發(fā)出去的可能性。這種“粘”不是接收側(cè)的效果，而是由于Nagle算法（或者TCP_CORK）的存在，在發(fā)送的時(shí)候，就把應(yīng)用開(kāi)發(fā)者多次send的數(shù)據(jù)，“粘”在一個(gè)tcp報(bào)文里面發(fā)出去了，于是，先被send的數(shù)據(jù)可能需要等待一段時(shí)間，才能跟后面被send的數(shù)據(jù)一起組成報(bào)文發(fā)出去。

這兩個(gè)其實(shí)都不是“問(wèn)題”。

一、針對(duì)上面第一點(diǎn)

1、分析

1）TCP 協(xié)議是基于字節(jié)流的傳輸層協(xié)議，其中不存在消息和數(shù)據(jù)包的概念。

2）應(yīng)用層協(xié)議沒(méi)有使用基于長(zhǎng)度或者基于終結(jié)符的消息邊界，導(dǎo)致多個(gè)消息的粘連，出現(xiàn)了“粘包”想象。這其實(shí)是使用者對(duì)于 TCP 的理解有誤導(dǎo)致的一個(gè)問(wèn)題。完全可以把這個(gè)問(wèn)題轉(zhuǎn)換為如何設(shè)計(jì)應(yīng)用層協(xié)議的問(wèn)題，即如何將TCP流解碼為報(bào)文數(shù)據(jù)（stream2datagram）。

3）數(shù)據(jù)傳遞

為了說(shuō)清楚這個(gè)問(wèn)題，我們先來(lái)看下client/server之間數(shù)據(jù)傳遞的過(guò)程。

1、客戶端->發(fā)送數(shù)據(jù)

2、服務(wù)端->接收數(shù)據(jù)

通常我們直覺(jué)性的認(rèn)為，客戶端直接向網(wǎng)絡(luò)中傳輸數(shù)據(jù)，對(duì)端從網(wǎng)絡(luò)中讀取數(shù)據(jù)，但是這是不正確的。

socket有緩沖區(qū)buffer的概念，每個(gè)TCP socket在內(nèi)核中都有一個(gè)發(fā)送緩沖區(qū)和一個(gè)接收緩沖區(qū)。客戶端send操作僅僅是把數(shù)據(jù)拷貝到buffer中，也就是說(shuō)send完成了，數(shù)據(jù)并不代表已經(jīng)發(fā)送到服務(wù)端了，之后才由TCP協(xié)議從buffer中發(fā)送到服務(wù)端。此時(shí)服務(wù)端的接收緩沖區(qū)被TCP緩存網(wǎng)絡(luò)上來(lái)的數(shù)據(jù)，而后server才從buffer中讀取數(shù)據(jù)。

因此，如果接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取 TCP Recv Buffer 中的數(shù)據(jù)，就會(huì)發(fā)生粘包。

2、解決辦法

最常見(jiàn)的兩種解決方案就是基于長(zhǎng)度或者基于終結(jié)符（Delimiter）。

二、針對(duì)上面第二點(diǎn)

1、分析

1）Nagle 算法是一種通過(guò)減少數(shù)據(jù)包的方式提高 TCP 傳輸性能的算法。

因?yàn)榫W(wǎng)絡(luò) 帶寬有限，它不會(huì)將小的數(shù)據(jù)塊直接發(fā)送到目的主機(jī)，而是會(huì)在本地緩沖區(qū)中等待更多待發(fā)送的數(shù)據(jù)，這種批量發(fā)送數(shù)據(jù)的策略雖然會(huì)影響實(shí)時(shí)性和網(wǎng)絡(luò)延遲，但是能夠降低網(wǎng)絡(luò)擁堵的可能性并減少額外開(kāi)銷(xiāo)。

Nagle算法如下：

如果包長(zhǎng)度達(dá)到MSS（或含有Fin包），立刻發(fā)送，否則等待下一個(gè)包到來(lái)；如果下一包到來(lái)后兩個(gè)包的總長(zhǎng)度超過(guò)MSS的話，就會(huì)進(jìn)行拆分發(fā)送；
等待超時(shí)（一般為200ms），第一個(gè)包沒(méi)到MSS長(zhǎng)度，但是又遲遲等不到第二個(gè)包的到來(lái)，則立即發(fā)送。

幾十年前還會(huì)發(fā)生網(wǎng)絡(luò)擁塞的問(wèn)題，但是今天的網(wǎng)絡(luò)帶寬資源不再像過(guò)去那么緊張，在默認(rèn)情況下，Linux 內(nèi)核都會(huì)使用如下的方式默認(rèn)關(guān)閉 Nagle 算法：

TCP_NODELAY = 1

3）除了 Nagle 算法之外，TCP 協(xié)議棧中還有另一個(gè)用于延遲發(fā)送數(shù)據(jù)的選項(xiàng) TCP_CORK，如果我們開(kāi)啟該選項(xiàng)，那么當(dāng)發(fā)送的數(shù)據(jù)小于 MSS 時(shí)，TCP 協(xié)議就會(huì)延遲 200ms 發(fā)送該數(shù)據(jù)或者等待緩沖區(qū)中的數(shù)據(jù)超過(guò) MSS5。無(wú)論是 TCP_NODELAY 還是 TCP_CORK，它們都會(huì)通過(guò)延遲發(fā)送數(shù)據(jù)來(lái)提高帶寬的利用率，它們會(huì)對(duì)應(yīng)用層協(xié)議寫(xiě)入的數(shù)據(jù)進(jìn)行拆分和重組，而這些機(jī)制和配置能夠出現(xiàn)的最重要原因是 — TCP 協(xié)議是基于字節(jié)流的協(xié)議，其本身沒(méi)有數(shù)據(jù)包的概念，不會(huì)按照數(shù)據(jù)包發(fā)送數(shù)據(jù)。

4）其實(shí)99%的情況下禁不禁止都一樣，延遲根本不是Nagle算法導(dǎo)致的；就算真有問(wèn)題，最優(yōu)解決方案也不是屏蔽Nagle算法。

2、解決辦法

設(shè)置TCP_NODELAY來(lái)屏蔽Nagle算法。不過(guò)這是要看情況的，比如：在頻繁進(jìn)行超短的信息交互（比如幾個(gè)字節(jié)）時(shí)禁用Nagle算法就是明智之舉。

不過(guò)，就算關(guān)閉 Nagle 算法，如果接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取 TCP Recv Buffer 中的數(shù)據(jù)，還是會(huì)發(fā)生粘包。

最后，“粘包”這個(gè)詞語(yǔ)容易引起歧義，不建議沿用。stream2datagram就是stream2datagram，TCP_NODELAY就是TCP_NODELAY。

參考鏈接：

https://www.zhihu.com/question/20210025/answer/1744906223

https://segmentfault.com/a/1190000039691657

https://draveness.me/whys-the-design-tcp-message-frame/

總結(jié)

以上是生活随笔為你收集整理的粘包问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。