封包已經走到 L4 門口：這一層要決定的不再是「怎麼送達」，而是「送達要不要保證」。

分層模型篇把一個封包送到了主機門口——IP 負責找到哪一台機器，port 負責找到哪一個程式。 從這裡開始，傳輸層（L4）要回答的是另一個問題：這條資料通道，要給應用什麼樣的保證？ TCP 與 UDP 就是兩個答案完全相反的協定，而它們的差異會一路影響到本系列後面每一個協定的設計。

兩種契約沒有優劣，只有「這個應用能不能忍受掉包，以及能不能忍受等待」。

「可靠」不是形容詞，是四個具體機制：初始序號同步、累積確認、重傳、有序交付。

TCP 連線的一生從三向交握（Three-way Handshake）開始。很多人記得「三次」，卻答不出為什麼是三次： 因為要同步的不是一個方向，而是兩個方向各自的初始序號（ISN, Initial Sequence Number）。 A 告知並被確認、B 告知並被確認，總共四件事——中間兩件可以合併成一個封包，於是變成三次。

一次來回（RTT，Round-Trip Time，封包往返一趟的時間）就能完成交握——但這 1-RTT 是 TCP 相對 UDP 的固定起手成本：TLS 篇的 0-RTT 只省得掉 TLS 交握那一趟、省不掉它；QUIC 篇的交握合一則把它和 TLS 交握併成同一趟。

連線建立後，TCP 眼中的資料是一條連續編號的位元組串流：每個 byte 都有序號，接收端用累積確認（Cumulative ACK） 回報「我已經連續收到 n 之前的所有資料，下一個請給我 n」。掉包的偵測與補救有兩條路：

現代 Linux 預設開啟 SACK：發送端因此能只補洞、不必把整個視窗重來一遍。這個細節在本篇的互動模擬器裡看得到。

關閉則是四次揮手：兩個方向各自 FIN / ACK，因為 TCP 是全雙工，一方沒話說不代表另一方也講完了。 主動關閉的一方會停在 TIME_WAIT 約 2 倍 MSL，用來吸收延遲抵達的舊封包、並確保最後那個 ACK 有機會重送：

這解釋了一個經典現象：服務重啟時出現 Address already in use，正是舊連線還卡在 TIME_WAIT； 解法是 SO_REUSEADDR，而不是盲目調低 TIME_WAIT（那會讓舊封包有機會污染新連線）。

兩個都是「別送太快」，但保護的對象完全不同：一個保護接收端，一個保護整條網路。

面試最常混淆的一組概念。分清楚只要問一句：是誰喊停？

兩者同時生效，發送端每一刻能送出的量取兩者較小值。

發送端真正能送出而未被確認的資料量是：

其中 rwnd 由接收端在每個 ACK 中告知。若接收端應用讀取太慢，rwnd 會一路縮到 0（zero window）， 發送端就只能定期送 window probe 等待對方鬆口——這就是 TCP 層的 backpressure，稍後在第 6 節〈I/O 模型與 Backpressure〉會看到它如何一路傳導回應用程式碼。

滑動視窗（Sliding Window）是實作方式：發送端維護一段「已送出但未確認」的區間， 收到累積 ACK 就把左邊界往右滑，空出額度再送新資料。視窗大小決定了管線能填多滿：

視窗若小於 BDP，鏈路永遠跑不滿——這就是「跨洲傳大檔案很慢，但不是因為頻寬不夠」的根因， 也是為什麼 window scaling 選項（把 16-bit 視窗欄位放大）是長肥管線的必要配備。

壅塞控制則是一套「試探－退讓」的迴圈。以經典的 Reno 家族為例：

• 慢啟動（Slow Start）：cwnd 從 1 個 MSS 起跳，每個 RTT 翻倍——名字叫慢，成長其實是指數。
• 壅塞避免（Congestion Avoidance）：cwnd 超過門檻 ssthresh 後改為每 RTT 加一，線性試探。
• 快速重傳／快速恢復：收到 3 個重複 ACK，判定只是輕度丟包，ssthresh 與 cwnd 減半後繼續。
• 超時：判定網路嚴重惡化，cwnd 直接砍回 1，重新慢啟動。

關鍵區分：CUBIC 把「丟包」當成網路已經塞住的證據；BBR 認為丟包可能只是無線干擾，改用「送多快才不會讓佇列變長」來判斷。

UDP 不是「殘缺的 TCP」，而是刻意保留的一塊空白——讓應用自己決定要什麼保證。

UDP 的 header 只有 8 bytes：來源 port、目的 port、長度、checksum。它做的事情僅僅是 「把 IP 的主機到主機，延伸成程式到程式」。沒有連線、沒有狀態、沒有重傳、沒有視窗。 但這份極簡帶來三個 TCP 給不了的特性：

最後一列是關鍵：選 UDP 常常不是為了「不要可靠性」，而是為了要一種 TCP 沒提供的可靠性。

典型的取捨是「部分可靠」：即時遊戲對玩家座標更新根本不需要重傳（下一個封包就會帶來更新的位置）， 但對「玩家開了一槍」這種事件則需要確認與重送。TCP 無法區分這兩者——它一視同仁地保證全部； UDP 讓應用自由選擇要對哪些訊息付出可靠性成本。同樣的思路，也支撐了在 UDP 之上重建整個可靠傳輸層的做法（系列後面的 QUIC 篇會專門處理）。

這張表是所有「在 UDP 上造輪子」專案的工作清單——每一列都是實打實的工程量。

bind / listen / accept / connect 不是四個 API，而是連線狀態機在使用者空間的四個掛載點。

Socket 是作業系統給的通訊端點抽象，在程式裡就是一個檔案描述符（fd）。 而一條 TCP 連線在核心裡的唯一識別，是眾所皆知的五元組：

這也解釋了「一台伺服器只開一個 port，為什麼能同時服務幾萬個客戶端」——因為每個客戶端的來源 IP／port 不同，五元組就不同。 真正的上限不是 65535 個 port，而是 fd 數量與記憶體。

# Server
fd = socket(AF_INET, SOCK_STREAM, 0)   # 建立端點，尚未綁定任何位址
setsockopt(fd, SO_REUSEADDR, 1)        # 允許重啟時立刻重新綁定（跳過 TIME_WAIT 殘留）
bind(fd, "0.0.0.0:8080")               # 綁 0.0.0.0 = 所有網卡；綁 127.0.0.1 則外部永遠連不到
listen(fd, backlog=1024)               # 轉被動；核心開始接受交握、填充 accept queue
while True:
    conn, peer = accept(fd)            # 取出已完成三向交握的連線，conn 是新的 fd
    handle(conn)

# Client
fd = socket(AF_INET, SOCK_STREAM, 0)
connect(fd, "203.0.113.7:8080")        # 送出 SYN；來源 port 由核心從 ephemeral 範圍挑選

注意 accept() 的語義：交握已經由核心做完了，應用只是來領取結果。

綁定了 port，不等於外面連得到你。這一段直接接回 nat-port-forwarding 的結論： bind() 只決定「本機哪個位址上的封包歸這個 socket」，而「封包能不能走到這台機器」是路徑上 NAT 與防火牆說了算：

最後一列是整個即時通訊生態的地基：因為「內往外」永遠通、「外往內」預設不通，所以裝置端一律主動建立並長期維持一條連線，之後所有雙向訊息都在這條連線上跑。本系列後面的 WebSocket 與 MQTT 都建立在這個前提上。

從 thread-per-connection 到 epoll 事件迴圈；以及當對端讀不動時，你的程式該做什麼。

拿到 fd 之後，「怎麼等資料」的策略決定了一台機器能扛多少連線。

從 select 到 epoll 的躍遷關鍵不是「更快」，而是把複雜度從「總連線數」換成「當下有事的連線數」——這正是十萬級長連線得以成立的原因。

fd = socket(); set_nonblocking(fd);
ep = epoll_create1(0);
epoll_ctl(ep, ADD, listen_fd, EPOLLIN);

while (true) {
  n = epoll_wait(ep, events, MAX, timeout);        # 只回報「就緒」的 fd
  for (ev in events[0..n]) {
    if (ev.fd == listen_fd)  accept_all();         # ET 模式必須 accept 到 EAGAIN 為止
    else if (ev.mask & EPOLLIN)   read_until_eagain(ev.fd);
    else if (ev.mask & EPOLLOUT)  flush_send_queue(ev.fd);   # 補送上次沒寫完的資料
  }
}

Level-Triggered（預設）只要還有資料就持續通知；Edge-Triggered 只在狀態變化時通知一次，因此必須把 fd 讀／寫到 EAGAIN，否則資料會卡在核心裡永遠等不到下一次事件。這是 ET 模式最經典的 bug。

事件迴圈解決了「同時等很多連線」，但沒解決另一半問題：對端讀不動的時候怎麼辦。

Backpressure（背壓）就是這個問題的答案，而它其實是第 3 節談流量控制時那個 rwnd 一路傳導上來的結果： 接收端應用讀得慢 → 接收端核心 buffer 滿 → rwnd 縮到 0 → 發送端不能再送 → 發送端核心 send buffer 滿 → write() 在阻塞模式下卡住、在非阻塞模式下回 EAGAIN。 那個 EAGAIN 就是網路對你的應用說「慢一點」。

四種策略的共同點：都預先決定了「撐不住時要犧牲什麼」。沒有明確答案的系統，預設答案就是 OOM。

$ ss -ltn                                    # 監聽中的 socket
State   Recv-Q  Send-Q  Local Address:Port
LISTEN  0       1024          0.0.0.0:8080   # Recv-Q = 等 accept 的連線數，Send-Q = backlog 上限

$ ss -tn state established
Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
0       262144  10.0.0.5:8080        10.0.0.9:51234   # Send-Q 持續堆高 = 對端來不及收
131072  0       10.0.0.5:8080        10.0.0.9:51235   # Recv-Q 堆高 = 你自己來不及讀

看 ss 的兩個佇列就能立刻定位 backpressure 發生在哪一端：Send-Q 堆積是對方慢，Recv-Q 堆積是自己慢。

親手在傳輸中途弄丟一個封包，看 TCP 如何重傳與排序，而 UDP 如何若無其事地留下一個永久缺口。

下面的模擬器把一段資料切成 8 個片段（seq 1–8）。點擊發送端任一個尚未確認的片段，就能預先注入丟包； 按「下一步」逐步推進，每一輪分成「發送」與「回應」兩個階段。切到 UDP 模式再跑一次，對照兩者的差別。

三個值得停下來觀察的畫面：(1) TCP 模式下對 seq 4 注入丟包（前兩輪先讓視窗長到 4），第三輪送出 4–7 時，5、6、7 會全部亮成「亂序緩衝」——它們已經安穩躺在接收端，卻因為前面缺一塊而不能交給應用，這就是 HoL Blocking 的具體樣貌。 (2) 下一輪只會補送 seq 4，5、6、7 因為已被 SACK 告知而跳過不重傳；同時 cwnd 立刻減半，順利的幾輪則從指數翻倍轉為線性加一——慢啟動與壅塞避免的分界就在 ssthresh。 (3) 切到 UDP 模式重跑：遺失的片段直接變成永久缺口，接收端毫不猶豫地把後面的資料交給應用——沒有重傳、沒有等待，也沒有人會告訴發送端出事了。

面試官問的從來不是「TCP 和 UDP 差在哪」，而是「你這個場景為什麼選它、代價是什麼」。

每一列的共同結構：便宜的選項把成本推遲到故障時，昂貴的選項把成本前置到設計時。

把這一篇收攏成一句：TCP 幫你把不可靠的封包網路，包裝成一條看起來像檔案讀寫的可靠位元組串流—— 代價是建連的 RTT、有序交付帶來的 HoL Blocking，以及一套你必須看得懂的視窗與佇列行為。 而 UDP 把這些全部拿掉，換來一張白紙與完全的自由。

但這條可靠管線還缺了一件事：它從頭到尾只保證「不掉、不亂」，沒保證「沒人看得懂」。 你寫進 socket 的每一個位元組，在路徑上的每一台路由器、每一個中間設備眼裡都是明文。 下一篇補上這缺失的一層——TLS 與 HTTPS：如何在完全不改動 TCP 的前提下，把裸奔的位元組串流變成一條加密、且能驗證對方身分的通道。