《计算机网络（第七版）-谢希仁》重点知识 - 运输层

运输层

根据B站视频《计算机网络（谢希仁第七版）-方老师》上课整理

重要概念：

1. 运输层为互相通信的应用进程提供通信

2. 它属于面向通信部分的最高层，同时也是用户功能中的最低层

   

3. 只有唯一网络边缘部分的主机的协议栈采有运输层（即：在核心部分负责转发的路由器只用下三层）

   

4. 从IP层来说，通信的两端是两台主机，而运输层来说正真终点是主机中的进程（具体到某个端口）

   

5. 一台主机经常有多个应用进程同时分别和另外一台主机中的多个应用进程通信，这表明运输层有两个很重要的功能——复用（multiplexing）和分用（demultiplexing）为此运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP

   

屏蔽作用

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。

两种不同的运输协议

主要特点：

• 传输控制协议TCP（Transmission Control Protocol）
  • 提供面向连接的服务
  • TCP的逻辑信道为全双工（允许数据在两个方向传输）的可靠信道。
  • 传送的数据单位协议是 TCP 报文段 (segment)
  • TCP 不提供广播或多播服务
  • 由于 TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源

• 用户数据报协议UDP（User Datagram Protocol）
  • 提供无连接服务
  • 逻辑信道是一条不可靠的信道
  • 传送的数据单位协议是 UDP 报文或用户数据报
  • 在传送数据之前不需要先建立连接
  • 对方的运输层在收到 UDP 报文后，不需要给出任何确认
  • 虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式

注意：

• 运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。
  • IP 数据报要经过互连网中许多路由器的存储转发
  • UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。
• TCP 报文段是在运输层抽象的端到端逻辑信道中传送，这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。

运输层的端口

​ 运行在计算机中的进程是用进程标识符来标志的，但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符，这是因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。

因此创建了协议端口号（protocol port number）通常简称为端口（port）

软件端口和硬件端口

• 两个不同的概念
• 在协议栈层间的抽象的协议端口是软件端口
• 路由器或交换机上的端口是硬件端口
• 硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。

TCP/IP运输层端口

• 端口用一个 16 位端口号进行标志
• 端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程
• 在互联网中，不同计算机的相同端口号是没有联系的

由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的 IP 地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。

两大类端口

1. 服务器端使用的端口号

   • 熟知端口，数值一般为 0 ~ 1023。
   
   • 登记端口号，数值为 1024 ~ 49151，为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记，以防止重复。

2. 客户端使用的端口号

   • 又称为短暂端口号，数值为 49152 ~ 65535，留给客户进程选择暂时使用。
   • 当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。

用户数据报协议UDP

UDP 只在 IP 的数据报服务之上增加了很少一点的功能：

• 复用和分用的功能
• 差错检测的功能

虽然 UDP 用户数据报只能提供不可靠的交付，但 UDP 在某些方面有其特殊的优点。

主要特点

1. 无连接的，发送数据之前不需要建立连接，，因此减少了开销和发送数据之前的时延
2. 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表
3. 面向报文的。 UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文
4. 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求
5. 支持一对一、一对多、多对一和多对多的交互通信
6. 首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短

面向报文的UDP

发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。

因此应用程序应该选择合适大小的报文

• 报文太长，UDP交给IP层之后，IP层需要进行分片，会降低IP层的效率
• 报文太短，UDP交给IP层后，会使IP数据报的部首相对长度太大，间接的降低IP层传输的效率

UDP的部首格式

用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节。

计算UDP检验和的例子

UDP基于端口的分用

当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交最后的终点——应用进程。

请注意，虽然在 UDP 之间的通信要用到其端口号，但由于 UDP 的通信是无连接的，因此不需要使用套接字。

传输控制协议TCP概述

主要特点

• TCP 是面向连接的运输层协议
• 每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是点对点的（一对一）
• TCP 提供可靠交付的服务
• TCP 提供 全双工 通信
• 面向字节流
  • TCP 中的 “流”(stream) 指的是流入或流出进程的字节序列
  • “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。

TCP面向流的概念

• TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系
• 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样

注意

• TCP 连接是一条虚连接而不是一条真正的物理连接
• TCP 对应用进程一次把多长的报文发送到 TCP 的缓存中是不关心的
• TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）
• TCP 可把太长的数据块划分短一些再传送
• TCP 也可等待积累有足够多的字节后再构成报文段发送出去。

TCP连接

• TCP 把连接作为最基本的抽象
• 每一条 TCP 连接有两个端点
• TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。TCP 连接的端点叫做套接字 (socket) 或插口
• 端口号拼接到 (concatenated with) IP 地址即构成了套接字。

套接字

每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：

可靠传输的工作原理

理想的传输条件有以下两个特点：

• 传输信道不产生差错
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。
然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

停止等待协议

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

全双工通信的双方既是发送方也是接收方。

为了讨论问题的方便，我们仅考虑 A 发送数据而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。有以下三种情况：

1. 无差错情况
   • A发送分组M1，发完就暂停发送，等待B的确认，B收到就向A发送确认信息，A收到M1的确认后就发送下一个分组M2
2. 出现差错
   • 在接收方 B 会出现两种情况：
     • B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）
     • M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做
   • 在这两种情况下，B 都不会发送任何信息
   • 如何保证 B 正确收到了 M1 呢？
   • 解决方法：超时重传
     • A 为每一个已发送的分组都设置了一个超时计时器
     • A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2
3. 确认丢失和确认迟到
   • 确认丢失
     • 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1
     • 假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动：
       • 第一，丢弃这个重复的分组 M1，不向上层交付
       • 第二，向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认
   • 确认迟到
     • 传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了
     • A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃
     • B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组

注意：

• 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发
• 分组和确认分组都必须进行编号
• 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

自动重传请求APQ协议

通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认(倒计时结束就重传)，就说明通信线路太差，不能进行通信。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
像上述的这种可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat request)。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。

信道利用率

停止等待协议的优点是简单，缺点是信道利用率太低

T_D为A发送分组所需要的时间，RTT是往返时间，T_A是发送确认分组所需要的时间。信道大部分的时间都花在等待确认的上。

所以我们要利用等待时间，发送下一个分组，即是流水线传输：

连续ARQ协议

• 滑动窗口协议比较复杂，是 TCP 协议的精髓所在
• 发送方维持的发送窗口，它的意义是：位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了
• 连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置

累计确认

接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。
优点： 容易实现，即使确认丢失也不必重传。
缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。

Go-back-N（回退N）

如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。
这就叫做 Go-back-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。
可见当通信线路质量不好时，连续 ARQ 协议会带来负面的影响。

TCP可靠通信的具体实现

• TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口
• TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段
• TCP 两端的四个窗口经常处于动态变化之中
• TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

TCP报文段的首部格式

• TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段
• 一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用
• TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现

序号字段（seq）——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号

• 作用:
  • 接收⽅可以去除复的数据；
  • 接收⽅可以根据数据包的序列号按序接收；
  • 可以标识发送出去的数据包中， 哪些是已经被对⽅收到的；

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

数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）

保留字段——占 6 位，保留为今后使用，但目前应置为 0

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

确认 ACK(Acknowledgment) —— 只有当 ACK= 1 时确认号字段才有效。当 ACK= 0 时，确认号无效（大写的ACK表示首部中的确认位，小写ack表示确认字段的值）

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

复位 RST (Reset) —— 当 RST= 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接

同步 SYN(Synchronization) —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文

终止 FIN (Finish) —— 用来释放一个连接。FIN= 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接

窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节

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

紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）

选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”

• TCP 最初只规定了一种选项，即最大报文段长度 MSS(Maximum Segment Size)。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
• 为什么要规定MSS？
  • MSS于接收窗口值没有关系
  • 选择较小的MSS长度，网络利用率低，因为在IP层传输数据报的开销至少是40字节（20字节的IP数据报首部、20字节的TCP首部）
  • 选择较大的长度，会在IP层传输时分配成多个短数据，然后装配成原来的TCP报文段，开销大
  • 最佳的MSS是很难确认的

TCP可靠传输的实现

以字节为单位的滑动窗口

TCP 的滑动窗口是以字节为单位的。

现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，而确认号是 31（这表明 B 期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了）。

根据这两个数据，A 就构造出自己的发送窗口，发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。 发送窗口里面的序号表示

允许发送的序号。 显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。（窗口可以扩大，当窗口需要减少，只会“只出不进”减少窗口大小）

A发送了11个字节的数据之后，B在为32、33两个序号未按序收到，会回退N，A会重新发送，直到B确认为止

但是A的发送窗口内的序号都已经用完，但还没收到确认 ，必须停止发送。

发送缓存和接收缓存

发送缓存

接收缓存

作用：

发送缓存用来暂时存放：

• 发送应用程序传送给发送方 TCP 准备发送的数据；
• TCP 已发送出但尚未收到确认的数据。

接收缓存用来暂时存放：

• 按序到达的、但尚未被接收应用程序读取的数据；
• 不按序到达的数据。

滑动窗口需要注意

1. A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）
2. TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
3. TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。

接收方发送确认

接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

但请注意两点：

1. 接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源
2. 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据

超时重传时间的选择

• 重传机制是 TCP 中最重要和最复杂的问题之一
• TCP 每发送一个报文段，就对这个报文段设置一次计时器
• 只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段
• 重传时间的选择是 TCP 最复杂的问题之一

往返时延的方差很大

由于 TCP 的下层是一个互联网环境，IP 数据报所选择的路由变化很大。因而运输层的往返时间 (RTT) 的方差也很大。

TCP超时重传时间设置

• 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大
• 但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率
• TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT

加权平均往返时间

• TCP 保留了 RTT 的一个加权平均往返时间 RTT_S（这又称为平滑的往返时间）。
• 第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTT_S：

• 式中，0 <α< 1。若α很接近于零，表示 RTT 值更新较慢。若选择 α 接近于 1，则表示 RTT 值更新较快。
• RFC 2988 推荐的α 值为 1/8，即 0.125。

超时重传时间RTO

RTO (Retransmission Time-Out) 应略大于上面得出的加权平均往返时间 RTT_S。
RFC 2988 建议使用下式计算 RTO：

RTT_D 是 RTT 的偏差的加权平均值。
RFC 2988 建议这样计算 RTT_D。第一次测量时，RTT_D 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTT_D：

β是个小于 1 的系数，其推荐值是 1/4，即 0.25。

往返时间（RTT）测量非常复杂

• TCP 报文段 1 没有收到确认。重传（即报文段 2）后，收到了确认报文段 ACK
• 如何判定此确认报文段是对原来的报文段 1 的确认，还是对重传的报文段 2 的确认？

Karn算法

• 在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本
• 这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确
• 但是，这又引起新的问题。当报文段的时延突然增大了很多时，在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据 Karn 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

修正之后：

• 报文段每重传一次，就把 RTO 增大一些：

• 系数 γ 的典型值是 2
• 当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值
• 实践证明，这种策略较为合理。

TCP的流量控制

利用滑动窗口实现流量控制

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

举个例子

rwnd 表示的是receiver window 并且 发送方的发送窗口不能超过接收方的接收窗口的数值

ACK=1 ack的值才有意义

肯能会出现死锁的情况

情况：

B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。

但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。

如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

为了解决这个问题，TCP 为每一个连接设有一个持续计时器 (persistence timer)：

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

TCP的传输效率

可以用不同的机制来控制 TCP 报文段的发送时机:

• 第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去
• 第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push) 操作
• 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。

如何控制 TCP 发送报文段的时机仍然是一个较为复杂的问题。

发送方糊涂窗口综合症

发送方每收到一字节就发送，但是一字节需要41字节的IP数据报，对方确认回送一字节，就需要传送162字节共4个报文段，效率极低。解决方法是使用

Nagle算法

• 若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来
• 当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存
• 只有在收到对前一个报文段的确认后才继续发送下一个报文段
• 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段

接收方糊涂窗口综合症

• 当接收方的 TCP 缓冲区已满，接收方会向发送方发送窗口大小为 0 的报文

• 若此时接收方的应用进程以交互方式每次只读取一个字节，于是接收方又发送窗口大小为一个字节的更新报文，发送方应邀发送一个字节的数据（发送的 IP 数据报是 41 字节长），于是接收窗口又满了，如此循环往复

• 解决方法： 让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。

TCP的拥塞控制

拥塞控制的一般原理

• 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞 (congestion)
• 若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降
• 出现拥塞的原因:

增加资源无法解决拥塞

网络拥塞是一个非常复杂的问题，简单的采用上述做法，在许多情况下，不能解决拥塞问题，而且还会使网络的性能更坏

网络拥塞往往是有许多因素引起的。例如：

• 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
• 提高处理机处理的速率会会将瓶颈转移到其他地方；

拥塞会逐渐恶化

• 如果一个路由器没有足够的缓存空间，它就会丢弃一些新到的分组
• 但当分组被丢弃时，发送这一分组的源点就会重传这一分组，甚至可能还要重传多次。这样会引起更多的分组流入网络和被网络中的路由器丢弃
• 可见拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞

拥塞控制和流量控制的区别

拥塞控制

• 就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载
• 所要做的都有一个前提，就是网络能够承受现有的网络负荷
• 是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素

流量控制

• 往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）
• 所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制和流量控制之所以常常被弄混，是因为某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点又和流量控制是很相似的。要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制

拥塞控制是很难设计的，因为它是一个动态的问题，而非静态，并且在当前网络的高速发展，很容易出现缓存不够大而造成分组的丢失，分组的丢失接收网络发生拥塞的征兆而不是原因，而在许多情况下，正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。

拥塞控制所起的作用

开环控制和闭环控制

• 开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。
• 闭环控制方法是基于反馈环路的概念。属于闭环控制的有以下几种措施：
  • 监测网络系统以便检测到拥塞在何时、何处发生
  • 将拥塞发生的信息传送到可采取行动的地方
  • 调整网络系统的运行以解决出现的问题

检测网络的拥塞的指标

主要指标有：

• 由于缺少缓存空间而被丢弃的分组的百分数；
• 平均队列长度；
• 超时重传的分组数；
• 平均分组时延；
• 分组时延的标准差，等等。

上述这些指标的上升都标志着拥塞的增长。

TCP的拥塞控制方法

采用基于窗口的方法进行拥塞控制，属于闭环控制方法。

TCP双方发送维持一个拥塞窗口cwnd（Congestion Window）：

• 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化
• 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量
• 所以，发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：

控制拥塞窗口的原则

只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率

但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞

拥塞的判断

重传定时器超时

• 现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于 1 %）。只要出现了超时，就可以猜想网络可能出现了拥塞

收到三个相同（重复）的 ACK

• 个别报文段会在网络中丢失，预示可能会出现拥塞（实际未发生拥塞），因此可以尽快采取控制措施，避免拥塞

TCP拥塞控制算法

四种拥塞控制方法（RFC 5681）

• 慢开始 (slow-start)
• 拥塞避免 (congestion avoidance)
• 快重传 (fast retransmit)
• 快恢复 (fast recovery)

慢开始（Slow start）

• 用来确定网络的负载能力

• 算法的思路：由小到大逐渐增大拥塞窗口数值

• 初始拥塞窗口 cwnd 设置：

  • 旧的规定：在刚刚开始发送报文段时，先把初始拥塞窗口cwnd 设置为 1 至 2 个发送方的最大报文段 SMSS (Sender Maximum Segment Size) 的数值。
    新的 RFC 5681 把初始拥塞窗口 cwnd 设置为不超过2至4个SMSS 的数值

• 慢开始门限 ssthresh（状态变量）：防止拥塞窗口cwnd 增长过大引起网络拥塞。

• 拥塞窗口 cwnd 控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值

• 其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数
• 不难看出，当 N < SMSS 时，拥塞窗口每次的增加量要小于 SMSS
• 用这样的方法逐步增大发送方的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。

传输轮次

• 使用慢开始算法后，每经过一个传输轮次 (transmission round)，拥塞窗口 cwnd 就加倍
• 一个传输轮次所经历的时间其实就是往返时间 RTT
• “传输轮次”更加强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认
• 例如，拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间。

满开始门限状态变量ssthresh

慢开始门限 ssthresh 的用法如下：

• 当 cwnd < ssthresh 时，使用慢开始算法
• 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法
• 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法

拥塞避免算法

思路：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。 因此在拥塞避免阶段就有“加法增大” (Additive Increase) 的特点。这表明在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

当网络出现拥塞时

• 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：
  • ssthresh = max (cwnd/2，2)
  • cwnd = 1
  • 执行慢开始算法
• 这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

慢开始和拥塞避免算法的实现举例

1. 当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。

2. 在执行慢开始算法时，拥塞窗口 cwnd=1，发送第一个报文段。

3. 发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1，然后开始下一轮的传输（请注意，横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。

4. 当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（图中的点1，此时拥塞窗口 cwnd = 16），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。

   强调一下：

   • “拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的
   • “拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞

5. 当拥塞窗口 cwnd = 24 时，网络出现了超时（图中的点2），发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd / 2 = 12，同时设置拥塞窗口cwnd=1，进入慢开始阶段。

6. 按照慢开始算法，发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1。当拥塞窗口 cwnd = ssthresh = 12 时（图中的点3，这是新的 ssthresh 值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。当拥塞窗口 cwnd = 16 时（图中的点4），出现了一个新的情况，就是发送方一连收到 3 个对同一个报文段的重复确认（图中记为 3-ACK）。发送方改为执行快重传和快恢复算法。

   快重传算法：

   • 采用快重传 FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失

   • 快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认

   • 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

   • 使用快重传可以使整个网络的吞吐量提高约20%。

   • 不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

     

   快恢复算法：

   • 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：
     • 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
     • 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
     • 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

7. 因此，在图的点5，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值 ssthresh = cwnd / 2 = 8，同时设置拥塞窗口 cwnd = ssthresh = 8（见图中的点5），并开始执行拥塞避免算法。

加法增大，乘法减少（ALMD）

• 可以看出，在拥塞避免阶段，拥塞窗口是按照线性规律增大的。这常称为“加法增大” AI (Additive Increase)
• 当出现超时或3个重复的确认时，就要把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值。这常称为“乘法减小”MD (Multiplicative Decrease)
• 二者合在一起就是所谓的 AIMD 算法

TCP拥塞控制流程图

发送窗口的上限值

发送方的发送窗口的上限值因该取接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个

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

当cwnd<rwnd时，网络的拥塞限制了发送窗口的最大值

也就是说rwnd和cwnd中数值较小的一个限制了发送窗口的最大值。

主动队列管理AQM

TCP 拥塞控制和网络层采取的策略有密切联系。

重传会使 TCP 连接的发送端认为在网络中发生了拥塞。于是在 TCP 的发送端就采取了拥塞控制措施，但实际上网络并没有发生拥塞。网络层的策略对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

“先进先出”FIFO 处理规则

路由器的队列通常都是按照“先进先出”FIFO (First In First Out) 的规则处理到来的分组。

当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。这就叫做尾部丢弃策略 (tail-drop policy)。

路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。

全局同步

更为严重的是，在网络中通常有很多的 TCP 连接，这些连接中的报文段通常是复用在网络层的 IP 数据报中传送的。
在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条 TCP 连接，结果使这许多 TCP 连接在同一时间突然都进入到慢开始状态。这在 TCP 的术语中称为全局同步 (global synchronization)。

全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。

因此，1998 年提出了主动队列管理 AQM (Active Queue Management)。

所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。

AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测 RED (Random Early Detection)。

随机早期检测RED

使路由器的队列维持两个参数：队列长度最小门限 TH_min 和最大门限 Th_max 。
RED 对每一个到达的分组都先计算平均队列长度 LAV 。

• (1) 若平均队列长度小于最小门限 TH_min ，则将新到达的分组放入队列进行排队
• (2) 若平均队列长度超过最大门限Th_max，则将新到达的分组丢弃
• (3) 若平均队列长度在最小门限 TH_min 和最大门限Th_max之间，则按照某一概率 p 将新到达的分组丢弃

概率P与H_min 和 Th_max的关系

• 当 L_AV<Th_min 时，丢弃概率 p = 0
• 当 L_AV> Th_max 时，丢弃概率 p = 1
• 当 TH_min < LAV < TH_max时， 0 <p < 1

在 RED 的操作中，最难处理的就是丢弃概率 p 的选择，因为 p 并不是个常数。例如，按线性规律变化，从 0 变到 p_max。

不太理想

• 多年的实践证明，RED 的使用效果并不太理想
• 2015 年公布的 RFC 7567 已经把 RFC 2309 列为“陈旧的”，并且不再推荐使用 RED
• 对路由器进行主动队列管理 AQM 仍是必要的
• AQM 实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃
• 现在已经有几种不同的算法来代替旧的 RED，但都还在实验阶段。

TCP的运输连接管理（重点）

TCP是面向连接的协议，

运输连接有三个阶段：

1. 连接建立（三次握手）
2. 数据传输
3. 连接释放（四次挥手）

运输连接的管理就是使运输连接的建立和释放都能正常地进行。

建立连接的过程中要解决的三个问题：

1. 要使每一方能够知道对方的存在
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
3. 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

客户-服务器方式

• TCP 连接的建立采用客户服务器方式
• 主动发起连接建立的应用进程叫做客户 (client)
• 被动等待连接建立的应用进程叫做服务器 (server)

TCP的连接建立

• TCP 建立连接的过程叫做握手
• 握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手
• 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。

握手前

⼀开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端⼝，处于 LISTEN 状态

第一次握手

A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。表示向服务端发起连接，该报⽂不 包含应⽤层数据，之后客户端处于 SYN-SENT 状态。

第二次握手

• B 的 TCP 收到连接请求报文段后，如同意，则发回确认
• 第二次握手可以分为两次握手，但是可以合成一步所以就形成了三层握手
  • 确认报文段ACK = 1， 其确认号 ack = x +1
  • 同步报文段中使 SYN = 1，自己选择的序号 seq = y。
• 该报⽂也不包含应⽤层数据，之后服务端处于 SYNRCVD 状态。

第三次握手

• A 收到此报文段后向 B 给出确认，其 ACK = 1， 确认号 ack = y +1
• A 的 TCP 通知上层应用进程，连接已经建立。
• 最后把报⽂发送给服务端，这次报⽂可以携带客 户到服务器的数据，之后客户端和服务端处于 ESTABLISHED 状态。
• 为什么要发送最后一次？
  • 防止已失效的连接请求报文段突然传送的B，产生错误。在网络中的情况是错综复杂的，可能旧的请求报文同步报文比最新的同步报文先到达，第三次握手就是为了防止出现这种情况，

从上⾯的过程可以发现第三次握⼿是可以携带数据的，前两次握⼿是不可以携带数据的，这也是⾯试常问的题。

连接过程中的一些问题：

为什么客户端和服务端的初始序列号 ISN 是不相同的？

​ 如果⼀个已经失效的连接被重⽤了，但是该旧连接的历史报⽂还残留在⽹络中，如果序列号相同，那么就⽆法分辨 出该报⽂是不是历史报⽂，如果历史报⽂被新的连接接收了，则会产⽣数据错乱。 所以，每次建⽴连接前重新初始化⼀个序列号主要是为了通信双⽅能够根据序号将不属于本连接的报⽂段丢弃。 另⼀⽅⾯是为了安全性，防⽌⿊客伪造的相同序列号的 TCP 报⽂被对⽅接收。

既然 IP 层会分⽚，为什么 TCP 层还需要 MSS 呢？

• 最大传送单元MTU（Maximum Transfer Unit）： ⼀个⽹络包的最⼤⻓度，以太⽹中⼀般为 1500 字节，如果超过数据链路层的MTU值，即要分片；

• 最大报文段长度 MSS(Maximum Segment Size) ：除去 IP 和 TCP 头部之后，⼀个⽹络包所能容纳的 TCP 数据的最⼤⻓度；

IP层分片是有很大的风险的，在IP层中大小超过了MTU大小的数据（TCP头部+TCP数据）都会分片后传输，再由目标主机重新组合交给上层TCP运输层，但是在这段过程中，如果有一个IP分片丢失，整个IP报文的分片都会重传，因为IP层只负责最大努力交付，不负责超时重传机制，而且在丢失后，则不会响应ACK给对方，需要等到TCP在超时重发，整个TCP报文，效率非常低。

为了达到最佳的传输效能 TCP 协议在建⽴连接的时候通常要协商双⽅的 MSS 值， 当TCP报文超过MSS时会分片，这样IP层就不需要分片。

TCP的连接释放

TCP 连接释放过程比较复杂。数据传输结束后，通信的双方都可释放连接。TCP 连接释放过程是四报文握手。

• 数据传输结束后，通信的双方都可释放连接。
• 现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP连接。

第一次挥手

• A 把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待 B 的确认，之后客 户端进⼊ FIN_WAIT_1 状态。

第二次挥手

• B 发出确认，确认号 ack = u + 1， 而这个报文段自己的序号 seq = v，接着服务端进⼊ CLOSED_WAIT 状态。
• TCP 服务器进程通知高层应用进程。
• 从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收，之后客户A进⼊ FIN_WAIT_2 状态。

第三次挥手

• 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接，发送连接释放报文FIN=1，确认号ack = u+1，序号seq = w，之后服务端进⼊ LAST_ACK 状态。
• A 收到连接释放报文段后，之后进⼊ TIME_WAIT 状态，并且必须发出确认。

第四次挥手

• 在确认报文段中 ACK = 1，确认号 ack =w + 1， 自己的序号 seq = u + 1。
• 服务器B收到客户A的确认报文后就进⼊了 CLOSED 状态，⾄此服务端已经完成连接的关闭。
• 客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSED 状态，⾄此客户端也完成连接的关闭。

为什么挥手需要四次？

再来回顾下四次挥⼿双⽅发 FIN 包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据
• 服务器收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接

从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN ⼀般都会分开发 送，从⽽⽐三次握⼿导致多了⼀次。

为什么 TIME_WAIT 等待的时间是 2MSL？

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最⻓时间，超过这个时间报⽂将被丢弃。因为 TCP 报⽂基于是 IP 协议的

⽽ IP 头中有⼀个 TTL 字段，是 IP 数据报可以经过的最⼤路由数，每经过⼀个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报⽂通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，⽽ TTL 是经过路由跳数。所以 MSL 应该要⼤于等于 TTL 消耗为 0 的 时间，以确保报⽂已被⾃然消亡。

TIME_WAIT 等待 2 倍的 MSL，⽐较合理的解释是： 保证客户A的最后一个ACK报文能够到达服务端B，⽹络中可能存在来⾃发送⽅的数据包，当这些发送⽅的数据包 被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。 ⽐如如果被动关闭⽅没有收到断开连接的最后的 ACK 报⽂，就会触发超时重发 Fin 报⽂，另⼀⽅接收到 FIN 后， 会重发 ACK 给被动关闭⽅， ⼀来⼀去正好 2 个 MSL。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端⼜接收到了服务端重发的 FIN 报⽂，那么 2MSL 时间将重新计时。

为什么需要TIME_WAIT 状态？

1. 防止旧连接的数据包

   图片来源《图解网络》-小林coding

   上述过程中，如果TIME-WAIT过短或者没有，可能在相同端口复用TCP连接的过程中，接收到上一次的SEQ = 301的报文产生错误。

   所以，TCP 就设计出了这么⼀个机制 ，经过 2MSL 这个时间，⾜以让两个⽅向上的数据包都被丢弃，使得原来 连接的数据包在⽹络中都⾃然消失，再出现的数据包⼀定都是新建⽴连接所产⽣的。

2. 保证连接正确关闭

   图片来源《图解网络》-小林coding

如果TIME-WAIT过短或者没有服务端一直处于LAST_ACK状态，而当客户端在建立连接的过程中如果收到RST报文就会终止连接，所以客户端在 TIME-WAIT 状态等待 2MSL 时间后，就可以保证双⽅的连接都可以正常的关闭。