70、TCP協議的三次握手與四次揮手
70.1、TCP報文結構
1、源端口號：表示發送端端口號，字段長為16位。
2、目標端口號：表示接收端口號，字段長為16位。
3、序列號：表示發送數據的位置，字段長為32位。每發送一次數據，就累加一次該數據字節數的大小。
注意：序列號不會從0或1開始，而是在建立連接時由計算機生成的一個隨機數作為其初始值，通過SYN包發送給接收端主機。然后再將每次轉發過去的字節數累加到初始值上表示數據的位置。
4、確認應答號：表示下一次應該收到的數據的序列號，字段長為32字節。發送端收到這個確認應答以后可以認為在這個序號以前的數據都已經被正常接收。
序號的優點：
（1）保證報文按序到達。
（2）保證可靠性。
（3）保證效率。
（4）精准的報告哪些報文已經收到，哪些需要重傳。
5、首部長度：該字段長度為4位，單位為4字節（32位）。TCP首部長度不包括選項的話，是20個字節，20/4=5，5的二進制序列：0101，報頭長度也叫數據偏移，所以該字段可以設置為5，選項字段最大的是40字節，所以，TCP首部長度為最大為20+40=60字節，該字段可以設置的最大長度為60/4=15。
6、保留：該字段主要是為了以后擴展時使用，其長度為4位。一般設置為0，即使收到的包在該字段不為0，此包也不會丟棄。
7、控制位：字段長為6，每一位從左到右分別為：URG、ACK、PSH、RST、SYN、FIN。當對應的值為1，表示有具體含義。
字段 含義
URG 緊急指針是否有效。為1，表示某一位需要被優先處理。
ACK 確認號是否有效，一般置為1。
PSH 提示接收端應用程序立即從TCP緩沖區把數據讀走。
RST 對方要求重新建立連接，復位。
SYN 請求建立連接，並在其序列號的字段進行序列號的初始值設定。建立連接，設置為1。
FIN 希望斷開連接。
8、窗口大小：接收緩沖區的大小，TCP不允許發送超過此處所示大小的數據。
9、校驗和：發送端填充，CRC校驗，接收校驗不通過，則認為數據有問題。和UDP的區別是，UDP校驗的是數據本身，TCP校驗的不僅包含TCP首部，而且包含TCP數據部分。
10、緊急指針：只有在URG為1時有效，該字段為1表示本報文的段中的緊急數據的指針。
11、選項：用於提高TCP的傳輸性能。需要根據首部長度進行控制，其最大長度為40字節。
70.2、TCP三次握手以及四次揮手用到的字段
1、序列號seq
占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生，給字節編上序號后，就給每一個報文段指派一個序號，序列號seq就是這個報文段中的第一個字節的數據編號。
2、確認號ack
占4個字節，期待收到對方下一個報文段的第一個數據字節的序號，序列號表示報文段攜帶數據的第一個字節的編號，而確認號指的是期望接受到下一個字節的編號，因此當前報文段最后一個字節的編號+1即是確認號。
3、確認ACK
占1個比特位，僅當ACK=1，確認號字段才有效。ACK=0，確認號無效。
4、同步SYN
連接建立時用於同步序號。當SYN=1，ACK=0表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使用SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接收報文，SYN這個標志位只有在TCP建立連接才會被置為1，握手完成后SYN標志位被置為0。
5、終止FIN
用來釋放一個連接。
70.3、TCP三次握手
step1:第一次握手
建立連接時，客戶端發送SYN包到服務器，其中包含客戶端的初始序號seq=x，並進入SYN_SENT狀態，等待服務器確認。（其中，SYN=1，ACK=0，表示這是一個TCP連接請求數據報文；序號seq=x，表明傳輸數據時的第一個數據字節的序號是x）。
step2:第二次握手
服務器收到請求后，必須確認客戶的數據包。同時自己也發送一個SYN包，即SYN+ACK包，此時服務器進入SYN_RECV狀態。（其中確認報文段中，標識位SYN=1，ACK=1，表示這是一個TCP連接響應數據報文，並含服務端的初始序號seq(服務器)=y，以及服務器對客戶端初始序號的確認號ack(服務器)=seq(客戶端)+1=x+1）。
step3:第三次握手
客戶端收到服務器的SYN+ACK包，向服務器發送一個序列號(seq=x+1)，確認號為ack(客戶端)=y+1，此包發送完畢，客戶端和服務器進入ESTAB_LISHED(TCP連接成功)狀態，完成三次握手。
未連接隊列
在三次握手協議中，服務器維護一個未連接隊列，該隊列為每個客戶端的SYN包(syn=j)開設一個條目，該條目表明服務器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包時，刪除該條目，服務器進入ESTAB_LISHED狀態。
70.4、四次揮手過程（關閉客戶端到服務器的連接）
step1：第一次揮手
首先，客戶端發送一個FIN，用來關閉客戶端到服務器的數據傳送，然后等待服務器的確認。其中終止標志位FIN=1，序列號seq=u。
step2：第二次揮手
服務器收到這個FIN，它發送一個ACK，確認ack為收到的序號加一。
step3：第三次揮手
關閉服務器到客戶端的連接，發送一個FIN給客戶端。
step4：第四次揮手
客戶端收到FIN后，並發回一個ACK報文確認，並將確認序號seq設置為收到序號加一。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
客戶端發送FIN后，進入終止等待狀態，服務器收到客戶端連接釋放報文段后，就立即給客戶端發送確認，服務器就進入CLOSE_WAIT狀態，此時TCP服務器進程就通知高層應用進程，因而從客戶端到服務器的連接就釋放了。此時是“半關閉狀態”，即客戶端不可以發送給服務器，服務器可以發送給客戶端。
此時，如果服務器沒有數據報發送給客戶端，其應用程序就通知TCP釋放連接，然后發送給客戶端連接釋放數據報，並等待確認。客戶端發送確認后，進入TIME_WAIT狀態，但是此時TCP連接還沒有釋放，然后經過等待計時器設置的2MSL（2倍報文最大生存時間）后，才進入到CLOSE狀態。
【注意】中斷連接端可以是 Client 端，也可以是 Server 端。
假設 Client 端發起中斷連接請求，也就是發送 FIN 報文。Server 端接到 FIN 報文后，意思是說"我 Client 端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急着關閉 Socket，可以繼續發送數據。所以你先發送 ACK，“告訴 Client 端，你的請求我收到了，但是我還沒准備好，請繼續你等我的消息”。這個時候 Client 端就進入FIN_WAIT 狀態，繼續等待 Server 端的 FIN 報文。當 Server 端確定數據已發送完成，則向 Client 端發送 FIN 報文，“告訴 Client 端，好了，我這邊數據發完了，准備好關閉連接了”。Client 端收到 FIN 報文后，“就知道可以關閉連接了，但是他還是不相信網絡，怕 Server 端不知道要關閉，所以發送 ACK 后進入 TIME_WAIT 狀態，如果 Server端沒有收到 ACK 則可以重傳。”Server 端收到 ACK 后，“就知道可以斷開連接了”。Client端等待了 2MSL 后依然沒有收到回復，則證明 Server 端已正常關閉，那好，我 Client 端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
70.5、為什么需要三次握手，兩次不可以嗎？或者四次、五次可以嗎？
我們來分析一種特殊情況，假設客戶端請求建立連接，發給服務器SYN包等待服務器確認，服務器收到確認后，如果是兩次握手，假設服務器給客戶端在第二次握手時發送數據，數據從服務器發出，服務器認為連接已經建立，但在發送數據的過程中數據丟失，客戶端認為連接沒有建立，會進行重傳。假設每次發送的數據一直在丟失，客戶端一直SYN，服務器就會產生多個無效連接，占用資源，這個時候服務器可能會掛掉。這個現象就是我們聽過的“SYN的洪水攻擊”。
總結：第三次握手是為了防止：如果客戶端遲遲沒有收到服務器返回確認報文，這時會放棄連接，重新啟動一條連接請求，但問題是：服務器不知道客戶端沒有收到，所以他會收到兩個連接，浪費連接開銷。如果每次都是這樣，就會浪費多個連接開銷。
也是為了防止失效的連接請求報文段突然又傳送到服務器，因而產生錯誤。
70.6、為什么是四次揮手，而不是三次或是五次、六次？
確保數據能夠完成傳輸。
關閉連接時，當收到對方的 FIN 報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉 SOCKET，也即你可能還需要發送一些數據給對方之后，再發送 FIN 報文給對方來表示你同意現在可以關閉連接了，所以它這里的 ACK 報文和FIN 報文多數情況下都是分開發送的。
TCP 協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP 是全雙工模式，這就意味着，當主機 1 發出 FIN 報文段時，只是表示主機 1 已經沒有數據要發送了，主機 1 告訴主機 2，它的數據已經全部發送完畢了；但是，這個時候主機 1 還是可以接受來自主機 2 的數據；當主機 2 返回 ACK 報文段時，表示它已經知道主機 1 沒有數據發送了，但是主機 2 還是可以發送數據到主機 1 的；當主機 2 也發送了 FIN 報文段時，這個時候就表示主機 2 也沒有數據要發送了，就會告訴主機 1，我也沒有數據要發送了，之后彼此就會愉快的中斷這次 TCP 連接。
70.7、time_wait 狀態產生的原因？
1）、可靠地實現 TCP 全雙工連接的終止
我們必須要假想網絡是不可靠的，你無法保證你最后發送的 ACK 報文會一定被對方收到，因此對方處於 LAST_ACK 狀態下的 SOCKET 可能會因為超時未收到 ACK 報文，而重發 FIN報文，client 必須維護這條連接的狀態（保持 time_wait，具體而言，就是這條TCP 連接對應的（local_ip, local_port）資源不能被立即釋放或重新分配）以便可以重發丟失的 ACK，如果主動關閉端不維持 TIME_WAIT 狀態，而是處於 CLOSED 狀態，主動關閉端將會響應一個 RST，結果 server 認為發生錯誤，導致服務器端不能正常關閉連接。**所以這個TIME_WAIT 狀態的作用就是用來重發可能丟失的 ACK 報文。**所以，當客戶端等待 2MSL（2倍報文最大生存時間）后，沒有收到服務端的 FIN 報文后，他就知道服務端已收到了 ACK報文，所以客戶端此時才關閉自己的連接。
2）、允許老的重復分節在網絡中消逝
2MSL可以使本連接持續的時間內所有所產生的報文段都從網絡中消失。這樣就可以使下一個新的連接中不會出現舊的連接的請求報文段。
如果 TIME_WAIT 狀態保持時間不足夠長 (比如小於2MSL)，第一個連接就正常終止了。第二個擁有相同四元組(local_ip, local_port, remote_ip,remote_port)的連接出現（建立起一個相同的 IP 地址和端口之間的 TCP 連接），而第一個連接的重復報文到達，干擾了第二個連接。TCP 實現必須防止某個連接的重復報文在連接終止后出現，所以讓TIME_WAIT 狀態保持時間足夠長 (2MSL)，連接相應方向上的 TCP 報文要么完全響應完畢，要么被丟棄。建立第二個連接的時候，不會混淆。
70.8、如果網絡連接中出現大量 TIME_WAIT 狀態所帶來的危害？
如果系統中有很多 socket 處於 TIME_WAIT 狀態，當需要創建新的 socket 連接的時候可能會受到影響，這也會影響到系統的擴展性。
之所以 TIME_WAIT 能夠影響系統的擴展性是因為在一個 TCP 連接中，一個 Socket如果關閉的話，它將保持 TIME_WAIT 狀態大約 1-4分鍾。如果很多連接快速的打開和關閉的話，系統中處於 TIME_WAIT 狀態的 socket 將會積累很多，由於本地端口數量的限制，同一時間只有有限數量的 socket 連接可以建立，如果太多的socket 處於TIME_WAIT狀態，你會發現，由於用於新建連接的本地端口太缺乏，將會很難再建立新的對外連接。
70.9、TCP如何保證傳輸的可靠性？
0、在傳遞數據之前，會有三次握手來建立連接。
1、應用數據被分割成 TCP 認為最適合發送的數據塊（按字節編號，合理分片）。這和UDP完全不同，應用程序產生的數據報長度將保持不變。(將數據截斷為合理的長度)
2、當 TCP 發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。(超時重發)
3、當 TCP 收到發自 TCP 連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒 。(對於收到的請求，給出確認響應) (之所以推遲，可能是要對包做完整校驗)。
4、TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。(校驗出包有錯，丟棄報文段，不給出響應，TCP 發送數據端，超時時會重發數據)
5、既然 TCP 報文段作為 IP 數據報來傳輸，而 IP 數據報的到達可能會失序，因此TCP 報文段的到達也可能會失序。如果必要，TCP 將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。(對失序數據進行重新排序，然后才交給應用層)
6、既然 IP 數據報會發生重復，TCP 的接收端必須丟棄重復的數據。(對於重復數據，能夠丟棄重復數據)
7、TCP 還能提供流量控制。TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發送接收端緩沖區所能接納的數據。這將防止較快主機致使較慢主機的緩沖區溢出。(TCP 可以進行流量控制，防止較快主機致使較慢主機的緩沖區溢出) TCP 使用的流量控制協議是可變大小的滑動窗口協議。
8、TCP 還能提供擁塞控制。當網絡擁塞時，減少數據的發送。
70.10、TCP 建立連接之后怎么保持連接（檢測連接斷沒斷）？
有兩種技術可以運用。一種是由 TCP 協議層實現的 Keepalive 機制，另一種是由應用層自己實現的 HeartBeat 心跳包。
1、在 TCP 中有一個 Keep-alive 的機制可以檢測死連接，原理很簡單，當連接閑置一定的時間（參數值可以設置，默認是 2 小時）之后，TCP 協議會向對方發一個 keepalive探針包（包內沒有數據），對方在收到包以后，如果連接一切正常，應該回復一個 ACK；如果連接出現錯誤了（例如對方重啟了，連接狀態丟失），則應當回復一個 RST；如果對方沒有回復，那么，服務器每隔一定的時間（參數值可以設置）再發送 keepalive 探針包，如果連續多個包（參數值可以設置）都被無視了，說明連接被斷開了。
2、心跳包之所以叫心跳包是因為：它像心跳一樣每隔固定時間發一次，以此來告訴服務器，這個客戶端還活着。事實上這是為了保持長連接，至於這個包的內容，是沒有什么特別規定的，不過一般都是很小的包，或者只包含包頭的一個空包。由應用程序自己發送心跳包來檢測連接的健康性。客戶端可以在一個 Timer 中或低級別的線程中定時向服務器發送一個短小精悍的包，並等待服務器的回應。客戶端程序在一定時間內沒有收到服務器回應即認為連接不可用，同樣，服務器在一定時間內沒有收到客戶端的心跳包則認為客戶端已經掉線。
71、TCP流量控制(滑動窗口機制)
滑動窗口協議的基本原理就是在任意時刻，發送方都維持了一個連續的允許發送的幀的序號，稱為發送窗口；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收窗口。發送窗口和接收窗口的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動窗口協議窗口大小一般不同。
所謂滑動窗口協議，自己理解有兩點：1）、“窗口”對應的是一段可以被發送者發送的字節序列，其連續的范圍稱之為“窗口”；2）、“滑動”則是指這段“允許發送的范圍”是可以隨着發送的過程而變化的，方式就是按順序“滑動”。在此之前要先了解以下前提：
1、TCP 協議的兩端分別為發送者 A 和接收者 B，由於是全雙工協議，因此 A 和 B 應該分別維護着一個獨立的發送緩沖區和接收緩沖區，由於對等性（A發B收 和 B發A收），我們以 A 發送 B 接收的情況作為例子；
2、發送窗口是發送緩存中的一部分，是可以被 TCP 協議發送的那部分，其實應用層需要發送的所有數據都被放進了發送者的發送緩沖區；
3、發送窗口中相關的有四個概念：已發送並收到確認的數據（不在發送窗口和發送緩沖區之內）、已發送但未收到確認的數據（位於發送窗口之中）、允許發送但尚未發送的數據以及發送窗口外發送緩沖區內暫時不允許發送的數據；
4、每次成功發送數據之后，發送窗口就會在發送緩沖區中按順序移動，將新的數據包含到窗口中准備發送；
71.1、流量控制
流量控制方面主要有兩個要點需要掌握。一是TCP利用滑動窗口實現流量控制的機制；二是如何考慮流量控制中的傳輸效率。
1、流量控制
所謂流量控制，主要是接收方傳遞信息給發送方，使其不要發送數據太快，是一種端到端的控制。主要的方式就是返回的ACK中會包含自己的接收窗口的大小，並且利用大小來控制發送方的數據發送：
這里面涉及到一種情況，如果B已經告訴A自己的緩沖區已滿，於是A停止發送數據；等待一段時間后，B的緩沖區出現了富余，於是給A發送報文告訴A我的rwnd大小為400，但是這個報文不幸丟失了，於是就出現A等待B的通知||B等待A發送數據的死鎖狀態。為了處理這種問題，TCP引入了持續計時器（Persistence timer），當A收到對方的零窗口通知時，就啟用該計時器，時間到則發送一個1字節的探測報文，對方會在此時回應自身的接收窗口大小，如果結果仍為0，則重設持續計時器，繼續等待。
2、傳遞效率
一個顯而易見的問題是：單個發送字節單個確認，和窗口有一個空余即通知發送方發送一個字節，無疑增加了網絡中的許多不必要的報文（請想想為了一個字節數據而添加的40字節頭部吧！），所以我們的原則是盡可能一次多發送幾個字節，或者窗口空余較多的時候通知發送方一次發送多個字節。對於前者我們廣泛使用Nagle算法，即：
1）、若發送應用進程要把發送的數據逐個字節地送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把后面的字節先緩存起來；
2）、當發送方收到第一個字節的確認后（也得到了網絡情況和對方的接收窗口大小），再把緩沖區的剩余字節組成合適大小的報文發送出去；
3）、當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段；
對於后者我們往往的做法是讓接收方等待一段時間，或者接收方獲得足夠的空間容納一個報文段或者等到接受緩存有一半空閑的時候，再通知發送方發送數據。
71.2、擁塞控制
網絡中的鏈路容量和交換結點中的緩存和處理機都有着工作的極限，當網絡的需求超過它們的工作極限時，就出現了擁塞。擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。常用的方法就是：
1、慢開始、擁塞控制；
2、快重傳、快恢復；
一切的基礎還是慢開始，這種方法的思路是這樣的：
1）、發送方維持一個叫做“擁塞窗口”的變量，該變量和接收端口共同決定了發送者的發送窗口；
2）、當主機開始發送數據時，避免一下子將大量字節注入到網絡，造成或者增加擁塞，選擇發送一個1字節的試探報文；
3）、當收到第一個字節的數據的確認后，就發送2個字節的報文；
4）、若再次收到2個字節的確認，則發送4個字節，依次遞增2的指數級；
5）、最后會達到一個提前預設的“慢開始門限”，比如24，即一次發送了24個分組，此時遵循下面的條件判定：
*1、cwnd < ssthresh，繼續使用慢開始算法；
*2、cwnd > ssthresh，停止使用慢開始算法，改用擁塞避免算法；
*3、cwnd = ssthresh，既可以使用慢開始算法，也可以使用擁塞避免算法；
6）、所謂擁塞避免算法就是：每經過一個往返時間RTT就把發送方的擁塞窗口+1，即讓擁塞窗口緩慢地增大，按照線性規律增長；
7）、當出現網絡擁塞，比如丟包時，將慢開始門限設為原先的一半，然后將cwnd設為1，執行慢開始算法（較低的起點，指數級增長）；
上述方法的目的是在擁塞發生時循序減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠的時間把隊列中積壓的分組處理完畢。慢開始和擁塞控制算法常常作為一個整體使用，而快重傳和快恢復則是為了減少因為擁塞導致的數據包丟失帶來的重傳時間，從而避免傳遞無用的數據到網絡。快重傳的機制是：
1）、接收方建立這樣的機制，如果一個包丟失，則對后續的包繼續發送針對該包的重傳請求；
2）、一旦發送方接收到三個一樣的確認，就知道該包之后出現了錯誤，立刻重傳該包；
3）、此時發送方開始執行“快恢復”算法：
*1、慢開始門限減半；
*2、cwnd設為慢開始門限減半后的數值；
*3、執行擁塞避免算法（高起點，線性增長）；
TCP 滑動窗口協議，窗口過大或過小有什么影響？
滑動窗口的大小對網絡性能有很大的影響。
如果滑動窗口過小，極端的情況就是停止等待協議，發一個報文等一個 ACK，會造成通信效率下降。
如果滑動窗口過大，網絡容易擁塞，容易造成接收端的緩存不夠而溢出，容易產生丟包現象，則需要多次發送重復的數據，耗費了網絡帶寬。
72、TCP與UDP的對比
TCP、UDP 都是傳輸層協議，他們的通信機制與應用場景不同。
TCP（Transmission Control Protocol），又叫傳輸控制協議，UDP（User Datagram Protocol），又叫用戶數據報協議，它們都是傳輸層的協議，但兩者的機制不同，它們的區別如下：
特點 TCP UDP
連接性 面向連接 面向非連接
可靠性 可靠 不可靠
傳輸效率 慢 快
TCP的優點：可靠，穩定。TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完后，還會斷開連接用來節約系統資源。TCP的缺點：慢，效率低，占用系統資源高，易被攻擊。TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接，事實上，每個連接都會占用系統的CPU、內存等硬件資源。而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
UDP的優點：快，比TCP稍安全。UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……；UDP的缺點：不可靠，不穩定，因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。
基於上面的優缺點，那么： 什么時候應該使用TCP： 當對網絡通訊質量有要求的時候，比如：整個數據要准確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸…………；什么時候應該使用UDP：當對網絡通訊質量要求不高的時候，要求網絡通訊速度能盡量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下：QQ語音、QQ視頻、TFTP ……。
TCP與UDP區別總結：
1、TCP面向連接（如打電話要先撥號建立連接）；UDP是無連接的，即發送數據之前不需要建立連接；
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達；UDP盡最大努力交付，即不保證可靠交付；
3、TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流；UDP是面向報文的，UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）；
4、每一條TCP連接只能是點到點的；UDP支持一對一，一對多，多對一和多對多的交互通信；
5、TCP首部開銷20字節；UDP的首部開銷小，只有8個字節；
6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道；
72.1、可靠性補充
在通信的角度來看，可靠即要確保通信雙方的通信信息不會丟失，若丟失了保證能夠對其進行恢復，並且收到的信息內容與原發送內容一樣。
在 TCP 中，傳輸報文都是通過建立的虛擬連接來進行傳輸，發送端傳輸的每一個 TCP報文，都會對其進行編號（編號是由於網絡傳輸的原因，發送的報文可能會亂序到達，因此需要根據編號對報文進行重排），並且開啟一個計時器；當接收端收到報文后，並且通過校驗和對收到的報文數據進行校驗，若校驗成功則會返回一個確認報文，告知發送端我已經成功收到該報文了；若發送端在計時器結束前仍未收到確認報文，則認為接收端接收失敗，則會重傳該報文；服務端若收到重復報文（根據編號發現已經是收到了），則會將該報文丟棄。
UDP不需要確保服務端一定能收到或收到完整的數據。它僅僅提供了校驗和機制來保障一個報文是否完整，若校驗失敗，則直接丟棄報文，不做任何處理。
基於TCP協議的應用層協議：http、ftp、telnet、smtp；
基於UDP協議的應用層協議：dns、rip、tftp；
————————————————
版權聲明：本文為CSDN博主「知行流浪」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zengxiantao1994/article/details/94634110