计算机网络知识点（运输层）

重要内容

运输层的作用

端口和套接字的意义

无连接的UDP的特点

面向连接的TCP的特点

在不可靠网络上实现可靠传输的原理

TCP的滑动窗口，流量控制，拥塞控制和连接管理

5.1 运输层协议概述

5.1.1 进程间的通信

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

两个主机进行通信实际上就是两个主机中的应用进程互相通信，应用进程之间的通信又称为端到端的通信。运输层的一个很重要的功能就是复用和分用，应用层不同进程的报文通过不同的端口向下交到运输层，再往下就共用网络层提供的服务。

运输层向用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），运输层提供应用进程间的逻辑通信。逻辑通信的意思是：运输层之间的通信好像是沿水平方向传送数据，但事实上这两个运输层之间并没有一条水平方向的物理连接。

当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的（只提供尽最大努力交付），但这种逻辑通信信道就相当于一条全双工的可靠信道。当运输层采用无连接的UDP协议时，这种逻辑通信信道就是一条不可靠信道。

5.1.2 运输层的两个主要协议

TCP/IP的运输层有两个不同的协议：

• 用户数据报协议UDP（User Datagram Protocol）
• 传输控制协议TCP（Transmission Control Protocol）

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU（Transport Protocol Data Unit）：

• TCP传送的数据单位协议是TCP报文段。
• UDP传送的数据单位协议是UDP报文或用户数据报。

UDP在传送数据之前不需要先建立连接，对方的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP是一种最有效的工作方式。TCP则提供面向连接的服务，TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

5.1.3 运输层的端口

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

解决上述问题的方法就是在运输层使用协议端口，或通常简称为端口。端口是指软件端口，是应用层的各种协议进程与运输实体进行层间交互的一种地址。

虽然通信的终点是应用进程，但我们可以把端口想象是通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP来完成。

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

三类端口：

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

5.2 用户数据报协议UDP

5.2.1 UDP概述

UDP只在IP的数据报服务之上增加了很少ー点的功能，即端口的功能和差错检测的功能。虽然UDP用户数据报只能提供不可靠的交付，但UDP在某些方面有其特殊的优点。

UDP的主要特点：

• UDP是无连接的，即发送数据之前不需要建立连接。
• UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
• UDP是面向报文的。UDP没有拥塞控制，很适合多媒体通信的要求。
• UDP支持一对一、一对多、多对一和多对多的交互通信。（支持多播）
• UDP的首部开销小，只有8个字节。

发送方UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文，所以应用程序必须选择合适大小的报文。

5.2.2 UDP的首部格式

用户数据报UDP有两个字段：数据字段和首部字段，首部字段有8个字节，由4个字段组成，每个字段都是两个字节。在计算检验和时，临时把伪首部和UDP用户数据报连接在一起，伪首部仅仅是为了计算检验和。

5.3 传输控制协议TCP

5.3.1 TCP最主要的特点

TCP的主要特点：

• TCP是面向连接的运输层协议。
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）。
• TCP提供可靠交付的服务。
• TCP提供全双工通信。
• 面向字节流。

TCP面向流的概念：

TCP连接是一条虚连接而不是一条真正的物理连接。TCP对应用进程一次把多长的报文发送到TCP的缓存中是不关心的，TCP根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用进程给出的）。TCP可把太长的数据块划分短一些再传送，TCP也可等待积累有足够多的字节后再构成报文段发送出去。

5.3.2 TCP的连接

TCP把连接作为最基本的抽象，每一条TCP连接有两个端点。TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口，TCP连接的端点叫做套接字（socket）或插口。

端口号拼接到IP地址即构成了套接字，即套接字socket=（IP地址：端口号）。

5.4 可靠传输的工作原理

5.4.1 停止等待协议

停止等待就是每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组。

A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，这就叫做超时重传。要实现超时重传，就要在每发送一个分组时设置一个超时计数器，在发送完一个分组后，必须暂时保留已发送的分组的副本，分组和确认分组都必须进行编号，超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信，这种可靠传输协议常称为自动重传请求ARQ（Automatic Repeat reQuest）。ARQ表明重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。

停止等待协议的优点是简单，但缺点是信道利用率太低，如下所示：

发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认，由于信道上一直有数据不间断地传送，这种传输
方式可获得很高的信道利用率。

5.4.2 连续ARQ协议

累计确认：接收方一般采用累积确认的方式，即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示到这个分组为止的所有分组都已正确收到了。累积确认的优点是容易实现，即使确认丢失也不必重传，缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。

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

TCP可靠通信的具体实现：

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

5.5 TCP报文段的首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段，一个TCP报文段分为首部和数据部分两部分：

各字段的意义：

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

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

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

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

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

• 紧急URG：当URG=1时，表明紧急指针字段有效，它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）。

• 确认ACK：只有当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。

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

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

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

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

• 窗口字段：占2字节，用来让对方设置发送窗口的依据，单位为字节。

• 检验和：占2字节，检验和字段检验的范围包括首部和数据这两部分，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。

• 紧急指针字段：占16位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

• 选项字段：长度可变，TCP最初只规定了一种选项，即最大报文段长度MSS，MSS告诉对方TCP：我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。此外，还有以下选项：

  1、窗口扩大选项：占3字节，其中有一个字节表示移位值S，新的窗口值等于TCP首部中的窗口位数增大到（16+S），相当于把窗口值向左移动S位后获得实际的窗口大小。

  2、时间戳选项：占10字节，其中最主要的字段时间戳值字段（4字节）和时间戳回送回答字段（4字节）。

  3、选择确认选项：在后面将详细介绍。

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

5.6 TCP可靠的传输实现

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

根据B给出的窗口值，A构造出自己的发送窗口：

A发送了11个字节的数据：

A收到新的确认号，发送窗口向前滑动：

A的发送窗口内的序号都已用完，但还没有再收到确认，必须停止发送：

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

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

5.6.2 超时重传时间的选择

重传机制是TCP中最重要和最复杂的问题之一，TCP每发送一个报文段，就对这个报文段设置一次计时器，只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。由于TCP的下层是一个互联网环境，IP数据报所选择的路由変化很大，因而运输层的往返时间的方差也很大。

加权平均往返时间RTTS：

超时重传时间RTO：

往返时间的测量相当复杂，当TCP报文段1没有收到确认，重传（即报文段2）后，收到了确认报文段ACK。如何判定此确认报文段是对原来的报文段1的确认，还是对重传的报文段2的确认？使用Karn算法：在计算加权平均RTTS时，只要报文段重传了，就不再采用其往返时间样本，这样得出的加权平均RTTS和RTO就较准确。

修正的Karn算法：

5.6.3 选择确认SACK

接收方收到了和前面的字节流不连续的两个字节块，如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

注意：

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

5.7 TCP的流量控制

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

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

原理：

• 接收端将自己可以接收的缓冲区大小放入TCP首部中的窗口大小字段，通过ACK字段通知发送端。窗口大小字段越大，说明网络的吞吐量越高。
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接受到这个窗口之后，就会减慢自己的发送速度。
• 如果接收端缓冲区满了，就会将窗口置为0，这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

A向B发送数据，在连接建立时，B告诉A：我的接收窗口是rwnd=400，因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

从上图中可以看出，B进行了三次流量控制，第一次把窗口减少到rwnd=300，第二次又减到了rwnd=100，最后减到rwnd=0，即不允许发送方再发送数据了（这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止）。

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

5.7.2 TCP的传输效率

可以用不同的机制来控制TCP报文段的发送时机：

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

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，产生拥塞。若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制与流量控制的关系：

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

拥塞控制是很难设计的，因为它是一个动态的问题，当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失，但分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因，这点应特别引起重视。

5.8.2 TCP拥塞控制的方法

慢开始和拥塞避免
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。

发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去，但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

慢开始算法：在主机刚刚开始发送报文段时可先设置拥塞窗口cwnd=1，即设置为一个最大报文段MSS的数值。在每收到一个对新的报文段的确认后，将拥塞窗口加1，即增加一个MSS的数值。用这样的方法逐步增大发送端的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。

使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd就加倍。一个传输轮次所经历的时间其实就是往返时间RTT，传输轮次更加强调把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口cwnd=4，这时的往返时间RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认总共经历的时间。

另外，慢开始的慢并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量，慢开始门限ssthresh的用法如下：

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

拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2），然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

如上图所示，用具体数值说明了上述拥塞控制的过程，假设发送窗口的大小和拥塞窗口一样大：

• 为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。当TCP连接进行初始化时，把拥塞窗口cwnd置为1，慢开始门限的初始值设置为16个报文段，即cwnd=16。
• 在执行慢开始算法时，拥塞窗口cwnd的初始值为1，以后发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值另1，然后开始下一轮的传输（图中横坐标为传输轮次），因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时（即当cwnd=16时），就改为执行拥塞控制算法，拥塞窗口按线性规律增长。
• 假定拥塞窗口的数值增长到24时，网络出现超时（这很可能就是网络发生拥塞了），更新后的ssthresh值变为12（即变为出现超时时的拥塞窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时间增加一个MSS的大小。

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

快重传和快恢复
快重传算法：要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。

接收方收到了M1和M2后都分别发出了确认，现在假定接收方没有收到M3但接着收到了M4，显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6，接收方收到这两个报文后，也还要再次发出对M2的重复确认，这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

与快重传配合使用的还有快恢复算法，其过程有以下两个要点：

• 当发送方连续收到三个重复确认，就执行乘法减小算法，即把慢开始门限ssthresh减半，这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。
• 由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（加法增大），使拥塞窗口缓慢地线性增大。

上图给出了快重传和快恢复的示意图，在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用，采用这样的拥塞控制方法使得TCP的性能有明显的改进。

接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方，接收窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口rwnd，故发送方窗口的上限值=Min[rwnd, cwnd]：

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

5.8.3 随机早期检测RED

上面讨论的TCP拥塞控制并没有和网络层采取的策略联系起来，其实，它们之间是有着密切的关系。例如，假定一个路由器对某些分组的处理时间特别长，那么这就可能使这些分组中的数据部分（即TCP报文段）经过很长时间才能到达终点，结果引起发送方对这些报文段的重传，根据上面所讲的，重传会使TCP连接的发送端认为在网络中发生了拥塞，于是在TCP的发送端就采取了拥塞控制措施，但实际上网络上并没有发生拥塞。

路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降低到很小的数值。更为严重的是，在网络中通常有很多的TCP连接（它们有不同的源点和终点），这些连接中的报文段通常是复用在网络层的IP数据报中传送。在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条TCP连接，结果就使这许多的TCP连接在同一时间突然都进入到慢开始状态。这在TCP的术语中称为全局同步，全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。

为了避免发生网络中的全局同步现象，可以在路由器采用随机早期检测RED的措施：使路由器的队列维持两个参数，即队列长度最小门限TH_min和最大门限TH_max，对每一个到达的数据报都先计算平均队列长度L_AV：

• 若平均队列长度小于最小门限TH_min，则将新到达的数据报放入队列进行排队。
• 若平均队列长度超过最大门限TH_max，则将新到达的数据报丢弃。
• 若平均队列长度在最小门限TH_min和最大门限TH_max之间，则按照某一概率p将新到达的数据报丢弃。

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

5.9 TCP的运输连接管理

运输连接就有三个阶段，即连接建立、数据传送和连接释放，运输连接的管理就是使运输连接的建立和释放都能正常地进行。连接建立过程中要解决以下三个问题：

• 要使每一方能够确知对方的存在。
• 要允许双方协商一些参数（如最大报文段长度，最大窗口大小，服务质量等）。
• 能够对运输实体资源（如缓存大小，连接表中的项目等）进行分配。

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

5.9.1 TCP的连接建立

TCP三次握手过程描述：

• A主动打开连接，B被动打开连接并处于LISTEN状态，等待客户的连接请求。
• 第一次握手：A向B发出连接请求报文段（这时TCP报文首部中的同部位SYN=1，同时选择一个初始序号seq=x），此时A处于SYN-SENT（同步已发送）状态。
• 第二次握手：B收到连接请求报文段后，如同意建立连接，则向A发送确认（在确认报文段中应将SYN和ACK位都置1，确认号ack=x+1，同时给自己选择一个初始序号seq=y），此时B进入SYN-RCVD（同步收到）状态。
• 第三次握手：客户端A收到B的确认后，还要向B给出确认（确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1），这时TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。
• 当B收到A的确认后，也进入ESTABLISHED（已建立连接）状态。

为什么要进行第三次握手，这主要是为了防止已失效的连接请求报文突然又传送到了B，因而产生错误：

• 所谓已失效的连接请求报文段是这样产生的，考虑一种正常情况，A发出连接请求，但因连接请求丢失而未收到确认。于是A再次重传一次连接请求，后来收到了确认建立了连接，数据传输完毕后，就释放了连接。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都处于ESTABLISHED（已建立连接）状态。A先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接（这时TCP报文首部中的终止控制位FIN=1，其序号seq=u，它等于前面传输过的数据的最后一个字节的序号加1），这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
• 第二次挥手：B接收到连接释放报文段后立即发出确认（确认号是ack=u+1，而这个报文段自己的序号为u，等于B前面已传输过的数据的最后一个字节的序号加1），然后B就进入CLOSE-WAIT（关闭等待）状态。此时从A到B这个方向的连接就释放了，这是的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。
• A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段（在这之前还需要接受服务器发送的最后的数据。
• 第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文（FIN=1，ACK=1，ack=u+1，由于在半关闭状态，服务器可能又发送了一些数据，假定此时的序列号为w，seq=w），此时服务器就进入LAST-ACK（最后确认）状态，等待客户端的确认。
• 第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认（ACK=1，ack=w+1，而自己的序列号为seq=u+1），此时客户端就进入TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须等待2MSL（最大报文生存时间）的时间后，A才进入CLOSED状态。
• 而服务器在收到客户端发出的确认之后立即进入CLOSED状态，结束这次TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么A在TIME-WAIT（时间等待）状态必须等待2MSL（最大报文生存时间）的时间：

• 为了防止这种情况：A接到B的释放连接请求后会发送一个确认信息，但是如果这个确认信息丢了，也就是B没有收到确认释放连接，那么B就会重发一个释放连接请求，这时候A还处于TIME_WAIT状态，所以会再次发送一个确认信息。
• 防止已经失效的连接请求报文段出现在本连接中。A在发送完最后一个ACK报文段并经过2MSL，会使本次连接持续时间内所有产生的报文段消失，保证在下一次新连接中不会出现旧连接遗留的请求报文段。

5.9.3 TCP的有限状态机

红色箭头表示对客户进程的正常变迁，蓝色虚线箭头表示对服务器进程的正常变迁，其他细线箭头表示异常变迁：