基于TCP協(xié)議下的網(wǎng)絡(luò)數(shù)據(jù)提取算法研究

精品文檔-下載后可編輯基于TCP協(xié)議下的網(wǎng)絡(luò)數(shù)據(jù)提取算法研究摘要通過(guò)TCP協(xié)議發(fā)送的數(shù)據(jù)包都會(huì)按字節(jié)進(jìn)行編號(hào)處理，其目的是當(dāng)對(duì)方在接到數(shù)據(jù)，在校驗(yàn)無(wú)誤的情況下接收方將會(huì)發(fā)出ACK（傳輸正確確認(rèn)信息）。如果發(fā)送數(shù)據(jù)端在預(yù)先設(shè)定時(shí)間內(nèi)沒(méi)有接到來(lái)自來(lái)接收端的確認(rèn)信息，那么發(fā)送方將認(rèn)為數(shù)據(jù)報(bào)文未正確到達(dá)接收端，需要重新發(fā)送數(shù)據(jù)。數(shù)據(jù)包進(jìn)行編號(hào)的優(yōu)點(diǎn)還有一個(gè)是確保接收端在收到數(shù)據(jù)時(shí)，能夠正確快速的處理數(shù)據(jù)，確保有序，有效重組報(bào)文以及丟棄無(wú)效或冗余數(shù)據(jù)。

【關(guān)鍵詞】網(wǎng)絡(luò)數(shù)據(jù)提取算法

通過(guò)TCP協(xié)議發(fā)送的數(shù)據(jù)包都會(huì)按字節(jié)進(jìn)行編號(hào)處理，其目的是當(dāng)對(duì)方在接到數(shù)據(jù)，在校驗(yàn)無(wú)誤的情況下接收方將會(huì)發(fā)出ACK（傳輸正確確認(rèn)信息）。如果發(fā)送數(shù)據(jù)端在預(yù)先設(shè)定時(shí)間內(nèi)沒(méi)有接到來(lái)自來(lái)接收端的確認(rèn)信息，那么發(fā)送方將認(rèn)為數(shù)據(jù)報(bào)文未正確到達(dá)接收端，需要重新發(fā)送數(shù)據(jù)。數(shù)據(jù)包進(jìn)行編號(hào)的優(yōu)點(diǎn)還有一個(gè)是確保接收端在收到數(shù)據(jù)時(shí)，能夠正確快速的處理數(shù)據(jù)，確保有序，有效重組報(bào)文以及丟棄無(wú)效或冗余數(shù)據(jù)。

TCP協(xié)議也不是十全十美，其可靠性保障措施是以犧牲部分傳輸效率為代價(jià)而換來(lái)的。因而在實(shí)際網(wǎng)絡(luò)應(yīng)用中，TCP協(xié)議只用來(lái)傳輸關(guān)鍵的、靠性要求很高的網(wǎng)絡(luò)鍵數(shù)據(jù)；而對(duì)于如即時(shí)視頻數(shù)據(jù)、音頻數(shù)據(jù)等等，因?yàn)槠洳粦峙碌舭栽谶@類(lèi)網(wǎng)絡(luò)環(huán)境的傳輸則采用高效率的UDP協(xié)議。

1TCP粘包原因研究

粘連數(shù)據(jù)包發(fā)生的原因可以?xún)蓚€(gè)方面來(lái)進(jìn)行剖析，其原因可能是由數(shù)據(jù)發(fā)送端產(chǎn)生，也可能是由數(shù)據(jù)接端方造成。假如網(wǎng)絡(luò)數(shù)據(jù)量較小，發(fā)送的網(wǎng)絡(luò)數(shù)據(jù)包都很少，根據(jù)TCP協(xié)議自身的優(yōu)化算法，通常會(huì)把這些數(shù)據(jù)整合成一個(gè)報(bào)文傳輸?shù)浇邮斩耍谶@個(gè)原因接收方就收到了幾個(gè)數(shù)據(jù)包合成的粘包數(shù)據(jù)。第二，由于接收方計(jì)算機(jī)性能或者其它原因，可能不能及時(shí)的從網(wǎng)絡(luò)IO緩存區(qū)中取走數(shù)據(jù)，進(jìn)而導(dǎo)致發(fā)生在接收端的網(wǎng)絡(luò)數(shù)據(jù)粘包。這是TCP協(xié)議自身算法原因，在網(wǎng)卡從網(wǎng)絡(luò)上收到正確無(wú)誤的數(shù)據(jù)時(shí)，需要將數(shù)據(jù)暫時(shí)放入系統(tǒng)網(wǎng)絡(luò)IO接收緩存區(qū)，等待上層應(yīng)用程序從系統(tǒng)緩沖區(qū)取走網(wǎng)絡(luò)數(shù)據(jù)，假如在新的數(shù)據(jù)報(bào)文到達(dá)時(shí)，緩存區(qū)中舊的數(shù)據(jù)報(bào)文內(nèi)容還沒(méi)有被上層應(yīng)用程序取走，那么就會(huì)發(fā)生新到數(shù)據(jù)包緊挨著舊數(shù)據(jù)包存放，形成一個(gè)大的數(shù)據(jù)塊。而且上層應(yīng)層程序只能按固定定大小的緩存區(qū)來(lái)取數(shù)據(jù)，由于有多個(gè)報(bào)文存在，程序從網(wǎng)絡(luò)接收緩存區(qū)中取出的數(shù)據(jù)，極有可能是來(lái)自多個(gè)數(shù)據(jù)報(bào)文。

粘包的方式有下面兩種，一種是操作系統(tǒng)接收多個(gè)數(shù)據(jù)包，并緩存在緩沖區(qū)，用戶(hù)出緩沖區(qū)取出的網(wǎng)絡(luò)包為多個(gè)完整的數(shù)據(jù)包，另一種情況也是最常見(jiàn)是用戶(hù)取出的多個(gè)包粘在一起，并且不是完整的包。粘連在一起的網(wǎng)絡(luò)數(shù)據(jù)包也不一定都需要進(jìn)一步的處理，比如在粘連的數(shù)據(jù)包（文件交換），這種數(shù)據(jù)沒(méi)有具體格式，不間斷地“流”式數(shù)據(jù)，不必要做包分離處理（簡(jiǎn)稱(chēng)“分包”），如果在實(shí)際的網(wǎng)絡(luò)傳輸中，大部分的信息都需要分開(kāi)，所以在這些原始數(shù)據(jù)上都加入一定的數(shù)據(jù)格式，再次封裝，在接收端按照一定的算法進(jìn)行分包處理。

當(dāng)網(wǎng)絡(luò)數(shù)據(jù)包的格式數(shù)固定長(zhǎng)度時(shí)（即按固定長(zhǎng)度發(fā)送數(shù)據(jù)），所使用的分包算法則相對(duì)簡(jiǎn)單一些；對(duì)于在網(wǎng)絡(luò)數(shù)據(jù)沒(méi)有固定格式，需要通過(guò)多步計(jì)算來(lái)確定數(shù)據(jù)結(jié)構(gòu)的，它們所使用的算法就變地相對(duì)困難，其中最為關(guān)鍵的難度就在于如果一個(gè)完整的網(wǎng)絡(luò)包被分成兩部分，一部分先接收，后一部分后接收，在這其中如果需要重新打包，計(jì)算包長(zhǎng)，所以處理起來(lái)難度就比較大。

為了避免在實(shí)際的網(wǎng)絡(luò)環(huán)境使用中出現(xiàn)粘包，從常用的技術(shù)中歸避粘包，軟件設(shè)計(jì)人員常使用如下三種方式；發(fā)送者所引起的網(wǎng)絡(luò)粘包，在發(fā)送者一端用戶(hù)可以通過(guò)網(wǎng)絡(luò)編程來(lái)配置網(wǎng)絡(luò)參數(shù)來(lái)規(guī)避，例如強(qiáng)制數(shù)據(jù)立即傳送：在TCP網(wǎng)絡(luò)通信中的緊急通信標(biāo)記PUSH，在底層操作系統(tǒng)的網(wǎng)絡(luò)模塊TCP協(xié)議收到該操作標(biāo)記時(shí)，會(huì)將當(dāng)前TCP緩存區(qū)的數(shù)據(jù)立即推送到網(wǎng)絡(luò)上去，而不必等待TCP發(fā)送系統(tǒng)緩存區(qū)滿(mǎn)；第二種情況是因?yàn)榻邮照咛幚聿划?dāng)導(dǎo)致地的網(wǎng)絡(luò)粘包，可以通過(guò)在調(diào)高接收線(xiàn)程或者接收進(jìn)程的CPU等級(jí)，使CPU優(yōu)先調(diào)度，還可以精簡(jiǎn)接收線(xiàn)程接收代碼，使其只負(fù)責(zé)接收數(shù)據(jù)，分配其它線(xiàn)程處理接收到的數(shù)據(jù)包，在這種優(yōu)化方式下，可以迅速的接收網(wǎng)絡(luò)中的數(shù)據(jù)，進(jìn)而規(guī)避粘連包；第三種方式為接收者從網(wǎng)絡(luò)中，只讀取按之前約定大小的數(shù)據(jù)，既不多讀也不少讀。如果約定數(shù)據(jù)較小，那么需要多次讀取網(wǎng)絡(luò)數(shù)據(jù)，并且在最后才能合成一個(gè)完整包。

上述所的三方案都有嚴(yán)重的缺點(diǎn)。方案一用程序代碼的方式設(shè)置PUSH標(biāo)記，解決了粘包問(wèn)題，但是新問(wèn)題是TCP發(fā)送數(shù)據(jù)的優(yōu)化算法在停用狀態(tài)下，將導(dǎo)致網(wǎng)絡(luò)利用率大幅度下降，進(jìn)一步影響整個(gè)系統(tǒng)的整體性能，正常情況下不應(yīng)使用該方法；方案二也只是降低了網(wǎng)絡(luò)粘包的概率，沒(méi)有從根本上杜絕。方案三的缺點(diǎn)應(yīng)用程序需要多次讀系統(tǒng)網(wǎng)絡(luò)接口，工作效率較低，對(duì)要求快速響應(yīng)網(wǎng)絡(luò)環(huán)境不推薦使用。

2TCP分包算法設(shè)計(jì)

在實(shí)際應(yīng)用開(kāi)發(fā)過(guò)程中，發(fā)現(xiàn)基于數(shù)據(jù)流處理傳輸?shù)腡CP協(xié)議，當(dāng)在傳輸大批量的網(wǎng)絡(luò)數(shù)據(jù)包時(shí)會(huì)出現(xiàn)粘包現(xiàn)象，即是發(fā)送方以較高傳輸速度發(fā)送若干包數(shù)據(jù)發(fā)送數(shù)據(jù)，當(dāng)數(shù)據(jù)到達(dá)接收方時(shí)，數(shù)據(jù)從網(wǎng)絡(luò)中取出時(shí)，不能區(qū)分?jǐn)?shù)據(jù)內(nèi)容是屬于哪個(gè)包，完全粘連成一個(gè)整包。針對(duì)這種粘包情況對(duì)TCP協(xié)議進(jìn)行了大量研究和實(shí)驗(yàn)，分析TCP網(wǎng)絡(luò)通信產(chǎn)生粘包的原因是先決問(wèn)題，并在此基礎(chǔ)上通過(guò)實(shí)驗(yàn)結(jié)果數(shù)據(jù)給出了處理TCP粘包問(wèn)題的方法與對(duì)策。

經(jīng)過(guò)上述分析給出高效解決方案：每一個(gè)在套接字連接分配一個(gè)單緩存區(qū)，對(duì)發(fā)送方對(duì)數(shù)據(jù)進(jìn)行格式化處理后在進(jìn)行發(fā)送。

類(lèi)型：為指出數(shù)據(jù)的類(lèi)型（如文件共享，文件碎片以及各種請(qǐng)求命令等）

數(shù)據(jù)長(zhǎng)度：指出后面有n個(gè)Byte數(shù)據(jù)要處理（除出類(lèi)型與數(shù)據(jù)長(zhǎng)度共長(zhǎng)8Byte)

數(shù)據(jù)：為真實(shí)需要傳輸?shù)膬?nèi)容

基本思路是首先將待處理的接收數(shù)據(jù)流其長(zhǎng)度設(shè)為m，數(shù)據(jù)格式如圖2-3中的n所示，然后在依靠數(shù)據(jù)長(zhǎng)度n計(jì)算得到一個(gè)完整數(shù)據(jù)報(bào)文的長(zhǎng)度。

（1）單緩存區(qū)獲取已接收數(shù)據(jù)的大小（r）。

（2）如果r>=8則強(qiáng)行轉(zhuǎn)換成預(yù)定的結(jié)構(gòu)數(shù)據(jù)形式，并從中網(wǎng)絡(luò)數(shù)據(jù)格中取出數(shù)據(jù)長(zhǎng)度字段（l），計(jì)算需要寫(xiě)入緩存區(qū)的數(shù)據(jù)大?。╯），s=l-(r-8);

（3）若m

（4）若m>=s，則將m中s長(zhǎng)的數(shù)據(jù)寫(xiě)入緩存區(qū)，并報(bào)告完整數(shù)據(jù)到達(dá)。

（5）若m-s>0，則將多余的數(shù)據(jù)繼續(xù)傳入下一次遞歸函數(shù)中。

（6）若r

（7）若r=8-r，向緩存區(qū)中寫(xiě)入長(zhǎng)度為8-r的數(shù)據(jù)，剩余數(shù)據(jù)進(jìn)入下一次遞歸函數(shù)繼續(xù)處理。

3實(shí)驗(yàn)結(jié)果與結(jié)論

實(shí)驗(yàn)環(huán)境設(shè)計(jì)根本原因在于提高服務(wù)器與客戶(hù)端的傳輸效率，盡可能的避免因?qū)嶒?yàn)環(huán)境而造成的實(shí)驗(yàn)誤差；服務(wù)器與客戶(hù)端均采用IOCP與線(xiàn)程池結(jié)合的方式最大限度的提高傳輸效率，提高服務(wù)器與客戶(hù)端數(shù)據(jù)的吞吐量，線(xiàn)程池中線(xiàn)程數(shù)為4；服務(wù)器支持文件的分段下載，支持?jǐn)帱c(diǎn)續(xù)傳，文件內(nèi)存映射等提高傳輸與存取文件效率的技術(shù)；客戶(hù)端并發(fā)連接請(qǐng)求數(shù)為10，盡可能的降低因單連接而引的傳輸速度不足，不能全完測(cè)試此算法的穩(wěn)定性。實(shí)驗(yàn)環(huán)境結(jié)構(gòu)圖如下所示。

客戶(hù)端采用TCP分包算法，根據(jù)算法需對(duì)對(duì)客戶(hù)端每一個(gè)并發(fā)連接都需要建立緩存區(qū)，保存暫未收到完整數(shù)據(jù)的包。

（1）在上述實(shí)驗(yàn)環(huán)境下，當(dāng)服務(wù)器連續(xù)發(fā)送的若干個(gè)數(shù)據(jù)包總長(zhǎng)度之和低于1500字節(jié)時(shí)，常會(huì)出現(xiàn)“粘包”現(xiàn)象，TCP分包遞歸算法能根據(jù)數(shù)據(jù)頭部，遞歸取出相互粘連的網(wǎng)絡(luò)包。若服務(wù)器關(guān)采取關(guān)閉“nagle優(yōu)化算法”，解決小封包問(wèn)題，但也導(dǎo)致較高的不可預(yù)測(cè)的延遲，同時(shí)降低了吞吐量。

（2）服務(wù)器發(fā)送數(shù)據(jù)包在1Kb到2Kb時(shí)，如果時(shí)間間隔低于9.8ms，會(huì)出現(xiàn)不定時(shí)的“粘包”現(xiàn)象，算法在接收到數(shù)據(jù)包時(shí)，也能對(duì)包進(jìn)行正確的分解，做到數(shù)據(jù)包分段分離。

（3）為測(cè)定算法在處理變長(zhǎng)數(shù)據(jù)包的穩(wěn)定性與時(shí)間，服務(wù)器隨機(jī)發(fā)送大小為1.4kb、1.8kb、1.3kb、1.7kb、1.1kb網(wǎng)絡(luò)數(shù)據(jù)包，總計(jì)1500個(gè)。為造成大量粘包的網(wǎng)絡(luò)數(shù)據(jù)，客戶(hù)端在開(kāi)始啟動(dòng)算法先線(xiàn)程睡眠10ms，而客戶(hù)端單緩存區(qū)大小為2Kb，統(tǒng)計(jì)發(fā)現(xiàn)客戶(hù)端接到1500個(gè)數(shù)據(jù)包，其中因粘包而被緩存的數(shù)據(jù)高達(dá)1079個(gè)，粘包率達(dá)到71.9%，經(jīng)過(guò)算法的解析均能正確的分離數(shù)據(jù)包，粘包處理總時(shí)長(zhǎng)小于1ms。

經(jīng)多次實(shí)驗(yàn)數(shù)據(jù)表明，TCP“粘包”現(xiàn)象的確存在，但采用此遞歸算法能穩(wěn)定分解大量并發(fā)數(shù)據(jù)包，接收方的預(yù)處理予以解決，而且處理時(shí)間非常短（實(shí)驗(yàn)中1000包數(shù)據(jù)總共處理時(shí)間不到1ms），幾乎不影響應(yīng)用程序的正常工作。在多線(xiàn)程的大文件傳輸過(guò)程中，能保證數(shù)據(jù)有效可靠的按照編號(hào)存儲(chǔ)，不會(huì)因?yàn)槎嗑€(xiàn)程導(dǎo)致的數(shù)據(jù)多位，亂序的情況。

4結(jié)束語(yǔ)

由于TCP自身“nagle算法”的存在，導(dǎo)致在小數(shù)據(jù)量時(shí)，數(shù)據(jù)包可能出現(xiàn)粘連的情況，提出TCP分包遞歸算法，通過(guò)實(shí)驗(yàn)得到很好的實(shí)現(xiàn)結(jié)果，解決“粘包”問(wèn)題，算法在時(shí)間，空間上開(kāi)銷(xiāo)都較小，分包算法中使用單緩存區(qū)降低設(shè)計(jì)的復(fù)雜性、提高算法的穩(wěn)定性。此算法不但解決在本線(xiàn)程中“粘包”問(wèn)題，不會(huì)干擾（同步、互斥）其它線(xiàn)程的工作，此算法不會(huì)限定數(shù)據(jù)總長(zhǎng)，不會(huì)壓縮