【計算機網路筆記】3.2 Multiplexing and Demultiplexing
【計算機網路筆記】3.2 Multiplexing and Demultiplexing
Hello Guys, I’m LukeTseng. 歡迎你也感謝你點入本篇文章,本系列主要讀本為《Computer Networking: A Top-Down Approach, 8th Edition》,就是計算機網路的聖經,會製作該系列也主要因為修課上會用到。若你喜歡本系列或本文,不妨動動你的手指,為這篇文章按下一顆愛心吧,或是追蹤我的個人公開頁也 Ok。
簡介
多工與解多工技術是一種將「主機對主機(Host-to-Host)」的傳輸服務,延伸轉化為「行程對行程(Process-to-Process)」傳輸服務的機制。
為什麼需要多工與解多工?
假設有位使用者的電腦同時開著瀏覽器下載網頁、開著 FTP 傳檔案、還掛著兩個 Telnet 連線。
網路層(IP)只負責把資料包(Datagram)送到電腦(Host)門口。
在當電腦收到這個資料包時,它該如何知道這是要給瀏覽器的,還是給 FTP 的?
此時就是傳輸層的工作了,傳輸層利用多工(Multiplexing)與解多工(Demultiplexing)機制,確保資料送到正確的應用程式手上。
術語解析
- 多工(Multiplexing):
- 發生於來源端主機(Source Host)。
- 工作:傳輸層從不同的 Socket 收集資料,加上標頭資訊(Header,如埠號),封裝成區段(Segment),然後統一交給網路層發送出去。
- 解多工(Demultiplexing):
- 發生於接收端主機(Destination Host)。
- 工作:傳輸層檢查收到區段(Segment)的標頭資訊,將資料導向正確的 Socket。
- Socket(通訊端/插座):
- 應用程式與網路之間的「門」,資料必須通過這個門才能進出。
- 傳輸層實際上是把資料交給 Socket,而非直接交給行程(Process)。
- Port Number(埠號):
- 就像是 Socket 的「門牌號碼」,因為一台電腦上可能有很多個 Socket,每個 Socket 都會有獨一無二的識別碼,因此需要 16-bit 的數字來區分它們(範圍 0~65535)。
- 0~1023 號通常保留給知名服務(如 HTTP 是 80,FTP 是 21)。
基本原理
所有的傳輸層區段(Segment)都有特定的欄位來幫助解多工:
- 來源端埠號欄位(Source Port Number Field #)
- 目的端埠號欄位(Destination Port Number Field #)

Image Source:Computer Networking: A Top-Down Approach (8th ed., p. 219, Figure 3.3)
無連線的多工與解多工(UDP)
情境設定:假設主機 A 的某個行程用 UDP 埠 19157,要傳送一段應用程式資料給主機 B 上的某個行程(用 UDP 埠 46428)。
識別 UDP Socket 的規則:一個 UDP Socket 僅透過二元組來識別接收端的 Socket,其二元組為 (目的 IP, 目的 Port)。
運作流程:
- Socket 建立:
- 當於 Python 建立一個 UDP Socket 時,傳輸層會自動為該 Socket 指定一個埠號(於 1024 ~ 65535 間指定一個該主機中沒被其他 UDP 占用的埠號)。
- 或可用
bind()指定埠號。
- 多工:
- 主機 A 的傳輸層建立一份包含應用程式資料、來源端埠號(19157)、目的端埠號(46428)的區段(Segment)。
- 傳輸層將所得區段交給網路層。
- 網路層則將此區段封裝於 IP 資料包中,盡力將該份區段交給接收端主機。
- 解多工:
- 該區段抵達接收端主機 B 後,接收端主機的傳輸層會檢查區段中的目的端埠號(46428)。
- 接著將該區段傳送給埠號 46428 所識別的 Socket。
- 註:主機 B 可能會同時執行多筆行程。
- 接收後的處理:Server 端的 Process 可透過
recvfrom()函式讀取區段中的「來源 IP」與「來源 Port」,藉此知道該回覆給誰。
註:來源端埠號的用途在於作為「返回位址」的一部分。
另外若有其他主機(主機 C,IP:C,Port 1120)也要發送一個 UDP 封包給主機 B,會因為與主機 A「目的 IP」與「目的 Port」相同,而都會被導向主機 B 的同一個 UDP Socket。
下圖講解若主機 A 傳送 UDP 封包給主機 B,而主機 B 想要回傳的話,就可以利用來源端 Port 回傳給主機 A。

Image Source:Computer Networking: A Top-Down Approach (8th ed., p. 221, Figure 3.4)
連線導向的多工與解多工(TCP)
識別 TCP Socket 的規則:一個 TCP Socket 是由一個四元組(Four-tuple)來做識別,四元組的內容如下:
- 來源 IP 位址(Source IP Address)
- 來源埠號(Source Port Number)
- 目的 IP 位址(Destination IP Address)
- 目的埠號(Destination Port Number)
這表示即使兩個 TCP 區段的目的地 IP 和 Port 一模一樣,只要來源不同,它們就會被導向不同的 Socket。
運作流程:
- 建立連線
- 伺服器準備:TCP Server 啟動時,會先建立一個接待 Socket,並綁定一個特定的埠號(例如 Web Server 常用的 Port 80),socket 在此等待,就像飯店門口的接待員。
- 客戶端敲門:客戶端發送一個連線請求區段(SYN segment),目的埠號是 80。
- 解多工:主機收到後,看到目的 Port 是 80,於是將這個請求導向那個正在等待的接待 Socket。
- 專屬服務
4. 建立新 Socket:一旦握手完成,伺服器作業系統會為該特定的客戶端生出一個新的 Socket。
5. 專屬標記:這個新生成的 Socket 會被標記上完整的四元組:(來源 IP=客戶端, 來源 Port=客戶端, 目的 IP=伺服器, 目的 Port=80)
6. 後續通訊:接著所有從該客戶端寄來的封包,雖然目的 Port 還是 80,但因為來源 IP/Port 符合這個新 Socket 的記錄,作業系統會直接把資料導向這個專屬 Socket,而不是原本的歡迎 Socket。
下圖 3.5 的情境為:
- 主機 C 發起兩個 HTTP 連線到伺服器 B(Port 80)。
- 主機 A 發起一個 HTTP 連線到伺服器 B(Port 80)。

Image Source:Computer Networking: A Top-Down Approach (8th ed., p. 223, Figure 3.5)
此時伺服器 B 會有幾個 Socket?
- 一個一直在監聽 Port 80 的接待 Socket。
- 兩個專屬於主機 C 的連線 Socket(因為主機 C 開了兩個瀏覽器分頁,用了兩個不同的來源 Port)。
- 一個專屬於主機 A 的連線 Socket。
總共會有 4 個 Socket,伺服器會透過檢查每一個到達封包的四個欄位來決定該把封包送去這 4 個房間的哪一間。
UDP vs TCP
| 比較項目 | UDP(無連線導向) | TCP(連線導向) |
|---|---|---|
| 識別依據 | 二元組(2-tuple) 1. 目的 IP 2. 目的 Port | 四元組(4-tuple) 1. 來源 IP 2. 來源 Port 3. 目的 IP 4. 目的 Port |
| Socket 行為 | 來自不同客戶端的封包,只要目的 Port 相同,都會進入同一個 Socket。 | 來自不同客戶端(或同一客戶端不同 Port)的封包,會進入不同的 Socket。 |
| 比喻 | 公共信箱:不管是誰寄來的信,只要地址對了,都丟進同一個信箱。 | 專屬會議室:接待員(接待 Socket)確認身分後,會開一個專屬的小房間(連線 Socket)給使用者,只有使用者能進去。 |
| 伺服器負擔 | 較輕,通常一個 Process 處理所有請求。 | 較重,通常每個連線對應一個新的 Process 或 Thread(執行緒)。 |
總整理
網路層(IP)只負責將資料包送到主機(Host),但一台電腦上通常同時運行多個網路應用程式(如瀏覽器、FTP、通訊軟體)。
傳輸層的多工與解多工機制,就是為了解決資料該交給哪個應用程式的問題,成功將主機對主機(Host-to-Host)的傳輸,細化為行程對行程(Process-to-Process)的服務。
術語解析
- Socket(通訊端 / 插座):應用程式與網路之間進出的門。
- Port Number(埠號):Socket 的專屬門牌號碼,使用 16-bit 數字組成(範圍 0~65535,其中 0~1023 保留給 HTTP 80 等知名服務)。
- 多工(Multiplexing):發生在發送端,傳輸層收集各 Socket 的資料,加上標頭(包含來源與目的埠號)封裝成區段(Segment),再統一交給網路層發送。
- 解多工(Demultiplexing):發生在接收端,傳輸層讀取區段的標頭資訊,藉此將資料精準導向對應的 Socket。
UDP 與 TCP 機制對比
傳輸層區段一定會帶有來源埠號(Source Port)與目的埠號(Destination Port),但 UDP 與 TCP 在辨識 Socket 的規則上有根本性的差異:
UDP(無連線導向):
- 識別規則:僅依賴二元組
(目的 IP, 目的 Port)。 - 運作邏輯:就像公共信箱,只要封包的目的地 IP 和 Port 正確,無論是誰寄來的,都會被丟進同一個 Socket 由同一個 Process 處理。
- 來源埠號的用途:僅作為附上的回信地址,讓接收端知道回覆時該寄去哪裡。
TCP(連線導向):
- 識別規則:必須嚴格核對四元組
(來源 IP, 來源 Port, 目的 IP, 目的 Port)。 - 運作邏輯:就像飯店的專屬會議室。
- 伺服器會有一個接待 Socket(例如 Port 80)專門等候連線請求。
- 當客戶端發起連線(握手),作業系統會根據四元組,為這個特定的客戶端開一間專屬的連線 Socket。
- 即使多個客戶端都連線到同一個目的 Port(80),只要來源 IP 或來源 Port 不同,資料就會被精準分流到各自專屬的 Socket 中。
UDP vs TCP
| 比較項目 | UDP(無連線導向) | TCP(連線導向) |
|---|---|---|
| 識別依據 | 二元組(2-tuple) 1. 目的 IP 2. 目的 Port | 四元組(4-tuple) 1. 來源 IP 2. 來源 Port 3. 目的 IP 4. 目的 Port |
| Socket 行為 | 來自不同客戶端的封包,只要目的 Port 相同,都會進入同一個 Socket。 | 來自不同客戶端(或同一客戶端不同 Port)的封包,會進入不同的 Socket。 |
| 比喻 | 公共信箱:不管是誰寄來的信,只要地址對了,都丟進同一個信箱。 | 專屬會議室:接待員(接待 Socket)確認身分後,會開一個專屬的小房間(連線 Socket)給使用者,只有使用者能進去。 |
| 伺服器負擔 | 較輕,通常一個 Process 處理所有請求。 | 較重,通常每個連線對應一個新的 Process 或 Thread(執行緒)。 |
