1. UDP

1.1 UDP結(jié)構(gòu)

• 2字節(jié)的長(zhǎng)度表示整個(gè)數(shù)據(jù)報(bào)的最大長(zhǎng)度（UDP首部＋UDP數(shù)據(jù)）。
• 校驗(yàn)和用來驗(yàn)證數(shù)據(jù)是否出錯(cuò)，出錯(cuò)就摒棄。
• 首部8個(gè)字節(jié)。
• 源/目的端口號(hào)：表示數(shù)據(jù)是從哪個(gè)進(jìn)程來，到哪個(gè)進(jìn)程去；
• 校驗(yàn)和：發(fā)送端填充，CRC校驗(yàn)。接收端校驗(yàn)不通過，則認(rèn)為數(shù)據(jù)有問題。

1.2 UDP特點(diǎn)

1. 無連接

知道對(duì)方的端口和IP就可以直接傳輸不用建立連接。
這使UDP更加的輕量級(jí)，適用于一些實(shí)時(shí)性高的應(yīng)用。

2. 不可靠

UDP沒有任何安全機(jī)制，發(fā)送端發(fā)送數(shù)據(jù)報(bào)以后，如果因?yàn)榫W(wǎng)絡(luò)錯(cuò)誤發(fā)生錯(cuò)誤，UDP協(xié)議層也不會(huì)給應(yīng)用層返回任何錯(cuò)誤信息。

3. 面向數(shù)據(jù)報(bào)

應(yīng)用層給UDP多長(zhǎng)的報(bào)文，就會(huì)發(fā)送多長(zhǎng)的報(bào)文，并不會(huì)拆分合并。

4. 緩沖區(qū)

UDP并沒有真正的發(fā)送緩沖區(qū)，具有接受緩沖區(qū)。
UDP的scoket既能讀，又能寫，所以是全雙工。

5. 大小受限

UDP協(xié)議首部有個(gè)16位的最大長(zhǎng)度，所以一次最多傳輸64Kb，包括UDP首部。

6. 無序性

UDP不保證數(shù)據(jù)包的傳輸順序，這對(duì)某些應(yīng)用來說可能是一個(gè)缺點(diǎn)，但對(duì)其他應(yīng)用來說，這樣的特性可以提高性能。

2. TCP

2.1 TCP結(jié)構(gòu)

• 6位標(biāo)志位:
  URG：緊急指針是否有效
  ACK：確認(rèn)號(hào)是否有效
  PSH：提示接收端應(yīng)用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走
  RST：對(duì)方要求重新建立連接；我們把攜帶RST標(biāo)識(shí)的稱為復(fù)位報(bào)文段
  SYN：請(qǐng)求建立連接；我們把攜帶SYN標(biāo)識(shí)的稱為同步報(bào)文段
  FIN：通知對(duì)方，本端要關(guān)閉了，我們稱攜帶FIN標(biāo)識(shí)的為結(jié)束報(bào)文段。

2.2 TCP特點(diǎn)

1. 有連接

通信雙方通信前需要建立連接，知道對(duì)方的端口號(hào)和IP。

2. 可靠性

TCP提供可靠的數(shù)據(jù)傳輸，確保數(shù)據(jù)的完整性和順序。主要通過確認(rèn)應(yīng)答。

3. 面向字節(jié)流

TCP是面向字節(jié)流的協(xié)議，而不是面向消息的。這意味著應(yīng)用程序需要負(fù)責(zé)將數(shù)據(jù)分割為適當(dāng)?shù)南⒒驍?shù)據(jù)塊，以便進(jìn)行傳輸。

4. 擁塞控制

TCP擁有擁塞控制機(jī)制，它可以調(diào)整發(fā)送速率以避免網(wǎng)絡(luò)擁塞。通過監(jiān)控網(wǎng)絡(luò)的延遲和丟包情況，TCP可以自動(dòng)適應(yīng)不同的網(wǎng)絡(luò)條件。

5. 頭部開銷

TCP頭部較大，包含序號(hào)、確認(rèn)號(hào)、窗口大小等字段，因此在某些情況下可能引入較高的開銷。

2.3 TCP原理

TCP相對(duì)UDP安全性提高，但是效率卻降低了，所以TCP中引入了很多在保證安全的情況下提高傳輸效率。

1. 確認(rèn)應(yīng)答（安全機(jī)制）

TCP將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)行了編號(hào)，即為序列號(hào)。每一個(gè)ACK都帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，意思是告訴發(fā)送者，我已經(jīng)收到了哪些數(shù)據(jù)；下一次你從哪里開始發(fā)。
確認(rèn)應(yīng)答就是對(duì)方收到消息后，給出回應(yīng)，讓對(duì)方知道你收到了。
每當(dāng)一方收到數(shù)據(jù)包時(shí)，它會(huì)發(fā)送一個(gè)確認(rèn)應(yīng)答，通常包含了已經(jīng)成功接收的數(shù)據(jù)的序號(hào)。這確保了數(shù)據(jù)的可靠傳輸，因?yàn)榘l(fā)送方會(huì)等待確認(rèn)應(yīng)答，以確定數(shù)據(jù)已經(jīng)到達(dá)并且沒有丟失。

2. 超時(shí)重傳（安全機(jī)制）

當(dāng)對(duì)方的回應(yīng)你遲遲沒有收到，當(dāng)?shù)竭_(dá)一定時(shí)間，可以重新發(fā)送一次。
當(dāng)一方的數(shù)據(jù)包或者對(duì)方的確認(rèn)應(yīng)答在傳輸途中丟失，一定時(shí)間后會(huì)重新發(fā)送相同的數(shù)據(jù)包，直到收到確認(rèn)應(yīng)答。累計(jì)到一定的重傳次數(shù)，TCP認(rèn)為網(wǎng)絡(luò)或者對(duì)端主機(jī)出現(xiàn)異常，強(qiáng)制關(guān)閉連接。

3. 連接管理（安全機(jī)制）

正常情況下TCP要經(jīng)過三次握手建立連接，四次揮手?jǐn)嚅_連接。

三次握手

第一次握手：客戶端向服務(wù)器發(fā)送一個(gè)特殊的TCP報(bào)文，這個(gè)報(bào)文中的SYN標(biāo)志位被置為1，這個(gè)報(bào)文表示客戶端希望建立連接。
第二次握手：服務(wù)器收到客戶端的SYN報(bào)文后，需要確認(rèn)建立連接。服務(wù)器會(huì)響應(yīng)一個(gè)包含SYN和ACK標(biāo)志位的報(bào)文。這個(gè)報(bào)文表示服務(wù)器同意建立連接。
第三次握手：客戶端收到服務(wù)器的確認(rèn)后，也要發(fā)送一個(gè)確認(rèn)報(bào)文ACK。這個(gè)報(bào)文告訴服務(wù)器它已經(jīng)收到了服務(wù)器的確認(rèn)，連接建立完成。

四次揮手

第一次揮手：關(guān)閉方（通常是客戶端）向另一方發(fā)送一個(gè)TCP報(bào)文，帶有FIN標(biāo)志位，表示它已經(jīng)沒有數(shù)據(jù)要發(fā)送，但仍愿意接收數(shù)據(jù)。這個(gè)報(bào)文開始了連接的關(guān)閉過程。
第二次揮手：接收方收到第一次揮手的報(bào)文后，它會(huì)發(fā)送一個(gè)ACK確認(rèn)報(bào)文作為響應(yīng)。表示接收方已經(jīng)收到并確認(rèn)了關(guān)閉方的FIN報(bào)文。
第三次揮手：接收方（通常是服務(wù)器）在確定沒有更多數(shù)據(jù)要發(fā)送后，也會(huì)發(fā)送一個(gè)FIN標(biāo)志的報(bào)文，通知對(duì)方它準(zhǔn)備關(guān)閉連接。
第四次揮手：關(guān)閉方收到第三次揮手的報(bào)文后，也要發(fā)送一個(gè)ACK確認(rèn)報(bào)文作為響應(yīng)，以確認(rèn)接收方的關(guān)閉請(qǐng)求。

4. 滑動(dòng)窗口（效率機(jī)制）

上述傳輸數(shù)據(jù)時(shí)，每次發(fā)送一個(gè)數(shù)據(jù)，都需要等待ACK才能發(fā)送下一段數(shù)據(jù)，這樣的效率并不高，性能較差，所以引入了滑動(dòng)窗口。
如圖：
我們可以一次發(fā)送多條數(shù)據(jù)，這樣就能才等待時(shí)間重疊在一起，提高性能。
窗口大小指的是無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。上圖的窗口大小就是4000個(gè)字節(jié)（四個(gè)段）。
發(fā)送前四個(gè)段的時(shí)候，不需要等待任何ACK，直接發(fā)送；
收到第一個(gè)ACK后，滑動(dòng)窗口向后移動(dòng)，繼續(xù)發(fā)送第五個(gè)段的數(shù)據(jù)；依次類推；
操作系統(tǒng)內(nèi)核為了維護(hù)這個(gè)滑動(dòng)窗口，需要開辟發(fā)送緩沖區(qū)來記錄當(dāng)前還有哪些數(shù)據(jù)沒有應(yīng)答；只有確認(rèn)應(yīng)答過的數(shù)據(jù)，才能從緩沖區(qū)刪掉；
窗口越大，則網(wǎng)絡(luò)的吞吐率就越高；
丟包處理

1. 丟了ACK
   這種情況下，如果前面的部分ACK丟失，只要接受到后面的ACK，依然可以確認(rèn)應(yīng)答。
   
2. 丟了數(shù)據(jù)包
   當(dāng)某一段報(bào)文段丟失之后，發(fā)送端會(huì)一直收到 1001 這樣的ACK，就像是在提醒發(fā)送端 “我想要的是 1001” 一樣；
   如果發(fā)送端主機(jī)連續(xù)三次收到了同樣一個(gè) “1001” 這樣的應(yīng)答，就會(huì)將對(duì)應(yīng)的數(shù)據(jù) 1001 - 2000 重新發(fā)送；
   這個(gè)時(shí)候接收端收到了 1001 之后，再次返回的ACK就是7001了（因?yàn)?001 - 7000）接收端其實(shí)之前就已經(jīng)收到了，被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)中；
   這種機(jī)制被稱為 “高速重發(fā)控制”（也叫 “快重傳”）。
   

5. 流量控制（安全機(jī)制）

接收端處理數(shù)據(jù)的速度是有限的。如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被打滿，這個(gè)時(shí)候如果發(fā)送端繼續(xù)發(fā)送，就會(huì)造成丟包，繼而引起丟包重傳等等一系列連鎖反應(yīng)。因此TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度。這個(gè)機(jī)制就叫做流量控制。
TCP通過流量控制機(jī)制來管理數(shù)據(jù)傳輸，以確保發(fā)送方不會(huì)發(fā)送過多的數(shù)據(jù)，從而導(dǎo)致接收方無法處理或網(wǎng)絡(luò)擁塞。流量控制的主要目標(biāo)是防止數(shù)據(jù)包的丟失和網(wǎng)絡(luò)擁塞。以下是TCP流量控制的關(guān)鍵概念和工作原理：

1. 窗口機(jī)制：TCP使用窗口機(jī)制來進(jìn)行流量控制。接收方會(huì)告訴發(fā)送方它可以接收多少數(shù)據(jù)，這個(gè)信息被稱為"接收窗口大小"（Receiver
   Window Size）。

2. 滑動(dòng)窗口：發(fā)送方維護(hù)一個(gè)發(fā)送窗口，它表示當(dāng)前可以發(fā)送的數(shù)據(jù)量。這個(gè)窗口的大小受到接收方的接收窗口大小和網(wǎng)絡(luò)條件的影響。

3. 通告窗口大?。航邮辗綍?huì)在TCP報(bào)文中通告當(dāng)前的接收窗口大小，發(fā)送給發(fā)送方。這告訴發(fā)送方可以發(fā)送多少數(shù)據(jù)，以避免過載接收方。

4. 動(dòng)態(tài)調(diào)整窗口大?。航邮辗娇梢愿鶕?jù)自身處理能力和可用內(nèi)存動(dòng)態(tài)調(diào)整接收窗口大小。如果接收方無法及時(shí)處理數(shù)據(jù)，它可以減小窗口大小，通知發(fā)送方降低發(fā)送速率。

5. 流量控制的目的：流量控制的主要目的是防止發(fā)送方發(fā)送過多數(shù)據(jù)，從而導(dǎo)致接收方緩沖區(qū)溢出，數(shù)據(jù)丟失，或網(wǎng)絡(luò)擁塞。通過維護(hù)適當(dāng)?shù)慕邮沾翱诖笮?，TCP可以確保發(fā)送和接收之間的數(shù)據(jù)傳輸協(xié)調(diào)順暢。

6. 自適應(yīng)機(jī)制：TCP的流量控制是自適應(yīng)的，它可以根據(jù)網(wǎng)絡(luò)狀況進(jìn)行調(diào)整。如果網(wǎng)絡(luò)擁塞，接收方可以減小窗口大小，發(fā)送方會(huì)相應(yīng)降低發(fā)送速率，從而減輕網(wǎng)絡(luò)負(fù)擔(dān)。

6. 擁塞控制（安全機(jī)制）

雖然TCP有了滑動(dòng)窗口這個(gè)大殺器，能夠高效可靠的發(fā)送大量的數(shù)據(jù)。但是如果在剛開始階段就發(fā)送大量的數(shù)據(jù)，仍然可能引發(fā)問題。
因?yàn)榫W(wǎng)絡(luò)上有很多的計(jì)算機(jī)，可能當(dāng)前的網(wǎng)絡(luò)狀態(tài)就已經(jīng)比較擁堵。在不清楚當(dāng)前網(wǎng)絡(luò)狀態(tài)下，貿(mào)然發(fā)送大量的數(shù)據(jù)，是很有可能引起雪上加霜的。
TCP引入慢啟動(dòng)機(jī)制，先發(fā)少量的數(shù)據(jù)，探探路，摸清當(dāng)前的網(wǎng)絡(luò)擁堵狀態(tài)，再?zèng)Q定按照多大的速度傳輸數(shù)據(jù)；

7. 延遲應(yīng)答（效率機(jī)制）

如果接收數(shù)據(jù)的主機(jī)立刻返回ACK應(yīng)答，這時(shí)候返回的窗口可能比較小。一定要記得，窗口越大，網(wǎng)絡(luò)吞吐量就越大，傳輸效率就越高。我們的目標(biāo)是在保證網(wǎng)絡(luò)不擁塞的情況下盡量提高傳輸效率；
規(guī)則：
數(shù)量限制：每隔N個(gè)包就應(yīng)答一次；
時(shí)間限制：超過最大延遲時(shí)間就應(yīng)答一次
具體的數(shù)量和超時(shí)時(shí)間，依操作系統(tǒng)不同也有差異；一般N取2，超時(shí)時(shí)間取200ms；

8. 捎帶應(yīng)答（效率機(jī)制）

在延遲應(yīng)答的基礎(chǔ)上，我們發(fā)現(xiàn)，很多情況下，客戶端服務(wù)器在應(yīng)用層也是 “一發(fā)一收” 的。意味著客戶端給服務(wù)器說了 “How are you”，服務(wù)器也會(huì)給客戶端回一個(gè) “Fine, thank you”；
那么這個(gè)時(shí)候ACK就可以搭順風(fēng)車，和服務(wù)器回應(yīng)的 “Fine，thank you” 一起回給客戶端

2.4 粘包問題

首先要明確，粘包問題中的 “包” ，是指的應(yīng)用層的數(shù)據(jù)包。
在TCP的協(xié)議頭中，沒有如同UDP一樣的 “報(bào)文長(zhǎng)度” 這樣的字段，但是有一個(gè)序號(hào)這樣的字段。
站在傳輸層的角度，TCP是一個(gè)一個(gè)報(bào)文過來的。按照序號(hào)排好序放在緩沖區(qū)中。
站在應(yīng)用層的角度，看到的只是一串連續(xù)的字節(jié)數(shù)據(jù)。
那么應(yīng)用程序看到了這么一連串的字節(jié)數(shù)據(jù)，就不知道從哪個(gè)部分開始到哪個(gè)部分，是一個(gè)完整的應(yīng)用層數(shù)據(jù)包。
那么如何避免粘包問題呢？歸根結(jié)底就是一句話，明確兩個(gè)包之間的邊界。

1. 對(duì)于定長(zhǎng)的包，保證每次都按固定大小讀取即可；例如上面的Request結(jié)構(gòu)，是固定大小的，那么就從緩沖區(qū)從頭開始按sizeof（Request）依次讀取即可；
2. 對(duì)于變長(zhǎng)的包，可以在包頭的位置，約定一個(gè)包總長(zhǎng)度的字段，從而就知道了包的結(jié)束位置；
3. 對(duì)于變長(zhǎng)的包，還可以在包和包之間使用明確的分隔符（應(yīng)用層協(xié)議，是程序猿自己來定的，只要保證分隔符不和正文沖突即可）；

對(duì)于UDP協(xié)議來說，是否也存在 “粘包問題” 呢？
對(duì)于UDP，如果還沒有上層交付數(shù)據(jù)，UDP的報(bào)文長(zhǎng)度仍然在。同時(shí)，UDP是一個(gè)一個(gè)把數(shù)據(jù)交付給應(yīng)用層。就有很明確的數(shù)據(jù)邊界。
站在應(yīng)用層的站在應(yīng)用層的角度，使用UDP的時(shí)候，要么收到完整的UDP報(bào)文，要么不收。不會(huì)出現(xiàn)"半個(gè)"的情況。文章來源地址http://www.zghlxwxcb.cn/news/detail-724935.html

到了這里，關(guān)于【傳輸層協(xié)議】UDP/TCP結(jié)構(gòu)特點(diǎn)與原理（詳解）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！