TCP协议和UDP协议
（注：本文部分摘自《計算機網絡 謝希仁》）
目錄
1.傳輸控制協議TCP
1.1TCP的主要特點：
1.1.1面向連接的運輸層協議
1.1.2每一條TCP連接只能有兩個端點，每一條TCP鏈接只能是點對點的（一對一）
1.1.3TCP提供可靠交付的服務
1.1.4TCP提供全雙工通信
1.1.5面向字節流
1.2與TCP有關的面試問題
2.用戶數據報協議UDP
2.1UDP協議的主要特點：
?
1.傳輸控制協議TCP
1.1TCP的主要特點：
1.1.1面向連接的運輸層協議
（1）TCP的連接
TCP的許多特性都與TCP是面向連接的這個基本特性有關，因此要對TCP的連接有更清楚的了解。
每一條TCP連接唯一地被通信兩端的兩個端點所確定，所謂的端點就是套接字（或插口）。
套接字的表示方法：在點分十進制的IP地址后面寫上端口號，例如IP地址是192.3.4.5，端口號是80，那么套接字就是（192.3.4.5：80） 。
（2）TCP的連接建立
三次握手：TCP建立連接的過程叫做握手，握手需要在客戶端和服務器之間交換三個TCP報文段。此過程如下：
（3）tcp的連接釋放
?四次揮手過程如下：
（4）tcp的有限狀態機
可以看我之前的這篇文章，這里不再贅述。
TCP連接的狀態——TIME_WAIT的存在意義https://blog.csdn.net/m0_54355780/article/details/121190546
1.1.2每一條TCP連接只能有兩個端點，每一條TCP鏈接只能是點對點的（一對一）
1.1.3TCP提供可靠交付的服務
（1）可靠傳輸的工作原理
①停止等待協議：
“停止等待”就是每發送完一個分組就停止發送，等待對方確認。在收到確認后再發送下一個分組。
- 無差錯的情況下：一端發送，另一端等待并接收
- 出現差錯的情況：一端在一段時間（會設置有超時計時器）一直沒有收到確認，認為自己剛發送的內容丟失，于是重新發送，這就叫超時重傳。這里需要注意三點：第一，發送完自己的分組需暫時保留自己的副本，以防超時重傳；第二，分組和確認分組要編號，從而確認哪些分組收到確認，哪些分組沒有收到確認；第三，超時計時器設置的重傳時間應當比數據在分組傳輸的平均往返時間長一些。
- 確認丟失和確認遲到：??
- 信道利用率?
等值等待協議的信道利用情況如下圖：
?
為了提高效率，發送方可以不使用低效率的停止等待協議，使用流水線傳輸，流水線傳輸就是發送方可以連續發送多個分組，不必每發完一個分組就停下來等待對方的確認。
②連續的ARQ協議
連續ARQ協議規定：發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。接收方采用累計確認的方式，也就是說：接收方不必對收到分組逐個發送確認，而是在收到幾個分組之后，對按序到達的最后一個分組發送確認。
（2）可靠傳輸的實現
①超時重傳時間的選擇
報文段的往返時間RTT：采用自適應算法，記錄一個報文段發出的時間，以及收到相應確認的時間。這兩個時間之差就是RTT。
平滑的往返事件RTTs：RTT的一個加權平均往返時間
上式的α值在RFC 6298推薦為0.125 。
超時重傳時間RTO：報文每重傳一次，就把超時重傳時間RTO增大一些，取新的重傳時間為舊的重傳時間的2倍。當不再發生報文段的重傳時，才根據下面的式子計算超時重傳時間。
②選擇確認SACK
如果收到的報文沒有差錯，但是未按序號，中間還缺少一些數據，使用選擇確認可以只傳送缺少的數據而不重傳已經確認到達接收方的數據。
要使用選擇確認，需在TCP首部的選項中加上“允許SACK”的選項，并且雙方必須事先商定好。
但是首部最長40字節，如果要報告5個字節塊的邊界信息，那么5個邊界需要2*5*4=40個字節來表述，再加上一個字節指明SACK選項命令一個字節指明SACK占用多少字節，這就一共需要42字節，超出首部長度。因此大多數的實現還是需要重傳全部的數據塊。
③流量控制
流量控制的目的：讓發送方的發送速率不要太快，從而讓接收方來的及接收
- 滑動窗口：在 TCP 的報頭中有一個字段叫做接收通告窗口，這個字段由接收端填充，是接收端告訴發送端自己還有多少緩沖區可以接收數據。于是發送端就可以根據這個接收端的處理能力來發送數據，而不會導致接收端處理不過來。所以發送端就會有一個發送窗口，這個發送窗 口的大小是由接收端填充的接收通告窗口的大小決定的，并且窗口的位置會隨著發送端數據 的發送和接收到接收端對數據的確認而不斷的向右滑動，將之稱為滑動窗口。（TCP的滑動窗口以字節為單位）p3-p1=A的發送窗口；p2-p1=已發送但尚未收到確認的字節數；p3-p2=允許發送但尚未發送的字節數。此外，需要注意的是，并不是發送方將數據直接發給接收方，而是發送方的應用進程把字節流寫入TCP的發送緩存，發送緩存用來暫時存放發送應用程序傳送給發送方TCP準備發送的數據以及TCP已發送出但尚未收到確認的數據。接收方的應用進程從TCP的接收緩存中讀取字節流，接收緩存用來暫時存放按序到達但尚未被接收應用程序讀取的數據以及為按序到達的數據。最后在滑動窗口的部分知識中需要注意三點：第一，同一時刻，發送方的發送端口并不總是和接收方的接收窗口一樣大，其會根據網絡擁塞情況適當減少自己的窗口值；第二，不按序到達的數據，先臨時存放在接收緩存中，等到缺少的字節收到后，再按序交付給上層的應用進程；第三，TCP接收方要有累計確認的功能。
- TCP的傳輸效率：TCP報文段的發送時機有三個控制機制：第一種，緩存中存放數據達到MSS（最大報文段長度）字節時，就組裝成一個TCP報文段發送；第二種，發送方應用進程指明要求發送報文段；第三種，發送方的一個計時期限到了，就把當前已有 緩存數據并且<=MSS裝入報文段發送出去。
④擁塞控制
- 滿開始：由小到大逐漸增大擁塞窗口數值。
- 擁塞避免：為了防止擁塞窗口增長過大引起網絡擁塞，設置慢開始門限。然后擁塞避免的算法思路就是讓擁塞窗口緩慢增大，即每經過一個往返時間RTT就把發送方的擁塞窗口加一。
- 快速重傳：接收方不要等待中積極發送數據的時候再進行對之前數據的捎帶確認，而是收到數據立即發送確認。快重傳算法規定：發送方一連收到三個重復的確認，就應當進行快重傳。
- 快速恢復：當出現超時的時候，不啟動慢開始，而是執行快恢復算法。發送方調整門限值=出現超時的cwnd(擁塞窗口)/2。
?
1.1.4TCP提供全雙工通信
1.1.5面向字節流
流式服務的特點：TCP 字節流的特點，發送端執行的寫操作次數和接收端執行的讀操作次數之間沒有任何數量關系，應用程序對數據的發送和接收是沒有邊界限制的。
1.2與TCP有關的面試問題
（1）為什么時三次握手，可不可以是兩次握手，為什么？
如果是兩次握手，那么如果出現這種情況：發送端發送請求連接報文，但是由于在網絡中出現了滯留并沒有按時到達接收端，等到一段時間發送端再次發送連接請求報文，接收端接收之后并發送確認連接。這樣兩次握手建立連接1。但是之前在網絡中滯留的連接請求報文并沒有丟失，于是發送給接收端，接收端誤以為建立連接，于是就回復確認建立連接，所以此時又建立了連接2，但是發送端并不會給連接2發送數據，所以接收端一直處于等待，就會浪費接受端許多資源。
三次握手也可以是四次握手：接收端在回復確認建立連接報文的時候，將其分成兩個報文段，一個是回復對發送端的連接確認，一個是發送自己的同步報文段。
（2）三次握手時可能出現什么攻擊？
可以參考下面這篇文章：
TCP三次握手有哪些漏洞？https://www.cnblogs.com/HuiH/p/12599048.html可能出現的攻擊有三種：SYN flood的攻擊，TCP全連接攻擊，Land攻擊。
（3）四次揮手的過程可以用三次完成嗎？
關閉連接時，服務器端收到FIN報文，并不會立刻關閉SOCKET,先回復ACK報文，等到服務器端的所有報文都發送完了，才發送FIN報文。所以不能三次完成，將ACK和FIN不能放在一起發送。
（4）對于三次握手四次揮手的面試題，可以看看這個文章
面試官，不要再問我三次握手和四次揮手https://zhuanlan.zhihu.com/p/86426969
（5）同一個端口可不可以被一個 TCP 和一個 UDP 的應用程序同時使用？
可以。原因是端口的唯一性標識是：端口號+協議名稱。所以TCP和UDP的端口完全沒有任何關系，協議內部端口號唯一。
追問：程序在連接到端口時，怎么知道此時從該端口進來的數據是tcp的還是udp的呢？
操作系統根據接收的IP數據包的首部內的8位協議來判斷這是什么報文，從而直接交給相關的內核進程或者協議棧處理。
追問：一個端口是否可以綁定多個端口號？
可以。一個進程可以打開多個文件描述符，每個文件描述符對應一個端口號，所以一個進程可以綁定多個端口號。Linux會給每個socket分配一個唯一的文件描述符，通過這個文件描述符來區分對應的套接字。
追問：一個端口號是否可以被多個進程綁定？
不可以。但是在父子進程中可以實現多進程綁定一個端口號，因為子進程具有父進程的文件描述符副本，可以處理綁定到同樣的端口上的連接
追問：一個端口可以同時連接多個TCP和多個UDP嗎？
一個端口可以建立多個TCP連接，所謂的同一個端口是指服務器端的ip和port不變，但是只要客戶端的ip和port不同就可以。一個端口同一時間只能綁定一個socket。UDP是面向無連接的，所以不存在多個UDP連接，只是服務端接收UDP數據需要綁定一個端口，一個socket只能綁定一個端口而已。
（如果還不是很清楚這方面的問題，可以參考下面幾篇文章）
TCP和UDP使用同一端口通信https://blog.csdn.net/szm1234/article/details/116994450一個端口號可以同時被兩個進程綁定嗎？https://zhuanlan.zhihu.com/p/280672302#:~:text= 由上述結果可知：TCP、UDP可以同時綁定一個端口8888，但是一個端口在同一時刻不可以被TCP或者UDP綁定2次。,原因如下： TCP和UDP傳輸協議監聽同一個端口后，接收數據互不影響，不沖突。快狗二面 一個端口可以 同時TCP 又UDP 嗎？https://cloud.tencent.com/developer/article/1813256
（6）同一個應用程序可以創建多個套接字嗎？
端口是唯一的，系統中任一個端口只能被一個程序占用。一個程序可以創建多個Socket，但多個Socket是不能共用端口的。
（7）什么是 TCP 粘包，如何解決？
定義：指的是多個報文數據內容融合在一起被接受
解決方案：
①循環接收、發送；即就是一次send,一次recv……
②設置分割標志。
③在頭部加上長度控制，然后讀取的時候只讀取頭部信息中指定的長度。
（8）為什么UDP數據包不發生粘包，而TCP會出現粘包？
TCP協議是面向鏈接的，收發兩端都必須要有成對的socket,因此發送端為了將多個發往接收端的包更有效的發送，使用了優化的方法nagle算法。
面向流的服務是沒有消息保護邊界的。
UDP協議是無連接，面向消息的，支持一對多的模式，所以接收端的套接字緩沖區采用鏈式結構記錄每一個到達的UDP包。
面向消息的通信是由消息保護邊界的。
（9）如果接收端填充的接收通告窗口為 0，發送端接下來怎么處理？
接收端通告的窗口大小變成0，發送端會發一個1字節的段，這一個字節段可以是下一字節的數據，如果沒有新的數據段發送的時候，就發一個ack，強制接收端重新宣告下一個期望的字節和窗口大小。如果接收方回復窗口大小仍然為零，則發送方的探測定時器加倍。沒有收到ACK時，發送探測包的最大次數之后連接超時。
（10）什么叫糊涂窗口綜合征？
糊涂窗口綜合癥是指當發送端應用進程產生數據很慢、或接收端應用進程處理接收緩沖區數據很慢，或二者兼而有之；就會使應用進程間傳送的報文段很小，特別是有效載荷很小； 極端情況下，有效載荷可能只有1個字節；傳輸開銷有40字節(20字節的IP頭+20字節的TCP頭) 這種現象。
要解決這個問題，發送方要把數據累計成足夠大的報文段，等到其到達接收方緩存區的一半大小，再發送報文。接收方等待一段時間，使得自己的接收緩存區中能夠容納一個最長的報文段或緩存區有一半空閑，然后再去發送確認報文。
（11）在 TCP 的實現中廣泛使用的 Nagle 算法是什么？
若發送應用進程，把要發送的數據逐個字節的送到TCP的發送緩存，則發送方就把第一個數據字節先發送出去，把后面的數據字節都緩存起來。當發送方收到對第一個數據字符的確認后，再把發送緩存中的所有數據組裝成一個發送報文段發送出去。
（12）TIME_WAIT 狀態存在的原因？
①保證發送端發送的最后一個ACK報文段能夠到達接收端，從而避免接收端因為收不到ACK報文段而不按照正常步驟進入CLOSED狀態。
②使本鏈接持續的時間內所產生的所有報文都從網絡中消失，避免下一個新連接中出現舊的連接請求報文段。
2.用戶數據報協議UDP
2.1UDP協議的主要特點：
（1）UDP是無連接的，可以減少開銷和發送數據之前的時延。
（2）UDP使用盡最大努力交付，不保證可靠交付，主機不需要維持復雜的連接狀態表。
（3）UDP是面向報文的，一次交付一個完整的報文。
（4）UDP沒有擁塞控制，因此網絡出現的擁塞不會使得源主機的發送速率降低。
（5）UDP支持一對一、一對多、多對一、多對多的交互通信。
（6）UDP的首部開銷小，只有八字節。
?
?
?
總結
以上是生活随笔為你收集整理的TCP协议和UDP协议的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数字图像处理：图像与编码
- 下一篇： 芥子空间破解游戏的加固保护案例