南京軟件定制開發(fā)

南京傾心軟件歡迎您訪問本站

13605185909

新聞資訊

NEWS CENTER
欄目導航

南京軟件開發(fā)之一文搞懂TCP與UDP的區(qū)別

發(fā)布時間:Mar 14, 2020         已有 人瀏覽

引言

網(wǎng)絡協(xié)議是每個工程師都必須要掌握的知識,TCP/IP 中有兩個具有代表性的傳輸層協(xié)議,分別是 TCP 和 UDP,本文將介紹下這兩者以及它們之間的區(qū)別。

一、TCP/IP網(wǎng)絡模型

計算機與網(wǎng)絡設備要相互通信,雙方就必須基于相同的方法。比如,如何探測到通信目標、由哪一邊先發(fā)起通信、使用哪種語言進行通信、怎樣結束通信等規(guī)則都需要事先確定。不同的硬件、操作系統(tǒng)之間的通信,所有的這一切都需要一種規(guī)則。而我們就把這種規(guī)則稱為協(xié)議(protocol)。

TCP/IP 是互聯(lián)網(wǎng)相關的各類協(xié)議族的總稱,比如:TCP,UDP,IP,F(xiàn)TP,HTTP,ICMP,SMTP 等都屬于 TCP/IP 族內的協(xié)議。

TCP/IP模型是互聯(lián)網(wǎng)的基礎,它是一系列網(wǎng)絡協(xié)議的總稱。這些協(xié)議可以劃分為四層,分別為鏈路層、網(wǎng)絡層、傳輸層和應用層。

  • 鏈路層:負責封裝和解封裝IP報文,發(fā)送和接受ARP/RARP報文等。
  • 網(wǎng)絡層:負責路由以及把分組報文發(fā)送給目標網(wǎng)絡或主機。
  • 傳輸層:負責對報文進行分組和重組,并以TCP或UDP協(xié)議格式封裝報文。
  • 應用層:負責向用戶提供應用程序,比如HTTP、FTP、Telnet、DNS、SMTP等。

在網(wǎng)絡體系結構中網(wǎng)絡通信的建立必須是在通信雙方的對等層進行,不能交錯。 在整個數(shù)據(jù)傳輸過程中,數(shù)據(jù)在發(fā)送端時經(jīng)過各層時都要附加上相應層的協(xié)議頭和協(xié)議尾(僅數(shù)據(jù)鏈路層需要封裝協(xié)議尾)部分,也就是要對數(shù)據(jù)進行協(xié)議封裝,以標識對應層所用的通信協(xié)議。接下去介紹TCP/IP 中有兩個具有代表性的傳輸層協(xié)議----TCP 和 UDP。

二、UDP

UDP協(xié)議全稱是用戶數(shù)據(jù)報協(xié)議,在網(wǎng)絡中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包,是一種無連接的協(xié)議。在OSI模型中,在第四層——傳輸層,處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進行排序的缺點,也就是說,當報文發(fā)送之后,是無法得知其是否安全完整到達的。

它有以下幾個特點:

1. 面向無連接

首先 UDP 是不需要和 TCP一樣在發(fā)送數(shù)據(jù)前進行三次握手建立連接的,想發(fā)數(shù)據(jù)就可以開始發(fā)送了。并且也只是數(shù)據(jù)報文的搬運工,不會對數(shù)據(jù)報文進行任何拆分和拼接操作。

具體來說就是:

  • 在發(fā)送端,應用層將數(shù)據(jù)傳遞給傳輸層的 UDP 協(xié)議,UDP 只會給數(shù)據(jù)增加一個 UDP 頭標識下是 UDP 協(xié)議,然后就傳遞給網(wǎng)絡層了
  • 在接收端,網(wǎng)絡層將數(shù)據(jù)傳遞給傳輸層,UDP 只去除 IP 報文頭就傳遞給應用層,不會任何拼接操作

2. 有單播,多播,廣播的功能

UDP 不止支持一對一的傳輸方式,同樣支持一對多,多對多,多對一的方式,也就是說 UDP 提供了單播,多播,廣播的功能。

3. UDP是面向報文的

發(fā)送方的UDP對應用程序交下來的報文,在添加首部后就向下交付IP層。UDP對應用層交下來的報文,既不合并,也不拆分,而是保留這些報文的邊界。因此,應用程序必須選擇合適大小的報文

4. 不可靠性

首先不可靠性體現(xiàn)在無連接上,通信都不需要建立連接,想發(fā)就發(fā),這樣的情況肯定不可靠。

并且收到什么數(shù)據(jù)就傳遞什么數(shù)據(jù),并且也不會備份數(shù)據(jù),發(fā)送數(shù)據(jù)也不會關心對方是否已經(jīng)正確接收到數(shù)據(jù)了。

再者網(wǎng)絡環(huán)境時好時壞,但是 UDP 因為沒有擁塞控制,一直會以恒定的速度發(fā)送數(shù)據(jù)。即使網(wǎng)絡條件不好,也不會對發(fā)送速率進行調整。這樣實現(xiàn)的弊端就是在網(wǎng)絡條件不好的情況下可能會導致丟包,但是優(yōu)點也很明顯,在某些實時性要求高的場景(比如電話會議)就需要使用 UDP 而不是 TCP。

從上面的動態(tài)圖可以得知,UDP只會把想發(fā)的數(shù)據(jù)報文一股腦的丟給對方,并不在意數(shù)據(jù)有無安全完整到達。

5. 頭部開銷小,傳輸數(shù)據(jù)報文時是很高效的。


UDP 頭部包含了以下幾個數(shù)據(jù):

  • 兩個十六位的端口號,分別為源端口(可選字段)和目標端口
  • 整個數(shù)據(jù)報文的長度
  • 整個數(shù)據(jù)報文的檢驗和(IPv4 可選 字段),該字段用于發(fā)現(xiàn)頭部信息和數(shù)據(jù)中的錯誤

因此 UDP 的頭部開銷小,只有八字節(jié),相比 TCP 的至少二十字節(jié)要少得多,在傳輸數(shù)據(jù)報文時是很高效的
 

三、TCP

當一臺計算機想要與另一臺計算機通訊時,兩臺計算機之間的通信需要暢通且可靠,這樣才能保證正確收發(fā)數(shù)據(jù)。例如,當你想查看網(wǎng)頁或查看電子郵件時,希望完整且按順序查看網(wǎng)頁,而不丟失任何內容。當你下載文件時,希望獲得的是完整的文件,而不僅僅是文件的一部分,因為如果數(shù)據(jù)丟失或亂序,都不是你希望得到的結果,于是就用到了TCP。

TCP協(xié)議全稱是傳輸控制協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,由 IETF 的RFC 793定義。TCP 是面向連接的、可靠的流協(xié)議。流就是指不間斷的數(shù)據(jù)結構,你可以把它想象成排水管中的水流。

1. TCP連接過程

如下圖所示,可以看到建立一個TCP連接的過程為(三次握手的過程):

第一次握手

客戶端向服務端發(fā)送連接請求報文段。該報文段中包含自身的數(shù)據(jù)通訊初始序號。請求發(fā)送后,客戶端便進入 SYN-SENT 狀態(tài)。

第二次握手

服務端收到連接請求報文段后,如果同意連接,則會發(fā)送一個應答,該應答中也會包含自身的數(shù)據(jù)通訊初始序號,發(fā)送完成后便進入 SYN-RECEIVED 狀態(tài)。

第三次握手

當客戶端收到連接同意的應答后,還要向服務端發(fā)送一個確認報文。客戶端發(fā)完這個報文段后便進入 ESTABLISHED 狀態(tài),服務端收到這個應答后也進入 ESTABLISHED 狀態(tài),此時連接建立成功。

這里可能大家會有個疑惑:為什么 TCP 建立連接需要三次握手,而不是兩次?這是因為這是為了防止出現(xiàn)失效的連接請求報文段被服務端接收的情況,從而產(chǎn)生錯誤。

2. TCP斷開鏈接


TCP 是全雙工的,在斷開連接時兩端都需要發(fā)送 FIN 和 ACK。

第一次握手

若客戶端 A 認為數(shù)據(jù)發(fā)送完成,則它需要向服務端 B 發(fā)送連接釋放請求。

第二次握手

B 收到連接釋放請求后,會告訴應用層要釋放 TCP 鏈接。然后會發(fā)送 ACK 包,并進入 CLOSE_WAIT 狀態(tài),此時表明 A 到 B 的連接已經(jīng)釋放,不再接收 A 發(fā)的數(shù)據(jù)了。但是因為 TCP 連接是雙向的,所以 B 仍舊可以發(fā)送數(shù)據(jù)給 A。

第三次握手

B 如果此時還有沒發(fā)完的數(shù)據(jù)會繼續(xù)發(fā)送,完畢后會向 A 發(fā)送連接釋放請求,然后 B 便進入 LAST-ACK 狀態(tài)。

第四次握手

A 收到釋放請求后,向 B 發(fā)送確認應答,此時 A 進入 TIME-WAIT 狀態(tài)。該狀態(tài)會持續(xù) 2MSL(最大段生存期,指報文段在網(wǎng)絡中生存的時間,超時會被拋棄) 時間,若該時間段內沒有 B 的重發(fā)請求的話,就進入 CLOSED 狀態(tài)。當 B 收到確認應答后,也便進入 CLOSED 狀態(tài)。

3. TCP協(xié)議的特點

  • 面向連接

    面向連接,是指發(fā)送數(shù)據(jù)之前必須在兩端建立連接。建立連接的方法是“三次握手”,這樣能建立可靠的連接。建立連接,是為數(shù)據(jù)的可靠傳輸打下了基礎。

  • 僅支持單播傳輸

每條TCP傳輸連接只能有兩個端點,只能進行點對點的數(shù)據(jù)傳輸,不支持多播和廣播傳輸方式。

  • 面向字節(jié)流

TCP不像UDP一樣那樣一個個報文獨立地傳輸,而是在不保留報文邊界的情況下以字節(jié)流方式進行傳輸。

  • 可靠傳輸

    對于可靠傳輸,判斷丟包,誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸?shù)目煽浚徒o每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節(jié)發(fā)回一個相應的確認(ACK);如果發(fā)送端實體在合理的往返時延(RTT)內未收到確認,那么對應的數(shù)據(jù)(假設丟失了)將會被重傳。

  • 提供擁塞控制

當網(wǎng)絡出現(xiàn)擁塞的時候,TCP能夠減小向網(wǎng)絡注入數(shù)據(jù)的速率和數(shù)量,緩解擁塞

  • TCP提供全雙工通信

TCP允許通信雙方的應用程序在任何時候都能發(fā)送數(shù)據(jù),因為TCP連接的兩端都設有緩存,用來臨時存放雙向通信的數(shù)據(jù)。當然,TCP可以立即發(fā)送一個數(shù)據(jù)段,也可以緩存一段時間以便一次發(fā)送更多的數(shù)據(jù)段(最大的數(shù)據(jù)段大小取決于MSS)

四、TCP和UDP的比較

1. 對比

  UDP TCP
是否連接 無連接 面向連接
是否可靠 不可靠傳輸,不使用流量控制和擁塞控制 可靠傳輸,使用流量控制和擁塞控制
連接對象個數(shù) 支持一對一,一對多,多對一和多對多交互通信 只能是一對一通信
傳輸方式 面向報文 面向字節(jié)流
首部開銷 首部開銷小,僅8字節(jié) 首部最小20字節(jié),最大60字節(jié)
適用場景 適用于實時應用(IP電話、視頻會議、直播等) 適用于要求可靠傳輸?shù)膽茫缥募鬏?/td>

2. 總結

  • TCP向上層提供面向連接的可靠服務 ,UDP向上層提供無連接不可靠服務。
  • 雖然 UDP 并沒有 TCP 傳輸來的準確,但是也能在很多實時性要求高的地方有所作為
  • 對數(shù)據(jù)準確性要求高,速度可以相對較慢的,可以選用TCP
Copyright © 2020-2022 南京傾心軟件技術有限公司 版權所有     蘇ICP備2020070309號-1
QQ在線咨詢
13605185909
返回頂部
主站蜘蛛池模板: 久旷成熟的岳的| 我与白丝同桌的故事h文| 久久久久亚洲AV成人网人人网站| 在线免费观看欧美大片| 中文字幕一级片| 色视频综合无码一区二区三区 | 色多多视频在线| 国产真实交换多p免视频| 色综合欧美在线视频区| 亚洲AV无码成人网站在线观看 | 中文字幕在线最新在线不卡| 天堂网404在线资源| 亚洲一区二区三区免费观看| 污污视频在线观看黄| 免费能直接在线观看黄的视频免费欧洲毛片**老妇女 | 国产在线午夜卡精品影院| 舌头伸进去里面吃小豆豆| 成人国产精品一区二区视频| 制服丝袜一区在线| 成年私人影院免费视频网站 | 欧美三级不卡在线观线看高清| 亚洲视频在线观看网址| 欧美一级在线免费观看| 2021国产精品露脸在线| 亚洲AV乱码中文一区二区三区| 日韩精品中文字幕在线观看| 中文字幕一区二区三区精华液| 国产麻豆精品原创| 日韩精品卡二卡3卡四卡| 2022国产精品最新在线| 亚洲国产成人久久综合碰 | 天天干天天干天天干| 香蕉99国内自产自拍视频| 午夜亚洲乱码伦小说区69堂| 欧美日韩精品一区二区三区在线 | 尹人香蕉网在线观看视频| 亚洲1234区乱码| 国产精品福利电影| 精品国产一二三产品价格| 两个人看的www在线| 国产三级在线视频播放线|