本篇文章主要是從運輸層協議概述、UDP、TCP、可靠傳輸的工作原理、TCP首部格式、TCP可靠傳輸的實現、TCP流量控制、TCP的擁塞控制、TCP的連接管理這幾個方面進行解析。

一、運輸層協議概述

1.進程之間的通信

• 從通信和信息處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。

• 當兩臺主機使用網絡的核心部分的功能進行點對點通信的時候，只有位于邊緣部分的主機的協議棧才有運輸層，而網絡核心的路由器在轉發的時候只有用到下三層的功能。

image

應用進程之間的通信：

• 兩個主機進行通信實際上就是兩個主機中的應用進程互相通信。
• 應用進程之間的通信又稱為端到端的通信。 輸層的一個很重要的功能就是復用和分用。應用層不同進程的報文通過不同的端口向下交到運輸層，再往下就共用網絡層提供的服務。
• “運輸層提供應用進程間的邏輯通信”?！斑壿嬐ㄐ拧钡囊馑际牵哼\輸層之間的通信好像是沿水平方向傳送數據。但事實上這兩個運輸層之間并沒有一條水平方向的物理連接。

image

運輸層的主要功能：

• 運輸層為應用進程之間提供端到端的邏輯通信（但網絡層是為主機之間提供邏輯通信）。
• 運輸層還要對收到的報文進行差錯檢測。
• 運輸層需要有兩種不同的運輸協議，即面向連接的 TCP 和無連接的 UDP。

兩種不同的運輸協議：

• 運輸層向高層用戶屏蔽了下面網絡核心的細節（如網絡拓撲、所采用的路由選擇協議等），它使應用進程看見的就是好像在兩個運- 輸層實體之間有一條端到端的邏輯通信信道。
• 當運輸層采用面向連接的 TCP 協議時，盡管下面的網絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。
• 當運輸層采用無連接的 UDP 協議時，這種邏輯通信信道是一條不可靠信道。

2.運輸層的兩個主要協議

TCP/IP 的運輸層有兩個不同的協議：

• (1) 用戶數據報協議 UDP(User Datagram Protocol)
• (2) 傳輸控制協議 TCP(Transmission Control Protocol)

TCP與UDP：

• 兩個對等運輸實體在通信時傳送的數據單位叫作運輸協議數據單元 TPDU (Transport Protocol Data Unit)。
• TCP 傳送的數據單位協議是 TCP 報文段(segment)
• UDP 傳送的數據單位協議是 UDP 報文或用戶數據報。

image

• UDP 在傳送數據之前不需要先建立連接。對方的運輸層在收到 UDP 報文后，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 是一種最有效的工作方式。
• TCP 則提供面向連接的服務。TCP 不提供廣播或多播服務。由于 TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷。這不僅使協議數據單元的首部增大很多，還要占用許多的處理機資源。

3.運輸層的端口

• 運行在計算機中的進程是用進程標識符來標志的。
• 運行在應用層的各種應用進程卻不應當讓計算機操作系統指派它的進程標識符。這是因為在因特網上使用的計算機的操作系統種類很多，而不同的操作系統又使用不同格式的進程標識符。
• 為了使運行不同操作系統的計算機的應用進程能夠互相通信，就必須用統一的方法對 TCP/IP 體系的應用進程進行標志。

端口號(protocol port number)，簡稱為端口(port)：

• 解決這個問題的方法就是在運輸層使用協議端口號(protocol port number)，或通常簡稱為端口(port)。
• 雖然通信的終點是應用進程，但我們可以把端口想象是通信的終點，因為我們只要把要傳送的報文交到目的主機的某一個合適的目的端口，剩下的工作（即最后交付目的進程）就由 TCP 來完成。

軟件端口與硬件端口:

• 在協議棧層間的抽象的協議端口是軟件端口。
• 路由器或交換機上的端口是硬件端口。
• 硬件端口是不同硬件設備進行交互的接口，而軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。

TCP 的端口 :

• 端口用一個 16 位端口號進行標志。
• 端口號只具有本地意義，即端口號只是為了標志本計算機應用層中的各進程。在因特網中不同計算機的相同端口號是沒有聯系的。

三類端口號：

• 熟知端口，數值一般為 0~1023。
• 登記端口號，數值為1024~49151，為沒有熟知端口號的應用程序使用的。使用這個范圍的端口號必須在 IANA 登記，以防止重復。
• 客戶端口號或短暫端口號，數值為49152~65535，留給客戶進程選擇暫時使用。當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的動態端口號。通信結束后，這個端口號可供其他客戶進程以后使用。

二、用戶數據報協議UDP

1.UDP概述

• UDP 只在 IP 的數據報服務之上增加了很少一點的功能，即端口的功能和差錯檢測的功能。
• 雖然 UDP 用戶數據報只能提供不可靠的交付，但 UDP 在某些方面有其特殊的優點。

UDP的主要特點：

• UDP 是無連接的，即發送數據之前不需要建立連接。
• UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。
• UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通信的要求。
• UDP 支持一對一、一對多、多對一和多對多的交互通信。
• UDP 的首部開銷小，只有 8 個字節。

面向報文的UDP：

• 發送方 UDP 對應用程序交下來的報文，在添加首部后就向下交付 IP 層。UDP 對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。
• 應用層交給 UDP 多長的報文，UDP 就照樣發送，即一次發送一個報文。
• 接收方 UDP 對 IP 層交上來的 UDP 用戶數據報，在去除首部后就原封不動地交付上層的應用進程，一次交付一個完整的報文。
• 應用程序必須選擇合適大小的報文

image

image

• 用戶數據報 UDP 有兩個字段：數據字段和首部字段。首部字段有 8 個字節，由 4 個字段組成，每個字段都是兩個字節。

• 在計算檢驗和時，臨時把“偽首部”和 UDP 用戶數據報連接在一起。偽首部僅僅是為了計算檢驗和。

  
  
  

  image

三、傳輸控制協議 TCP 概述

1.TCP 最主要的特點

• TCP 是面向連接的運輸層協議。
• 每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP 連接只能是點對點的（一對一）。
• TCP 提供可靠交付的服務。
• TCP 提供全雙工通信。
• 面向字節流。

image

注意：

• TCP 連接是一條虛連接而不是一條真正的物理連接。
• TCP 對應用進程一次把多長的報文發送到TCP 的緩存中是不關心的。
• TCP 根據對方給出的窗口值和當前網絡擁塞的程度來決定一個報文段應包含多少個字節（UDP 發送的報文長度是應用進程給出的）。
• TCP 可把太長的數據塊劃分短一些再傳送。TCP 也可等待積累有足夠多的字節后再構成報文段發送出去。

2.TCP的連接

TCP 把連接作為最基本的抽象。

• 每一條 TCP 連接有兩個端點。
• TCP 連接的端點不是主機，不是主機的IP 地址，不是應用進程，也不是運輸層的協議端口。TCP 連接的端點叫做套接字(socket)或插口。
• 端口號拼接到(contatenated with) IP 地址即構成了套接字。
• 每一條 TCP 連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定

四、可靠傳輸工作原理

1.停止等待協議

image

• 在發送完一個分組后，必須暫時保留已發送的分組的副本。
• 分組和確認分組都必須進行編號。
• 超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。

image

• 使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網絡上實現可靠的通信。
• 這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest)。
• ARQ 表明重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組 。

缺點：

• 停止等待協議的優點是簡單，但缺點是信道利用率太低。

流水線傳輸：

• 發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認。
• 由于信道上一直有數據不間斷地傳送，這種傳輸方式可獲得很高的信道利用率。

image

2.連續ARQ協議

image

累積確認:

• 接收方一般采用累積確認的方式。即不必對收到的分組逐個發送確認，而是對按序到達的最后一個分組發送確認，這樣就表示：到這個分組為止的所有分組都已正確收到了。
• 累積確認有的優點是：容易實現，即使確認丟失也不必重傳。缺點是：不能向發送方反映出接收方已經正確收到的所有分組的信息。

Go-back-N(回退 N):

• 如果發送方發送了前 5 個分組，而中間的第 3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。
• 這就叫做 Go-back-N（回退 N），表示需要再退回來重傳已發送過的 N 個分組。
• 可見當通信線路質量不好時，連續 ARQ 協議會帶來負面的影響。

TCP 可靠通信的具體實現:

• TCP 連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口。
• TCP 的可靠傳輸機制用字節的序號進行控制。TCP 所有的確認都是基于序號而不是基于報文段。
• TCP 兩端的四個窗口經常處于動態變化之中。
• TCP連接的往返時間 RTT 也不是固定不變的。需要使用特定的算法估算較為合理的重傳時間。

五、TCP報文段的首部格式

image

• 源端口和目的端口字段——各占 2 字節。端口是運輸層與應用層的服務接口。運輸層的復用和分用功能都要通過端口才能實現。

• 序號字段——占 4 字節。TCP 連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。

• 確認號字段——占 4 字節，是期望收到對方的下一個報文段的數據的第一個字節的序號。

• 數據偏移（即首部長度）——占 4 位，它指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移”的單位是 32 位字（以 4 字節為計算單位）。

• 保留字段——占 6 位，保留為今后使用，但目前應置為 0。

• 緊急 URG —— 當 URG ? 1 時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應盡快傳送(相當于高優先級的數據)。

• 確認 ACK —— 只有當 ACK ? 1 時確認號字段才有效。當 ACK ? 0 時，確認號無效。

• 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的報文段，就盡快地交付接收應用進程，而不再等到整個緩存都填滿了后再向上交付。

• 復位 RST (ReSeT) —— 當 RST ? 1 時，表明 TCP 連接中出現嚴重差錯（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立運輸連接。

• 同步 SYN —— 同步 SYN = 1 表示這是一個連接請求或連接接受報文。

• 終止 FIN (FINis) —— 用來釋放一個連接。FIN ? 1 表明此報文段的發送端的數據已發送完畢，并要求釋放運輸連接。

• 窗口字段 —— 占 2 字節，用來讓對方設置發送窗口的依據，單位為字節。

• 檢驗和 —— 占 2 字節。檢驗和字段檢驗的范圍包括首部和數據這兩部分。在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的偽首部。

• 緊急指針字段 —— 占 16 位，指出在本報文段中緊急數據共有多少個字節（緊急數據放在本報文段數據的最前面）。

• 選項字段 —— 長度可變。TCP 最初只規定了一種選項，即最大報文段長度 MSS。MSS (Maximum Segment Size)是 TCP 報文段中的數據字段的最大長度。數據字段加上 TCP 首部才等于整個的 TCP 報文段。后面Tcp又增加了其他的選項：

  • 窗口擴大選項 ——占 3 字節，其中有一個字節表示移位值 S。新的窗口值等于TCP 首部中的窗口位數增大到(16 + S)，相當于把窗口值向左移動 S 位后獲得實際的窗口大小。
  • 時間戳選項——占10 字節，其中最主要的字段時間戳值字段（4 字節）和時間戳回送回答字段（4 字節）。
  • 選擇確認選項——在后面的 5.6.3 節介紹。

• 填充字段 —— 這是為了使整個首部長度是 4 字節的整數倍。

六、TCP可靠傳輸的實現

1.以字節為單位的滑動窗口

image

image

image

image

發送緩存與接收緩存的作用：

• 發送緩存用來暫時存放：
  • 發送應用程序傳送給發送方 TCP 準備發送的數據；
  • TCP 已發送出但尚未收到確認的數據。

image

• 接收緩存用來暫時存放：
  • 按序到達的、但尚未被接收應用程序讀取的數據；
  • 不按序到達的數據。

image

需要強調三點：

• A 的發送窗口并不總是和 B 的接收窗口一樣大（因為有一定的時間滯后）。
• TCP 標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到后，再按序交付上層的應用進程。
• TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。

2.超時重傳時間的選擇

• 重傳機制是 TCP 中最重要和最復雜的問題之一。
• TCP 每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。

加權平均往返時間：

• TCP 保留了 RTT 的一個加權平均往返時間 RTTS（這又稱為平滑的往返時間）。
• 第一次測量到 RTT 樣本時，RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTTS：
  新的 RTTS = (1 -a) * (舊的 RTTS)
  + a* (新的 RTT 樣本) (5-4)
  式中，0 < a < 1。若 ? 很接近于零，表示 RTT 值更新較慢。若選擇a 接近于 1，則表示 RTT 值更新較快。
• R- FC 2988 推薦的 a 值為 1/8，即 0.125。

超時重傳時間RTO:

• RTO 應略大于上面得出的加權平均往返時間 RTTS。
• RTO = RTTS + 4 * RTTD
• RTTD 是 RTT 的偏差的加權平均值。
• RFC 2988 建議這樣計算 RTTD。第一次測量時，RTTD 值取為測量到的 RTT 樣本值的一半。在以后的測量中，則使用下式計算加權平均的 RTTD：
  • 新的 RTTD = (1 - b) * (舊的RTTD)
    + b * |RTTS - 新的 RTT 樣本|
• b 是個小于 1 的系數，其推薦值是 1/4，即 0.25。

Karn算法：
在計算平均往返時間 RTT 時，只要報文段重傳了，就不采用其往返時間樣本。
這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較準確。

修正的 Karn 算法：

• 報文段每重傳一次，就把 RTO 增大一些：
  • 新的 RTO = y * (舊的 RTO)
• 系數 y 的典型值是 2 。
• 當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。
• 實踐證明，這種策略較為合理。

3.選擇確認SACK

• 接收方收到了和前面的字節流不連續的兩個字節塊。
• 如果這些字節的序號都在接收窗口之內，那么接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方不要再重復發送這些已收到的數據。

七、TCP的流量控制

1.利用滑動窗口實現流量控制

• 一般說來，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。
• 流量控制(flow control)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。

• 利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。

  
  
  

  image

持續計時器：

• TCP 為每一個連接設有一個持續計時器。
• 只要 TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。
• 若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶 1 字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
• 若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器。
• 若窗口不是零，則死鎖的僵局就可以打破了。

2.必須考慮傳輸效率

可以用不同的機制來控制 TCP 報文段的發送時機:

• 第一種機制是 TCP 維持一個變量，它等于最大報文段長度 MSS。只要緩存中存放的數據達到 MSS 字節時，就組裝成一個 TCP 報文段發送出去。
• 第二種機制是由發送方的應用進程指明要求發送報文段，即 TCP 支持的推送(push)操作。
• 第三種機制是發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過 MSS）發送出去。

八、TCP的擁塞控制

1.擁塞控制的一般原理

• 在某段時間，若對網絡中某資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞——產生擁塞(congestion)。
• 出現資源擁塞的條件：
  • 對資源需求的總和 > 可用資源
• 若網絡中有許多資源同時產生擁塞，網絡的性能就要明顯變壞，整個網絡的吞吐量將隨輸入負荷的增大而下降。

擁塞控制與流量控制的關系：

• 擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。
• 擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。
• 流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制。
• 流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收。

擁塞控制的一般原理：

• 擁塞控制是很難設計的，因為它是一個動態的（而不是靜態的）問題。
• 當前網絡正朝著高速化的方向發展，這很容易出現緩存不夠大而造成分組的丟失。但分組的丟失是網絡發生擁塞的征兆而不是原因。
• 在許多情況下，甚至正是擁塞控制本身成為引起網絡性能惡化甚至發生死鎖的原因。這點應特別引起重視。

開環控制和閉環控制：

• 開環控制方法就是在設計網絡時事先將有關發生擁塞的因素考慮周到，力求網絡在工作時不產生擁塞。
• 閉環控制是基于反饋環路的概念。屬于閉環控制的有以下幾種措施：
  • 監測網絡系統以便檢測到擁塞在何時、何處發生。
  • 將擁塞發生的信息傳送到可采取行動的地方。
  • 調整網絡系統的運行以解決出現的問題。

2.幾種擁塞控制方法

1.慢開始和擁塞避免

• 發送方維持一個叫做擁塞窗口 cwnd (congestion window)的狀態變量。擁塞窗口的大小取決于網絡的擁塞程度，并且動態地在變化。發送方讓自己的發送窗口等于擁塞窗口。如再考慮到接收方的接收能力，則發送窗口還可能小于擁塞窗口。
• 發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡中的分組數。

慢開始算法的原理：

• 在主機剛剛開始發送報文段時可先設置擁塞窗口 cwnd = 1，即設置為一個最大報文段 MSS 的數值。
• 在每收到一個對新的報文段的確認后，將擁塞窗口加 1，即增加一個 MSS 的數值。

• 用這樣的方法逐步增大發送端的擁塞窗口 cwnd，可以使分組注入到網絡的速率更加合理。

  
  
  

  image

傳輸輪次：

• 使用慢開始算法后，每經過一個傳輸輪次，擁塞窗口 cwnd 就加倍。
• 一個傳輸輪次所經歷的時間其實就是往返時間 RTT。
• “傳輸輪次”更加強調：把擁塞窗口 cwnd 所允許發送的報文段都連續發送出去，并收到了對已發送的最后一個字節的確認。
• 例如，擁塞窗口 cwnd = 4，這時的往返時間 RTT 就是發送方連續發送 4 個報文段，并收到這 4 個報文段的確認，總共經歷的時間。

設置慢開始門限狀態變量ssthresh：

• 慢開始門限 ssthresh 的用法如下：
• 當 cwnd < ssthresh 時，使用慢開始算法。
• 當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。
• 當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞避免算法。
• 擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢地增大，即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1，而不是加倍，使擁塞窗口 cwnd 按線性規律緩慢增長。

當網絡出現擁塞時：

• 無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有按時收到確認），就要把慢開始門限 ssthresh 設置為出現擁塞時的發送方窗口值的一半（但不能小于2）。
• 然后把擁塞窗口 cwnd 重新設置為 1，執行慢開始算法。

• 這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

  
  
  

  image

加法增大：
“加法增大”是指執行擁塞避免算法后，在收到對所有報文段的確認后（即經過一個往返時間），就把擁塞窗口 cwnd增加一個 MSS 大小，使擁塞窗口緩慢增大，以防止網絡過早出現擁塞。

“擁塞避免”并非指完全能夠避免了擁塞。利用以上的措施要完全避免網絡擁塞還是不可能的。
“擁塞避免”是說在擁塞避免階段把擁塞窗口控制為按線性規律增長，使網絡比較不容易出現擁塞。

2.快重傳和快恢復

• 快重傳算法首先要求接收方每收到一個失序的報文段后就立即發出重復確認。這樣做可以讓發送方及早知道有報文段沒有到達接收方。
• 發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段。

• 不難看出，快重傳并非取消重傳計時器，而是在某些情況下可更早地重傳丟失的報文段。

  
  
  

  image

快恢復算法 ：

• (1) 當發送端收到連續三個重復的確認時，就執行“乘法減小”算法，把慢開始門限 ssthresh 減半。但接下去不執行慢開始算法。
• (2)由于發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，即擁塞窗口 cwnd 現在不設置為 1，而是設置為慢開始門限 ssthresh 減半后的數值，然后開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。

image

發送窗口的上限值：

• 發送方的發送窗口的上限值應當取為接收方窗口 rwnd 和擁塞窗口 cwnd 這兩個變量中較小的一個，即應按以下公式確定：
  發送窗口的上限值=Min [rwnd, cwnd] (5-8)
• 當 rwnd < cwnd 時，是接收方的接收能力限制發送窗口的最大值。
• 當 cwnd < rwnd 時，則是網絡的擁塞限制發送窗口的最大值。

九、TCP 的運輸連接管理

1.運輸連接的三個階段

• 運輸連接就有三個階段，即：連接建立、數據傳送和連接釋放。運輸連接的管理就是使運輸連接的建立和釋放都能正常地進行。
• 連接建立過程中要解決以下三個問題：
  • 要使每一方能夠確知對方的存在。
  • 要允許雙方協商一些參數（如最大報文段長度，最大窗口大小，服務質量等）。
  • 能夠對運輸實體資源（如緩存大小，連接表中的項目等）進行分配。

客戶-服務器方式：

• TCP 連接的建立都是采用客戶服務器方式。
• 主動發起連接建立的應用進程叫做客戶(client)。
• 被動等待連接建立的應用進程叫做服務器(server)。

image

• A 的 TCP 向 B 發出連接請求報文段，其首部中的同步位 SYN = 1，并選擇序號 seq = x，表明傳送數據時的第一個數據字節的序號是 x。

• B 的 TCP 收到連接請求報文段后，如同意，則發回確認。B 在確認報文段中應使 SYN = 1，使 ACK = 1，其確認號ack = x ? 1，自己選擇的序號 seq = y。

• A 收到此報文段后向 B 給出確認，其 ACK = 1，確認號 ack = y ? 1。A 的 TCP 通知上層應用進程，連接已經建立。

• B 的 TCP 收到主機 A 的確認后，也通知其上層應用進程：TCP 連接已經建立。

2.TCP的釋放

image

• 數據傳輸結束后，通信的雙方都可釋放連接。現在 A 的應用進程先向其 TCP 發出連接釋放報文段，并停止再發送數據，主動關閉 TCP 連接。A 把連接釋放報文段首部的 FIN = 1，其序號seq = u，等待 B 的確認。

• B 發出確認，確認號 ack = u ? 1，而這個報文段自己的序號 seq = v。TCP 服務器進程通知高層應用進程。從 A 到 B 這個方向的連接就釋放了，TCP 連接處于半關閉狀態。B 若發送數據，A 仍要接收。

• 若 B 已經沒有要向 A 發送的數據，其應用進程就通知 TCP 釋放連接。

• A 收到連接釋放報文段后，必須發出確認。

• 在確認報文段中 ACK = 1，確認號 ack ? w ? 1，自己的序號 seq = u + 1。TCP 連接必須經過時間 2MSL 后才真正釋放掉。

A 必須等待 2MSL 的時間：

• 第一，為了保證 A 發送的最后一個 ACK 報文段能夠到達 B。
• 第二，防止 “已失效的連接請求報文段”出現在本連接中。A 在發送完最后一個 ACK 報文段后，再經過時間 2MSL，就可以使本連接持續的時間內所產生的所有報文段，都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。