1 功能

1.1 程式間通訊

從通訊和資訊處理的角度看,運輸層嚮應用層提供通訊服務,它屬於面向通訊部分的最高層,同時也是使用者功能中的最底層
當網路的邊緣部分中的兩個主機使用網路的核心部分的功能進行端到端的通訊時,只有位於網路邊緣部分的主機的協議棧才有運輸層,而網路核心部分中的路由器在轉發分組時都只用到下三層的功能

運輸層為相互通訊的應用程式提供了邏輯通訊

1.2 應用程式間通訊

兩個主機進行通訊實際上是兩個主機中的應用程式通訊
應用程式間通訊又稱為端到端的通訊
運輸層的一個很重要的功能就是複用和分用
應用層不同程式的報文透過不同的埠向下交到運輸層，再往下就共用網路層提供的服務。
運輸層提供應用程式間的邏輯通訊
"邏輯通訊"：運輸層之間的通訊好像是沿水平方向傳送資料。但事實上這兩個運輸層之間並沒有一條水平方向的物理連線

運輸層協議和網路層協議的主要區別

1.3 運輸層的主要功能

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

1.4 兩種不同的運輸協議

運輸層向高層使用者遮蔽了下面網路核心的細節,它使應用程式看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通訊通道
當運輸層採用面向連線的 TCP 協議時，儘管下面的網路是不可靠的（只提供盡最大努力服務），但這種邏輯通訊通道就相當於一條全雙工的可靠通道
當運輸層採用無連線的 UDP 協議時，這種邏輯通訊通道是一條不可靠通道

2 UDP與TCP異同

2.1 TCP 與 UDP

兩個對等運輸實體在通訊時傳送的資料單位叫作運輸協議資料單元 TPDU (Transport Protocol Data Unit)。
TCP 傳送的資料單位協議是 TCP 報文段(segment)
UDP 傳送的資料單位協議是 UDP 報文或使用者資料包

TCP/IP 體系中的運輸層協議
UDP 在傳送資料之前不需要先建立連線。對方的運輸層在收到 UDP 報文後，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 是一種最有效的工作方式。
TCP 則提供面向連線的服務。TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的、面向連線的運輸服務，因此不可避免地增加了許多的開銷。這不僅使協議資料單元的首部增大很多，還要佔用許多的處理機資源
運輸層的 UDP 使用者資料包與網際層的IP資料包有很大區別。IP 資料包要經過互連網中許多路由器的儲存轉發，但 UDP 使用者資料包是在運輸層的端到端抽象的邏輯通道中傳送的。
TCP 報文段是在運輸層抽象的端到端邏輯通道中傳送，這種通道是可靠的全雙工通道。但這樣的通道卻不知道究竟經過了哪些路由器，而這些路由器也根本不知道上面的運輸層是否建立了 TCP 連線。

3.1 運輸層的埠

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

3.2 需要解決的問題

由於程式的建立和撤銷都是動態的，傳送方几乎無法識別其他機器上的程式。
有時我們會改換接收報文的程式，但並不需要通知所有傳送方。
我們往往需要利用目的主機提供的功能來識別終點，而不需要知道實現這個功能的程式。
解決這個問題的方法就是在運輸層使用協議埠號(protocol port number)，或通常簡稱為埠(port)。
雖然通訊的終點是應用程式，但我們可以把埠想象是通訊的終點，因為我們只要把要傳送的報文交到目的主機的某一個合適的目的埠，剩下的工作（即最後交付目的程式）就由 TCP 來完成。

軟體埠與硬體埠

在協議棧層間的抽象的協議埠是軟體埠。
路由器或交換機上的埠是硬體埠。
硬體埠是不同硬體裝置進行互動的介面，而軟體埠是應用層的各種協議程式與運輸實體進行層間互動的一種地址

3.3 TCP 的埠

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

3.4 三類埠

熟知埠，數值一般為 0~1023。
登記埠號，數值為1024~49151，為沒有熟知埠號的應用程式使用的。使用這個範圍的埠號必須在 IANA 登記，以防止重複。
客戶埠號或短暫埠號，數值為49152~65535，留給客戶程式選擇暫時使用。當伺服器程式收到客戶程式的報文時，就知道了客戶程式所使用的動態埠號。通訊結束後，這個埠號可供其他客戶程式以後使用

4 TCP

4.1 TCP 最主要的特點

面向連線的運輸層協議
面向連線意味著兩個使用 TCP的應用在交換資料前必須先建立一個 TCP 連線,在一個 TCP 連線中，僅有兩方進行彼此通訊，廣播和多播不能用於 TCP
每一條 TCP 連線只能有兩個端點(endpoint)
每一條 TCP 連線只能是點對點的（一對一）
提供可靠交付的服務
提供全雙工通訊
面向位元組流
位元組流服務：兩個應用程式透過 TCP 連線，TCP 不在位元組中插入記錄識別符號
TCP對位元組流的內容不做任何解釋,不知道傳輸的位元組流資料是二進位制資料還是 ASCII 字元或其他型別資料,對位元組流的解釋由TCP連線雙方的應用層

TCP 面向流的概念

應當注意

TCP 連線是一條虛連線而不是一條真正的物理連線
TCP 對應用程式一次把多長的報文傳送到TCP 的快取中是不關心的
TCP 根據對方給出的視窗值和當前網路擁塞的程度來決定一個報文段應包含多少個位元組（而UDP 傳送的報文長度是應用程式給出的）
TCP 可把太長的資料塊劃分短一些再傳送
TCP 也可等待積累有足夠多的位元組後再構成報文段傳送出去

4.2 TCP 的連線

TCP 把連線作為最基本的抽象
每一條 TCP 連線有兩個端點
TCP 連線的端點不是主機,不是主機的IP 地址,不是應用程式,也不是運輸層的協議埠.TCP 連線的端點叫做套接字(socket)
埠號拼接到(contatenated with) IP 地址即構成了套接字

4.2.1 套接字 (Socket)

套接字 Socket = (IP地址: 埠號)
每一條 TCP 連線唯一地被通訊兩端的兩個端點（即兩個套接字）所確定
即：
TCP 連線 ::= {socket1, socket2}
= {(IP1: port1), (IP2: port2)}

Socket的多層含義

應用程式設計介面 API 稱為 socket API, 簡稱為 socket
socket API 中使用的一個函式名也叫作 socket
呼叫 socket 函式的端點稱為 socket
呼叫 socket 函式時其返回值稱為 socket 描述符，可簡稱為 socket
在作業系統核心中連網協議的 Berkeley 實現，稱為 socket 實現

4.2.2 四次揮手

TCP建立連線的三次握手

第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND態，待伺服器確認
SYN：同步序列編號(Synchronize Sequence Numbers)
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，伺服器進入SYN_RECV態
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手

完成三次握手，客戶端與伺服器開始傳送資料
一個完整的三次握手也就是請求---應答---再次確認

4.2.3 四次揮手

由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉

原則是
當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線
收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料
首先進行關閉的一方將執行主動關閉，另一方執行被動關閉

（1）客戶端A傳送一個FIN，用來關閉Client A ---->>>Server B的資料傳送
（2）B收FIN，發ACK，確認序號為收到的序號加1
（3）B關閉與A的連線，發FIN給A
（4）A發ACK報文確認，並將確認序號設定為收到序號加1

四次分手

4.2.4 為什麼建立連線協議是三次握手，而關閉連線卻是四次握手

服務端的listen狀態下的socket當收到syn報文的連線請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來傳送。
但關連線時，當收到對方的FIN報文時，僅表示對方沒有資料傳送給你了
但未必你所有的資料都全部傳送給對方了，所以你可以未必馬上關閉socket,即你可能還需傳送一些資料後，再發FIN來表示你可以關連線了，所以這裡的ACK報文和FIN報文多數情況下都是分開傳送的

4.3 可靠傳輸

4.3.1 工作原理

停止等待協議

注意

在傳送完一個分組後,必須暫時保留已傳送的分組的副本
分組和確認分組都必須進行編號
超時計時器的重傳時間應當比資料在分組傳輸的平均往返時間更長一些

確認丟失和確認遲到

4.3.2 可靠傳輸的實現

TCP 透過下列方式提供可靠性

將應用資料分割為 TCP 認為最合適傳送的資料塊
超時重傳
當 TCP 發出一個段後，他啟動一個定時器，等待目的端確認收到這個報文段
若不能及時收到一個確認，將重發這個報文段
當 TCP 收到發自 TCP 連結另一端的資料時，它將傳送一個確認（對於收到的請求，給出確認響應）
這個確認不是立即傳送，通常將推遲幾分之一秒（之所以推遲，可能是要對包做完校驗）
若 TCP 收到包，校驗出包有錯，丟棄報文段，不給出響應，TCP 傳送端會超時重傳
對於失序資料進行重排序，然後交給應用層
TCP 報文段作為 ip 資料包進行傳輸，而 ip 資料包的到達會失序，因此 TCP 報文段的到達也可能失序。若必要，TCP 將對收到的資料進行重新排列，以正確的順序交給應用層
對於重複資料，直接丟棄。
TCP 可以進行流量控制，防止較快主機致使較慢主機的緩衝區溢位。

使用上述的確認和重傳機制,我們就可以在不可靠的傳輸網路上實現可靠的通訊

這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest)

ARQ表明重傳的請求是自動進行的
接收方不需要請求傳送方重傳某個出錯的分組

4.3.3 TCP 可靠通訊的具體實現

TCP 連線的每一端都必須設有兩個視窗

一個傳送視窗
一個接收視窗

TCP 的可靠傳輸機制用位元組的序號進行控制:所有的確認都是基於序號而不是基於報文段

TCP 兩端的四個視窗經常處於動態變化中

TCP 連線的往返時間 RTT 也不是固定不變的:需要使用特定的演算法估算較為合理的重傳時間

5 TCP 報文段的首部格式

TCP 報文段結構

源/目的埠——各佔 2 位元組
埠是運輸層與應用層的服務介面:運輸層的複用和分用都要透過埠實現
序號——佔 4 位元組
傳送的資料流中的每一個位元組都編上一個序號:序號的值則指的是本報文段所傳送資料的第一個位元組的序號
確認號——佔 4 位元組
期望收到對方下一個報文段的資料的第一個位元組的序號
資料偏移（首部長度）——佔 4 位
指出報文段的資料起始處距離報文段的起始處有多遠:“資料偏移”的單位是 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 告訴對方 TCP：“我的快取所能接收的報文段的資料欄位的最大長度是 MSS 個位元組。”
- MSS (Maximum Segment Size)
  是 TCP 報文段中的資料欄位的最大長度.
  資料欄位加上 TCP 首部,才等於整個的 TCP 報文段。
視窗擴大 ——佔 3 位元組
有一個位元組表示移位值 S。
新的視窗值等於TCP 首部中的視窗位數增大到(16 + S)，相當於把視窗值向左移動 S 位後獲得實際的視窗大小
時間戳選項——佔10 位元組
其中最主要的欄位時間戳值欄位（4 位元組）和時間戳回送回答欄位（4 位元組）
選擇確認選項
填充
這是為了使整個首部長度是 4 位元組的整數倍

6 TCP 的流量控制

6.1 利用滑動視窗實現流量控制

一般我們總希望資料傳輸得更快一些.但如果傳送方把資料傳送得過快,接收方就可能來不及接收,這就會造成資料的丟失

流量控制(flow control)就是讓傳送方的傳送速率不要太快,既要讓接收方來得及接收,也不要使網路發生擁塞
利用滑動視窗機制可以很方便地在 TCP 連線上實現流量控制

TCP 在傳送資料時,傳送方的傳送視窗不能超過接收方給出的接收視窗的數值
TCP視窗的單位是位元組
當接收方接收資料的速度變慢時,就在確認報文中告訴傳送方接收視窗的大小
傳送方根據接收視窗的大小確認傳送視窗的大小,從而達到控制流量

流量控制舉例
持續計時器(persistence timer)
- 若視窗仍是零，則收到這個報文段的一方就重新設定持續計時器。
- 若視窗不是零，則死鎖的僵局就可以打破了
- TCP 為每一個連線設有一個持續計時器
- 只要 TCP 連線的一方收到對方的零視窗通知，就啟動持續計時器
- 若持續計時器設定的時間到期，就傳送一個零視窗探測報文段（僅攜帶 1 位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值

6.2 傳輸效率

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

TCP 維持一個變數，等於最大報文段長度(MSS)
只要快取中存放的資料達到MSS 位元組，就組裝成一個 TCP 報文段傳送出去
由傳送方的應用程式指明要求傳送報文段
即 TCP 支援的推送(push)操作
傳送方的一個計時器期限到了，這時就把當前已有的快取資料裝入報文段（但長度不能超過 MSS）傳送出去

7 TCP的擁塞控制

7.1 原理

在某段時間,若對網路中某資源的需求超過了該資源所能提供的可用部分,網路的效能就要變壞——產生擁塞(congestion)

出現擁塞的條件
對資源需求 > 可用資源
若網路中有許多資源同時產生擁塞，網路效能就會明顯變壞，整個網路的吞吐量將隨輸入負荷的增大而下降

擁塞控制與流量控制的關係

擁塞控制
- 所要做的都有一個前提，就是網路能夠承受現有的網路負荷
- 是一個全域性性的過程，涉及到所有的主機、所有的路由器，以及與降低網路傳輸效能有關的所有因素
流量控制
- 在給定的傳送端和接收端之間的點對點通訊量的控制
- 抑制傳送端發資料的速率，以便使接收端來得及接收
  
  擁塞控制所起的作用

7.2 擁塞控制的一般原理

擁塞控制是很難設計的，因為它是一個動態的問題

當前網路正朝著高速化的方向發展，這很容易出現快取不夠大而造成分組的丟失。但分組的丟失是網路發生擁塞的徵兆而不是原因。

在許多情況下，甚至正是擁塞控制本身成為引起網路效能惡化甚至發生死鎖的原因。這點應特別引起重視

7.3 開環控制和閉環控制

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

7.4 擁塞控制方法

慢開始和擁塞避免

傳送方維持一個叫做擁塞視窗 cwnd (congestion window)的狀態變數
擁塞視窗的大小取決於網路的擁塞程度，並且動態地在變化
傳送方讓自己的傳送視窗等於擁塞視窗
如再考慮到接收方的接收能力，則傳送視窗還可能小於擁塞視窗
傳送方控制擁塞視窗的原則
- 網路沒有出現擁塞，擁塞視窗就再增大一些，以便把更多的分組傳送出去
- 網路出現擁塞，擁塞視窗就減小一些，以減少注入到網路中的分組數

慢開始演算法的原理

在主機剛剛開始傳送報文段時可先設定擁塞視窗 cwnd = 1，即設定為一個最大報文段 MSS 的數值
在每收到一個對新的報文段的確認後，將擁塞視窗加 1，即增加一個 MSS 的數值
用這樣的方法逐步增大傳送端的擁塞視窗 cwnd，可以使分組注入到網路的速率更加合理

傳送方每收到一個對新報文段的確認（重傳的不算在內）就使 cwnd 加 1

傳輸輪次(transmission round)

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

設定慢開始門限狀態變數ssthresh

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

當網路出現擁塞時

無論在慢開始階段還是在擁塞避免階段，只要傳送方判斷網路出現擁塞（其根據就是沒有按時收到確認），就要把慢開始門限 ssthresh 設定為出現擁塞時的傳送方視窗值的一半（但不能小於2）
然後把擁塞視窗 cwnd 重新設定為 1，執行慢開始演算法
這樣做的目的就是要迅速減少主機傳送到網路中的分組數，使得發生擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢

2.1.5 乘法減小�(multiplicative decrease)

不論在慢開始階段還是擁塞避免階段，只要出現一次超時（即出現一次網路擁塞），就把慢開始門限值 ssthresh 設定為當前的擁塞視窗值乘以 0.5
當網路頻繁出現擁塞時，ssthresh 值就下降得很快，以大大減少注入到網路中的分組數

2.1.6 加法增大�(additive increase)

執行擁塞避免演算法後，在收到對所有報文段的確認後（即經過一個往返時間），就把擁塞視窗 cwnd增加一個 MSS 大小，使擁塞視窗緩慢增大，以防止網路過早出現擁塞

作者：芥末無疆sss
連結：
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。

計算機網路之運輸層