第5章 运输层

5.1 运输层协议概述

5.1.1 进程之间的通信

• 从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
• 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
• 运输层的作用： 运输层提供应用进程间的逻辑通信；复用和分用；屏蔽作用
• 网络层和运输层有明显的区别：
  • 网络层是为主机之间提供逻辑通信
  • 运输层为应用进程之间提供端到端的逻辑通信。

5.1.2 运输层的两个主要协议

• TCP/IP 的运输层有两个主要协议：

  • 用户数据报协议 UDP
  • 传输控制协议 TCP

• 两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU:

• UDP：一种无连接协议:

  • 提供无连接服务。
  • 传送的数据单位协议是 UDP 报文或用户数据报。
  • 对方的运输层在收到 UDP 报文后，不需要给出任何确认。
  • 虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式。

• TCP：一种面向连接的协议

  • 提供面向连接的服务。逻辑通信信道就相当于一条全双工的可靠信道。
  • 传送的数据单位协议是 TCP 报文段 (segment)。
  • TCP 不提供广播或多播服务。
  • 由于 TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。
  • 面向字节流：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。

5.1.3 运输层的端口

• 运行在计算机中的进程是用进程标识符来标志的。

• 但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。

• 为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对
  TCP/IP 体系的应用进程进行标志。

• 需要解决的问题

  • 由于进程的创建和撤销都是动态的，发送方几乎无法识别其他机器上的进程。
  • 有时我们会改换接收报文的进程，但并不需要通知所有发送方。
  • 我们往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。

• 解决方法：在运输层使用协议端口号，或通常简称为端口 。

  • 虽然通信的终点是应用进程，但我们可以把端口想象是通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由 TCP 来完成。
  • 端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。

• TCP/IP 运输层端口

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

• 两大类端口 ：

  • 服务器端使用的端口号 image.png
    • 熟知端口，数值一般为 0~1023。
    • 登记端口号，数值为 1024~49151，为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记，以防止重复。
  • 客户端使用的端口号
    • 又称为短暂端口号，数值为 49152~65535，留给客户进程选择暂时使用。
    • 当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。

5.2 用户数据报协议UDP

5.2.1 UDP概述

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

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

• UDP 的主要特点 ：

  • (1) UDP 是无连接的，发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。

  • (2) UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。

  • (3) UDP 是面向报文的。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文。
    应用程序必须选择合适大小的报文。

    • 若报文太长，UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，这会降低 IP 层的效率。
    • 若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，这也降低了 IP 层的效率。

  • (4) UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。

  • (5) UDP 支持一对一、一对多、多对一和多对多的交互通信。

  • (6) UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

5.2.2 UDP的首部格式

image.png

• 用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节。
• 在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
• 计算 UDP 检验和的例子 image.png

5.3 传输控制协议TCP概述

5.3.1 TCP最主要的特点

5.3.2 TCP的连接

• TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。

• TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节

• TCP 可把太长的数据块划分短一些再传送。TCP 也可等待积累有足够多的字节后再构成报文段发送出去。

• TCP 连接的端点叫做套接字 (socket) 或插口。端口号拼接到 IP 地址即构成了套接字。 image.png
• 每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。即： image.png

5.4 可靠传输的工作原理

• 理想的传输条件有以下两个特点：
  (1) 传输信道不产生差错。
  (2) 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
• 在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

5.4.1 停止等待协议

• “停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
• 全双工通信的双方既是发送方也是接收方。

1、无差错情况

A 发送分组 M1，发完就暂停发送，等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送 ACK。A 在收到了对 M1 的确认后，就再发送下一个分组 M2。

image.png

2、出现差错

• 在接收方 B 会出现两种情况：

  • B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
  • M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。

• 在这两种情况下，B 都不会发送任何信息。如何保证 B 正确收到了 M1 呢？
  解决方法：超时重传

  • A 为每一个已发送的分组都设置了一个超时计时器。

  • A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。

    
    image.png

3、确认丢失和确认迟到

• 确认丢失

  • 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内不能收到确认，但 A 并无法知道：是自己发送的分组出错、丢失了，或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。
  • 假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动：
    • 第一，丢弃这个重复的分组 M1，不向上层交付。
    • 第二，向 A 发送确认。不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。

• 确认迟到

  • 传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了。
  • A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。
  • B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组。

• 注意：

  • 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。
  • 分组和确认分组都必须进行编号

  • 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

    
    image.png

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

4、信道利用率

• 停止等待协议的优点是简单，缺点是信道利用率太低。 image.png
• 流水线传输：就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。 image.png

5.4.2 连续ARQ协议

• 发送方维持的发送窗口，它的意义是：位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
• 连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
• 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。
  • 优点：容易实现，即使确认丢失也不必重传。
  • 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。
• Go-back-N（回退 N）: 表示需要再退回来重传已发送过的 N 个分组。
  • 如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。
  • 可见当通信线路质量不好时，连续 ARQ 协议会带来负面的影响。

5.5 TCP报文段的首部格式

• 一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。

• TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。

  
  image.png
  • 源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
  • 序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
  • 确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
  • 数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
  • 紧急 URG —— 当 URG =1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。
  • 确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。
  • 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
  • 复位 RST (ReSeT) —— 当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
  • 同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。
  • 终止 FIN (FINish) —— 用来释放一个连接。FIN =1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
  • 窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
  • 检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
  • 紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
  • 选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
  • 其他选项
    • 窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小。
    • 时间戳选项——占 10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节）。
    • 选择确认选项

• 为什么要规定 MSS ？

  • 若选择较小的 MSS 长度，网络的利用率就降低
  • 若 TCP 报文段非常长，那么在 IP 层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的 TCP 报文段。当传输出错时还要进行重传。这些也都会使开销增大。
  • 由于 IP 数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要分片的 MSS，如果改走另一条路径就可能需要进行分片。因此最佳的 MSS 是很难确定的。

5.6 TCP可靠传输的实现

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

5.6.1 以字节为单位的滑动窗口

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

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

• 根据这两个数据，A 就构造出自己的发送窗口

• 发送窗口的位置由窗口前沿和后沿的位置共同确定。TCP标准强烈不赞成向后收缩。

• B接收窗口，类A。

• 接收方发送确认

  • 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 但请注意两点：
    • 第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。。

    • 第二，捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

      
      image.png

• 发送方的应用进程把字节流写入 TCP 的发送缓存。发送窗口通常只是发送缓存的一部分。

• 接收方的应用进程从 TCP 的接收缓存中读取字节流。

• 缓存空间和序号空间都是有限的，并且都是循环使用的。

• 发送缓存用来暂时存放：

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

• 接收缓存用来暂时存放：

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

• 注意

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

5.6.2 超时重传时间的选择

• 重传机制是 TCP 中最重要和最复杂的问题之一。重传时间的选择是 TCP 最复杂的问题之一。
• TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。
• 由于 TCP 的下层是一个互联网环境，IP 数据报所选择的路由变化很大。因而运输层的往返时间 (RTT) 的方差也很大。
• 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。
• 但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
• TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。

• 加权平均往返时间(平滑的往返时间)
  

  第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS： image.png

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

• 超时重传时间 RTO：应略大于上面得出的加权平均往返时间 RTTS。
  RFC 2988 建议使用下式计算 RTO：其中RTTD 是 RTT 的偏差的加权平均值。

  
  image.png

RFC 2988 建议这样计算 RTTD。第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：belta是个小于 1 的系数，其推荐值是 1/4，即 0.25。
[图片上传中...(image.png-5872e7-1592282375427-0)]

• 往返时间 (RTT) 的测量
  • Karn 算法:在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。超时重传时间就无法更新。
  • 修正的 Karn 算法 :报文段每重传一次，就把 RTO 增大一些。系数gamma的典型值是 2 。当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。 image.png

5.6.3 选择确认SACK

• 若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据：选择确认 SACK 。

• 和前后字节不连续的每一个字节块都有两个边界：边界和右边界。左边界指出字节块的第一个字节的序号，但右边界减 1 才是字节块中的最后一个序号。

• RFC 2018 的规定

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

5.7 TCP的流量控制

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

• 流量控制 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

• 利用可变窗口进行流量控制：A 向 B 发送数据。在连接建立时，B 告诉 A：“我的接收窗口 rwnd = 400（字节）”。

• 可能发生死锁：

  • B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。
  • 但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。
  • 如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
  • 为了解决这个问题，TCP 为每一个连接设有一个持续计时器 。

• 持续计时器

• TCP 为每一个连接设有一个持续计时器。

• 只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。

• 若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

• 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。

• 若窗口不是零，则死锁的僵局就可以打破了。

5.7.2 TCP的传输效率

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

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

• 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞

• 增加资源不能解决拥塞。

• 网络拥塞往往是由许多因素引起的、

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

• 拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞。

• 拥塞控制与流量控制的区别

  • 拥塞控制
    • 拥塞控制就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。
    • 拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
    • 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
  • 流量控制
    • 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。
    • 流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
• 拥塞控制所起的作用 image.png

• 分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。

• 开环控制和闭环控制

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

• 监测网络的拥塞的指标（这些指标的上升都标志着拥塞的增长）：

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

5.8.2 TCP的拥塞控制方法

• TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。
• TCP发送方维持一个拥塞窗口 CWND
  • 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。
  • 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
  • 所以，发送窗口大小不仅取决于接收方公告的接收窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：Min(公告窗口值，拥塞窗口值)
    即发送窗口的上限值 =Min [rwnd, cwnd]
• 控制拥塞窗口的原则
  • 只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。
  • 但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
• 拥塞的判断
  • 重传定时器超时：现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于 1 %）。只要出现了超时，就可以猜想网络可能出现了拥塞。
  • 收到三个相同（重复）的 ACK：个别报文段会在网络中丢失，预示可能会出现拥塞（实际未发生拥塞），因此可以尽快采取控制措施，避免拥塞。

TCP拥塞控制算法：四种（ RFC 5681）

• 慢开始 (slow-start)

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

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

  • 初始拥塞窗口 cwnd 设置：

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

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

    image.png
    • 其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
    • 用这样的方法逐步增大发送方的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。
    • 每经过一个传输轮次，拥塞窗口就加倍。窗口大小按指数增加，不慢！
    • 一个传输轮次所经历的时间其实就是往返时间 RTT。“传输轮次”更加强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

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

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

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

    • 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：

      • ssthresh = max(cwnd/2，2)
      • cwnd = 1
      • 执行慢开始算法

    • 这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

    • 发送方一连收到 3 个对同一个报文段的重复确认。发送方改为执行快重传和快恢复算法。

• 快重传 (fast retransmit)
  • 采用快重传FR 算法可以让发送方尽早知道发生了个别报文段的丢失
  • 快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
  • 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
  • 使用快重传可以使整个网络的吞吐量提高约20%。
  • 不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

• 快恢复 (fast recovery)
  • 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：
    • (1) 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
    • (2) 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
    • (3) 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
  • “加法增大” AI ，“乘法减小”MD ，二者合在一起就是所谓的 AIMD 算法。

5.8.3 主动队列管理AQM

5.9 TCP的运输连接管理

• 运输连接有三个阶段：

  • 连接建立
  • 数据传送
  • 连接释放

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

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

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

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

5.9.1 TCP的连接建立

• TCP 建立连接的过程叫做握手。

• 握手需要在客户和服务器之间交换三个 TCP 报文段。称之为三报文握手。

• 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。 image.png

• A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。

• B 的 TCP 收到连接请求报文段后，如同意，则发回确认。
  B 在确认报文段中应使 SYN = 1，使 ACK = 1， 其确认号ack = x + 1，自己选择的序号 seq = y。

• A 收到此报文段后向 B 给出确认，其 ACK = 1， 确认号 ack = y+1。A 的 TCP 通知上层应用进程，连接已经建立。

• B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。

5.9.2 TCP的连接释放

• TCP 连接释放过程比较复杂。

• 数据传输结束后，通信的双方都可释放连接。

• TCP 连接释放过程是四报文握手。
  

  image.png

• 数据传输结束后，通信的双方都可释放连接。

• 现在 A 的应用进程先向其 TCP 发出连接释放
  报文段，并停止再发送数据，主动关闭 TCP
  连接。
  A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认。

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

• 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。

• A 收到连接释放报文段后，必须发出确认。
  在确认报文段中 ACK = 1，确认号 ack = w + 1， 自己的序号 seq = u + 1。

• A 必须等待 2MSL的时间

  • 第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
  • 第二，防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

MSL：最长报文段时间

5.9.3 TCP的有限状态机

• TCP 的有限状态机可以更清晰地看出 TCP 连接的各种状态之间的关系。
• TCP 有限状态机的图中每一个方框都是 TCP 可能具有的状态。
• 每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名。
• 状态之间的箭头表示可能发生的状态变迁。
• 箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。
• 图中有三种不同的箭头。
  • 粗实线箭头表示对客户进程的正常变迁。
  • 粗虚线箭头表示对服务器进程的正常变迁。
  • 细线箭头表示异常变迁。
    image.png