UDP協(xié)議

UDP（User Datagram Protocol）：用戶報(bào)文協(xié)議
沒有任何特點(diǎn)
和TCP對比：不可靠、無連接、面向報(bào)文
1. 網(wǎng)絡(luò)的基本情況就是不可靠的

沒有誰能保證數(shù)據(jù)一定是可以發(fā)送到對方的，可能丟失（丟包)

即使數(shù)據(jù)發(fā)送給對方了，也不能保證數(shù)據(jù)就是無差錯(cuò)的（不考慮有人故意修改數(shù)據(jù)的情況)

依次發(fā)送多個(gè)數(shù)據(jù)后，不能保證接收方按照發(fā)送順序接收到數(shù)據(jù)（亂序)，每次數(shù)據(jù)的發(fā)送，都是一次獨(dú)立的尋找路徑的過程

2. UDP作為一種最簡單的傳輸層協(xié)議，基本上沒有做什么的操作來幫助用戶處理復(fù)雜的網(wǎng)絡(luò)環(huán)境，所以UDP保留下來這種不可靠的特性。

3. UDP報(bào)文的頭信息（定長的（8字節(jié)））

4. 校驗(yàn)和（checksum）的作用和工作機(jī)制

判斷收到的報(bào)文（數(shù)據(jù)）是否出現(xiàn)差錯(cuò)的

利用hash函數(shù)的原理︰通過設(shè)計(jì)一種hash函數(shù)，達(dá)到?jīng)_突率很低的一種情況
發(fā)送端:checksum(payload)=>校驗(yàn)和1 （把校驗(yàn)和1填寫到UDP的header 中）
接收端:checksum(payload)=>校驗(yàn)和2
比較校驗(yàn)和2和header 中的校驗(yàn)和1：如果不等，payload在傳輸過程中一定出現(xiàn)差錯(cuò)了；如果相等，大概率payload沒有出現(xiàn)出錯(cuò)

針對校驗(yàn)和可以對上的情況，正常接收數(shù)據(jù)。
針對校驗(yàn)和對不上的情況，直接丟棄包: UDP不是特別可靠

5.UDP協(xié)議棧的作用

計(jì)算校驗(yàn)和

填寫正確的header信息

把 header + payload一起交給網(wǎng)絡(luò)層 （重點(diǎn):UDP沒有發(fā)送緩沖區(qū)）

網(wǎng)絡(luò)層發(fā)送數(shù)據(jù)到網(wǎng)卡

send方法返回
重點(diǎn):我們在應(yīng)用層調(diào)用send方法時(shí)send方法返回了，就意味著數(shù)據(jù)已經(jīng)到達(dá)網(wǎng)絡(luò)中

接收到數(shù)據(jù)之后

計(jì)算校驗(yàn)和

解包

通知指定的進(jìn)程，數(shù)據(jù)已經(jīng)到達(dá)…這段期間，進(jìn)程可能還暫時(shí)來不及過來取數(shù)據(jù)。所以UDP協(xié)議棧需要找個(gè)地方把數(shù)據(jù)暫存一會兒。UDP協(xié)議棧中有接收緩沖區(qū)。

6. UDP有接收緩沖區(qū)，沒有發(fā)送緩沖區(qū)
用戶發(fā)送多少數(shù)據(jù)，UDP也會發(fā)送多少數(shù)據(jù)，所以UDP是面向報(bào)文的
UDP發(fā)送數(shù)據(jù)無需任何準(zhǔn)備工作，隨時(shí)隨地可以發(fā)送:寄信vs打電話，所以UDP是無連接的

7. 面向數(shù)據(jù)報(bào)文導(dǎo)致的一個(gè)后果:
由于底層(物理層＋網(wǎng)絡(luò)層)）都對一次發(fā)送的數(shù)據(jù)有大小限制。如果強(qiáng)行發(fā)送大于限制的數(shù)據(jù)，就會出現(xiàn)數(shù)據(jù)被截?cái)唷?br /> 全雙工:同一個(gè)信道是雙向的。

8. UDP協(xié)議的最適用場景
對實(shí)時(shí)性要求較高，對可靠性要求較低的場景
實(shí)時(shí)聊天（語音、視頻聊天)
UDP支持廣播。如果有廣播需求，也可以考慮用UDP。

TCP協(xié)議

TCP（Transmission Control Protocol）：傳輸控制協(xié)議

目標(biāo):

以進(jìn)程為單位傳遞數(shù)據(jù)

追求可靠性

什么是可靠性?

TCP只能保證盡自己最大的可能，把數(shù)據(jù)有序地發(fā)送給對方。但不能保證一定能發(fā)送給對方。

盡可能去發(fā)送給對方

即使發(fā)不過去，也有反饋

保證對方接收是有序的

保證對方不會收到差錯(cuò)數(shù)據(jù)

TC會設(shè)計(jì)一些機(jī)制，來盡可能的優(yōu)化網(wǎng)絡(luò)，提高對方收到的可能性

TCP使用什么樣的機(jī)制，來保證可靠性——確認(rèn)應(yīng)答機(jī)制

TCP發(fā)送的數(shù)據(jù)，一般被稱為segment(數(shù)據(jù)段)

應(yīng)答: acknowledge

如果發(fā)送方同時(shí)發(fā)送了多條segment，應(yīng)答進(jìn)行了多次應(yīng)答。發(fā)送方如何得知，接收方收到的是哪一次的segment?
編號機(jī)制:發(fā)送方為發(fā)送的數(shù)據(jù)做編號，應(yīng)答的時(shí)候帶上對應(yīng)編號即可。

如果接收方?jīng)]有收到數(shù)據(jù)，則不會應(yīng)答;或者接收方應(yīng)答了，但應(yīng)答丟包了
總之:發(fā)送方?jīng)]有收到對應(yīng)的應(yīng)答。則認(rèn)為對方?jīng)]有收到數(shù)據(jù)——超時(shí)重傳機(jī)制

TCP協(xié)議的header格式

和UDP不同，TCP的header 不是定長的。

哪個(gè)或者哪些字段，可以保證接受方的TCP協(xié)議棧進(jìn)行解包工作?
4位header長度

根據(jù)源port+目標(biāo)port做分用

到目前為止，TCP發(fā)送的 segment有兩種:（1.攜帶數(shù)據(jù)segment，⒉.應(yīng)答segment），TCP協(xié)議并沒有把兩種作用的segment進(jìn)行不同格式的設(shè)計(jì)，而是進(jìn)行統(tǒng)一的設(shè)置了!
那具體怎么區(qū)分本次segment是否有應(yīng)答的作用呢?
ack ==1時(shí)segment有應(yīng)答功能；ack == 0時(shí)segment沒有應(yīng)答功能

segment的可能情況:（1）光攜帶數(shù)據(jù)；（2）攜帶數(shù)據(jù)＋應(yīng)答（網(wǎng)絡(luò)中合并數(shù)據(jù)的發(fā)送，可以提高網(wǎng)絡(luò)發(fā)送的效率）

32位序號：SN（Sequence Number）
32位確認(rèn)序號：ASN（Acknowledge Sequence Number）

SN和ASN書寫規(guī)則

TCP為發(fā)送的每個(gè)字節(jié)都進(jìn)行編號(只是payload，沒有header)[h ello]
h: 108(隨便選的) ，e: 109 ，l: 110， l: 111， o: 112

TCP協(xié)議棧在建立連接時(shí)，會隨機(jī)一個(gè)初識序列號(Initial Sequence Number lSN)lSN : 108

發(fā)送的時(shí)候，header 中的SN填寫的是 payload 中的第一個(gè)字節(jié)的序列號
[ hello ]
SN: 108
接收方是知道長度是5的，所以，接收方如果收到數(shù)據(jù)，則表示108 - 112已經(jīng)全部收到了

ASN應(yīng)該如何填寫？填寫的是接收方期望收到的下一個(gè)字節(jié)的數(shù)據(jù)
上述例子中，接收方要應(yīng)答的話ASN應(yīng)該填寫113。隱含的意思就是113之前的所有數(shù)據(jù)，已經(jīng)全部接收到了。

如果發(fā)送方超過一定時(shí)間都沒有收到應(yīng)答，則可能

發(fā)送方的處理邏輯是一致的。超時(shí)之后，直接重傳即可(重傳的數(shù)據(jù)不會丟失)，不需要區(qū)分情況

如果亂序到達(dá)怎么辦？

對于發(fā)送方，收到了一個(gè)應(yīng)答segASN = x時(shí)，發(fā)送方是怎么理解這個(gè)信號的?
對方已經(jīng)收到收到了x-1之前的所有數(shù)據(jù)了。
TCP協(xié)議是有接收緩沖區(qū)的，保證對方接收是有序的（接收端可以重新整理數(shù)據(jù)，接收過得數(shù)據(jù)不再接收）

如果超時(shí)之后，重傳對方仍然沒有收到，怎么辦?

繼續(xù)重傳，直到到達(dá)一個(gè)閾值（假設(shè)6次）。如果6次，我都沒有收到應(yīng)答。我就認(rèn)為不需要再努力的，放棄:

盡人事，試圖通知對方，連接異常關(guān)閉了——通過發(fā)送一個(gè)reset segment(另一種)。
rst = 1，reset segment
rst = 0，不是reset segment

通知我們的應(yīng)用層，數(shù)據(jù)發(fā)送失敗了。（Java中是通過異常的方式通知的，會收到一個(gè)IOException (SocketException)描述reset connection）

連接管理（Connection Message）

為什么需要連接（連接是什么抽象）？

作為TCP協(xié)議棧，是需要維護(hù)一個(gè)接收緩沖區(qū)的。
（1）保證整理亂序到達(dá)的數(shù)據(jù)
（2）在數(shù)據(jù)暫時(shí)未被應(yīng)用層讀走之前，臨時(shí)保存數(shù)據(jù)

作為TCP協(xié)議棧，是需要維護(hù)一個(gè)發(fā)送緩沖區(qū)的。
因?yàn)橐紤]重發(fā)的可能性，所以未應(yīng)答的數(shù)據(jù)不能直接扔掉，所以需要一個(gè)空間暫存
例：send(‘hello’)成功，代表數(shù)據(jù)被發(fā)送到OS的TCP協(xié)議棧的發(fā)送緩沖區(qū)中

作為TCP協(xié)議棧
發(fā)送方時(shí)，需要維護(hù)已經(jīng)發(fā)送的SN
接收方時(shí)，需要維護(hù)應(yīng)該應(yīng)答的SN

上述3點(diǎn)，足以說明:TCР協(xié)議棧，為了保證之前的那些機(jī)制可用，必須為每個(gè)信道，維護(hù)一組相關(guān)的數(shù)據(jù)! !

建立連接階段的必要性

由于TCP是追求可靠性的，所以TCP在正式發(fā)送數(shù)據(jù)之前，想驗(yàn)證下對象是否能收到我的數(shù)據(jù)。
類比:寄信＋電話

Connection對象，有一部分信息是無法獨(dú)立知道的，需要雙方進(jìn)行有效信息的同步

TCP的建立連接,需要雙方交換幾次信息——三 次——三 次握手
[常見面試題]為什么是三次?為什么不是兩次，為什么不是四次，為什么不是其他次?

4種segment:數(shù)據(jù)segment、應(yīng)答segment (ack= 1)、reset segment (rst= 1)、同步segment (syn= 1)

什么是連接&為什么TCP需要有連接，UDP就沒有連接。
邏輯上對信道的抽象。物理上各自內(nèi)存中維護(hù)的信道相關(guān)的一組數(shù)據(jù)。
因?yàn)門CP為了追求可靠性引入一系列機(jī)制（確認(rèn)應(yīng)答機(jī)制，超時(shí)重傳機(jī)制），為了這些機(jī)制能正常的工作，使得TCP必須引入連接的概念。

為什么要有建立連接階段的必要性

互相確認(rèn)對象在線

雙方同步必要的初識信息

為什么是三次握手。

總結(jié)

以上是生活随笔為你收集整理的UDP协议和TCP协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。