计算机网络（五）运输层

5.1、运输层概述

概念

进程之间的通信

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

进程之间通信流程

以上图为例：进程Ap1与Ap4之间以及进程Ap2与Ap3之间进行基于网络的通信。它们在运输层使用不同的端口，来对应不同的应用进程。然后通过网络层及其下层来传输应用层报文。接收方的运输层通过不同的端口，将收到的应用层报文，交付给应用层中相应的应用进程。

注意：此处运输层的端口是区分不同应用进程的标识符，而非物理端口。

逻辑通信：运输层之间的通信好像是沿水平方向传送数据，但事实上，这两条数据并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的

总结

5.2、运输层端口号、复用与分用的概念

为什么用端口号

IANA：因特网数字分配机构

发送方的复用和接收方的分用

发送方的某些应用程序所发送的不同应用报文，在运输层使用UDP协议进行封装，称为UDP复用，使用TCP协议进行封装，称为TCP复用。运输层使用不同的端口号区分不同的进程。无论是UDP协议封装的UDP用户数据段还是TCP协议封装的TCP报文段，它们都会在网络层使用IP协议封装成IP数据报，而这称为IP复用。

接收方的网络层收到发送方的IP数据报后进行IP分用：如果该IP数据报首部中协议字段的值为17，则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP，如果该IP数据报首部中协议字段的值为6，则把IP数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。运输层对UDP用户数据报进行UDP分用，对TCP报文段进行TCP分用，将它们交付给上层相应的应用进程

注意：IP数据报首部中协议字段的值，用来表明IP数据报的数据载荷部分封装的是何种协议数据单元：值为6表明封装TCP报文段，值为17表明封装UDP用户数据段

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

运输层传输流程

如图所示，以上主机通过交换器互连并处于同一个以太网中

现我们在用户PC中使用浏览器访问web服务器：输入域名，回车浏览。用户PC中的DNS客户端进程会发送一个DNS查询请求报文。该报文需要使用运输层的UDP协议封装成UDP用户数据报，其首部中的源端口字段的值，在短暂端口号49151~65535中挑选一个未被占用的（此处使用49152），用来表示DNS客户端进程，目的端口字段的值为53，是DNS服务器端进程所使用的熟知端口号。

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器

DNS服务器收到该IP数据报后，从中解封出UDP用户数据报。UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程。

DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址。之后DNS服务器会给用户PC发送DNS响应报文，DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报。其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号。

DNS服务器将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC

用户PC收到该数据报后，从中解封出UDP用户数据报。UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程。DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的IP地址

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文。

HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段，其首部中的源端口字段的值短暂端口号49151~65535中挑选一个未被占用的（此处使用49152），用来表示HTTP客户端进程，目的端口字段的值为80，是HTTP服务器端进程所使用的熟知端口号。

之后，将TCP报文段封装在IP数据报中，通过以太网发送给Web服务器

DWeb服务器收到该IP数据报后，从中解封出TCP用户数据报TCP首部中的目的端口号为80，这表明应将该TCP报文段的数据载荷部分，也就是HTTP请求报文，交付给本服务器中的HTTP服务器端进程。

HTTP服务器端进程解析HTTP请求报文的内容，然后按其要求查找首页内容。之后Web服务器会给用户PC发送HTTP响应报文，其内容是HTTP客户端所请求的首页内容。HTTP响应报文需要使用运输层的TCP协议封装成TCP报文段。其首部中的源端口字段的值设置为熟知端口号80，表明这是DNS服务器端进程所发送的TCP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送HTTP请求报文的HTTP客户端进程所使用的短暂端口号。

之后将TCP报文段封装在IP数据报中，通过以太网发送给用户PC

用户PC收到该数据报后，从中解封出TCP报文段。TCP首部中的目的端口号为49152，这表明应将该TCP报文段的数据载荷部分，也就是HTTP响应报文，交付给用户PC中的HTTP客户端进程。HTTP客户端进程解析HTTP响应报文的内容，并在网页浏览器中进行显示。这样我们就可以在网页浏览器中看到Web服务器所提供的首页内容了

5.3、UDP和TCP的对比

概念

UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议
当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。
当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道。

可靠信道与不可靠信道

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。
TCP 传送的数据单位协议是 TCP 报文段(segment)。
UDP 传送的数据单位协议是 UDP 报文或用户数据报。

使用UDP协议的双方，可以随时发送数据。

三报文握手和四报文挥手属于TCP的连接管理，实现较为复杂。

UDP的通信是无连接的，不需要套接字（Socket）

TCP是面向连接的，TCP之间的通信必须要在两个套接字（Socket）之间建立连接

注意：此处的连接依然是指逻辑连接关系，而非物理连接

用户数据报协议UDP（User Datagram Protocol）

其中任何一台主机都可以向其他三台主机发送广播，也可以向某个多播组发送多播，还可以发送单播，也就是说UDP支持一对一，一对多，以及一对全的通信

发送方的应用进程将应用层报文交付给运输层的UDP，UDP给每个应用层报文添加一个UDP首部使之成为UDP用户数据报，然后发送。接收方的UDP收到UDP用户数据报后，去掉UDP首部，将应用层报文交付给应用进程

UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。换句话说，UDP是面向应用报文

发送方给接收方发送UDP用户数据报，若传输过程中用户数据报受到干扰而产生误码，接收方UDP可以通过该数据报首部中的校验和字段的值检查出产生误码的情况并丢失该数据报。

发送方给接收方发送UDP用户数据报，如果该数据报被因特网中的某个路由器丢弃了，发送方UDP不做任何处理

传输控制协议TCP（Transmission Control Protocol）

使用TCP协议的通信双方，在进行数据传输之前，必须使用三报文握手建立TCP连接

TCP连接建立成功后，通信双方之间就好像有一条可靠的通信信道，通信双方使用这条基于TCP连接的可靠信道进行通信

很显然，TCP仅支持单播，也就是一对一的通信

发送方

TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP并不知道这些待传送的字节流的含义，仅将他们编号，并存储在自己发送缓存中
TCP会根据发送策略，从发送缓存中提取一定量的字节构建TCP报文并发送

接收方

TCP一方面从所接收到的TCP报文段中，取出数据载荷部分并存储在接收缓存中，一方面将接收缓存中的一些字节交付给应用进程

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

接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

本图只画了一个方向的数据流，在实际网络中，基于TCP连接的两端，可以同时进行TCP报文段的发送和接收

使用TCP连接的双方基于TCP连接的可靠通道使用数据传输，不会出现误码，丢失，乱序以及重复等传输差错

TCP结构

总结

5.4、TCP的流量控制

概念

假设主机a发送的每100字节数据都封装成TCP报文段，b的接收窗口为400个字节数据，因此主机a的发送窗口也设置为400。主机a在未收到主机b发来的确认时，可将落入发送窗口中的全部数据发送出去

seq是tcp报文段首部中的序号字段取值，值为1表示tcp报文段数据载荷第一个字节序号为1。

date表示该数据是tcp数据报文段。

ACK表示tcp报文段首部中的标志位，值为1表示这是一个tcp确认报文段。。

ack表示tcp报文段首部中的确认号字段，值为201表示序号201之前的数据已全部接收，先希望收到序号201及其后续数据。

rwnd是报文段首部中的窗口字段，取值300表示自己的接收窗口大小为300

流量控制是根据网络波动调节的

由于主机b在该累计确认中已将自己的接收窗口调整了300，因此主机a相应的把自己的发送窗口也调整为300。

主机a收到201之前的数据的累计确认后，将发送窗口向前滑动，使已发送并收到确认的这些数据的序号移除发送窗口并将1~200的字节数据全部删除。

在上图中201-300是已发送数据，当重传计时器超时，它们仍会被重传。

当201-500的重传计时器超时时，主机a将其重新封装成一个TCP报文段发送出去，暂时不能发送新数据

在上图的最后，主机b向主机a发送零窗口通知

为解决该问题，TCP为每一个连接设置一个持续计时器。

如上图所示：主机a收到了收到主机b的零窗口通知，就启动持续计时器。当持续计时器超时，主机a发送一个零窗口探测报文，主机b收到探测报文段后发送包含其接收窗口值的确认报文。如果该值仍为0，主机a收到该报文段重新启动持续计时器。如果该值不为0，则打破死锁的局面

主机a发送的零窗口探测报文段后，启动重传计时器。当零窗口探测报文段丢失后，主机b无法收到该报文，因此主机a也无法收到确认报文，此时重传计时器就会超时，零窗口探测报文段会被重传

注意：TCP规定：即使接收窗口为0，主机也必须接收零窗口探测报文段，确认报文段以及携带紧急数据的报文段

习题

主机甲收到确认后，先滑动发送窗口再调整发送窗口

总结

5.5、TCP的拥塞控制

概念

理想的拥塞控制：当输入负载达到某一限度时，由于网络资源受限，吞吐量不再增长，达到饱和。此时加大输入负载，则会损失数据

无拥塞控制：在未达到吞吐量饱和前，就有部分输入分组被丢弃。当网络吞吐量明显小于理想吞吐量时，网络进入轻度拥塞状态。当输入负载达到某一数值时，网络吞吐量随输入负载增大而降低，进入拥塞状态直到死锁

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

1.点缓存的容量太小；

2.链路的容量不足；

3.处理机处理的速率太慢；

4.拥塞本身会进一步加剧拥塞；

拥塞控制的一般原理

1.拥塞控制的前提：网络能够承受现有的网络负荷。

2.实践证明，拥塞控制是很难设计的，因为它是一个动态问题。

3.分组的丢失是网络发生拥塞的征兆而不是原因。

4.在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制和闭环控制

监测网络的拥塞

主要指标有：

1.由于缺少缓存空间而被丢弃的分组的百分数；

2.平均队列长度；

3.超时重传的分组数；

4.平均分组时延；

5.分组时延的标准差；

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

拥塞控制的算法

真正的发送窗口值 = Min (接收方窗口值，拥塞窗口值)

传输轮次：

1.发送方给接收方发送数据报文段后，接收方给发送方发发回相应的确认报文段

2.一个传输轮次所经历的时间其实就是往返时间，往返时间并非是恒定的数值

3.使用传输轮次是为了强调拥塞窗口把允许发送的报文段都连续发送出去，并收到了对已发送的最后一个报文段的确认

拥塞窗口（cwnd）：

1.初始拥塞窗口值：2 种设置方法，窗口值逐渐增大。

2 至 4 个最大报文段（RFC 5681
1 至 2 个最大报文段（旧标准）

2.拥塞窗口会随网络拥塞程度，以及所使用的拥塞控制算法动态变化

3.拥塞窗口值是多少发送方就可以发送多少个数据报文段

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

接下来我们将以一个完整的数据传输过程来讲解慢开始和拥塞避免算法

慢开始（slow-start）

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

算法的思路：由小到大逐渐增大拥塞窗口数值。发送方每收到一个新报文段的确认，拥塞窗口值加一，然后开始下一轮的传输。

接下来我们将举一个具体的例子，在本例中，发送方初始拥塞窗口值为1

如上图所示发送方收到了一个确认报文，因此拥塞窗口加一

经过四个传输轮次后，拥塞窗口值等于慢开始门限值，开始拥塞避免算法

拥塞避免（congestion avoidance）

思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
每经过一个传输轮次，拥塞窗口加一，使拥塞窗口 cwnd 按线性规律缓慢增长。
在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

如图所示，每经过一次传输轮次后，拥塞窗口就会加一

如果在发送过程中出现部分报文段丢失，这必然会造成发送方对这些丢失报文段的超时重传

此时重新从慢开始算法开始，并将慢开始门限值调整为了发送拥塞时拥塞窗口的一半

当拥塞窗口值等于慢开始门限值时，开始拥塞避免算法

两个算法完整示意图

快重传和快恢复

快重传（fast retrasmit）

如上图所示：接收方发现自己接收到的报文段M4不是依序达到的报文段时，就会向发送方再次发送重复确认报文段M3以告诉发送方发送丢失的报文段。当该行为连续发生三次以后，发送方就会立刻重传丢失的报文段M3。当接收方收到丢失的报文段M3时，发送最后接收到的报文段M6的确认报文段，以告知发送方报文段M6之前的报文段已正常接收。此时便不会造成发送方对M3的超时重传了

快恢复（fast recovery）

改进后的整体算法的示意图

习题

5.6、TCP超时重传时间的选择

如果超时重传时间RTO的值设置得比RTT0的值小很多，这可能会造成发送方未收到确认报文段时超时重传器就超时了，然后发生不必要的重传，使网络负荷增大

如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率

TCP可以通过某次测量的RTT计算出一个相对合理的RTO

由于TCP下层是复杂的互联网环境，因此每次数据传输的RTT都可能不同，单次RTT计算得出的RTP可能并不准确，这会造成发送方不必要的超时重传，所以TCP会根据每次的RTT计算更新RTP

RFC6298建议使用下式计算超时重传时间RTO

往返时间RTT的测量比较复杂

TCP超时重传的计算

总结

5.7、TCP可靠传输的实现

本节以一个具体的例子去描述TCP可靠传输的实现

不推荐的原因：发送方在收到向后收缩的通知前，可能发送了窗口中的很多数据，此时在收缩窗口不允许发送这些数据就会发送错误

比如：发送方在收到收缩通知时，已经发送了31-41的数据但未收到确认报文并且发送窗口位置也没有改变，此时将窗口调整到了31-35，就会发生错误，无法描述发送窗口的状态

因此TCP使用了三个指针P1,P2,P3分别指向相应的字节序号，通过相关计算便可确认发送窗口的状态了

发送方向接收方发送31-41的报文段，由于31报文段各种异常原因，接收方首先收到了32-33的报文段，由于该报文段落在接收窗口，所以接收方依然将其存入接收缓存中。

由于接收方只能对按序到达的报文段发送确认报文，因此接收方向发送方发送31号确认报文。当发送方收到31号的重复确认时，就知道接收方收到了未按序达到的数据。由于这是第一次重复确认，因此不会引起快重传

注意：运输层的ack表示希望收到的报文段而非数据链路层的ack

此时接收方收到了发送方发送的数据报文段31，将其存入接收缓存。接收方将31-33的数据报文段交付给应用进程，并移动三个接收窗口

现在接收方收到了37,38,40的数据报文段并发送给发送方确认报文段，虽然37,38,40落在接收窗口，但它们都是未按序到达的数据只能暂存在接收缓存中

此时发送方收到确认报文

此时发送方又发送了42-53的报文段，发送窗口数据发送完毕。

习题

5.8、TCP的运输连接管理

概念

TCP的连接建立

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

TCP的连接建立要解决以下三个问题

TCP使用“三报文握手”建立连接

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

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

如下为三次握手的过程

最初两端的TCP进程都处于关闭状态

TCP服务器首先建立传输控制块用来存储TCP连接中的一些重要信息，之后进入监听状态被动等待客户端进程的连接请求

TCP服务器进程被动发起TCP连接建立的过程称为被动动打开连接

注意：TCP客户进程也是先创建传输控制块，后建立TCP连接

当TCP客户进程向TCP服务器进程主动发送TCP连接请求报文段时，进入同步已发送状态。

TCP客户进程主动发起TCP连接建立的过程称为主动打开连接

TCP连接请求报文段首部中

同步位SYN被设置为1，表明这是一个TCP连接请求报文段

序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号

请注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

TCP连接请求确认报文段首部中

同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段

序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号

确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号（seq）的确认

请注意：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态

普通的TCP确认报文段首部中

确认位ACK被设置为1，表明这是一个普通的TCP确认报文段

序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，所以TCP客户进程发送的第二个报文段的序号为x+1

确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认

请注意：TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号

TCP服务器进程收到该确认报文段后也进入连接已建立状态

现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接，进行可靠的数据传输

三报文握手是否多余，我们通过一个“两报文握手”实例进行观察

当TCP客户进程发送一个TCP连接请求报文段后，该报文段由于各种原因导致在某网络节点长时间滞留，此时TCP客户进程对该报文段超时重传。

TCP服务进程正常接收新的报文段并向TCP客户进程发送TCP确认报文段，之后进入连接已建立状态。

TCP客户进程收到TCP确认报文段后进入TCP连接已建立状态。

此时客户进程和服务器进程可以进行数据传输，之后通过四报文挥手释放连接并进入关闭状态。

一段时间以后，原本滞留的TCP连接请求报文段到达TCP服务器进程，TCP服务器进程会错误的再次进入连接已建立状态并向TCP客户进程发送TCP确认报文段，但TCP客户进程并不理睬，因此这必然造成服务器进程的资源浪费

因此三报文握手是为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误

习题

总结

TCP的连接释放

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

TCP通过“四报文挥手”来释放连接

TCP 连接的建立采用客户服务器方式。
主动发起连接建立的应用进程叫做TCP客户 (client)。
被动等待连接建立的应用进程叫做TCP服务器 (server)。
任何一方都可以在数据传送结束后发出连接释放的通知

过程

现在TCP客户进程和TCP服务器进程都处于连接已建立状态

TCP客户进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态

TCP连接释放报文段首部中

终止位FIN和确认为ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认

序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1

确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1

请注意：TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态

普通的TCP确认报文段首部中

确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段

序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配

确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认

TCP服务器进程通知高层应用进程，TCP客户进程要断开与自己的TCP连接。这时从TCP客户进程到TCP服务器进程这个方向的连接就释放了，此时TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了，该状态可能持续一段时间。

但如果TCP服务器进程还有数据要发送，TCP客户进程仍要接收，也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭

TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段

若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接

由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接

TCP服务器进程发送TCP连接释放报文段并进入最后确认状态

该报文段首部中

终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认

序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送一些数据

确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态

该报文段首部中

确认为ACK的值被设置为1，表明这是一个普通的TCP确认报文段

序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号

确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认

TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要进过2MSL后才能进入关闭状态

2MSL时长的时间等待里，TCP客户端没有收到来自TCP服务器进程的确认报文段就说明TCP服务器收到了TCP确认报文段而没有超时重发，并且在2MSL时间后，本次连接释放而存在的报文段全部消失不再影响下一次连接释放

如果TCP客户进程没有时间等待而直接处于关闭状态，TCP服务器进程就会因为迟迟收不到确认报文段而超时重发无法进入CLOSE状态，因此时间等待很有必要