[轉(zhuǎn)]tcp不能保證數(shù)據(jù)傳輸?shù)娜f(wàn)無(wú)一失
■tcp認(rèn)識(shí)的誤區(qū)
應(yīng)用開(kāi)發(fā)人員常常遇到這樣的困惑:為什么用tcp寫(xiě)的應(yīng)用還會(huì)出現(xiàn)數(shù)據(jù)丟失呢?很多人都以為tcp 協(xié)議可以確保數(shù)據(jù)的傳輸,但事實(shí)上沒(méi)有任何一種協(xié)議可以做到這一點(diǎn)。tcp所能做只是傳輸數(shù)據(jù),如果失敗了,它會(huì)通知你,但它無(wú)法告訴你有多少數(shù)據(jù)沒(méi)有被正確傳送。
tcp 協(xié)議中的應(yīng)答機(jī)制使得發(fā)送方的tcp棧確保接收方tcp棧收到了數(shù)據(jù)。
tcp包頭包括32位的順序碼和應(yīng)答碼,順序碼是在連接建立時(shí)隨機(jī)產(chǎn)生的,并隨著傳輸?shù)淖止?jié)數(shù)遞增。當(dāng)數(shù)據(jù)被接收時(shí),接收方的tcp棧會(huì)給發(fā)送方發(fā)送應(yīng)答碼, 如果發(fā)送方?jīng)]收到應(yīng)答碼, 它就會(huì)重發(fā)該數(shù)據(jù)。發(fā)方和收方的順序碼是各自獨(dú)立的。
■tcp是一個(gè)窗口式的協(xié)議
tcp是一個(gè)窗口式的協(xié)議。tcp包頭數(shù)據(jù)中也包含窗口的大小,它告訴遠(yuǎn)端再傳多少數(shù)據(jù)后就必須停止。窗口大小實(shí)際上就是緩存區(qū)的大小,當(dāng)緩沖區(qū)滿的 時(shí)候,窗口就會(huì)關(guān)閉。當(dāng)發(fā)送方收到的應(yīng)答中窗口大小為零時(shí),它會(huì)自動(dòng)停止發(fā)送。發(fā)送方會(huì)記住自己發(fā)送了多少數(shù)據(jù),即使沒(méi)有收到窗口大小為零的應(yīng)答,它也不 會(huì)發(fā)送大于緩沖區(qū)的數(shù)據(jù)。
通常接收方應(yīng)答這些數(shù)據(jù)時(shí),應(yīng)用會(huì)不斷讀數(shù)據(jù),這樣窗口就經(jīng)常處于開(kāi)放狀態(tài)。
導(dǎo)致窗口關(guān)閉的最常見(jiàn)原因是i/o阻塞。這通常是臨時(shí)性的,一般i/o通暢后,緩存(窗口)會(huì)自動(dòng)開(kāi)放。第二個(gè)原因就是應(yīng)用代碼中的bug使得接收應(yīng)用程序忽略了連接,重要的不在于接收方讀沒(méi)讀數(shù)據(jù),而在于發(fā)送方在收到應(yīng)答后是否正確地發(fā)送了數(shù)據(jù)。
■tcp的緩存機(jī)制
發(fā)送tcp棧在收到應(yīng)答前必須對(duì)數(shù)據(jù)進(jìn)行緩存,而應(yīng)用程序在調(diào)用tcp棧發(fā)送數(shù)據(jù)時(shí)并不知道數(shù)據(jù)已經(jīng)在緩存區(qū)了。只要發(fā)送tcp棧還有空間,它就會(huì)接收來(lái)自應(yīng)用的數(shù)據(jù)并進(jìn)行緩存。一旦緩存滿了導(dǎo)致應(yīng)用程序無(wú)法繼續(xù)發(fā)送,它就會(huì)認(rèn)為有問(wèn)題了。
如果問(wèn)題是發(fā)送tcp棧沒(méi)有收到應(yīng)答,那么它會(huì)重發(fā),等待應(yīng)答的時(shí)間會(huì)越來(lái)越長(zhǎng),直至最終放棄并重新建立連接。重新連接后本地緩存會(huì)清空,并通知應(yīng)用 程序。但是至于有多少數(shù)據(jù)在緩存區(qū)沒(méi)有收到應(yīng)答仍不得而知。本地tcp棧無(wú)法知道遠(yuǎn)端是否收到了數(shù)據(jù),也不知道是否收到了遠(yuǎn)端應(yīng)答。
如果問(wèn)題是窗口關(guān)閉了,那么發(fā)送tcp棧會(huì)定期發(fā)送窗口探針來(lái)探測(cè)接收方窗口是否開(kāi)放。接收tcp棧必須應(yīng)答窗口探針包。應(yīng)答包含當(dāng)前窗口大小。在收到探針應(yīng)答前,發(fā)送tcp棧只能等待。
■路在何方
也許有人會(huì)說(shuō):既然如此,為何還要用tcp協(xié)議?如果應(yīng)用中必須包括數(shù)據(jù)標(biāo)識(shí)和應(yīng)答,為什么不用udp協(xié)議?tcp的優(yōu)勢(shì)在于你不必?fù)?dān)心數(shù)據(jù)傳輸機(jī) 制,如果數(shù)據(jù)包在傳輸過(guò)程中由于路由的關(guān)系,其到達(dá)順序被打亂,接收tcp棧會(huì)將這些數(shù)據(jù)包按其順序碼重新排列,從而保證了數(shù)據(jù)的正確性。而如果采用 udp的話,則應(yīng)用中必須設(shè)法提供所有這些機(jī)制。
如果發(fā)生了傳輸線路中斷,僅有應(yīng)用層的應(yīng)答是不夠的。按照應(yīng)用層應(yīng)答機(jī)制,在重建連接后,發(fā)送方會(huì)重發(fā)那些沒(méi)有收到應(yīng)答的數(shù)據(jù)包,但是有可能雖然這些 應(yīng)答丟了,可數(shù)據(jù)卻到達(dá)了,并已用于應(yīng)用程序。為了防止這種情況,發(fā)送應(yīng)用方需保存沒(méi)被接收應(yīng)用應(yīng)答的數(shù)據(jù)段的標(biāo)識(shí) ,接收應(yīng)用方也應(yīng)保存自己已接收和處理過(guò)的數(shù)據(jù)段的標(biāo)識(shí)。當(dāng)重建連接時(shí),發(fā)送方將發(fā)送第一個(gè)沒(méi)有收到應(yīng)答的數(shù)據(jù)段,或者詢問(wèn)接收方最后發(fā)出的應(yīng)答進(jìn)行確 認(rèn)。為了確保數(shù)據(jù)傳輸?shù)臒o(wú)誤, 應(yīng)該保證接收應(yīng)用方保存的數(shù)據(jù)段標(biāo)識(shí)在應(yīng)用重啟或系統(tǒng)癱瘓時(shí)仍能安然無(wú)恙。
盡管tcp協(xié)議十分優(yōu)秀,但它并不能確保數(shù)據(jù)數(shù)據(jù)傳輸萬(wàn)無(wú)一失。
應(yīng)用開(kāi)發(fā)人員常常遇到這樣的困惑:為什么用tcp寫(xiě)的應(yīng)用還會(huì)出現(xiàn)數(shù)據(jù)丟失呢?很多人都以為tcp 協(xié)議可以確保數(shù)據(jù)的傳輸,但事實(shí)上沒(méi)有任何一種協(xié)議可以做到這一點(diǎn)。tcp所能做只是傳輸數(shù)據(jù),如果失敗了,它會(huì)通知你,但它無(wú)法告訴你有多少數(shù)據(jù)沒(méi)有被正確傳送。
tcp 協(xié)議中的應(yīng)答機(jī)制使得發(fā)送方的tcp棧確保接收方tcp棧收到了數(shù)據(jù)。
tcp包頭包括32位的順序碼和應(yīng)答碼,順序碼是在連接建立時(shí)隨機(jī)產(chǎn)生的,并隨著傳輸?shù)淖止?jié)數(shù)遞增。當(dāng)數(shù)據(jù)被接收時(shí),接收方的tcp棧會(huì)給發(fā)送方發(fā)送應(yīng)答碼, 如果發(fā)送方?jīng)]收到應(yīng)答碼, 它就會(huì)重發(fā)該數(shù)據(jù)。發(fā)方和收方的順序碼是各自獨(dú)立的。
■tcp是一個(gè)窗口式的協(xié)議
tcp是一個(gè)窗口式的協(xié)議。tcp包頭數(shù)據(jù)中也包含窗口的大小,它告訴遠(yuǎn)端再傳多少數(shù)據(jù)后就必須停止。窗口大小實(shí)際上就是緩存區(qū)的大小,當(dāng)緩沖區(qū)滿的 時(shí)候,窗口就會(huì)關(guān)閉。當(dāng)發(fā)送方收到的應(yīng)答中窗口大小為零時(shí),它會(huì)自動(dòng)停止發(fā)送。發(fā)送方會(huì)記住自己發(fā)送了多少數(shù)據(jù),即使沒(méi)有收到窗口大小為零的應(yīng)答,它也不 會(huì)發(fā)送大于緩沖區(qū)的數(shù)據(jù)。
通常接收方應(yīng)答這些數(shù)據(jù)時(shí),應(yīng)用會(huì)不斷讀數(shù)據(jù),這樣窗口就經(jīng)常處于開(kāi)放狀態(tài)。
導(dǎo)致窗口關(guān)閉的最常見(jiàn)原因是i/o阻塞。這通常是臨時(shí)性的,一般i/o通暢后,緩存(窗口)會(huì)自動(dòng)開(kāi)放。第二個(gè)原因就是應(yīng)用代碼中的bug使得接收應(yīng)用程序忽略了連接,重要的不在于接收方讀沒(méi)讀數(shù)據(jù),而在于發(fā)送方在收到應(yīng)答后是否正確地發(fā)送了數(shù)據(jù)。
■tcp的緩存機(jī)制
發(fā)送tcp棧在收到應(yīng)答前必須對(duì)數(shù)據(jù)進(jìn)行緩存,而應(yīng)用程序在調(diào)用tcp棧發(fā)送數(shù)據(jù)時(shí)并不知道數(shù)據(jù)已經(jīng)在緩存區(qū)了。只要發(fā)送tcp棧還有空間,它就會(huì)接收來(lái)自應(yīng)用的數(shù)據(jù)并進(jìn)行緩存。一旦緩存滿了導(dǎo)致應(yīng)用程序無(wú)法繼續(xù)發(fā)送,它就會(huì)認(rèn)為有問(wèn)題了。
如果問(wèn)題是發(fā)送tcp棧沒(méi)有收到應(yīng)答,那么它會(huì)重發(fā),等待應(yīng)答的時(shí)間會(huì)越來(lái)越長(zhǎng),直至最終放棄并重新建立連接。重新連接后本地緩存會(huì)清空,并通知應(yīng)用 程序。但是至于有多少數(shù)據(jù)在緩存區(qū)沒(méi)有收到應(yīng)答仍不得而知。本地tcp棧無(wú)法知道遠(yuǎn)端是否收到了數(shù)據(jù),也不知道是否收到了遠(yuǎn)端應(yīng)答。
如果問(wèn)題是窗口關(guān)閉了,那么發(fā)送tcp棧會(huì)定期發(fā)送窗口探針來(lái)探測(cè)接收方窗口是否開(kāi)放。接收tcp棧必須應(yīng)答窗口探針包。應(yīng)答包含當(dāng)前窗口大小。在收到探針應(yīng)答前,發(fā)送tcp棧只能等待。
■路在何方
也許有人會(huì)說(shuō):既然如此,為何還要用tcp協(xié)議?如果應(yīng)用中必須包括數(shù)據(jù)標(biāo)識(shí)和應(yīng)答,為什么不用udp協(xié)議?tcp的優(yōu)勢(shì)在于你不必?fù)?dān)心數(shù)據(jù)傳輸機(jī) 制,如果數(shù)據(jù)包在傳輸過(guò)程中由于路由的關(guān)系,其到達(dá)順序被打亂,接收tcp棧會(huì)將這些數(shù)據(jù)包按其順序碼重新排列,從而保證了數(shù)據(jù)的正確性。而如果采用 udp的話,則應(yīng)用中必須設(shè)法提供所有這些機(jī)制。
如果發(fā)生了傳輸線路中斷,僅有應(yīng)用層的應(yīng)答是不夠的。按照應(yīng)用層應(yīng)答機(jī)制,在重建連接后,發(fā)送方會(huì)重發(fā)那些沒(méi)有收到應(yīng)答的數(shù)據(jù)包,但是有可能雖然這些 應(yīng)答丟了,可數(shù)據(jù)卻到達(dá)了,并已用于應(yīng)用程序。為了防止這種情況,發(fā)送應(yīng)用方需保存沒(méi)被接收應(yīng)用應(yīng)答的數(shù)據(jù)段的標(biāo)識(shí) ,接收應(yīng)用方也應(yīng)保存自己已接收和處理過(guò)的數(shù)據(jù)段的標(biāo)識(shí)。當(dāng)重建連接時(shí),發(fā)送方將發(fā)送第一個(gè)沒(méi)有收到應(yīng)答的數(shù)據(jù)段,或者詢問(wèn)接收方最后發(fā)出的應(yīng)答進(jìn)行確 認(rèn)。為了確保數(shù)據(jù)傳輸?shù)臒o(wú)誤, 應(yīng)該保證接收應(yīng)用方保存的數(shù)據(jù)段標(biāo)識(shí)在應(yīng)用重啟或系統(tǒng)癱瘓時(shí)仍能安然無(wú)恙。
盡管tcp協(xié)議十分優(yōu)秀,但它并不能確保數(shù)據(jù)數(shù)據(jù)傳輸萬(wàn)無(wú)一失。
posted on 2011-07-21 15:08 艾斯維亞 閱讀(2159) 評(píng)論(0) 編輯 收藏 引用