趣談TCP與UDP

       大家都知道,傳輸層定義了兩種協議,一種是TCP,另一種就是UDP。提到TCP,我們第一印象就是這是一種面向連接、可靠、不會丟包的傳輸層控制協議;而提到UDP,我們就會說非可靠連接、會丟包、但是速度快,可實時傳輸數據。這些特點我想每一位學網絡的人都早已耳熟能詳,即使沒有接觸過網絡的人也早已而聞。但是具體的講,這是什麼原因造成的?TCP和UDP的區別這麼大,在如今快速發展的互聯網時代,他們又在哪些實際應用中分別發揮着自己的功能呢?

帶着這些疑問,聽小編細細道來。

“3次握手建立TCP連接,4次握手終止TCP連接”。是的,TCP和UDP最大的不同就在這裡,當客戶和服務器彼此交換數據前,必須先在雙方之間建立一個TCP連接,之後才能傳輸數據。TCP建立連接的過程是通過三次握手來完成的,首先發送端給接收端發送一個SYN請求,就相當於問對方:“我可以給你發送數據嗎?”接收端收到這個請求後,向發送端回應一個SYN/ACK應答,就是說:“當然可以,我可以向你發送數據嗎?”然後發送方收到此包後在向接收端回應ACK,發送端說:“可以啊。”完成3次握手後,TCP連接成功建立,雙方就能相互發送數據了。而終止一個TCP連接需要4次握手,這是由TCP的半關閉狀態造成的。由於發送端和接收端的連接都能獨立的被終止,所以在這個過程中雙方都需要發送一個FIN和ACK。

TCP提供超時重發、丟棄重複數據、檢驗數據、流量控制等功能,保證數據能從一端傳到另一端。提到這些TCP的特有功能,其實在TCP的報頭中完美的體現了出來。

TCP

 

圖1   TCP 報頭結構

TCP報頭的總長最小為20字節,其中來源連接端口指定了發送端的端口,目的連接端口指定了接收端的端口,它們用來標識發送方和接收方的應用層。對於每個TCP連接的一端,都有一個相關的16位的無符號端口號分配給它們,這個端口號與它所在主機的IP地址構成一個48位的套接字,一對套接字在互聯網中唯一標識一個TCP連接。序列號是用於標識每個報文段,使接收端可確認已收到指定報文段中的數據。當發送端用多個報文段發送一個報文時,即使這些報文到達目的主機的順序不一樣,序列號也可以使目的主機按順序排列它們。確認號32位,目的主機返回確認號,使源主機知道某個或幾個報文段已被接收。如果ACK控制位被設置為1,則該字段有效。確認號等於順序接收到的最後一個報文段的序號加1,這也是目的主機希望下次接收的報文段的序號值。返回確認號後,計算機就認為此確認號之前的數據都已經接收到。如此,就實現了無亂序、無丟失、和無重複的可靠數據傳輸。標題長度佔4位,指明了TCP報文頭的長度,保留是為以後預留一個字段,標誌符就是我們通常所說的標誌位,當滿足條件時,把對應的位置1。例如:當發送確認信號時,就在報文頭中把ARK位置1.窗口指明了發送端下一段能發送數據的大小,避免主機分組發送得過快而使接收端來不及完全收下,避免了網絡阻塞。TCP的校驗和佔16位,在傳輸是設置了雙校驗機制,也就是發送者在發送時需要把TCP的段頭和數據包校驗一次,同時接收者收到報文後也需要重新校驗一次。如此一來,就保證了報文的完整性和正確性。緊急指針指明報文中包含緊急信息,只有當URG位置1時,緊急指針才有效。

相對而言,UDP的數據傳輸就簡單多了,它不提供可靠性,只是把數據包往IP層上一扔,至於數據包能不能傳送到目的地,會不會丟包,傳送數據報的順序是否正確,不好意思,這就不是UDP能夠提供的了。由於UDP傳輸數據包前不需要建立連接,沒有重發機制,所以UDP速度非常快。其實這些在UDP的報頭中都體現了出來。

UDP報頭

圖2 UDP報頭結構

UDP報頭由4個部分組成,其中兩個是可選的。各16bit的來源端口和目的端口用來標記發送和接受的應用進程。因為UDP不需要應答,所以來源端口是可選的,如果來源端口不用,那麼置為零。在目的端口後面是長度固定的以字節為單位的長度域,用來指定UDP頭部和UDP數據的總長度,長度最小值為8byte。報頭剩下地16bit是用來對首部和數據部分一起做校驗和(Checksum)的,這部分是可選的,但在實際應用中一般都使用這一功能。

顯然,TCP和UDP都有一些自己的獨特的地方,這就決定了TCP與UDP在不同的領域發光發熱。這就要我們選擇時多注意點了,下面是我的幾點建議:

  • 當數據傳輸的性能必須讓位於數據傳輸的完整性、可控制性和可靠性時,TCP協議是當然的選擇,如:發送郵件;
  • 當強調傳輸性能而不是傳輸的完整性時,如:實時流多媒體(如因特網廣播)、實時多媒體播放器和遊戲、IP電話(VoIP)等等,UDP是最好的選擇。在數據傳輸時間很短,以至於此前的連接過程成為主體的情況下,UDP也是一個好的選擇,如:DNS交換。把SNMP建立在UDP上的部分原因是設計者認為當發生網絡阻塞時,UDP較低的開銷使其有更好的機會去傳送管理數據。

TCP豐富的功能有時會導致不可預料的性能低下,但是我們相信不遠的將來一定會出現功能多、性能高的TCP協議應用到我們的網絡中。

By Cillian

感謝關注!