目錄

1.區(qū)別

1.1 概括

1.2 詳解

2.TCP

2.1 內(nèi)容

2.2 可靠傳輸

2.2.1 確認(rèn)應(yīng)答

2.2.2 超時(shí)重傳

2.2.3 連接管理

三次握手

四次揮手

2.2.4 滑動(dòng)窗口

2.2.5 流量控制

2.2.6 擁塞控制

2.2.7?延時(shí)應(yīng)答

2.2.8?捎帶應(yīng)答

2.2.9?面向字節(jié)流

2.2.10?異常情況的處理

1.進(jìn)程崩潰

2.主機(jī)關(guān)機(jī)（正常關(guān)機(jī)）

3.主機(jī)掉電（非正常）

4.網(wǎng)線斷開(kāi)

3.對(duì)比

---

TCP和UDP是傳輸層的兩個(gè)重要協(xié)議，也是面試中經(jīng)常會(huì)被問(wèn)到的，屬于面試高頻點(diǎn)。今天，我們來(lái)學(xué)習(xí)這兩個(gè)協(xié)議。

1.區(qū)別

1.1 概括

TCP：有連接，可靠傳輸，面向字節(jié)流，全雙工

UDP：無(wú)連接，不可靠，面向數(shù)據(jù)報(bào)，全雙工

1.2 詳解

1.TCP是有連接的，UDP是無(wú)連接的

連接是抽象的概念，本質(zhì)上是建立連接的雙方，各自保存對(duì)方的信息

兩臺(tái)計(jì)算機(jī)建立連接，就是彼此保存了對(duì)方的關(guān)鍵信息

TCP想要通信，就需要建立連接，做完之后，才能后續(xù)通信。至于連接如何建立，不需要代碼干預(yù)，是系統(tǒng)內(nèi)核自動(dòng)負(fù)責(zé)完成的。

對(duì)于應(yīng)用程序來(lái)說(shuō)，客戶端這邊，主要是要發(fā)起“建立連接”動(dòng)作；服務(wù)器這邊，主要是把建立好的連接從內(nèi)核中拿到應(yīng)用程序里~

如果有客戶端，和服務(wù)器建立連接，這個(gè)時(shí)候服務(wù)器的應(yīng)用程序是不需要做出任何操作（也沒(méi)有任何感知的），內(nèi)核直接就完成了，建立連接的過(guò)程（三次握手），完成流程之后，就會(huì)在內(nèi)核的隊(duì)列中（這個(gè)隊(duì)列是每個(gè)serverSocket都有一個(gè)這樣的隊(duì)列）排隊(duì)。

應(yīng)用程序要想和這個(gè)客戶端進(jìn)行通信，就需要通過(guò)一個(gè)accept方法，把內(nèi)核隊(duì)列已經(jīng)建立好的連接對(duì)象，拿到應(yīng)用程序中。

即一個(gè)典型的生產(chǎn)者-消費(fèi)者模型。

UDP想要通信，直接發(fā)送數(shù)據(jù)即可，不需要征得對(duì)方同意，UDP自身也不會(huì)保存對(duì)方的信息

2.TCP是可靠傳輸，UDP是不可靠傳輸?shù)?/p>

網(wǎng)絡(luò)上進(jìn)行通信，A-> B發(fā)送一個(gè)消息，這個(gè)消息是不可能做到100%送到的

TCP就內(nèi)置了可靠傳輸機(jī)制，UDP就沒(méi)有內(nèi)置可靠傳輸。

A -> B 發(fā)消息，消息是不是到達(dá)B這一方，A自己能感知到，進(jìn)一步的，就可以在發(fā)送失敗的時(shí)候采取一定的措施（嘗試重傳之類(lèi)的）

可靠傳輸需要付出代價(jià)：a.機(jī)制更復(fù)雜? b.傳輸效率會(huì)降低

3.TCP是面向字節(jié)流的，UDP是面向數(shù)據(jù)報(bào)的

TCP和文件一樣，以字節(jié)位單位來(lái)進(jìn)行傳輸

UDP則是按照數(shù)據(jù)報(bào)為單位，來(lái)進(jìn)行傳輸?shù)?#xff08;UDP數(shù)據(jù)報(bào)是有嚴(yán)格的格式的）

4.TCP和UDP都是全雙工的

一個(gè)信道，允許雙向通信，就是全雙工

一個(gè)信道，允許單向通信，就是半雙工

2.TCP

2.1 內(nèi)容

2.2 可靠傳輸

常見(jiàn)面試題：

TCP是如何保證可靠傳輸?shù)?#xff1f;

通過(guò)確認(rèn)應(yīng)答為核心，借助其他機(jī)制輔助，最終完成可靠傳輸

2.2.1 確認(rèn)應(yīng)答

發(fā)送方，把數(shù)據(jù)發(fā)給接收方之后，接收方收到數(shù)據(jù)就會(huì)給發(fā)送方返回一個(gè)應(yīng)答報(bào)文

發(fā)送方，如果收到這個(gè)應(yīng)答報(bào)文了，就知道自己的數(shù)據(jù)是否發(fā)送成功

2.2.2 超時(shí)重傳

如果網(wǎng)絡(luò)傳輸過(guò)程中，出現(xiàn)丟包了，發(fā)送包，勢(shì)必就無(wú)法收到ACK了

由于丟包是一個(gè)“隨機(jī)”的事件，因此在TCP傳輸過(guò)程中，丟包就存在兩種情況：

1.傳輸?shù)臄?shù)據(jù)丟了

2.返回的ACK丟了

無(wú)論出現(xiàn)上述兩種情況，發(fā)送方都會(huì)采取統(tǒng)一的措施，就是“重傳”

發(fā)送方，何時(shí)重傳？等待時(shí)間

發(fā)送方，發(fā)出數(shù)據(jù)之后，會(huì)等待一段時(shí)間，如果這個(gè)時(shí)間之內(nèi)，ack來(lái)了，此時(shí)就自然視為數(shù)據(jù)到達(dá)

如果達(dá)到這個(gè)時(shí)間之后，數(shù)據(jù)還沒(méi)到，就會(huì)觸發(fā)重傳機(jī)制~

超過(guò)等待時(shí)間，再重傳~

第二次重傳后的等待時(shí)間會(huì)比第一次時(shí)間延長(zhǎng)，但延長(zhǎng)也不是無(wú)限制延長(zhǎng)，重傳若干次后，時(shí)間拉長(zhǎng)到一定程度，認(rèn)為數(shù)據(jù)再重傳也沒(méi)有用了，就放棄tcp連接（準(zhǔn)確來(lái)說(shuō)就是會(huì)觸發(fā)tcp的重置連接操作）

TCP會(huì)有一個(gè)“接收緩沖區(qū)”就是一個(gè)內(nèi)存空間，會(huì)保存當(dāng)前已經(jīng)收到的數(shù)據(jù)，以及數(shù)據(jù)的序號(hào)

接收方如果發(fā)現(xiàn)，當(dāng)前發(fā)送方發(fā)來(lái)的數(shù)據(jù)，是已經(jīng)再接收緩沖區(qū)中存在的（收到過(guò)的重復(fù)數(shù)據(jù)了），接收方就會(huì)直接把這個(gè)后來(lái)的數(shù)據(jù)給丟棄掉，確保應(yīng)用程序進(jìn)行read的時(shí)候，讀到的是只有一個(gè)數(shù)據(jù)

2.2.3 連接管理

建立連接 + 斷開(kāi)連接

面試中最經(jīng)典的問(wèn)題：三次握手 + 四次揮手

建立連接

三次握手

tcp這里的握手，也就是給對(duì)方傳輸一個(gè)簡(jiǎn)短的，沒(méi)有業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)包，通過(guò)這個(gè)數(shù)據(jù)包，來(lái)喚起對(duì)方的注意，從而觸發(fā)后續(xù)的操作（握手這個(gè)操作，不是TCP獨(dú)有的，甚至不是網(wǎng)絡(luò)通信獨(dú)有的，計(jì)算機(jī)中很多的操作，都會(huì)涉及到握手）

TCP的三次握手，TCP在建立連接的過(guò)程中，需要通信雙方進(jìn)行“打三次招呼”才能夠完成連接建立的

問(wèn)：三次握手是要解決什么問(wèn)題？

答：三次握手核心作用一：

投石問(wèn)路，確認(rèn)當(dāng)前網(wǎng)絡(luò)是否是暢通的

三次握手核心作用二：

能夠發(fā)送方和接受黨都能確認(rèn)自己的接收能力和發(fā)送能力均正常

三次握手核心作用三：

讓通信雙方，在通信過(guò)程中，針對(duì)一些重要的參數(shù)，進(jìn)行協(xié)商

問(wèn)：四次握手可以嗎？兩次握手可以嗎？

答：四次：可以，但沒(méi)必要

兩次：不可以，不能達(dá)到雙方都知道信息的過(guò)程

斷開(kāi)連接

四次揮手

為什么中間兩次不能像建立連接一樣合并為一步？

不一定

不能合并的原因：ACK和第二個(gè)FIN的觸發(fā)時(shí)機(jī)是不同的

ACK是內(nèi)核響應(yīng)的，B收到FIN，就會(huì)立即返回ACK

第二個(gè)FIN是應(yīng)用程序的代碼觸發(fā)，B這邊調(diào)用了close方法，才會(huì)觸發(fā)FIN

是否意味著，如果這這邊代碼close沒(méi)寫(xiě)/沒(méi)執(zhí)行到，是不是第二個(gè)FIN就一直發(fā)不出去？（有可能的）

如果是正常的四次揮手，正常的流程斷開(kāi)的連接

如果是不正常的揮手（沒(méi)有揮完四次），異常的流程斷開(kāi)連接（也是存在的）

三次握手ACK和第二個(gè)syn都是內(nèi)核觸發(fā)的，同一個(gè)時(shí)機(jī)，可以合并

可以合并的情況：TCP還有一個(gè)機(jī)制，延遲應(yīng)答，能夠拖延ACK的回應(yīng)時(shí)間，一旦ACK滯后了，就有機(jī)會(huì)和下一個(gè)FIN一起合并

哪一方，主動(dòng)斷開(kāi)連接，哪一方就會(huì)進(jìn)入TIME_WAIT

TIME_WAIT狀態(tài)的主要存在的意義，就是為了防止最后一個(gè)ACK丟失，留下的后手

如果最后一個(gè)ACK丟了，站在B的角度，B就會(huì)觸發(fā)超時(shí)重傳，重新把剛才的FIN給傳一遍

如果剛才A沒(méi)有TIME_WAIT狀態(tài)，就意味著A這個(gè)時(shí)候就已經(jīng)真的釋放連接了，此時(shí)重傳的FIN也就沒(méi)人能處理，沒(méi)人能返回ACK了，B也就永遠(yuǎn)收不到ACK了

A這邊使用TIME_WAIT狀態(tài)進(jìn)行等待，等待的這個(gè)時(shí)間，就會(huì)為了處理后續(xù)B重傳的FIN

此時(shí)如果有重傳的FIN來(lái)了，就可以繼續(xù)返回ACK了，B這邊的重傳才有意義

TIME_WAIT等待多久呢？

假設(shè)網(wǎng)絡(luò)上兩個(gè)節(jié)點(diǎn)通信消耗的最大等待時(shí)間為MSL，此時(shí)的TIME_WAIT的時(shí)間就是2MSL (已經(jīng)是上限了，絕大部分的數(shù)據(jù)包不會(huì)達(dá))

2.2.4 滑動(dòng)窗口

提高效率

TCP的可靠傳輸，是會(huì)影響傳輸?shù)男实?/p>

滑動(dòng)窗口，就讓可靠傳輸性能的影響，更小一些

TCP只要引入了可靠傳輸，傳輸效率是不可能超過(guò)沒(méi)有可靠性的UDP的

TCP這里的“效率機(jī)制”都是為了讓影響更小，縮小和UDP的差距

批量傳輸數(shù)據(jù)，不等ack回來(lái)，直接再發(fā)下一個(gè)數(shù)據(jù)

批量傳輸，也不是“無(wú)限的”傳輸

批量傳輸也是存在一定的上限的，達(dá)到上限之后，再統(tǒng)一等待ack

不等待的情況，批量最所發(fā)多少數(shù)據(jù)，這個(gè)數(shù)據(jù)量，稱為“窗口大小”

當(dāng)前A->B是批量的發(fā)了四份數(shù)據(jù)

此時(shí)B也要給A回應(yīng)四組ACK，此時(shí)A已經(jīng)達(dá)到窗口大小，再收到ACK之前，不能繼續(xù)往下發(fā)了

需要等待有ACK回來(lái)了之后，才能繼續(xù)往下發(fā)。

可以不需要一次等待四個(gè)ACK全部回來(lái)之后才能繼續(xù)發(fā)，而是回來(lái)一個(gè)ack，就立即繼續(xù)發(fā)一個(gè)

窗口越大，等待的ack越多，此時(shí)傳輸效率也就越高

情況一：ack丟了

這種情況，不需要任何重傳，沒(méi)事了

確認(rèn)信號(hào)，表示的含義是，當(dāng)前序號(hào)之前的數(shù)據(jù)，已經(jīng)確認(rèn)收到了

下一個(gè)你應(yīng)該從確認(rèn)序號(hào)這里，繼續(xù)發(fā)送

例如:如果1001這個(gè)ACK丟了，但是2001ACK到了，則證明2001之前的數(shù)據(jù)都已經(jīng)確認(rèn)傳輸成功了，涵蓋了1001的情況

情況二：數(shù)據(jù)包丟了

主機(jī)A就需要知道是哪個(gè)數(shù)據(jù)丟了，主機(jī)B也就得告訴A是哪個(gè)數(shù)據(jù)丟了。

主機(jī)A看到了B這邊連續(xù)的幾個(gè)ack，都是再索要1001，A就知道了，1001這個(gè)數(shù)據(jù)就是丟了，就重傳了1001

1001-2000重傳之后，順利到達(dá)B索要的就是7001

上述的重傳過(guò)程，并沒(méi)有額外的冗余操作，哪個(gè)數(shù)據(jù)丟了，就重傳哪個(gè)，沒(méi)丟的數(shù)據(jù)就不需要重傳，整個(gè)過(guò)程都是比較快速的

如果通信雙方，傳輸數(shù)據(jù)的量比較小，也不頻繁，就仍然是普通的確認(rèn)應(yīng)答和超時(shí)重傳。

如果通信雙方，傳輸數(shù)據(jù)量更大，也比較頻繁，就會(huì)進(jìn)入到滑動(dòng)窗口模式，按照快速重傳的方式處理。

通過(guò)滑動(dòng)窗口的方式傳輸數(shù)據(jù)，效率是會(huì)提升的

窗口越大，傳輸效率就越大（一份時(shí)間，等待的ack更多了，總的等待時(shí)間更少了）

當(dāng)然，滑動(dòng)窗口也不是設(shè)置越大越好

如果傳輸?shù)乃俣忍?#xff0c;就可能會(huì)使接收方，處理不過(guò)來(lái)了，此時(shí)，接收方也會(huì)出現(xiàn)丟包，發(fā)送方還得重傳。

2.2.5 流量控制

站在接收方的角度，反向制約發(fā)送方的傳輸效率

考慮接收方的處理能力

發(fā)送方發(fā)送的速率，不應(yīng)該超過(guò)接收方的處理能力

可以根據(jù)緩沖區(qū)剩余空間大小來(lái)判斷消費(fèi)者處理速度

把剩余緩沖區(qū)返回給發(fā)送方，發(fā)送方根據(jù)改緩沖區(qū)大小發(fā)送數(shù)據(jù)

窗口探測(cè)包：并不攜帶具體的業(yè)務(wù)數(shù)據(jù)，只是為了觸發(fā)ack，為了查詢當(dāng)前接收方這邊的接收緩沖區(qū)剩余空間。

2.2.6 擁塞控制

不僅僅是接收方，還有整個(gè)通信的路徑

關(guān)鍵問(wèn)題：接收方的處理能力，很方便進(jìn)行量化

但是中間節(jié)點(diǎn)，結(jié)構(gòu)更復(fù)雜，更難以直接的進(jìn)行量化，因此可以通過(guò)“實(shí)驗(yàn)”的方式，來(lái)找到一個(gè)合適的值

讓A先按照比較低的速度（小的窗口）來(lái)發(fā)送數(shù)據(jù)

如果數(shù)據(jù)傳輸?shù)倪^(guò)程非常順利，沒(méi)有丟包，再嘗試使用更大的窗口，更高的速度進(jìn)行發(fā)送（一點(diǎn)一點(diǎn)變化）

隨著窗口大小不停的增大，達(dá)到一定的程度，可能中間節(jié)點(diǎn)就會(huì)出現(xiàn)問(wèn)題了，此時(shí)這個(gè)節(jié)點(diǎn)就可能出現(xiàn)丟包

發(fā)送方發(fā)現(xiàn)丟包了，就把窗口大小調(diào)整小，此時(shí)如果還是繼續(xù)丟包，就繼續(xù)縮小，如果不丟包了，就繼續(xù)嘗試變大

在這個(gè)過(guò)程中，發(fā)送發(fā)不斷調(diào)整窗口大小，逐漸達(dá)到“動(dòng)態(tài)平衡”

最終時(shí)機(jī)發(fā)送的窗口大小，是取流量控制和擁塞控制中的窗口的較小值

2.2.7?延時(shí)應(yīng)答

A把數(shù)據(jù)傳給B，B就立即返回ack給A（正常）

也有時(shí)候，A傳輸給B，此時(shí)B等一會(huì)再返回給ack給A（延時(shí)應(yīng)答）

本質(zhì)上也是為了提升傳輸效率

延時(shí)返回ack,給接收方更多的時(shí)間，來(lái)讀取接收緩沖區(qū)的數(shù)據(jù)

此時(shí)接收方讀了這個(gè)數(shù)據(jù)之后，緩沖區(qū)剩余空間，變大了，返回的窗口大小也就更大了

2.2.8?捎帶應(yīng)答

在延時(shí)應(yīng)答的基礎(chǔ)上，進(jìn)一步的提升效率

網(wǎng)絡(luò)通信中，往往是這種“一問(wèn)一答”這樣的通信模型

ack也是內(nèi)核立即返回的，response則是應(yīng)用程序代碼來(lái)返回的，這兩者的時(shí)機(jī)是不同的

由于tcp引入了延時(shí)應(yīng)答，上面的ack不一定是立即返回，可能要等一會(huì)

在等一會(huì)的過(guò)程中，B就剛好把response給計(jì)算好了，計(jì)算好了之后，就會(huì)把response返回，與此同時(shí)順便就把剛才要返回的ack也帶上了，兩個(gè)數(shù)據(jù)就合并成了一個(gè)數(shù)據(jù)，此時(shí)就可以得到更高效的效果

2.2.9?面向字節(jié)流

這里有一個(gè)最重要的問(wèn)題，粘包問(wèn)題（不是tcp獨(dú)有的，而是面向字節(jié)流的機(jī)制都有類(lèi)似的情況）

此處“包”應(yīng)用層數(shù)據(jù)包，如果同時(shí)有多個(gè)應(yīng)用層數(shù)據(jù)包被傳輸過(guò)去，此時(shí)就容易出現(xiàn)粘包問(wèn)題

目前，接收緩沖區(qū)中，這三個(gè)應(yīng)用層數(shù)據(jù)包的數(shù)據(jù)，就是以字節(jié)的形式緊緊挨在一起的

接收方的應(yīng)用程序，讀取數(shù)據(jù)的時(shí)候，可以一次讀一個(gè)字節(jié)，也可以讀兩個(gè)字節(jié)也可以讀N個(gè)字節(jié)……

但是最終的目標(biāo)是為了得到完整的應(yīng)用層數(shù)據(jù)包，B應(yīng)用程序，就不知道，緩沖區(qū)里的數(shù)據(jù)，從哪里到哪里是一個(gè)完整的應(yīng)用數(shù)據(jù)包了

相比之下，像UDP這樣的面向數(shù)據(jù)報(bào)的通信方式，就沒(méi)有上述問(wèn)題

UDP的接收緩沖區(qū)中，相當(dāng)于是一個(gè)一個(gè)的DatagramPacket對(duì)象，應(yīng)用程序讀的時(shí)候，就明確知道哪里到哪里是一個(gè)完整的數(shù)據(jù)。

如何解決粘包問(wèn)題？

核心思想：通過(guò)定義好應(yīng)用層協(xié)議，明確應(yīng)用層數(shù)據(jù)包之間的邊界

1.引入分隔符

例如，可以使用\n作為分隔符

aaa\n

bbb\n

ccc\n

2.引入長(zhǎng)度

3aaa

4bbbb

3ccc

自定義應(yīng)用層協(xié)議的格式

xml,json,protobuffer,本身都是明確了包的邊界的

2.2.10?異常情況的處理

如果在tcp的使用中出現(xiàn)了意外，會(huì)如何處理？

1.進(jìn)程崩潰

（本質(zhì)上是進(jìn)程沒(méi)了，異常終止了。文件描述符表，也就釋放了，相當(dāng)于調(diào)用socket.close(),此時(shí)就會(huì)觸發(fā)FIN，對(duì)方收到之后，自然也就返回FIN和ACK，這邊再進(jìn)行ACK，即正常的四次揮手?jǐn)嚅_(kāi)連接的流程）

TCP的連接，可以獨(dú)立于進(jìn)程存在（進(jìn)程沒(méi)了，TCP連接不一定沒(méi)）

2.主機(jī)關(guān)機(jī)（正常關(guān)機(jī)）

進(jìn)行關(guān)機(jī)的時(shí)候，就是會(huì)觸發(fā)強(qiáng)制終止進(jìn)程的操作，相當(dāng)于1，此時(shí)就會(huì)觸發(fā)FIN，對(duì)方收到之后就會(huì)返回FIN和ACK，此時(shí)不僅僅是進(jìn)程沒(méi)了，整個(gè)系統(tǒng)也可能關(guān)閉了，如果在系統(tǒng)關(guān)閉之前，對(duì)端返回的ACK和FIN到了，此時(shí)系統(tǒng)還是可以返回ACK，進(jìn)行正常的四次揮手。但如果系統(tǒng)已經(jīng)關(guān)閉了，ACK和FIN遲到了，無(wú)法進(jìn)行后續(xù)ACK的響應(yīng)，站在對(duì)端的角度，對(duì)端以為是自己的FIN丟包了，重傳FIN，重傳幾次都沒(méi)有響應(yīng)，自然就會(huì)放棄連接（把持有的對(duì)端的信息就刪了）。

3.主機(jī)掉電（非正常）

此時(shí)，就是一瞬間的事情，來(lái)不及殺進(jìn)程，也來(lái)不及發(fā)送FIN，主機(jī)就直接停機(jī)了，站在對(duì)端的角度，對(duì)端不一定知道這個(gè)事情

如果對(duì)端是在發(fā)送數(shù)據(jù)（接收方掉電），發(fā)送的數(shù)據(jù)就一直會(huì)等待ACK ，觸發(fā)超時(shí)重傳，觸發(fā)TCP連接重置功能，發(fā)起“復(fù)位報(bào)文段”，如果復(fù)位報(bào)文段發(fā)過(guò)去之后，也沒(méi)有效果，此時(shí)就會(huì)釋放連接了

RST復(fù)位報(bào)文段

如果對(duì)端是在接收數(shù)據(jù)（發(fā)送方掉電），對(duì)端還在等待數(shù)據(jù)到達(dá)…..等了半天沒(méi)消息，此時(shí)其實(shí)是無(wú)法區(qū)分，是對(duì)端沒(méi)發(fā)消息，還是對(duì)方掛了

TCP中提供了心跳包機(jī)制（形象的比喻），即接收方也會(huì)周期性的給發(fā)送方發(fā)送一個(gè)特殊的，不攜帶業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)包，并且期望對(duì)方返回一個(gè)應(yīng)答，如果對(duì)方?jīng)]有應(yīng)答，并且重復(fù)了多次之后，仍然沒(méi)有，就視為對(duì)方掛了，此時(shí)就可以單方面釋放連接了。

4.網(wǎng)線斷開(kāi)

和主機(jī)掉電非常類(lèi)似

當(dāng)前A給B發(fā)送數(shù)據(jù)，一旦網(wǎng)線斷開(kāi)

A就相當(dāng)于會(huì)觸發(fā)超時(shí)重傳 -> 連接重置 ->單方面釋放連接

B就會(huì)觸發(fā)心跳包 -> 發(fā)現(xiàn)對(duì)端沒(méi)響應(yīng) -> 單方面釋放連接

3.對(duì)比

TCP和UDP之間的對(duì)比

TCP優(yōu)勢(shì)在于可靠傳輸，更適用絕大部分場(chǎng)景

UDP優(yōu)勢(shì)在于高效率，更適用于“可靠性不敏感，性能敏感”場(chǎng)景

局域網(wǎng)內(nèi)部（同一個(gè)機(jī)房）的主機(jī)之間通信

如果要傳輸比較大的數(shù)據(jù)包，TCP更優(yōu)先（UDP有64kb的限制）

如果要進(jìn)行“廣播傳輸”，優(yōu)先考慮UDP，UDP天然支持廣播，TCP不支持（應(yīng)用程序額外寫(xiě)代碼實(shí)現(xiàn)）

有一種特殊的場(chǎng)景，需要把數(shù)據(jù)發(fā)給局域網(wǎng)的所有機(jī)器，這個(gè)情況就是廣播