TCP與UDP的區(qū)別

一文搞懂TCP與UDP的區(qū)別

image

摘要:計算機(jī)網(wǎng)絡(luò)基礎(chǔ)

引言

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

一瓜贾、TCP/IP網(wǎng)絡(luò)模型

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

TCP/IP 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱空凸,比如:TCP嚎花,UDP,IP呀洲,F(xiàn)TP紊选,HTTP,ICMP道逗,SMTP 等都屬于 TCP/IP 族內(nèi)的協(xié)議兵罢。

TCP/IP模型是互聯(lián)網(wǎng)的基礎(chǔ),它是一系列網(wǎng)絡(luò)協(xié)議的總稱滓窍。這些協(xié)議可以劃分為四層卖词,分別為鏈路層、網(wǎng)絡(luò)層吏夯、傳輸層和應(yīng)用層此蜈。

  • 鏈路層:負(fù)責(zé)封裝和解封裝IP報文,發(fā)送和接受ARP/RARP報文等噪生。
  • 網(wǎng)絡(luò)層:負(fù)責(zé)路由以及把分組報文發(fā)送給目標(biāo)網(wǎng)絡(luò)或主機(jī)裆赵。
  • 傳輸層:負(fù)責(zé)對報文進(jìn)行分組和重組,并以TCP或UDP協(xié)議格式封裝報文杠园。
  • 應(yīng)用層:負(fù)責(zé)向用戶提供應(yīng)用程序顾瞪,比如HTTP、FTP抛蚁、Telnet、DNS惕橙、SMTP等瞧甩。
image

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

二、UDP

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

它有以下幾個特點:

1. 面向無連接

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

具體來說就是:

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

2. 有單播申窘,多播弯蚜,廣播的功能

UDP 不止支持一對一的傳輸方式,同樣支持一對多剃法,多對多碎捺,多對一的方式,也就是說 UDP 提供了單播贷洲,多播收厨,廣播的功能。

3. UDP是面向報文的

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

4. 不可靠性

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

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

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

image

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

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

image

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

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

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

三蜈七、TCP

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

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

1. TCP連接過程

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

image

第一次握手

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

第二次握手

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

第三次握手

當(dāng)客戶端收到連接同意的應(yīng)答后俯画,還要向服務(wù)端發(fā)送一個確認(rèn)報文析桥。客戶端發(fā)完這個報文段后便進(jìn)入 ESTABLISHED 狀態(tài)艰垂,服務(wù)端收到這個應(yīng)答后也進(jìn)入 ESTABLISHED 狀態(tài)泡仗,此時連接建立成功。

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

image

2. TCP斷開鏈接

image

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

第一次握手

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

第二次握手

B 收到連接釋放請求后,會告訴應(yīng)用層要釋放 TCP 鏈接姐浮。然后會發(fā)送 ACK 包谷遂,并進(jìn)入 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 便進(jìn)入 LAST-ACK 狀態(tài)。

第四次握手

A 收到釋放請求后偷拔,向 B 發(fā)送確認(rèn)應(yīng)答蒋院,此時 A 進(jìn)入 TIME-WAIT 狀態(tài)。該狀態(tài)會持續(xù) 2MSL(最大段生存期莲绰,指報文段在網(wǎng)絡(luò)中生存的時間欺旧,超時會被拋棄) 時間,若該時間段內(nèi)沒有 B 的重發(fā)請求的話蛤签,就進(jìn)入 CLOSED 狀態(tài)辞友。當(dāng) B 收到確認(rèn)應(yīng)答后,也便進(jìn)入 CLOSED 狀態(tài)顷啼。

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

  • 面向連接

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

  • 僅支持單播傳輸

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

  • 面向字節(jié)流

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

  • 可靠傳輸

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

  • 提供擁塞控制

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

  • TCP提供全雙工通信

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

四非凌、TCP和UDP的比較

1. 對比

UDP TCP
是否連接 無連接 面向連接
是否可靠 不可靠傳輸举农,不使用流量控制和擁塞控制 可靠傳輸,使用流量控制和擁塞控制
連接對象個數(shù) 支持一對一敞嗡,一對多,多對一和多對多交互通信 只能是一對一通信
傳輸方式 面向報文 面向字節(jié)流
首部開銷 首部開銷小航背,僅8字節(jié) 首部最小20字節(jié)喉悴,最大60字節(jié)
適用場景 適用于實時應(yīng)用(IP電話、視頻會議玖媚、直播等) 適用于要求可靠傳輸?shù)膽?yīng)用箕肃,例如文件傳輸

2. 總結(jié)

  • TCP向上層提供面向連接的可靠服務(wù) ,UDP向上層提供無連接不可靠服務(wù)今魔。
  • 雖然 UDP 并沒有 TCP 傳輸來的準(zhǔn)確勺像,但是也能在很多實時性要求高的地方有所作為
  • 對數(shù)據(jù)準(zhǔn)確性要求高,速度可以相對較慢的错森,可以選用TCP
  • 特別需要記住的是吟宦,TCP是面向連接的,可靠的涩维,緩慢的殃姓,可靠交付以及保證消息順序的,而UDP是無連接的瓦阐,不可靠的蜗侈,沒有序列保證,但是一個快速傳輸?shù)膮f(xié)議睡蟋。TCP頭開銷也比UDP高得多踏幻,因為它每個數(shù)據(jù)包中藥發(fā)送更多的元數(shù)據(jù)。值得一提的是戳杀,TCP頭的大小是20個字節(jié)该面,而UDP頭大小是8個字節(jié)。如果你不想丟失任何消息豺瘤,使用TCP協(xié)議吆倦,而UDP能夠高速傳輸數(shù)據(jù),并且丟失少量的數(shù)據(jù)包是可以接受的坐求,如視頻流或在線多玩家游戲蚕泽。對于基于TCP / UDP協(xié)議,運行在Linux上的應(yīng)用,需要牢記的基本網(wǎng)絡(luò)命令须妻,如Telnet和netstat仔蝌,他們極大的幫助調(diào)試和排除任何連接問題。
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末荒吏,一起剝皮案震驚了整個濱河市敛惊,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌绰更,老刑警劉巖瞧挤,帶你破解...
    沈念sama閱讀 219,270評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異儡湾,居然都是意外死亡特恬,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,489評論 3 395
  • 文/潘曉璐 我一進(jìn)店門徐钠,熙熙樓的掌柜王于貴愁眉苦臉地迎上來癌刽,“玉大人,你說我怎么就攤上這事尝丐∠园荩” “怎么了?”我有些...
    開封第一講書人閱讀 165,630評論 0 356
  • 文/不壞的土叔 我叫張陵爹袁,是天一觀的道長远荠。 經(jīng)常有香客問我,道長呢簸,這世上最難降的妖魔是什么矮台? 我笑而不...
    開封第一講書人閱讀 58,906評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮根时,結(jié)果婚禮上瘦赫,老公的妹妹穿的比我還像新娘。我一直安慰自己蛤迎,他們只是感情好确虱,可當(dāng)我...
    茶點故事閱讀 67,928評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著替裆,像睡著了一般校辩。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上辆童,一...
    開封第一講書人閱讀 51,718評論 1 305
  • 那天宜咒,我揣著相機(jī)與錄音,去河邊找鬼把鉴。 笑死故黑,一個胖子當(dāng)著我的面吹牛儿咱,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播场晶,決...
    沈念sama閱讀 40,442評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼混埠,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了诗轻?” 一聲冷哼從身側(cè)響起钳宪,我...
    開封第一講書人閱讀 39,345評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎扳炬,沒想到半個月后吏颖,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,802評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡鞠柄,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,984評論 3 337
  • 正文 我和宋清朗相戀三年侦高,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片厌杜。...
    茶點故事閱讀 40,117評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖计螺,靈堂內(nèi)的尸體忽然破棺而出夯尽,到底是詐尸還是另有隱情,我是刑警寧澤登馒,帶...
    沈念sama閱讀 35,810評論 5 346
  • 正文 年R本政府宣布匙握,位于F島的核電站,受9級特大地震影響陈轿,放射性物質(zhì)發(fā)生泄漏圈纺。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,462評論 3 331
  • 文/蒙蒙 一麦射、第九天 我趴在偏房一處隱蔽的房頂上張望蛾娶。 院中可真熱鬧,春花似錦潜秋、人聲如沸蛔琅。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,011評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽罗售。三九已至,卻和暖如春钩述,著一層夾襖步出監(jiān)牢的瞬間寨躁,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,139評論 1 272
  • 我被黑心中介騙來泰國打工牙勘, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留职恳,地道東北人。 一個月前我還...
    沈念sama閱讀 48,377評論 3 373
  • 正文 我出身青樓,卻偏偏與公主長得像话肖,于是被迫代替她去往敵國和親北秽。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,060評論 2 355

推薦閱讀更多精彩內(nèi)容