TCP與UDP基本區別

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

UDP應用場景：

1. 面向數據報方式
2. 網絡數據大多為短消息
3. 擁有大量Client
4. 對數據安全性無特殊要求
5. 網絡負擔非常重，但對響應速度要求高

TCP報頭

UDP報頭

TCP三次握手

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

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

一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。

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

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

TCP四次揮手

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

2.服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，并且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。

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

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

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

5.服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

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

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設置不同的MSL值。

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

第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

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

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

如果已經建立了連接，但是客戶端突然出現故障了怎么辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

總的來說 TCP協議提供可靠的服務， UDP協議提供高效率的服務。

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

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

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

而UDP提供的是非面向連接的、不可靠的數據流傳輸。當一個UDP數據包在網絡中移動時， 發送過程并不知道它是否到達了目的地，除非應用層已經確認了它已到達的事實。 當數據傳輸的性能必須讓位于數據傳輸的 完整性、 可控制性 可靠性時， TCP協議是當然的選擇。 當強調傳輸性能而不是傳輸的完整性時， 如：音頻和多媒體應用， UDP是最好的選擇。 在數據傳輸時間很短，以至于此前的連接過程成為整個流量主體的情況下 UDP也是一個好的選擇 ，如：DNS交換。把SNMP建立在UDP上的部分原因是設計者認為當發生網絡阻塞時， UDP較低的開銷使其有更好的機會去傳送管理數據。

總結

tcp 提供可靠的服務 若強調 完整性 可靠性可控性 選擇tcp

udp 提供高效的服務 若強調 傳輸性能 選擇udp

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

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

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

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

ip層的接收

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

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

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

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

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

那么如何選擇tcp還是udp?

先看下人家怎么選

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

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

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

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

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

那么現在來歸納一下

[1] 如果數據要求完整,不允許任何錯誤發生

[A] 應用層協議開放模式 [例如http ftp]

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

[B] 應用曾協議封閉模式 [例如游戲]

(1) 大量連接

[a] 長連接

[一] 少量數據傳輸

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

[二] 大流量數據傳輸

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

[b] 短連接

[一] 少量數據傳輸

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

[二] 大流量數據傳輸

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

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

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

[a] 長連接

除非有數據的實時性要求,優先考慮tcp,否則使用udp可靠傳輸.

[b] 短連接

優先考慮tcp.

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

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

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

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

[c]部分數據優先傳輸,部分可丟棄數據在規定時效內傳輸, 這通常是實時視頻流, 在有限連接模式下,可以考慮tcp+udp , 但是通常, 可靠udp傳輸是最好的選擇.

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

TCP 與 UDP 的區別及應用場景

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

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

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

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

可靠性 在講解 TCP 如何保證可靠性前，首先得理解什么是可靠。在通信的角度來看，可靠即要確保通信雙方的通信信息不會丟失，若丟失了保證能夠對其進行恢復，并且收到的信息內容與原發送內容一樣。 在 TCP 中，傳輸報文都是通過建立的虛擬連接來進行傳輸，發送端傳輸的每一個 TCP 報文，都會對其進行編號（編號是由于網絡傳輸的原因，發送的報文可能會亂序到達，因此需要根據編號對報文進行重排），并且開啟一個計時器；當接收端收到報文后，并且通過校驗和對收到的報文數據進行校驗，若校驗成功則會返回一個確認報文，告知發送端我已經成功收到該報文了；若發送端在計時器結束前仍未收到確認報文，則認為接收端接收失敗，則會重傳該報文；服務端若收到重復報文（根據編號發現已經是收到了），則會將該報文丟棄。 因此，從上面的機制可以知道，TCP 是通過重傳、確認和校驗和的方式來確保可靠。 注：校驗和并不能檢驗數據是否被篡改過，想要保證數據的完整性可以了解一下數字簽名

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

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

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

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