[计算机网络]第五章 运输层

[计算机网络]第五章 运输层

学习使用工具

HillZhang的计算机网络复习笔记 https://hillzhang1999.gitee.io/2020/05/22/ji-suan-ji-wang-luo-quan-bu-fu-xi-bi-ji/

《计算机网络》谢希仁

1. 运输层的功能

运输层向它上面的应用层提供通信服务，负责互联网内任意两台主机上的进程（应用程序）之间的数据传输（不是分组传输，网络层才有分组）。它属于面向通信部分的最高层，同时也是用户功能中的最低层。

只有位于网络边缘部分的主机的协议栈才有运输层。而网络核心部分中的路由器在转发分组时都只用到下三层的功能。运输层与网络层的区别在于：运输层为主机上的进程间提供数据传输服务，而网络层为主机提供分组传输服务。

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

运输层有一个很重要的功能，即复用和分用。复用指在发送方不同的应用进程都可以使用同一个运输层协议传送数据，分用指接收方在剥去报文的首部后能够把这些数据交付正确的目的应用进程。

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

解决这个问题的方法就是在运输层使用协议端口号，简称端口。这就是说，虽然通信的终点是应用进程，但只要把所传送的报文交到目的主机的某个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP或UDP来完成。这种在协议栈层间的抽象的协议端口是软件端口。在路由器或交换机上的端口是硬件端口。

• 端口用一个 16 位端口号（0到65535）进行标志。
• 端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。
• 在互联网中，不同计算机的相同端口号是没有联系的。
• 由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的 IP 地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。

服务器端进程一般保持使用确定的端口号，方便客户端进程请求和使用。而客户端进程的端口号不确定，可以随时改变。

• 服务器端

  • 熟知端口号

    

  • 登记端口号

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

• 客户端

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

2.用户数据报协议UDP

无连接，不可靠，协议数据单元为用户数据报。可靠性差，但传输效率好，实时性好。适用于只对数据传输的实时性要求较高，但对传输质量要求低的场景，如在线语音、视频聊天等。

在传送数据之前不需要先建立连接。发送完数据后，不需要接到对方的确认。

虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式（例如流式媒体运输，如视频电话等）。应用进程本身可以在不影响应用的实时性前提下，采取一些措施提高UDP的可靠性，如向前纠错或重传报文。常用UDP的应用和应用层协议：DNS、TFTP、RIP、DHCP、SNMP、NFS、IGMP等。

UDP 只在 IP 的数据报服务之上增加了很少一点的功能，即复用和分用的功能及差错检测的功能。

UDP的特点：

1. UDP 是无连接的，发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
2. UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
3. UDP 是面向报文的。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文。
4. UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信（如IP电话、视频会议）的要求。 （但是，如果多个源主机上的进程使用UDP同时向网络发送实时视频流时，可能导致拥塞）
5. UDP 支持一对一、一对多、多对一和多对多的交互通信，而TCP不支持广播和多播。
6. UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。
7. 面向报文：UDP交付和接收的单位是一个报文，不会对报文进行分段。所以采用UDP发送的报文段需要长度适中。

UDP首部有8个字节，此外还需要12字节的伪首部，作用是用于计算检验和。伪首部不向上传送也不向下递交。UDP计算检验和的方法与IP数据报基本相同，唯一的区别在于UDP把首部（包含伪首部）和数据部分一起检验。

3.传输控制协议TCP

有连接，可靠，协议数据单元为TCP报文段。传输效率低，实时性差，但可靠性高，适用于对数据传输的质量有较高要求，但对实时性要求不高的场景，如传输文件（HTTP、HTTPS、FTP）、发送邮件（SMTP）、远程登录（SSH、TELNET）等协议。需要先建立连接。对方收到TCP报文段后需要给出确认。每条TCP链接只能是点对点的，因此TCP不提供广播或多播服务。TCP 提供全双工通信。

由于 TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销， 如确认、流量控制、计时器以及连接管理等 。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。（用户数据报的首部仅为8个字节，而TCP报文段的首部为20到60个字节）。

TCP特点：

1. TCP 连接是一条虚连接而不是一条真正的物理连接。
2. TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。
3. TCP 根据对方给出的窗口值（流量控制）和当前网络拥塞的程度（拥塞控制）来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。TCP 可把太长的数据块划分短一些再传送，也可等待积累有足够多的字节后再构成报文段发送出去。
4. 面向字节流：
   1. TCP 中的“流”指的是流入或流出进程的字节序列。
   2. “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。TCP可以对报文的字节流进行分段形成报文段，而UDP不对报文进行分段。
   3. TCP不保证数据块的一致性，但保证数据块中的字节流的一致性。
5. TCP 把连接作为最基本的抽象，每一条 TCP 连接有两个端点（套接字）。TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。TCP 连接的端点叫做套接字socket或插口。端口号拼接到IP 地址即构成了套接字，即套接字 socket = （IP地址 : 端口号）

• TCP报文段首部

  

  TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 n是整数。因此 TCP 首部的最小长度是 20 字节。最长为60字节。（与IP数据报的首部类似）

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

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

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

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

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

  紧急 URG —— 当 URG=1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送相当于高优先级的数据相当于高优先级的数据。 例如，向远程主机发送Control+c的中断命令。

  确认 ACK（注意大小写，大写为确认位，小写为确认号） —— 只有当 ACK=1 时确认号字段才有效。当 ACK=0 时，确认号无效。 例如，停止等待协议的确认分组。

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

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

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

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

  窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。指的是发送本报文段的一方的接收窗口。（发送方的发送窗口应小于等于拥塞窗口cnwd和接收方的接收窗口中的最小值）

  检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。（和UDP基本类似，但伪首部略有区别）

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

  选项字段——长度可变。

  • 最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”MSS 与接收窗口值没有关系。若选择较小的 MSS 长度，网络的利用率就降低。MSS 应尽可能大些，最佳的 MSS 是很难确定的
  • 窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 16+S，相当于把窗口值向左移动 S 位后获得实际的窗口大小。
  • 时间戳选项——占 10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节）。
  • 选择确认选项

  填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

理想传输条件的特点包括：传输信道不产生差错、不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

TCP为了实现可靠传输，使用确认机制+重传机制。可靠传输协议常称为自动重传请求 ARQ 。意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。

• 停止等待协议

  每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。如果在规定时间内没有收到确认，那么需要进行超时重传。

  停止等待协议是ARQ协议的一种，十分简单，但是信道利用率很低，传输效率低，高效的ARQ协议采用流水线方式发送数据，称为连续ARQ协议，它的详细版本即滑动窗口协议。

  • 无差错

    

  • 有差错

    

  • 确认丢失

    

  • 确认迟到

    

  在发送完一个分组后，必须暂时保留已发送的分组的副本（保留在发送缓存中），以备出现问题后重发。分组和确认分组都必须进行编号（字节流中字节的序号）。超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

• 滑动窗口协议

  是一种连续ARQ协议。

  发送方维持的发送窗口，位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样信道利用率就提高了。连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

  接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示到这个分组为止的所有分组都已正确收到了。规定时间内，没有继续收到按序到达的分组，就依据当前按序到达的最后一个分组发送确认。容易实现，即使确认丢失也不必重传。但不能向发送方反映出接收方已经正确收到的所有分组的信息。当按序到达的分组中间某处发生分组丢失时，需要进行Go-back-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。

  • 选择重传：提高信道效率。（不必重传已发送成功的分组）接收方需要更大缓存。（需要将丢失分组后面序号的分组暂时保存在接收方的缓存区，等待重传的分组到达，再一起接收）
  • 回退N步：接收方缓存区小。信道效率低，需要重传正确的分组。

  TCP 的滑动窗口是以字节为单位（TCP面向字节流）的。现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节（流量控制），而确认号是 31（这表明 B 期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了）。根据这两个数据，A 就构造出自己的发送窗口(实际情况下,还需要考虑拥塞窗口)
  ​

因为是全双工通信，因此TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。总共有4个窗口，窗口的大小根据拥塞控制和流量控制动态改变。发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。接收窗口表示：接收方允许接收的字节序号。A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。

TCP连接的每一端都拥有发送缓存和接收缓存。发送缓存用来暂时存放发送应用程序传送给发送方 TCP 准备发送的数据和TCP 已发送出但尚未收到确认的数据。接收缓存用来暂时存放按序到达的、但尚未被接收应用程序读取的数据和不按序到达的数据。（选择重传）TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

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

4.TCP的流量控制与拥塞控制

• 流量控制

  利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制，让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。（点对点，使用接收窗口控制）只要不断减少接收窗口，即可降低数据发送速率。

  但这样可能会造成死锁：发送方因接收方的接收窗口为0，一直等待。此时，接收方有了一些窗口，但发送的非零窗口报文段丢失，导致双方互相等待死锁（发送方等待接收方的接收窗口大于0，而接收方等待发送方发送数据）。

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

• 拥塞控制

  在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞。简单的增加网络中的资源并不能解决拥塞问题。换句话说，就是网络中的数据量太大。拥塞控制是指防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。

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

  1. 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
  2. 拥塞控制是一个全局性（整个网络）的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
  3. 二者的共同点就是：目的都是降低数据发送速率。都是基于窗口的，接收窗口rwnd和拥塞窗口cwnd。

  TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。TCP发送方维持一个拥塞窗口 CWND 。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。所以，发送窗口大小不仅取决于接收方公告的接收窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：min（接收窗口，拥塞窗口）。

  • 慢开始

    当重传定时器超时时，说明整个网络出现了拥塞，需要重新慢开始。慢开始指由小到大逐渐增大拥塞窗口数值，每一个传输轮次对拥塞窗口进行加倍。

    初始拥塞窗口 cwnd 设置：

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

    在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS 的数值。每经过一个传输轮次，拥塞窗口就加倍。拥塞窗口的大小指数增加。

    为了防止拥塞，窗口cwnd 增长到达某一阈值ssthresh时，拥塞窗口 cwnd 就开始缓慢地增大，即每经过一个传输轮次就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。ssthresh一开始是默认的，后面根据拥塞发生时的窗口大小动态改变。

    每当慢开始阶段或者拥塞避免阶段出现了网络拥塞（确认超时）

    1. ssthresh = max（cwnd/2，2）
    2. cwnd = 1
    3. 执行慢开始算法

  • 快重传

    算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的最后一个报文段的重复确认。（原先的接收方如果收到了失序的报文段是仅仅收下而不反馈任何信息的。这样会导致无法区分到底是个别报文段因某些因素丢失了还是整个网络出现了拥塞。这样会使发送方超时，从而错误地开启慢开始算法）

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

  • 快恢复

    当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，而是报文产生了丢失，问题没有那么严重。因此现在不执行慢开始算法，而是执行快恢复算法。

    1. 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
    2. 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；（超时导致的重新慢开始，cnwd=1）
    3. 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

    

  TCP连接中，发送方发送窗口的最大值等于拥塞窗口cwnd（拥塞控制）和接收窗口rwnd（流量控制）二者的最小值。

• 超时重传时间RTO

  ARQ协议的重传机制使用的超时重传时间RTO不是固定的，而是动态变化的，往往比数据在信道中传输的平均往返时间RTT略大一些。如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大，但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。因此使用自适应算法决定超时重传时间。

• 自适应算法

  往返时间RTT：记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT。

  加权平均往返时间 RTTS：

  1. 第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。

  2. 以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS。RFC 2988 推荐的α值为 1/8，即 0.125：

     

  3. 超时重传时间 RTO：应略大于上面得出的加权平均往返时间 RTTS。RFC 2988 建议使用下式计算 RTO：

     

  4. Karn 算法：在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。

• 主动队列管理AQM

  网络层的路由器分组丢弃策略对TCP拥塞控制影响很大。当发生拥塞后，路由器将队列尾部的分组全部丢弃。这可能导致全局同步。

  全局同步：若发生了路由器中的尾部丢弃，就可能会同时影响到很多条 TCP 连接，结果使这许多 TCP 连接在同一时间突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。

  AQM是指在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。

  AQM的实现方法：RED随机早期检测。

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

  

5.TCP运输连接

TCP 是面向连接的协议，需要在客户端和服务器之间建立连接。运输连接有三个阶段：

1. 连接建立
2. 数据传送
3. 连接释放

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

• 建立连接：三次握手

  1. A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1（表明是一个连接请求报文段），并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。
  2. B 的 TCP 收到连接请求报文段后，如同意，则发回确认。B 在确认报文段中应使 SYN = 1（表明是一个连接接受报文段），使 ACK = 1（表示当前为确认请求报文段），其确认号ack = x + 1，自己选择的序号 seq = y。第二次握手是为了让客户端知道连接已经成功建立。如果没有第二次握手，假如连接建立失败，此时客户端不知情，会继续发送数据，导致出错。
  3. A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。A 的 TCP 通知上层应用进程，连接已经建立。B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。第三次握手是防止失效了的连接建立请求再次到达服务端，导致服务端试图再次建立连接，从而产生错误。所以，B建立连接时需要再次向A进行确认。

  

• 释放链接：四次挥手

  1. 数据传输结束后，通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认。
  2. B 发出确认，ACK = 1，确认号 ack = u + 1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收。
  3. 此时，从B到A这个方向的连接尚未释放，B可以发送剩余的数据给A（因为是A发起的关闭连接，所以A到B的数据必然已经传输完，但B到A的不一定）。等B发送完剩余的数据，向A发送连接释放报文段，并停止再发送。该报文段首部的 FIN = 1，ACK = 1（表示是响应的释放连接，而不是主动释放），确认号 ack = u + 1。
  4. A 收到连接释放报文段后，必须发出确认。 在确认报文段中 ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1。 此时，A在等待2MSL（最长报文寿命，RFC793中设为2min）后，彻底释放TCP连接。
  5. • 这是为了保证 A 发送的最后一个 ACK 报文段能够到达 B。即A等到2MSL后，当出现A发送的确认报文段丢失时，可以收到B超时重传报文段，从而再次确认，使连接正常释放。
     • 防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。