一文解析TCP/UDP

聲明：本文部分內容來自互聯網、書籍等渠道，表示感謝；

轉載請注明出處：@熱風、https://www.cnblogs.com/refeng/p/13996657.html

---

目錄

• TCP/UDP詳解
  • 1、TCP/UDP比較
    • 1.1：簡介
    • 1.2：TCP
    • 1.3：UDP
    • 1.4：TCP/UDP比較
  • 2、TCP詳解
    • 2.1：概念
    • 2.2：TCP報文格式
      • 2.2.1：各字段含義
    • 2.3：可靠傳輸步驟
      • 2.3.1：建立連接，三次握手
      • 2.3.2：差錯控制
        • 2.3.2.1：校驗與確認
        • 2.3.2.2：超時重傳
        • 2.3.2.3：流量控制
      • 2.3.3:關閉連接，四次揮手
    • 2.4：常用TCP端口號分配
    • 2.5：TCP的擁塞控制
      • 2.5.1：概念
      • 2.5.2：擁塞窗口
      • 2.5.3：控制方法
        • 2.5.3.1：慢啟動算法
        • 2.5.3.2：擁塞避免算法
        • 2.5.3.3：工作過程
  • 3、UDP詳解
    • 3.1：UDP數據報格式
    • 3.2：UDP的基本工作過程
    • 3.3：常用UDP端口號分配

TCP/UDP詳解

1、TCP/UDP比較

1.1：簡介

TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Datagram Protocol，用戶數據報協議）是OSI七層模型——傳輸層的兩個主要協議，均是互聯網的正式標准。

1.2：TCP

TCP是一種面向連接的、可靠的、基於字節流的通信協議，是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。

• 優點：可靠。傳遞數據之前，通過三次握手來建立連接，在數據傳遞時，有滑動窗口、擁塞控制、超時重傳等機制保證傳輸的可靠性、正確性，在數據傳輸完成后，可保持連接狀態（長連接）或通過四次揮手來斷開連接（短連接）。
• 缺點：效率較低、占用系統資源高，易被攻擊。TCP在傳遞數據之前，要先建連接，會消耗時間，在數據傳遞時，各種機制都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接，事實上，每個連接都會占用系統的CPU、內存等硬件資源。而且TCP有確認機制、三次握手機制，這些容易被人利用。

1.3：UDP

UDP是一種無連接的、不可靠的、基於報文的通信協議，為應用程序提供了一種無需建立連接就可以發送封裝的 IP 數據包的方法。

• 優點：快。沒有TCP協議的各種機制。
• 缺點：不可靠，不穩定。盡最大努力交付，如果網絡質量不好，就很容易丟包。

1.4：TCP/UDP比較

	TCP	UDP
是否連接	面向連接	無連接
是否可靠	可靠	不可靠
連接對象個數	只能一對一	支持一對一，一對多，多對一和多對多
傳輸方式	面向字節流	面向報文
首部開銷	首部最小20字節，最大60字節	首部開銷小，僅8字節
適用場景	適用於要求可靠傳輸的應用，例如FTP、HTTP、STMP	適用於實時應用，例如即時通信、視頻會議、直播等（丟包影響不大、就要快）

2、TCP詳解

2.1：概念

• TCP是一種面向連接的、可靠的傳輸層協議；
• TCP協議建立在不可靠的網絡層IP協議之上，IP不能提供任何可靠性機制，TCP的可靠性完全由自己實現；
• TCP采用的最基本的可靠性技術是：
  • 確認與超時重傳
  • 滑動窗口機制進行流量控制

2.2：TCP報文格式

2.2.1：各字段含義

1. 源端口號與目的端口號：各占2個字節。端口是傳輸層與高層的服務接口。
2. 序號：占4字節，是本報文段所發送的數據部分第一個字節的序號。在TCP傳送的數據流中，每一個字節都有一個序號。例如，在一個報文段中，序號為300，而報文中的數據共100字節。那么在下一個報文段中，其序號就是400。因此TCP是面向數據流（字節流）的。
3. 確認號：占4字節，是期望收到對方下次發送的數據的第一個字節的序號，也就是期望收到的下一個報文段的首部中的序號。由於序號字段有32bit長，可對4GB(即4千兆字節)的數據進行編號。
4. 報頭長度：占4bit，
5. 確認比特ACK：只有當ACK＝1時確認序號字段才有意義。當ACK＝0時，確認序號沒有意義。
6. 同步比特SYN：在連接建立時使用。當SYN＝1而ACK＝0時，表明這是一個連接請求報文段。對方若同意建立連接，則應在發回的報文段中使SYN＝1和ACK=1，表明這是一個連接接受報文段。因此，同步比特SYN為1，就表示這是一個連接請求或連接接受報文，而 ACK比特的值用來區分是哪一種報文。
7. 終止比特FIN：用來釋放一個連接，當FIN＝1時．表明欲發送的字節串已經發完，並要求釋放傳輸連接。
8. 窗口大小：占2字節。窗口字段實際上是報文段發送方的接收窗口，單位為字節。通過此窗口告訴對方，“在未收到我的確認時，你能發送的數據的字節數至多是此窗口的大小。”
9. 檢驗和：占2字節。檢驗和字段檢驗的范圍包括首部和數據這兩部分。

2.3：可靠傳輸步驟

1. 建立連接
2. 報文傳輸
   • 差錯控制：校驗，錯誤（丟包）重傳機制
   • 流量控制：滑動窗口機制
3. 關閉連接

2.3.1：建立連接，三次握手

1. 主機1 首先發起TCP 連接請求，並在所發送的數據段中將控制字段中的SYN置為“1”、ACK置為“0”，並設置數據起始序號為x；
2. 主機2 收到該報文，若同意建立連接，則發送一個連接接受的應答數據段，其中控制字段的SYN 和ACK均被置“1”，指示對第一個SYN 報文段的確認，響應序號x+1,表示對指定報文的響應，同時指定自己的數據序號y，以繼續握手操作；否則，主機2 要發送一個將RST置為“1”的應答數據段，表示拒絕建立連接。
3. 主機1 收到主機2 發來的同意建立連接數據段后，還有再次進行選擇的機會，若其確認要建立這個連接，則向主機2 發送確認數據段，確認序號為y+1，同時自己的數據需要為x+1，用來通知主機2 雙方已完成建立連接；若主機1已不想建立這個連接，則可以發送一個將RST置為“1”的應答數據段來告之主機2 拒絕建立連接。（思考：若主機1遲遲不發消息，怎么辦？）

2.3.2：差錯控制

TCP采用校驗、確認以及超時重傳，進行差錯控制。

2.3.2.1：校驗與確認

發送方會對發送數據進行處理生成校驗碼，並設置在校驗碼字段中，隨數據一起發送：

• 接收方對數據進行校驗，判斷數據傳輸是否出現錯誤；
• 接收方對正確接收到的數據進行確認；
• 發送方發送數據時，啟動定時器，超時未接收到確認，則重傳數據。

2.3.2.2：超時重傳

采用單一定時器

• 發送TCP分段（TCP會自己分段）時，如果沒有重傳定時器開啟，那么開啟；如果已有重傳定時器開啟，不再開啟。

• 收到一個非重復ACK時，如果有數據在傳輸中，重新開啟重傳定時器；如果沒有數據在傳輸中，則關閉重傳定時器。

• 未收到確認造成定時器超時，重傳所有發出未確認的分段。

• 收到重復ACK時，超過3個，則立即重傳重復確認的數據。

  （還有一些深入知識不詳解）

2.3.2.3：流量控制

接收方和發送方都有一定大小的接收和發送緩沖區。發送方的發送速度不能超過接收方的接收速度。

為了防止由於發送端與接收端之間的不匹配而引起數據丟失，TCP采用滑動窗口進行流量控制。雙方通過窗口大小來告訴對方，在沒有收到確認前，最多可以發送的數據量。

發送窗口=min{擁塞窗口，通告窗口}

• 擁塞窗口：從通信子網擁塞程度考慮確定的在沒有收到接收方確認情況，發送方可以發送的數據量；
• 通告窗口：從接收方接收能力的角度考慮，確定的在沒有收到接收方確認情況，發送方可以發送的數據量；由接收到的TCP報文中的窗口大小字段確定。

2.3.3:關閉連接，四次揮手

1. 當主機1 的數據已發送完畢時，其在等待確認的同時可發送一個將控制字段FIN 置“1”的數據段給主機2，表示請求中斷主機1到主機2的連接。
2. 若主機2 已正確接收主機1 的所有分段，則會發送一個數據段正確接收的確認段，同時通知本地相應的應用程序，對方要求關閉連接，接着再發送一個對主機1 所發送的FIN段進行確認的應答段。由此便拆除了一個方向的TCP連接。
3. 但是，此時在相反方向上，主機2 仍然可以向主機1 發送數據，直到主機2 數據發送完畢並要求關閉連接。這個方向上連接的拆除同樣要經過（1）、（2）兩步，由主機2發起FIN段，主機1應答確認ACK，拆除另一方向的TCP連接。（全雙工）

2.4：常用TCP端口號分配

端口號	服務進程	說明
20	FTP	文件傳輸協議（數據連接）
21	FTP	文件傳輸協議（控制連接）
23	Telent	虛擬終端網絡
25	SMTP	簡單郵件傳輸協議
53	DNS	域名服務器
80	HTTP	超文本傳輸協議
111	RPC	遠程過程調用

2.5：TCP的擁塞控制

2.5.1：概念

網絡中的鏈路帶寬、交換節點的存儲和處理能力等都是網絡的資源，這些資源一般是有限的，當網絡的資源容量和處理能力大於網絡負載的需求時，網絡處於正常運轉狀態，反之網絡會出現擁塞。

網絡擁塞的根本原因在於端系統向網絡提供的負載大於網絡資源容量和處理能力，主要體現在網絡轉發設備的存儲空間有限，網絡鏈路帶寬有限以及網絡轉發設備的處理能力有限等。

TCP擁塞控制的基本策略是發送端通過跟蹤傳輸數據的丟失現象和往返時延的變化確定網絡的傳輸能力，並以此來調整發送數據率。

2.5.2：擁塞窗口

擁塞窗口cwnd是每個TCP端系統在建立連接時創建的擁塞控制量，同樣定義為發送端未收到確認時可以連續發送的字節數。擁塞窗口隨網絡傳輸能力變化而變化。當網絡負載較小時，擁塞窗口可以設置比較大，發之，就要設置成相對較小值。

2.5.3：控制方法

TCP發送端可以通過兩種方式檢測到發送的數據在網絡中丟失，一種是通過超時定時器，超時未收到對發送數據的正確確認，則判定所發數據丟失，另一種方式是，當發送端連續收到多個對其發送的某個數據分組的重復確認時，說明該分組后繼分組在傳輸中出了問題。對兩種不同方式檢測到的數據包丟棄，TCP發送端采用不同的方式進行擁塞控制。

針對超時重發檢測到的數據丟失，TCP發送端采用慢啟動和擁塞避免方法進行擁塞控制；

對通過重復確認發現的數據包丟失，TCP發送端采用快重發和擁塞避免方法進行擁塞控制。

慢啟動門限ssthresh是一個動態變化的門限值，用來確定當前是否采用擁塞避免算法，初始值65535。

2.5.3.1：慢啟動算法

RTT：傳輸往返時間

（思考：cwnd以指數形式增長，為什么叫慢啟動算法？）

2.5.3.2：擁塞避免算法

cwnd線性增長。

例子：發生超時，進入慢啟動；超過門限，進入擁塞避免

2.5.3.3：工作過程

例子：

3、UDP詳解

UDP是一種無連接的、不可靠的傳輸層協議，UDP協議的目的是希望以最小的開銷來達到網絡環境中的進程通信目的。

3.1：UDP數據報格式

3.2：UDP的基本工作過程

3.3：常用UDP端口號分配

端口號	服務進程	說明
53	Name server	域名服務
67	Bootps	下載引導程序信息的服務器端口
68	Bootpc	下載引導程序信息的客戶器端口
69	TFTP	簡單文件傳輸協議
111	RPC	遠程過程調用
123	NTP	網絡時間協議
161	SNMP	簡單網絡管理協議

---

聲明：本文部分內容來自互聯網、書籍等渠道，表示感謝；

轉載請注明出處：@熱風、https://www.cnblogs.com/refeng/p/13996657.html

如果有學到東西，請點贊給予鼓勵，謝謝。

---