一、什么是TCP和UDP  
      TCP和UDP是TCP/IP協(xié)議中的兩個傳輸層協(xié)議，它們使用IP路由功能把數(shù)據(jù)包發(fā)送到目的地，從而為應用程序及應用層協(xié)議（包括：HTTP、SMTP、SNMP、FTP和Telnet）提供網(wǎng)絡服務。TCP提供的是面向連接的、可靠的數(shù)據(jù)流傳輸，而UDP提供的是非面向連接的、不可靠的數(shù)據(jù)流傳輸。面向連接的協(xié)議在任何數(shù)據(jù)傳輸前就建立好了點到點的連接。ATM和幀中繼是面向連接的協(xié)議，但它們工作在數(shù)據(jù)鏈路層，而不是在傳輸層。普通的音頻電話也是面向連接的。  
      可靠的傳輸協(xié)議可避免數(shù)據(jù)傳輸錯誤。其實現(xiàn)方式是：在構造數(shù)據(jù)包時在其中設置校驗碼，到達目的地后再采用一定的算法重新計算校驗碼，通過比較二者，就可以找出被破壞了的數(shù)據(jù)。因為需要重發(fā)被破壞了的和已經(jīng)丟失的數(shù)據(jù)，所以在需要重發(fā)數(shù)據(jù)時協(xié)議必須能夠使目的地給出源頭的一個確認信號。有些數(shù)據(jù)包不一定按照順序到達，所以協(xié)議必須能夠探測出亂序的包，暫存起來，然后把它們按正確的次序送到應用層中去。另外，協(xié)議還必須能夠找出并丟棄重復發(fā)送的數(shù)據(jù)。一組定時器可以限制針對不同確認的等待時間，這樣就可以開始重新發(fā)送或重新建立連接。  
      數(shù)據(jù)流傳輸協(xié)議不支持位傳輸。TCP不能在一個包內(nèi)以字節(jié)或位為單位構造數(shù)據(jù)，它只負責傳輸未經(jīng)構造的8位字符串。  
      非面向連接的傳輸協(xié)議在數(shù)據(jù)傳輸之前不建立連接，而是在每個中間節(jié)點對非面向連接的包和數(shù)據(jù)包進行路由。沒有點到點的連接，非面向連接的協(xié)議，如UDP，是不可靠的連接。當一個UDP數(shù)據(jù)包在網(wǎng)絡中移動時，發(fā)送過程并不知道它是否到達了目的地，除非應用層已經(jīng)確認了它已到達的事實。非面向連接的協(xié)議也不能探測重復的和亂序的包。標準的專業(yè)術語用“不可靠”來描述UDP。在現(xiàn)代網(wǎng)絡中，UDP并不易于導致傳輸失敗，但是你也不能肯定地說它是可靠的。 

二、TCP工作流程  
      現(xiàn)在讓我們一起來看看TCP段的各個域，在IP包中它們緊跟在IP頭部信息之后。第一個16位確認了源端口，第二個16位確認了目的端口。端口的劃分使IP主機之間可用單個的IP地址實現(xiàn)不同類型的并發(fā)連接。在絕大多數(shù)現(xiàn)代操作系統(tǒng)中，采用32位IP地址和16位端口地址的組合來確認一個接口。源接口和目的接口的組合就定義了一個連接。有216或65536個可能的端口。最低的1024個端口是常用的，它們是系統(tǒng)為特定的應用層協(xié)議所保留的默認設置。如：默認狀態(tài)下，HTTP使用端口80，而POP3使用端口110。其它的應用可以使用編號更高的端口。  
      在接下來的兩個域中，序列號和確認號是TCP實現(xiàn)可靠連接的關鍵。當建立一個TCP連接時，發(fā)送方主機發(fā)出一個隨機的初始化序列號給初始化器，初始化器將其加1后送回確認域的起始器，這意味著下一個字節(jié)可以發(fā)送了。一旦數(shù)據(jù)開始流動，序列號和確認號將跟蹤已發(fā)送了那些數(shù)據(jù)，那些數(shù)據(jù)已被確認。因為每個域都是32位，總共可以有232個值，所以每個域的范圍是：0～4294967295，當超過上限時回到0。  
      4位的偏移量代表TCP頭部一共有多少個32位的信息。這個信息是必不可少的，因為有可選的頭部區(qū)域，偏移量標識了頭部的結束和數(shù)據(jù)的開始。  
      TCP的設計者保留了接下來的6位，以防萬一將來要對其進行擴展。實際上，自從RFC793（傳輸控制協(xié)議）1981年發(fā)布以來，還沒人有恰當?shù)睦碛墒褂眠@些位，在這一點上，Jon  Postel和他的同事一定是過分謹慎了。  
      隨后的6位每個都是一個標志。若UNG標志位的值為1，意味著遠在頭部緊急指針區(qū)域的數(shù)據(jù)是有效的；若ACK標志位的值為1，則意味著確認號區(qū)域中的數(shù)據(jù)是有效的。（注意：一個SYN包有一個有意義的序列號，但它的確認號是無意義的，因為它并不確認任何事件）PSH標志位使數(shù)據(jù)不必等待發(fā)送和等待接收。RST標志位將斷開一個連接。SYN（同步）標志位意味著序列號是有效的，F(xiàn)IN（結束）標志位將指出發(fā)送方已經(jīng)發(fā)完了數(shù)據(jù)。  
      16位長的窗口區(qū)域表示了“滑動窗口”的大小，也就是告訴發(fā)送方它已經(jīng)準備好接收多少個字的數(shù)據(jù)。TCP通過調(diào)整窗口的大小來控制數(shù)據(jù)的流量。一個值為0的窗口意味著通告發(fā)送方：如果沒有進一步的通知，接收器已滿，不能再接收更多的數(shù)據(jù)了。大的窗口可以確保在任何給定的時間傳輸多達65536個未經(jīng)確認的字節(jié)，但是，當重發(fā)定時器超時且又沒有得到接收確認時，窗口將減半，從而有效地降低傳輸速率。  
      16位的校驗碼區(qū)域保證了數(shù)據(jù)的完整性，保護了TCP頭部和IP頭部的各個區(qū)域。發(fā)送方計算校驗值并把它插入這個區(qū)域，接收方根據(jù)收到的包重新計算該值并比較二者，如果它們是匹配的，則認為數(shù)據(jù)是完整無損的。  
      當設置緊急標志位時，緊急指針是一個16位的偏移量，它代表必須加快的最后一個字。選擇區(qū)域可以容納0或多個32位字，可擴展TCP的性能。大多數(shù)常用的選擇區(qū)域支持大于65536字節(jié)的窗口，從而縮短了等待確認的時間，尤其是在高傳輸率時。  
      TCP的傳輸機構有多個定時器。當一個包發(fā)送時，重發(fā)定時器開始計數(shù)；當收到確認信號后，重發(fā)定時器停止計數(shù)。如果超過設定時間段還沒有收到確認信號，就重發(fā)該包。一個比較棘手的問題是如何設置該時間段。如果太長，當網(wǎng)絡傳輸錯誤增加時將導致不必要的等待時間；如果太短，就會產(chǎn)生過多的重復包從而降低網(wǎng)絡的反應時間。現(xiàn)代TCP協(xié)議根據(jù)實際情況對重發(fā)定時器進行動態(tài)設定。  
      持續(xù)定時器對于避免死鎖是必不可少的。如果網(wǎng)絡收到了一個大小為0的窗口確認并且丟失了隨后的重發(fā)數(shù)據(jù)的確認，持續(xù)定時器將超時并發(fā)送一個探針。探針的回應將指出窗口的大小（也許仍為0）。保持定時器在本端沒有任何活動后，將檢查在連接的另一端是否還有運行的進程。如果沒有任何回應，該定時器將斷開連接。  
      當斷開一個連接時，斷開連接定時器將包的最大生命期加倍。該定時器在連接斷開之前確保流量最大。 
      不管重發(fā)過程執(zhí)行得多么有效，很少的丟失包就能嚴重地降低TCP連接的流量。每個未收到的包或包的片段只會在重發(fā)定時器超時的時候才會丟失。在數(shù)據(jù)重發(fā)時，接收過程一直在遞送這些重發(fā)的數(shù)據(jù)，這樣就使總體的數(shù)據(jù)傳輸陷于停頓，直到丟失的數(shù)據(jù)被取代為止。這些重發(fā)過程導致基于TCP的連接有時處于不穩(wěn)定狀態(tài)。
 
三、TCP與UDP的選擇  
      如果比較UDP包和TCP包的結構，很明顯UDP包不具備TCP包復雜的可靠性與控制機制。與TCP協(xié)議相同，UDP的源端口數(shù)和目的端口數(shù)也都支持一臺主機上的多個應用。一個16位的UDP包包含了一個字節(jié)長的頭部和數(shù)據(jù)的長度，校驗碼域使其可以進行整體校驗。（許多應用只支持UDP，如：多媒體數(shù)據(jù)流，不產(chǎn)生任何額外的數(shù)據(jù)，即使知道有破壞的包也不進行重發(fā)。）  
      很明顯，當數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾浴⒖煽刂菩院涂煽啃詴r，TCP協(xié)議是當然的選擇。當強調(diào)傳輸性能而不是傳輸?shù)耐暾詴r，如：音頻和多媒體應用，UDP是最好的選擇。在數(shù)據(jù)傳輸時間很短，以至于此前的連接過程成為整個流量主體的情況下，UDP也是一個好的選擇，如：DNS交換。把SNMP建立在UDP上的部分原因是設計者認為當發(fā)生網(wǎng)絡阻塞時，UDP較低的開銷使其有更好的機會去傳送管理數(shù)據(jù)。TCP豐富的功能有時會導致不可預料的性能低下，但是我們相信在不遠的將來，TCP可靠的點對點連接將會用于絕大多數(shù)的網(wǎng)絡應用。

四、總結

      二者就是基于連接與無連接的區(qū)別。由此導致TCP保證數(shù)據(jù)正確性，UDP可能丟包； TCP保證數(shù)據(jù)順序，UDP不保證。TCP對系統(tǒng)資源的要求較UDP多。
TCP與UDP的區(qū)別：
  1、基于連接與無連接
  2、對系統(tǒng)資源的要求（TCP較多，UDP少）
  3、UDP程序結構較簡單
  4、流模式與數(shù)據(jù)報模式
  5、TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證
      工業(yè)場合的應用一般都有以下特點：
1、要求時時傳輸，但也有一些場合是定時傳輸，總的來說在整個傳輸過程中要求服務器中心端和GPRS終端設備能相互的、時時的傳輸數(shù)據(jù)。
TCP本身就是可靠鏈路傳輸，提供一個時時的雙向的傳輸通道，能很好的滿足工業(yè)現(xiàn)場傳輸?shù)囊蟆５荊PRS網(wǎng)絡對TCP鏈路也存在一個限制：此條鏈路在長時間（大概20分鐘左右，視具體情況而定）沒有數(shù)據(jù)流量，會自動降低此鏈路的優(yōu)先級直至強制斷開此鏈路。所以在實際使用中也會采用心跳包（一般是一個字節(jié)的數(shù)據(jù)）來維持此鏈路。
UDP由于自身特點，以及GPRS網(wǎng)絡UDP端口資源的有限性，在一段時間沒有數(shù)據(jù)流量后，端口容易改變，產(chǎn)生的影響就是從服務器中心端向GPRS終端發(fā)送數(shù)據(jù)，GPRS終端接收不到。具體的原因就是移動網(wǎng)關從中作了中轉，需要隔一定時間給主機發(fā)UDP包來維持這個IP和端口號,這樣主機就能主動給GPRS發(fā)UDP包了并且我在測試中發(fā)現(xiàn),這個間隔時間很短,我在1多分鐘發(fā)一次UDP包才能夠維持,但是再長可能移動網(wǎng)關那邊就要丟失這個端口了,此時如果主機想主動發(fā)數(shù)據(jù)給GPRS,那肯定是不行的了,只有GPRS終端設備再發(fā)一個UDP包過去,移動重新給你分配一個中轉IP和端口,才能夠進行雙向通訊。
 2、要求數(shù)據(jù)的丟包率較小。有些工業(yè)場合，例如電力、水務抄表，環(huán)保監(jiān)測等等，不容許傳輸過程中的數(shù)據(jù)丟失或者最大限度的要求數(shù)據(jù)的可靠性。
從這一點來看，很顯然在無線數(shù)據(jù)傳輸過程中，TCP比UDP更能保證數(shù)據(jù)的完整性、可靠性，存在更小的丟包率。在實際測試中也是如此。以廈門藍斯通信有限公司提供的GPRS終端設備為例：TCP的在千分之9，UDP的在千分之17左右。
3、要求降低費用。目前有很大部分GPRS設備的應用都是取代前期無線數(shù)傳電臺，除了使用范圍外，其考慮的主要問題就是費用。能降低費用當然都是大家最愿意接受的。和費用直接相關的就是流量了，流量低，費用就低了。
雖然TCP本身的包頭要比UDP多，但是UDP在實際應用中往往需要維護雙向通道，就必須要通過大量的心跳包數(shù)據(jù)來維護端口資源。總的比較起來，UDP的實際流量要比TCP還要大。很多使用者在初期的時候并不了解UDP需要大量心跳包來維持端口資源這個問題，往往都認為UDP要比TCP更節(jié)省流量，實際上這里存在著一個誤區(qū)。
4、在某些特定的應用場合，例如一些銀行的時時交互系統(tǒng)，對響應速度要求很高，此時數(shù)據(jù)傳輸頻率較快，不需要大量心跳包維持UDP端口資源，采用UDP就比較有利了。
5、在目前的1：N的傳輸模式中，既有多個GPRS終端設備往一個服務器中心傳輸數(shù)據(jù)，此時采用UDP會比TCP要好的多，因為UDP耗用更少的系統(tǒng)資源。但是在實際應用中卻發(fā)現(xiàn)，很多用戶還是采用TCP的傳輸方式，建立二級中心1：A（1：N），即每一個分中心對應N/A臺設備，獨立處理數(shù)據(jù)，再統(tǒng)一將數(shù)據(jù)傳送到主中心。這樣既能保證了傳輸過程中采用了TCP的傳輸協(xié)議，又能很好處理了中心服務器的多鏈路的系統(tǒng)耗用的問題。