• Copyright(C)肖文棟教授@北京科技大學自動化學院

內容概要

6 The Transport Layer 6.1 The Transport Service 6.2 Elements of Transport Protocols 6.3 Congestion Control 6.4 The Internet Transport Protocols: UDP 6.5 The Internet Transport Protocols: TCP 6.6 Performance Issues* 6.7 Delay-tolerant Networking*

6.1 The Transport Service

6.1.1 Services Provided to the Upper Layers 6.1.2 Transport Service Primitives 6.1.3 Berkeley Sockets 6.1.4 An Example of Socket Programming: An Internet File Server

6.1.1 Services Provided to the Upper Layers

• 引入傳輸層的原因

–消除網路層的不可靠性: 傳輸層執行在使用者機器上,網路層程式碼主要執行在路由器上,使用者對網路層無真正的控制權,故加入傳輸層提高網路的QoS.

–提供從源端主機到目的端主機的可靠的、與實際使用的網路無關的資訊傳輸。

• 傳輸服務

–傳輸實體（transport entity）：完成傳輸層功能的硬軟體； –傳輸層實體利用網路層提供的服務向高層提供有效、可靠的服務 –傳輸層提供兩種服務

• 面向連線的傳輸服務：連線建立，資料傳輸，連線釋放

• 無連線的傳輸服務。

–1 ~ 4層稱為傳輸服務提供者（transport service provider），4層以上稱為傳輸服務使用者（transport service user）。

6.1.2 Transport Service Primitives

傳輸使用者（應用程式）通過傳輸服務原語訪問傳輸服務

一個簡單的建立和釋放連線的狀態圖

• 拆除連線方式有兩種

-不對稱方式：任何一方都可以關閉雙向連線；

-對稱方式：連線的兩個方向彼此獨立,每個方向需單獨關閉，雙方都執行DISCONNECT才能關閉整條連線

6.1.3 Berkeley Sockets套接字

TCP/IP中採用套接字原語,廣泛應用於Internet程式設計中,尤其是基於Unix的系統和Windows系統中(Winsock)

套接字原語

• 建立連線

-伺服器程式碼

• 呼叫socket建立一個新的套接字，並在傳輸層實體中分配表空間，返回一個檔案描述符用於以後呼叫中使用該套接字；

• 呼叫bind將一個地址賦予該套接字，使得遠端客戶程式能訪問該服務程式；

• 呼叫listen分配資料空間，以便儲存多個使用者的連線建立請求；

• 呼叫accept將服務程式阻塞起來，等待接收客戶程式發來的連線請求。當傳輸層實體接收到建立連線的段時，新建立一個和原來的套接字相同屬性的套接字並返回其檔案描述符。服務程式建立一個子程式處理此次連線，然後繼續等待發往原來套接字的連線請求。

• 建立連線

-客戶程式

• 呼叫socket建立一個新的套接字，並在傳輸層實體中分配表空間，返回一個檔案描述符用於在以後的呼叫中使用該套接字；

• 呼叫connect阻塞客戶程式，傳輸層實體開始建立連線，當連線建立完成時，取消阻塞；

• 資料傳輸

-雙方使用send和receive完成資料的全雙工傳送。

• 釋放連線

-釋放連線是對稱的,雙方都執行了close原語後連線被釋放。

6.1.4 套接字程式設計例項：Internet檔案傳輸

A client program requests a file from the server program, and the server responds by sending the whole file.

6.2 Elements of Transport Protocols

6.2.1 Addressing 6.2.2 Connection Establishment 6.2.3 Connection Release 6.2.4 Error Control and Flow Control 6.2.5 Multiplexing 6.2.6 Crash Recovery

Transport Protocol

6.2.1 定址（Addressing）

通常方法：定義埠，即傳輸服務訪問點TSAP（Transport Service Access Point），來表示應用程式，用來與另一應用程式建立連線。 網路層的類似端點（網路層地址）亦稱為網路服務訪問點

遠方客戶程式如何獲得服務程式的TSAP？

–方法1：預先約定、廣為人知的，如郵件伺服器固定在TCP埠25； –方法2：建立埠影射器。使用者向埠影射器查詢所需服務的TSAP，再與服務程式建立連線。注：新服務被建立時，其必須向埠影射器註冊。 –方法3：初始連線協議。

• 一個稱為程式伺服器（process server）的程式(inetd)同時在多個埠上監聽；

• 遠方客戶程式向它實際想訪問的服務程式的TSAP發出連線建立請求；

• 如果沒有服務程式在此TSAP上監聽，則遠方客戶和程式伺服器建立連線；

• 程式伺服器派生出所請求的新的服務程式，並使該程式繼承和遠端客戶的連線；

• 程式伺服器返回繼續監聽新的連線請求；

6.2.2建立連線

• 網路可能丟失、重複包，特別是延遲重複包的存在，導致傳輸層建立連線的複雜性（如重複建立連線）

• 解決延遲重複包的關鍵是丟棄過時的包

三次握手方案（three-way handshake）

6.2.3釋放連線

• 兩種連線釋放方法

–非對稱式：一方釋放連線，整個連線斷開，存在丟失資料的危險；

釋放連線

–對稱式：每個方向單獨釋放。即使主機傳送了Disconnect段後仍可接收資料。

–由於兩軍問題的存在，可以證明不存在安全的通過N次握手實現對稱式連線釋放的方法；

著名的協議舉例

• 佔據東、西兩個山頂的藍軍1和藍軍2與駐紮在山谷的白軍作戰。其力量對比是：單獨的藍軍1或藍軍2打不過白軍，但藍軍1和藍軍2協同作戰則可戰勝白軍。現藍軍1擬於次日正午向白軍發起攻擊。於是用計算機傳送電文給藍軍2。但通訊線路很不好，電文出錯或丟失的可能性較大（沒有電話可使用）。因此要求收到電文的友軍必須送回一個確認電文。但此確認電文也可能出錯或丟失。試問能否設計出一種協議使得藍軍1和藍軍2能夠實現協同作戰因而一定（即100 %而不是99.999…%）取得勝利？

結論

• 這樣無限迴圈下去，兩邊的藍軍都始終無法確定自己最後發出的電文對方是否已經收到。

• 沒有一種協議能夠藍軍能100% 獲勝。

釋放連線

–使用三次握手+ 定時器的方法釋放連線在絕大多數情況下是成功的。

6.2.4 Error Control and Flow Control

• 傳輸層的校驗和保護跨越各個網路路徑的段，採用端到端的校驗機制，與資料鏈路層校驗不同。

• 傳輸層時間延遲較長，必須使用大的滑動視窗

• 快取：由於網路層服務是不可靠的，傳輸層實體必須快取所有連線發出的段，而且為每個連線單獨做快取，以便用於錯誤情況下的重傳。

• 接收方的傳輸層實體既可以也可以不為特定的連線設定專用的特定快取。如接收端可讓設立一個緩衝池讓所有連線共享。

• 如何組織緩衝池？見下頁圖

–組織成大小統一的緩衝區構成的池，每個緩衝區容納一個段。 –使用可變大小的緩衝區 –為每個連線使用一個大的迴圈緩衝區。

利用緩衝區控制傳送端資料傳輸速率

• 初始時，傳送端根據其需求請求緩衝區

• 接收端根據能力分配儘可能多的緩衝區

• 傳送端每傳送一段, 接收端減少其緩衝區數。到0時停止傳送

• 接收端在逆向流量中稍帶上確認和緩衝區數

基於網路承載能力的流量控制機制

• 緩衝區空間不再限制最大流量時，網路的承載能力成為瓶頸

• 採用動態滑動視窗實現流量控制及擁塞控制

6.2.5多路複用

• 多路複用: 如多個傳輸層程式使用相同的網路地址

• 逆向多路複用:把傳輸層流量分攤到多條網路路徑上

Multiplexing

6.2.6Crash Recovery崩潰恢復

假設一主機向伺服器傳送檔案，伺服器有可能發生崩潰：

• 伺服器可能發生3種事件：傳送一確認（A）、將資料寫到輸出程式(W)、崩潰(C).

• 可能發生的6種順序AC(W), AWC, C(AW), C(WA), WAC, and WC(A)

6.3 Congestion Control

6.3.1 Desirable Bandwidth Allocation 6.3.2 Regulating the Sending Rate 6.3.3 Wireless Issues

6.3.1 Desirable Bandwidth Allocation理想頻寬分配

Efficiency and Power效率與功率: 實際吞吐量和延遲，在擁塞出現時效能開始下降。達到最大功率的負載表示了傳輸實體放置在網路上的有效負載

最大-最小公平性（Max-MinFairness）

如果分配給一個流的頻寬在不減少分配給其他流頻寬的前提下無法增加，則不給這個流更多頻寬。即，增加一個流的頻寬只會讓不太富裕的那些流情況變得更糟。

6.3.2 Regulating the Sending Rate

傳送速率受到流量控制與擁塞控制的限制

擁塞控制協議中的訊號

顯式擁塞協議（XCP，eXplicit Congestion Protocol）：路由器通知源端速率 顯式擁塞通知（ECN，Explicit Congestion Notification）：路由器在資料包中設定警告

速率控制法則

加法遞增乘法遞減(AIMD: Additive Increase Multiplicative Decrease) 法則能達到有效、公平的操作點

6.3.3 Wireless Issues

問題：通常傳輸協議把丟包視作擁塞發生的訊號，但在無線網路丟包幾乎都是由傳輸錯誤引起的。 擁塞控制觀察到的丟包應是由頻寬不足造成的，如何辦到？

• 使用無線鏈路上的重傳機制把無線網路的丟包掩蓋起來

-鏈路層的幀重傳與傳輸層的擁塞控制作用在不同尺度上

• 其他方案：如前向糾錯FEC

6.4 The Internet Transport Protocols: UDP

6.4.1 Introduction to UDP 6.4.2 Remote Procedure Call 6.4.3 Real-Time Transport Protocols

6.4.1 Introduction to UDP

UDP ：使用者資料包協議

• 無連線的傳輸協議

• 沒有流量控制、無擁塞控制、無重傳機制

6.4.2 Remote Procedure Call 遠端過程呼叫

6.4.3 Real-time Transport Protocols（RTP）實時傳輸協議

• 實時多媒體應用

RTP頭格式

RTCP實時傳輸控制協議

能處理反饋、同步、使用者介面等資訊

• 可以向源端提供延遲、抖動、頻寬、擁塞等網路特性的反饋資訊

• 處理流之間的同步

• 提供了命名不同源的方法，如可告訴使用者在和誰說話

帶有緩衝和抖動控制的播放

• 在接收端媒體播放之前進行緩衝，以減少抖動

帶有緩衝和抖動控制的播放

• 播放點的設定：決定等待多長時間取決於抖動

6.5 The Internet Transport Protocols: TCP

6.5.1 Introduction to TCP 6.5.2 The TCP Service Model 6.5.3 The TCP Protocol 6.5.4 The TCP Segment Header 6.5.5 TCP Connection Establishment 6.5.6 TCP Connection Release 6.5.7 TCP Connection Management Modeling 6.5.8 TCP Sliding Window 6.5.9 TCP Timer Management 6.5.10 TCP Congestion Control

6.5.1 Introduction to TCP

傳輸控制協議TCP（Transmission Control Protocol）

-面向連線的、可靠的、端到端的、基於位元組流的傳輸協議

使用者資料協議UDP（User Data Protocol）

-無連線的端到端傳輸協議

The IP layer gives no guarantee that datagrams will be delivered properly, nor any indication of how fast datagrams may be sent. It is up to TCP

• to send datagrams fast enough to make use of the capacity but not cause congestion

• to time out and retransmit any datagrams that are not delivered.

• to reassemble datagrams in the wrong order into messages in the proper sequence.

In short, TCP must furnish good performance with the reliability that most applications want and that IP does not provide.

6.5.2 The TCP Service Model

• 應用程式訪問TCP服務是通過在收發雙方建立套接字來實現的；

• 套接字的地址是用（IP地址，主機埠號）來表示的。1024以下的埠號被特權使用者保留，如FTP/21，HTTP/80；

• 每條連線用(套接字1,套接字2)來表示，是點到點的全雙工通道；

• TCP不支援多播（multicast）和廣播（broadcast）；

• TCP連線是基於位元組流的，而非訊息流。

• 對於應用程式發來的資料，TCP可以立即傳送，也可以快取一段時間以便一次傳送更多的資料。為了強迫資料傳送，可以使用PUSH標記；

• 對於緊急資料（urgent data），可以使用URGENT標記。

The TCP Service Model

6.5.3 The TCP Protocol

• 每個段有一個32位的序號；

• 傳輸實體之間使用段(segment)交換資料；

• 每個段包含一個20位元組的頭（選項部分另加）和0個或多個資料位元組。段的大小必須首先滿足65535位元組的IP包資料淨荷長度限制，還要滿足底層網路傳輸介質的最大傳輸單元（MTU）的限制，比如乙太網的MTU為1500位元組；

• TCP實體使用滑動視窗協議，確認序號等於接收方希望接收的下一個序號。

6.5.4 The TCP Segment Header

The TCP Segment Header

• 源埠和目的埠：各16位；

• 序號和確認號：以位元組為單位編號，各32位；

• TCP頭的長度：指明瞭TCP頭包含多少個32位的字，包含可選項域；

• 4位的保留域；

• 8個1位元的標識位：置1表示有效

-ECE：給TCP傳送端發訊號，告訴傳送端放慢傳送速度
-CWR：傳送端給接收端發訊號表明傳送端已放慢速率
-URG：和緊急指標配合使用，傳送緊急資料；
-ACK：表示確認號欄位是否有效；
-PSH：指示傳送方和接收方將資料不做快取，立刻傳送或接收；
-RST：由於不可恢復的錯誤重置連線；
-SYN：用於連線建立指示；
-FIN：用於連線釋放指示

• 視窗大小：用於基於可變滑動視窗的流控，指示傳送方從確認號開始可以再傳送視窗大小的位元組流；

• 校驗和：為增加可靠性，對TCP頭，資料和偽頭計算校驗和；

• 可選項域, 如指定願意接收的最大段長、時間戳等

6.5.5 TCP Connection Establishment

TCP連線管理

• 三次握手建立連線

-伺服器方執行LISTEN和ACCEPT原語，被動監聽； -客戶方執行connect原語，產生一個SYN為1和ACK為0的TCP段，表示連線請求； -伺服器方的傳輸實體接收到這個TCP段後，首先檢查是否有服務程式在所請求的埠上監聽，若沒有，回答RST置位的TCP段； -若有服務程式在所請求的埠上監聽，該服務程式可以決定是否接受該請求。在接受後，發出一個SYN置1和ACK置1的TCP段表示連線確認，並請求與對方的連線； -發起方收到確認後，發出一個SYN置0和ACK置1的TCP段表示給對方的連線確認； -若兩個主機同時試圖建立彼此間的連線，則只能建立一條連線。

6.5.6 TCP Connection Release

單向的連線釋放

釋放連線時，發出FIN位置1的TCP段並啟動定時器，在收到確認後關閉連線。若無確認並且超時，也關閉連線。

6.5.7 TCP Connection Management Modeling

TCP連線管理的有限狀態機

6.5.8 TCP Sliding Window

TCP的視窗管理機制

-基於確認和可變視窗大小； -視窗大小為0時，正常情況下，傳送方不能再發TCP段，但有兩個例外

• 緊急資料可以傳送；
• 為防止死鎖，傳送方可以傳送1位元組的TCP段，以便讓接收方重新宣告確認號和視窗大小。

如何改進傳輸層的效能？

-策略1：傳送方快取應用程式的資料，等到形成一個比較大的段再發出；

-策略2：在沒有可能進行“捎帶”的情況下，接收方延遲傳送確認段；

-策略3(Nagle演算法解決小資料包問題)：當應用程式每次向傳輸實體發出一個位元組時，傳輸實體發出第一個位元組並快取所有其後的位元組直至收到對第一個位元組的確認；然後將已快取的所有位元組組段發出並對再收到的位元組快取，直至收到下一個確認；

-策略4：使用Clark演算法解決低能視窗綜合症（silly window syndrome）

• 傻視窗症狀：當應用程式一次從傳輸層實體讀出一個位元組時，傳輸層實體會產生一個一位元組的視窗更新段，使得傳送方只能傳送一個位元組

• 解決辦法：強制接收端必須等待一段時間，直到有了一定數量的可用空間後再通告給對方。

6.5.9 TCP Timer Management

重傳計時器的值如何設定？

6.5.10 TCP Congestion Control

TCP處理網路擁塞的措施

• 傳送方維護兩個視窗：流量控制視窗和擁塞視窗，按兩個視窗的最小值傳送；

• 擁塞視窗是任何時候傳送端可以往網路傳送的位元組數

• 流量控制視窗指出了接收端可以緩衝的位元組數

利用突發資料包返回傳送端的速率得到最慢鏈路的速率

TCP的擁塞控制

慢速啟動: 在網路擁塞視窗啟動時，按指數規律增長。傳送一個報文段，收到一個確認，視窗大小變為2個報文段；傳送兩個報文段，收到兩個確認，將視窗大小增大到4個報文段；以此類推，直到視窗大小達到閾值（慢啟動閾值）。

TCP Tahoe

• 每當檢測到丟包（如確認時鐘超時），慢啟動閾值就被設定為當前擁塞視窗的一半

• TCP從慢速啟動切換到線性增加

• 利用重複確認識別資料包丟失。

• 資料包丟失後啟動快速重傳：慢啟動閾值被設定為當前擁塞視窗的一半，重新開始慢啟動過程。

TCP Reno

• 快速恢復（fastrecovery），閾值減半

• 加法遞增（RTT）+乘法遞減（RTT）