引言

傳輸層是網(wǎng)絡通信的核心樞紐，TCP（傳輸控制協(xié)議）與 UDP（用戶數(shù)據(jù)報協(xié)議）作為該層的兩大基石，以差異化設(shè)計支撐多樣化數(shù)據(jù)傳輸需求。

TCP 秉持 “可靠性優(yōu)先”，通過面向連接、重傳機制、流量與擁塞控制，實現(xiàn)數(shù)據(jù)無丟失、無差錯、按序交付，成為文件傳輸、網(wǎng)頁瀏覽等場景的核心支撐。

UDP 堅守 “高效輕便” 原則，采用無連接模式，省去連接建立與釋放開銷，以低延遲優(yōu)勢適配實時音視頻、網(wǎng)絡游戲等對響應速度敏感的場景。

二者優(yōu)勢互補，共同構(gòu)成現(xiàn)代網(wǎng)絡通信的基礎(chǔ)，理解其特性是構(gòu)建高效網(wǎng)絡應用的關(guān)鍵。

一：UDP的協(xié)議

特點：UDP傳輸?shù)倪^程類似于寄信

• 無連接:知道對端的IP和端口號就直接進行傳輸，不需要建立連接。
• 不可靠：沒有確認機制，沒有重傳機制；如果因為網(wǎng)絡故障導致該斷無法發(fā)送對方，UDP協(xié)議層也不會給應用層返回任何錯誤信息。
• 面向數(shù)據(jù)報：不能夠靈活的控制讀寫數(shù)據(jù)的次數(shù)和數(shù)量。

===》：應用層交給UDP多長的報文，UDP原樣發(fā)送，既不會拆分，也不會合并；
例如：用UDP傳輸100個字節(jié)的數(shù)據(jù)：

如果發(fā)送端調(diào)用一次sendto，發(fā)送100個字節(jié)，那么接收端也必須調(diào)用對應的一次recvfrom，接受100個字節(jié)，而不能循環(huán)調(diào)用10次recvfrom，每次接受10個字節(jié)。

UDP協(xié)議端格式

• 16位UDP長度，表示整個數(shù)據(jù)報(UDP首部+UDP數(shù)據(jù)）的最大長度；
• 如果校驗和出錯，就會直接丟棄；

UDP使用注意事項：

我們注意到, UDP協(xié)議首部中有一個16位的最大長度. 也就是說一個UDP能傳輸?shù)臄?shù)據(jù)最大長度是64K(包含UDP首部)，然而64K在當今的互聯(lián)網(wǎng)環(huán)境下, 是一個非常小的數(shù)字。

如果我們需要傳輸?shù)臄?shù)據(jù)超過64K, 就需要在應用層手動的分包, 多次發(fā)送, 并在接收端手動拼裝;

基于UDP的應用層協(xié)議：

• NFS:網(wǎng)絡文件系統(tǒng)
• TFTP：簡單文件傳輸協(xié)議
• DHCP：動態(tài)主機配置協(xié)議
• BOOTP：啟動協(xié)議（用于無盤設(shè)備啟動）
• DNS：域名解析協(xié)議
  也包括我們自己寫UDP程序自定義的應用層協(xié)議

二：TCP協(xié)議

?? TCP全稱 傳輸控制協(xié)議（Transmission Control Protocol）,人如其名，聚焦數(shù)據(jù)傳輸?shù)娜鞒叹珳士刂?，核心在?ldquo;可靠”與“有序”。

TCP協(xié)議端格式

??源/目的端口號：表示數(shù)據(jù)是從哪個進程來，到哪個進程去；

??32位序號/32位確認號：32位序號標數(shù)據(jù)，確認號應答已收；

??4位TCP報頭長度：表示該TCP頭部有多少個32位bit(有多少4個字節(jié))；所以TCP頭部的最大長度為15*4=60；

??6位標志位：

• URG:緊急指針是否有效
• ACK：確認序號是否有效
• PSH：提示接收端應用程序盡快從TCP緩沖區(qū)把數(shù)據(jù)讀走
• RST：對方要求重新建立連接，我們把攜帶RST標識的稱為復位報文段
• SYN：請求建立連接，我們把攜帶SYN標識的稱之為同步報文段
• FIN：通知對方，本端要關(guān)閉了，我們稱攜帶FIN標識的為結(jié)束報文段

??16位窗口大?。篢CP 流量控制核心，限定接收端緩存容量
??16位校驗和：發(fā)送端填充，CRC校驗，接收端校驗不通過，則認為數(shù)據(jù)有問題，此處的校驗和不光包含TCP首部，也包含TCP數(shù)據(jù)部分；
??16位緊急指針：標識哪部分數(shù)據(jù)是緊急數(shù)據(jù)；
??40字節(jié)頭部選項：TCP 頭部可選字段，最大 40 字節(jié)擴展功能

下面介紹TCP的核心特性：

2.1：確認應答

TCP將每個字節(jié)數(shù)據(jù)都進行了編號，即為序列號。

每一個ACK都帶有一個對應的確認信號，目的是為了告訴發(fā)送者，我已經(jīng)收到了哪些數(shù)據(jù)，下次該從哪里發(fā)送;

2.2：延時重傳

場景： 主機A發(fā)送數(shù)據(jù)給主機B后，可能因為網(wǎng)絡擁堵等信息，數(shù)據(jù)無法到達主機B；

• 如果主機A在特定的時間間隔內(nèi)，沒有收到主機B發(fā)來的確認應答就會進行重發(fā)；（但是主機A未收到主機B的確認應答，也可能是因為ACK丟包了）

這樣主機B就會收到很多重復的數(shù)據(jù)，那么TCP協(xié)議就需要能夠識別出那些包是重復的包，并且把重復的丟棄掉；

那么是如何解決的呢？

這個時候就用上了我們的序列號，這樣就可以很容易的實現(xiàn)去重的效果；

這里還有一個問題:超時時間該如何確定？

===》

• 最理想的情況下，找到一個最小的時間，保證確認應答能夠在這個時間內(nèi)可以返回。
• 隨著網(wǎng)絡的的波動，這個時間的長短是有差異的。
• 如果超時時間設(shè)置的太長，可能會影響整體的重傳效率。
• 如果超時時間設(shè)置的太短，可能會頻繁的發(fā)送重復的包。

?TCP為了保證無論在什么環(huán)境下都有比較高性能的通信，因此會動態(tài)的計算這個最大的超時時間。

• Linux中（BSD Unix和Windows也是如此），超時以500ms為一個單位進行控制，每次判定超時重發(fā)的超時時間都是500ms的整數(shù)倍。
• 如果重發(fā)一次后，還沒有收到應答，等待2*500ms后再進行重傳。
• 如果仍然還沒有收到應答，等待4*500ms進行重傳，依次類推，以指數(shù)的形式遞增。
• 累計到了一定的重傳次數(shù)，TCP認為網(wǎng)絡或者對端主機出現(xiàn)異常，會強制關(guān)閉連接。

2.3：連接管理

這里最重要的點三次握手和四次揮手

TCP中的握手，傳輸一個“打招呼”的數(shù)據(jù)包，這個數(shù)據(jù)包不攜帶任何的業(yè)務數(shù)據(jù)（沒有應用層載荷），數(shù)據(jù)包中只有報頭，沒有正文。
三次握手，在建立連接的過程中，客戶端和服務器要經(jīng)過三次這樣的“打招呼”，連接才能在雙方這邊建立好。

1）：客戶端給服務器發(fā)起一個syn（同步報文段）客戶端告訴服務器，我要和你進行連接，請你保存為的信息。

2）：服務器給客戶端返回一個ack，服務器告訴客戶端：收到我會保存！?。?/p>

3）：服務器也給客戶端發(fā)送一個syn，告訴客戶端，我也要和你建立連接，請你也保存我的信息

4）：客戶端收到之后，也會返回一個ack，告訴服務器：收到 ~我會保存

從邏輯上是四次交互，但是中間兩次，可以合并成一個TCP數(shù)據(jù)包，網(wǎng)絡上實際只傳輸了三個數(shù)據(jù)包。 實際圖如下所示：

??那么三次握手（建立連接）有什么意義？

1.類比于投石問路，確認當前通信路徑是否通暢
2.也是驗證通信雙方發(fā)送能力和接受能力是否正常
3.協(xié)商參數(shù)，通信雙方共同確認一些通信中的必備的參數(shù)數(shù)值

LISTEN狀態(tài)：服務器在new ServerSocket就會進入到LISTEN表示在監(jiān)聽這個窗口，端口上過來的客戶端就可以accept。

ESTABUSHED:客戶端和服務器之間連接建立好了，可以進行通信了。

我們可以使用netstat -ano來查看狀態(tài)。

TCP斷開連接（四次揮手）

1）：客戶端告訴服務器，我要和你斷開連接，請你把我刪了；

2）：服務器回應收到；

3）：服務器也告訴客戶端我也和你斷開連接，請你也把我刪了；

4）：客戶端回應收到；

客戶端和服務器都會把對方的信息（之前保存對方的ip和端口）刪除掉，刪除完了就斷開連接了；

之所以叫做四次揮手，是因為中間兩次相互，是不一定觸發(fā)合并的；

而三次握手本質(zhì)區(qū)別在于四次揮手不是完全由操作系統(tǒng)內(nèi)核完成的，而是和應用層代碼有關(guān)系。合并場景是特殊情況，優(yōu)化手段，所以還是把TCP的斷開連接稱為“四次揮手”；

那么合并的情況是什么？

比如，收到FIN觸發(fā)close之間，間隔的時間本身就不長，再加上上一個ack延遲應答了，這時就可以把這兩數(shù)據(jù)合并了；

2.3.1：CLOSE_WAIT：

被動一方斷開連接進入的狀態(tài)，收到對方發(fā)來的FIN，就會返回ACK同時進入CLOSE_WAIT狀態(tài)。（可以理解成wait close，等待關(guān)閉，等待應用程序代碼，調(diào)用close），通常情況下存在時間比較短。

一般而言，對于服務器上出現(xiàn)大量的 CLOSE_WAIT 狀態(tài), 原因就是服務器沒有正確的關(guān)閉 socket, 導致四次揮手沒有正確完成. 這是一個 BUG. 只需要加上對應的 close 即可解決問題.

通過cmd輸入netstat -an可以來查看這個狀態(tài)。

2.3.2：TIME_WAIT:

(類似于線程中TIME_WAITING狀態(tài)，有時間限制的等待），主動發(fā)起斷開連接一方進入的狀態(tài)，我方發(fā)起FIN，對方返回ACK，對方發(fā)起FIN，我方返回ACK同時進入TIME_WAIT狀態(tài) 。

想?想, 為什么是TIME_WAIT的時間是2MSL?

• MSL是TCP報文的最大生存時間, 因此TIME_WAIT持續(xù)存在2MSL的話
• 就能保證在兩個傳輸方向上的尚未被接收或遲到的報文段都已經(jīng)消失(否則服務器立刻重啟, 可能會收到來自一個進程的遲到的數(shù)據(jù), 但是這種數(shù)據(jù)很可能是錯誤的)；
• 同時也是在理論上保證最后一個報文可靠到達(假設(shè)最后一個ACK丟失, 那么服務器會再重新再發(fā)一個FIN. 這時雖然客戶端的進程不在了, 但是TCP連接還在, 仍然可以重發(fā)LAST_ACK);

其他幾個關(guān)鍵的狀態(tài)：

LISTEN:手機開機，信號良好，可以隨時打電話。

ESTABISHED:連接已經(jīng)建立，電話接聽，可以說話了。

TCP的狀態(tài)轉(zhuǎn)換匯總：

2.4：滑動窗口

如果我們對每一個發(fā)送的數(shù)據(jù)段，都給一個ACK確認應答，收到了ACK在發(fā)送下一個數(shù)據(jù)段，這樣就會造成問題—性能比較差，特別是數(shù)據(jù)返回時間很長的時候。

面對性能比較低，為我們可以一次發(fā)送多條數(shù)據(jù)，這樣就可以大大提升性能（實際就是將多個段的等待時間重疊在一起了）。

當我們批量發(fā)送多少數(shù)據(jù)不需要等待的，就稱之為“窗口大小”,當收到一個ACK時候就在發(fā)送一組數(shù)據(jù)，窗口再往后移動一格，此時這個窗口一直在往右平移，即我們就稱之為“滑動窗口”。

操作系統(tǒng)為了維護這個滑動窗口，需要開辟發(fā)送緩沖區(qū)來記錄當前還有哪些數(shù)據(jù)還有應答，只有確認應答過的數(shù)據(jù)，才能從緩沖區(qū)刪掉。
這里的窗口越大，即網(wǎng)絡的吞吐率越高。

那么如果這里出現(xiàn)了丟包—ACK丟了，怎么進行重傳的？

這種情況的丟包沒啥大要緊關(guān)系，因為可以通過后面的ACK進行確認。即當1001這個ACK返回的丟包了，可以通過收到2001這個ACK來確認接收方收到了1-1000的數(shù)據(jù)。

但是如果數(shù)據(jù)包丟了。

• 當1001-2000報文段丟失后，發(fā)送端就會一直收到1001這樣的ACK
• 如果發(fā)送端連續(xù)三次收到了同樣一個1001這樣的應答，就會將數(shù)據(jù)1001-2000重新發(fā)送；
• 這個時候接收端收到1001之后，再次返回的ACK就是7001（這是因為2001-7000）接收端已經(jīng)就已經(jīng)收到了，被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)里面了；

這種機制被稱之為“高速重發(fā)控制”（也叫“快重傳”）；

2.5：流量控制

接收端處理數(shù)據(jù)的速度是有限的，如果發(fā)送端發(fā)的太快，導致接收端的緩沖區(qū)滿了，這個時候發(fā)送端繼續(xù)發(fā)送，就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應。所以TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度，這個機制就叫做流量控制（Flow Control）；

• 接受端將自己可以接受的緩沖區(qū)大小放入TCP首部中的“窗口大小”字段，通過ACK端通知發(fā)送端；
• 窗口大小字段越大，說明網(wǎng)絡吞吐量越高；
• 當接收端發(fā)現(xiàn)自己的緩沖區(qū)要滿了，就會將窗口大小設(shè)置成一個更小的值通知發(fā)送給發(fā)送端；
• 發(fā)送端接收到這個窗口后，就會減慢自己的發(fā)送速度；
• 如果接收端緩沖區(qū)滿了，就會將窗口大小設(shè)置為0，這時發(fā)送方不在發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一個窗口探測數(shù)據(jù)段，把接收端窗口大小告訴給發(fā)送端；

這里TCP首部有一個16位的窗口字段，就是存放了窗口大小信息；這里有一個問題16位數(shù)字最大表示是65535，那么TCP的窗口大小最大也是65535字節(jié)嗎？實際上，TCP首部40字節(jié)選項中還包含了一個窗口擴大因子M，實際窗口的大小是窗口字段的值左移M位；

2.6：擁塞控制

雖然TCP有了滑動窗口這個神器，能夠高效可靠的發(fā)送大量的數(shù)據(jù)，但是如果在剛開始階段就發(fā)送大量的數(shù)據(jù)，可能會引發(fā)問題。因為網(wǎng)絡上有很多計算機，看你當前的網(wǎng)絡就是已經(jīng)比較擁堵，在不清楚當前網(wǎng)絡的狀態(tài)下，貿(mào)然發(fā)送大量數(shù)據(jù)，會引起問題。

TCP引入慢啟動機制，先發(fā)送少量數(shù)據(jù)，先探探路在摸清楚當前網(wǎng)絡的擁堵狀態(tài)，再決定按照多大的速度傳輸數(shù)據(jù)。

此時我們的擁塞窗口就起到了作用，剛開始發(fā)送，定義擁塞窗口大小為1，每次收到一個ACK應答，擁塞窗口就加1，每次發(fā)送數(shù)據(jù)的時候，將擁塞窗口和接收端主機反饋的窗口大小作比較，取較小的值作為實際發(fā)送端的窗口大?。?/p>

擁塞窗口增長速度是指數(shù)級別的，慢啟動只是初始時候慢，其增長速度是非常快的。

為了使增長的速度不那么快，就不能是擁塞窗口單純的加倍；我們引入一個叫做慢啟動的閾值，當擁塞窗口超過這個閾值的時候，就不再按照指數(shù)方式增長，而是按照線性方式增長；當TCP啟動的時候慢啟動閾值等于窗口最大值，在每次超時重發(fā)的時候，慢啟動閾值會變成原來的一半，同時擁塞窗口的值置為1；少量的丟包，我們認為是出發(fā)超時重傳，大量的丟包，我們就認為網(wǎng)絡擁塞；

當TCP通信開始后，網(wǎng)絡吞吐量會逐漸上升；隨著網(wǎng)絡發(fā)生擁堵，吞吐量會立即下降；

擁塞控制歸根結(jié)底是TCP協(xié)議想盡可能快的把數(shù)據(jù)傳輸給對方，但又要避免給網(wǎng)絡造成太大的壓力的折中方案。

2.7：延時應答

承接滑動窗口，在可靠性的前提下盡量讓窗口大一些，最終讓傳輸效率提高一些。不立即返回ACK。而是稍微等一等，就相當于給接收方留出一些時間，好能夠多消費一些，使接收緩沖區(qū)的剩余空間更大一點！

如果接收數(shù)據(jù)的主機立刻返回ACK應答，此時返回的窗口可能偏小。舉個直觀例子：

• 假設(shè)接收端緩沖區(qū)總大小為1M，一次收到500K數(shù)據(jù)后立刻應答，返回的窗口僅為500K；
• 但實際處理端可能速度很快，10ms內(nèi)就把這500K數(shù)據(jù)從緩沖區(qū)消費完畢；
• 這種情況下，接收端遠沒達到處理極限，就算窗口再放大也能應對。

如果接收端稍微延遲一點應答（比如等待200ms），此時緩沖區(qū)已空閑，返回的窗口大小就能達到1M。要知道：窗口越大，網(wǎng)絡吞吐量越高，傳輸效率也越強。我們的核心目標，就是在避免網(wǎng)絡擁塞的前提下，最大化傳輸效率。

不過，并非所有包都能延遲應答，需要遵守兩個關(guān)鍵限制：

• 數(shù)量限制：每接收N個包，必須應答一次；
• 時間限制：超過最大延遲時間，必須應答一次。

具體的N值和超時時間，不同操作系統(tǒng)會有差異，通常N取2，超時時間默認200ms。

2.8：捎帶應答

網(wǎng)絡通信中，經(jīng)常是“一問一答的模型”，客戶端發(fā)起request，服務器返回response

由于TCP會延時應答，當推遲后就正好趕上服務器返回的響應了，這樣就可以直接把ACK報文和響應數(shù)據(jù)，做成一個tcp數(shù)據(jù)報返回給客戶端了。此時基于延時應答的基礎(chǔ)上，提高傳輸效率的方案==》就叫做捎帶應答

捎帶應答，既取決于延時應答，有和應用程序的處理邏輯有關(guān)，捎帶應答不是100%會觸發(fā)的，但TCP會盡可能的進行捎帶應答。

2.9：面向字節(jié)流

創(chuàng)建TCP socket時，內(nèi)核會同步生成發(fā)送緩沖區(qū)與接收緩沖區(qū)，二者是TCP數(shù)據(jù)傳輸?shù)暮诵闹虚g載體，支撐起連接的全雙工特性。

數(shù)據(jù)寫入流程：調(diào)用write時，數(shù)據(jù)并非直接發(fā)送至網(wǎng)絡，而是先寫入發(fā)送緩沖區(qū)。若數(shù)據(jù)量過大，內(nèi)核會自動拆分為多個TCP數(shù)據(jù)包分批發(fā)送；若數(shù)據(jù)量過小，則會在緩沖區(qū)暫存，等待達到合適大小或滿足觸發(fā)條件后再批量發(fā)送，以此提升傳輸效率。

數(shù)據(jù)讀取流程：接收方的數(shù)據(jù)包先由網(wǎng)卡驅(qū)動接收，再傳入內(nèi)核的接收緩沖區(qū)，應用程序通過調(diào)用read，即可從該緩沖區(qū)中獲取數(shù)據(jù)。

緩沖區(qū)的存在讓TCP的讀寫操作完全解耦，無需一一匹配：

• 寫入100字節(jié)時，可一次調(diào)用write寫入全部，也可分100次調(diào)用、每次寫1字節(jié)；
• 讀取100字節(jié)時，無需關(guān)注發(fā)送方的寫入方式，既可一次read讀取全部，也可分100次、每次讀1字節(jié)。

正是這兩個獨立緩沖區(qū)的存在，使得單個TCP連接能同時進行讀、寫操作，這一特性被稱為全雙工。

2.10：粘包問題

以下面例子為例：

去掉報頭后，把載荷內(nèi)容梵高一個接收緩沖區(qū)里面；

則read的可能性：

1）：a a a b b b c c c
2）：aa ab bb ccc
3）：aaa bbb ccc
4）：aaab bbcc c
5）：aa abb bcc c
6）：aaa bbbc cc
··········等等

粘包，粘的是應用層的數(shù)據(jù)包
由于TCP字節(jié)流的特性，收到多個TCP數(shù)據(jù)報的時候把所有的載荷都混到了一起放到接收緩沖區(qū)里面。

那么如何解決粘包問題：

• 通過特殊的分隔符，來作為包邊界的區(qū)分。（比如：約定每個應用層數(shù)據(jù)包都以 ；結(jié)尾）但是這里要注意的是包里面內(nèi)容不能包括 ；這個字符，所以需要找到合適的分隔符，確保這個符號不會再正文中重復出現(xiàn)；
• 在應用層數(shù)據(jù)包開頭的地方，通過固定長度，約定整個應用層數(shù)據(jù)包的長度。

應用程序在read的時候，先固定read2個字節(jié)，看看2個字節(jié)里面的內(nèi)容是啥？（發(fā)現(xiàn)是3接下來在read3個字節(jié)，就讀到了aaa這樣就是完整的應用層數(shù)據(jù)保包了)。

粘包問題只針對于字節(jié)流的傳輸，對于文件操作（使用文件存儲多個結(jié)構(gòu)化數(shù)據(jù)，也是可能涉及到粘包問題的）例如：
通過文件，保存若干學生信息

//簡寫代碼
class Student{
	name;
	id;
	age;
	classId;
	···
}

此時約定成每個學生信息占一行使用 \n 作為結(jié)束標記即分隔符；

對于UDP來說，就不存在粘包問題；

這里應用層每次調(diào)用recv得到的就是一個完整的DatagramPacket ，也就對應一個完整應用層數(shù)據(jù)包；

2.11：異常情況

• 1.進程崩潰

意味著對應的文件描述符就被關(guān)閉了（調(diào)用close，關(guān)閉進程）只要進程退出了，都會釋放PCB，釋放文件描述表。

• 2.主機關(guān)機（正常流程）

正常流程下主機關(guān)機，就會先殺死所有的進程，此時也會觸發(fā)FIN，進而進入四次揮手；如果關(guān)機速度比較慢，有很大的可能四次揮手揮完了；如果關(guān)機速度表較快，四次揮手就會沒有揮完剛發(fā)FIN，機器就關(guān)閉了； 對端可以正常返回ACK，也會繼續(xù)正常發(fā)送FIN，這里的FIN就沒有收到ACK，嘗試重傳幾次FIN；還是沒有收到ACK，對端就會直接斷開連接即刪除之前保存的對端信息。

• 3.主機掉電（直接拔掉電源）

這里就會來不及發(fā)起FIN
1）：如果掉電的一方是接收方，對方是發(fā)送方。對方會繼續(xù)發(fā)送數(shù)據(jù)，沒有ack就會超時重傳在還沒有ack繼續(xù)超時重傳；到了一定的程度后，發(fā)送方就會發(fā)送一個復位報文 表示放棄鏈接。
2）：如果掉電一方是發(fā)送方，對方是接收方；這里就引入了一個心跳包 ：接收方會周期性的和發(fā)送方交換“心跳包”；
A給B發(fā)送一個無業(yè)務數(shù)據(jù)的報文，B就給A返回一個ACK。如果對方有應答就表示對方是正常工作的；如果心跳包沒有應答，就可以認為對方掛了，這時候就可以單方面的釋放連接了；

• 網(wǎng)線斷開

對于是發(fā)送方來說，沒有ack=》超時重傳=》仍然沒有ack=》超時重傳=》達到一定程度，放棄連接；
對于是接收方來說，周期性出發(fā)心跳包=》發(fā)現(xiàn)對端下線=》放棄連接；

三：UDP和TCP的區(qū)別

雖然TCP是可靠連接，但不能簡單判定其絕對優(yōu)于UDP——二者作為TCP/IP協(xié)議族的核心傳輸層協(xié)議，優(yōu)缺點各有側(cè)重，需結(jié)合具體場景選擇，而非絕對化比較。

TCP的核心優(yōu)勢是可靠傳輸：通過三次握手建立連接、四次揮手關(guān)閉連接，搭配重傳、排序、流量控制、擁塞控制等機制，能確保數(shù)據(jù)無丟失、無重復、按序到達。其適用場景集中在對數(shù)據(jù)完整性要求高的場景，比如文件傳輸、重要數(shù)據(jù)同步、支付轉(zhuǎn)賬、狀態(tài)更新等，缺點是協(xié)議開銷大、傳輸延遲較高，且不支持廣播/組播。

UDP的核心優(yōu)勢是高效實時：無需建立連接，頭部開銷極小，數(shù)據(jù)發(fā)送直接高效，延遲低、吞吐量高，且支持廣播和組播。它適用于對實時性、傳輸速度要求優(yōu)先于可靠性的場景，比如早期QQ聊天、視頻/語音通話、直播、游戲數(shù)據(jù)傳輸?shù)龋秉c是無可靠傳輸保障，數(shù)據(jù)可能丟失、亂序，需應用層自行處理可靠性需求。

歸根結(jié)底，TCP和UDP是程序員應對不同需求的工具，選擇的核心是匹配場景訴求：追求可靠選TCP，追求高效實時選UDP。

最后再分享一道經(jīng)典面試題給大家哈！----》用UDP實現(xiàn)可靠傳輸！
我們可以參考TCP的可靠性機制，在應用層實現(xiàn)類似的邏輯！
如：引入序列號，保證數(shù)據(jù)順序；
引入確認應答，確保對端收到了數(shù)據(jù)；
引入超時重傳，如果隔一段時間沒有收到應答，就重新發(fā)送數(shù)據(jù)
引入滑動窗口,設(shè)定發(fā)送窗口大小,無需等待前一個包的 ACK 即可發(fā)送后續(xù)包，避免 “發(fā)一個等一個” 的低效問題，平衡可靠性與傳輸效率。
以及流量控制和擁塞控制；

總結(jié)

到此這篇關(guān)于JavaEE初階教程之UDP協(xié)議和TCP協(xié)議的文章就介紹到這了,更多相關(guān)Java UDP協(xié)議和TCP協(xié)議內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論