計算機網(wǎng)絡第5章_第1頁
計算機網(wǎng)絡第5章_第2頁
計算機網(wǎng)絡第5章_第3頁
計算機網(wǎng)絡第5章_第4頁
計算機網(wǎng)絡第5章_第5頁
已閱讀5頁,還剩112頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、課件制作人:謝鈞 謝希仁 計算機網(wǎng)絡教程(第4版) 第 5 章 運輸層 課件制作人:謝鈞 謝希仁 第 5 章 運輸層 5.1 運輸層協(xié)議概述 5.1.1 進程之間的通信 5.1.2 因特網(wǎng)的運輸層協(xié)議 5.1.3 運輸層的復用與分用 5.2 用戶數(shù)據(jù)報協(xié)議 UDP 5.2.1 UDP 概述 5.2.2 UDP 的首部格式 課件制作人:謝鈞 謝希仁 第 7 章 運輸層(續(xù)) 5.3 傳輸控制協(xié)議 TCP 5.3.1 TCP 的主要特點 5.3.2 TCP 報文段結構 5.3.3 TCP 的可靠傳輸 5.3.4 TCP的流量控制 5.3.5 TCP 的連接管理 5.4 擁塞控制 5.4.1 擁塞的

2、原因與危害 5.4.2 擁塞控制的基本方法 5.4.3 TCP的擁塞控制 課件制作人:謝鈞 謝希仁 5.1 運輸層協(xié)議概述 5.1.1 進程之間的通信 n從通信和信息處理的角度看,運輸層向它上面 的應用層提供通信服務,它屬于面向通信部分 的最高層,同時也是用戶功能中的最低層。 物理層 網(wǎng)絡層 運輸層 應用層 數(shù)據(jù)鏈路層 面向信息處理 面向通信 用戶功能 網(wǎng)絡功能 運輸層為相互通信的應用進程提供了 邏輯通信 5 4 3 2 1 運輸層提供應用進程間的邏輯通信 主機 A主機 B 應用進程應用進程 路由器 1路由器 2 AP1 LAN2WAN AP2 AP3 AP4 IP 層 LAN1 AP1 AP

3、2 AP4 端口 端口5 4 3 2 1 IP 協(xié)議的作用范圍 運輸層協(xié)議 TCP 和 UDP 的作用范圍 AP3 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 應用進程之間的通信 n兩個主機進行通信實際上就是兩個主機中的應 用進程互相通信。 n應用進程之間的通信又稱為端到端的通信。 n運輸層的一個很重要的功能就是復用和分用。 應用層不同進程的報文通過不同的端口向下交 到運輸層,再往下就共用網(wǎng)絡層提供的服務。 n“運輸層提供應用進程間的邏輯通信”?!斑?輯通信”的意思是:運輸層之間的通信好像是 沿水平方向傳送數(shù)據(jù)。但事實上這兩個運輸層 之間并沒有一條水平方向的物理連接。 課件制作人:謝鈞

4、 謝希仁 運輸層協(xié)議和網(wǎng)絡層協(xié)議 的主要區(qū)別 應用進程 應用進程 IP 協(xié)議的作用范圍 (提供主機之間的邏輯通信) TCP 和 UDP 協(xié)議的作用范圍 (提供進程之間的邏輯通信) 因 特 網(wǎng) 課件制作人:謝鈞 謝希仁 運輸層的主要功能 n運輸層為應用進程之間提供端到端的邏輯通信 (但網(wǎng)絡層是為主機之間提供邏輯通信)。 n運輸層還要對收到的報文進行差錯檢測。 n運輸層可選的功能: n可靠數(shù)據(jù)傳輸、流量控制、擁塞控制 課件制作人:謝鈞 謝希仁 因特網(wǎng)的運輸層有兩個不同的協(xié)議: (1) 用戶數(shù)據(jù)報協(xié)議 UDP (User Datagram Protocol) (2) 傳輸控制協(xié)議 TCP (Tran

5、smission Control Protocol) 5.1.2 因特網(wǎng)的運輸層協(xié)議 課件制作人:謝鈞 謝希仁 n兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作 運輸協(xié)議數(shù)據(jù)單元 TPDU (Transport Protocol Data Unit)。 nTCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報文段 (segment) n UDP 傳送的數(shù)據(jù)單位協(xié)議是 UDP 報文或用戶數(shù) 據(jù)報。 TCP 與 UDP 課件制作人:謝鈞 謝希仁 TCP/IP 體系中的運輸層協(xié)議 TCPUDP IP 應用層 與各種網(wǎng)絡接口 運輸層 課件制作人:謝鈞 謝希仁 TCP 與 UDP nUDP 在傳送數(shù)據(jù)之前不需要先建立連接

6、。對 方的運輸層在收到 UDP 報文后,不需要給出 任何確認。雖然 UDP 不提供可靠交付,但在 某些情況下 UDP 是一種最有效的工作方式。 nTCP 則提供面向連接的服務。TCP 不提供廣 播或多播服務。由于 TCP 要提供可靠的、面 向連接的運輸服務,因此不可避免地增加了許 多的開銷。這不僅使協(xié)議數(shù)據(jù)單元的首部增大 很多,還要占用許多的處理機資源。 課件制作人:謝鈞 謝希仁 還要強調兩點 n運輸層的 UDP 用戶數(shù)據(jù)報與網(wǎng)際層的IP數(shù)據(jù)報 有很大區(qū)別。IP 數(shù)據(jù)報要經(jīng)過互連網(wǎng)中許多路 由器的存儲轉發(fā),但 UDP 用戶數(shù)據(jù)報是在運輸 層的端到端抽象的邏輯信道中傳送的。 nTCP 報文段是在

7、運輸層抽象的端到端邏輯信道 中傳送,這種信道是可靠的全雙工信道。但這 樣的信道卻不知道究竟經(jīng)過了哪些路由器,而 這些路由器也根本不知道上面的運輸層是否建 立了 TCP 連接。 課件制作人:謝鈞 謝希仁 5.1.3 運輸層的復用與分用 n復用是指在發(fā)送方不同的應用進程都可以使用同 一個運輸層協(xié)議傳送數(shù)據(jù)(當然需要加上適當?shù)?首部); n而分用是指接收方的運輸層在剝?nèi)笪牡氖撞亢?能夠把這些數(shù)據(jù)正確交付到目的應用進程。 n要能正確地將數(shù)據(jù)交付給指定應用進程,就必須 給每個應用進程賦予一個明確的標志。 n在TCP/IP網(wǎng)絡中,使用一種與操作系統(tǒng)無關的協(xié) 議端口號(protocol port numb

8、er)(簡稱端口號) 來實現(xiàn)對通信的應用進程的標志。 課件制作人:謝鈞 謝希仁 運輸層端口的概念 n端口就是應用進程的運輸層地址。 n端口的作用就是讓應用層的各種應用進程都能將 其數(shù)據(jù)通過端口向下交付給運輸層,以及讓運輸 層知道應當將其報文段中的數(shù)據(jù)向上通過端口交 付給應用層相應的進程。 n從這個意義上講,端口是用來標志應用層的進程。 端口在進程之間的通信中所起的作用 應 用 層 運 輸 層 網(wǎng) 絡 層 TCP 報文段 UDP 用戶數(shù)據(jù)報 應用進程 TCP 復用 IP 復用 UDP 復用 TCP 報文段 UDP 用戶數(shù)據(jù)報 應用進程 端口端口 TCP 分用UDP 分用 IP 分用 IP 數(shù)據(jù)報

9、IP 數(shù)據(jù)報 發(fā)送方 接收方 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 端口 n端口用一個 16 位端口號進行標志。 n端口號只具有本地意義,即端口號只是為 了標志本計算機應用層中的各進程。在因 特網(wǎng)中不同計算機的相同端口號是沒有聯(lián) 系的。 n并且TCP和UDP端口號之間也沒有必然聯(lián) 系 課件制作人:謝鈞 謝希仁 三類端口 (1) 熟知端口,其數(shù)值一般為 01023。當一種新 的應用程序出現(xiàn)時,必須為它指派一個熟知端 口。 (2) 登記端口,其數(shù)值為 102449151。這類端 口是 ICANN 控制的,使用這個范圍的端口必 須在 ICANN 登記,以防止重復。 (3) 動態(tài)端口,其

10、數(shù)值為 4915265535。這類端 口是留給客戶進程選擇作為臨時端口。 課件制作人:謝鈞 謝希仁 5.2 用戶數(shù)據(jù)報協(xié)議 UDP 5.2.1 UDP 概述 nUDP 只在 IP 的數(shù)據(jù)報服務之上增加了很少一 點的功能,即端口的功能和差錯檢測的功能。 n雖然 UDP 用戶數(shù)據(jù)報只能提供不可靠的交付, 但 UDP 在某些方面有其特殊的優(yōu)點。 n發(fā)送數(shù)據(jù)之前不需要建立連接 nUDP 的主機不需要維持復雜的連接狀態(tài)表。 nUDP 用戶數(shù)據(jù)報只有 8 個字節(jié)的首部開銷。 n網(wǎng)絡出現(xiàn)的擁塞不會使源主機的發(fā)送速率降低。這 對某些實時應用是很重要的。 課件制作人:謝鈞 謝希仁 UDP 的特點 nUDP 是無

11、連接的,即發(fā)送數(shù)據(jù)之前不需 要建立連接(當然發(fā)送數(shù)據(jù)結束時也沒 有連接可釋放),因此減少了開銷和發(fā) 送數(shù)據(jù)之前的時延。 nUDP 使用盡最大努力交付,即不保證可 靠交付,同時也不使用擁塞控制,因此 主機不需要維持具有許多參數(shù)的、復雜 的連接狀態(tài)表。 課件制作人:謝鈞 謝希仁 UDP 的特點(續(xù)) n由于 UDP 沒有擁塞控制,因此網(wǎng)絡出現(xiàn) 的擁塞不會使源主機的發(fā)送速率降低。 這對某些實時應用是很重要的。很多的 實時應用(如 IP 電話、實時視頻會議等) 要求源主機以恒定的速率發(fā)送數(shù)據(jù),并 且允許在網(wǎng)絡發(fā)生擁塞時丟失一些數(shù)據(jù), 但卻不允許數(shù)據(jù)有太大的時延。UDP 正 好適合這種要求。 課件制作人

12、:謝鈞 謝希仁 UDP 的特點(續(xù)) nUDP 是面向報文的。這就是說,UDP 對 應用程序交下來的報文不再劃分為若干 個分組來發(fā)送,也不把收到的若干個報 文合并后再交付給應用程序。 n應用程序交給 UDP 一個報文,UDP 就發(fā)送 這個報文;而 UDP 收到一個報文,就把它 交付給應用程序。 n應用程序必須選擇合適大小的報文。 課件制作人:謝鈞 謝希仁 UDP 的特點(續(xù)) nUDP 支持一對一、一對多、多對一和多 對多的交互通信。 n用戶數(shù)據(jù)報只有 8 個字節(jié)的首部開銷, 比 TCP 的 20 個字節(jié)的首部要短。 課件制作人:謝鈞 謝希仁 UDP 的問題 n雖然某些實時應用需要使用沒有擁塞

13、控 制的 UDP,但當很多的源主機同時都向 網(wǎng)絡發(fā)送高速率的實時視頻流時,網(wǎng)絡 就有可能發(fā)生擁塞,結果大家都無法正 常接收。 n還有一些使用 UDP 的實時應用需要對 UDP 的不可靠的傳輸進行適當?shù)母倪M以 減少數(shù)據(jù)的丟失。 課件制作人:謝鈞 謝希仁 5.2.2 UDP 的首部格式 偽首部源端口目的端口長 度檢驗和 數(shù) 據(jù)首 部 UDP長度源 IP 地址目的 IP 地址017 IP 數(shù)據(jù)報 字節(jié)44112 122222字節(jié) 發(fā)送在前 數(shù) 據(jù)首 部 UDP 用戶數(shù)據(jù)報 偽首部源端口目的端口長 度檢驗和 數(shù) 據(jù)首 部 UDP長度源 IP 地址目的 IP 地址017 IP 數(shù)據(jù)報 字節(jié)44112 1

14、22222字節(jié) 發(fā)送在前 數(shù) 據(jù)首 部UDP 用戶數(shù)據(jù)報 用戶數(shù)據(jù)報 UDP 有兩個字段:數(shù)據(jù)字段和首部 字段。首部字段有 8 個字節(jié),由 4 個字段組成, 每個字段都是兩個字節(jié)。 課件制作人:謝鈞 謝希仁 偽首部源端口目的端口長 度檢驗和 數(shù) 據(jù)首 部 UDP長度源 IP 地址目的 IP 地址017 IP 數(shù)據(jù)報 字節(jié)44112 122222字節(jié) 發(fā)送在前 數(shù) 據(jù)首 部UDP 用戶數(shù)據(jù)報 在計算檢驗和時,臨時把“偽首部”和 UDP 用戶數(shù)據(jù) 報連接在一起。偽首部僅僅是為了計算檢驗和。 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 UDP的多路分用模型 課件制作人:謝鈞 謝希仁 5.3

15、傳輸控制協(xié)議 TCP 5.3.1 TCP 的主要特點 nTCP 是面向連接的運輸層協(xié)議。 n每一條 TCP 連接只能有兩個端點 (endpoint),每一條 TCP 連接只能是點 對點的(一對一)。 nTCP 提供可靠交付的服務。 n TCP 提供全雙工通信。 n面向字節(jié)流。 課件制作人:謝鈞 謝希仁 TCP 面向流的概念 端口 發(fā)送 TCP 報文段 TCP TCP 接收緩存發(fā)送緩存 報文段 報文段報文段 端口 發(fā)送方接收方 向發(fā)送緩存 寫入數(shù)據(jù)塊 從接收緩存 讀取數(shù)據(jù)塊 應用進程應用進程 課件制作人:謝鈞 謝希仁 應當注意 nTCP 連接是一條虛連接而不是一條真正的物理連 接。 nTCP 對

16、應用進程一次把多長的報文發(fā)送到TCP 的 緩存中是不關心的。 nTCP 根據(jù)對方給出的窗口值和當前網(wǎng)絡擁塞的程 度來決定一個報文段應包含多少個字節(jié)(UDP 發(fā) 送的報文長度是應用進程給出的)。 nTCP 可把太長的數(shù)據(jù)塊劃分短一些再傳送。TCP 也可等待積累有足夠多的字節(jié)后再構成報文段發(fā) 送出去。 課件制作人:謝鈞 謝希仁 TCP 連接的任何一方 都能夠發(fā)送和接收數(shù)據(jù) n通信是全雙工方式。 n發(fā)送方的應用進程按照自己產(chǎn)生數(shù)據(jù)的規(guī)律, 不斷地把數(shù)據(jù)塊陸續(xù)寫入到 TCP 的發(fā)送緩存 中。TCP 再從發(fā)送緩存中取出一定數(shù)量的數(shù)據(jù), 將其組成 TCP 報文段(segment)逐個傳送給 IP 層,然后

17、發(fā)送出去。 n接收方從 IP 層收到 TCP 報文段后,先把它暫 存在接收緩存中,然后讓接收方的應用進程從 接收緩存中將數(shù)據(jù)塊逐個讀取。 課件制作人:謝鈞 謝希仁 一對一的通信 n由于運輸層的通信是面向連接的,因此 TCP 每一條連接上的通信只能是一對一 的,而不可能是一對多、多對一或多對 多的。 TCP 的連接 nTCP 把連接作為最基本的抽象。 n每一條 TCP 連接唯一地被通信兩端的兩 個端點所確定。即: TCP 連接 := (IP1: port1), (IP2: port2) 課件制作人:謝鈞 謝希仁 UDP與TCP復用的區(qū)別 應用進程 緩 存 目的地址/ 端口相同 應用 進程 應用

18、進程 應用 進程 進 程 緩 存 同一源/目 的地址/端 口號 應用 進程 應用 進程 應用 進程 緩 存 緩 存 進 程 進 程 可以是不同進程 同一端 口號 課件制作人:謝鈞 謝希仁 UDP TCP 課件制作人:謝鈞 謝希仁 5.3.2 TCP 報文段結構 nTCP 報文段分為首部和數(shù)據(jù)兩部分。 nTCP 的全部功能都體現(xiàn)在它首部中各字 段的作用。 nTCP 報文段首部的前 20個 字節(jié)是固定 的,后面有 4N 字節(jié)是根據(jù)需要而增加 的選項(N 必須是整數(shù))。因此 TCP 首部 的最小長度是 20 字節(jié)。 TCP 首部 20 字節(jié)的 固定首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項

19、 (長 度 可 變) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N 32 位 S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 TCP 數(shù)據(jù)部分TCP 首部 TCP 報文段 IP 數(shù)據(jù)部分IP 首部 發(fā)送在前 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 源端

20、口和目的端口字段各占 2 字節(jié)。端口是運輸 層與應用層的服務接口。運輸層的復用和分用功能都 要通過端口才能實現(xiàn)。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 序號字段占 4 字節(jié)。TCP 連接中傳送的數(shù)據(jù)流 中的每一個字節(jié)都編上一個序號。序號字段的值則指 的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。 課件制作人:謝鈞 謝希仁 TCP

21、首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 確認號字段占 4 字節(jié),是期望收到對方的下一個 報文段的數(shù)據(jù)的第一個字節(jié)的序號。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H

22、 A C K U R G 位 0 8 16 24 31 填 充 數(shù)據(jù)偏移占 4 位,它指出 TCP 報文段的數(shù)據(jù)起始 處距離 TCP 報文段的起始處有多遠?!皵?shù)據(jù)偏移”的 單位不是字節(jié)而是 32 位字(4 字節(jié)為計算單位)。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 保留字段占 6 位,保留為今后使用,但目前 應置為 0。 課件制作

23、人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 緊急位 URG 當 URG 1 時,表明緊急指針 字段有效。它告訴系統(tǒng)此報文段中有緊急數(shù)據(jù),應 盡快傳送(相當于高優(yōu)先級的數(shù)據(jù))。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針

24、 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 確認位 ACK 只有當 ACK 1 時確認號字段 才有效。當 ACK 0 時,確認號無效。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 推送位 PSH (PuSH) 接收 TCP 收到 PSH =

25、 1 的 報文段,就盡快地交付給接收應用進程,而不再等到 整個緩存都填滿了后再向上交付。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 復位位 RST (ReSeT) 當 RST 1 時,表明 TCP 連接中出現(xiàn)嚴重差錯(如由于主機崩潰或其他原因), 必須釋放連接,然后再重新建立運輸連接。 課件制作人:謝鈞 謝希仁 TCP 首部 20

26、字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 同步位 SYN 當 SYN = 1 時,表示這是一個連 接請求或連接接受報文。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K

27、U R G 位 0 8 16 24 31 填 充 終止位 FIN (FINal) 用來釋放連接。當 FIN 1 時,表明此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢,并要 求釋放運輸連接。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 窗口字段 占 2 字節(jié)。窗口字段用來控制對方發(fā)送 的數(shù)據(jù)量,單位為字節(jié)。TCP 連接的一端根據(jù)設置的緩 存空間大小

28、確定自己的接收窗口大小,然后通知對方以 確定對方的發(fā)送窗口的上限。課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 檢驗和 占 2 字節(jié)。檢驗和字段檢驗的范圍包括 首部和數(shù)據(jù)這兩部分。在計算檢驗和時,要在 TCP 報文段的前面加上 12 字節(jié)的偽首部。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏

29、移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24 31 填 充 緊急指針字段 占 16 位。緊急指針指出在本報 文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C K U R G 位 0 8 16 24

30、 31 填 充 選項字段 長度可變。TCP 只規(guī)定了一種選項, 即最大報文段長度 MSS (Maximum Segment Size)。 MSS 告訴對方 TCP:“我的緩存所能接收的報文段 的數(shù)據(jù)字段的最大長度是 MSS 個字節(jié)?!?MSS 是 TCP 報文段中的數(shù)據(jù)字段的最大長度。 數(shù)據(jù)字段加上 TCP 首部 才等于整個的 TCP 報文段。 課件制作人:謝鈞 謝希仁 TCP 首部 20 字節(jié) 固定 首部 目 的 端 口 數(shù)據(jù) 偏移 檢 驗 和 選 項 (長 度 可 變 ) 源 端 口 序 號 緊 急 指 針 窗 口 確 認 號 保 留 F I N S Y N R S T P S H A C

31、 K U R G 位 0 8 16 24 31 填 充 填充字段 這是為了使整個首部長度是 4 字節(jié)的 整數(shù)倍。 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 5.3.3 TCP 的可靠傳輸 n我們知道因特網(wǎng)的網(wǎng)絡層服務是不可靠的,即通過 IP傳送的數(shù)據(jù)可能出現(xiàn)差錯、丟失、亂序或重復。 nTCP在IP的不可靠的盡最大努力服務的基礎上實現(xiàn) 了一種可靠數(shù)據(jù)傳輸服務,保證數(shù)據(jù)無差錯、無丟 失、按序和無重復的交付。 n由于TCP下面的傳輸數(shù)據(jù)的互聯(lián)網(wǎng)的結構非常復雜, 因此不能采用最簡單的停止等待協(xié)議來實現(xiàn)可靠傳 輸。 課件制作人:謝鈞 謝希仁 1. 數(shù)據(jù)編號與確認 nTCP 協(xié)議是面向字節(jié)的。T

32、CP 將所要傳送的報文 看成是字節(jié)組成的數(shù)據(jù)流,并使每一個字節(jié)對應于 一個序號。 n在連接建立時,雙方要商定初始序號。TCP 每次 發(fā)送的報文段的首部中的序號字段數(shù)值表示該報文 段中的數(shù)據(jù)部分的第一個字節(jié)的序號。 n TCP 的確認是對接收到的數(shù)據(jù)的最高序號表示確 認。接收方返回的確認號是已收到的數(shù)據(jù)的最高序 號加 1。因此確認號表示接收方期望下次收到的數(shù) 據(jù)中的第一個數(shù)據(jù)字節(jié)的序號。 課件制作人:謝鈞 謝希仁 1. 數(shù)據(jù)編號與確認(續(xù)) n由于TCP連接能提供全雙工通信,因此通信中的每 一方都不必專門發(fā)送確認報文段,而可以在傳送數(shù) 據(jù)時順便把確認信息捎帶傳送。 n為此,接收方在正確接收到數(shù)據(jù)

33、時可能要等待一小 段時間(不能超過0.5秒)再發(fā)送確認,若這段時 間內(nèi)有數(shù)據(jù)要發(fā)送給對方,則采用捎帶確認。這樣 做可以提高傳輸效率。 課件制作人:謝鈞 謝希仁 1. 數(shù)據(jù)編號與確認(續(xù)) n接收方若收到有差錯的報文段就丟棄(不發(fā)送否認 信息)。 n若收到重復的報文段,也要丟棄,但要發(fā)回(或捎 帶發(fā)回)確認信息。 n若收到失序的報文段,可選擇將失序報文段丟棄, 或者先將其暫存于接收緩存內(nèi),待所缺序號的報文 段收齊后再一起上交應用層。注意,不論采用哪種 方法,接收方都要對已按序接收到的數(shù)據(jù)進行確認。 課件制作人:謝鈞 謝希仁 2. 以字節(jié)為單位的滑動窗口 nTCP 采用大小可變的滑動窗口進行流量控

34、制。窗口 大小的單位是字節(jié)。 n在 TCP 報文段首部的窗口字段寫入的數(shù)值就是當前 給對方設置的發(fā)送窗口數(shù)值的上限。 n發(fā)送窗口在連接建立時由雙方商定。但在通信的過 程中,接收方可根據(jù)自己的資源情況,隨時動態(tài)地 調整對方的發(fā)送窗口上限值(可增大或減小)。 收到確認即可前移 1002003004005006007008009001012013014015016017018011 發(fā)送窗口 可發(fā)送不可發(fā)送 指針 n發(fā)送方要發(fā)送 900 字節(jié)長的數(shù)據(jù),劃分為 9 個 100 字節(jié)長的報文段,而發(fā)送窗口確定為 500 字節(jié)。 n發(fā)送方只要收到了對方的確認,發(fā)送窗口就可 前移。 n發(fā)送 TCP 要維護一

35、個指針。每發(fā)送一個報文 段,指針就向前移動一個報文段的距離。 課件制作人:謝鈞 謝希仁 收到確認即可前移 1002003004005006007008009001012013014015016017018011 可發(fā)送不可發(fā)送 指針 1002003004005006007008009001012013014015016017018011 發(fā)送窗口 可發(fā)送不可發(fā)送 指針發(fā)送窗口前移 n發(fā)送方已發(fā)送了 400 字節(jié)的數(shù)據(jù),但只收到對前 200 字節(jié)數(shù)據(jù)的確認,同時窗口大小不變。 n現(xiàn)在發(fā)送方還可發(fā)送 300 字節(jié)。 已發(fā)送 并被確認 已發(fā)送但 未被確認 課件制作人:謝鈞 謝希仁 100200300

36、4005006007008009001012013014015016017018011 已發(fā)送 并被確認 已發(fā)送但 未被確認 可發(fā)送不可發(fā)送 指針 1002003004005006007008009001012013014015016017018011 已發(fā)送 并被確認 可發(fā)送 不可 發(fā)送 指針 發(fā)送窗口前移 發(fā)送窗口縮小 n發(fā)送方收到了對方對前 400 字節(jié)數(shù)據(jù)的確認,但對 方通知發(fā)送方必須把窗口減小到 400 字節(jié)。 n現(xiàn)在發(fā)送方最多還可發(fā)送 400 字節(jié)的數(shù)據(jù)。 課件制作人:謝鈞 謝希仁 發(fā)送緩存 最后被確認 的字節(jié) 發(fā)送應用程序 發(fā)送緩存 最后發(fā)送 的字節(jié) 發(fā)送窗口 TCP 序號增大

37、課件制作人:謝鈞 謝希仁 接收緩存 接收應用程序 已收到 接收窗口 TCP 接收緩存 下一個讀取 的字節(jié) 序號增大 下一個期望收到的 字節(jié)(確認號) 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 3. 超時重傳時間的選擇 n重傳機制是 TCP 中最重要和最復雜的問 題之一。 nTCP 每發(fā)送一個報文段,就對這個報文 段設置一次計時器。只要計時器設置的 重傳時間到但還沒有收到確認,就要重 傳這一報文段。 課件制作人:謝鈞 謝希仁 往返時間的方差很大 n由于 TCP 的下層是一個互聯(lián)網(wǎng)環(huán)境,IP 數(shù)據(jù) 報所選擇的路由變化很大。因而運輸層的往返 時間的方差也很大。 往返時間 數(shù)據(jù)鏈路層 運輸層

38、 T1T2T3 概率 課件制作人:謝鈞 謝希仁 指數(shù)加權移動平均往返時間 nTCP 用指數(shù)加權移動平均往返時間 RTTS(這又稱為 平滑的往返時間)來估計當前RTT 。 n第一次測量到 RTT 樣本時,RTTS 值就取為所測量到 的 RTT 樣本值。以后每測量到一個新的 RTT 樣本, 就按下式重新計算一次 RTTS: 新的 RTTS (1 ) (舊的 RTTS) (新的 RTT 樣本) (5-1) n式中,0 1。若 很接近于零,表示 RTT 值更新 較慢。若選擇 接近于 1,則表示 RTT 值更新較快。 nRFC 2988 推薦的 值為 1/8,即 0.125。 課件制作人:謝鈞 謝希仁

39、超時重傳時間 RTO (RetransmissionTime-Out) nRTO 應略大于上面得出的加權平均往返時間 RTTS。 nRFC 2988 建議使用下式計算 RTO: n RTO RTTS + 4 RTTD (5-2) nRTTD 是 RTT 的偏差的加權平均值。 nRFC 2988 建議這樣計算 RTTD。第一次測量時, RTTD 值取為測量到的 RTT 樣本值的一半。在以后的 測量中,則使用下式計算加權平均的 RTTD: 新的 RTTD = (1 ) (舊的RTTD) + RTTS 新的 RTT 樣本 (5-3) n 是個小于 1 的系數(shù),其推薦值是 1/4,即 0.25。 課件

40、制作人:謝鈞 謝希仁 往返時間 RTT? 往返時間的測量相當復雜 nTCP 報文段 1 沒有收到確認。重傳(即報文 段 2)后,收到了確認報文段 ACK。 n如何判定此確認報文段是對原來的報文段 1 的 確認,還是對重傳的報文段 2 的確認? 發(fā)送一個 TCP 報文段 超時重傳 TCP 報文段 收到 ACK 時間12 往返時間 RTT? 是對哪一個報文段 的確認? 課件制作人:謝鈞 謝希仁 Karn 算法 n在計算平均往返時間 RTT 時,只要報文 段重傳了,就不采用其往返時間樣本。 n這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較準確。 課件制作人:謝鈞 謝希仁 n報

41、文段每重傳一次,就把 RTO 增大一些: 新的 RTO (舊的 RTO) n系數(shù) 的典型值是 2 。 n當不再發(fā)生報文段的重傳時,才根據(jù)報文段的往返 時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數(shù)值。 n實踐證明,這種策略較為合理。 修正的 Karn 算法 課件制作人:謝鈞 謝希仁 4. 快速重傳 n快要求接收方每收到一個失序的報文 段后就立即發(fā)出重復確認。 n發(fā)送方只要一連收到三個重復確認就 應當立即重傳對方尚未收到的報文段。 n不難看出,快重傳并非取消重傳計時 器,而是在某些情況下可更早地重傳 丟失的報文段。 快速重傳舉例 發(fā)送方 接收方 發(fā)送 M1 確認 M1 t 確認 M2

42、 發(fā)送 M2 發(fā)送 M3 發(fā)送 M4 ? 發(fā)送 M5 發(fā)送 M6 重復確認 M2 立即重傳 M3 重復確認 M2 重復確認 M2 t 發(fā)送 M7 收到三個連續(xù)的 對 M2 的重復確認 立即重傳 M3 丟失 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 5. 選擇確認 n選擇確認SACK (Selective ACK) 允許接 收方通知發(fā)送方所有正確接收了的但是 失序的字節(jié)塊,發(fā)送方可以根據(jù)這些信 息只重傳那些接收方還沒有收到的字節(jié) 塊,這很像前面介紹的選擇重傳SR的工 作方式。 課件制作人:謝鈞 謝希仁 5. 選擇確認 nTCP在首部中提供了一個可變長的“SACK選 項字段”來存放接收到

43、的失序字節(jié)塊的信息 n在建立TCP連接時,通過添加“允許SACK選 項字段”首部選項,表示都支持選擇確認功能 課件制作人:謝鈞 謝希仁 5.3.4 流量控制 n如果發(fā)送方把數(shù)據(jù)發(fā)送得過快,接收方 就可能來不及接收,這就會造成數(shù)據(jù)的 丟失。 n流量控制(flow control)就是讓發(fā)送方的發(fā) 送速率不要太快,既要讓接收方來得及 接收。 n利用滑動窗口機制可以很方便地在 TCP 連接上實現(xiàn)流量控制。 課件制作人:謝鈞 謝希仁 接收緩存 接收應用程序 已收到 接收窗口 TCP 接收緩存 下一個讀取 的字節(jié) 序號增大 下一個期望收到的 字節(jié)(確認號) 發(fā)送方的發(fā)送窗口 大小不能超過接收方 的接收窗

44、口的大小! 每段100字節(jié),初始窗口和接收緩存為400 SEQ = 1 SEQ = 201 SEQ = 401 SEQ = 301 SEQ = 101 SEQ = 501 ACK = 201, WIN = 300 ACK = 601, WIN = 0 ACK = 501, WIN = 100 主機 A主機 B 允許 A 再發(fā)送 300 字節(jié)(序號 201 至 500) A 還能發(fā)送 200 字節(jié) A 還能發(fā)送 100 字節(jié)(序號 401 至 500) A 還能發(fā)送 300 字節(jié) A 不能再發(fā)送500 以后的數(shù)據(jù) A 超時重傳,但不能繼續(xù)發(fā)送 允許 A 再發(fā)送 100 字節(jié)(序號 501 至 6

45、00) A 不能再發(fā)送600以后的數(shù)據(jù) 不允許 A 再發(fā)送(到序號 600 的數(shù)據(jù)都已收到) SEQ = 201 丟失!應用程序取走100 字節(jié) 應用程序取走100 字節(jié) 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 5.3.5 TCP 的連接管理 1. TCP的連接建立 n運輸連接就有三個階段,即:連接建立、 數(shù)據(jù)傳送和連接釋放。運輸連接的管理 就是使運輸連接的建立和釋放都能正常 地進行。 n連接建立過程中要解決以下三個問題: n要使每一方能夠確知對方的存在。 n要允許雙方協(xié)商一些參數(shù)(如最大報文段長 度,最大窗口大小,服務質量等)。 n能夠對運輸實體資源(如緩存大小,連接表 中的項目

46、等)進行分配。 課件制作人:謝鈞 謝希仁 客戶服務器方式 nTCP 的連接和建立都是采用客戶服務器 方式。 n主動發(fā)起連接建立的應用進程叫做客戶 (client)。 n被動等待連接建立的應用進程叫做服務 器(server)。 課件制作人:謝鈞 謝希仁 用三次握手建立 TCP 連接 SYN = 1, seq = x 主機 B SYN = 1, ACK = 1, seq = y, ack= x 1 ACK = 1, seq = x + 1, ack = y 1 被動打開主動打開 B 發(fā)送確認 A 發(fā)送確認 主機 A 連接請求 連接建立狀態(tài) 建立 TCP 連接 nA 的 TCP 向 B 發(fā)出連接請求

47、報文段,其首部中的 同步位 SYN = 1,并選擇序號 x,表明下一個報文 段的第一個數(shù)據(jù)字節(jié)的序號是 x + 1。 nB 的 TCP 收到連接請求報文段后,如同意,則發(fā)回 確認,在確認報文段中使 SYN = 1 和 ACK = 1,其 確認號應為 ack = x 1,并選擇序號seq = y。 nA 收到此報文段后,向 B 給出確認,其 ACK = 1, 序號應為 seq = x + 1,確認號應為 ack = y 1。 nA 的 TCP 通知上層應用進程,連接已經(jīng)建立。 n當運行服務器進程的主機 B 的 TCP 收到主機 A 的 確認后,也通知其上層應用進程,連接已經(jīng)建立。 課件制作人:謝

48、鈞 謝希仁 課件制作人:謝鈞 謝希仁 三次握手或三次聯(lián)絡 (three-way handshake) n防止已失效的連接請求報文段又傳送到 B,因 而產(chǎn)生錯誤。 nA 發(fā)出連接請求,但因未收到確認而再重傳一 次。后來收到了確認,建立了連接。數(shù)據(jù)傳輸 完畢后釋放了連接。A 共發(fā)送了兩個連接請求 報文段,其中的第二個到達了 B。 nA 發(fā)出的第一個連接請求報文段以后又傳送到 B。B 誤認為是 A 又發(fā)出一次新的連接請求。 于是就向 A 發(fā)出確認報文段,同意建立連接。 n A 不會理睬 B 的確認 。但 B 卻以為運輸連接 就這樣建立了,并一直等待 A 發(fā)來數(shù)據(jù)。 B 的許多資源就這樣白白浪費了。

49、課件制作人:謝鈞 謝希仁 2. TCP 的連接釋放 FIN =1, seq = x ACK = 1, seq = y, ack= x 1 ACK =1, seq = x + 1, ack = y 1 應用進程釋放連接 A 不再發(fā)送報文 主機 B主機 A 通知主機 應用進程 FIN =1, ACK =1, seq = y, ack = x + 1 應用進程釋放連接 B 不再發(fā)送報文 發(fā)送確認 確認 至此,整個連接已經(jīng)全部釋放。 半關閉狀態(tài) 關閉狀態(tài) 從 A 到 B 的連接就釋放了,連接處于半關閉狀態(tài)。 相當于 A 向 B 說:“我已經(jīng)沒有數(shù)據(jù)要發(fā)送了。 但你如果還發(fā)送數(shù)據(jù),我仍接收?!?3. T

50、CP 的 有 限 狀 態(tài) 機 CLOSED ESTABLISHED LISTEN CLOSE_WAIT FIN_WAIT_1 SYN_RCVD FIN_WAIT_2 CLOSING TIME_WAIT SYN_SENT LAST_ACK 主動打開 被動打開 被動關閉 主動關閉 起點 被動打開 主動打開 發(fā)送 SYN 同時打開 收到 SYN,發(fā)送 SYN, ACK 收到 ACK 數(shù)據(jù)傳送 階段 關閉 發(fā)送 FIN 關閉 發(fā)送 FIN 關閉 發(fā)送 FIN 收到 RST 收到 SYN 發(fā)送 SYN, ACK 關閉 或超時 收到 ACK 收到 SYN, ACK 發(fā)送 ACK 收到 ACK 收到 ACK

51、 收到 FIN 發(fā)送 ACK 收到 FIN, ACK 發(fā)送 ACK 收到 FIN 發(fā)送 ACK 同時關閉 收到 FIN 發(fā)送 ACK 發(fā)送 SYN 定時經(jīng)過兩倍報文段壽命后 關閉 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 5.4 擁塞控制 n如果網(wǎng)絡中的負載(load),即發(fā)送到網(wǎng)絡 中的分組數(shù)量,超過了網(wǎng)絡的容量,即 網(wǎng)絡中能處理的分組數(shù)量,那么在網(wǎng)絡 中就會發(fā)生擁塞(congestion)。 n所謂擁塞控制(congestion control)就是防 止過多的數(shù)據(jù)注入到網(wǎng)絡中,這樣可以 使網(wǎng)絡中的路由器或鏈路不致過載。 課件制作人:謝鈞 謝希仁 5.4.1 擁塞的原因與危害 提

52、供的負載 吞吐量 理想的擁塞控制 實際的擁塞控制 0 死鎖(吞吐量 = 0) 無擁塞控制 擁塞 輕度 擁塞 課件制作人:謝鈞 謝希仁 一個簡單的網(wǎng)絡擁塞例子 n理想吞吐量為100 Mb/s n不加任何控制只能達到60 Mb/s n當分組丟失時, 任何用于傳輸該分組的上游傳輸能力都 被浪費! 課件制作人:謝鈞 謝希仁 5.4.2 擁塞控制的基本方法 擁塞控制與流量控制的區(qū)別 n擁塞控制是一個全局性的過程,涉及到所 有的主機、所有的路由器,以及與降低網(wǎng) 絡傳輸性能有關的所有因素。 n流量控制往往指在給定的發(fā)送端和接收端 之間的點對點通信量的控制。 n流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù) 據(jù)的速率,

53、以便使接收端來得及接收。 課件制作人:謝鈞 謝希仁 開環(huán)控制和閉環(huán)控制 n開環(huán)控制方法就是在設計網(wǎng)絡時事先將有 關發(fā)生擁塞的因素考慮周到,力求網(wǎng)絡在 工作時不產(chǎn)生擁塞。 n閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉 環(huán)控制的有以下幾種措施: n監(jiān)測網(wǎng)絡系統(tǒng)以便檢測到擁塞在何時、何處發(fā) 生。 n將擁塞發(fā)生的信息傳送到可采取行動的地方。 n調整網(wǎng)絡系統(tǒng)的運行以解決出現(xiàn)的問題。 課件制作人:謝鈞 謝希仁 顯式反饋和隱式反饋 n根據(jù)擁塞反饋信息的形式又可以將閉環(huán)擁塞 控制算法分為顯式反饋算法和隱式反饋算法。 n在顯式反饋算法中,從擁塞點(即路由器) 向源端提供關于網(wǎng)絡中擁塞狀態(tài)的顯式反饋 信息。 n在隱式反

54、饋算法中,源端通過對網(wǎng)絡行為的 觀察(如分組丟失與往返時延)來推斷網(wǎng)絡 是否發(fā)生了擁塞。 nTCP采用的就是隱式反饋算法。 課件制作人:謝鈞 謝希仁 5.4.3 TCP的擁塞控制 n發(fā)送方維持一個叫做擁塞窗口 cwnd (congestion window)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng) 絡的擁塞程度,并且動態(tài)地在變化。發(fā)送方讓自 己的發(fā)送窗口等于擁塞窗口。如再考慮到接收方 的接收能力,則發(fā)送窗口還可能小于擁塞窗口。 n發(fā)送方控制擁塞窗口的原則是:只要網(wǎng)絡沒有出 現(xiàn)擁塞,擁塞窗口就再增大一些,以便把更多的 分組發(fā)送出去。但只要網(wǎng)絡出現(xiàn)擁塞,擁塞窗口 就減小一些,以減少注入到網(wǎng)絡中的分組數(shù)。

55、 課件制作人:謝鈞 謝希仁 接收方窗口 rwnd 和 擁塞窗口 cwnd n(1) 接收方窗口 rwnd 這是接收方根據(jù)其目前的 接收緩存大小所許諾的最新的窗口值,是來自接 收方的流量控制。接收方將此窗口值放在 TCP 報文的首部中的窗口字段,傳送給發(fā)送方。 n(2) 擁塞窗口 cwnd (congestion window) 是發(fā) 送方根據(jù)自己估計的網(wǎng)絡擁塞程度而設置的窗口 值,是來自發(fā)送方的流量控制。 課件制作人:謝鈞 謝希仁 發(fā)送窗口的上限值 n發(fā)送方的發(fā)送窗口的上限值應當取為接收方窗口 rwnd 和擁塞窗口 cwnd 這兩個變量中較小的一個, 即應按以下公式確定: 發(fā)送窗口的上限值 M

56、in rwnd, cwnd (5-4) n當 rwnd cwnd 時,是接收方的接收能力限制發(fā)送 窗口的最大值。 n當 cwnd rwnd 時,則是網(wǎng)絡的擁塞限制發(fā)送窗口 的最大值。 課件制作人:謝鈞 謝希仁 1. 慢啟動和擁塞避免 n在主機剛剛開始發(fā)送報文段時可先將擁塞窗口 cwnd 設置為一個最大報文段 MSS 的數(shù)值。 n在每收到一個對新的報文段的確認后,將擁塞 窗口增加至多一個 MSS 的數(shù)值。 n用這樣的方法逐步增大發(fā)送方的擁塞窗口 cwnd,可以使分組注入到網(wǎng)絡的速率更加合理。 課件制作人:謝鈞 謝希仁 用例子說明慢啟動算法的原理 n用報文段的個數(shù)作為窗口大小的單位。還假定 接收方

57、窗口 rwnd 足夠大,因此發(fā)送窗口只受 發(fā)送方的擁塞窗口的制約。 n發(fā)送方先設置 cwnd = 1,發(fā)送 M0,接收方收 到后發(fā)回 ACK1。 n發(fā)送方收到 ACK1 后,把 cwnd 從 1 增大到 2, 發(fā)送方接著發(fā)送 M1 和 M2 兩個報文段。 n接收方收到后發(fā)回 ACK2 和 ACK3。 n發(fā)送方每收到一個對新報文段的確認 ACK,就 使發(fā)送方的擁塞窗口加 1,因此現(xiàn)在發(fā)送方的 cwnd 又從 2 增大到 4,并可發(fā)送 M3 M6 共 4 個報文段。 發(fā)送方接收方 發(fā)送 M1 確認 M1 cwnd = 1 tt 發(fā)送方每收到一個對新報文段的確認 (重傳的不算在內(nèi))就使 cwnd 加

58、 1。 課件制作人:謝鈞 謝希仁 發(fā)送方接收方 發(fā)送 M1 確認 M1 發(fā)送 M2M3 確認 M2M3 cwnd = 1 cwnd = 2 tt 發(fā)送方每收到一個對新報文段的確認 (重傳的不算在內(nèi))就使 cwnd 加 1。 課件制作人:謝鈞 謝希仁 發(fā)送方接收方 發(fā)送 M1 確認 M1 發(fā)送 M2M3 確認 M2M3 發(fā)送 M4M7 確認 M4M7 cwnd = 1 cwnd = 2 cwnd = 4 tt 發(fā)送方每收到一個對新報文段的確認 (重傳的不算在內(nèi))就使 cwnd 加 1。 課件制作人:謝鈞 謝希仁 發(fā)送方接收方 發(fā)送 M1 確認 M1 發(fā)送 M2M3 確認 M2M3 發(fā)送 M4M7

59、 確認 M4M7 cwnd = 1 cwnd = 2 cwnd = 4 發(fā)送 M8M15cwnd = 8 tt 發(fā)送方每收到一個對新報文段的確認 (重傳的不算在內(nèi))就使 cwnd 加 1。 課件制作人:謝鈞 謝希仁 發(fā)送方接收方 發(fā)送 M1 確認 M1 發(fā)送 M2M3 確認 M2M3 發(fā)送 M4M7 確認 M4M7 cwnd = 1 cwnd = 2 cwnd = 4 發(fā)送 M8M15cwnd = 8 tt 發(fā)送方每收到一個對新報文段的確認 (重傳的不算在內(nèi))就使 cwnd 加 1。 輪次 1 輪次 2 輪次 3 課件制作人:謝鈞 謝希仁 課件制作人:謝鈞 謝希仁 慢啟動的作用 n可見慢啟動的

60、“慢”并不是指 cwnd 的 增長速率慢,而是指在開始時發(fā)送速率 “慢”( cwnd = 1)。 n使用慢啟動算法可以使發(fā)送方在開始發(fā) 送時向網(wǎng)絡注入的分組數(shù)大大減少。這 對防止網(wǎng)絡出現(xiàn)擁塞是非個常有力的措 施。 課件制作人:謝鈞 謝希仁 開始門限 ssthresh n為了防止擁塞窗口 cwnd 的增長引起網(wǎng) 絡擁塞,還需要另一個狀態(tài)變量,即慢 啟動門限 ssthresh,其用法如下: n當 cwnd ssthresh 時,停止使用慢啟動 算法而改用擁塞避免算法。 n當 cwnd = ssthresh 時,既可使用慢啟動 算法,也可使用擁塞避免算法。 課件制作人:謝鈞 謝希仁 擁塞避免算法 n

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論