Chapter 3 Transport Layer (傳輸層)

Topic Overview 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原則 3.7 TCP 擁塞控制 R.-W. Hung 2011

Topic Overview (Cont.) 目標 (Goal) 了解傳輸層服務背後的原則 學習有關網際網路上的傳輸層協定 多工/解多工 可靠的資料傳輸 流量控制 擁塞控制 學習有關網際網路上的傳輸層協定 UDP：非預接式傳輸 TCP： 連線導向的傳輸 TCP： 擁塞控制 應用層 傳輸層 網路層 連結層 實體層 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式(無連線)傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.1 傳輸層服務 傳輸層服務以及協定 提供不同主機上執行應用程式之間的邏輯通訊 在終端系統間執行的傳輸協定 應用層可用的傳輸協定超過一個 3.1 傳輸層服務 傳輸層服務以及協定 提供不同主機上執行應用程式之間的邏輯通訊 邏輯通訊  從應用程式的觀點來看，兩台執行的行程的主機就像是直接連線；實際上，它們可能透過許多路由器及連結線進行連線 在終端系統間執行的傳輸協定 傳送端： 將應用程式的訊息分割成資料分段、傳送到網路層 接收端： 將資料分段重組成訊息、傳給應用層 應用層可用的傳輸協定超過一個 網際網路： TCP 以及 UDP 傳輸層協定的製作範圍 製作在終端系統(network edge) 網路中的路由器(network core)沒有製作此層，它們只製作到網路層 R.-W. Hung 2011

傳輸層的邏輯通訊 (logical communication) 3.1 傳輸層服務 (Cont.) 傳輸層的邏輯通訊 (logical communication) 應用層 傳輸層 網路層 資料連結層 實體層 連結層 實體層 網路層 連結層 實體層 網路層 終端系統對終端系統的邏輯傳輸 連結層 實體層 網路層 連結層 實體層 網路層 應用層 傳輸層 網路層 資料連結層 實體層 連結層 實體層 網路層 圖3.1 傳輸層提供了應用程式行程間的邏輯通訊而非實體的通訊 R.-W. Hung 2011

傳輸層 vs. 網路層 網路層：主機之間的邏輯通訊 傳輸層：行程之間的邏輯通訊 家庭的比喻：12 個小孩傳送信件給12個小孩 3.1 傳輸層服務 (Cont.) 傳輸層 vs. 網路層 網路層：主機之間的邏輯通訊 傳輸層：行程之間的邏輯通訊 依賴、增強、網路層服務 家庭的比喻：12 個小孩傳送信件給12個小孩 行程 = 小孩 應用程式訊息 = 信封中的信 主機 = 房子 傳輸層協定 = Royce 以及 Tommy (雙方收信的代表) 網路層協定 = 郵政服務 Royce Tommy  R.-W. Hung 2011

網際網路傳輸層協定 可靠的、有序的資料遞送 (TCP) 不可靠的、無序的資料遞送：UDP 不提供的服務： 3.1 傳輸層服務 (Cont.) 網際網路傳輸層協定 可靠的、有序的資料遞送 (TCP) 擁塞控制 (congestion control) 流量控制 (flow control) 連線建立 (connection creation) 不可靠的、無序的資料遞送：UDP “盡全力”的 IP的精簡延伸 不提供的服務： 延遲保證 頻寬保證 安全性保證 應用層 傳輸層 網路層 連結層 實體層 連結層 實體層 網路層 連結層 實體層 網路層 終端系統對終端系統的邏輯傳輸 連結層 實體層 網路層 連結層 實體層 網路層 應用層 連結層 實體層 網路層 傳輸層 網路層 連結層 【註】 TCP/UDP封包名稱 = segmentation (區段) 網路層封包名稱 = datagram (資料包) 實體層 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.2 多工和解多工 多工(multiplexing)和解多工(Demultiplexing) 收集多個socket的資料、 3.2 多工和解多工 多工(multiplexing)和解多工(Demultiplexing) 收集多個socket的資料、 用標頭 (稍後將用在解多工) 將每個資料片段封裝成資料區段 傳送端主機的多工： 將收到的資料分段傳送給正確的socket 接收端主機的解多工： = socket = 行程 應用層 應用層 應用層 P3 P1 P2 P4 傳輸層 傳輸層 傳輸層 網路層 網路層 網路層 資料連結層 資料連結層 資料連結層 實體層 實體層 實體層 主機 1 (傳送端) 主機 2 (接收端) 主機 3 (傳送端) 圖3.2 傳輸層的多工與解多工 R.-W. Hung 2011

多工/解多工 家庭比喻  Royce Tommy Tommy從郵差(網路層)那邊收取套信 Tommy將套信拆封 3.2 多工和解多工 (Cont.) 多工/解多工 家庭比喻  Royce Tommy Tommy從郵差(網路層)那邊收取套信 Tommy將套信拆封 並將信件交給正確收信人(解多工) Royce蒐集信件 並封裝成一組套信(多工) Royce將套信交給郵差(網路層)傳遞 R.-W. Hung 2011

解多工如何運作 ? 主機收到網路層的 IP 資料包 (IP datagram) 3.2 多工和解多工 (Cont.) 解多工如何運作 ? 主機收到網路層的 IP 資料包 (IP datagram) 每一個IP資料包都擁有來源端 IP位址以及目的端IP位址 每一個IP資料包載送 1 個傳輸層資料區段 (transport-layer segment) 每一個傳輸層資料區段都擁有來源端埠號以及目的端埠號 主機使用 IP 位址以及埠號(port number) 將資料區段送到正確的socket 同台電腦中的每個socket都有一個唯一的port number，藉以識別socket 32 位元 來源端埠號 # 目的端埠號 # 其它標頭欄位 應用程式資料 (訊息) 圖3.3 傳輸層資料區段(segment)格式 R.-W. Hung 2011

Socket 行程的基本通訊 Socket 可由一個 IP位址 和 一個埠號 (port number) 所組成 3.2 多工和解多工 (Cont.) Socket 行程的基本通訊 Socket 可由一個 IP位址 和 一個埠號 (port number) 所組成 一組行程使用一對插座 (雙方各一個) 在網路上通訊 R.-W. Hung 2011

無連線(connectionless)的解多工  UDP 3.2 多工和解多工 (Cont.) 無連線(connectionless)的解多工  UDP 以埠號產生socket： DatagramSocket mySocket1 = new DatagramSocket(12534); DatagramSocket mySocket2 = new DatagramSocket(12535); 以兩組資料識別 UDP socket ： (目的端 IP 位址、目的端埠號) 當主機收到 UDP 資料區段(UDP segment)時： 確認資料區段中的目的端埠號 以此埠號將UDP資料區段傳送到socket 具有不同來源端 IP位址的IP資料包(網路層封包) 和/或 來源端埠號會被送到同一個 socket (若目的端埠號相同) R.-W. Hung 2011

無連線(connectionless)的解多工 (Cont.) DatagramSocket serverSocket = new DatagramSocket(6428); 用戶端 IP：A 伺服端 IP：C 用戶端 IP：B P2 P1 P1 P3 SP：6428 DP：9157 SP：6428 DP：5775 SP：9157 DP：6428 SP：5775 DP：6428 SP = Source Port DP = Destination Port SP 提供 “回傳埠號” 圖3.4 來源端與目的端埠號的交換 R.-W. Hung 2011

連線(connection)的解多工  TCP 3.2 多工和解多工 (Cont.) 連線(connection)的解多工  TCP TCP socket 以四組資料加以識別： 來源端 IP 位址 來源端埠號 目的端 IP 位址 目的端埠號 接收端主機使用全部的四個數值將資料區段送到適當的 socket 伺服端主機可能同時支援許多TCP sockets： 每個 socket 以它自己的四組資料加以識別 Web 伺服器針對連結到它的每一個用戶端都有不同的socket 非永久性 HTTP 針對每一次的請求都有不同的 socket R.-W. Hung 2011

連線(connection)的解多工 (Cont.) 用戶端 IP：A Web 伺服端 IP：C 每個連線由一個HTTP行程控制 (HTTP thread) 用戶端 IP：B P1 P1 P2 P4 P5 P6 P3 傳輸層 解多工控制 SP： 7546 DP： 80 S_IP： A D_IP：C SP： 7532 DP： 80 S_IP： A D_IP：C SP： 4560 DP： 80 S_IP： B D_IP：C SP = Source Port DP = Destination Port S_IP = Source IP addr. D_IP = Destination IP addr. 圖3.5 兩個用戶端，使用相同的目的端埠號(80)來與相同的Web伺服器進行通訊 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式(無連線)傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.3 非預接式傳輸  UDP UDP (User Datagram Protocol)： 使用者資料包協定 RFC 768 實際的、精簡的網際網路傳輸協定 “盡全力” 的服務、UDP 資料區段可能： 遺失  不保證資料會到達目的地 不按順序傳送給應用程式 非預接式服務 在 UDP 傳送端和接收端之間沒有交握程序 (non-handshaking) 每一個 UDP 資料區段的處理和其它資料區段是獨立的 為何會使用 UDP ? (1) 不需建立連線 (建立連線會增加延遲) (2) 簡單：在傳送端和接收端不需維持連線狀態 (3) 較小的封包標頭 (4) 沒有擁塞控制：UDP 可以盡可能地快速傳送資料  DNS 採用此種傳輸方式 R.-W. Hung 2011

UDP (Cont.) 常見的網際網路應用及其下層的傳輸協定 應用 應用層協定 底層傳輸層協定 電子郵件 SMTP TCP 遠端終端機連線 Telnet 網頁 HTTP 檔案傳輸 FTP 遠端檔案伺服器 NFS 一般是UDP 串流多媒體 私人協定 UDP或TCP 網際網路電話 網路管理 SNMP 繞徑協定 RIP 領域名稱系統 DNS 圖3.6 常見的網際網路應用及其下層的傳輸協定 R.-W. Hung 2011

UDP (Cont.) 通常用在串流的多媒體應用程式 其他使用 UDP 的有 使用UDP的可靠傳輸？  在應用層加入可靠性的機制 可以容忍資料遺失 易受速率影響 其他使用 UDP 的有 DNS SNMP (Simple Network Management Protocol) 使用UDP的可靠傳輸？  在應用層加入可靠性的機制 32 位元 來源端埠號 # 目的端埠號 # 長度 檢查和 以位元組為單位的 UDP資料區段大小 (包含標頭) 應用程式資料 (訊息) 圖3.7 UDP 資料區段(segment)格式 R.-W. Hung 2011

UDP (Cont.) UDP 檢查和 (check sum) 目標： 偵測傳送的資料區段中的 “錯誤” (例如，偵測被翻轉的位元) 作法： 傳送端： 將資料區段的內容視為一列16位元的整數 檢查和：資料區段內容的加法 (1的補數和) 傳送端將檢查和的值放入UDP的檢查和欄位 接收端： 計算收到的資料區段的檢查和 確認計算出來的檢查和是否和檢查和欄位中的相等： NO – 偵測到錯誤 YES – 沒有偵測到錯誤。但是仍然可能有錯誤? 後面有更多介紹  資料+檢查和 = 1 1 1 1 1 1 ... 1 1 Ex: 0110011001100000 0101010101010101 1000111100001100 0 1 1 0 0 1 1 0 0 1 1 0 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 1 0 1 0 0 1 0 1 0 1 1 0 0 0 0 0 1 +) 0 1 0 0 1 0 1 0 1 1 0 0 0 0 1 0 1’s補數: 01&10 check sum = 1 0 1 1 0 1 0 1 0 0 1 1 1 1 0 1 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.4 可靠資料傳輸的原理 實作可靠資料傳輸 (reliable data transfer) 的分層 應用層、傳輸層、資料連結層 3.4 可靠資料傳輸的原理 實作可靠資料傳輸 (reliable data transfer) 的分層 應用層、傳輸層、資料連結層 可以列在網路問題中的前十大清單 不可靠通道(資料會遺失及錯誤)的特性決定了 可靠資料傳輸協定 (rdt, reliable data transfer) 的複雜性 應用層 傳輸層 網路層 連結層 實體層 圖3.8 可靠的資料傳輸  服務模型與服務實作 R.-W. Hung 2011

rdt_rcv()：當封包抵達接收端的通道時被呼叫 3.4.1 建立可靠資料傳輸協定 建立可靠的資料傳輸 rdt_send()：被上層呼叫 (例如應用層) 。 將資料傳遞給接收端的上層協定 deliver_data()：被 rdt 呼叫。 將資料傳送到上層 send side receive side rdt udt_send( ) udt_send()：被rdt呼叫。 經由不可靠的通道將封包 傳送給接收端 (un-reliable data transfer) rdt_rcv()：當封包抵達接收端的通道時被呼叫 R.-W. Hung 2011

有限狀態機 (FSM) Finite-State Machine 說明傳送端、 接收端可靠資料傳輸協定的狀態/事件轉移 導致狀態轉換的事件 3.4.1 建立可靠資料傳輸協定 (Cont.) 有限狀態機 (FSM) Finite-State Machine 說明傳送端、 接收端可靠資料傳輸協定的狀態/事件轉移 導致狀態轉換的事件 狀態轉換時所採取的動作 狀態 1 狀態 2 事件 動作 狀態： 在這個“狀態”時，下一個狀態將唯一地被下一個事件所決定 R.-W. Hung 2011

FSM (Cont.) 例子 鬧鐘響 刷牙、吃飯、上學 睡覺 上課 3.4.1 建立可靠資料傳輸協定 (Cont.) R.-W. Hung 2011

Rdt1.0  使用可靠通道的可靠傳輸 底層的通道是完全可靠的 傳送端和接收端擁有各自的 FSM： 沒有位元錯誤 沒有資料遺失 3.4.1 建立可靠資料傳輸協定 (Cont.) Rdt1.0  使用可靠通道的可靠傳輸 底層的通道是完全可靠的 沒有位元錯誤 沒有資料遺失 傳送端和接收端擁有各自的 FSM： 傳送端將資料送入底層的通道 接收端從底層的通道接收資料 rdt_send(data) rdt_rcv(packet) 等待上層 傳來的呼叫 等待下層 傳來的呼叫 packet = make_pkt(data) udt_send(packet) extract (packet, data) deliver_data(data) (a) 傳送端 (b) 接收端 圖3.9 使用絕對可靠通道的協定 R.-W. Hung 2011

Rdt1.0  使用可靠通道的可靠傳輸 (Cont.) 上層 (eg. 應用層) sending process receiver process data rdt_send(data) 本層 (eg. 傳輸層) 可靠傳輸 協定 make_packet(data) header data udt_send(packet) 可靠通道 下層 (eg. 網路層) R.-W. Hung 2011

Rdt1.0  使用可靠通道的可靠傳輸 (Cont.) 上層 (eg. 應用層) sending process receiver process data extract(packet) 本層 (eg. 傳輸層) 可靠傳輸 協定 header data 可靠通道 rdt_rcv(packet) 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0  可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉 (位元錯誤) 問題：如何回覆錯誤 ? 3.4.1 建立可靠資料傳輸協定 (Cont.) Rdt2.0  可能產生位元錯誤的通道 底層的通道可能會將封包中的位元翻轉 (位元錯誤) 偵測位元錯誤的檢查和 問題：如何回覆錯誤 ? 確認 (ACKs)：接收端明確地告訴傳送端封包的傳送 OK (正確) 否定確認 (NAKs)：接收端明確地告訴傳送端封包的傳送有問題 (不正確) 當收到NAK時，傳送端會重傳封包 rdt2.0 的新機制 (優於rdt1.0)：具ARQ協定(Auto Repeat reQuest) 錯誤偵測 接收端回饋：控制訊息 (ACK、NAK) 接收端  傳送端 R.-W. Hung 2011

Rdt2.0 (Cont.) FSM 說明 (a) 傳送端 (b) 接收端 rdt_send(data) packet = make_pkt(data, checksum) udt_send(packet) rdt_rcv(rcvpkt) && isNAK(rcvpkt) 等待上層 傳來的呼叫 等待接收端 傳來ACK/NAK udt_send(packet) rdt_rcv(rcvpkt) && not_correct(rcvpkt) rdt_scv(rcvpkt) && isACK(rcvpkt) packet = make_pkt(NAK) udt_send(packet) None (a) 傳送端 等待下層 傳來的呼叫 rdt_rcv(rcvpkt) && is_correct(rcvpkt) extract(rcvpkt, data) deliver_data(data) packet = make_pkt(ACK) udt_send(packet) (b) 接收端 圖3.10 使用會產生位元錯誤通道的協定 R.-W. Hung 2011

Rdt2.0 (Cont.) 沒有錯誤時的運作： (a) 傳送端 (b) 接收端 rdt_send(data) packet = make_pkt(data, checksum) udt_send(packet) rdt_rcv(rcvpkt) && isNAK(rcvpkt) 等待上層 傳來的呼叫 等待接收端 傳來ACK/NAK udt_send(packet) rdt_rcv(rcvpkt) && not_correct(rcvpkt) rdt_scv(rcvpkt) && isACK(rcvpkt) packet = make_pkt(NAK) udt_send(packet) None (a) 傳送端 等待下層 傳來的呼叫 rdt_rcv(rcvpkt) && is_correct(rcvpkt) extract(rcvpkt, data) deliver_data(data) packet = make_pkt(ACK) udt_send(packet) (b) 接收端 R.-W. Hung 2011

Rdt2.0 (Cont.) 沒有錯誤時的運作： (Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) data rdt_send(data) 本層 (eg. 傳輸層) 可靠傳輸 協定 make_packet(data) header data udt_send(packet) 不可靠通道 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 沒有錯誤時的運作： (Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) data extract(packet) 本層 (eg. 傳輸層) 可靠傳輸 協定 header data 不可靠通道 rdt_rcv(rcvpkt) rdt_rcv(packet) && correct 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 沒有錯誤時的運作： (Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) data extract(packet) 本層 (eg. 傳輸層) 可靠傳輸 協定 不可靠通道 rdt_rcv(rcvpkt) ACK udt_send(ACK) 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 發生錯誤時的運作： (a) 傳送端 (b) 接收端 rdt_send(data) packet = make_pkt(data, checksum) udt_send(packet) rdt_rcv(rcvpkt) && isNAK(rcvpkt) 等待上層 傳來的呼叫 等待接收端 傳來ACK/NAK udt_send(packet) rdt_rcv(rcvpkt) && not_correct(rcvpkt) rdt_scv(rcvpkt) && isACK(rcvpkt) packet = make_pkt(NAK) udt_send(packet) None (a) 傳送端 等待下層 傳來的呼叫 rdt_rcv(rcvpkt) && is_correct(rcvpkt) extract(rcvpkt, data) deliver_data(data) packet = make_pkt(ACK) udt_send(packet) (b) 接收端 R.-W. Hung 2011

Rdt2.0 (Cont.) 發生錯誤時的運作：(Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) data rdt_send(data) 本層 (eg. 傳輸層) 可靠傳輸 協定 make_packet(data) header data udt_send(packet) 不可靠通道 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 發生錯誤時的運作：(Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 header data 不可靠通道 rdt_rcv(rcvpkt) rdt_rcv(packet) && incorrect 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 發生錯誤時的運作：(Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 不可靠通道 rdt_rcv(rcvpkt) NAK udt_send(NAK) 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 發生錯誤時的運作：(Cont.) 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 sending process receiver process 上層 (eg. 應用層) 本層 (eg. 傳輸層) 可靠傳輸 協定 header data 不可靠通道 udt_send(packet) rdt_rcv(packet) 下層 (eg. 網路層) R.-W. Hung 2011

Rdt2.0 (Cont.) 致命的缺點： 假如 ACK/NAK 損毀了會如何？ 重複的處理： 傳送端不知道接收端發生了什麼事！ 沒辦法直接重傳：可能會重複 重複的處理： 假如 ACK/NAK損壞了，傳送端會重新傳送目前的封包 傳送端會在每個封包加上序號(sequence number) 接收端根據序號刪掉 (不往上傳) 重複的封包 Rdt2.0 為停止並等待 (stop-and-wait) 協定 傳送端傳送一個封包，並等待接收端的回應 沒有效率 使用 Rdt3.0 改進  Rdt2.1 & Rdt2.2 (自我學習) R.-W. Hung 2011

Rdt3.0  使用會發生錯誤及遺失封包的通道 假設：底層的通道(channel)也可能遺失封包 (資料或 ACK) 3.4.1 建立可靠資料傳輸協定 (Cont.) Rdt3.0  使用會發生錯誤及遺失封包的通道 假設：底層的通道(channel)也可能遺失封包 (資料或 ACK) 檢查和 (checksum, 檢查位元錯誤) 封包序號 (2個封包序號, M0、M1) ACK (2個ACK, ACK0、ACK1) 重傳 (使用Timer設定重傳時間) 方法：傳送端等待ACK “合理的” 時間 假如在這段時間內沒有收到 ACK，則重傳 假如封包 (或 ACK) 只是延遲了 (沒有遺失)：(過早逾時) 重傳會導致重複，但是封包序號的使用能夠處理這個情況 接收端必須指定確認的封包序號 需要倒數計時器(countdown timer) R.-W. Hung 2011

3.4.1 建立可靠資料傳輸協定 (Cont.) Rdt3.0 (Cont.) 圖3.16 Rdt3.0 的位元變換協定 (alternating-bit protocol, M0/M1交換) R.-W. Hung 2011

Rdt3.0 (Cont.) 圖3.16 Rdt3.0 的位元轉換協定 (Cont.) 3.4.1 建立可靠資料傳輸協定 (Cont.) R.-W. Hung 2011

Rdt3.0 (Cont.) None None None None rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt, 1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) None None 等待從上 一層傳來 的呼叫M0 等待 ACK 訊息0 timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt, 1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt, 0) stop_timer stop_timer 等待ACK 訊息1 等待從上 一層傳來 的呼叫M1 timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) rdt_send(data) None rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt, 0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer None 圖3.15 Rdt3.0 傳送端的FSM R.-W. Hung 2011

Rdt3.0 (Cont.) Rdt3.0 的效能 Rdt3.0 能夠運作，但是效能很糟 範例：1 Gbps 的連結線、15 毫秒(ms) 終端對終端傳遞延遲、1KB 的封包傳送 傳送時間 dtrans = 傳送端(通道)使用率(utilization) (傳送端將位元傳入通道的時間比例) Usender = 傳送端處於忙碌的時間只有0.027%  效能極差 網路協定限制了實體資源的使用！ 解決方案 傳送端不使用 stop-and-wait 運作，而允許同時送出多個封包，不需每個封包一一等待確認(ACK) Pipeline (3.4.2節) R.-W. Hung 2011

Rdt3.0 (Cont.) Rdt3.0 的效能 (Cont.) Rdt3.0： 停止並等待的機制 傳送端 接收端 在 t = 0 時，傳送第1個封包的第1個位元 在 t = L / R 時，傳送第1個封包的最後1個位元 第一個封包的第一個位元到達 RTT (round-trip time) 第一個封包的最後一個位元到達，並且送出ACK 在 t = RTT + L / R 時，ACK到達，然後送出下1個封包 圖3.18(a) Rdt3.0 的停止並等待協定 R.-W. Hung 2011

3.4.2 管線化的可靠資料傳輸協定 (Pipeline) 管線化協定 管線化 (pipelining)： 傳送端允許多個、 “傳送中的”、 還沒有被確認的封包 序號的範圍必須增加 傳送端 和/或 接收端需要暫存器 兩種管線化協定的一般性型態 回溯N (Go-Back N, GBN) 選擇性重複 (Selective Repeat, SR) 圖3.17 (a)停止並等待協定 (b)管線化協定 R.-W. Hung 2011

管線化  增加使用率 RTT 傳送端 接收端 續 Rdt3.0 範例：(同時送出3個封包) 增加3倍的使用率！ 3.4.2 管線化的可靠資料傳輸協定 (Cont.) 管線化  增加使用率 傳送端 接收端 在 t = 0 時，傳送第1個封包的第1個位元 在 t = L/R 時，傳送第1個封包的最後一個位元 第1個封包的第1個位元到達 RTT 第1個封包的最後1個位元到達、送出ACK 第2個封包的最後1個位元到達、送出ACK 第3個封包的最後1個位元到達、送出ACK ACK arrives、 send next packet、 t = RTT + L / R 續 Rdt3.0 範例：(同時送出3個封包) 增加3倍的使用率！ 圖3.18(b) 管線化傳輸協定 R.-W. Hung 2011

回溯N (GBN) 概念 傳送端製作 允許傳送端同時傳送多個封包而不需等待確認 但管線中未被確認的封包數量不得超過某個可容許的整數N 3.4.3 回溯N協定 (Go-Back N, GBN) 回溯N (GBN) 概念 允許傳送端同時傳送多個封包而不需等待確認 封包標頭的 k-位元序號 (封包序號) 但管線中未被確認的封包數量不得超過某個可容許的整數N 又稱為 sliding-window protocol (滑動視窗協定) 傳送端製作 base：最久未被確認的封包序號 nextseqnum：下一個要被傳送的封包序號 當 nextseqnum  base + 1  N，允許傳送封包 (傳送後nextseqnum++) ；否則，不允許傳送封包 當收到確認base封包(ACK base) ，base++ GBN Applet: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/go-back-n/index.html 圖3.19 回溯N協定中，傳送端的封包序號觀點 R.-W. Hung 2011

回溯N (Cont.)      GBN 傳送端的 FSM Initial rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum, data, chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data)  base=1 nextseqnum=1 Initial  start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) timeout  等待 rdt_rcv(rcvpkt) && error(rcvpkt) None  base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && not_error(rcvpkt)  圖3.20 回溯N協定中，傳送端的FSM圖 R.-W. Hung 2011

回溯N (Cont.)    GBN 接收端的 FSM 只使用ACK：只為接收順序正確的封包傳送 ACK 順序不正確的封包： 只需要記住 expectedseqnum (期望收到的下一個封包序號) 順序不正確的封包： 刪除 (不會暫存)  接收端沒有暫存器! 重新回應最高的順序正確封包 udt_send(sndpkt) default  rdt_rcv(rcvpkt) && not_error(rcvpkt) && hasseqnum(rcvpkt, expectedseqnum) extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(expectedseqnum, ACK, chksum) udt_send(sndpkt) expectedseqnum++  expectedseqnum = 1 sndpkt = make_pkt(0, ACK, chksum) Initial  等待 圖3.21 回溯N協定中，接收端的FSM圖 R.-W. Hung 2011

回溯N (Cont.) GBN 的運作 window TCP採用GBN技術 GBN Applet: 圖3.22 回溯N協定的運作 http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/go-back-n/index.html 圖3.22 回溯N協定的運作 R.-W. Hung 2011

3.4.4 選擇性重複協定 (Selective Repeat, SR) GBN的問題 單一封包的錯誤，將導致其後的所有封包均需重傳 (重新傳送大量封包) 選擇性重複 傳送端只重傳沒有收到 ACK 的封包 傳送端針對每一個未確認的封包需要一個計時器 接收端分別確認所有正確接收的封包 依需要暫存封包、 最終會依序傳送到上一層 傳送端視窗 N 個連續的序號 再次、用來限制傳送出去的、 未確認的封包序號 SR Applet: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html R.-W. Hung 2011

選擇性重複協定 (Cont.) SR的傳送端、 接收端視窗 圖3.23 選擇性重複協定中，傳送端與接收端的封包序號觀點 R.-W. Hung 2011

選擇性重複協定 (Cont.) 選擇性重複的運作 來自上層的資料： 封包n 在 [rcvbase, rcvbase+N1] 中 傳送端 接收端 來自上層的資料： 假如下一個可用的序號在視窗內，則傳送封包 timeout(n)： 重送封包 n；重新啟動計時器 每個封包都有timer ACK(n) 在 [sendbase, sendbase+N]中： 將封包 n 標示為已收到的 假如 n 為未確認的封包中最小的，將視窗的 base 往前移到下一個未回應的序號 封包n 在 [rcvbase, rcvbase+N1] 中 傳送 ACK(n) 不正確的順序： 暫存區 正確順序： 遞送 (也遞送暫存區內順序錯誤的封包)、將視窗前進到下一個未接收的封包 封包 n 在 [rcvbaseN, rcvbase1]中 ACK(n) 否則： 忽略該封包 R.-W. Hung 2011

選擇性重複協定 (Cont.) 選擇性重複的運作 (Cont.) SR Applet: 圖3.26 選擇性重複協定的運作 http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/SR/index.html 圖3.26 選擇性重複協定的運作 R.-W. Hung 2011

選擇性重複協定 (Cont.) 選擇性重複的困境 範例： 接收端無法分辨(a)(b)兩種情況 的差別! 不正確地重新傳送重複的資料 序號： 0、 1、 2、 3 視窗大小=3 接收端無法分辨(a)(b)兩種情況 的差別! 不正確地重新傳送重複的資料 如同 (a) 圖3.27 選擇性重複協定中，接收端無法判斷是新的封包還是重傳的封包 R.-W. Hung 2011

可靠資料傳輸機制的總整理 表3.1 可靠資料傳輸機制及其用途的總整理 機制 用途、註解 Checksum 用來偵測傳輸封包的位元錯誤。 3.4 可靠資料傳輸的原理 (Cont.) 可靠資料傳輸機制的總整理 表3.1 可靠資料傳輸機制及其用途的總整理 機制 用途、註解 Checksum 用來偵測傳輸封包的位元錯誤。 Timer 用來進行封包逾時/重送，可能因為該封包(或其ACK)遺失在通道中。 Sequence number 用來對從傳送端流向接收端的資料封包進行循序編號。收到的封包序列號碼若不連續，則接收端可偵測出封包的遺失。 Acknowledge 接收端用此訊息封包告知傳送端某個(組)封包已被正確接收。 Negative acknowledge 接收端用此訊息封包告知傳送端某個封包並未被正確接收。 Windows, pipelining 傳送端可能會被限制只能傳送序號在某個範圍的封包。藉由容許多個正在傳輸但未被確認的封包傳送端的通道使用率將比停止並等待操作模式增加。 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 區段結構、可靠的資料傳輸、流量控制、連線管理 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.5 連線導向傳輸  TCP TCP綜觀 TCP定義於 RFCs 793、1122、1323、2018、2581 TCP具備的功能 點對點： 一個傳送端、一個接收端 可靠的、有順序的位元組串流： 沒有 “訊息界線” 管線化： TCP擁塞控制和流量控制，可設定視窗大小 傳送端和接收端暫存器(緩衝區, buffer) 全雙工資料傳輸：(full-duplex service) 同一個連結中，雙向的資料流 MSS：最大資料區段大小 (maximum segment size) 連線導向： 交握程序 (控制訊息的交換) 在資料開始交換之前，設定傳送端和接收端的狀態 流量控制： 傳送端傳送的資料量不會超過接收端可接收的資料量 R.-W. Hung 2011

TCP綜觀 (Cont.) 讀出 圖3.28 TCP 的傳送端與接收端的緩衝區 (buffer) 資料區段 資料區段 TCP傳送端 緩衝區 TCP接收端 緩衝區 圖3.28 TCP 的傳送端與接收端的緩衝區 (buffer) R.-W. Hung 2011

TCP資料區段結構 (segment structure) 3.5 連線導向傳輸  TCP (Cont.) TCP資料區段結構 (segment structure) 32位元 URG：緊急資料 (通常不會使用) 來源端埠號 接收端埠號 ACK：確認有效 序列號碼 以資料位元組計算 (非資料區段的編號!) PSH：馬上將資料送出 (通常不會使用) 確認號碼 標頭 長度 未 使用 U A P R S F 接收端的視窗 接收端願意 接收的位元組數 網際網路檢查和 緊急資料指標 RST、SYN、FIN： 連線建立 (設定、中斷指令) 選用欄位 (不固定長度) 用於流量控制(flow control) 網際網路檢查和 (如同UDP) 應用程式資料 (不固定長度) 圖3.29 TCP 區段的結構 (segment structure) R.-W. Hung 2011

TCP序列號碼與確認號碼 序列號碼： 確認號碼：  Q: 接收端如何處理順序不正確的資料區段 3.5 連線導向傳輸  TCP (Cont.) TCP序列號碼與確認號碼 序列號碼： 資料區段中，第一個位元的位元組串流 “編號” (非封包序號) 例如：主機A將一資料串流(500,000 bytes的檔案)透過TCP傳送給主機B，其中TCP的MSS=1,000 bytes 此資料串流的第1個byte被編號為0 第1個TCP區段的序列號碼 = 0 第2個TCP區段的序列號碼 = 1000 See 圖3.30 確認號碼： 主機A期待從主機B收到的下一個位元組序列號碼(A到B的資料區段)  主機正在等待的下一個資料位元組的序號 累積式確認  Q: 接收端如何處理順序不正確的資料區段 Ans: TCP 規格中未限制、取決於程式開發者 0 1 ... 999 1000 1001 ... 1999 R.-W. Hung 2011

TCP序列號碼與確認號碼 (Cont.) 確認號碼：(Cont.) 主機A傳送資料給主機B 主機A已從主機B收到序號從0到535的所有位元組 主機A正要傳送一筆TCP區段給主機B  主機A傳送的TCP區段中的「確認號碼」為536 R.-W. Hung 2011

TCP序列號碼與確認號碼 (Cont.) 主機B 主機A 使用者 鍵入字元 Seq=42、 ACK=79、 data = ‘C’ ‘C’ 主機確定收到 ‘C’ ，然 後回應字元 ‘C’ Seq=43、 ACK=80 主機確定收到 回應字元 ‘C’的ACK訊息 時間 圖3.31 簡單的TCP Telnet範例 R.-W. Hung 2011

TCP 來回傳遞時間以及逾時 Q: 如何設定 TCP 的逾時值? Q:如何估計來回傳遞時間 ( RTT)? (EstimatedRTT) 太短： 過早逾時 不需要重新傳送 太長： 太晚對資料區段遺失作出反應 Q:如何估計來回傳遞時間 ( RTT)? (EstimatedRTT) 樣本RTT (SampleRTT)：測量資料區段傳送出去到收到確認所需的時間 忽略重傳 樣本RTT會有所變動、我們想要讓預估的RTT “更平滑” 將好幾個最近的測量值做平均、而非目前的樣本RTT R.-W. Hung 2011

TCP 來回傳遞時間以及逾時 (Cont.) TCP更新估算RTT值的公式 EstimatedRTT = (1  )  EstimatedRTT +   SampleRTT 指數加權移動平均值 過去樣本的影響將以指數速率減少 建議值： = 0.125 R.-W. Hung 2011

TCP 來回傳遞時間以及逾時 (Cont.) 範例 RTT 估計： 圖3.32 RTT取樣與RTT估算值 R.-W. Hung 2011

TCP 來回傳遞時間以及逾時 (Cont.) 設定逾時間隔 首先估計 SampleRTT 與 EstimatedRTT 的差距： DevRTT = (1)  DevRTT +   |SampleRTT  EstimatedRTT| (的建議值=0.25) 接著設定逾時間隔： TimeoutInterval = EstimatedRTT + 4DevRTT R.-W. Hung 2011

TCP 可靠的資料傳輸 What? 簡化的TCP傳送端： TCP 在 IP 的不可靠服務上建立 rdt 服務 忽略重複的ack 忽略流量控制、擁塞控制 R.-W. Hung 2011

TCP 可靠的資料傳輸 (Cont.) 簡化的TCP傳送端：(Cont.) 從應用程式收到資料： 產生含有序號的資料區段 序號是資料區段中、第一個資料位元組的位元組串流編號 假如計時器尚未執行、啟動計時器 (將計時器想成與最久的未確認資料區段有關) 逾時時間：TimeOutInterval 逾時： 傳新傳送導致逾時的資料區段 重新啟動計時器 收到Ack： (假如確認為之前未確認的資料區段) 更新已確認的狀態 假如還有未確認的資料區段、重新啟動計時器 R.-W. Hung 2011

TCP 可靠的資料傳輸 (Cont.) 簡化的TCP傳送端：(Cont.) 圖3.33 簡化的TCP傳送端 NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event： data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event： timer timeout retransmit not-yet-acknowledged segment with smallest sequence number event： ACK received、 with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) } } /* end of loop forever */ 圖3.33 簡化的TCP傳送端 R.-W. Hung 2011

TCP 可靠的資料傳輸 (Cont.) X TCP重新傳送的情況： loss 過早逾時 時序 時序 ACK 遺失的情況 主機 A Seq=92、 8 bytes data ACK=100 loss 逾時的間隔 ACK 遺失的情況 主機 B X 時序 主機 A 主機 B 序號=92 逾時間隔 Seq=92、 8 bytes data Seq=100、 20 bytes data ACK=100 ACK=120 Sendbase = 100 Seq=92、 8 bytes data SendBase = 120 序號=92 逾時間隔 ACK=120 SendBase = 100 SendBase = 120 過早逾時 時序 R.-W. Hung 2011

TCP 可靠的資料傳輸 (Cont.) TCP重新傳送的情況：(more) X loss time 累積式 ACK 的情況 主機 A Seq=92、 8 bytes data ACK=100 loss 逾時間隔 累積式 ACK 的情況 主機 B X Seq=100、 20 bytes data ACK=120 time SendBase = 120 R.-W. Hung 2011

3.5.5 TCP流量控制 (flow control) 運作原理 TCP連線的接收端有一個接收緩衝區 (圖3.38) 應用程式的行程也許會以較慢的速度從緩衝區讀取資料 流量控制  傳送端不會傳送太多太快的資料超過接收端的緩衝區 調整傳送端的速度與接收端應用程式能負擔的速度相符 圖3.38 接收端的接收視窗(RcvWindow)與接收緩衝區(RcvBuffer) R.-W. Hung 2011

TCP流量控制的運作 假設：TCP 接收端會將順序不正確的資料區段捨棄 緩衝區內的剩餘空間 RcvWindow 3.5.5 TCP流量控制 (Cont.) TCP流量控制的運作 假設：TCP 接收端會將順序不正確的資料區段捨棄 緩衝區內的剩餘空間 RcvWindow = RcvBuffer  (LastByteRcvd  LastByteRead) 接收端 將 RcvWindow值 包含在資料區段裡，以告知剩餘的空間 傳送端 限制未確認的資料大小在 RcvWindow值之下 保證接收端緩衝區不會溢出 Flow control Applet: http://media.pearsoncmg.com/aw/aw_kurose_network_4/applets/flow/FlowControl.htm R.-W. Hung 2011

3.5.6 TCP連線管理 (connection management) 序號 緩衝區、流量控制資訊 (例如 RcvWindow) 用戶端：開始連線者 Socket clientSocket = new Socket("hostname“, "port number"); 伺服端：被用戶端聯繫 Socket connectionSocket = welcomeSocket.accept(); 三路交握 (three-way handshaking) 步驟 1：用戶端主機傳送 TCP SYN 資料區段到伺服器 指定初始的序號 沒有資料傳遞 步驟 2：伺服端主機收到 SYN，以 SYNACK 資料區段回應 伺服端配置緩衝區 指定伺服端的初始序號 步驟 3：用戶端收到 SYNACK，回應 ACK 資料區段，可能含有資料  圖3.39 R.-W. Hung 2011

TCP關閉連線 用戶端關閉 socket： clientSocket.close(); 3.5.6 TCP連線管理 (Cont.) TCP關閉連線 用戶端關閉 socket： clientSocket.close(); 步驟 1：用戶端 終端系統傳送 TCP FIN控制區段到伺服端 步驟 2：伺服端 接收到FIN、以 ACK 回應。關閉連線、傳送 FIN 步驟 3：用戶端 收到 FIN、 回應 ACK 訊息 進入 “等待計時”  對接收到的 FIN 做確認的回應 步驟 4：伺服端 收到ACK。連線關閉 用戶端 伺服端 FIN 關閉 ACK 關閉 FIN ACK 已關閉 time out 已關閉 圖3.40 關閉TCP連線 R.-W. Hung 2011

TCP的生命週期 圖3.41 TCP 用戶端生命週期 圖3.42 TCP 伺服端生命週期 3.5.6 TCP連線管理 (Cont.) R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.6 擁塞控制的原理 (Congestion control) 非正式地：“太多的來源端傳送太多的資料，對網路來說太快，超過能處理的速度” 與流量控制不同！ 表現形式： 封包遺失 (路由器緩衝區溢出) 長的延遲 (在路由器緩衝區佇列中等待) 前十大的網路問題之一 R.-W. Hung 2011

網路擁塞 (Cont.) 主機A 主機B router’s buffer In >> Out 3.6 連線導向傳輸  TCP (Cont.) 網路擁塞 (Cont.) 主機A 主機B router’s buffer In >> Out R.-W. Hung 2011

擁塞的原因和代價  情境 1 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 lout = 接收的速度 3.6 連線導向傳輸  TCP (Cont.) 擁塞的原因和代價  情境 1 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 主機A lout = 接收的速度 lin = 傳送的速度 主機B 沒有限制的分享輸出連結緩衝器 R = 通道的容量 圖3.43 擁塞情境 1 R.-W. Hung 2011

擁塞的原因和代價  情境 1 (Cont.) 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 3.6 連線導向傳輸  TCP (Cont.) 擁塞的原因和代價  情境 1 (Cont.) 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 圖3.44 擁塞情境 1  產出量與延遲時間相對於主機傳送速度的函數圖形 當擁塞時會有很長的延遲 最大的可達成流通量 = R/2 R.-W. Hung 2011

擁塞的原因和代價  情境 2 兩個傳送端、兩個接收端；一個路由器具有限的緩衝區；沒有重傳機制 lout = 接收的速度 3.6 連線導向傳輸  TCP (Cont.) 擁塞的原因和代價  情境 2 兩個傳送端、兩個接收端；一個路由器具有限的緩衝區；沒有重傳機制 主機A lout = 接收的速度 lin = 傳送的速度 l‘in = 原始資料+ 重新傳送的資料 主機B 有限制的分享輸出連結緩衝器 R = 通道的容量 圖3.45 擁塞情境 2 R.-W. Hung 2011

擁塞的原因和代價  情境 2 (Cont.) 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 b. a. c. 3.6 連線導向傳輸  TCP (Cont.) 擁塞的原因和代價  情境 2 (Cont.) 兩個傳送端、兩個接收端；一個路由器具無限的緩衝區；沒有重傳機制 R/2 lin lout b. a. c. R/4 R/3 圖3.46 擁塞情境 2  使用有限緩衝區效能 擁塞的“代價”： 對給定的 “實際產量”(goodput) ，會有更多的工作 (重新傳輸) 不需要的重新傳輸：連結必須負擔多個封包的副本 R.-W. Hung 2011

擁塞控制的方法 端點對端點擁塞控制： 網路協助的擁塞控制： 網路層並沒有提供明顯的協助 根據終端系統觀察到的遺失及延遲來判斷擁塞 3.6 連線導向傳輸  TCP (Cont.) 擁塞控制的方法 端點對端點擁塞控制： 網路層並沒有提供明顯的協助 根據終端系統觀察到的遺失及延遲來判斷擁塞 TCP 採用的方法 網路協助的擁塞控制： 路由器提供協助給終端系統 以一個位元來表示擁塞 (SNA、 DECbit、 TCP/IP ECN、 ATM) 限制傳送端應該傳送的明確速率 R.-W. Hung 2011

第三章 導覽流程 3.1 傳輸層服務 3.2 多工和解多工 3.3 非預接式傳輸  UDP 3.4 可靠資料傳輸的原理 3.5 連線導向傳輸  TCP 3.6 擁塞控制的原理 3.7 TCP 擁塞控制 R.-W. Hung 2011

3.7 TCP 擁塞控制 (TCP Congestion control) 原理 採用端點對端點擁塞控制 讓傳送端根據某些原則來偵測網路擁塞的程度 若網路擁塞則傳送端限制自己將資料流量送入連線的速率 方法 累積遞增、倍數遞減 (only describe in this course) 低速啟動 回應逾時事件 R.-W. Hung 2011

TCP 擁塞控制  累積遞增、倍數遞減 增加傳送速率 (視窗大小)，以探測可用的頻寬 (直到發生遺失的狀況) 3.7 TCP 擁塞控制 (Cont.) TCP 擁塞控制  累積遞增、倍數遞減 增加傳送速率 (視窗大小)，以探測可用的頻寬 (直到發生遺失的狀況) 累積遞增：每個 RTT，將 CongWin (congestion window, 擁塞窗格大小) 加 1，直到發生遺失 倍數遞減：在發生遺失之後，將 CongWin 減為一半 看到鋸齒形式： 頻寬的探測 圖3.54 累積遞增、倍數遞減的擁塞控制 R.-W. Hung 2011

第三章 總結 傳輸層服務的原則： 網際網路上的例證和實作  接下來： 多工、解多工 可靠的資料傳輸 流量控制 擁塞控制 UDP TCP 離開網路 “邊緣” (應用層、傳輸層) 進入網路 “核心” (網路層、連結層)  第4、5章 R.-W. Hung 2011

End of Chapter 3 R.-W. Hung 2011