一文解析TCP/UDP

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

轉載請註明出處：@熱風、http://www.javashuo.com/article/p-wmigdywq-nv.html

---

目錄

• TCP/UDP詳解
  • 一、TCP/UDP比較
    • 1.1：簡介
    • 1.2：TCP
    • 1.3：UDP
    • 1.4：TCP/UDP比較
  • 二、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：工做過程
  • 三、UDP詳解
    • 3.1：UDP數據報格式
    • 3.2：UDP的基本工做過程
    • 3.3：經常使用UDP端口號分配

TCP/UDP詳解

一、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	適用於實時應用，例如即時通訊、視頻會議、直播等（丟包影響不大、就要快）

二、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：工做過程

例子：

三、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	簡單網絡管理協議

---

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

轉載請註明出處：@熱風、http://www.javashuo.com/article/p-wmigdywq-nv.html

若是有學到東西，請點贊給予鼓勵，謝謝。