http://blog.163.com/linfenliang@126/blog/static/127857195201310231037392/
2013
粘包產(chǎn)生原因：
先說(shuō)TCP：由于TCP協(xié)議本身的機制（面向連接的可靠地協(xié)議-三次握手機制）客戶(hù)端與服務(wù)器會(huì )維持一個(gè)連接（Channel），數據在連接不斷開(kāi)的情況下，可以持續不斷地將多個(gè)數據包發(fā)往服務(wù)器，但是如果發(fā)送的網(wǎng)絡(luò )數據包太小，那么他本身會(huì )啟用Nagle算法（可配置是否啟用）對較小的數據包進(jìn)行合并（基于此，TCP的網(wǎng)絡(luò )延遲要UDP的高些）然后再發(fā)送（超時(shí)或者包大小足夠）。那么這樣的話(huà)，服務(wù)器在接收到消息（數據流）的時(shí)候就無(wú)法區分哪些數據包是客戶(hù)端自己分開(kāi)發(fā)送的，這樣產(chǎn)生了粘包；服務(wù)器在接收到數據庫后，放到緩沖區中，如果消息沒(méi)有被及時(shí)從緩存區取走，下次在取數據的時(shí)候可能就會(huì )出現一次取出多個(gè)數據包的情況，造成粘包現象（確切來(lái)講，對于基于TCP協(xié)議的應用，不應用包來(lái)描述，而應 用 流來(lái)描述），個(gè)人認為服務(wù)器接收端產(chǎn)生的粘包應該與linux內核處理socket的方式 select輪詢(xún)機制的線(xiàn)性?huà)呙桀l度無(wú)關(guān)。
再說(shuō)UDP：本身作為無(wú)連接的不可靠的傳輸協(xié)議（適合頻繁發(fā)送較小的數據包），他不會(huì )對數據包進(jìn)行合并發(fā)送（也就沒(méi)有Nagle算法之說(shuō)了），他直接是一端發(fā)送什么數據，直接就發(fā)出去了，既然他不會(huì )對數據合并，每一個(gè)數據包都是完整的（數據+UDP頭+IP頭等等發(fā)一次數據封裝一次）也就沒(méi)有粘包一說(shuō)了。
分包產(chǎn)生的原因就簡(jiǎn)單的多：可能是IP分片傳輸導致的，也可能是傳輸過(guò)程中丟失部分包導致出現的半包，還有可能就是一個(gè)包可能被分成了兩次傳輸，在取數據的時(shí)候，先取到了一部分（還可能與接收的緩沖區大小有關(guān)系），總之就是一個(gè)數據包被分成了多次接收。
解決辦法：
粘包與分包的處理方法：
我根據現有的一些開(kāi)源資料做了如下總結（常用的解決方案）：
一個(gè)是采用分隔符的方式，即我們在封裝要傳輸的數據包的時(shí)候，采用固定的符號作為結尾符（數據中不能含結尾符），這樣我們接收到數據后，如果出現結尾標識，即人為的將粘包分開(kāi)，如果一個(gè)包中沒(méi)有出現結尾符，認為出現了分包，則等待下個(gè)包中出現后 組合成一個(gè)完整的數據包，這種方式適合于文本傳輸的數據，如采用/r/n之類(lèi)的分隔符；
另一種是采用在數據包中添加長(cháng)度的方式，即在數據包中的固定位置封裝數據包的長(cháng)度信息（或可計算數據包總長(cháng)度的信息），服務(wù)器接收到數據后，先是解析包長(cháng)度，然后根據包長(cháng)度截取數據包（此種方式常出現于自定義協(xié)議中），但是有個(gè)小問(wèn)題就是如果客戶(hù)端第一個(gè)數據包數據長(cháng)度封裝的有錯誤，那么很可能就會(huì )導致后面接收到的所有數據包都解析出錯（由于TCP建立連接后流式傳輸機制），只有客戶(hù)端關(guān)閉連接后重新打開(kāi)才可以消除此問(wèn)題，我在處理這個(gè)問(wèn)題的時(shí)候對數據長(cháng)度做了校驗，會(huì )適時(shí)的對接收到的有問(wèn)題的包進(jìn)行人為的丟棄處理（客戶(hù)端有自動(dòng)重發(fā)機制，故而在應用層不會(huì )導致數據的不完整性）；
另一種不建議的方式是TCP采用短連接處理粘包（這個(gè)得根據需要來(lái)，所以不建議）；
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
