《计算机网络》笔记——第5章 运输层（二）

声明：

本博客是本人在学习《计算机网络》后整理的笔记，旨在方便复习和回顾，并非用作商业用途。

本博客已标明出处，如有侵权请告知，马上删除。

5.6 TCP 可靠传输的实现

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

• TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输。
• TCP 的滑动窗口是以字节为单位的。
• 发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口。
• 发送窗口表示：在没有收到确认的情况下，可以连续把窗口内的数据全部发送出去。
• 接收窗口表示：只允许接收落入窗口内的数据。

发送缓存

接收缓存

发送缓存与接收缓存的作用

• 发送缓存用来暂时存放：
  • 发送应用程序传送给发送方 TCP 准备发送的数据；
  • TCP 已发送出但尚未收到确认的数据。
• 接收缓存用来暂时存放：
  • 按序到达的、但尚未被接收应用程序读取的数据；
  • 不按序到达的数据。

需要强调三点

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

接收方发送确认

• 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
• 但请注意两点：
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

5.6.2 超时重传时间的选择

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

往返时延的方差很大

TCP 超时重传时间设置

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

加权平均往返时间

• TCP 保留了 RTT 的一个加权平均往返时间 RTTS（这又称为平滑的往返时间）。

• 第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
  $$新的RTTS=(1+\alpha )\ast (旧的RTTS)+\alpha \ast (新的RTT样本)$$

• 式中，0 <= α < 1。若 α 很接近于零，表示 RTT 值更新较慢。若选择 α 接近于 1，则表示 RTT 值更新较快。

• RFC 6298 推荐的 α 值为 1/8，即 0.125。

超时重传时间 RTO

• RTO (Retransmission Time-Out) 应略大于上面得出的加权平均往返时间 RTTS。

• RFC 6298 建议使用下式计算 RTO：
  $$RTO=RTTS+4\ast RTTD$$

• RTTD 是 RTT 的偏差的加权平均值。

• RFC 6298 建议这样计算 RTTD 。第一次测量时， RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD ：
  $$新的RTTD=(1-\beta )\ast (旧的RTTD)+\beta \ast |RTTS-新的RTT样本|$$

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

往返时间 (RTT) 的测量相当复杂

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

Karn 算法

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

修正的 Karn 算法

• 报文段每重传一次，就把 RTO 增大一些：
  $$新的RTO=\gamma \ast (旧的RTO)$$

• 系数 γ 的典型值是 2 。

• 当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。

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

5.6.3 选择确认 SACK

• 问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？
• 答案是可以的。选择确认 SACK (Selective ACK) 就是一种可行的处理方法。

接收到的字节流序号不连续

RFC 2018 的规定

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

5.7 TCP 的流量控制

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

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

利用可变窗口进行流量控制举例

可能发生死锁

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

持续计时器

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

5.7.2 必须考虑传输效率

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

糊涂窗口综合症

糊涂窗口综合症：每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象。

发送方糊涂窗口综合症

• 发送方 TCP 每次接收到一字节的数据后就发送。
• 这样，发送一个字节需要形成 41 字节长的 IP 数据报。效率很低。
• 解决方法：使用 Nagle 算法。

Nagle 算法

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

接收方糊涂窗口综合症

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

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

5.8 TCP 的拥塞控制

5.8.1 拥塞控制的一般原理

• 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞 (congestion)。
• 最坏结果：系统崩溃。

拥塞产生的原因

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

  • 点缓存的容量太小；
  • 链路的容量不足；
  • 处理机处理的速率太慢；
  • 拥塞本身会进一步加剧拥塞；

• 出现拥塞的原因：
  $$\sum 对资源需求>可用资源$$

增加资源能解决拥塞吗？

• 不能。这是因为网络拥塞是一个非常复杂的问题。简单地采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能使网络的性能更坏。
• 网络拥塞往往是由许多因素引起的。例如：
  • 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
  • 提高处理机处理的速率会会将瓶颈转移到其他地方；

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

拥塞控制所起的作用

拥塞控制的一般原理

• 拥塞控制的前提：网络能够承受现有的网络负荷。
• 实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
• 分组的丢失是网络发生拥塞的征兆而不是原因。
• 在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制和闭环控制

闭环控制

属于闭环控制的有以下几种措施：

• 监测网络系统，以便检测到拥塞在何时、何处发生。
• 将拥塞发生的信息传送到可采取行动的地方。
• 调整网络系统的运行以解决出现的问题。

监测网络的拥塞

• 主要指标有：
  • 由于缺少缓存空间而被丢弃的分组的百分数；
  • 平均队列长度；
  • 超时重传的分组数；
  • 平均分组时延；
  • 分组时延的标准差，等等。
• 上述这些指标的上升都标志着拥塞的增长。

5.8.2 TCP 的拥塞控制方法

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

• TCP 发送方维持一个拥塞窗口 cwnd (Congestion Window)

• 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。

• 发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：
  $$真正的发送窗口值=Min(接收方窗口值，拥塞窗口值)$$

控制拥塞窗口的原则

• 只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。
• 但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

拥塞的判断

TCP 拥塞控制算法

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

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

慢开始 (Slow start)

• 目的：用来确定网络的负载能力或拥塞程度。

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

• 两个变量：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rQvMXtFE-1594907708108)(img2/5-8-6.png)]

• 拥塞窗口 cwnd 控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。
  $$拥塞窗口cwnd每次的增加量=min(N,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 缓慢地增大，避免出现拥塞。
• 每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
• 使拥塞窗口 cwnd 按线性规律缓慢增长。
• 在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

注意：

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

当网络出现拥塞时

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

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

1. 当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。
2. 在执行慢开始算法时，拥塞窗口 cwnd=1，发送第一个报文段。发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1，然后开始下一轮的传输（请注意，横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
3. 当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（图中的点 1 ，此时拥塞窗口 cwnd = 16），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
4. 当拥塞窗口 cwnd = 24 时，网络出现了超时（图中的点 2 ），发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd / 2 = 12，同时设置拥塞窗口 cwnd = 1，进入慢开始阶段。
5. 按照慢开始算法，发送方每收到一个对新报文段的确认 ACK，就把拥塞窗口值加 1。
6. 当拥塞窗口 cwnd = ssthresh = 12 时（图中的点 3，这是新的 ssthresh 值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。
7. 当拥塞窗口 cwnd = 16 时（图中的点 4 ），出现了一个新的情况，就是发送方一连收到 3 个对同一个报文段的重复确认（图中记为 3-ACK）。发送方改为执行快重传和快恢复算法。因此，在图的点 4，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值 ssthresh = cwnd / 2 = 8，同时设置拥塞窗口 cwnd = ssthresh = 8（见图中的点），并开始执行拥塞避免算法。

快重传算法

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

快重传举例

快恢复算法

当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：

• 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
• 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
• 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

加法增大，乘法减小 (AIMD)

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

TCP 拥塞控制流程图

发送窗口的上限值

• 发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即应按以下公式确定：
  $$发送窗口的上限值=Min[rwnd,cwnd]$$

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

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

• 也就是说，rwnd 和 cwnd 中数值较小的一个，控制了发送方发送数据的速率。

5.8.3 主动队列管理 AQM

• TCP 拥塞控制和网络层采取的策略有密切联系。
• 若路由器对某些分组的处理时间特别长，那么这就可能使这些分组中的 TCP 报文段经过很长时间才能到达终点，结果引起发送方超时，对这些报文段进行重传。
• 重传会使 TCP 连接的发送端认为在网络中发生了拥塞，但实际上网络并没有发生拥塞。
• 对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

“先进先出” FIFO 处理规则

• 路由器的队列通常都是按照 “先进先出” FIFO (First In First Out) 的规则处理到来的分组。
• 当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。这就叫做尾部丢弃策略 (tail-drop policy)。
• 路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。

全局同步

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

主动队列管理 AQM

• 1998 年提出了主动队列管理 AQM (Active Queue Management)。
• 所谓 “主动” 就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。
• AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测 RED (Random Early Detection)。

随机早期检测 RED

• 使路由器的队列维持两个参数：队列长度最小门限 THmin 和最大门限 Thmax 。
• RED 对每一个到达的分组都先计算平均队列长度 LAV 。
  • 若平均队列长度小于最小门限 THmin，则将新到达的分组放入队列进行排队。
  • 若平均队列长度超过最大门限 Thmax ，则将新到达的分组丢弃。
  • 若平均队列长度在最小门限 THmin 和最大门限 Thmax 之间，则按照某一概率 p 将新到达的分组丢弃。

RED 将路由器的到达队列划分成为三个区域：

• 当 LAV < Thmin 时，丢弃概率 p = 0。
• 当 LAV > Thmax 时，丢弃概率 p = 1。
• 当 Thmin < LAV < Thmax时， 0 < p < 1 。

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

5.9 TCP 的运输连接管理

运输连接的三个阶段

• TCP 是面向连接的协议。
• TCP 连接有三个阶段：
  1. 连接建立
  2. 数据传送
  3. 连接释放
• TCP 连接的管理就是使 TCP 连接的建立和释放都能正常地进行。

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

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

客户—服务器方式

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

5.9.1 TCP 的连接建立

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

5.9.2 TCP 的连接释放

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

A 必须等待 2MSL 的时间

• 第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
• 第二，防止 “已失效的连接请求报文段” 出现在本连接中。

保活计时器

• 用来防止在 TCP 连接出现长时期的空闲。
• 保活计时器通常设置为 2 小时 。若服务器过了 2 小时还没有收到客户的信息，它就发送探测报文段。若发送了 10 个探测报文段（每一个相隔 75 秒）还没有响应，就假定客户出了故障，因而就终止该连接。

5.9.3 TCP 的有限状态机

• 箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。
• 图中有三种不同的箭头。
  • 粗实线箭头表示对客户进程的正常变迁。
  • 粗虚线箭头表示对服务器进程的正常变迁。
  • 细线箭头表示异常变迁。