1. 程式人生 > >TCP和UDP的傳輸過程以及二者之間的區別

TCP和UDP的傳輸過程以及二者之間的區別

TCP和UDP的區別
TCP
    TCP/IP協議是一個協議簇。裡面包括很多協議的。UDP只是其中的一個。之所以命名為TCP/IP協議,因為TCP,IP協議是兩個很重要的協議,就用他兩命名了。TCP和UDP協議屬於傳輸層協議,而IP協議屬於網路層協議。
    TCP(Transmission Control Protocol,傳輸控制協議)是面向連線的協議,也就是說,在收發資料前,必須和對方建立可靠的連線。一個TCP連線必須要經過三次“對話”才能建立起來,其中的過程非常複雜,只簡單的描述下這三次對話的簡單過程:
(1)第一次握手:建立連線時,客戶端傳送syn包(syn=j)到伺服器,並進入SYN_SENT狀態,等待伺服器確認;SYN:同步序列編號(Synchronize Sequence Numbers)。
(2)第二次握手:伺服器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也傳送一個SYN包(syn=k),即SYN+ACK包,此時伺服器進入SYN_RECV狀態;
(3)第三次握手:客戶端收到伺服器的SYN+ACK包,向伺服器傳送確認包ACK(ack=k+1),此包傳送完畢,客戶端和伺服器進入ESTABLISHED狀態,完成三次握手。
關於需要握手三次的理解:TCP是一種可靠的傳輸,所以建立連線的時候也是需要保證可靠的,應答機制是必不可少的。A和B要完成一次完整的資訊互動:A向B傳送了一次資料,B必須告訴A自己收到資料,並且告訴一些資訊給A,這就導致第二次資料的傳送,當然A收到B發過來的資料,也必須告訴B自己收到了資料,所以A需要再一次傳送資料給B。這三次是完成一個資訊互動最基本的過程,整個過程感覺上是一問一答,有問必答的形式。

TCP建立連線要進行3次握手,而斷開連線要進行4次:
(1)當主機A完成資料傳輸後,將控制位FIN置1,提出停止TCP連線的請求
(2)主機B收到FIN後對其作出響應,確認這一方向上的TCP連線將關閉,將ACK置1
(3)由B 端再提出反方向的關閉請求,將FIN置1
(4)主機A對主機B的請求進行確認,將ACK置1,雙方向的關閉結束。
由TCP的三次握手和四次斷開可以看出,TCP使用面向連線的通訊方式,大大提高了資料通訊的可靠性,使傳送資料端和接收端在資料正式傳輸前就有了互動,為資料正式傳輸打下了可靠的基礎。從斷開的4次握手可以看出,只是在B回覆A和B對A說話這兩個分為兩步,而不是像建立連線的時候合為一步,這樣多出來了一次握手。

為什麼需要分為四次的原因:
    這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後,它可以把ACK和SYN(ACK起應答作用,而SYN起同步作用)放在一個報文裡來發送。但關閉連線時,當收到對方的FIN報文通知時,它僅僅表示對方沒有資料傳送給你了;但未必你所有的資料都全部發送給對方了,所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後,再發送FIN報文給對方來表示你同意現在可以關閉連線了,所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。



UDP
(1) UDP是一個非連線的協議,傳輸資料之前源端和終端不建立連線,當它想傳送時就簡單地去抓取來自應用程式的資料,並儘可能快地把它扔到網路上。在傳送端,UDP傳送資料的速度僅僅是受應用程式生成資料的速度、計算機的能力和傳輸頻寬的限制;在接收端,UDP把每個訊息段放在佇列中,應用程式每次從佇列中讀一個訊息段。
(2) 由於傳輸資料不建立連線,因此也就不需要維護連線狀態,包括收發狀態等,因此一臺服務機可同時向多個客戶機傳輸相同的訊息。
(3) UDP資訊包的標題很短,只有8個位元組,相對於TCP的20個位元組資訊包的額外開銷很小。
(4) 吞吐量不受擁擠控制演算法的調節,只受應用軟體生成資料的速率、傳輸頻寬、源端和終端主機效能的限制。
(5)UDP使用盡最大努力交付,即不保證可靠交付,因此主機不需要維持複雜的連結狀態表(這裡面有許多引數)。
(6)UDP是面向報文的。傳送方的UDP對應用程式交下來的報文,在新增首部後就向下交付給IP層。既不拆分,也不合並,而是保留這些報文的邊界,因此,應用程式需要選擇合適的報文大小。
我們經常使用“ping”命令來測試兩臺主機之間TCP/IP通訊是否正常,其實“ping”命令的原理就是向對方主機發送UDP資料包,然後對方主機確認收到資料包,如果資料包是否到達的訊息及時反饋回來,那麼網路就是通的。


小結TCP與UDP的區別:
1.基於連線與無連線;
2.對系統資源的要求(TCP較多,UDP少);
3.UDP程式結構較簡單;
4.流模式與資料報模式 ;
5.TCP保證資料正確性,UDP可能丟包,TCP保證資料順序,UDP不保證。

注:關於第4點不同的解釋:
    用UDP協議傳送時,用sendto函式最大能傳送資料的長度為:65535-20-8=65507位元組,其中20位元組為IP包頭長度,8位元組為UDP包頭長度。用sendto函式傳送資料時,如果指的的資料長度大於該值,則函式會返回錯誤。
    用TCP協議傳送時,由於TCP是資料流協議,因此不存在包大小的限制(暫不考慮緩衝區的大小),這是指在用send函式時,資料長度引數不受限制。而實際上,所指定的這段資料並不一定會一次性發送出去,如果這段資料比較長,可能會被分段傳送,如果比較短,可能會等待和下一次資料一起傳送。
關於第5點不同的解釋:
多執行緒的排程問題,先發的後排程,後發的先排程,以及路由選擇的不同路徑都可能造成UDP資料到達的無序性。

單機上使用UDP傳輸是否會存在丟包?
答:也會存在,但是一般不會出現。目的ip為本機地址,或者使用環回地址的資料包都是直接在到達資料鏈路層之前,直接返回IP輸入函式,不經過網絡卡所以應該是緩衝區的問題,以及伺服器端處理速度跟不上。