天天看點

TCP通信粘包問題分析和解決

轉載至https://www.cnblogs.com/kex1n/p/6502002.html

在socket網絡程式中,TCP和UDP分别是面向連接配接和非面向連接配接的。是以TCP的socket程式設計,收發兩端(用戶端和伺服器端)都要有成對的socket,是以,發送端為了将多個發往接收端的包,更有效的發到對方,使用了優化方法(Nagle算法),将多次間隔較小、資料量小的資料,合并成一個大的資料塊,然後進行封包。這樣,接收端,就難于分辨出來了,必須提供科學的拆包機制。

對于UDP,不會使用塊的合并優化算法,這樣,實際上目前認為,是由于UDP支援的是一對多的模式,是以接收端的skbuff(套接字緩沖區)采用了鍊式結構來記錄每一個到達的UDP包,在每個UDP包中就有了消息頭(消息來源位址,端口等資訊),這樣,對于接收端來說,就容易進行區分處理了。是以UDP不會出現粘包問題。

====================================================================

在介紹TCP之前先普及下兩個相關的概念,長連接配接和短連接配接。

1.長連接配接

Client方與Server方先建立通訊連接配接,連接配接建立後 不斷開, 然後再進行封包發送和接收。

2.短連接配接

Client方與Server每進行一次封包收發交易時才進行通訊連接配接,交易完畢後立即斷開連接配接。此種方式常用于一點對多點通訊,比如多個Client連接配接一個Server.

TCP協定簡介

TCP是一個面向連接配接的傳輸層協定,雖然TCP不屬于ISO制定的協定集,但由于其在商業界和工業界的成功應用,它已成為事實上的網絡标準,廣泛應用于各種網絡主機間的通信。

作為一個面向連接配接的傳輸層協定,TCP的目标是為使用者提供可靠的端到端連接配接,保證資訊有序無誤的傳輸。它除了提供基本的資料傳輸功能外,還為保證可靠性采用了資料編号、校驗和計算、資料确認等一系列措施。它對傳送的每個資料位元組都進行編号,并請求接收方回傳确認資訊(ACK)。發送方如果在規定的時間内沒有收到資料确認,就重傳該資料。

(1)     資料編号使接收方能夠處理資料的失序和重複問題。

(2)     資料誤碼問題通過在每個傳輸的資料段中增加校驗和予以解決,接收方在接收到資料後檢查校驗和,若校驗和有誤,則丢棄該有誤碼的資料段,并要求發送方重傳。

(3)     流量控制也是保證可靠性的一個重要措施,若無流控,可能會因接收緩沖區溢出而丢失大量資料,導緻許多重傳,造成網絡擁塞惡性循環。

(4)     TCP采用可變視窗進行流量控制,由接收方控制發送方發送的資料量。

TCP為使用者提供了高可靠性的網絡傳輸服務,但可靠性保障措施也影響了傳輸效率。是以,在實際工程應用中,隻有關鍵資料的傳輸才采用TCP,而普通資料的傳輸一般采用高效率的UDP。

保護消息邊界和流

那麼什麼是保護消息邊界和流呢?

保護消息邊界,就是指傳輸協定把資料當作一條獨立的消息在網上傳輸,接收端隻能接收獨立的消息。也就是說存在保護消息邊界,接收端一次隻能接收發送端發出的一個資料包。而面向流則是指無保護消息保護邊界的,如果發送端連續發送資料,接收端有可能在一次接收動作中,會接收兩個或者更多的資料包。

例如,我們連續發送三個資料包,大小分别是2k,4k ,8k,這三個資料包,都已經到達了接收端的網絡堆棧中,如果使用UDP協定,不管我們使用多大的接收緩沖區去接收資料,我們必須有三次接收動作,才能夠把所有的資料包接收完.而使用TCP協定,我們隻要把接收的緩沖區大小設定在14k以上,我們就能夠一次把所有的資料包接收下來,隻需要有一次接收動作。

注意:

這就是因為UDP協定的保護消息邊界使得每一個消息都是獨立的。而流傳輸卻把資料當作一串資料流,他不認為資料是一個一個的消息。是以有很多人在使用tcp協定通訊的時候,并不清楚tcp是基于流的傳輸,當連續發送資料的時候,他們時常會認識tcp會丢包。其實不然,因為當他們使用的緩沖區足夠大時,他們有可能會一次接收到兩個甚至更多的資料包,而很多人往往會忽視這一點,隻解析檢查了第一個資料包,而已經接收的其他資料包卻被忽略了。是以大家如果要作這類的網絡程式設計的時候,必須要注意這一點。

結論:

(1)TCP為了保證可靠傳輸,盡量減少額外開銷(每次發包都要驗證),是以采用了流式傳輸,面向流的傳輸,相對于面向消息的傳輸,可以減少發送包的數量,進而減少了額外開銷。但是,對于資料傳輸頻繁的程式來講,使用TCP可能會容易粘包。當然,對接收端的程式來講,如果機器負荷很重,也會在接收緩沖裡粘包。這樣,就需要接收端額外拆包,增加了工作量。是以,這個特别适合的是資料要求可靠傳輸,但是不需要太頻繁傳輸的場合(兩次操作間隔100ms,具體是由TCP等待發送間隔決定的,取決于核心中的socket的寫法)

(2)UDP,由于面向的是消息傳輸,它把所有接收到的消息都挂接到緩沖區的接受隊列中,是以,它對于資料的提取分離就更加友善,但是,它沒有粘包機制,是以,當發送資料量較小的時候,就會發生資料包有效載荷較小的情況,也會增加多次發送的系統發送開銷(系統調用,寫硬體等)和接收開銷。是以,應該最好設定一個比較合适的資料包的包長,來進行UDP資料的發送。(UDP最大載荷為1472,是以最好能每次傳輸接近這個數的資料量,這特别适合于視訊,音頻等大塊資料的發送,同時,通過減少握手來保證流媒體的實時性)

粘包問題分析與對策

TCP粘包是指發送方發送的若幹包資料到接收方接收時粘成一包,從接收緩沖區看,後一包資料的頭緊接着前一包資料的尾。

出現粘包現象的原因是多方面的,它既可能由發送方造成,也可能由接收方造成。

什麼時候需要考慮粘包問題

1如果利用tcp每次發送資料,就與對方建立連接配接,然後雙方發送完一段資料後,就關閉連接配接,這樣就不會出現粘包問題(因為隻有一種包結構,類似于http協定)。

關閉連接配接主要是要雙方都發送close連接配接(參考tcp關閉協定)。如:A需要發送一段字元串給B,那麼A與B建立連接配接,然後發送雙方都預設好的協定字元如"hello give me sth abour yourself",然後B收到封包後,就将緩沖區資料接收,然後關閉連接配接,這樣粘包問題不用考慮到,因為大家都知道是發送一段字元。

2如果發送資料無結構,如檔案傳輸,這樣發送方隻管發送,接收方隻管接收存儲就ok,也不用考慮粘包3如果雙方建立連接配接,需要在連接配接後一段時間内發送不同結構資料,如連接配接後,有好幾種結構:

1)"hellogive me sth abour yourself"

2)"Don'tgive me sth abour yourself"

那這樣的話,如果發送方連續發送這個兩個包出去,接收方一次接收可能會是"hellogive me sth abour yourselfDon't give me sth abour yourself"這樣接收方就傻了,到底是要幹嘛?不知道,因為協定沒有規定這麼詭異的字元串,是以要處理把它分包,怎麼分也需要雙方組織一個比較好的包結構,是以一般可能會在頭加一個資料長度之類的包,以確定接收。

粘包出現原因

簡單得說,在流傳輸中出現,UDP不會出現粘包,因為它有消息邊界(參考Windows網絡程式設計)

1發送端需要等緩沖區滿才發送出去,造成粘包

2接收方不及時接收緩沖區的包,造成多個包接收

具體點:

(1)發送方引起的粘包是由TCP協定本身造成的,TCP為提高傳輸效率,發送方往往要收集到足夠多的資料後才發送一包資料。若連續幾次發送的資料都很少,通常TCP會根據優化算法把這些資料合成一包後一次發送出去,這樣接收方就收到了粘包資料。

(2)接收方引起的粘包是由于接收方使用者程序不及時接收資料,進而導緻粘包現象。這是因為接收方先把收到的資料放在系統接收緩沖區,使用者程序從該緩沖區取資料,若下一包資料到達時前一包資料尚未被使用者程序取走,則下一包資料放到系統接收緩沖區時就接到前一包資料之後,而使用者程序根據預先設定的緩沖區大小從系統接收緩沖區取資料,這樣就一次取到了多包資料。

粘包情況有兩種,一種是粘在一起的包都是完整的資料包,另一種情況是粘在一起的包有不完整的包。

不是所有的粘包現象都需要處理,若傳輸的資料為不帶結構的連續流資料(如檔案傳輸),則不必把粘連的包分開(簡稱分包)。但在實際工程應用中,傳輸的資料一般為帶結構的資料,這時就需要做分包處理。

在處理定長結構資料的粘包問題時,分包算法比較簡單;在處理不定長結構資料的粘包問題時,分包算法就比較複雜。特别是粘在一起的包有不完整的包的粘包情況,由于一包資料内容被分在了兩個連續的接收包中,處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。

為了避免粘包現象,可采取以下幾種措施:

(1)對于發送方引起的粘包現象,使用者可通過程式設計設定來避免,TCP提供了強制資料立即傳送的操作指令push,TCP軟體收到該操作指令後,就立即将本段資料發送出去,而不必等待發送緩沖區滿;

(2)對于接收方引起的粘包,則可通過優化程式設計、精簡接收程序工作量、提高接收程序優先級等措施,使其及時接收資料,進而盡量避免出現粘包現象;

(3)由接收方控制,将一包資料按結構字段,人為控制分多次接收,然後合并,通過這種手段來避免粘包。

以上提到的三種措施,都有其不足之處。

(1)第一種程式設計設定方法雖然可以避免發送方引起的粘包,但它關閉了優化算法,降低了網絡發送效率,影響應用程式的性能,一般不建議使用。

(2)第二種方法隻能減少出現粘包的可能性,但并不能完全避免粘包,當發送頻率較高時,或由于網絡突發可能使某個時間段資料包到達接收方較快,接收方還是有可能來不及接收,進而導緻粘包。

(3)第三種方法雖然避免了粘包,但應用程式的效率較低,對實時應用的場合不适合。

一種比較周全的對策是:接收方建立一預處理線程,對接收到的資料包進行預處理,将粘連的包分開。對這種方法我們進行了實驗,證明是高效可行的。

具體可以參考:http://blog.csdn.net/soli/article/details/1297109

TCP無保護消息邊界的解決

針對這個問題,一般有3種解決方案:

(1)發送固定長度的消息

(2)把消息的尺寸與消息一塊發送

(3)使用特殊标記來區分消息間隔

其解決方法具體解決可以參考:http://blog.csdn.net/zhangxinrun/article/details/6721427

網絡通訊的封包和拆包

對于基于TCP開發的通訊程式,有個很重要的問題需要解決,就是封包和拆包。

為什麼基于TCP的通訊程式需要進行封包和拆包

TCP是個"流"協定,所謂流,就是沒有界限的一串資料,大家可以想想河裡的流水,是連成一片的,其間是沒有分界線的。但一般通訊程式開發是需要定義一個個互相獨立的資料包的,比如用于登陸的資料包,用于登出的資料包。由于TCP"流"的特性以及網絡狀況,在進行資料傳輸時會出現以下幾種情況。

假設我們連續調用兩次send分别發送兩段資料data1和data2,在接收端有以下幾種接收情況(當然不止這幾種情況,這裡隻列出了有代表性的情況).

A.先接收到data1,然後接收到data2.

B.先接收到data1的部分資料,然後接收到data1餘下的部分以及data2的全部.

C.先接收到了data1的全部資料和data2的部分資料,然後接收到了data2的餘下的資料.

D.一次性接收到了data1和data2的全部資料.

對于A這種情況正是我們需要的,不再做讨論.對于B,C,D的情況就是大家經常說的"粘包",就需要我們把接收到的資料進行拆包,拆成一個個獨立的資料包,為了拆包就必須在發送端進行封包。

另:對于UDP來說就不存在拆包的問題,因為UDP是個"資料包"協定,也就是兩段資料間是有界限的,在接收端要麼接收不到資料要麼就是接收一個完整的一段資料,不會少接收也不會多接收。

為什麼會出現B.C.D的情況

1.由Nagle算法造成的發送端的粘包:Nagle算法是一種改善網絡傳輸效率的算法.簡單的說,當我們送出一段資料給TCP發送時,TCP并不立刻發送此段資料,而是等待一小段時間,看看在等待期間是否還有要發送的資料,若有則會一次把這兩段資料發送出去.這是對Nagle算法一個簡單的解釋,詳細的請看相關書籍. C和D的情況就有可能是Nagle算法造成的.

2.接收端接收不及時造成的接收端粘包:TCP會把接收到的資料存在自己的緩沖區中,然後通知應用層取資料.當應用層由于某些原因不能及時的把TCP的資料取出來,就會造成TCP緩沖區中存放了幾段資料.

怎樣封包和拆包

最初遇到"粘包"的問題時,我是通過在兩次send之間調用sleep來休眠一小段時間來解決。這個解決方法的缺點是顯而易見的,使傳輸效率大大降低,而且也并不可靠。後來就是通過應答的方式來解決,盡管在大多數時候是可行的,但是不能解決B的那種情況,而且采用應答方式增加了通訊量,加重了網絡負荷. 再後來就是對資料包進行封包和拆包的操作。

封包

封包就是給一段資料加上標頭,這樣一來資料包就分為標頭和包體兩部分内容了(以後講過濾非法包時封包會加入"包尾"内容)。標頭其實上是個大小固定的結構體,其中有個結構體成員變量表示包體的長度,這是個很重要的變量,其他的結構體成員可根據需要自己定義。根據標頭長度固定以及標頭中含有包體長度的變量就能正确的拆分出一個完整的資料包。

拆包

對于拆包目前我最常用的是以下兩種方式:

(1)動态緩沖區暫存方式。之是以說緩沖區是動态的是因為當需要緩沖的資料長度超出緩沖區的長度時會增大緩沖區長度。

大概過程描述如下:

A,為每一個連接配接動态配置設定一個緩沖區,同時把此緩沖區和SOCKET關聯,常用的是通過結構體關聯.

B,當接收到資料時首先把此段資料存放在緩沖區中.

C,判斷緩存區中的資料長度是否夠一個標頭的長度,如不夠,則不進行拆包操作.

D,根據標頭資料解析出裡面代表包體長度的變量.

E,判斷緩存區中除標頭外的資料長度是否夠一個包體的長度,如不夠,則不進行拆包操作.

F,取出整個資料包.這裡的"取"的意思是不光從緩沖區中拷貝出資料包,而且要把此資料包從緩存區中删除掉.删除的辦法就是把此包後面的資料移動到緩沖區的起始位址.

這種方法有兩個缺點.

1) 為每個連接配接動态配置設定一個緩沖區增大了記憶體的使用.

2) 有三個地方需要拷貝資料,一個地方是把資料存放在緩沖區,一個地方是把完整的資料包從緩沖區取出來,一個地方是把資料包從緩沖區中删除.第二種拆包的方法會解決和完善這些缺點.

前面提到過這種方法的缺點.下面給出一個改進辦法, 即采用環形緩沖.但是這種改進方法還是不能解決第一個缺點以及第一個資料拷貝,隻能解決第三個地方的資料拷貝(這個地方是拷貝資料最多的地方).第2種拆包方式會解決這兩個問題.

環形緩沖實作方案是定義兩個指針,分别指向有效資料的頭和尾.在存放資料和删除資料時隻是進行頭尾指針的移動.

(2)利用底層的緩沖區來進行拆包

由于TCP也維護了一個緩沖區,是以我們完全可以利用TCP的緩沖區來緩存我們的資料,這樣一來就不需要為每一個連接配接配置設定一個緩沖區了。另一方面我們知道recv或者wsarecv都有一個參數,用來表示我們要接收多長長度的資料。利用這兩個條件我們就可以對第一種方法進行優化。

對于阻塞SOCKET來說,我們可以利用一個循環來接收標頭長度的資料,然後解析出代表包體長度的那個變量,再用一個循環來接收包體長度的資料。

程式設計實作見:http://blog.csdn.net/zhangxinrun/article/details/6721495

這個問題産生于程式設計中遇到的幾個問題:

1、使用TCP的Socket發送資料的時候,會出現發送出錯,WSAEWOULDBLOCK,在TCP中不是會保證發送的資料能夠安全的到達接收端的嗎?也有視窗機制去防止發送速度過快,為什麼還會出錯呢?

2、TCP協定,在使用Socket發送資料的時候,每次發送一個包,接收端是完整的接受到一個包還是怎麼樣?如果是每發一個包,就接受一個包,為什麼還會出現粘包問題,具體是怎麼運作的?

3、關于Send,是不是隻有在非阻塞狀态下才會出現實際發送的比指定發送的小?在阻塞狀态下會不會出現實際發送的比指定發送的小,就是說隻能出現要麼全發送,要麼不發送?在非阻塞狀态下,如果之發送了一些資料,要怎麼處理,調用了Send函數後,發現傳回值比指定的要小,具體要怎麼做?

4、最後一個問題,就是TCP/IP協定和Socket是什麼關系?是指具體的實作上,Socket是TCP/IP的實作?那麼為什麼會出現使用TCP協定的Socket會發送出錯。

這個問題第1個回答:

1應該是你的緩沖區不夠大,

2 tcp是流,沒有界限.也就沒所謂的包.

3阻塞也會出現這種現象,出現後繼續發送沒發送出去的.

4tcp是協定,socket是一種接口,沒必然聯系.錯誤取決于你使用接口的問題,跟tcp沒關系.

這個問題第2個回答:

1、應該不是緩沖區大小問題,我試過設定緩沖區大小,不過這裡有個問題,就是就算我把緩沖區設定成幾G,也傳回成功,不過實際上怎麼可能設定那麼大

3、出現沒發送完的時候要手動發送吧,有沒有具體的代碼實作?

4、當選擇TCP的Socket發送資料的時候,TCP中的視窗機制不是能防止發送速度過快的嗎?為什麼Socket在出現了WSAEWOULDBLOCK後沒有處理?

這個問題第3個回答:

1.在使用非阻塞模式的情況下,如果系統發送緩沖區已滿,并示及時發送到對端,就會産生該錯誤,繼續重試即可。

3.如果沒有發完就繼續發送後續部分即可。

這個問題第4個回答:

1、使用非阻塞模式時,如果目前操作不能立即完成則會傳回失敗,錯誤碼是WSAEWOULDBLOCK,這是正常的,程式可以先執行其它任務,過一段時間後再重試該操作。

2、發送與接收不是一一對應的,TCP會把各次發送的資料重新組合,可能合并也可能拆分,但發送次序是不變的。

3、在各種情況下都要根據send的傳回值來确定發送了多少資料,沒有發送完就再接着發。

4、socket是Windows提供網絡程式設計接口,TCP/IP是網絡傳輸協定,使用socket是可以使用多種協定,其中包括TCP/IP。

這個問題第5個回答:

發送的過程是:發送到緩沖區和從緩沖區發送到網絡上

WSAEWOULDBLOCK和粘包都是出現在發送到緩沖區這個過程的

Socket程式設計 (異步通訊,解決Tcp粘包)

前面提到,TCP會出現粘包問題,下面将以執行個體示範解決方案:

問題一般會出現的情況如下,假設我們連續發送兩條兩天記錄("我是liger_zql"):

模拟發送示例:

#region 測試消息發送,并比對協定

 TcpClient client =new TcpClient();

 client.AsynConnect();

 Console.WriteLine("下面将連續發送2條測試消息...");

 Console.ReadKey();

 MessageProtocol msgPro;

  for (int i = 0; i<2; i++)

  {

     msgPro =newMessageProtocol("我是liger_zql");

     Console.WriteLine("第{0}條:{1}", i +1,msgPro.MessageInfo.Content);

     client.AsynSend(msgPro);

  }

  #endregion

接收端接受兩條資訊會出現如下三種情況:

1.(1)我是liger_zql(2)我是liger_zql

2.(1)我是liger_zql我是(2)liger_zql

3.(1)我是liger_zql我是liger_zql

通過以上三種情況,顯然2、3都不是我們想要的結果。那麼如何處理這中情況呢?

解決方案:通過自定義協定...

我們可以以将資訊以xml的格式發送出去,列入<protocol>content</protocol>通過正則比對資訊是否完整,如果不完整,我們可以先将本次接受資訊緩存接受下一次資訊,再次比對得到相應的結果。

(1)将資訊對象轉換成一定格式的xml字元串:

(2)對接收的資訊通過正則進行比對處理:

(3)将該定義的協定換換成資訊對象,通過對象擷取自己想要的資訊。

結果:

最後運作結果如下

附上源碼:SocketProQuests.zip

詳細可參考:http://www.cnblogs.com/zengqinglei/archive/2013/05/14/3078842.html

附:

關于Socket/TCP粘包、多包和少包, 斷包:http://tsing01.blog.163.com/blog/static/2059572832012716103711125/

關于Tcp封包粘包問題:http://www.cnblogs.com/jiangtong/archive/2012/03/22/2411985.html

TCP通訊處理粘包詳解:http://www.cnblogs.com/smark/p/3284756.html

參考:

http://hi.baidu.com/chongerfeia/blog/item/b1e572f631dd7e28bd310965.html

http://blog.csdn.net/binghuazh/archive/2009/05/28/4222516.aspx

http://blog.csdn.net/zhangxinrun/article/details/6721495