|
|||||||||||
| 技術(shù)交流 | 電路欣賞 | 工控天地 | 數(shù)字廣電 | 通信技術(shù) | 電源技術(shù) | 測控之家 | EMC技術(shù) | ARM技術(shù) | EDA技術(shù) | PCB技術(shù) | 嵌入式系統(tǒng) 驅(qū)動編程 | 集成電路 | 器件替換 | 模擬技術(shù) | 新手園地 | 單 片 機 | DSP技術(shù) | MCU技術(shù) | IC 設(shè)計 | IC 產(chǎn)業(yè) | CAN-bus/DeviceNe |
ＧＰＲＳ／ＣＤＭＡ行業(yè)應(yīng)用中的TCP與UDP的比較！ |
| 作者：lxj7871 欄目：通信技術(shù) |
中國移動、中國聯(lián)通推行的GPRS網(wǎng)絡(luò)、CDMA網(wǎng)絡(luò)已覆蓋大量的區(qū)域，通過無線網(wǎng)絡(luò)實現(xiàn)數(shù)據(jù)傳輸成為可能。無線MODEM采用GPRS、CDMA模塊通過中國移動、中國聯(lián)通的GPRS、CDMA網(wǎng)絡(luò)進行數(shù)據(jù)傳輸，并通過TCP/IP協(xié)議進行數(shù)據(jù)封包，可靈活地實現(xiàn)多種設(shè)備接入，工程安裝簡單，在工業(yè)現(xiàn)場數(shù)據(jù)傳輸?shù)膽?yīng)用中，能很好的解決偏遠無網(wǎng)絡(luò)無電話線路地區(qū)的數(shù)據(jù)傳輸?shù)碾y題。同傳統(tǒng)的數(shù)傳電臺想比較，更具有簡便性、靈活性、易操作性，同時還降低了成本，無線MODEM傳輸方案是現(xiàn)代化工業(yè)現(xiàn)場數(shù)據(jù)傳輸最好的選擇方案。 目前中國移動、中國聯(lián)通提供的GPRS網(wǎng)絡(luò)、CDMA網(wǎng)絡(luò)的數(shù)據(jù)傳輸帶寬在40Kbps左右，且受帶寬的限制，數(shù)據(jù)采集方案最好采用于主動告警、數(shù)據(jù)輪巡采集、告警主動回叫等對傳輸帶寬占用較少的采集方式。同時考慮對前置機實時采集方案的支持，無線MODEM傳輸方案只能作為目前傳輸方案的補充。 隨著無線通訊技術(shù)的不斷發(fā)展，無線傳輸數(shù)據(jù)帶寬將不斷提高，采用3G無線網(wǎng)絡(luò)，數(shù)據(jù)傳輸帶寬將達到2M，無線傳輸方案將逐漸成為監(jiān)控傳輸組網(wǎng)的主要應(yīng)用方案。 目前，由于GPRS和CDMA固有的特性，在各個領(lǐng)域中GPRS和CDMA的應(yīng)用也越來越廣泛，但是關(guān)于傳輸中使用TCP/IP協(xié)議還是UDP協(xié)議，卻爭論很多。 這里先簡單的說一下TCP與UDP的區(qū)別： 1。基于連接與無連接 2。對系統(tǒng)資源的要求（TCP較多，UDP少） 3。UDP程序結(jié)構(gòu)較簡單 4。流模式與數(shù)據(jù)報模式 5。TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證 另外結(jié)合GPRS網(wǎng)絡(luò)的情況具體的談一下他們的區(qū)別： 1。TCP傳輸存在一定的延時，大概是1600MS（移動提供），UDP響應(yīng)速度稍微快一些。 2。TCP包頭結(jié)構(gòu) 源端口16位 目標端口 16位 序列號 32位 回應(yīng)序號 32位 TCP頭長度 4位 reserved 6位 控制代碼6位 窗口大小16位 偏移量16位 校驗和16位 選項 32位(可選) 這樣我們得出了TCP包頭的最小大小.就是20字節(jié). UDP包頭結(jié)構(gòu) 源端口16位 目的端口16位 長度 16位 校驗和 16位 UDP的包小很多.確實如此.因為UDP是非可靠連接.設(shè)計初衷就是盡可能快的將數(shù)據(jù)包發(fā)送出去.所以UDP協(xié)議顯得非常精簡. 3。GPRS網(wǎng)絡(luò)端口資源，UDP十分緊缺，變化很快；而TCP采用可靠鏈路傳輸，不存在端口變化的問題 工業(yè)場合的應(yīng)用一般都有以下特點， 1。要求時時傳輸，但也有一些場合是定時傳輸，總的來說在整個傳輸過程中要求服務(wù)器中心端和GPRS終端設(shè)備能相互的、時時的傳輸數(shù)據(jù)。 TCP本身就是可靠鏈路傳輸，提供一個時時的雙向的傳輸通道，能很好的滿足工業(yè)現(xiàn)場傳輸?shù)囊�。但是GPRS網(wǎng)絡(luò)對TCP鏈路也存在一個限制：此條鏈路在長時間（大概20分鐘左右，視具體情況而定）沒有數(shù)據(jù)流量，會自動降低此鏈路的優(yōu)先級直至強制斷開此鏈路。所以在實際使用中也會采用心跳包（一般是一個字節(jié)的數(shù)據(jù)）來維持此鏈路。 UDP由于自身特點，以及GPRS網(wǎng)絡(luò)UDP端口資源的有限性，在一段時間沒有數(shù)據(jù)流量后，端口容易改變，產(chǎn)生的影響就是從服務(wù)器中心端向GPRS終端發(fā)送數(shù)據(jù)，GPRS終端接收不到。具體的原因就是移動網(wǎng)關(guān)從中作了中轉(zhuǎn)，需要隔一定時間給主機發(fā)UDP包來維持這個IP和端口號,這樣主機就能主動給GPRS發(fā)UDP包了并且我在測試中發(fā)現(xiàn),這個間隔時間很短,我在1多分鐘發(fā)一次UDP包才能夠維持,但是再長可能移動網(wǎng)關(guān)那邊就要丟失這個端口了,此時如果主機想主動發(fā)數(shù)據(jù)給GPRS,那肯定是不行的了,只有GPRS終端設(shè)備再發(fā)一個UDP包過去,移動重新給你分配一個中轉(zhuǎn)IP和端口,才能夠進行雙向通訊。 2。要求數(shù)據(jù)的丟包率較小。有些工業(yè)場合，例如電力、水務(wù)抄表，環(huán)保監(jiān)測等等，不容許傳輸過程中的數(shù)據(jù)丟失或者最大限度的要求數(shù)據(jù)的可靠性。 從這一點來看，很顯然在無線數(shù)據(jù)傳輸過程中，TCP比UDP更能保證數(shù)據(jù)的完整性、可靠性，存在更小的丟包率。在實際測試中也是如此。以廈門桑榮科技有限公司提供的GPRS終端設(shè)備為例：TCP的在千分之9，UDP的在千分之17左右。 3。要求降低費用。目前有很大部分GPRS設(shè)備的應(yīng)用都是取代前期無線數(shù)傳電臺，除了使用范圍外，其考慮的主要問題就是費用。能降低費用當然都是大家最愿意接受的。和費用直接相關(guān)的就是流量了，流量低，費用就低了。 雖然TCP本身的包頭要比UDP多，但是UDP在實際應(yīng)用中往往需要維護雙向通道，就必須要通過大量的心跳包數(shù)據(jù)來維護端口資源�？偟谋容^起來，UDP的實際流量要比TCP還要大。很多使用者在初期的時候并不了解UDP需要大量心跳包來維持端口資源這個問題，往往都認為UDP要比TCP更節(jié)省流量，實際上這里存在著一個誤區(qū)。 4。在某些特定的應(yīng)用場合，例如一些銀行的時時交互系統(tǒng)，對響應(yīng)速度要求很高，此時數(shù)據(jù)傳輸頻率較快，不需要大量心跳包維持UDP端口資源，采用UDP就比較有利了。 5。在目前的1：N的傳輸模式中，既有多個GPRS終端設(shè)備往一個服務(wù)器中心傳輸數(shù)據(jù)，此時采用UDP會比TCP要好的多，因為UDP耗用更少的系統(tǒng)資源。但是在實際應(yīng)用中卻發(fā)現(xiàn)，很多用戶還是采用TCP的傳輸方式，建立二級中心1：A（1：N），即每一個分中心對應(yīng)N/A臺設(shè)備，獨立處理數(shù)據(jù)，再統(tǒng)一將數(shù)據(jù)傳送到主中心。這樣既能保證了傳輸過程中采用了TCP的傳輸協(xié)議，又能很好處理了中心服務(wù)器的多鏈路的系統(tǒng)耗用的問題。 總的來說，TCP/IP協(xié)議更能滿足目前各行業(yè)對遠程數(shù)據(jù)傳輸?shù)囊�，它提供更穩(wěn)定更便利的傳輸通道，很好的滿足了遠程數(shù)據(jù)傳輸?shù)囊蟆Ｉs公司所有ＤＴＵ產(chǎn)品都支持ＴＣＰ和ＵＤＰ協(xié)議，客戶可以自行選擇． |
| 2樓： | >>參與討論 |
| 作者： chunyang 于 2005/3/26 16:20:00 發(fā)布：
好！ 只要你寫，俺老漢就送你“褲頭”！下一條已準備好了…… |
|
| 3樓： | >>參與討論 |
| 作者： masm311 于 2005/3/26 20:11:00 發(fā)布：
好東西，定先 |
|
| 4樓： | >>參與討論 |
| 作者： lxj7871 于 2005/3/27 3:21:00 發(fā)布：
謝謝版主贈送褲頭，以后努力賺褲頭． |
|
| 5樓： | >>參與討論 |
| 作者： 12864 于 2005/3/27 13:47:00 發(fā)布：
謝樓主！看來GPRS穩(wěn)定性不高啊 TCP丟失率接近1％，UDP丟失率接近2％，還不如短信呢。 如果接收方給出確認信息，發(fā)送方發(fā)送之后限時判斷是否重發(fā)，結(jié)果流量會更大。 最好的辦法是發(fā)送大的壓縮包，可是這樣對于發(fā)送方處理器的要求就多一些，而且因為打包實時性也受損。 怎樣降低丟失率呢？特別是在快速移動的終端上。 |
|
| 6樓： | >>參與討論 |
| 作者： lxj7871 于 2005/3/27 22:40:00 發(fā)布：
完整性沒問題 使用TCP協(xié)議進行數(shù)據(jù)通信時，必須要經(jīng)過三個階段，第一個階段是連接建立階段，第二個階段是數(shù)據(jù)收發(fā)階段，第三個階段是連接釋放階段： 1）.連接建立階段： 連接的建立又有主動連接和被動連接之分，一般來說客戶機都是主動發(fā)起連接的，而服務(wù)器是被動接受連接的。所謂的主動連接是指本方主動向遠端發(fā)起連接請求， 而被動連接指的是本方偵聽一個端口，等待遠端及其主動向自己發(fā)起一個連接請求并且進行回應(yīng)并且最終握手建鏈成功。在連接成功，切換到數(shù)據(jù)態(tài)后，我們可以通過OPEN命令幀控制SARO-1000P 進行主動連接。當然，連接時要指定對方的IP地址和端口號。至于被動連接，SARO-1000P也可以支持，目前的程序只支持偵聽一個端口。對方主動連接（SARO-1000P被動連接）成功后將建立一條新的通信連接，SARO-1000P將把這個被動連接成功的事件通知給上位機。 2）.數(shù)據(jù)收發(fā)階段： 當一條連接建立之后，我們就可以在這條連接上進行數(shù)據(jù)收發(fā)了。我們可以使用SEND命令幀控制SARO-1000P進行數(shù)據(jù)發(fā)送。當然，發(fā)送時要指定連接號（通過本地端口、目的地址和端口唯一確定）。對于對方發(fā)送過來的數(shù)據(jù)，SARO-1000P首先將其存儲在自身的數(shù)據(jù)緩沖區(qū)中，然后將數(shù)據(jù)已到達此事件通知給上位機，上位機讀取到數(shù)據(jù)已到達事件后，應(yīng)當及時使用RECV命令幀控制SARO-1000P將相應(yīng)連接上的所有數(shù)據(jù)通過串口讀出，當數(shù)據(jù)讀出后，這些數(shù)據(jù)原先占用的數(shù)據(jù)緩沖區(qū)空間將會被釋放。注意，由于SARO-1000P的數(shù)據(jù)緩沖區(qū)有限（總量僅有25K Bytes）,所以，對于對方發(fā)來的數(shù)據(jù)，上位機一定要及時讀出，否則數(shù)據(jù)越積越多，可能會導(dǎo)致數(shù)據(jù)緩沖區(qū)溢出，丟失數(shù)據(jù)。 3）.掛斷連接階段： 當一條連接上的所有數(shù)據(jù)都已經(jīng)收發(fā)完成了，不再需要這條連接時，就可以把連接給掛斷了。和連接建立階段相類似，掛斷也分為主動掛斷和被動掛斷。我們可以使用RSET命令幀控制SARO-1000P進行連接的主動掛斷。如果連接被對方主動掛斷，SARO-1000P將會把這個事件通知給上位機進行處理。 ＴＣＰ連接本身是支持１００％傳輸完整性的．只要服務(wù)器端能夠按照上面所說的方式與終端進行三次握手，傳輸完整性是完全可以得到保障的． |
|
| 7樓： | >>參與討論 |
| 作者： 12864 于 2005/3/28 2:59:00 發(fā)布：
完整性就是指：只丟包，不錯數(shù)，不丟數(shù)？ 能收到的每一包都是完整并正確的，要么就干脆收不到。 |
|
| 8樓： | >>參與討論 |
| 作者： chunyang 于 2005/3/28 12:08:00 發(fā)布：
干脆收不到應(yīng)是結(jié)構(gòu)上的問題 若連接請求過程處理不當或網(wǎng)路本身的連接出現(xiàn)嚴重問題如掉線等才會有此情況出現(xiàn)。 |
|
| 9樓： | >>參與討論 |
| 作者： 12864 于 2005/3/28 21:47:00 發(fā)布：
chunyang:但是丟包現(xiàn)象的確存在啊 除了定時收不到應(yīng)答，超時重發(fā)，沒有其他辦法呀。你能保證在網(wǎng)絡(luò)正常時，100％不丟失數(shù)據(jù)包嗎？ |
|
| 10樓： | >>參與討論 |
| 作者： lxj7871 于 2005/3/29 13:34:00 發(fā)布：
當然可以確保 說過只要中心軟件和監(jiān)測點三次握手程序編得沒問題,TCP是有重傳功能的,丟了包我知道,我再傳.你說的是過程,我們給客戶的是結(jié)果.客戶要的100%的收到了就可以了. 金融行業(yè)每個數(shù)據(jù)都很重要,一個都不能少,現(xiàn)在用GPRS/CDMA就很多. |
|
| 11樓： | >>參與討論 |
| 作者： masm311 于 2005/3/29 18:46:00 發(fā)布：
0 * - 本貼最后修改時間：2005-3-31 7:43:34 修改者：masm311 |
|
| 12樓： | >>參與討論 |
| 作者： 12864 于 2005/3/29 23:06:00 發(fā)布：
受教了，下次試試TCP，以前一直覺得附加流量大不敢用 |
|
| 13樓： | >>參與討論 |
| 作者： guorock 于 2005/12/25 9:27:00 發(fā)布：
恩，文章不錯！ |
|
|
|
| 免費注冊為維庫電子開發(fā)網(wǎng)會員，參與電子工程師社區(qū)討論，點此進入 |
Copyright © 1998-2006 m.58mhw.cn 浙ICP證030469號 |