教你如何快速理解TCP與UDP協議

1、TCP（傳輸控制協議）

1.1端口

• 傳輸層:爲相互通信的應用程序提供邏輯通信，負責將數據從一端發送至另外一端
• 在UDP/IP協議中，用源IP地址 + 源端口號 + 目的IP地址 + 目的端口號 + 協議號（組成的套接字），這樣的五元組來標識一個通信
• 端口號是一個32位的整數
• 端口號用來標識一個進程, 告訴操作系統, 當前的這個數據要交給哪一個進程來處理
• 端口範圍的劃分：
  1、0 - 1023: 知名端口號
  2、1024 - 65535: 操作系統動態分配的端口號
• 常見知名端口號
  

1.2 報文結構

源/目端口號：應用進程與應用進程之間通信的監聽出入口。
序列號：序列號隨機生成，每次序號都會不一樣，有一個複雜的初始化算法。序列號會隨着雙方通訊而不斷的增加。序列號一共32比特，最大值2^32-1，到達最大值後重新從0開始。
確認序列號：確認序列號是上次已成功接收到數據字節序列號加1。
首部長度：選項不用，TCP的頭部爲20字節；存在選項則爲60字節。
保留：爲將來定義新的用途保留，現在一般置0。
標誌：每個標誌佔1比特，1表示有效，0爲無效。

1. URG：緊急指針是否有效。有效會告訴系統此時有緊急數據需要儘快傳送。
2. ACK：確認序號是否有效。僅當ACK=1時確認字段纔有效。建立連接後，所有的傳送的報文都必須把ACK置爲1。
3. PSH：接收方應該儘快將這個報文段交給應用層。不必等待緩存區滿後再向上交付
4. RST：復位，對方要求重新建立連接。當RST=1代表TCP連接出現嚴重差錯，必須釋放連接再重新建立連接。
5. SYN：同步序列號，請求建立連接。在連接請求中，SYN=1 ACK=0表示該數據段是未捎帶確認的連接請求報文；SYN=1 ACK=1表示是一個捎帶了確認的連接請求報文。
6. FIN：用於釋放連接，FIN=1時表示發送方已經沒有數據發送了，即關閉本方數據流。

窗口：滑動窗口大小，用來告知發送端接受端的緩存大小，以此控制發送端發送數據的速率，從而達到流量控制。窗口大小最大爲65535。
檢驗和：覆蓋了整個TCP報文段：TCP首部和TCP數據，因爲TCP是一個可靠的協議，所以這是強制性的字段，由發送方計算和設置，並由接收方進行驗證，這就是可靠性保證的重要手段。
緊急指針：只有當URG=1纔有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最後一個報文段。TCP 的緊急方式是發送端向另一端發送緊急數據的一種方式。
選項：就是TCP頭部的不是“必須”的選項
數據：可選，在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段。

1.3 TCP的建立和終止

1.3.1 建立

描述：

1. 客戶端發送一個SYN報文表示希望和服務器建立連接，並附帶上一個客戶端隨機產生的序列號X。,此時進入SYN-SEND狀態。（同步發送）
2. 服務端收到SYN請求後會發送給客戶端SYN報文段作爲應答。同時發送ACK報文段進行確認。並附帶一個服務端隨機產生的序列號Y和一個確認序列號X+1，此時爲SYN-RCVD（同步收到）狀態
3. 客戶端收到服務端發送的響應包後，客戶端發送確認包給服務端表示收到了服務端發送的SYN報文。確認包中包含序列號X+1和確認序列號Y+1，此時雙方進入了ESTAB-LISHED(建立連接)狀態。

當以上三個報文段完成交互後就證明連接已經建立，這個過程也成爲“三次握手”。接下來客戶端就可以發送數據給服務端，服務端可以響應數據。

經典面試題：爲何TCP客戶端最後還要發送一次確認呢？
主要防止已經失效的數據報文突然又傳送到服務器，從而產生錯誤

1.3.2 終止

描述：

1. 客戶端發送FIN報文希望主動關閉連接，報文中攜帶隨機序列號U。此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2. 服務端收到這個FIN報文段時，它將發送給客戶端一個ACK表示確認斷開，此報文中攜帶隨機序列號V和一個確認序列號U+1。此時，服務端就進入了CLOSE_WAIT（關閉等待）狀態。
3. 服務端把收到的FIN的消息告訴應用程序，應用程序就會關閉它的連接。導致服務端發送一個FIN給客戶端。報文中攜帶確認序列號U+1。由於半連接狀態，服務端很可能又發送了一些數據。 此時，服務器就進LAST-ACK（最後確認）狀態，等待客戶端的確認。
4. 客戶端收到服務端的FIN報文段時，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態。客戶端會立刻對此FIN報文進行ACK回覆，報文中包含序列號U+1和確認序列號V+1。此時TCP連接還沒有釋放，必須經過2MSL（最長長報文段生存）的時間後，才進入CLOSED狀態。

注：TCP是全雙工模式的，客戶端關閉連接不代表服務端就可以立刻關閉，如果客戶端發起關閉的時候，服務端還沒有響應完數據給客戶端，服務端還是需要把數據發完了再去關閉的，而客戶端主動發起了閉關但不會立即關閉，而是進入“FIN_WAIT2”狀態進行數據接收，此爲半關閉。直到服務端發送完了並最後發送結束連接報文段FIN才進入TIME_WAIT狀態。

1.3.3 爲何需要三次握手，四次斷開？

• 建立一個連接需要三次握手，而終止一個連接需要經過4次握手，這是由於TCP的半關閉造成的。既然一個TCP連接是全雙工的（即數據在兩個方向上能同時傳遞），因此每個方向必須單獨地進行關閉。當一端收到一個FIN，它必須通知應用層另一端已經終止了那個方向的數據傳送。發送FIN通常是應用層關閉的結果，一般爲客戶端關閉連接。

1.3.4 MSL與2MSL等待時間

• TCP報文的在網絡上單向傳送的最大生存時間叫做MSL

• 2MSL（最大報文段生存時間）等待狀態。之所以要等待，是因爲關閉方要確認處於“CLOSE_WAIT”狀態的被關閉方收到它最後的ACK報文，，等待確認報文來回的時間就是2MSL，如果被關閉方在2MSL內都沒有收到ACK，就會重複發送FIN報文。如果關閉方在2MSL時間內未收到被關閉方的報文，則默認收到
  Windows : MSL = 2 min
  linux(Ubuntu, CentOs) : MSL = 60s

• 2MLS等待原因
  1、2MSL的時間能保證在兩個傳輸方向上的未被接收的數據和遲到的數據全部被丟棄（當連接關閉時，有可能收到遲到的報文段。這時，若立馬就建立新的連接（同一端口），那麼新的連接就會接收遲到的報文，誤以爲是發給自己的）
  2、保證了最後一個報文可靠到達(假設最後一個ACK丟失, 那麼服務器會再重發一個FIN. 這時雖然客戶端的進程不在了,但是TCP連接還在,仍然可以重發LAST_ACK）如果直到2MSL，客戶端都沒有再次收到FIN，那麼客戶端推斷ACK已經被成功接收，則結束TCP連接。

注：報文在網絡中的生存時間並不只由TCP決定的，網絡層的IP協議對數據報同樣存在着網絡單向傳送的時間限制，這個限制叫TTL。

1.3.5 同時打開和關閉

TCP建立連接不一定必須是三次握手，有時可能會是4次。

• 比如當雙發同時進行請求主動打開連接的時候就是4次。此時並沒有客戶端和服務端之稱，雙方都有主動發送數據的權利。

1.4 可靠傳輸機制

確認應答機制和重傳機制

• 當數據完整發送到對端時，對端會發送確認序列號（ACK）確保數據完整性，當數據中的某些數據段因爲一些原因未能傳輸到對端時（丟包），就會採用重傳機制對丟失的數據段進行重發。從而保證了數據的可靠性

如何確定超時重傳時間？

• 系統基於TCP協議實現，動態計算報文最大生存時間（MSL）,超時時間設置爲2MSL。
• 超過超時時間表示丟包，需要重新發數據。數據不會被反覆，無限重發，達到一定次數強制關閉連接。

1.5 滑動窗口

• 滑動窗口
  用來告訴發送端可以發送數據的大小或者說是窗口標記了接收端緩衝區的大小。窗口指一次批量發送多少數據

• 滑動窗口產生的原因
  在確認應答的策略中，每發送一次數據段都需要一個ACK確認應答，收到ACK後再發送下一個數據段，這樣每次都需要確認，性能較差。採用滑動窗口的機制就會一次發送多條數據，提高傳輸性能

• 丟包後如何重傳
  1、數據包並未丟失，ACK確認包丟失
  當窗口值較大時，即使有少量的確認應答丟失，也不會進行重傳，可以通過下一個確認應答進行確認
  2、數據包直接丟失
  接收端在沒有收到自己所期望序號的數據時，會對之前收到的數據進行確認應答。發送端一但收到某個確認應答後，又連續3次收到同樣的確認應答，則認爲數據段已經丟失，需要進行重發。這種機制比起超時機制可以提供更爲快速的重發服務，也叫快重傳。

1.6 流量控制

• 接收端通過TCP協議頭中”窗口大小“字段，告知發送端發送數據的大小。
• 流量控制的目的：防止接收緩衝區被佔滿，再次接收到的數據就會被直接丟棄，接收端主機無法處理。
• 接收端將自己可以接收的緩衝區大小放入 TCP 首部中的 “窗口大小” 字段, 通過ACK端通知發送端
• 窗口大小字段越大, 說明網絡的吞吐量越高
• 接收端一旦發現自己的緩衝區快滿了, 就會將窗口大小設置成一個更小的值通知給發送端
• 發送端接受到這個窗口之後, 就會減慢自己的發送速度
• 如果接收端緩衝區滿了, 就會將窗口置爲0; 這時發送方不再發送數據, 但是需要定期發送一個窗口探測數據段, 使接收端把窗口大小告訴發送端

1.7 擁塞控制

• 如果在剛開始階段發送大量的數據, 會引發大量問題

• 擁塞控制就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載

  1.7.1 慢啓動與擁塞避免

• 慢啓動的思路就是，不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。
  

• TCP開始啓動的時候, 慢啓動閾值等於窗口最大值

• 擁塞避免是指把擁塞窗口設置爲線性規律增長，使網絡較不容易出現擁塞

• 每次超時重發的時候, 慢啓動閾值會變成原來的一半, 同時擁塞窗口置回1

• 少量的丟包, 僅僅觸發超時重傳; 大量的丟包, 我們就認爲網絡擁塞

• 當TCP通信開始, 網絡吞吐量會逐漸上升; 隨着網絡發生擁堵, 吞吐量會立刻下降

• 擁塞控制, 歸根結底是TCP協議想儘可能快的把數據傳輸給對方, 但是又要避免給網絡造成太大壓力的一種方案

1.7.2 快重傳和快恢復

• 快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
• 當發送方連續收到三個重複確認時，就執行“乘法減小”算法，把慢啓動閾值門限減半。但是接下去並不執行慢開始算法。
• 考慮到如果網絡出現擁塞的話就不會收到好幾個重複的確認，所以發送方現在認爲網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將擁塞窗口設置爲慢啓動閾值的大小，然後執行擁塞避免算法

2、UDP(用戶數據報協議)

2.1 報文結構

源端口號:源主機的應用程序使用的端口號。
目的端口號:目的主機的應用程序使用的端口號。
UDP長度:是指UDP頭部和UDP數據的字節長度。因爲UDP頭部長度爲8字節，所以該字段的最小值爲8。
**UDP校驗和:**該字段提供了與TCP校驗字段同樣的功能;該字段是可選的。

2.2 UDP特點

• 無連接：知道對端的IP和端口號就直接進行傳輸，不需要建立連接
• 不可靠:沒有確認機制，沒有重傳機制；如果因爲網絡故障該段報文無法送達對方，UDP協議也不會給應用層返回任何錯誤信息