UDP協(xié)議為應(yīng)用層提供不可靠、無(wú)連接和基于數(shù)據(jù)報(bào)的服務(wù)。所以，使用UDP協(xié)議的應(yīng)用程序通常要自己處理數(shù)據(jù)確認(rèn)、超時(shí)重傳等邏輯。而TCP協(xié)議則完全相反，為應(yīng)用層提供可靠的、面向連接的和基于流的服務(wù)。當(dāng)發(fā)送端應(yīng)用程序連續(xù)執(zhí)行多次寫(xiě)操作時(shí)，TCP模塊先將這些數(shù)據(jù)放入TCP發(fā)送緩沖區(qū)中。當(dāng)TCP模塊真正發(fā)送數(shù)據(jù)時(shí)，發(fā)送緩沖區(qū)中等待發(fā)送的數(shù)據(jù)就可能被封裝成一個(gè)或者多個(gè)TCP報(bào)文段發(fā)出。因此，TCP模塊發(fā)送出的TCP報(bào)文段的個(gè)數(shù)和應(yīng)用程序執(zhí)行的寫(xiě)操作次數(shù)之間沒(méi)有固定的數(shù)量關(guān)系。

顯然的tcp發(fā)幀數(shù)據(jù)，你需要自己處理好分幀問(wèn)題，這塊寫(xiě)起來(lái)既不方便，也很麻煩，所以用tcp收發(fā)幀數(shù)據(jù)，往往需要在上層再包裝一層協(xié)議，比如IoT中比較流行的mqtt，欽定只支持tcp封裝，并且流傳輸肯定是有序的，后面的數(shù)據(jù)到了前面沒(méi)到，也必須等待前面數(shù)據(jù)到了才能夠組裝起來(lái)，這也導(dǎo)致其延遲控制能力更差。

但好處是tcp非常適合于傳輸大量數(shù)據(jù)，比如像文件或http這種，能夠保證數(shù)據(jù)是按照順序發(fā)給你的，如果丟包了，底層也有重發(fā)機(jī)制能夠盡可能保證數(shù)據(jù)發(fā)送可靠性，還有一系列擁塞機(jī)制，盡可能利用信道帶寬。

udp就簡(jiǎn)單粗暴多了，發(fā)送一個(gè)數(shù)據(jù)包，要么完整收到，要么丟包，傳輸層中沒(méi)有那么多七七八八的算法，所以u(píng)dp很快，也非常適合做裸協(xié)議發(fā)送一些控制幀數(shù)據(jù)，包括rts游戲中的網(wǎng)絡(luò)同步，能夠更好控制延遲問(wèn)題，但是顯然的就得付出代價(jià)，比如可能會(huì)丟包哦，可能收到的數(shù)據(jù)包是亂序的哦，所以如果你用udp來(lái)傳輸大文件，七寫(xiě)八寫(xiě)一通下來(lái)，可能就是實(shí)現(xiàn)了一個(gè)蹩腳的tcp。

除此之外還有什么別的么，誒，如果我們?cè)偻蠈幼?，維護(hù)tcp連接和邏輯實(shí)現(xiàn)，需要更多的性能及資源哦，所以面向tcp的攻擊會(huì)更多，比如synflood，或者是面向序列號(hào)的三方攻擊或某些不可說(shuō)的rst中間人中斷攻擊。當(dāng)然，如果不觸及傳輸層實(shí)現(xiàn)，tcp往往需要再包裝一層協(xié)議(會(huì)話或表示層），針對(duì)該層的慢速攻擊及半連接攻擊甚至是溢出攻擊，處理起來(lái)尤為頭疼，這也是這層協(xié)議設(shè)計(jì)起來(lái)尤為頭疼的地方。

WRITE-BUG研發(fā)團(tuán)隊(duì)衷心希望【W(wǎng)RITE-BUG數(shù)字空間】可以給每位同學(xué)一個(gè)屬于自己的秘密空間，同時(shí)祝愿大家在“公開(kāi)圈子”世界里，遇見(jiàn)志同道合的伙伴們，因?yàn)槲覀兣c大家一樣，都曾孤獨(dú)前行著。