05.计算机网络-2015版本-阮晓龙-第5章：运输层

Transcription

1 1 计算机网络 第五章 : 运输层 阮晓龙 / rxl@hactcm.edu.cn 河南中医学院管理信息工程学科河南中医学院网络信息中心

2 2 本章教学计划 运输层协议概述 用户数据报协议 UDP UDP 传输控制协议 TCP 可靠传输的工作原理 TCP 报文段的首部格式 TCP 可靠传输的实现 TCP 的流量控制 TCP 的拥塞控制 TCP 的运输连接管理 TCP

3 3 本章教学计划 概括介绍运输层协议的特点, 以及进程之间的通信以及端口等重要概念 讲述 UDP 和 TCP 协议 重点讨论较为复杂的 TCP 协议 : TCP 协议和可靠传输原理 TCP 的三个重要问题 : 滑动窗口 流量控制 拥塞控制 TCP 连接管理

4 4 本章教学计划 运输层是整个网络体系结构中的关键层次之一, 本部分的重要概念有 : 运输层为相互通信的应用进程提供逻辑通信 端口和套接字 UDP 的特点 TCP 的特点 在不可靠的网络上实现可靠传输的工作原理, 以及停止等待协议和 ARQ 协议 TCP 的滑动窗口 流量控制 拥塞控制 TCP 的连接管理

5 5 1. 运输层协议概述 1.1 进程之间的通信 从通信和信息处理的角度看, 运输层向它上面的应用层提供通信服务, 它属于面向通信部分的最高层, 同时也是用户功能中的最低层 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时, 只有位于网络边缘部分的主机的协议栈才有运输层, 而网络核心部分中的路由器在转发分组时都只用到下三层的功能

6 6 1. 运输层协议概述 1.1 进程之间的通信 应用进程应用进程 AP 1 AP 5 2 端口运输层提供应用进程间的逻辑通信端口 4 AP 3 AP IP 层 主机 A 主机 B AP 路由器 1 路由器 2 1 LAN AP 3 LAN WAN AP AP 4 IP 协议的作用范围 运输层协议 TCP 和 UDP 的作用范围

7 7 1. 运输层协议概述 1.1 进程之间的通信 两个主机进行通信实际上就是两个主机中的应用进程互相通信 应用进程之间的通信又称为端到端的通信 运输层的一个很重要的功能就是复用和分用 应用层不同进程的报文通过不同的端口向下交到运输层, 再往下就共用网络层提供的服务 运输层提供应用进程间的逻辑通信 逻辑通信 的意思是 : 运输层之间的通信好像是沿水平方向传送数据 但事实上这两个运输层之间并没有一条水平方向的物理连接

8 8 1. 运输层协议概述 1.1 进程之间的通信 因特网 IP 协议的作用范围 ( 提供主机之间的逻辑通信 ) TCP 和 UDP 协议的作用范围 ( 提供进程之间的逻辑通信 )

9 9 1. 运输层协议概述 1.1 进程之间的通信 运输层的主要作用 : 运输层为应用进程之间提供端到端的逻辑通信, 网络层是为主机之间提供逻辑通信 运输层还要对收到的报文进行差错检测 网络层只对 IP 数据报首部提供首部数据的校验而不检查数据部分 根据应用程序的不同需求, 运输层需要有两种不同的运输协议, 即面向连接的 TCP 和无连接的 UDP

10 10 1. 运输层协议概述 1.1 进程之间的通信 两种不同的运输协议 : 运输层向高层用户屏蔽了下面网络核心的细节 ( 如网络拓扑 所采用的路由选择协议等 ), 它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道 当运输层采用面向连接的 TCP 协议时, 尽管下面的网络是不可靠的 ( 只提供尽最大努力服务 ), 但这种逻辑通信信道就相当于一条全双工的可靠信道 当运输层采用无连接的 UDP 协议时, 这种逻辑通信信道是一条不可靠信道

11 11 1. 运输层协议概述 1.2 运输层的两个主要协议 TCP/IP 的运输层有两个不同的协议, 且都是因特网标准 用户数据报协议 UDP(User Datagram Protocol),RFC 768 传输控制协议 TCP(Transmission Control Protocol),RFC 793 两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU(Transport Protocol Data Unit) TCP 传送的数据单位协议是 TCP 报文段 (segment) UDP 传送的数据单位协议是 UDP 报文或用户数据报

12 12 1. 运输层协议概述 1.2 运输层的两个主要协议 UDP 在传送数据之前不需要先建立连接 对方的运输层在收到 UDP 报文后, 不需要给出任何确认 虽然 UDP 不提供可靠交付, 但在某些情况下 UDP 是一种最有效的工作方式 TCP 提供面向连接的服务 TCP 不提供广播或多播服务 由于 TCP 要提供可靠的 面向连接的运输服务, 因此不可避免地增加了许多的开销 这不仅使协议数据单元的首部增大很多, 还要占用许多的处理机资源

13 13 1. 运输层协议概述 1.3 运输层的端口 运输层的重要功能就是复用和分用 应用层所有的应用进程都可以通过运输层再传送到 IP 层, 这就是复用 运输层从 IP 层收到数据后必须交付指明的应用进程, 这就是分用 这就说明 : 给应用层的每个应用进程赋予一个非常明确的标志是非常重要的 也就是说, 应用层的应用进程必须要有明确的标识系统

14 14 1. 运输层协议概述 1.3 运输层的端口 讨论 : 应用进程标识的几种可能性

15 15 1. 运输层协议概述 1.3 运输层的端口 解决应用进程标识问题的方法就是在运输层使用协议端口号 (protocol port number), 或通常简称为端口 (port) 虽然通信的终点是应用进程, 但可以把端口想象是通信的终点, 因为只要把要传送的报文交到目的主机的某一个合适的目的端口, 剩下的工作 ( 即最后交付目的进程 ) 就由 TCP 来完成

16 16 1. 运输层协议概述 1.3 运输层的端口 注意 : 软件端口与硬件端口 在协议栈层间的抽象的协议端口是软件端口 路由器或交换机上的端口是硬件端口 硬件端口是不同硬件设备进行交互的接口, 而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址 协议端口和硬件端口是完全无关的两个概念

17 17 1. 运输层协议概述 1.4 端口的标示 TCP/IP 的运输层使用一个 16 位端口号进行端口标志 端口号只具有本地意义, 即端口号只是为了标志本计算机应用层中的各进程 在因特网中不同计算机的相同端口号是没有联系的 16 位端口号就表明端口号的取值为 0~65535, 共计 个不同的端口号

18 18 1. 运输层协议概述 1.4 端口的标示 端口分为两类 : 服务器端使用的端口号 : 熟知端口号 (wellknown port number) 或系统端口号, 数值为 0~1023 IANA 把这些端口号指派给 TCP/IP 最重要的一些应用程序, 让所有用户都知道 登记端口号, 数值为 1024~49151 这类端口是为没有熟知端口号的应用程序使用的, 使用这类端口号必须在 IANA 按照规定的手续登记, 以防止重复 讨论 : 我是否可以自由使用服务器端使用的端口号?

19 19 1. 运输层协议概述 1.4 端口的标示 端口分为两类 : 客户端使用的端口号 : 数值为 49152~65535, 留给客户进程选择暂时使用 当服务器进程收到客户进程的报文时, 就知道了客户进程所使用的动态端口号 通信结束后, 这个端口号可供其他客户进程以后使用

20 20 1. 运输层协议概述 1.4 端口的标示 IANA 定义的常见服务端口 :

21 21 1. 运输层协议概述 1.4 端口的标示 演示 : 查看 Windows 系统中端口占用情况 : Windows 系统端口 : 通过控制台命令 netstat 查看端口占用情况 Netstat -an Netstat ano findstr 80 使用 TCPView 查看端口占用情况 官网 :

22 22 1. 运输层协议概述 1.4 端口的标示 演示 : 查看 Linux 系统中端口占用情况 : Linux 系统端口 :/etc/services 使用 Netstat 命令查看活动端口

23 23 2. 用户数据报协议 UDP 2.1 UDP 概述 UDP 只在 IP 的数据报服务之上增加了很少一点的功能, 即使用端口实现复用的功能和差错检测的功能 UDP 用户数据报只能提供不可靠的交付, 但 UDP 在某些方面有其特殊的优点

24 24 2. 用户数据报协议 UDP 2.1 UDP 概述 UDP 的主要特点 : UDP 是无连接的, 即发送数据之前不需要建立连接 UDP 使用尽最大努力交付, 即不保证可靠交付, 同时也不使用拥塞控制 UDP 是面向报文的 应用层交下来的报文,UDP 在添加首部后就直接交付给网络层, 不做拆分合并, 而是保留报文的边界 对于收到的 UDP 报文, 去除首部后直接提交给应用层 UDP 没有拥塞控制 网络出现拥塞也不会使源主机的发送速率降低, 很适合多媒体通信的要求 UDP 支持一对一 一对多 多对一和多对多的交互通信 UDP 的首部开销小, 只有 8 个字节

25 25 2. 用户数据报协议 UDP 2.1 UDP 首部格式 应用层报文 应用层 UDP 首部 UDP 用户数据报的数据部分运输层 IP 首部 IP 数据报的数据部分 网络层

26 26 2. 用户数据报协议 UDP 2.1 UDP 首部格式 字节 源 IP 地址目的 IP 地址 0 17 UDP 长度 字节 伪首部源端口目的端口长度检验和 UDP 用户数据报 首部 数 据 发送在前 首部 数 据 IP 数据报

27 27 2. 用户数据报协议 UDP 2.1 UDP 首部格式 用户数据报 UDP 有两个字段 : 数据字段和首部字段 首部字段很简单, 只有 8 个字节, 由四个字段组成, 每个字段的长度都是两个字节 各字段意义为 : 源端口 : 源端口号 在需要对方回信时选用 不需要时可用全 0 目的端口 : 目的端口号 在终点交付报文时必须要使用到 长度 :UDP 用户数据报的长度, 最小值为 8 检验和 : 检测 UDP 用户数据报在传输时是否有错

28 28 2. 用户数据报协议 UDP 2.1 UDP 首部格式 当运输层从 IP 层收到 UDP 数据报时, 就根据首部中的目的端口, 把 UDP 数据报通过相应的端口, 上交到相应的应用进程 端口 1 端口 2 端口 3 UDP 分用 UDP 数据报到达 IP 层

29 29 2. 用户数据报协议 UDP 2.1 UDP 首部格式 在计算校验和时, 在 UDP 用户数据报之前增加 12 个字节的伪首部 它只在计算时使用, 既不向上也不向下传送 仅仅为了计算校验和 字节 源 IP 地址目的 IP 地址 0 17 UDP 长度 字节 伪首部源端口目的端口长度检验和 UDP 用户数据报 首部 数 据 发送在前 首部 数 据 IP 数据报

30 30 2. 用户数据报协议 UDP 2.2 UDP 校验和 在计算校验和时, 在 UDP 用户数据报之前增加 12 个字节的伪首部 它只在计算时使用, 既不向上也不向下传送 仅仅为了计算校验和 现场讨论并演算 :UDP 检验和的计算

31 31 2. 用户数据报协议 UDP 2.2 UDP 校验和 计算 UDP 校验和 12 字伪首部 8 字节 UDP 首部 7 字节数据 全 全 0 数据数据 数据数据 数据数据 数据全 0 填充

32 32 2. 用户数据报协议 UDP 2.2 UDP 校验和 12 字伪首部 8 字节 UDP 首部 7 字节数据 全 全 0 数据数据 数据数据 数据数据 数据全 0 填充 和 ( 检验和 ) 数据 数据 数据 数据和 0

33 33 2. 用户数据报协议 UDP 2.2 UDP 校验和

34 34 2. 用户数据报协议 UDP 2.2 UDP 校验和

35 35 2. 用户数据报协议 UDP 2.2 UDP 校验和 校验和

36 36 2. 用户数据报协议 UDP 2.2 UDP 校验和 实例 :UDP 校验和的计算

37 37 3. 传输控制协议 TCP 3.1 TCP 的主要特点 TCP 是 TCP/IP 体系中最复杂的一个协议, 其主要特点有 : TCP 是面向连接的运输层协议 每一条 TCP 连接只能有两个端点 (endpoint), 每一条 TCP 连接只能是点对点的 ( 一对一 ) TCP 提供可靠交付的服务 TCP 提供全双工通信 面向字节流

38 38 3. 传输控制协议 TCP 3.1 TCP 的主要特点 TCP 是面向字节流,TCP 中的 流 (stream) 指的是流入到进程或从进程流出的字节序列 面向字节流的含义是 : 虽然应用程序和 TCP 的交互是一次一个数据块, 但 TCP 把应用程序交下来的数据看成仅仅是一连串的无结构的字节流 TCP 并不知道传送的字节流的含义

39 39 3. 传输控制协议 TCP TCP 发送方 应用进程 字节流 把字节写入发送缓存 H H x 表示 TCP 报文段的首部 表示序号为 x 的数据字节 加上 TCP 首部构成 TCP 报文段 10 9 H TCP 连接 发送 TCP 报文段 H 从接收缓存读取字节 3.1 TCP 的主要特点 TCP 接收方 应用进程 字节流

40 40 3. 传输控制协议 TCP 3.1 TCP 的主要特点 对 TCP 面向字节流的补充说明 : TCP 连接是一条虚连接而不是一条真正的物理连接 TCP 对应用进程一次把多长的报文发送到 TCP 的缓存中是不关心的 TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节 (UDP 发送的报文长度是应用进程给出的 ) TCP 可把太长的数据块划分短一些再传送,TCP 也可等待积累有足够多的字节后再构成报文段发送出去

41 41 3. 传输控制协议 TCP 3.2 TCP 的连接 TCP 把连接作为最基本的抽象 TCP 的许多特征都与 TCP 是面向连接的这个基本特征有关 每一条 TCP 连接有两个端点 但是 TCP 连接的端点不是主机, 不是主机的 IP 地址, 不是应用进程, 也不是运输层的协议端口 TCP 连接的端点叫做套接字 (socket) 或插口 根据 RFC793 的定义 : 端口号拼接到 (contatenated with) IP 地址即构成了套接字

42 42 3. 传输控制协议 TCP 3.2 TCP 的连接 套接字 socket = (IP 地址 : 端口号 ) 每一条 TCP 连接唯一地被通信两端的两个端点 ( 即两个套接字 ) 所确定 即 : TCP 连接 ::={socket1, socket2} TCP 连接 ::={(IP1:port1),(IP2:port2)}

43 43 3. 传输控制协议 TCP 3.2 TCP 的连接 TCP 连接 ::={socket1, socket2} TCP 连接 ::={(IP1:port1),(IP2:port2)} IP1 IP2 分别是两个端点主机的 IP 地址, Port1 Port2 分别是两个端点主机中的端口号 TCP 连接的两个套接字就是 socket1 socket2

44 44 3. 传输控制协议 TCP 3.2 TCP 的连接 Socket 在不同的场景上有多种表示 : 允许应用程序访问连网协议的应用编程接口 API 称为 socket API, 简称为 socket socket API 中使用的一个函数名也叫作 socket 调用 socket 函数的端点称为 socket 调用 socket 函数时其返回值称为 socket 描述符, 可简称为 socket 在操作系统内核中连网协议的 Berkeley 实现, 称为 socket 实现?

45 45 4. 可靠传输的工作原理 TCP 发送的报文段是交给 IP 层传送的, 但是 IP 层只能提供尽最大努力服务, 也就是说,TCP 下面的网络所提供的是不可靠的传输 TCP 必须采用适当的措施才能使两个运输层之间的通信变得可靠

46 46 4. 可靠传输的工作原理 理想的传输条件有两个特点 : 传输信道不产生错误 不管发送方以多快的速度发送数据, 接收方总是来得及处理收到的数据 在理想传输条件下, 不需要采取任何措施就能够实现可靠传输 但是理想的传输条件是不存在的, 因为为了实现可靠传输就需要使用一些可靠传输协议 当发生差错时让发送方重传出现差错的数据, 在接收方来不及处理收到的数据时, 及时告诉发送方适当降低发送数据的速度

47 47 4. 可靠传输的工作原理

48 48 4. 可靠传输的工作原理 4.1 停止等待协议 全双工通信的双方既是发送方又是接收方 为了讨论问题的方便, 仅考虑从 A 向 B 传送数据,A 发送数据叫做发送方,B 接收数据并发送确认, 叫做接收方 本部分进讨论可靠传输原理, 因此把传送的数据单元叫做分组, 不考虑在哪一个层次上传送 停止等待就是每发送完一个分组就停止发送, 等待对方确认 收到确认后, 在发送下一个分组

49 49 4. 可靠传输的工作原理 A 发送分组 M1, 发完就暂停发送, 等待 B 的确认 B 收到 M1, 就向 A 发送确认 A 收到了对 M1 的确认后, 就再发送下一个分组 M2 在收到 B 对 M2 的确认后, 就再发送下一个分组 M3 A 发送 M 1 发送 M 2 发送 M 停止等待协议 B 确认 M 1 确认 M 2 确认 M 3 t t 无差错情况

50 50 4. 可靠传输的工作原理 4.1 停止等待协议 分组在传输过程中出现差错 B 接收 M1 时检测出了错误, 就丢弃 M1, 或者是 M1 在传输过程中丢失了 B 没有向 A 发送确认信息 A 超过一定时间没有收到确认, 就认为发送的分组丢失, 就重传 M1 A 在发送分组后设置超时计时器 A 发送 M 1 超时重传 M 1 发送 M 2 t 超时重传 B t 丢弃有差错的报文 确认 M 1

51 51 4. 可靠传输的工作原理 4.1 停止等待协议 A 在发送完一个分组后, 必须暂时保留已发送的分组的副本 分组和确认分组都必须进行编号, 才能够明确是哪一个发送出去的分组收到了确认 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些 A 发送 M 1 超时重传 M 1 发送 M 2 t 超时重传 B t 丢弃有差错的报文 确认 M 1

52 52 4. 可靠传输的工作原理 A 发送 M1,B 收到 M1 B 发送的 M1 确认丢失,A 在设定的超时重传时间内没有收到确认 A 在超时后重传 M1,B 收到重传 M1 后, 丢弃重传 M1 数据, 并且再次确认 M1 超时重传 M 1 发送 M 2 A 4.1 停止等待协议 B 确认 M 1 丢弃重复的 M 1 重传确认 M 1 t t 确认丢失

53 53 4. 可靠传输的工作原理 4.1 停止等待协议 传输过程没有出现差错, 但是 B 对分组 M1 的确认迟到 A 会收到重复的确认,A 收到重复确认后直接丢弃 B 会收到重发的 M1,B 收到重复数据后直接丢弃, 并重新确认分组 发送 M 1 超时重传 M 1 发送 M 2 收下迟到 的确认 但什么也不做 t t A 确认迟到 B 确认 M 1 丢弃重复的 M 1 重传确认 M 1

54 54 4. 可靠传输的工作原理 4.1 停止等待协议 上述描述的确认和重传机制, 就可以在不可靠的传输网络上实现可靠的通信 上述的可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat request) 就是说, 重传的请求是自动进行的, 接收方不需要请求发送方重传某个出错的分组 发送方和接收方达成默契, 只要在超时重传时间内没有得到确认, 就自动重发分组

55 55 4. 可靠传输的工作原理 4.1 停止等待协议 上述描述的确认和重传机制, 就可以在不可靠的传输网络上实现可靠的通信 上述的可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat request) 就是说, 重传的请求是自动进行的, 接收方不需要请求发送方重传某个出错的分组 发送方和接收方达成默契, 只要在超时重传时间内没有得到确认, 就自动重发分组

56 56 4. 可靠传输的工作原理 4.1 停止等待协议 停止等待协议的优点是简单, 但缺点是信道利用率太低 B t A T D RTT t T D + RTT + T A

57 57 4. 可靠传输的工作原理 4.1 停止等待协议 信道利用率 U T D T D RTT T A

58 58 4. 可靠传输的工作原理 4.1 停止等待协议 计算 : 假定 1200km 的信道的往返时间 RTT=20ms, 分组长度为 1200bit, 发送速率为 1Mbps, 若忽略处理时间和 T A, 那么信道利用率为多少? 如果把发送速率提升为 10Mbps, 则信道利用率为多少? 如果把发送速率提升为 100Mbps, 则信道利用率为多少?

59 59 4. 可靠传输的工作原理 4.1 停止等待协议 在上述计算中, 如果 RTT 远大于分组发送时间, 那么信道利用率将非常低 如果考虑到出现差错后的分组重传, 则信道利用率还要进一步降低

60 60 4. 可靠传输的工作原理 4.1 停止等待协议 流水线传输 : 为了提高传输效率, 发送方可以不使用低效率的停止等待协议, 而是采用流水线传输 流水线传输就是发送方可连续发送多个分组, 不必每发完一个分组就停顿下来等待对方的确认 由于信道上一直有数据不间断地传送, 这种传输方式可获得很高的信道利用率

61 61 4. 可靠传输的工作原理 4.1 停止等待协议 流水线传输 : 流水线传输时, 最为常见的是连续 ARQ 协议和滑动窗口协议 B t A t

62 62 4. 可靠传输的工作原理 4.2 连续 ARQ 协议 滑动窗口协义比较复杂, 是 TCP 协议的精髓 本部分不涉及到细节问题, 先讨论连续 ARQ 协议的基本概念 在讨论之前, 需要先明确和重复一个概念 :TCP 是全双工通信,TCP 连接的通信两端可以同时发送和接收数据

63 63 4. 可靠传输的工作原理 4.2 连续 ARQ 协议 发送方维持发送窗口 位于发送窗口内的 5 个分组都可以连续发出去, 而不需要等待对方的确认 发送窗口 发送方维持发送窗口 ( 发送窗口是 5)

64 64 4. 可靠传输的工作原理 4.2 连续 ARQ 协议 连续 ARQ 协议规定, 发送方每收到一个确认, 就把发送窗口向前滑动一个分组的位置 当接收方发送一个确认而发送方收到后, 发送窗口向前移动一个分组, 则第 6 个分组就可以发送 发送窗口 向前 收到一个确认后发送窗口向前滑动

65 65 4. 可靠传输的工作原理 4.2 连续 ARQ 协议 接收方通常会采用累积确认的方式 接收方不必对收到的分组逐个发送确认, 而是在收到几个分组后, 对按序到达的最后一个分组发送确认 这就表示 : 到这个分组为止的所有分组都已经正确收到了 累积确认的优缺点 : 优点是 : 容易实现, 即使确认丢失也不必重传? 缺点是 : 不能向发送方反映出接收方已经正确收到的所有分组的信息

66 66 4. 可靠传输的工作原理 4.2 连续 ARQ 协议 累积确认的优缺点 : 优点是 : 容易实现, 即使确认丢失也不必重传? 缺点是 : 不能向发送方反映出接收方已经正确收到的所有分组的信息 讨论 : 如果发送方发送了前 5 个分组, 而中间的第 3 个分组丢失了 这时接收方只能对前两个分组发出确认 发送方无法知道后面三个分组的下落, 而只好把后面的三个分组都再重传一次 这就叫做 Go-back-N( 回退 N), 表示需要再退回来重传已发送过的 N 个分组 当通信线路质量不好时, 连续 ARQ 协议会带来负面的影响

67 67 5.TCP 报文段的首部格式 TCP 在通信时是面向字节流的, 但是 TCP 传送的数据单元却是报文段 TCP 报文段分为首部和数据两部分, 而 TCP 的全部功能都体现在它首部中各字段的作用 要想理解 TCP 的工作原理, 就必须要熟练掌握 TCP 首部各字段的作用

68 68 5.TCP 报文段的首部格式 TCP 报文段首部的前 20 个字节是固定, 后面有 4n 字节是根据需要而增加的选项 (n 是整数 ) TCP 首部的最小长度为 20 字节, 最大为 60 字节

69 69 5.TCP 报文段的首部格式 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 TCP 报文段 TCP 首部 TCP 数据部分 发送在前 IP 首部 IP 数据部分

70 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 源端口和目的端口字段 : 各 2 字节 端口是运输层与应用层的服务接口 运输层的复用和分用功能都要通过端口才能实现 序号字段 :4 字节 TCP 连接中传送的数据流中的每一个字节都编上一个序号 序号字段的值指的是本报文段所发送数据的第一个字节的序号 确认号字段 :4 字节 是期望收到对方的下一个报文段的数据的第一个字节的序号 如果确认号为 N, 则表明序号 N-1 为止的所有数据都已经正确收到

71 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 数据偏移 ( 即首部长度 ):4 位 它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远 数据偏移 的单位是 32 位字 ( 以 4 字节为计算单位 ) 因此 TCP 报文段首部最大长度为 :(2 4-1)*4 字节 =60 字节 保留字段 :6 位 保留为今后使用, 目前应置为 0

72 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 紧急 URG(URGent):1 位 当 URG=1 时, 表明紧急指针字段有效 它告诉系统此报文段中有紧急数据, 应尽快传送 ( 相当于高优先级的数据 ) 确认 ACK(ACKnowlegment):1 位 当 ACK=1 时, 表明确认号字段有效 当 ACK=0 时, 表明确认号字段无效 推送 PSH(PuSH) :1 位 接收端收到 TCP 报文段的 PSH=1 时, 此报文会尽快地交付接收应用进程, 而不再等到整个缓存都填满后再向上交付

73 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 复位 RST(ReSeT):1 位 当 RST=1 时, 表明 TCP 连接中出现严重差错 ( 如主机崩溃或其他原因 ), 必须释放连接, 然后再重新建立运输连接 同步 SYN(SYNchronization):1 位 当 SYN=1 且 ACK=0 时, 表示这是一个连接请求报文段, 如果对方同意建立连接, 则 SYN=1 且 ACK=1 因此当 SYN=1, 表示这是一个连接请求或连接接受报文 终止 FIN(FINis):1 位 用来释放一个连接 当 FIN=1 表明此报文段的发送端的数据已发送完毕, 并要求释放运输连接

74 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 窗口 :2 字节 窗口指的是发送本报文段的一方的接受窗口 窗口值告诉对方 : 从本报文段首部中的确认号算起, 接收方目前允许对方发送的数据量 由于接收方的数据缓存空间是有限的, 窗口值作为接收方让发送方设置其发送窗口的依据 其数据单位为字节 在 ACK=1 时才有效

75 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 检验和 :2 字节 检验和字段检验的范围包括首部和数据这两部分 和 UDP 用户数据报一样, 在计算校验和时, 要在 TCP 报文段的前面加上 12 字节的伪首部 伪首部的格式和 UDP 用户数据报的结构一样, 但要把协议号修改为 6 校验和的计算方法和 UDP 用户数据报的计算方法相同 紧急指针 :16 位 该字段在 UGR=1 时起效 指出在本报文段中的紧急数据共有多少个字节 ( 紧急数据放在本报文段数据的最前面 ) 因此紧急指针指出了紧急数据的末尾在报文段中的位置 当所有紧急数据都处理完毕后,TCP 就告诉应用程序恢复到正常操作

76 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 选项 :0-40 字节 TCP 最初只规定了一种选项, 即最大报文段长度 MSS MSS 告诉对方 TCP: 我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节 TCP 报文的最大长度 =MSS+TCP 首部长度随着因特网的发展, 逐步增加了新的选项 如窗口扩大选项 时间戳选项 选择确认选项等

77 32 位 位 源端口 目的端口 TCP 首部 数据偏移 保留 U R G 检验和 A C K P S H R S T 序号 确认号 S Y N F I N 窗口紧急指针 20 字节的固定首部 选项 ( 长度可变 ) 填充 填充 : 为什么要有填充选项? 填充的内容是什么?

78 78 5.TCP 报文段的首部格式 现场讨论 : 根据提供的报文进行分析, 并回答六个问题 : 问题一 : 来源和目的 MAC 地址是什么? 问题二 : 来源和目的 IP 地址是什么? 问题三 : 来源和目的端口是什么? 问题四 : 运输层协议是什么? 问题五 : 应用层协议是什么?

79 79 5.TCP 报文段的首部格式

80 80

81 81 5.TCP 报文段的首部格式

82 82

83 83 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 TCP 的滑动窗口是以字节为单位的 假定 A 收到了 B 发来的确认报文段, 其中窗口是 20( 字节 ), 而确认号是 31( 表示希望收到的下一个序号为 31, 序号 30 为止的数据已经收到 ) 根据窗口和确认号,A 就可以构造出自己的发送窗口 说明 : 为了讨论方便, 仅假定数据传输只在一个方向进行, 即 A 发送数据,B 给出确认

84 84 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 后沿 前沿 前移 A 的发送窗口 = 20 收缩 前移 已发送并收到确认 B 期望收到的序号 允许发送的序号 不允许发送

85 85 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 TCP 的滑动窗口是以字节为单位的 发送窗口里面的序号表示允许发送的序号 窗口越大, 发送发就可以在收到对方确认之前连续发送更多的数据, 从而获得更高的传输效率 发送窗口后沿的后面部分表示已发送且收到了确认 发送窗口前沿的前面部分表示不允许发送的 发送窗口的位置由窗口前沿和后沿的位置共同确定

86 86 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 发送窗口后沿的变化情况有两种可能 : 不动和前移 没有收到新的确认, 就不动 ; 收到了新的确认, 就前移 发送窗口后沿不可能向后移动, 因为不能够撤销已经收到的确认 发送窗口前沿的变化情况有三种可能 : 不动 前移和收缩 没有收到新的确认或者收到新的确认但窗口变小都可能造成前沿不动 在对方通知的窗口缩小时, 发送窗口前沿也可能向后收缩, 但是 TCP 标准强烈不造成这种做法

87 87 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 假定 A 发送了序号 的数据 这时, 发送窗口位置并未改变, 但是 的 11 个字节为已发送但未收到确认 的 9 个字节为允许发送但尚未发送 要描述一个发送窗口的状态需要三个指针 :P1 P2 P3 P3-P1 = A 的发送窗口 P2-P1 = 已发送但尚未收到确认的字节数 P3-P2 = 允许发送但尚未发送的字节数

88 88 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 A 的发送窗口位置不变 可用窗口 已发送并收到确认 已发送但未收到确认 允许发送但尚未发送 不允许发送 56 P 1 P 2 P 3 B 的接收窗口 已发送确认并交付主机 允许接收 不允许接收 未按序收到

89 89 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 假定 B 收到了序号为 31 的数据, 并把序号为 的数据交付主机, 然后 B 删除这些数据 接着把接收窗口向前移动 3 个序号, 同时给 A 发送确认, 窗口值仍为 20, 确认号为 34 同时 B 收到了 的数据, 但是没有按序到达 A 收到 B 的确认后, 就可以把发送窗口向前滑动 3 个序号, 但指针 P2 不动 A 的可用窗口增大, 可发送的序号范围是 42-53

90 90 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 A 的发送窗口向前滑动 已发送并收到确认 已发送允许发送但尚未发送但未收到确认 P 1 P 2 P 3 56 不允许发送 B 的接收窗口向前滑动 已发送确认并交付主机 允许接收 不允许接收 未按序收到 先存下, 等待缺少的数据的到达

91 91 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 A 在继续发送完序号 的数据后, 指针 P2 向前移动和 P3 重合 发送窗口内的序号都已用完, 但还没有再收到确认 由于 A 的发送窗口已满, 可用窗口已减小到零, 因此停止发送数据

92 92 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 A 的发送窗口已满, 有效窗口为零 已发送并收到确认 已发送但未收到确认 不允许发送 P 1 P 2 P 3

93 93 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 发送方的应用进程把字节流写入 TCP 的发送缓存, 接收方的应用进程从 TCP 的接收缓存中读取字节流 窗口和缓存的关系对于研究 TCP 可靠传输非常重要, 在讨论之前说明两点 : 缓存空间和序号空间都是有限的, 且都是循环使用的 实际上缓存或窗口中的字节数都是非常大的

94 94 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 发送应用程序 TCP 发送窗口 发送缓存 已发送 最后被确认的字节 最后发送的字节 序号增大

95 95 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 接收应用程序 TCP 下一个读取的字节 接收缓存 接收窗口 已收到 下一个期望收到的字节 ( 确认号 ) 序号增大

96 96 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 发送缓存用来暂存 : 发送应用程序传送给发送方 TCP 准备发送的数据 ; TCP 已发送出但尚未收到确认的数据 接收缓存用来暂存 : 按序到达的 但尚未被接收应用程序读取的数据 ; 未按序到达的数据

97 97 6.TCP 可靠传输的实现 6.1 以字节为单位的滑动窗口 关于 TCP 窗口强调三点 : 虽然 A 的发送窗口是根据 B 的接收窗口设置的, 但在同一时刻,A 的发送窗口并不总是和 B 的接收窗口一样大 对于不按序到达的数据如何处理,TCP 没有明确规定 TCP 通常对不按序到达的数据是先临时存放在接收窗口中, 等到字节流中所缺少的字节收到后, 再按序交付上层的应用进程 TCP 要求接收方必须有累积确认的功能, 这样可以减小传输开销 接收方可以在合适的时候发送确认, 也可以在自己有数据要发送时把确认信息捎带上

98 98 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段, 这种重传的概念是简单的, 但重传时间的选择却是 TCP 最复杂的问题之一 TCP 每发送一个报文段, 就对这个报文段设置一次计时器 只要计时器设置的重传时间到但还没有收到确认, 就要重传这一报文段

99 99 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 由于 TCP 的下层是一个互联网环境,IP 数据报所选择的路由变化很大 因而运输层的往返时间的方差也很大 往返时间的概率分布 数据链路层 运输层 时间 T 1 T 2 T 3

100 100 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 运输层的超时计时器的超时重传时间究竟应设置为多大呢? TCP 采用了一种自适应算法, 它记录一个报文段发出的时间, 以及收到相应的确认的时间 这两个时间之差就是报文段的往返时间 RTT TCP 保留了 RTT 的一个加权平均往返时间 RTT S ( 这又称为平滑的往返时间,S 表示 Smoothed)

101 101 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 第一次测量到 RTT 样本时,RTT S 值就取为所测量到的 RTT 样本值 以后每测量到一个新的 RTT 样本, 就按下式重新计算一次 RTT S : 新的 RTT S (1 ) ( 旧的 RTT S ) ( 新的 RTT 样本 ) 式中,0 1 若 很接近于零, 表示 RTT 值更新较慢 若选择 接近于 1, 则表示 RTT 值更新较快 RFC2988 推荐的 值为 1/8, 即 0.125

102 102 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 超时计时器设置的超时重传时间 RTO(Retransmission Time-Out) 应略大于上面的 RTT S RFC 2988 建议使用下式计算 RTO: RTO RTT S + 4 RTT D

103 103 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 RTT D 是 RTT 的偏差的加权平均值 RFC 2988 建议这样计算 RTT D : 第一次测量时,RTT D 值取为测量到的 RTT 样本值的一半 在以后的测量中, 则使用下式计算加权平均的 RTT D : 新的 RTT D = (1 ) ( 旧的 RTT D ) + RTT S 新的 RTT 样本 是个小于 1 的系数, 其推荐值是 1/4, 即 0.25

104 104 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 TCP 报文段 1 没有收到确认 重传 ( 即报文段 2) 后, 收到了确认报文段 ACK 如何判定此确认报文段是对原来的报文段 1 的确认, 还是对重传的报文段 2 的确认? 发送一个 TCP 报文段 超时重传 TCP 报文段 是对哪一个报文段的确认? 收到 ACK 1 2 时间 往返时间 RTT? 往返时间 RTT?

105 105 6.TCP 可靠传输的实现 6.2 超时重传时间的选择 Karn 算法 : 在计算平均往返时间 RTT 时, 只要报文段重传了, 就不采用其往返时间样本 这样得出的加权平均平均往返时间 RTT S 和超时重传时间 RTO 就较准确 报文段每重传一次, 就把 RTO 增大一些 : 系数 的典型值是 2 新的 RTO ( 旧的 RTO) 当不再发生报文段的重传时, 才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值 实践证明, 这种策略较为合理

106 106 6.TCP 可靠传输的实现 6.3 选择确认 SACK 如果收到的报文段无差错, 只是未按序号, 中间缺少一些序号的数据, 那么是否设法只传送缺少的数据而不重传已经正确到达接收方的数据? TCP 采用了选择确认的方式来处理 接收方收到了和前面的字节流不连续的两个字节块 如果这些字节的序号都在接收窗口之内, 那么接收方就先收下这些数据, 但要把这些信息准确地告诉发送方, 使发送方不要再重复发送这些已收到的数据

107 107 6.TCP 可靠传输的实现 6.3 选择确认 SACK 连续的字节流 第一个字节块 第二个字节块 确认号 = 1001 L 1 = 1501 R 1 = 3001 L 2 = 3501 R 1 = 4501 和前后字节不连续的每一个字节块都有两个边界 : 左边界和右边界 第一个字节块的左边界 L1=1501, 但右边界 R1=3001 左边界指出字节块的第一个字节的序号, 但右边界减 1 才是字节块中的最后一个序号 第二个字节块的左边界 L2=3501, 而右边界 R2=4501

108 108 6.TCP 可靠传输的实现 6.3 选择确认 SACK RFC 2018 的规定 : 如果要使用选择确认, 那么在建立 TCP 连接时, 就要在 TCP 首部的选项中加上 允许 SACK 的选项, 而双方必须都事先商定好 如果使用选择确认, 那么原来首部中的 确认号字段 的用法仍然不变 只是以后在 TCP 报文段的首部中都增加了 SACK 选项, 以便报告收到的不连续的字节块的边界 由于首部选项的长度最多只有 40 字节, 而指明一个边界就要用掉 4 字节, 因此在选项中最多只能指明 4 个字节块的边界信息

109 109 7.TCP 流量控制 7.1 利用滑动窗口实现流量控制 一般说来, 总是希望数据传输得更快一些 但如果发送方把数据发送得过快, 接收方就可能来不及接收, 这就会造成数据的丢失 流量控制 (flow control) 就是让发送方的发送速率不要太快, 既要让接收方来得及接收, 也不要使网络发生拥塞 利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制

110 110 7.TCP 流量控制 7.1 利用滑动窗口实现流量控制 TCP 在发送数据时, 发送方的发送窗口不能超过接收方给出的接收窗口的数值 注意 :TCP 窗口的单位是字节, 不是报文段 TCP 就利用这一原理实现流量控制 当接收方接收数据的速度变慢时, 就在确认报文中告诉发送方接收窗口的大小, 发送方根据接收窗口的大小确定发送窗口大小 从而达到控制流量的目的

111 111 7.TCP 流量控制 7.1 利用滑动窗口实现流量控制 A 向 B 发送数据 在连接建立时,B 告诉 A: 我的接收窗口 rwnd = 400( 字节 ) A B seq = 1, DATA A 发送了序号 1 至 100, 还能发送 300 字节 seq = 101, DATA A 发送了序号 101 至 200, 还能发送 200 字节 seq = 201, DATA 丢失! ACK = 1, ack = 201, rwnd = 300 允许 A 发送序号 201 至 500 共 300 字节 seq = 301, DATA A 发送了序号 301 至 400, 还能再发送 100 字节新数据 seq = 401, DATA A 发送了序号 401 至 500, 不能再发送新数据了 seq = 201, DATA A 超时重传旧的数据, 但不能发送新的数据 ACK = 1, ack = 501, rwnd = 100 允许 A 发送序号 501 至 600 共 100 字节 seq = 501, DATA A 发送了序号 501 至 600, 不能再发送了 ACK = 1, ack = 601, rwnd = 0 不允许 A 再发送 ( 到序号 600 为止的数据都收到了 )

112 112 7.TCP 流量控制 7.1 利用滑动窗口实现流量控制 持续计时器 (persistence timer) TCP 为每一个连接设有一个持续计时器 只要 TCP 连接的一方收到对方的零窗口通知, 就启动持续计时器 若持续计时器设置的时间到期, 就发送一个零窗口探测报文段 ( 仅携带 1 字节的数据 ), 而对方就在确认这个探测报文段时给出了现在的窗口值 若窗口仍然是零, 则收到这个报文段的一方就重新设置持续计时器 若窗口不是零, 则死锁的僵局就可以打破了

113 113 7.TCP 流量控制 7.2 必须考虑传输效率 应用进程把数据传送到 TCP 的发送缓存后, 剩下的发送任务就由 TCP 具体控制 如何控制 TCP 发送报文段的时机是非常复杂的,TCP 有不同的机制来控制 TCP 报文段的发送时机 第一种机制 :TCP 维持一个变量, 它等于最大报文段长度 MSS 只要缓存中存放的数据达到 MSS 字节时, 就组装成一个 TCP 报文段发送出去 第二种机制 : 由发送方的应用进程指明要求发送报文段, 即 TCP 支持推送 (push) 操作 第三种机制 : 发送方的一个计时器期限到了, 这时就把当前已有的缓存数据装入报文段 ( 但长度不能超过 MSS) 发送出去

114 114 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 在某段时间, 若对网络中某资源的需求超过了该资源所能提供的可用部分, 网络的性能就要变坏 这种情况就叫做拥塞 (congestion) 出现网络拥塞的条件是 : 对资源需求的总和 > 可用资源 若网络中有许多资源同时产生拥塞, 网络的性能就要明显变坏, 整个网络的吞吐量将随输入负荷的增大而下降

115 115 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 网络拥塞往往是由许多因素引起的, 是一个非常复杂的问题, 需要综合考虑和分析 有人说 : 只要任意增加一些资源, 例如把节点缓存的存储空间扩大, 或把链路更换为更高速率的链路, 或把结点处理机的运算速度提高, 就可以解决网络拥塞的问题 其实, 简单的采用上述的做法, 在许多情况下, 不但不能解决拥塞问题, 而且还可能使网络的性能变得更差

116 116 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 拥塞控制与流量控制的关系非常密切, 但是也存在一定的差别 拥塞控制所要做的都有一个前提, 就是网络能够承受现有网络负荷 拥塞控制是一个全局性的过程, 涉及到所有的主机 所有的路由器, 以及与降低网络传输性能有关的所有因素 流量控制往往指在给定发送端和接收端之间的点对点通信量的控制 流量控制所要做的就是抑制发送端发送数据的速率, 以便使接收端来得及接收

117 117 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 吞吐量 理想的拥塞控制 实际的拥塞控制 死锁 ( 吞吐量 = 0) 0 轻度拥塞 拥塞 无拥塞控制 提供的负载

118 118 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 拥塞控制是很难设计的, 因为它是一个动态的 ( 而不是静态的 ) 问题 当前网络正朝着高速化的方向发展, 这很容易出现缓存不够大而造成分组的丢失 但分组的丢失是网络发生拥塞的征兆而不是原因 在许多情况下, 甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因 这点应特别引起重视

119 119 8.TCP 拥塞控制 8.1 拥塞控制的一般原理 从大的方面来看, 拥塞控制可分为开环控制和闭环控制两种方法 开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到, 力求网络在工作时不产生拥塞 闭环控制是基于反馈环路的概念 属于闭环控制有以下几种措施 : 监测网络系统以便检测到拥塞在何时 何处发生 将拥塞发生的信息传送到可采取行动的地方 调整网络系统的运行以解决出现的问题

120 120 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 1999 年公布的因特网建议标准 RFC 2581 定义了进行拥塞控制的四种算法 : 慢开始 (slow-start) 拥塞避免 (congestion avoidance) 快重传 (fast retransmit) 快恢复 (fast recovery) 之后 RFC 2582 和 RFC 3390 又对这些算法进行了一些改进 在讨论拥塞控制时, 为了讨论方便做如下假定 : 数据是单方向发送, 而另一个方向只传送确认 ; 接收方总是有足够大的缓存空间, 因而发送窗口的大小由网络的拥塞程度来决定

121 121 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 发送方维持一个叫做拥塞窗口 cwnd (congestion window) 的状态变量 拥塞窗口的大小取决于网络的拥塞程度, 并且动态地在变化 发送方让自己的发送窗口等于拥塞窗口 如再考虑到接收方的接收能力, 则发送窗口还可能小于拥塞窗口 发送方控制拥塞窗口的原则是 : 只要网络没有出现拥塞, 拥塞窗口就再增大一些, 以便把更多的分组发送出去 但只要网络出现拥塞, 拥塞窗口就减小一些, 以减少注入到网络中的分组数

122 122 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 在主机刚刚开始发送报文段时可先设置拥塞窗口 cwnd=1, 即设置为一个最大报文段 MSS 的数值 在每收到一个对新的报文段的确认后, 将拥塞窗口加 1, 即增加一个 MSS 的数值 用这样的方法逐步增大发送端的拥塞窗口 cwnd, 可以使分组注入到网络的速率更加合理

123 123 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 cwnd = 1 发送方发送 M 1 接收方 确认 M 1 轮次 1 cwnd = 2 发送 M 2 ~M 3 确认 M 2 ~M 3 轮次 2 cwnd = 4 发送 M 4 ~M 7 确认 M 4 ~M 7 轮次 3 cwnd = 8 发送 M 8 ~M 15 t t

124 124 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 使用慢开始算法后, 每经过一个传输轮次, 拥塞窗口 cwnd 就加倍 一个传输轮次所经历的时间其实就是往返时间 RTT 传输轮次 更加强调 : 把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去, 并收到了对已发送的最后一个字节的确认 例如, 拥塞窗口 cwnd=4, 这时的往返时间 RTT 就是发送方连续发送 4 个报文段, 并收到这 4 个报文段的确认, 总共经历的时间

125 125 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 为了防止拥塞窗口 cwnd 增长过大引起网络拥塞, 设置慢开始门限状态变量 ssthresh 当 cwnd<ssthresh 时, 使用慢开始算法 当 cwnd>ssthresh 时, 停止使用慢开始算法而改用拥塞避免算法 当 cwnd=ssthresh 时, 既可使用慢开始算法, 也可使用拥塞避免算法 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大, 即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1, 而不是加倍, 使拥塞窗口 cwnd 按线性规律缓慢增长

126 126 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 无论在慢开始阶段还是在拥塞避免阶段, 只要发送方判断网络出现拥塞 ( 其根据就是没有按时收到确认 ), 就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半 ( 但不能小于 2) 然后把拥塞窗口 cwnd 重新设置为 1, 重新执行慢开始算法 这样做的目的就是要迅速减少主机发送到网络中的分组数, 使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕

127 127 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 慢开始算法 ssthresh 的初始值 新的 ssthresh 值 慢开始 拥塞窗口 cwnd 指数规律增长 网络拥塞 乘法减小 慢开始 拥塞避免 加法增大 慢开始 拥塞避免 加法增大 22 传输轮次

128 128 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 乘法减小 (multiplicative decrease) 乘法减小 是指不论在慢开始阶段还是拥塞避免阶段, 只要出现一次超时 ( 即出现一次网络拥塞 ), 就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5 当网络频繁出现拥塞时,ssthresh 值就下降得很快, 以大大减少注入到网络中的分组数 然后把拥塞窗口 cwnd 重新设置为 1, 重新执行慢开始算法 这样做的目的就是要迅速减少主机发送到网络中的分组数, 使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕

129 129 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 加法增大 (additive increase) 加法增大 是指执行拥塞避免算法后, 在收到对所有报文段的确认后 ( 即经过一个往返时间 ), 就把拥塞窗口 cwnd 增加一个 MSS 大小, 使拥塞窗口缓慢增大, 以防止网络过早出现拥塞

130 130 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 慢开始和拥塞避免 : 拥塞避免 并非指完全能够避免了拥塞 利用以上的措施要完全避免网络拥塞还是不可能的 拥塞避免 是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长, 使网络比较不容易出现拥塞

131 131 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 快重传和快恢复 : 快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认 这样做可以让发送方及早知道有报文段没有到达接收方 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段 不难看出, 快重传并非取消重传计时器, 而是在某些情况下可更早地重传丢失的报文段

132 132 8.TCP 拥塞控制 快重传和快恢复 : 发送 M 1 发送方 8.2 拥塞控制的几种方法 接收方 发送 M 2 确认 M 1 收到三个连续的对 M 2 的重复确认 立即重传 M 3 发送 M 3? 丢失发送 M 4 发送 M 5 发送 M 6 发送 M 7 确认 M 2 重复确认 M 2 重复确认 M 2 重复确认 M 2 t t

133 133 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 快重传和快恢复 : 与快重传配合使用的还有快恢复算法, 其过程有两个要点 : 当发送端收到连续三个重复的确认时, 就执行 乘法减小 算法, 把慢开始门限 ssthresh 减半, 但接下去不执行慢开始算法 由于发送方现在认为网络很可能没有发生拥塞, 因此现在不执行慢开始算法, 即拥塞窗口 cwnd 现在不设置为 1, 而是设置为慢开始门限 ssthresh 减半后的数值, 然后开始执行拥塞避免算法 ( 加法增大 ), 使拥塞窗口缓慢地线性增大

134 134 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 快重传和快恢复 : ssthresh 的初始值 拥塞窗口 cwnd 拥塞避免 加法增大 乘法减小 收到 3 个重复的确认执行快重传算法 拥塞避免 加法增大 TCP Reno 版本 新的 ssthresh 值 12 8 快恢复 TCP Tahoe 版本 ( 已废弃不用 ) 慢开始 慢开始 传输轮次

135 135 8.TCP 拥塞控制 8.2 拥塞控制的几种方法 快重传和快恢复 : 发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个, 即应按以下公式确定 : 发送窗口的上限值 =Min [rwnd, cwnd] 当 rwnd<cwnd 时, 是接收方的接收能力限制发送窗口的最大值 当 cwnd<rwnd 时, 则是网络的拥塞限制发送窗口的最大值

136 136 8.TCP 拥塞控制 8.3 随机早期检测 RED

137 137 9.TCP 的运输连接管理 TCP 是面向连接的协议 运输连接是用来传送 TCP 报文的 TCP 运输连接的建立和释放是每一次面向连接的通信中必不可少的过程 运输连接有三个阶段, 即 : 连接建立 数据传送和连接释放 运输连接的管理就是使运输连接的建立和释放都能正常地进行

138 138 9.TCP 的运输连接管理 TCP 是面向连接的协议, 在连接建立过程中要解决以下三个问题 : 要使每一方能够确知对方的存在 要允许双方协商一些参数 ( 如最大报文段长度, 最大窗口大小, 服务质量等 ) 能够对运输实体资源 ( 如缓存大小, 连接表中的项目等 ) 进行分配 TCP 连接的建立都是采用客户服务器方式 主动发起连接建立的应用进程叫做客户 (client), 被动等待连接建立的应用进程叫做服务器 (server)

139 139 9.TCP 的运输连接管理 9.1 TCP 连接建立 客户 服务器 A B 主动打开 CLOSED CLOSED 被动打开 SYN- SENT LISTEN SYN- RCVD ESTAB- LISHED 数据传送 ESTAB- LISHED

140 140 9.TCP 的运输连接管理 客户 A B 服务器 9.2 TCP 连接施放 主动关闭 ESTAB- LISHED 数据传送 ESTAB- LISHED 通知应用进程 FIN- WAIT-1 CLOSE- WAIT 被动关闭 等待 2MSL FIN- WAIT-2 TIME- WAIT LAST- ACK CLOSED CLOSED

141 141 9.TCP 的运输连接管理 9.3 TCP 有限状态机 ( 七次握手 )

142 142

143 143 Thanks