计算机网络 - 第 5 章 运输层

5.1 运输层协议概述

5.1.1 进程之间的通信

5.1.2 运输层的两个主要协议

5.1.3 运输层的端口

5.2 用户数据报协议 UDP

5.2.1 UDP 概述

5.2.2 UDP 的首部格式

5.3 传输控制协议 TCP 概述

5.3.1 TCP 最主要的特点

TCP 是 TCP/IP 体系中非常复杂的一个协议，下面介绍 TCP 最主要的特点

(1). TCP 是面向连接的传输层协议

也就是，应用程序在使用 TCP 协议之前，必须先建立 TCP 连接；在传送数据完毕后，必须释放已经建立的 TCP 连接

也就是，应用进程之间的通信好像在 "打电话" ：通话前要先拨号建立连接，通话结束后要挂机释放连接

(2). 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）

(3). TCP 提供可靠交付的服务；通过 TCP 连接传送的数据，无差错 、不丢失 、不重复，并且按序到达

(4). TCP 提供全双工通信

TCP 允许通信双方的应用进程在任何时候都能发送数据；TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据；在发送时，应用程序在把数据传送给 TCP 的缓存后，就可以做自己的事，而 TCP 在合适的时候把数据发送出去；在接收时，TCP 把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据

(5). 面向字节流

TCP 中的 "流（stream）" 指的是流入到进程或从进程流出的字节序列；

"面向字节流" 的含义是 ：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流；TCP 并不知道所传送的字节流的含义；

TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的 TCP 共 10 个数据块，但接收方的 TCP 可能只用了 4 个数据块就把收到的字节流交付上层的应用程序）

但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样；当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据

图 5-8 TCP 面向字节流的概念

为了突出示意图的要点，我们只画了一个方向的数据流；但注意，在实际的网络中，一个 TCP 报文段包含上千个字节很常见，而图中的各部分都只画了几个字节，知识为了更方便地说明 "面向字节流" 的概念

另一点很重要 ：图中的 TCP 连接是一条虚连接（也就是逻辑连接），而不是一条真正的物理连接；TCP 报文段先要传送到 IP 层，加上 IP 首部后，再传送到数据链路层，再加上数据链路层的首部和尾部后，才离开主机发送到物理链路

图 5-8 指出，TCP 和 UDP 在发送报文时所采用的方式完全不同；TCP 并不关心应用进程一次把多长的报文发送到 TCP 的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）；如果应用进程传送到 TCP 缓存的数据块太长，TCP 就可以把它划分短一些再传送；如果应用进程一次只发来一个字节，TCP 也可以等待积累足够多的字节后再构成报文段发送出去

5.3.2 TCP 的连接

TCP 把连接作为最基本的抽象；TCP 的许多特性都与 TCP 是面向连接的这个基本特性有关，因此我们对 TCP 连接需要有更清楚的了解

前面已经讲过，每一条 TCP 连接有两个端点；TCP 连接的端点是什么呢？不是主机，不是主机的 IP 地址，不是应用进程，也不是传输层的协议端口；

TCP 连接的端点叫做套接字（socket）或插口

根据 RFC 793 的定义：端口号拼接到 IP 地址，即构成了套接字；因此，套接字的表示方法是在点分十进制的 IP 地址后面写上端口号，中间用冒号或逗号隔开；

例如，若 IP 地址是 192.3.4.5 而端口号是 80 ，那么得到的套接字就是 （192.3.4.5 : 80），总之有

        套接字 socket  = （IP 地址：端口号）

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

    TCP 连接 ::= {socket1，socket2} = {(IP1：port1)，(IP2：port2)}

这里 IP1 和 IP2 分别是两个端点主机的 IP 地址，而 port1 和 port2 分别是两个端点主机中的端口号；TCP 连接的两个套接字就是 socket1 和 socket2；可见套接字 socket 是个很抽象的概念

总之，TCP 连接就是由协议软件所提供的一种抽象；虽然有时为了方便，我们也可以说，在一个应用进程和另一个应用进程之间建立了一条 TCP 连接；

但一定要记住：TCP 连接的端点是个很抽象的套接字，即（IP地址：端口号）；同一个 IP 地址可以有多个不同的 TCP 连接，而同一个端口号也可以出现在多个不同的 TCP 连接中

同一个名词 socket 却可以表示多种不同的意思：

(1). 允许应用程序访问连网协议的应用编程接口 API（Application Programming Interface），即传输层和应用层之间的一种接口，称为 socket API ，简称为 socket

(2). 在 socket API 中使用的一个函数名也叫做 socket

(3). 在调用 socket 函数的端点称为 socket ，如 "创建一个数据报 socket"

(4). 调用 socket 函数时，其返回值称为 socket 描述符，可简称为 socket

(5). 在操作系统内核中连网协议的 Berkeley 实现，称为 socket 实现

5.4 可靠传输的工作原理

我们知道，TCP 发送的报文段是交给 IP 层传送的；IP 层只能提供尽最大努力服务，也就是说，TCP 下面的网络所提供的是不可靠的传输；因此，TCP 必须采用适当的措施才能使得两个传输层之间的通信变得可靠

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

(1). 传输信道不产生差错

(2). 不管发送方以多块的速度发送数据，接收方总是来得及处理收到的数据

在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。

然而实际的网络都不具备以上两个理想条件；但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度；这样一来，本来不可靠的传输信道就能够实现可靠传输了

5.4.1 停止等待协议

全双工通信的双方既是发送方也是接收方；下面为了讨论问题的方便，仅考虑 A 发送数据，而 B 接收数据并发送确认；A 叫做发送方，B 叫做接收方；这里讨论可靠传输的原理，因此把传送的数据单元都称为分组，并不考虑数据是在哪一个层次上传送的；"停止等待" 就是每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组

1. 无差错情况

    停止等待协议可用图 5-9 来说明；图 5-9(a) 是最简单的无差错情况；A 收到分组 M1 ，发完就暂停发送，等待 B 的确认；B 收到了 M1 就向 A 发送确认；A 在收到了对 M1 的确认后，就再发送下一个分组 M2；A 在收到 B 对 M2 的确认后，再发送 M3

2. 出现差错

图 5-9(b) 是分组在传输过程中出现差错的情况；

B 接收到 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）；也可能是 M1 在传输过程中丢失了，这时 B 当然什么都不知道；在这两种情况下，B 都不会发送任何信息给 A 。

可靠传输协议是这样设计的：

(1). A 只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组；这就叫做超时重传

(2). 要实现超时重传，就要在每发送完一个分组时设置一个超时计时器；如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器；

在图 5-9(a) 中，A 为每一个已发送的分组都设置了一个超时计时器，但 A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器；为简单起见，这些细节在图 5-9(a) 中都省略了。

这里注意以下三点：

第一，A 在发送完一个分组后，必须暂时保留已发送的分组的副本（在发生超时重传时使用）；只有在收到相应的确认后才能清除暂时保留的分组副本

第二，分组和确认分组都必须进行编号，这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认

第三，超时计时器设置的重传时间，应当比数据在分组传输的平均往返时间更长一些；图 5-9(b) 中的一段虚线表示如果 M1 正确到达 B 同时 A 也正确收到确认的过程；可见重传时间应设定为比平均往返时间更长一些；如果重传时间设定得很长，那么通信的效率就会很低，如果重传时间设定得太短，会导致产生不必要的重传，浪费网络资源；实际上，在传输层重传时间的准确设定是非常复杂的，因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延（这取决于这些网络当时的拥塞情况），这些都是不确定因素

图 5-9 中把往返时间当做固定的，只是为了讲述原理的方便，关于重传时间如何选择，后面再做进一步讨论

3. 确认丢失和确认迟到

图 5-10(a) 说明的是另一种情况；B 所发送的对 M1 的确认丢失了，A 在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错 、丢失，或者是 B 发送的确认丢失了；因此 A 在超时计时器到期后就要重传 M1 ；现在应注意 B 的动作，假定 B 又收到了重传的分组 M1，这时 B 应采取两个行动：

第一，丢弃这个重复的分组 M1，不向上层交付

第二，向 A 发送确认；不能认为已经发送过确认就不再发送，因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认

图 5-10(b) 也是一种可能出现的情况；传输过程中没有出现差错，但 B 对分组 M1 的确认迟到了；A 会收到重复的确认，对重复确认的处理很简单：收下后就丢弃。B 仍然会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组

通常 A 最终总是可以收到对所有发出的分组的确认；如果 A 不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信

像上述的这种可靠传输协议常称为自动重传请求 ARQ（Automatic Repeat Request），意思是重传的请求是自动进行的；接收方不需要请求发送方重传某个出凑的分组

4. 信道利用率

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

5.4.2 连续 ARQ 协议

滑动窗口协议比较复杂，是 TCP 协议的精髓所在；这里先给出连续 ARQ 协议最基本的概念，但不涉及许多细节问题；详细的滑动窗口协议将在后面的 5.6 节中讨论

图 5-13(a) 表示发送方维持的发送窗口，它的意义是：位于发送窗口内的 5 个分组都可以连续发送出去，而怒需要等待对方的确认；这样，信道利用率就提高了

在讨论滑动窗口时，我们应当注意到，图中还有一个时间坐标（但以后往往省略这样的时间坐标）；按照习惯，"向前" 是指 "向着时间增大的方向" ，而 "向后" 是 "向着时间减少的方向"；分组发送是按照分组序号从小到大发送的

连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置；图 5-13(a) 表示发送方收到了第 1 个分组的确认，于是把发送窗口向前移动一个分组的位置；如果原来已经发送了前 5 个分组，那么现在就可以发送窗口内的第 6 个分组了

接收方一般都是采用累积确认的方式；也就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分都已正确收到了

累积确认有优点也有缺点；优点是：容易实现，即使确认丢失也不必重传；缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息

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

在深入讨论 TCP 的可靠传输问题之前，必须先了解 TCP 的报文段首部的格式

5.5 TCP 报文段的首部格式

TCP 虽然是面向字节流的，但 TCP 传送的数据单元就是报文段；一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用；因此，只有弄清 TCP 首部各字段的作用才能掌握 TCP 的工作原理；下面讨论 TCP 报文段的首部格式

TCP 报文段首部的前 20 个字节是固定的（图 5-14），后面有 4n 字节是根据需要而增加的选项（n 是整数）；因此 TCP 首部的最小长度是 20 字节

首部固定部分各字段的意义如下：

(1). 源端口和目的端口

      各占 2 个字节，分别写入源端口号和目的端口号；和前面图 5-6 所示的 UDP 的分用相似，TCP 的分用功能也是通过端口实现的

(2). 序号

      占 4 字节；序号范围是 [0，232 - 1]，共 232（即 4294967296）个序号；序号增加到 232 - 1 后，下一个序号就又回到 0

(3). 

(4). 

(5). 

(6). 

(7). 

(8). 

(9). 

(10). 

(11). 

(12). 

(13). 

(14). 

(15).  

5.6 TCP 可靠传输的实现

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

5.6.2 超时重传时间的选择

5.6.3 选择确认 SACK

5.7 TCP 的流量控制

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

5.7.2 TCP 的传输效率

5.8 TCP 的拥塞控制

5.8.1 拥塞控制的一般原理

   (1). 在计算机网络中，链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源

   (2). 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏；这种情况就叫做 "拥塞（congestion）" 

   (3). 可以把出现网络拥塞的条件写成如下公式：

                          对资源的需求  >  可用资源

   (4). 若网络中有许多资源同时呈现供应不足，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降；

有人可能会说："只要任意增加一些资源，例如，把结点缓存的存储空间扩大，或把链路更换为更高速率的链路，或把结点处理机的运算速度提高，就可以解决网络拥塞的问题了" ；其实不然，这是因为网络拥塞是一个非常复杂的问题，简单采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能使得网络的性能更坏

网络拥塞往往是由许多因素引起的；例如，当某个结点缓存的容量太小时，到达该结点的分组因无存储空间暂存而不得不被丢弃；现在设想将该结点缓存的容量扩展到非常大，于是凡到达该结点的分组均可在结点的缓存队列中排队，不受任何限制；由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数分组的排队等待时间将会大大增加，结果上层软件只好把这些队列中的分组进行重传（因为早就超时了）；由此可见，简单地扩大缓存的存储空间同样会造成网络资源的严重浪费，因而解决不了网络拥塞的问题

又如，处理机处理的速率太慢可能引起网络的拥塞；简单地将处理机的速率提高，可能会使上述情况缓解一些，但往往又会将瓶颈转移到其他地方；问题的实质往往是整个系统的各个部分不匹配；只有所有的部分都平衡了，问题才会得到解决

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

拥塞控制与流量控制的关系密切，这两者之间也存在着一些差别；

所谓拥塞控制，就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载；拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷；拥塞控制是一个全局性的过程，涉及到所有的主机 、所有的路由器，以及与降低网络传输性能有关的所有因素；但 TCP 连接的端点只要迟迟不能收到对方的确认信息，就猜想在当前网络中的某处很可能发生了拥塞，但这时却无法知道到底发生在网络的何处，也无法知道发生拥塞的具体原因（是访问某个服务器的信息量过大？还是在某个地区出现自然灾害）

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

5.8.2 TCP 的拥塞控制方法

TCP 进行拥塞控制的算法有四种：

   (1). 即慢开始（slow-start）

   (2). 拥塞避免（congestion avoidance）

   (3). 快重传（fast retransmit）

   (4). 快恢复（fast recovery）

假定：

A. 数据是单方向传送的，对方只传送确认报文

B. 接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定

5.8.3 主动队列管理 AQM

上一节讨论的 TCP 拥塞控制并没有和网络层采取的策略联系起来；其实，它们之间有着密切的关系

5.9 TCP 的运输连接管理

   (1). TCP 是面向连接的协议

   (2). 运输连接是用来传送 TCP 报文的

   (3). TCP 运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程

   (4). 运输连接就有三个阶段，即：连接建立 、数据传送 、连接释放

   (5). 运输连接的管理就是使运输连接的建立和释放都能正常地运行

在 TCP 连接建立过程中要解决以下三个问题：

   (1). 要使任何一方都能明确感知对方的存在

   (2). 要允许双方协商一些参数（如 最大窗口值 、是否使用窗口扩大选项和时间戳选项，以及服务质量等）

   (3). 能够对运输实体资源（如缓存大小 、连接表中的项目等）进行分配

   (4). TCP 连接的建立采用客户服务器方式

  主动发起连接建立的应用进程叫做客户（client），而被动等待连接建立的应用进程叫做服务器（server）

5.9.1 TCP 的连接建立

   (1). TCP 建立连接的过程叫做握手，握手需要在客户与服务器之间交换 3 个 TCP 报文段

   图 5-28 画出了 3 次握手建立 TCP 连接的过程

   0). 假定主机 A 运行的是 TCP 客户程序，而主机 B 运行 TCP 服务器程序；最初两端的 TCP 进程都处于 CLOSED（关闭）状态；图中在主机下面的方框分别是 TCP 进程所处的状态；请注意，在本例中，A 主动打开连接，B 被动打开连接

   1). 主机 B 的 TCP 服务器进程先创建传输控制模块 TCB，准备接受客户进程的连接请求；然后 B 的服务器进程就处于 LISTEN（监听）状态，等待客户的连接请求；如有连接请求，立即做出响应

   2). A 的 TCP 客户进程也是先创建传输控制模块 TCB；然后，在准备建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN = 1，同时选择一个初始序号 seq = x；TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号；这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态

   3). B 的 TCP 服务器进程收到连接请求报文段后，如 B 同意建立连接，则向 A 发送确认；在确认报文段中应把 SYN 位和 ACK 位都置为 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y；请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号；这时 TCP 服务器进程进入 SYN-RCVD（同步收到）状态

   4). A 的 TCP 客户进程收到 B 的确认后，还要向 B 给出确认；确认报文段的 ACK 位，置为 1，确认号 ack = y + 1，而自己的序号 seq = x + 1；TCP 的标准规定，ACK 报文段可以携带数据，如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x + 1；这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态

   5). 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态

    上面给出的连接建立过程叫做三报文握手（TCP 三次握手）；请注意，在图 5-28 中 B 发送给 A 的报文段，也可拆成两个报文段；可以先发送一个确认报文段（ACK = 1，ack = x + 1），然后再发送一个同步报文段（SYN = 1，seq = y）；这样的过程就变成了四报文握手，但效果跟三次握手是一样的

    为什么 A 最后还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误

    所谓 "已失效的连接请求报文段" 是这样的产生的；考虑一种正常情况，A 发出连接请求，但因连接请求报文丢失而未收到 B 的确认；于是 A 再重传一次连接请求；后来收到了 B 的确认，建立了连接；数据传输完毕后，就释放了连接；A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B ，没有 "已失效的连接请求报文段"

    现假定出现一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B；本来这是一个早已失效的报文段；但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出一次新的连接请求，于是就向 A 发出确认报文段，同意建立连接；假定不采用报文握手，那么只要 B 发出确认，新的连接就能建立

    由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据；但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据；B 的许多资源就这样白白浪费了

    采用三报文握手的办法，可以防止上述现象的发生；例如在刚才的异常情况下，A 不会向 B 的确认发出确认；B 由于收不到确认，就知道 A 并没有要求建立连接

5.9.2 TCP 的连接释放

    TCP 连接释放过程比较复杂，我们仍结合双方的状态的改变来阐明连接释放的过程；

    数据传输结束后，通信的双方都可释放连接；当前 A 和 B 都处于 ESTANLISHED 状态（图 5-29）；A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接；A 把连接释放报文段首部的终止控制位 FIN 置为 1 ，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1；这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认；请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号

    B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，这个报文段自己的序号 seq = v，等于 B 前面已传送过的数据的最后一个字节的序号加 1；然后 B 就进入 CLOSE-WAIT（关闭等待）状态；TCP 服务器进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据发送了，但 B 若发送数据，A 仍要接收；也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间

    A 收到来自 B 的确认后，就进入 FIN-WAIT-2（终止等待 2）状态，等待 B 发出的连接释放报文段

    若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接；这时 B 发出的连接释放报文段必须使 FIN = 1；现假定 B 的序号 seq = w（在半关闭状态 B 可能又发送了一些数据）；B 还必须重复上次已发送过的确认号 ack = u + 1；这时 B 就进入 LAST-ACK（最后确认）状态，等待 A 的确认

    A 在收到 B 的连接释放报文段后，必须对此发出确认；在确认报文段中把 ACK 置为 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（根据 TCP 标准，前面发送过的 FIN 报文要消耗一个序号）；然后进入到 TIME-WAIT（时间等待）状态；请注意，现在 TCP 连接还没有释放掉，必须经过时间等待计时器（TIME-WAIT timer）设置的时间 2MSL 后，A 才进入到 CLOSED 状态；时间 MSL 叫做最长报文段寿命（Maximun Segment Lifetime），RFC 793 建议设为 2 分钟，但这完全是从工程上来考虑的，对于现在的网络，MSL = 2 分钟可能太长了；因此 TCP 允许不同的实现可根据具体情况使用更小的 MSL 值；因此，从 A 进入到 TIME-WAIT 状态后，要经过 4 分钟才能进入到 CLOSED 状态，才能开始建立下一个新的连接；当 A 撤销相应的传输控制块 TCB 后，就结束了这次的 TCP 连接

为什么 A 在 TIME-WAIT 状态必须等待 2MSL 的时间呢？这有两个理由：

(1). 为了保证 A 发送的最后一个 ACK 报文段能够到达 B；这个 ACK 报文段有可能丢失，因而导致处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认；B 会超时重传这个 FIN + ACK 报文段，而 A 就能在 2MSL 时间内收到这个重传的 FIN + ACK 报文段；接着 A 重传一次确认，重新启动 2MSL 计时器；最后，A 和 B 都正常进入到 CLOSED 状态；如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段；这样，B 就无法按照正常步骤进入 CLOSED 状态 

(2). 防止 "已失效的连接请求报文段" 出现在本连接中；A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL ，就可以使本连接持续的时间内所产生的所有报文段都在网络中消失；这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段

B 只要收到了 A 发出的确认，就进入 CLOSED 状态；同样，B 在撤销相应的传输控制块 TCB 之后，就结束了这次的 TCP 连接；可以看到，B 结束 TCP 连接的时间要比 A 早一些

上述的 TCP 连接释放过程是四报文握手

除时间等待计时器外，TCP 还设有一个保活计时器（keepalive timer）；设想有这样的情况：客户已主动与服务器建立了 TCP 连接，但后来客户端的主机突然出故障；显然，服务器之后就不能再收到客户发来的数据；因此，应当有措施使得服务器不要再白白等下去，这就是使用保活计时器；服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时；若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔 75 秒钟发送一次；若一连发送 10 个探测报文段后仍无客户的响应，服务器就认为客户端出现了故障，接着就关闭这个连接

5.9.3 TCP 的有限状态机

为了更清晰地看出 TCP 连接的各种状态之间的关系，图 5-30 给出了 TCP 的有限状态机；图中每一个方框即 TCP 可能具有的状态；每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名；状态之间的箭头表示可能发生的状态变迁；箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作；

请注意图中有三种不同的箭头，粗实线交投表示对客户进程的正常变迁，粗虚线箭头表示对服务器进程的正常变迁，另一种细线箭头表示异常变迁

我们可以把图 5-30 和前面的图 5-28 、图 5-29 对照起来看；在图 5-28 和图 5-29 中左边客户进程从上到下的状态变迁，就是图 5-30 中粗实线箭头所指的状态变迁；而在图 5-28 和图 5-29 右边服务器进程从上到下的状态变迁，就是图 5-30 中粗虚线箭头所指的状态变迁

还有一些状态变迁，例如连接建立过程中的从 LISTEN 到 SYN-SENT 和从 SYN-SENT 到 SYN-RCVD