第 8 章 传输层协议

113
1 第8第 第第第第

Upload: brilliant

Post on 04-Jan-2016

116 views

Category:

Documents


5 download

DESCRIPTION

第 8 章 传输层协议. 8.4 传输控制协议 TCP. 主要内容: TCP 概述 TCP 的端口号和套接字地址 TCP 的报文段 TCP 的数据编号与确认 TCP 的连接管理 TCP 的连接管理状态转换图 流量控制 傻瓜窗口综合症 差错控制 拥塞控制 定时器管理. 8.4.1 TCP 概述. 面向连接的服务 要获得 T C P 服务,在一个应用进程向另一个应用进程开始发送数据之前,必须先在双方之间建立一条连接,数据传送结束后要释放连接 。. 8.4.1 TCP 概述. 发送端. 接收端. . . 应用进程. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 第 8 章 传输层协议

1

第 8 章 传输层协议

Page 2: 第 8 章 传输层协议

2

8.4 传输控制协议 TCP主要内容: TCP 概述 TCP 的端口号和套接字地址 TCP 的报文段 TCP 的数据编号与确认 TCP 的连接管理 TCP 的连接管理状态转换图 流量控制 傻瓜窗口综合症 差错控制 拥塞控制 定时器管理

Page 3: 第 8 章 传输层协议

3

8.4.1 TCP 概述

面向连接的服务 要获得 T C P 服务,在一个应用进程

向另一个应用进程开始发送数据之前,必须先在双方之间建立一条连接,数据传送结束后要释放连接。

Page 4: 第 8 章 传输层协议

4

8.4.1 TCP 概述

端口

发送 TCP 报文段

TCPTCP

TCPTCP接收缓存发送缓存

报文段报文段 …报文段报文段 报文段报文段

端口

发送端 接收端

向发送缓存写入数据块

从接收缓存读取数据块

应用进程 应用进程

Page 5: 第 8 章 传输层协议

5

全双工服务 TCP 连接提供全双工服务,所有 TCP 连接都

是点到点的。 字节流传递服务 一个 TCP 连接就是一个字节流,即:两个建

立了 TCP 连接的应用进程之间交换的是字节流。端到端之间不保留消息的边界。

例如:一方的应用程序发送两个 1024B 的报文,连接的另一方将无法了解发送方每次发送了多少字节。当 2048B 到达接收方时,接收这 2048B, 而并不知道这是两个 1024B 的消息,还是一个 2048B 的消息。

Page 6: 第 8 章 传输层协议

6

8.4.2     TCP 的端口号和套接字地址 TCP 和 UDP 都采用 16bit 的端口号来标识

应用程序

Page 7: 第 8 章 传输层协议

7

8.4.2     TCP 的端口号和套接字地址

TCP 和 UDP 对端口号的使用彼此独立,即:同一个端口号可以有两种不同的用途。

例如:如果一个应用程序可以使用 TCP 和 UDP ,就对这个应用程序分配相同的端口号。

Page 8: 第 8 章 传输层协议

8

8.4.2     TCP 的端口号和套接字地址

套接字地址有一个 IP 地址与一个端口号组成,共 48bit 。

要使用 TCP 服务,首先要在发送端的套接字和接收端的套接字之间建立一条连接,即建立一对套接字地址:客户套接字地址和服务器套接字地址。

一个套接字可能同时用于多个连接。

Page 9: 第 8 章 传输层协议

9

8.4.3     TCP 的报文段 TCP 报文段由首部和数据两部分组成。 首部前 20 字节是固定部分,后面有 4N 字节是

根据需要而增加的选项( N 必须是整数,若不是整数则需加 0 填充)。

选项部分最多是 40 字节 (4N) 。

首部

固定部分20B

Page 10: 第 8 章 传输层协议

10

8.4.3     TCP 的报文段 TCP 报文段既可以用来传送数据,也可以用来

建立连接和应答(连接的建立和终止时,双方交换的报文段仅有 TCP 首部)。

首部

固定部分20B

Page 11: 第 8 章 传输层协议

11

TCP首部

20 字节的固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

32 bit

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

TCP 数据部分TCP 首部TCP 报文段

IP 数据部分IP 首部发送

Page 12: 第 8 章 传输层协议

12

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

源端口和目的端口字段——各占 2 字节。源端口号和目的端口号 : 分别标识发送和接收这个报文段的应用程序的端口。端口是传输层与应用层的服务接口。传输层的复用和分用功能都要通过端口才能实现。

Page 13: 第 8 章 传输层协议

13

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

序号字段——占 4 字节。 TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号(由随机数产生器产生,并非从 0 开始)。

Page 14: 第 8 章 传输层协议

14

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

已知一个报文段的序号为 301 ,报文段中共有 100B ,即其最后一个字节的序号是 400 。因此在下一个报文段的序号为 401 。

Page 15: 第 8 章 传输层协议

15

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

确认号字段——占 4 字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。

Page 16: 第 8 章 传输层协议

16

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

TCP 的确认号是“累计的”。例如:接收端正确地接收了一个报文段,其序号字段的值是 2001 ,而数据长度是 1000B ,表明序号在 2001~3000 之间的数据均已收到,则确认号应是 3001 ,即接收端期望收到的下一个字节的序号。

Page 17: 第 8 章 传输层协议

17

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

TCP 无法对一个报文段进行否认。例如:如果收到 1025~2048 字节的报文段,但它的校验和错,那么 TCP 接收端所能做的就是发回一个确认号为 1025 的确认报文。

Page 18: 第 8 章 传输层协议

18

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

数据偏移 ( 首部长度 )—— 占 4 bit ,它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远,即:表明 TCP 首部的长度共有多少个 4B (以 4 字节为计算单位)。

Page 19: 第 8 章 传输层协议

19

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

保留字段——占 6 bit ,保留为今后使用,但目前应置为 0 。

Page 20: 第 8 章 传输层协议

20

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

控制字段 ——定义了 6 个不同的控制位。用于 TCP 的流量控制、连接的建立和终止以及表示数据的传送方式等。

Page 21: 第 8 章 传输层协议

21

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

紧急比特 URG —— 当 URG 1 时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送 ( 相当于高优先级的数据 ) 。

Page 22: 第 8 章 传输层协议

22

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

确认比特 ACK —— 只有当 ACK 1 时确认号字段才有效。当 ACK 0 时,确认号无效。

Page 23: 第 8 章 传输层协议

23

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

推送比特 PSH (PuSH) —— 接收 TCP 收到推送比特置 1 的报文段,就尽快地交付给接收应用进程,而不再等到整个缓存都填满了后再向上交付。

Page 24: 第 8 章 传输层协议

24

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

复位比特 RST (ReSet) —— 当 RST 1 时,表明 TCP 连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立传输连接。

Page 25: 第 8 章 传输层协议

25

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

同步比特 SYN —— 同步比特 SYN 置为 1 ,就表示这是一个连接请求或连接接受报文。

Page 26: 第 8 章 传输层协议

26

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

SYN 结合 ACK 对报文进行区分。报文段的 SYN=1,ACK=0 表示 TCP 连接请求报文报文段的 SYN=1,ACK=1 表示对方同意建立连接请求的确认报文

Page 27: 第 8 章 传输层协议

27

当一端为建立连接而发送它的 SYN 时,它为连接选择一个初始序号 ISN ,一个 SYN占用一个序号。

例如:1 )当主机 A 的 TCP 向主机 B 的 TCP 发出连接请求报文段时,其 SYN位置 1 ,同时选择一个初始序号 X 为 1200;

2 )当主机 B 对主机 A 的 SYN 报文段进行确认时,这个报文段中的 ACK 序号为 X+1=1201 。

Page 28: 第 8 章 传输层协议

28

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

终止比特 FIN (FINal) —— 用来释放一个连接。当 FIN 1 时,表明此报文段的发送端的数据已发送完毕,并要求释放传输连接,但接收端还可以继续接收数据。

Page 29: 第 8 章 传输层协议

29

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

窗口大小字段 —— 占 2 字节。窗口大小字段用来控制对方发送的数据量,单位为字节。 TCP 连接的一端根据设置的缓存空间大小确定自己的接收窗口大小,然后通知对方以确定对方的发送窗口的上限。

Page 30: 第 8 章 传输层协议

30

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部。

Page 31: 第 8 章 传输层协议

31

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

紧急指针字段 —— 占 16 bit 。紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。当URG(紧急标志位)置 1 ,该字段才有效,指示这个报文段中包括紧急数据。

Page 32: 第 8 章 传输层协议

32

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

选项字段 —— 长度可变。在 TCP 首部中有 40 字节的可选信息。 最重要的选项,即最大报文段长度 MSS (Maximum Segment Size) 。 MSS 告诉对方 TCP :“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”

MSS 是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部

才等于整个的 TCP 报文段。

Page 33: 第 8 章 传输层协议

33

选项 :在TCP首部中有 40字节的可选信息。最重要的选项是MSS(Maximum Segment Size) 。

代 码: 2 长 度: 4 最大报文段长度 ( 8bit) ( 8bit) ( 16bit)

选项MSS的格式

Page 34: 第 8 章 传输层协议

34

选项字段连接建立过程中,连接的双方都要宣布各自

的 MSS (在 SYN 报文段中给出 MSS 选项),并且查看对方给出的 MSS 。

在以后双方的数据传输过程中, MSS 取双方给出的最小值。如果一方没有指明这个选项,则默认它的 MSS 为 536B 。

Page 35: 第 8 章 传输层协议

35

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

填充字段 ——长度不定,用于填充以保证 TCP头部的长度为 4 字节的整数倍,值全为 0 。

Page 36: 第 8 章 传输层协议

36

8.4.3 TCP 的数据编号与确认 TCP 协议是面向字节流的。 TCP 将所要传送的

报文看成是字节组成的数据流,并使每一个字节对应于一个序号。

TCP 采用字节序号:字节流中的每一个字节都分配一个序号,使接收端 TCP 能把接收到的这些字节按正确的顺序重新装配起来交付到终点。

在连接建立时,双方要商定初始序号。 TCP 每次发送的报文段的首部中的序号字段数值表示该报文段中的数据部分的第一个字节的序号。

TCP 的确认是对接收到的数据的最高序号表示确认。接收端返回的确认号是已收到的数据的最高序号加 1 。因此确认号表示接收端期望下次收到的数据中的第一个数据字节的序号。

Page 37: 第 8 章 传输层协议

37

8.4.4 TCP 的连接管理1. 传输连接的三个阶段

传输连接就有三个阶段,即:连接建立、数据传送和连接释放。传输连接的管理就是使传输连接的建立和释放都能正常地进行。

连接建立过程中要解决以下三个问题:要使每一方能够确知对方的存在。要允许双方协商一些参数(如最大报文段长

度,最大窗口大小,服务质量等)。能够对传输实体资源(如缓存大小,连接表

中的项目等)进行分配。

Page 38: 第 8 章 传输层协议

38

客户服务器方式 TCP 的连接和建立都是采用客户服务器方

式。 主动发起连接建立的应用进程叫做客户 (cli

ent) 。 被动等待连接建立的应用进程叫做服务器

(server) 。

Page 39: 第 8 章 传输层协议

39

1 )建立连接 TCP协议中建立连接采用三次握手( three-way handshake)的方式实现。

TCP 协议建立连接三次握手的过程

报文段 1 : SYN 连接请求

报文段 2 : SYN+ACK 确认

报文段 3 : ACK 确认

主动打开 被动打开

Page 40: 第 8 章 传输层协议

40

建立 TCP 连接 A 的 TCP 向 B 发出连接请求报文段,其首部中的同步比特 SYN 应置为 1 ,并选择序号 x ,表明传送数据时的第一个数据字节的序号是 x 。

B 的 TCP 收到连接请求报文段后,如同意,则发回确认。

B 在确认报文段( ACK置 1 )中应将 SYN 置为 1 ,其确认号应为 x 1 ,同时也为自己选择序号 y 。

A 收到此报文段后,向 B 给出确认 (ACK置 1) ,其确认号应为 y 1 ,序号是 x+1 。

A 的 TCP 通知上层应用进程,连接已经建立。 当运行服务器进程的主机 B 的 TCP 收到主机 A 的确

认后,也通知其上层应用进程,连接已经建立。

Page 41: 第 8 章 传输层协议

41

连接请求碰撞:两个主机同时向对方发出主动打开命令,同时要求和对方建立连接。

此种情况下,两个 TCP 都向对方发送 SYN+ACK 报文段,在双方之间建立一条连接。(注意:仅建立一条连接,而不是两条。)

时间

主动打开 主动打开

Page 42: 第 8 章 传输层协议

42

思考题 若 TCP使用两次握手的方法来建立连接,

是否可能产生死锁?试举例说明。

Page 43: 第 8 章 传输层协议

43

2 )释放连接TCP 连接释放四次握手的步骤 :

我已经没有数据要发送了。但你如果还发送数据,我仍接收。

报文段 1 : FIN

报文段 2 : ACK

报文段 3 : FIN

报文段 4 : ACK

Page 44: 第 8 章 传输层协议

44

连接释放 TCP 连接释放四次握手的步骤 :1) 首先进行关闭的客户端 TCP 发送第一个报文段,

终止比特 FIN 标志置 1 。将执行主动关闭,不再发送数据。

2) 服务器端 TCP 发送第二个报文段,用来确认从客户发来的 FIN 报文段。

3)当服务器端没有数据发送时,它就发送第三个报文段,终止比特 FIN 标志置 1 。

4) 客户端 TCP 发送第四个报文段, 用来确认从服务器端 TCP 收到了 FIN 报文段。

Page 45: 第 8 章 传输层协议

45

如果一个 TCP 连接的两端同时主动关闭(同时发送 FIN 报文段)。这两个报文段按常规方法被确认,然后连接被释放。这与两台主机按顺序先后释放连接没有本质区别。

Page 46: 第 8 章 传输层协议

46

3 ) 连接复位 连接复位表示撤销当前的连接。只要连接复位,双

方的数据传输就都立即终止。 当 TCP 需要连接复位时使用 RST 报文段,其复位

比特 RST置 1 。 发生连接复位的 3 种情况: ( 1 )一端的 TCP请求连接到并不存在的端口,另一端

的 TCP 就可以发送一个复位报文段来取消这个请求。 ( 2 )一端的 TCP 出现异常,而愿意把连接异常终止,

它就可以发送复位报文段来关闭这一连接。 ( 3 )一端的 TCP 可能发现在另一端的 TCP 已经空闲了很长时间,则它可以发送复位报文段把这个连接撤销。

复位报文段不需另一端做出任何响应,也不需要另一端进行确认。

Page 47: 第 8 章 传输层协议

47

8.4.5  TCP 的连接管理状态转换 TCP 的 11 种连接状态名称及其描述:

CLOSED :没有任何连接状态

LISTEN :服务器侦听来自客户的 TCP 的连接请求

SYN-SENT :在发送连接请求后等待确认

SYN-RECEIVED :收到连接请求

ESTABLISHED :已建立连接,可传输数据

FIN-WAIT-1 :应用进程请求关闭连接,已发出 FIN ,等待对方同意释放连接的确认

FIN-WAIT-2 :已收到对方同意释放连接的确认,等待对方关闭连接

TIME-WAIT :等待足够的时间以确保该连接的所有报文段消失

CLOSING :双方同时开始关闭连接,双方都在等待对方同意自己关闭连接的确认

CLOSE-WAIT :服务器等待自己的应用进程要求释放连接

LAST-ACK :服务器等待客户端对服务器端释放连接请求的确认

Page 48: 第 8 章 传输层协议

48

8.4.5  TCP 的连接管理状态转换

用有限状态机描述 TCP 的各种连接状态以及各状态之间可能发生的转换。

在任何时刻,机器只处于某一种状态,并一直保持这个状态,直到某个事件发生。发生的事件使机器进入一个新的状态,即事件可使机器完成某种操作。

状态转换表示一个状态到另一个状态的迁移,包括迁移的条件和迁移的动作。

Page 49: 第 8 章 传输层协议

49

8.4.5  TCP 的连接管理状态转换 为了管理因特网,在网络管理中心设有管理信息库 MIB (Management Information Base) 。

管理信息库存放着各主机的 TCP 连接表。 TCP 连接表对每个连接都登记了其连接信息。除本地和远地的 IP 地址和端口号外,还要记录每一个连接所处的状态。 连接状态 本地 IP 地址 本地端口 远地 IP 地址 远地端口

连接 1连接 2

连接 n

Page 50: 第 8 章 传输层协议

50

8.4.5  TCP 的连接管理状态转换 TCP 的 11 种连接状态名称及其描述:

CLOSED :没有任何连接状态

LISTEN :服务器侦听来自客户的 TCP 的连接请求

SYN-SENT :在发送连接请求后等待确认

SYN-RECEIVED :收到连接请求

ESTABLISHED :已建立连接,可传输数据

FIN-WAIT-1 :应用进程请求关闭连接,已发出 FIN ,等待对方同意释放连接的确认

FIN-WAIT-2 :已收到对方同意释放连接的确认,等待对方关闭连接

TIME-WAIT :等待足够的时间以确保该连接的所有报文段消失

CLOSING :双方同时开始关闭连接,双方都在等待对方同意自己关闭连接的确认

CLOSE-WAIT :服务器端等待自己的应用进程要求释放连接

LAST-ACK :服务器端等待客户端对服务器端释放连接请求的确认

Page 51: 第 8 章 传输层协议

51

TCP的有限状态机

CLOSED

ESTABLISHED

LISTEN

CLOSE_WAIT

FIN_WAIT_1

SYN_RCVD

FIN_WAIT_2

CLOSING

TIME_WAIT

SYN_SENT

LAST_ACK

主动打开

被动打开

被动关闭

主动关闭

起点

被动打开 主动打开 发送 SYN

同时打开收到 SYN ,发送 SYN, ACK

收到 ACK

数据传送 阶段

关闭发送 FIN

关闭发送 FIN

关闭发送 FIN

收到 RST

收到 SYN发送 SYN, ACK

关闭或超时

收到 ACK

收到 SYN, ACK发送 ACK

收到 ACK收到 ACK

收到 FIN发送 ACK

收到 FIN, ACK 发送 ACK

收到 FIN发送 ACK

同时关闭

收到 FIN发送 ACK

发送 SYN

定时经过两倍报文段寿命后

关闭粗实线表示客户端状态转换流程

粗虚线表示服务器端状态转换流程

Page 52: 第 8 章 传输层协议

52

TCP 的正常的连接建立和关闭

SYN, SEQ = x

客户进程 服务器进程

LISTEN (被动打开)

(主动打开 ) SYN_SENT SYN_RCVD

ESTABLISHED

ESTABLISHED

(主动关闭 ) FIN_WAIT_1 CLOSE_WAIT ( 被动关闭 )

FIN_WAIT_2

LAST_ACKTIME_WAIT

CLOSED

(全双工数据传送阶段)

SYN, ACK, SEQ = y, ACK = x + 1

ACK, SEQ = x + 1, ACK = y + 1

FIN, SEQ = u

ACK, SEQ = v, ACK = u + 1

FIN, ACK, SEQ = v, ACK = u + 1

ACK, SEQ = u + 1, ACK = v + 1TIME_WAIT

CLOSE_WAIT

SYN_RCVD

ESTABLISHED

Page 53: 第 8 章 传输层协议

53

8.4.6 流量控制 TCP 连接的每一方都有个固定大小的缓冲空间用来暂存从应

用程序传递来并准备发送的数据。 流量控制:定义发送端在收到从接收端发来的确认报文之前可

以发送的数据量。 传输层通信的两种极端情况:

发送端只发送一个字节的数据,然后等待确认,当收到接收端的确认后再发送下一个字节。(简单的确认重发机制)

——传输效率低 传输层协议能够发送它的所有数据而不考虑确认。 ——加快了传输过程,但可能造成缓冲区溢出

为了防止发送方的数据发送得过快,以致接收方来不及处理的情况。 TCP 采用可变大小的滑动窗口协议进行流量控制。

Page 54: 第 8 章 传输层协议

54

8.4.6 流量控制 TCP 采用可变大小的滑动窗口协议进行流量控

制。滑动窗口机制是对简单的确认重发机制的改进: 简单确认重发机制:发送方在发送一个数据之后必须停下来等待对方确认,在这段时间只有一个数据在从发送方到接收方的路径上传输。

滑动窗口机制:允许发送方可以连续发送多个数据,然后再等待接收方的确认。

Page 55: 第 8 章 传输层协议

55

8.4.6 流量控制滑动窗口的概念

TCP 采用大小可变的滑动窗口进行流量控制。滑动窗口协议定义了在缓存上的一个窗口。

窗口大小的单位是字节。一台主机在等待另一台主机发来的确认报文期间可以发送多少个字节,由窗口大小定义。

Page 56: 第 8 章 传输层协议

56

TCP首部

20字节固定首部

目 的 端 口

数据偏移

检 验 和

选 项 (长 度 可 变)

源 端 口

序 号

紧 急 指 针

窗 口 大 小

确 认 号

保 留FIN

SYN

RST

PSH

ACK

URG

比特 0 8 16 24 31

填 充

在 TCP 报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。

发送窗口在连接建立时由双方商定。但在通信的过程中,接收端可根据自己的

资源情况,随时动态地调整对方的发送窗口上限值 ( 可增大或减小 ) 。

Page 57: 第 8 章 传输层协议

57

8.4.6 流量控制滑动窗口的概念

窗口区间是缓存的一部分,随着数据的发送和确认的接收能够在缓存上移动,因此称为“滑动窗口”。

缓存是循环使用的,可以把缓存看成一片环形的空间。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

滑动方向窗口 窗口起点

滑动方向:回到起点

终点

Page 58: 第 8 章 传输层协议

58

8.4.6 流量控制滑动窗口的概念

TCP 协议发送的字节流根据数据状态分成 3 个部分:( 1 )已经发送过且收到了对方确认的数据,发送方 TCP 能确定

这些数据已被对方收到。( 2 )已经发送但还没收到对方确认的数据,这些数据存在 3 种可

能: 1 )数据正在传输途中 2 )对方已收到,但正在传输这些数据的确认 3 )数据的确认已经丢失 ( 3 )发送方的 TCP 还没有发送的数据。

已发送 发送中 待发送

TCP 的数据状态划分

Page 59: 第 8 章 传输层协议

59

收到确认即可前移

100 200 300 400 500 600 700 800 900101 201 301 401 501 601 701 8011

发送窗口

可发送 不可发送

指针

发送端要发送 900 字节长的数据,划分为 9 个 100 字节长的报文段,而发送窗口确定为 500 字节。

发送端只要收到了对方的确认,发送窗口就可前移。

发送 TCP 要维护一个指针。每发送一个报文段,指针就向前移动一个报文段的距离。

Page 60: 第 8 章 传输层协议

60

收到确认即可前移

100 200 300 400 500 600 700 800 900101 201 301 401 501 601 701 8011

可发送 不可发送

指针

100 200 300 400 500 600 700 800 900101 201 301 401 501 601 701 8011

发送窗口

可发送 不可发送

指针 发送窗口前移

发送端已发送了 400 字节的数据,但只收到对前 200 字节数据的确认,同时窗口大小不变。

现在发送端还可发送 300 字节。

已发送并被确认

已发送但未被确认

Page 61: 第 8 章 传输层协议

61

100 200 300 400 500 600 700 800 900101 201 301 401 501 601 701 8011

已发送并被确认

已发送但未被确认 可发送 不可发送

指针

100 200 300 400 500 600 700 800 900101 201 301 401 501 601 701 8011

已发送并被确认 可发送 不可

发送指针

发送窗口前移

发送窗口缩小

发送端收到了对方对前 400 字节数据的确认,但对方通知发送端必须把窗口减小到 400 字节。

现在发送端最多还可发送 400 字节的数据。

Page 62: 第 8 章 传输层协议

62

8.4.6 流量控制利用可变窗口大小进行流量控制

应用程序写入 2KB 数据

应用程序写入 2KB 数据

报文段 1 : 0~2047B

ACK 报文段

报文段 2 : 2048~4095B

ACK 报文段

ACK 报文段

报文段 3 : 4096~5119B

ACK 报文段

直到收到非零WIN

应用程序写入 1KB 数据

2KB 空

4KB(满 )

空 2KB

1KB空 2KB

0 4KB

0 4KB

0 4KB

0 4KB应用进程读取 2KB 数据

0 4KB

已存储数据的区域

空闲区域

Page 63: 第 8 章 传输层协议

63

8.4.6 流量控制

当窗口大小为 0 时,发送端不能再发送数据,以下两种情况例外:

1 )紧急数据可以发送 2 )发送方想让接收方宣布下一个期望的字

节和窗口的大小,则可以发送一个字节的报文段。(避免当一个宣告窗口信息的报文段丢失之后发生死锁。)

Page 64: 第 8 章 传输层协议

64

8.4.7 傻瓜窗口综合症

当发送端应用进程产生数据很慢、或者接收端应用进程处理数据接收缓冲区数据很慢,或者二者兼而有之;就会使应用进程间传送的报文段很小,特别是有效载荷很小。极端情况下,每次只发送包含有效载荷为一个字节的报文段,同时接收方每次也仅对接收到的包含一个字节有效载荷的报文段进行确认。有效载荷只有 1个字节;而传输开销有 40字节 (20 字节的 IP 头 +20 字节的 TCP头 )这种现象就叫傻瓜窗口综合症。

Page 65: 第 8 章 传输层协议

65

8.4.7 傻瓜窗口综合症

傻瓜窗口综合症分为两大类: 发送端引起的傻瓜窗口综合症 接收端引起的傻瓜窗口综合症

Page 66: 第 8 章 传输层协议

66

8.4.7 傻瓜窗口综合症发送端引起的傻瓜窗口综合症:如果发送端为

产生数据很慢的应用程序服务,例如,一次产生一个字节。这个应用程序一次将一个字节的数据写入发送端的 TCP 的缓存。如果发送端的TCP没有特定的指令,它就产生只包括一个字节数据的报文段。结果有很多数据区包含字节数很少的 IP 数据报就在互连网中传来传去。

Page 67: 第 8 章 传输层协议

67

8.4.7 傻瓜窗口综合症

针对发送端引起的傻瓜窗口综合症的改进策略Nagle算法: 主要针对发送方应用进程产生数据比较慢,

而造成发送报文段包含数据量比较小的情况,其主要思想是强迫发送方等待,让它收集发送数据,以便发送大块数据,即通过减少发送次数来加大每次发送的数据量。

Page 68: 第 8 章 传输层协议

68

8.4.7 傻瓜窗口综合症• 针对发送端引起的傻瓜窗口综合症的改进策略• Nagle 算法:

Page 69: 第 8 章 传输层协议

69

8.4.7 傻瓜窗口综合症

针对发送端引起的傻瓜窗口综合症的改进策略Nagle算法: 优点就是简单,并且它考虑到应用程序产

生数据的速率,以及网络运输数据的速率。若应用程序比网络更快,则报文段就更大(最大报文段长度MSS )。若应用程序比网络慢,则报文段就较小(小于最大报文段长度MSS )。

Page 70: 第 8 章 传输层协议

70

8.4.7 傻瓜窗口综合症接收端引起的傻瓜窗口综合症: 如果接收端的应用程序处理数据很慢,例如,一次消耗一个字节。 1 )假定发送端应用程序产生了 1000 字节的数据块,但接收端应用程序每次只吸收 1 字节的数据。

2 ) 再假定接收端的 TCP 的输入缓存为 4000 字节。发送端先发送第一个4000 字节的数据。接收端将它存储在其缓存中。现在缓存满了。它通知窗口大小为零,这表示发送端必须停止发送数据。

3 )接收应用程序从接收端的 TCP 的输入缓存中读取第一个字节的数据。在输入缓存中现在有了 1 字节的空间。接收端的 TCP宣布其窗口大小为 1 字节,这表示期待发送端的 TCP会把这个宣布当作一个好消息,并使发送端发送只包括一个字节数据的报文段。

4 ) 这样的过程一直继续下去。一个字节的数据被消耗掉,然后发送只包含一个字节数据的报文段。

Page 71: 第 8 章 传输层协议

71

8.4.7 傻瓜窗口综合症

针对由接收端引起的傻瓜窗口综合症,即接收端应用程序消耗数据比到达的慢,有两种建议的改进策略:

Clark算法延迟确认算法

Page 72: 第 8 章 传输层协议

72

8.4.7 傻瓜窗口综合症Clark算法: 只要接收方的接收缓冲区已满,则每次接收

到 TCP 报文后返回窗口值为 0 的确认报文,以停止发送方的数据发送,直到接收缓冲区的空闲区域已经能容纳最大长度的报文段或有一半以上的接收缓空间已经空闲,再发送一个窗口值不为 0 的确认窗口,以重新更新发送方的滑动窗口大小,使发送方可以继续发送报文段。

Page 73: 第 8 章 传输层协议

73

8.4.7 傻瓜窗口综合症延迟确认算法: 当接收方收到报文段后,并不马上回复确认报文,

而是等接收缓冲区已经有一定数量的空闲空间后,再回送确认报文段。这样便可减慢发送方滑动窗口的滑动速度,进而降低数据的发送速度。优点:减少了通信量。接收端不需要确认每一个报文段。缺点:延迟确认的延迟时间过长有可能迫使发送方重传未被确认的报文,因此延迟确认的时间不能太长,一般不能超过 500ms 。

Page 74: 第 8 章 传输层协议

74

8.4.8 差错控制

TCP差错控制包括检测受到损伤的报文段、丢失的报文段、失序的报文段和重复的报文段,以及检测出差错后纠正差错,它除了使用检验和,还使用确认技术和超时机制。

TCP 发送方采用超时机制来恢复报文段的丢失问题

TCP使用累计确认系统。

Page 75: 第 8 章 传输层协议

75

8.4.8 差错控制 防丢失——带重传的肯定确认技术(超时机制)

Page 76: 第 8 章 传输层协议

76

8.4.8 差错控制

TCP 的确认是对收到的字节流进行累计确认。发送 TCP 报文段时,头部的“确认号”就指出该端希望接收的下一个字节的序号,其含义是在此之前的所有数据都已经正确收到,请发送从确认号开始的数据。

TCP 的确认方式有两种:一种是利用只有 TCP 头部,而没有数据区的专门确认报文段进行确认;另一种是当通信双方都有数据要传输时,把确认“捎带”在要传输的报文段中进行确认,因此这种 TCP 的确认报文段和普通数据报文段没有区别。

Page 77: 第 8 章 传输层协议

77

8.4.8 差错控制

防重复——可捎带的累计确认技术① 为每一个报文段赋予序号。② 确认时也指明确认哪个报文段。③ 序号同时保证了报文段之间的正确顺序。

Page 78: 第 8 章 传输层协议

78

8.4.8 差错控制累计确认机制

每一个确认是证实一直到由确认号指明的字节为止的所有字节都已经收到了。

序号为 1601的字节之前的所有字节都已经收到

Page 79: 第 8 章 传输层协议

79

确认 TCP 采用确认来证实收到了报文段 控制报文段不携带数据,但消耗一个序号 控制报文段也需要确认 ACK 报文段不需要确认

Page 80: 第 8 章 传输层协议

80

产生确认

1. 当某一端向另一端发送数据报文段时,必须包含确认,此确认给出它所期望接收的下一个序号。

2. 当接收端没有数据要发送,并且收到了按序到达的报文段,同时前一个报文段也已经确认了,那么接收端就推迟发送确认报文段,直到另一个报文段到达,或再经过一段时间(通常为 500ms )。

Page 81: 第 8 章 传输层协议

81

产生确认(续)3. 当具有所期望序号的报文段到达时,同时前一个按序到达的报文段还没有被确认,那么接收端就要立即发送 ACK 报文段。

4. 当序号比期望的序号还大的失序报文段到达时,接收端就要立即发送 ACK 报文段,并宣布下一个期望的报文段的序号。

5. 当一个丢失的报文段到达时,接收端就发送 ACK报文段,并宣告下一个所期望的序号。

6. 如果到达一个重复的报文段,接收端就要立即发送 ACK 报文段,这就解决了 ACK 报文段丢失时所带来的问题。

Page 82: 第 8 章 传输层协议

82

对于丢失或受损的报文段,发送方将依靠超时确认机制驱动报文段重发来解决。

报文段 3丢失重传

Page 83: 第 8 章 传输层协议

83

每一个报文段都包含检验和字段,用来检查收到损伤的报文段,若报文段收到损伤,则由接收端的 TCP 将其丢弃,并被认为是丢失了。

报文段 3受损重传重传的报文段 2丢失再重传

Page 84: 第 8 章 传输层协议

84

8.4.8 差错控制出现重复报文段时,接收方只是简单地丢弃重

复报文段。

Page 85: 第 8 章 传输层协议

85

8.4.8 差错控制当接收方的确认报文出现丢失等差错后, TCP引入了

累计确认机制,即当 B 发送的一个确认报文段丢失后,B系统可以不予理睬, A 后面所接收到的确认报文段可以确认一直到该报文段中的确认号指明的字节序号之前的所有字节都已经收到。

AB

Page 86: 第 8 章 传输层协议

86

8.4.8 差错控制

出现报文段失序的情况后, TCP 采用了延迟确认的方式予以解决,即当接收方收到失序报文段后不会马上确认,而是先将其存放在缓冲区中,当被确认报文段之前的所有报文段都已经收到了才回送确认报文。

Page 87: 第 8 章 传输层协议

87

8.4.9 拥塞控制

拥塞: 中间路由器或物理链路的超载势必也会引起数据传输的严重延时,即网络拥塞。

Page 88: 第 8 章 传输层协议

88

8.4.9 拥塞控制 发送端的主机在确定发送报文段的速率时,既要

根据接收端的接收能力,又要从全局考虑不要使网络发生拥塞。

因此,每一个 TCP 连接需要有以下两个状态变量:接收端窗口 rwnd (receiver window) 又称为通

知窗口 (advertised window) 。拥塞窗口 cwnd (congestion window) 。

Page 89: 第 8 章 传输层协议

89

接收端窗口 rwnd 和拥塞窗口 cwnd

(1) 接收端窗口 rwnd 这是接收端根据其目前的接收缓存大小所许诺的最新的窗口值,是来自接收端的流量控制。接收端将此窗口值放在 TCP 报文的首部中的窗口字段,传送给发送端。

(2) 拥塞窗口 cwnd 是发送端根据自己估计的网络拥塞程度而设置的窗口值,是来自发送端的流量控制。

Page 90: 第 8 章 传输层协议

90

发送窗口的上限值 发送端的发送窗口的上限值应当取为接收端窗口 rw

nd 和拥塞窗口 cwnd 这两个变量中较小的一个,即应按以下公式确定:

发送窗口的上限值 Min [rwnd, cwnd] ( 8-1 )

当 rwnd < cwnd 时,是接收端的接收能力限制发送窗口的最大值。

当 cwnd < rwnd 时,则是网络的拥塞限制发送窗口的最大值。

Page 91: 第 8 章 传输层协议

91

在 TCP 中引入了慢启动和拥塞避免两种策略机制来实现对拥塞窗口大小的控制,进而来避免和消除网络拥塞。慢启动算法拥塞避免算法

Page 92: 第 8 章 传输层协议

92

慢启动算法的原理 在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。

在每收到一个对新的报文段的确认后,将拥塞窗口增加至多一个 MSS 的数值(收到多少个确认,拥塞窗口就增加多少个 MSS )。

用这样的方法逐步增大发送端的拥塞窗口 cwnd ,可以使分组注入到网络的速率更加合理。

这样,接收方的确认报文返回的越快,表明网络通信能力越强,因此拥塞窗口大小就增长得越快。而且拥塞窗口大小的增长实际上是一种指数型增长,如果对其增长速度不控制,拥塞窗口很快就将变得很大。

Page 93: 第 8 章 传输层协议

93

拥塞避免算法为了避免拥塞窗口过快增长,尽量避免拥塞现象的出

现。当拥塞窗口大小达到一个门限值(慢启动门限值ssthresh )时,便采取拥塞避免算法来改变拥塞窗口的大小。

拥塞避免的原理:每收到一个确认报文,拥塞窗口大小增加一个 MSS ,即使该确认报文是针对多个报文段的,拥塞窗口也只增加一个 MSS 。

这样,拥塞窗口大小的增长就变成了线性增长,增长速度减缓了。当然,由于拥塞窗口依然在增长,最终仍然可能导致拥塞。

Page 94: 第 8 章 传输层协议

94

重传定时器

由于上述两种策略都将使拥塞窗口变得很大,进而造成网络拥塞的发生。为此, TCP/IP 中引入了重传定时器。

当由于网络拥塞使重传定时器超时的时候,发送方则进入拥塞解决阶段。发送方在进行 TCP报文段重传的同时,将拥塞窗口的门限值调整为拥塞窗口的一半,并将拥塞窗口恢复成一个MSS ,然后进入新一轮的调整。

Page 95: 第 8 章 传输层协议

95

慢启动和拥塞避免算法的实现举例

当 TCP 连接进行初始化时,将拥塞窗口置为 1 。图中的窗口单位不使用字节而使用报文段。慢启动门限的初始值设置为 16 个报文段,即 ssthresh = 16 。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 96: 第 8 章 传输层协议

96

慢启动和拥塞避免算法的实现举例

发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大,因此现在发送窗口的数值等于拥塞窗口的数值。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 97: 第 8 章 传输层协议

97

慢启动和拥塞避免算法的实现举例

在执行慢启动算法时,拥塞窗口 cwnd 的初始值为 1 ,发送第一个报文段 M0 。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 98: 第 8 章 传输层协议

98

慢启动和拥塞避免算法的实现举例

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

发送端收到 ACK1 (确认 M0 ,期望收到 M1 )后,将 cwnd 从 1 增大到 2 ,于是发送端可以接着发送 M1 和 M2 两个报文段。

Page 99: 第 8 章 传输层协议

99

慢启动和拥塞避免算法的实现举例

接收端发回 ACK2 和 ACK3 。发送端每收到一个对新报文段的确认 ACK ,就把发送端的拥塞窗口加 1 。现在发送端的 cwnd 从 2 增大到 4 ,并可发送 M3 ~ M6 共 4 个报文段。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 100: 第 8 章 传输层协议

100

慢启动和拥塞避免算法的实现举例

发送端每收到一个对新报文段的确认 ACK ,就把发送端的拥塞窗口加 1 ,因此拥塞窗口 cwnd 随着传输次数按指数规律增长。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 101: 第 8 章 传输层协议

101

慢启动和拥塞避免算法的实现举例

当拥塞窗口 cwnd 增长到慢启动门限值 ssthresh 时(即当 cwnd = 16 时),就改为执行拥塞避免算法,拥塞窗口按线性规律增长。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

ssthresh = 16

慢启动 慢启动

线性规律增长

拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 102: 第 8 章 传输层协议

102

慢启动和拥塞避免算法的实现举例

假定拥塞窗口的数值增长到 24 时,网络出现超时(表明网络拥塞了)。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 103: 第 8 章 传输层协议

103

慢启动和拥塞避免算法的实现举例

更新后的 ssthresh 值变为 12 (即发送窗口数值 24 的一半),拥塞窗口再重新设置为 1 ,并执行慢启动算法。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 104: 第 8 章 传输层协议

104

慢启动和拥塞避免算法的实现举例

当 cwnd = 12 时改为执行拥塞避免算法,拥塞窗口按按线性规律增长,每经过一个往返时延就增加一个 MSS 的大小。

2 4 6 8 10 12 14 16 18 20 2200

4

8

12

16

20

24

传输次数

拥塞窗口 cwnd

进入拥塞避免

发生超时

指数规律增长

线性规律增长

ssthresh = 16

慢启动 慢启动拥塞避免 拥塞避免

更新后的 ssthresh = 12

进入拥塞避免

Page 105: 第 8 章 传输层协议

105

8.4.10 定时器管理

定时器 重传定时器 持续定时器 保活定时器 时间等待定时器重传定时器 持续定时器 保活定时器 时间等待定时器

定时器

为了实现 TCP 协议,对每个连接 TCP 管理 4 个不同的定时器。

Page 106: 第 8 章 传输层协议

106

重传计时器( Retransmission Timer )

一般情况下,一个 TCP 段发送后启动重传计时器,如果在计时器超时前收到这个 TCP 段的确认,则停止该计时器,否则,重新发送该 TCP段。

Page 107: 第 8 章 传输层协议

107

重传计时器( Retransmission Timer )

超时应该多久呢?太长:低效(延时长,带宽利用率低)太短:造成不必要的重传(占用额外的带宽)

一个好的实现超时重发的方案应该是超时间隔可以随网络的通信状况而自动调整,即超时间隔应具有一定的自适应性。这种动态调整超时间隔的方法与一条连接从发送端发出数据到收到确认所需的往返时间 RTT(Round Trip Time)有关。

Page 108: 第 8 章 传输层协议

108

重传计时器( Retransmission Timer )TCP重传计时器基于 RTT

对于每一条 TCP 连接, TCP维护一个变量 RTT ,用于存放所估计的从发送端到目的端的往返传输时间。

每次发送一个 TCP 报文段时记录下这个时刻,当对 TCP 报文段的确认回来后就可以计算该段的往返传输时间样本 sampleRTT ,然后修正 RTT 变量:

其中为修正因子,决定了以前估计的 RTT 的权重, 0 1 ,一般取值为 7/8 。

平均往返时延 RTT

( 前一个 RTT) (1 ) (sampleRTT) ( 8-2 )

Page 109: 第 8 章 传输层协议

109

往返时延 RTT?

往返时间的测量相当复杂 TCP 报文段 1 没有收到确认。重传(即报文段

2 )后,收到了确认报文段 ACK 。 如何判定此确认报文段是对原来的报文段 1 的确

认,还是对重传的报文段 2 的确认?

发送一个TCP 报文段

超时重传TCP 报文段 收到 ACK

时间1 2

往返时延 RTT?

是对哪一个报文段的确认?

Page 110: 第 8 章 传输层协议

110

Karn 算法对重传多义性的解决方法

在计算平均往返时延 RTT 时,只要报文段重传了,就不采用其往返时延样本。

每重传一次,超时时间加倍 这样得出的平均往返时延 RTT 和重传

时间就较准确。

Page 111: 第 8 章 传输层协议

111

Karn修正算法

报文段每重传一次,就将重传时间增大一些:

新的重传时间 RTT ( 8-3 )

系数 的典型值是 2 ,即:设定重传时间等于前一个 RTT值的两倍。当等待到 2倍的加权平均往返时间后还没有收到确认就重发数据。 。

当不再发生报文段的重传时,才根据报文段的往返时延更新平均往返时延 RTT 和重传时间的数值(公式 8-2 )。

实践证明,这种策略较为合理。

Page 112: 第 8 章 传输层协议

112

8.4.10 定时器管理持续计时器( Persistence Timer )

如果发送窗口大小为 0 的 ACK 报文段后,该 TCP 接收进程发现可以继续接收对方的数据,这时需要发送窗口大小为一定值的 ACK 报文段,但是这个 ACK 报文段由于某种原因而被丢失,如果没有相应的措施,那么就会发生死锁。

解决的办法就是采用持续计时器,当这个计时器超时后还未收到对方的数据,则可以认为这个 ACK被丢失,并且重新发送该 ACK 段。

其它计时器

Page 113: 第 8 章 传输层协议

113

8.5 TCP8.5 TCP 与与 UDPUDP 的比较的比较