TCP與UDP基本區(qū)別

1. 基于連接與無(wú)連接
2. TCP要求系統(tǒng)資源較多，UDP較少；
3. UDP程序結(jié)構(gòu)較簡(jiǎn)單
4. 流模式（TCP）與數(shù)據(jù)報(bào)模式(UDP);
5. TCP保證數(shù)據(jù)正確性，UDP可能丟包
6. TCP保證數(shù)據(jù)順序，UDP不保證

UDP應(yīng)用場(chǎng)景：

1. 面向數(shù)據(jù)報(bào)方式
2. 網(wǎng)絡(luò)數(shù)據(jù)大多為短消息
3. 擁有大量Client
4. 對(duì)數(shù)據(jù)安全性無(wú)特殊要求
5. 網(wǎng)絡(luò)負(fù)擔(dān)非常重，但對(duì)響應(yīng)速度要求高

TCP報(bào)頭

UDP報(bào)頭

TCP三次握手

1.TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，時(shí)刻準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求，此時(shí)服務(wù)器就進(jìn)入了LISTEN（監(jiān)聽(tīng)）狀態(tài)； 2.TCP客戶進(jìn)程也是先創(chuàng)建傳輸控制塊TCB，然后向服務(wù)器發(fā)出連接請(qǐng)求報(bào)文，這是報(bào)文首部中的同部位SYN=1，同時(shí)選擇一個(gè)初始序列號(hào) seq=x ，此時(shí)，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個(gè)序號(hào)。 3.TCP服務(wù)器收到請(qǐng)求報(bào)文后，如果同意連接，則發(fā)出確認(rèn)報(bào)文。確認(rèn)報(bào)文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號(hào)是ack=x+1，同時(shí)也要為自己初始化一個(gè)序列號(hào) seq=y，此時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個(gè)報(bào)文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個(gè)序號(hào)。 4.TCP客戶進(jìn)程收到確認(rèn)后，還要向服務(wù)器給出確認(rèn)。確認(rèn)報(bào)文的ACK=1，ack=y+1，自己的序列號(hào)seq=x+1，此時(shí)，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。TCP規(guī)定，ACK報(bào)文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號(hào)。 5.當(dāng)服務(wù)器收到客戶端的確認(rèn)后也進(jìn)入ESTABLISHED狀態(tài)，此后雙方就可以開(kāi)始通信了。

為什么TCP客戶端最后還要發(fā)送一次確認(rèn)呢？

一句話，主要防止已經(jīng)失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)器，從而產(chǎn)生錯(cuò)誤。

如果使用的是兩次握手建立連接，假設(shè)有這樣一種場(chǎng)景，客戶端發(fā)送了第一個(gè)請(qǐng)求連接并且沒(méi)有丟失，只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了，由于TCP的客戶端遲遲沒(méi)有收到確認(rèn)報(bào)文，以為服務(wù)器沒(méi)有收到，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文，此后客戶端和服務(wù)器經(jīng)過(guò)兩次握手完成連接，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時(shí)此前滯留的那一次請(qǐng)求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個(gè)報(bào)文本該是失效的，但是，兩次握手的機(jī)制將會(huì)讓客戶端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)。

如果采用的是三次握手，就算是那一次失效的報(bào)文傳送過(guò)來(lái)了，服務(wù)端接受到了那條失效報(bào)文并且回復(fù)了確認(rèn)報(bào)文，但是客戶端不會(huì)再次發(fā)出確認(rèn)。由于服務(wù)器收不到確認(rèn)，就知道客戶端并沒(méi)有請(qǐng)求連接。

TCP四次揮手

1.客戶端進(jìn)程發(fā)出連接釋放報(bào)文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部，F(xiàn)IN=1，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。

2.服務(wù)器收到連接釋放報(bào)文，發(fā)出確認(rèn)報(bào)文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。

3.客戶端收到服務(wù)器的確認(rèn)請(qǐng)求后，此時(shí)，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。

4.服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。

客戶端收到服務(wù)器的連接釋放報(bào)文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號(hào)是seq=u+1，此時(shí)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。

5.服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接?？梢钥吹剑?wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。

為什么客戶端最后還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實(shí)現(xiàn)可以設(shè)置不同的MSL值。

第一，保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文能夠到達(dá)服務(wù)器，因?yàn)檫@個(gè)ACK報(bào)文可能丟失，站在服務(wù)器的角度看來(lái)，我已經(jīng)發(fā)送了FIN+ACK報(bào)文請(qǐng)求斷開(kāi)了，客戶端還沒(méi)有給我回應(yīng)，應(yīng)該是我發(fā)送的請(qǐng)求斷開(kāi)報(bào)文它沒(méi)有收到，于是服務(wù)器又會(huì)重新發(fā)送一次，而客戶端就能在這個(gè)2MSL時(shí)間段內(nèi)收到這個(gè)重傳的報(bào)文，接著給出回應(yīng)報(bào)文，并且會(huì)重啟2MSL計(jì)時(shí)器。

第二，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個(gè)確認(rèn)報(bào)文后，在這個(gè)2MSL時(shí)間中，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會(huì)出現(xiàn)舊連接的請(qǐng)求報(bào)文。

為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？

建立連接的時(shí)候， 服務(wù)器在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。 而關(guān)閉連接時(shí)，服務(wù)器收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來(lái)表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開(kāi)發(fā)送，從而導(dǎo)致多了一次。

如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個(gè)保活計(jì)時(shí)器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒(méi)有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒(méi)反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

總的來(lái)說(shuō) TCP協(xié)議提供可靠的服務(wù)， UDP協(xié)議提供高效率的服務(wù)。

高可靠性的TCP服務(wù)提供面向連接的服務(wù)，主要用于一次傳輸大量報(bào)文的情形， 如文件傳輸，遠(yuǎn)程登錄等；

高效率的UDP協(xié)議提供無(wú)連接的數(shù)據(jù)報(bào)服務(wù)，用于一次傳輸少量的報(bào)文。 即使發(fā)生傳輸錯(cuò)誤，也可以重新傳輸并且不會(huì)為此付出多少代價(jià)。

TCP提供的是面向連接的、可靠的數(shù)據(jù)流傳輸，可避免數(shù)據(jù)傳輸錯(cuò)誤。 面向連接的協(xié)議在任何數(shù)據(jù)傳輸前就建立好了點(diǎn)到點(diǎn)的連接。

而UDP提供的是非面向連接的、不可靠的數(shù)據(jù)流傳輸。當(dāng)一個(gè)UDP數(shù)據(jù)包在網(wǎng)絡(luò)中移動(dòng)時(shí)， 發(fā)送過(guò)程并不知道它是否到達(dá)了目的地，除非應(yīng)用層已經(jīng)確認(rèn)了它已到達(dá)的事實(shí)。 當(dāng)數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)?完整性、 可控制性 可靠性時(shí)， TCP協(xié)議是當(dāng)然的選擇。 當(dāng)強(qiáng)調(diào)傳輸性能而不是傳輸?shù)耐暾詴r(shí)， 如：音頻和多媒體應(yīng)用， UDP是最好的選擇。 在數(shù)據(jù)傳輸時(shí)間很短，以至于此前的連接過(guò)程成為整個(gè)流量主體的情況下 UDP也是一個(gè)好的選擇 ，如：DNS交換。把SNMP建立在UDP上的部分原因是設(shè)計(jì)者認(rèn)為當(dāng)發(fā)生網(wǎng)絡(luò)阻塞時(shí)， UDP較低的開(kāi)銷使其有更好的機(jī)會(huì)去傳送管理數(shù)據(jù)。

總結(jié)

tcp 提供可靠的服務(wù) 若強(qiáng)調(diào) 完整性 可靠性可控性 選擇tcp

udp 提供高效的服務(wù) 若強(qiáng)調(diào) 傳輸性能 選擇udp

TCP： 面向連接、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)、 用于傳輸大量數(shù)據(jù)(流模式)、速度慢，建立連接需要開(kāi)銷較多 (時(shí)間，系統(tǒng)資源)。 UDP：面向非連接、傳輸不可靠、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快。

[1] tcp和udp的區(qū)別,簡(jiǎn)單來(lái)說(shuō), tcp是有序可靠傳輸, 而udp是不可靠亂序傳輸,但是實(shí)際上你把udp看做IP可能更準(zhǔn)確一點(diǎn),因?yàn)榭梢栽趗dp基礎(chǔ)上開(kāi)發(fā)出可靠udp等各種傳輸.

[2] tcp的優(yōu)缺點(diǎn)是什么?優(yōu)點(diǎn),這是一個(gè)國(guó)際通行了很多年的標(biāo)準(zhǔn)實(shí)現(xiàn),調(diào)用簡(jiǎn)單,省心,很多應(yīng)用都基于tcp進(jìn)行實(shí)現(xiàn)的,最關(guān)鍵的是,它的兼容性是跨平臺(tái)的,也就是,只要你選擇的是tcp,那么不管是windows還是linux,unix,只要支持tcp/ip,那么就可以保證實(shí)現(xiàn)可靠連接和傳輸.作為軟件的開(kāi)發(fā)者只需要考慮應(yīng)用層,比如應(yīng)用協(xié)議等的實(shí)現(xiàn)就可以了. 至于可靠傳輸?shù)男阅?由于是國(guó)際標(biāo)準(zhǔn),在內(nèi)核層實(shí)現(xiàn)和運(yùn)行,很多都做了硬件級(jí)的優(yōu)化,因此對(duì)比起用udp等實(shí)現(xiàn)的可靠傳輸,本機(jī)[注意是本機(jī)]的極限傳輸性能要高很多.

那么tcp有什么明顯的缺點(diǎn)呢? 對(duì)開(kāi)發(fā)者來(lái)說(shuō)最頭大的恐怕就是2條, 第一是每個(gè)tcp連接都是1對(duì)1連接,這意味著每個(gè)連接都需要一個(gè)套接字socket,并且需要隨時(shí)測(cè)試是否數(shù)據(jù)可讀可寫.當(dāng)連接數(shù)量達(dá)到一定的程度,性能會(huì)直線下降. 沒(méi)有經(jīng)歷過(guò)大規(guī)模并發(fā)應(yīng)用開(kāi)發(fā)的朋友可能很難想像,就一個(gè)基本沒(méi)有數(shù)據(jù)的空連接怎么會(huì)消耗系統(tǒng)的性能呢?其實(shí)這個(gè)問(wèn)題,不可以單純從硬件或者api接口等進(jìn)行解釋,而需要從tcp/ip協(xié)議棧的實(shí)現(xiàn)中去發(fā)現(xiàn)的,從可以查看到的代碼,Linux freebsd unix來(lái)看,無(wú)一列外,在操作系統(tǒng)里使用的是指針鏈表進(jìn)行管理, 重要的事情說(shuō)3遍 , 用的是指針鏈表 ,指針鏈表,指針鏈表 , 看下Linux 下的實(shí)現(xiàn) [不是最新版,不過(guò)這個(gè)應(yīng)該不會(huì)改變,因?yàn)闀?huì)導(dǎo)致整個(gè)代碼重構(gòu)] ,

ip層的接收

复制for( qp=ipqueue; qp!=NULL; qplast=qp,qp=qp- >next)
{
  if(iph- >id==qp- >iph- >id && .......
     }

新版本4的測(cè)試版Linux核心tcp/ip實(shí)現(xiàn), 和之前的比,是使用了rcu_函數(shù)來(lái)優(yōu)化,其實(shí)換湯不換藥,在執(zhí)行插入和寫操作的時(shí)候,需要執(zhí)行rcu_writelock, 這和readlock不同,能且只有一個(gè)鎖定,而無(wú)法多重鎖定,性能在這里遇到了瓶頸, 這個(gè)瓶頸出現(xiàn)在tcp/ip協(xié)議棧的實(shí)現(xiàn)中,由于tcp包的構(gòu)成問(wèn)題,至少到目前,或者可以遇見(jiàn)的將來(lái),tcp這個(gè)嚴(yán)重影響并發(fā)性能的問(wèn)題會(huì)一直存在在實(shí)現(xiàn)中,這是絕大部分人都始終沒(méi)有搞明白,為什么tcp在面對(duì)海量并發(fā)的時(shí)候,在超過(guò)一定數(shù)字后性能出現(xiàn)直線下降的其中一個(gè)關(guān)鍵原因. [我曾經(jīng)嘗試過(guò)為L(zhǎng)inux下Tcp/ip棧的指針鏈表引入排序等優(yōu)化,但是經(jīng)過(guò)各種測(cè)試,我發(fā)現(xiàn)事實(shí)上這個(gè)實(shí)現(xiàn)在大部分情況下性能比排序好,因?yàn)榕判虻确炊鴮?dǎo)致了性能下降,因此除非有革命性的優(yōu)化出現(xiàn),目前這個(gè)瓶頸會(huì)一直存在.]

給出我們自己編寫的延遲測(cè)試結(jié)果 硬件是Intel i3 2350 [2.3g] ddr3 1333 , tcp 連接數(shù)量大并頻繁小包傳輸下,協(xié)議棧導(dǎo)致延遲非常明顯,

看出問(wèn)題在那里了嗎？是個(gè)指針遍歷操作 ， 獨(dú)占模式 ，一萬(wàn)空連接在目前的cpu前，可能沒(méi)什么 ，但是如果是并發(fā)模式n萬(wàn)小包呢， 那開(kāi)銷n/2......，你再多的cpu核心也沒(méi)用，一個(gè)鏈表只有一個(gè)獨(dú)占模式的遍歷操作，其他cpu只能干著急。所以在面對(duì)小數(shù)據(jù)量海量長(zhǎng)時(shí)間連接的應(yīng)用時(shí),選擇tcp必須要慎重再慎重. 第二個(gè)大問(wèn)題是tcp是雙向流傳輸,而keepalive這個(gè)功能并非普遍支持, 雙向流傳輸意味著,數(shù)據(jù)是采用流模式過(guò)來(lái)的,如果切割取決于協(xié)議的制定者,例如普遍的采用rn作為分割字符, 而keepalive的非普遍實(shí)現(xiàn),則導(dǎo)致另外一個(gè)問(wèn)題,那就是每個(gè)連接,必須每過(guò)一定時(shí)間在應(yīng)用協(xié)議層檢測(cè)連接是否還存活,最典型的就是ftp,如果沒(méi)有指令操作,那么客戶端每過(guò)一定時(shí)間必須發(fā)送一條指令,通常是noop指令給服務(wù)器端,告訴服務(wù)器,我還保持著連接,不要中斷. 可能有人無(wú)法理解,tcp不是可靠連接嗎? tcp是可靠連接,要命的時(shí),當(dāng)tcp建立連接后,如果雙方?jīng)]有應(yīng)用層的數(shù)據(jù)傳輸,那么當(dāng)物理中斷發(fā)生的時(shí)候,等待的一方是接收不到發(fā)生故障的一方的任何消息的,直到?jīng)]有發(fā)生故障的一方,主動(dòng)發(fā)送數(shù)據(jù)給另一方,出現(xiàn)發(fā)送超時(shí)的時(shí)候,才能給出中斷判斷,否則就是個(gè)死等待,這就是ftp等協(xié)議中引入noop等類似機(jī)制的原因. 流傳輸?shù)牧硪粋€(gè)問(wèn)題是,無(wú)法實(shí)現(xiàn)數(shù)據(jù)的并發(fā)傳輸,而只等排隊(duì)發(fā)送,這在很多應(yīng)用,特別是游戲類應(yīng)用是嚴(yán)重的缺陷,無(wú)論你有多著急,一個(gè)連接就是一個(gè)流,你要排隊(duì)先發(fā)送到緩沖,然后由系統(tǒng)負(fù)責(zé)發(fā)送緩沖數(shù)據(jù),可能有人說(shuō)可以使用緊急指針帶外數(shù)據(jù),但這玩意不是讓你用來(lái)傳輸數(shù)據(jù)的,其實(shí)是讓你用來(lái)發(fā)送緊急通知用的,在tcp中使用帶外數(shù)據(jù),除了帶來(lái)更復(fù)雜的實(shí)現(xiàn),沒(méi)有什么實(shí)質(zhì)性作用,以ftp為例子,實(shí)際上無(wú)論你使用使用緊急指針帶外數(shù)據(jù),都可以中斷數(shù)據(jù)傳輸?shù)?這個(gè)緊急指針在那里除了保持兼容性,沒(méi)有實(shí)際作用.

[3] udp的優(yōu)缺點(diǎn)是什么? udp是比tcp更接近IP的協(xié)議, 通常udp是不可靠傳輸,但是我們可以在應(yīng)用層對(duì)udp加上校驗(yàn)和序列號(hào),做成可靠傳輸,這一點(diǎn)不可不知. udp的優(yōu)點(diǎn)是什么? 書上總是說(shuō)udp的性能比tcp好,有沒(méi)有人想過(guò)為什么? 其實(shí)原因很簡(jiǎn)單, udp是發(fā)射后不管, 不需要對(duì)方發(fā)送ack包進(jìn)行確認(rèn), tcp由于需要對(duì)每一個(gè)包進(jìn)行ack確認(rèn),一來(lái)一回,就會(huì)影響到傳輸效率,但事實(shí)上,這個(gè)影響是很小的,如果不考慮丟包和線路不穩(wěn)定等,這個(gè)差距一般只有百分只幾,除非你做極限測(cè)試. 但實(shí)際上,真正用到udp高效傳輸?shù)膱?chǎng)合是非常少的,一個(gè)關(guān)鍵的原因在于它的不可靠性,特別是在Internent上,遇到網(wǎng)關(guān)路由高負(fù)載的時(shí)候,優(yōu)先扔掉udp包,而且有幾率發(fā)生連續(xù)的丟包. 我個(gè)人認(rèn)為,udp最大的優(yōu)點(diǎn)在于它的可塑性非常強(qiáng), 我們可以通過(guò)各種機(jī)制來(lái)改造udp,例如實(shí)現(xiàn)可靠傳輸,實(shí)現(xiàn)1對(duì)多傳輸, 實(shí)現(xiàn)包和流模式同時(shí)傳輸,優(yōu)先發(fā)送,多路雙向傳輸?shù)鹊? 很多擴(kuò)展在tcp上是無(wú)法實(shí)現(xiàn)的,但是通過(guò)udp擴(kuò)展就可以很輕松的做到. 同樣,通過(guò)擴(kuò)展udp來(lái)實(shí)現(xiàn)可靠傳輸,我們可以避開(kāi)tcp/ip協(xié)議棧實(shí)現(xiàn)中指針鏈表查詢導(dǎo)致的性能急劇下降,很多人都沒(méi)有意識(shí)到這點(diǎn),其實(shí)在應(yīng)對(duì)海量連接方面,udp可靠傳輸能支持的用戶數(shù)量遠(yuǎn)超tcp,因?yàn)閡dp不需要那種大規(guī)模的鏈表查詢,是個(gè)隊(duì)列操作. 那么udp的缺點(diǎn)是什么,最要命的就是不可靠傳輸,其次是包的偽造,雖然我們可以通過(guò)加入各種機(jī)制和擴(kuò)展,把udp改造成可靠傳輸,但是由于這個(gè)實(shí)現(xiàn)是在應(yīng)用層,因此在面對(duì)少量用戶大流量傳輸?shù)臅r(shí)候,極限輸出不如tcp,例如本機(jī).

那么如何選擇tcp還是udp?

先看下人家怎么選

1 HTTP, http協(xié)議現(xiàn)在已經(jīng)深入影響到我們的方方面面，重要性就不說(shuō)了， 它采用的是tcp 協(xié)議，為什么使用tcp, 因?yàn)樗鼈鬏數(shù)膬?nèi)容是不可以出現(xiàn)丟失，亂序等各種錯(cuò)誤的，其次它需要跨平臺(tái)實(shí)現(xiàn)，而tcp滿足了這個(gè)要求，發(fā)展到今天，http享受了tcp帶來(lái)的簡(jiǎn)潔高效和跨平臺(tái)，但是也承受了tcp的各種缺點(diǎn)，例如缺少tcp keep alive機(jī)制[這個(gè)其實(shí)是后來(lái)添加的支持，并非普遍實(shí)現(xiàn)], tcp協(xié)議棧的實(shí)現(xiàn)問(wèn)題引發(fā)的難以支持海量用戶并發(fā)連接[只能通過(guò)dns等級(jí)別的集群或者cdn來(lái)實(shí)現(xiàn)]，協(xié)議太復(fù)雜導(dǎo)致很難模塊化處理[其實(shí)這個(gè)問(wèn)題已經(jīng)在nginx解決了，nginx通過(guò)模塊化和對(duì)協(xié)議的分段處理機(jī)制，并引入消息機(jī)制，避免了多進(jìn)程[線程]的頻繁切換，相比apache等老牌web服務(wù)器軟件，在應(yīng)對(duì)大量用戶上擁有極大的優(yōu)勢(shì)。 即使站在今天的角度看，http也確實(shí)應(yīng)該選擇tcp.

2 FTP, 這個(gè)協(xié)議比http更加古老，它采用的也是tcp協(xié)議， 因?yàn)樗拿恳粋€(gè)指令，或者文件傳輸?shù)臄?shù)據(jù)流，都需要保證可靠性，同時(shí)要求在各種平臺(tái)上廣泛支持，那么就只能選擇tcp, 和http不同，它采用了noop指令機(jī)制來(lái)處理tcp缺少keep alive機(jī)制帶來(lái)的問(wèn)題，也就是客戶端必須每過(guò)一段時(shí)間，如果沒(méi)有發(fā)送其他指令，就必須發(fā)送一個(gè)noop指令給服務(wù)器，避免被服務(wù)器認(rèn)為是死連接。 Ftp的缺陷在哪里呢？,其次它的文件傳輸是采用新的數(shù)據(jù)連接來(lái)執(zhí)行，等于1個(gè)用戶需要2個(gè)連接,其次當(dāng)一個(gè)文件正在傳輸?shù)臅r(shí)候，你無(wú)法進(jìn)行其他操作，例如列表，也許你可以把它當(dāng)作是一一對(duì)應(yīng)的典范，因?yàn)檫@樣我們可以直接用命令行進(jìn)行控制，但是很多用戶其實(shí)是需要在下載的時(shí)候同時(shí)進(jìn)行列表等操作的，為了解決這個(gè)問(wèn)題，很多客戶端只要開(kāi)啟多個(gè)指令連接[和數(shù)據(jù)連接]，這樣一來(lái)，無(wú)形中額外帶給了Ftp服務(wù)器很多壓力，而采用udp可靠傳輸就不存在這個(gè)問(wèn)題，但是udp可靠傳輸是沒(méi)有跨平臺(tái)支持的，這樣是魚(yú)和熊掌不可兼得，對(duì)于這樣一個(gè)簡(jiǎn)單的開(kāi)放協(xié)議的實(shí)現(xiàn)，tcp是個(gè)好選擇。

3 POP3/SMTP， 常見(jiàn)的郵件協(xié)議，沒(méi)什么好說(shuō)的，反應(yīng)--應(yīng)答模式，跨平臺(tái)要求，因此tcp是個(gè)選擇,這個(gè)協(xié)議的悲劇在于，當(dāng)初沒(méi)有考慮到郵件附件會(huì)越來(lái)越大的問(wèn)題，因此它的實(shí)現(xiàn)中將附件文件采用了base64編碼格式，用文本模式進(jìn)行發(fā)送，導(dǎo)致產(chǎn)生了大量的額外流量。

4 TFTP ,這是一個(gè)非常古老的用于內(nèi)部傳輸小文件的協(xié)議,沒(méi)有FTP那么多功能,采用的是udp協(xié)議,通過(guò)在包中加入包頭信息,用盡可能簡(jiǎn)單的代碼來(lái)實(shí)現(xiàn)小文件傳輸,注意是小文件,是一個(gè)值得參考的udp改造應(yīng)用范例.

5 通常的voip,實(shí)時(shí)視頻流等,通常會(huì)采用udp協(xié)議,這是以內(nèi)這些應(yīng)用可以允許丟包,很多人可能認(rèn)為是udp的高效率所以才在這方面有廣泛應(yīng)用,這我不敢茍同,我個(gè)人認(rèn)為,之所以采用udp,是因?yàn)檫@些傳輸允許丟包,這是一個(gè)最大的前提

那么現(xiàn)在來(lái)歸納一下

[1] 如果數(shù)據(jù)要求完整,不允許任何錯(cuò)誤發(fā)生

[A] 應(yīng)用層協(xié)議開(kāi)放模式 [例如http ftp]

建議選擇tcp,幾乎是唯一選擇.

[B] 應(yīng)用曾協(xié)議封閉模式 [例如游戲]

(1) 大量連接

[a] 長(zhǎng)連接

[一] 少量數(shù)據(jù)傳輸

優(yōu)先考慮可靠udp傳輸 , tcp建議在20000連接以下使用.

[二] 大流量數(shù)據(jù)傳輸

只有在10000連接以下可以考慮tcp , 其他情況優(yōu)先使用udp可靠傳輸

[b] 短連接

[一] 少量數(shù)據(jù)傳輸

建議使用udp標(biāo)準(zhǔn)模式, 加入序列號(hào), 如果連接上限不超2萬(wàn),可以考慮tcp

[二] 大流量數(shù)據(jù)傳輸

10000連接以下考慮tcp ,其他情況使用udp可靠傳輸

在遇到海量連接的情況下,建議優(yōu)先考慮udp可靠傳輸,使用tcp,由于tcp/ip棧的鏈表實(shí)現(xiàn)的影響,連接越多,性能下降越快,而udp可以實(shí)現(xiàn)隊(duì)列,是一條平滑的直線,幾乎沒(méi)有性能影響.

(2) 有限連接 [通常小于2000 , 一般每服務(wù)器為幾百到1000左右]

[a] 長(zhǎng)連接

除非有數(shù)據(jù)的實(shí)時(shí)性要求,優(yōu)先考慮tcp,否則使用udp可靠傳輸.

[b] 短連接

優(yōu)先考慮tcp.

在有限連接的情況下,使用tcp可以減少代碼的復(fù)雜性,增加廣泛的移植性,并且不需要考慮性能問(wèn)題.

[2] 允許丟包,甚至可以亂序

[a] 對(duì)實(shí)時(shí)性要求比較高,例如voip , 那么udp是最優(yōu)選擇.

[b] 部分?jǐn)?shù)據(jù)允許丟包,部分?jǐn)?shù)據(jù)要求完整,部分有實(shí)時(shí)性要求,通常這樣的需求是出現(xiàn)在游戲里, 這時(shí)候, 基于udp協(xié)議改造的udp多路可靠傳輸[同時(shí)支持不可靠模式],基本是唯一能滿足的,當(dāng)然也可以使用tcp來(lái)傳輸要求完整的數(shù)據(jù),但是通常不建議,因?yàn)橥瑫r(shí)使用tcp和udp傳輸數(shù)據(jù),會(huì)導(dǎo)致代碼臃腫復(fù)雜度增加,udp可靠傳輸完全可以替代tcp.

[c]部分?jǐn)?shù)據(jù)優(yōu)先傳輸,部分可丟棄數(shù)據(jù)在規(guī)定時(shí)效內(nèi)傳輸, 這通常是實(shí)時(shí)視頻流, 在有限連接模式下,可以考慮tcp+udp , 但是通常, 可靠udp傳輸是最好的選擇.

最后的話, tcp/ip協(xié)議很偉大, 在這些基礎(chǔ)上誕生了很多劃時(shí)代的應(yīng)用,但是時(shí)代在發(fā)展,需求也在改變,幾十年前誕生的基礎(chǔ)協(xié)議,也遇到了各種問(wèn)題,典型的是32位地址編碼問(wèn)題,雖然通過(guò)nat等技術(shù)盡可能的支持更多的機(jī)器接入,但是很多應(yīng)用被限制了,由于tcp/ip協(xié)議的巨大影響和事實(shí)的上的壟斷,導(dǎo)致后續(xù)的更新必須考慮到完全兼容, ipv6出現(xiàn)了, 它繼承了ipv4的幾乎所有優(yōu)點(diǎn)和缺點(diǎn),只為了一個(gè)字,兼容. 我們可以擁有更快的cpu , 內(nèi)存, 更強(qiáng)大的tcp/ip系統(tǒng)調(diào)用api,但是比較遺憾,tcp/ip協(xié)議棧的實(shí)現(xiàn),我們始終無(wú)法繞開(kāi)指針鏈表, 而正是這,導(dǎo)致了tcp模式在面對(duì)海量連接的時(shí)候,超過(guò)一定數(shù)量,網(wǎng)絡(luò)io性能直線下降, 許許多多的工程師始終認(rèn)為是cpu 內(nèi)存不夠?qū)е?卻沒(méi)有想到是tcp協(xié)議棧的實(shí)現(xiàn)上存在性能瓶頸. 在目前的情況下,也只有udp能避開(kāi)這個(gè)協(xié)議棧的性能瓶頸,為什么? 因?yàn)閡dp采用的是1對(duì)多的虛擬連接, 例如,當(dāng)虛擬[或者實(shí)際]通過(guò)udp構(gòu)建的連接數(shù)量是1萬(wàn)個(gè)的時(shí)候,實(shí)際上在協(xié)議棧增加的單元只有1個(gè), 而同樣1萬(wàn)個(gè)連接,tcp增加的單元是1萬(wàn)個(gè),每個(gè)片的到達(dá)平均要查詢5千次,而可靠udp采用隊(duì)列模式,查詢次數(shù)是1, 因此, 在今天, 如果你希望你的每臺(tái)服務(wù)器能支持更多的連接,除非你的應(yīng)用協(xié)議需要開(kāi)放或者兼容其他應(yīng)用,否則盡可能考慮采用udp, 而不是tcp.

TCP 與 UDP 的區(qū)別及應(yīng)用場(chǎng)景

概述 兩者都是通信協(xié)議， TCP、UDP 是傳輸層協(xié)議，但他們的通信機(jī)制與應(yīng)用場(chǎng)景不同，下面來(lái)闡述兩者的區(qū)別以及它們的應(yīng)用場(chǎng)景。

TCP 與 UDP TCP（Transmission Control Protocol），又叫傳輸控制協(xié)議，UDP（User Datagram Protocol），又叫用戶數(shù)據(jù)報(bào)協(xié)議，它們都是傳輸層的協(xié)議，但兩者的機(jī)制不同，它們的區(qū)別如下：

特點(diǎn) TCP UDP 連接性 面向連接 面向非連接 可靠性 可靠 不可靠 傳輸效率 慢 快

TCP 從如上表格看到，TCP 是面向連接的，并且是一種可靠的協(xié)議，在基于 TCP 進(jìn)行通信時(shí)，通信雙方需要先建立一個(gè) TCP 連接，建立連接需要經(jīng)過(guò)三次握手，握手成功才可以進(jìn)行通信，關(guān)于 TCP 三次握手、四次揮手的過(guò)程請(qǐng)看該文章。 另外 TCP 協(xié)議是一種可靠的傳輸協(xié)議，那么它是如何保證可靠性的呢？

可靠性 在講解 TCP 如何保證可靠性前，首先得理解什么是可靠。在通信的角度來(lái)看，可靠即要確保通信雙方的通信信息不會(huì)丟失，若丟失了保證能夠?qū)ζ溥M(jìn)行恢復(fù)，并且收到的信息內(nèi)容與原發(fā)送內(nèi)容一樣。 在 TCP 中，傳輸報(bào)文都是通過(guò)建立的虛擬連接來(lái)進(jìn)行傳輸，發(fā)送端傳輸?shù)拿恳粋€(gè) TCP 報(bào)文，都會(huì)對(duì)其進(jìn)行編號(hào)（編號(hào)是由于網(wǎng)絡(luò)傳輸?shù)脑?，發(fā)送的報(bào)文可能會(huì)亂序到達(dá)，因此需要根據(jù)編號(hào)對(duì)報(bào)文進(jìn)行重排），并且開(kāi)啟一個(gè)計(jì)時(shí)器；當(dāng)接收端收到報(bào)文后，并且通過(guò)校驗(yàn)和對(duì)收到的報(bào)文數(shù)據(jù)進(jìn)行校驗(yàn)，若校驗(yàn)成功則會(huì)返回一個(gè)確認(rèn)報(bào)文，告知發(fā)送端我已經(jīng)成功收到該報(bào)文了；若發(fā)送端在計(jì)時(shí)器結(jié)束前仍未收到確認(rèn)報(bào)文，則認(rèn)為接收端接收失敗，則會(huì)重傳該報(bào)文；服務(wù)端若收到重復(fù)報(bào)文（根據(jù)編號(hào)發(fā)現(xiàn)已經(jīng)是收到了），則會(huì)將該報(bào)文丟棄。 因此，從上面的機(jī)制可以知道，TCP 是通過(guò)重傳、確認(rèn)和校驗(yàn)和的方式來(lái)確?？煽?。 注：校驗(yàn)和并不能檢驗(yàn)數(shù)據(jù)是否被篡改過(guò)，想要保證數(shù)據(jù)的完整性可以了解一下數(shù)字簽名

UDP UDP 是一種面向無(wú)連接，且不可靠的協(xié)議，在通信過(guò)程中，它并不像 TCP 那樣需要先建立一個(gè)連接，只要（目的地址，端口號(hào)，源地址，端口號(hào)）確定了，就可以直接發(fā)送信息報(bào)文，并且不需要確保服務(wù)端一定能收到或收到完整的數(shù)據(jù)。它僅僅提供了校驗(yàn)和機(jī)制來(lái)保障一個(gè)報(bào)文是否完整，若校驗(yàn)失敗，則直接丟棄報(bào)文，不做任何處理。

TCP 與 UDP 的應(yīng)用場(chǎng)景 從特點(diǎn)上我們已經(jīng)知道，TCP 是可靠的但傳輸速度慢 ，UDP 是不可靠的但傳輸速度快。因此在選用具體協(xié)議通信時(shí)，應(yīng)該根據(jù)通信數(shù)據(jù)的要求而決定。 若通信數(shù)據(jù)完整性需讓位與通信實(shí)時(shí)性，則應(yīng)該選用 TCP 協(xié)議（如文件傳輸、重要狀態(tài)的更新等）；反之，則使用 UDP 協(xié)議（如視頻傳輸、實(shí)時(shí)通信等）。

一般面試官都會(huì)問(wèn)TCP和UDP的區(qū)別，這個(gè)很好回答啊，TCP面向連接，可靠，基于字節(jié)流，而UDP不面向連接，不可靠，基于數(shù)據(jù)報(bào)。對(duì)于連接而言呢，其實(shí)真正的就不存在，TCP面向連接只不過(guò)三次握手在客戶端和服務(wù)端之間初始化好了序列號(hào)。只要滿足TCP的四元組+序列號(hào)，那客戶端和服務(wù)端之間發(fā)送的消息就有效，可以正常接收。雖然說(shuō)TCP可靠，但是可靠的背后卻是lol無(wú)盡之刃的復(fù)雜和痛苦，滑動(dòng)窗口，擁塞避免，四個(gè)超時(shí)定時(shí)器，還有什么慢啟動(dòng)啊，快恢復(fù)，快重傳啊這里推薦大家看看（圖解TCP/IP,這個(gè)簡(jiǎn)單容易，TCP卷123，大量的文字描述真是煩），所以什么都是相對(duì)呢，可靠性的實(shí)現(xiàn)也讓TCP變的復(fù)雜，在網(wǎng)絡(luò)的狀況很差的時(shí)候，TCP的優(yōu)勢(shì)會(huì)變成?；谧止?jié)流什么意思呢？一句話就可以說(shuō)明白，對(duì)于讀寫沒(méi)有相對(duì)應(yīng)的次數(shù)。UDP基于數(shù)據(jù)報(bào)就是每對(duì)應(yīng)一個(gè)發(fā)，就要對(duì)應(yīng)一個(gè)收。而TCP無(wú)所謂啊，現(xiàn)在應(yīng)該懂了吧。對(duì)于UDP而言，不面向連接，不可靠，沒(méi)有三次握手，我給你發(fā)送數(shù)據(jù)之前，不需要知道你在不在，不要你的同意，我只管把數(shù)據(jù)發(fā)送出去至于你收到不收到，從來(lái)和我沒(méi)有半毛錢的關(guān)系。

對(duì)于可靠不可靠而言，沒(méi)有絕對(duì)的說(shuō)法，TCP可靠?jī)H僅是在傳輸層實(shí)現(xiàn)了可靠，我也可以讓UDP可靠啊，那么就要向上封裝，在應(yīng)該層實(shí)現(xiàn)可靠性。因此很多公司都不是直接用TCP和UDP，都是經(jīng)過(guò)封裝，滿足業(yè)務(wù)的需要而已。說(shuō)到這里的話，那就在提一下心跳包，在linux下有keep-alive系統(tǒng)自帶的，但是默認(rèn)時(shí)間很長(zhǎng)，如果讓想使用話可以setsockopt設(shè)置，我也可以在應(yīng)用層實(shí)現(xiàn)一個(gè)簡(jiǎn)單心跳包，上次自己多開(kāi)了一個(gè)線程來(lái)處理，還是包頭解決。