TCP與UDP基本區(qū)別

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

UDP應(yīng)用場景：

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

TCP報頭

UDP報頭

TCP三次握手

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

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

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

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

如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務(wù)端接受到了那條失效報文并且回復了確認報文，但是客戶端不會再次發(fā)出確認。由于服務(wù)器收不到確認，就知道客戶端并沒有請求連接。

TCP四次揮手

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

[1] tcp和udp的區(qū)別,簡單來說, tcp是有序可靠傳輸, 而udp是不可靠亂序傳輸,但是實際上你把udp看做IP可能更準確一點,因為可以在udp基礎(chǔ)上開發(fā)出可靠udp等各種傳輸.

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

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

ip層的接收

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

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

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

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

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

那么如何選擇tcp還是udp?

先看下人家怎么選

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

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

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

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

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

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

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

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

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

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

(1) 大量連接

[a] 長連接

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

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

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

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

[b] 短連接

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

建議使用udp標準模式, 加入序列號, 如果連接上限不超2萬,可以考慮tcp

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

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

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

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

[a] 長連接

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

[b] 短連接

優(yōu)先考慮tcp.

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

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

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

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

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

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

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

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

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

特點 TCP UDP 連接性 面向連接 面向非連接 可靠性 可靠 不可靠 傳輸效率 慢 快

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

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

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

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

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

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