408计算机网络知识点——第五章 运输层

注：内容参考湖科大教书匠《深入浅出计算机网络》

运输层概述

进程间基于网络的通信

计算机网络体系结构中的物理层、数据链路层和网络层，它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。

然而在计算机网络中实际进行通信的真正实体，是位于通信两端主机中的进程。

运输层的主要任务是为运行在不同主机上的应用进程提供直接的逻辑通信服务。运输层协议又称为端到端协议。

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

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输层协议，即面向连接的TCP和无连接的UDP。

注：这里的“端口”并不是看得见、摸得着的物理端口，而是用来区分不同应用进程的标识符。

TCP/IP运输层中的两个重要协议

TCP	UDP
传输控制协议（TCP）为其上层提供面向连接的可靠的数据传输服务。	用户数据报协议（UDP）为其上层提供无连接的不可靠的数据传输服务。
使用TCP通信的双方，在传送数据之前必须首先建立TCP连接（逻辑连接，而非物理连接）。数据传输结束后必须要释放TCP连接。	使用UDP通信的双方，在传送数据之前不需要建立连接。
TCP为了实现可靠传输，就必须使用很多措施，例如TCP连接管理、确认机制、超时重传、流量控制以及拥塞控制等。	UDP不需要实现可靠传输，因此不需要使用实现可靠传输的各种机制。
TCP的实现复杂，TCP报文段的首部比较大，占用处理机资源比较多。	UDP的实现简单，UDP用户数据报的首部比较小

因特网中的一些典型应用所使用的TCP/IP应用层协议和相应的运输层协议如下所示：

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

运输层端口号

运行在计算机上的进程是使用进程标识符（PID）来标识的。

然而，因特网上的计算机并不是使用统一的操作系统，而不同操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程之间能够基于网络进行通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。

TCP/IP体系结构的运输层使用端口号来标识和区分应用层的不同应用进程。端口号的长度为16比特，取值范围是0~65535。

• 服务器端使用的端口号

  • 熟知端口号：又称为全球通用端口号，取值范围是0～1023。这些端口号分配给了TCP/IP体系结构应用层中最重要的一些应用协议。
  • 登记端口号：取值范围是1024～49151。这类端口号是为没有熟知端口号的应用程序使用的，要使用这类端口号必须登记。

• 客户端使用的短暂端口号：取值范围是49152～65535。这类端口号仅在客户端使用，由客户进程在运行时动态选择，又称为临时端口号。

注：端口号只具有本地意义，即端口号只是为了标识本计算机网络协议栈应用层中的各应用进程。在因特网中，不同计算机中的相同端口号是没有关系的，即相互独立。另外，TCP和UDP端口号之间也是没有关系的。

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

发送方的某些应用程序所发送的不同应用报文，在运输层使用UDP协议进行封装，这称为UDP复用；而另一些应用进程所发送的不同应用报文，在运输层使用TCP协议进行封装，这称为TCP复用。运输层使用端口号来区分不同的应用进程。

不管是使用运输层的UDP协议封装成的UDP用户数据报，还是使用TCP协议封装成的TCP报文段，在网际层都需要使用IP协议封装成IP数据报，这称为IP复用。IP数据报首部中的协议字段用来表明是何种协议数据单元。取值为6表示TCP报文段，取值为17表示UDP用户数据报。

接收方的网际层收到IP数据报后进行IP分用。

运输层对UDP用户数据报进行UDP分用，对TCP报文段进行TCP分用，根据UDP用户数据报或TCP报文段首部中的目的端口号，将它们向上交付给应用层的相应应用进程。

TCP/IP体系结构应用层常用协议所使用的运输层协议和熟知端口号如下图所示

注：OSPF报文并不使用运输层的UDP或TCP进行封装，而是直接使用网际层的IP进行封装，协议字段的值为89。

UDP和TCP的对比

无连接的UDP和面向连接的TCP

UDP是无连接的。使用UDP的通信双方，在传送数据之前不需要建立连接，可以随时发送数据。

TCP是面向连接的。换句话说，使用TCP的通信双方，在传送数据之前必须使用“三报文握手”来建立TCP连接。数据传输结束后，必须使用“四报文挥手”来释放TCP连接。

UDP和TCP对单播、多播和广播的支持情况

UDP支持单播、多播和广播。UDP支持“一对一”、“一对多”以及“—对全”的通信。

TCP仅支持单播，也就是“一对一”的通信。

UDP和TCP对应用层报文的处理

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

综上所述，UDP对应用进程交付下来的报文既不合并也不拆分，而是保留这些报文的边界。

UDP是面向应用报文的。

发送方的TCP把应用进程交付下来的应用报文，仅仅看作一连串的、无结构的字节流。TCP并不知道这些待传输的字节流的含义，仅将它们编号并存储在自已的发送缓存中。TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送。接收方的TCP一方面从所接收到的TCP报文段中取出数据载荷并存储在接收缓存中，另一方面将接收缓存中的一些字节向上交付给应用进程。

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

注：在实际的网络中，基于TCP连接的两端可以同时进行TCP报文段的发送和接收，也就是全双工通信。

UDP和TCP对数据传输可靠性的支持情况

当运输层使用UDP时，UDP向其上层提供的也是无连接不可靠的数据传输服务。

对于UDP用户数据报出现的误码和丢失等问题，UDP并不关心。基于UDP的这个特点，UDP适用于实时应用，例如IP电话和视频会议等。

尽管IP数据报可能在传输过程中出现丢失或误码，但只要运输层使用TCP协议，TCP就可向其上层提供面向连接的可靠的数据传输服务。

基于TCP连接的可靠信道进行数据传输，不会出现误码、丢失、失序和重复等传输差错。基于TCP的这个特点，TCP适用于要求可靠传输且对实时性要求不高的应用，例如文件传输和电子邮件等。

UDP首部和TCP 首部的对比

UDP用户数据报由首部和数据载荷两部分构成。

UDP用户数据报的首部仅有4个字段，每个字段长度为2字节。由于UDP不提供可靠传输服务，它仅仅在网际层的基础上添加了用于区分应用进程的端口，因此它的首部非常简单，仅有8字节。

TCP报文段由首部和数据载荷两部分构成。

TCP报文段的首部比UDP用户数据报的首部复杂得多，其最小长度为20字节，最大长度为60字节。TCP要实现可靠传输、流量控制、拥塞控制等服务，其首部自然会比较复杂，首部中的字段比较多，首部长度也比较长。

传输控制协议

传输控制协议（TCP）是TCP/IP体系结构运输层中面向连接的协议，它向其上的应用层提供全双工的可靠的数据传输服务。

TCP除具有面向连接和可靠传输的特性，TCP还在运输层使用了流量控制和拥塞控制机制。

TCP报文段的首部格式

源端口字段和目的端口字段

源端口字段占16比特，用来写入源端口号。源端口号用来标识发送该TCP报文段的应用进程。

目的端口字段占16比特，用来写入目的端口号。目的端口号用来标识接收该TCP报文段的应用进程。

序号

占32比特，取值范围$0\sim 2^{32}-1$。当序号增加到最后一个时，下一个序号又会回到$0$。

用来指出本TCP报文数据载荷的第一字节的序号。

确认号

占32比特，取值范围为$0\sim 2^{32}-1$。当确认号增加到最后一个时，下一个确认号又回到$0$。

用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。

确认标志位ACK

只有当ACK取值为1时，确认号字段才有效。ACK取值为0时，确认号字段无效。TCP规定在TCP连接建立后，所有传送的TCP报文段都必须把ACK置1。

数据偏移

占4比特，该字段的取值以4字节为单位。

指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远，这实际上指出了TCP报文段的首部长度。

保留

占6比特，保留为今后使用，目前应置为0。

窗口

占16比特，该字段的取值以字节为单位。

指出发送本报文段的一方的接收窗口的大小，即接收缓存的可用空间大小，这用来表征接收方的接收能力。

检验和

占16比特，用来检查整个TCP报文段在传输过程中是否出现了误码。

发送方检验和计算方法

1. 将TCP首部中检验和字段的值置为0。
2. 将伪首部、TCP首部以及数据载荷这三部分划分成若干个2字节的字。若伪首部、TCP首部以及数据载荷这三部分的总长度不是偶数个字节，则在最后添加1 个“全0”字节。
3. 对划分出的全部2字节的字进行反码算数运算求和，并将求和结果取反码。
4. 将步骤3得到的结果写入TCP首部中的检验和字段。

接收方判断是否误码的方法

1. 给接收到的TCP报文段前面添加一个12字节的伪首部。
2. 将伪首部、TCP首部以及数据载荷这三部分划分成若干个2 字节的字。
3. 对划分出的全部2字节的字进行反码算数运算求和，并将求和结果取反码。
4. 若步骤3得到的结果为0，则表示TCP报文段在传输过程中没有误码。否则，表示出现了误码.

同步标志位SYN

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

当SYN=1且ACK=0时，表明这是一个TCP连接请求报文段。

对方若同意建立连接，则应在响应的TCP报文段的首部中使SYN=1且ACK=1 。

注：SYN为1的TCP报文段要么是一个连接请求报文段，要么是一个连接响应报文段。

终止标志位FIN

用于释放TCP连接。

当FIN=1时，表明此TCP报文段的发送方已经将全部数据发送完毕，现在要求释放TCP连接。

复位标志位RST

用于复位TCP连接。

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

RST置1还用来拒绝一个非法的TCP报文段或拒绝打开一个TCP连接。

推送标志位PSH

发送方TCP把PSH置1，并立即创建一个TCP报文段发送出去，而不需要积累到足够多的数据再发送。

接收方TCP收到PSH为1的TCP报文段，就尽快地交付给应用进程，而不再等到接收到足够多的数据才向上交付。

紧急标志位URG

当URG=1时，紧急指针字段有效。当URG=0时，紧急指针字段无效。

紧急指针

占16 比特，以字节为单位，用来指明紧急数据的长度。

当发送方有紧急数据时，可将紧急数据“插队”到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。

接收方收到紧急标志位为1的TCP报文段，会按照紧急指针字段的值从报文段数据载荷中取出紧急数据并直接上交应用进程，而不必在接收缓存中排队。

选项

TCP报文段首部除了20字节的固定部分，还有最大40字节的选项部分。增加选项可以增加TCP的功能。

填充

由于选项字段的长度是可变的，因此还需要使用填充字段（填充内容为若干个比特0）来确保TCP报文段首部能被4整除。这是因为TCP报文段首部中的数据偏移字段是以4字节为单位的。

TCP运输连接管理

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。TCP运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程。

TCP运输连接有三个阶段：

1. 建立TCP连接：通过“三报文握手”来建立TCP连接。
2. 数据传送：基于已建立的TCP连接进行可靠的数据传输。
3. 释放连接：在数据传输结束后，还要通过“四报文挥手”来释放TCP连接。

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

“三报文握手”建立TCP连接的目的在于解决以下三个主要问题：

• 使TCP双方能够确知对方的存在。
• 使TCP双方能够协商一些参数（例如最大报文段长度、最大窗口大小、时间戳选项等）。
• 使TCP双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等。

1. 报文1：TCP连接请求报文段和TCP连接请求确认报文段首部中的同步标志位SYN的值必须设置为1。序号seq字段被设置了一个初始值x，作为TCP客户进程所选择的初始序号。

注：TCP规定同步标志位SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号。因此，TCP客户进程下一次发送的TCP报文段的数据载荷的第一个字节的序号为x+1。

2. 报文2：TCP连接请求确认报文段首部中的同步标志位SYN和确认标志位ACK的值都设置为1。序号seq字段被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。确认号ack字段的值被设置为x+1，这是对TCP客户进程所选择的初始序号x的确认。

3. 报文3：确认标志位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。确认号ack字段的值被设置为y+1，这是对TCP服务器进程所选择的初始序号y的确认。

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

1. 报文1：TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。序号seq字段的值设置为u，等于TCP客户进程之前已经传送的数据的最后一个字节的序号加1。确认号ack字段的值设置为v，等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。

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

2. 报文2：确认标志位ACK的值被设置为1，表明这是一个TCP普通确认报文段。序号seq字段的值设置为v，等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1。这也与之前收到的TCP连接释放报文段中的确认号v匹配。确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。

注：此时的TCP连接属于半关闭状态，从TCP客户进程到TCP服务器进程这个方向的连接就释放了，从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。

3. 报文3：TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。序号seq字段的值假定被设置为w，这是因为在半关闭状态下TCP服务器进程可能又发送了一些数据。确认号ack字段的值被设置为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

4. 报文4：确认标志位ACK的值设置为1，表明这是一个TCP普通确认报文段。序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。

MSL是最长报文段寿命，建议为2分钟。也就是说，TCP客户进程进入时间等待（TIMEWAIT）状态后，还要经过4分钟才能进入关闭（CLOSED）状态。

TCP保活计时器

除时间等待计时器（2MSL计时），TCP还设有一个保活计时器。

TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（通常为2小时）。

若保活计时器在定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，于是就关闭这个连接。

TCP的流量控制

TCP流量控制的基本概念

TCP为应用程序提供了流量控制（Flow Control）机制，以解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题。

流量控制的基本方法：接收方根据自己的接收能力（接收缓存的可用空间大小）控制发送方的发送速率。

TCP流量控制方法

TCP利用滑动窗口机制可用再TCP连接上实现对发送方的流量控制。

说明如下：

主机A和B已成功建立了TCP连接，A给B发送数据，B对A进行流量控
制。图中给出了主机A待发送数据的字节序号，每个小格子表示100字节数据的序号。

假设主机A发送的每个TCP数据报文段都携带100字节的数据，在主机A和B建立TCP连接时，B告诉A接收窗口为400，因此主机A的发送窗口也设置为400。

（1）主机A将发送窗口内序号为1～100的数据封装成一个TCP报文段发送出去，还有300字节可以发送。

seq是TCP报文段首部中的序号字段，取值1表示该TCP报文段数据载荷的第一个字节的序号是1；DATA表示这是TCP数据报文段。

（2）主机A将序号为101～200的数据封装成一个TCP报文段发送出去，发送窗口内还有200字节可以发送。

（3）主机A将序号为201～300的数据封装成一个TCP报文段发送出去，但该报文段在传输过程中丢失了。

（4）主机A还可发送100个字节的数据，即301～400号数据。此时主机B给主机A发送累积确认报文段，对主机A之前所发送的201号以前的数据进行累积确认。

该累积确认报文段首部中的ACK被设置为1，表示这是一个TCP确认报文段；确认号字段ack的取值设置为201，表示序号201之前的数据已全部正确接收，现在期望收到序号201及其后续数据；窗口字段rwnd的值被设置为300，主机B的接收缓存的可用空间变为为300字节，对主机A进行流量控制。

（5）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，使已发送并收到确认的数据的序号移出发送窗口，这些数据可从发送缓存中删除了。由于主机B在该累积确认报文段中将自己的接收窗口调整为了300，因此主机A相应地将自己的发送窗口调整为300。

这样，主机A的发送窗口内的序号为201～500，其中201~300号是已发送但还未收到确认的数据的序号，因此不能将这些数据从发送缓存删除，因为有可能之后会超时重传这些数据；301～400号字节数据以及401～500号字节数据还未被发送，可被分别封装在一个TCP报文段中发送。

（6）主机A将序号301～400号的数据封装成一个TCP报文段发送出去，还有401～500号共100字节可以发送。

（7）主机A将序号401～500号的数据封装成一个TCP报文段发送出去。至此，序号落在发送窗口内的数据已经全部发送出去了，不能再发送新的数据了。

（8）假设此时主机A发送窗口内序号201～300这100字节数据的重传计时器超时了，主机A将它们重新封装成一个TCP报文段发送出去，暂时不能发送其他数据。

（9）主机B收到该重传的TCP报文段后，给主机A发送累积确认报文段，对主机A之前所发送的501号以前的数据进行累积确认。

另外，主机B在该累积确认报文段中将自己的接收窗口调整为100，这是主机B对主机A进行的第二次流量控制。

（10）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，相应地将自己的发送窗口调整为100。这样，主机A的发送窗口内的序号为501～600，也就是主机A还可以发送这100字节数据。

（11）主机A将发送窗口内序号为501～600号的数据封装成一个TCP报文段发送出去。至此，序号落在发送窗口内的数据已经全部发送出去了，不能再发送新的数据了。

（12）主机B给主机A发送累积确认报文段，对主机A之前所发送的601号以前的数据进行累积确认。

另外，主机B在该累积确认报文段中将自己的接收窗口调整为0，这是主机B对主机A进行的第三次流量控制。

（13）主机A收到主机B发来的累积确认报文段后，将发送窗口向前滑动，相应地将自己的发送窗口调整为0。主机A不能再发送普通的TCP报文段了。

（14）假设主机B的接收缓存又有了一些可用空间。于是主机B向主机A发送了接收窗口等于300的报文段。然而，这个报文段丢失了。

（15）主机A一直等待主机B发送的非零窗口的通知，而主机B也一直等待主机A发送的数据。如果不采取措施，这种互相等待而形成的死锁局面将一直持续下去。

为了打破死锁局面，TCP为每一个连接都设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。当持续计时器超时时，就发送一个零窗口探测报文段，仅携带1字节的数
据。对方在确认这个零窗口探测报文段时，给出自己现在的接收窗口值。如果接收窗口值仍然是0，那么收到这个报文段的一方就重新启动持续计时器。如果接收窗口值不是0，那么死锁的局面就可以被打破了。

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

TCP的拥塞控制

拥塞控制的基本概念

在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这就叫做拥塞。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制的基本方法

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

流量控制：以接收方的接收能力控制发送方（源点）的发送速率，只与特定的点对点通信的发送方和接收方之间的流量有关。

拥塞控制：源点根据各方面因素，按拥塞控制算法自行控制发送速率，全局性问题，涉及网络中所有的主机、路由器等。

拥塞控制的基本方法

开环控制

• 试图用良好的设计来解决问题。
• 从一开始就保证问题不会发生。
• 一旦系统启动并运行起来，就不需要中途修正。

当网络的流量特征可以准确规定且性能要求可以事先获得时，适合使用开环控制。

闭环控制

基于反馈的控制方法，包括以下三个部分：

1. 监测网络拥塞在何时、何地发生。
2. 把拥塞发生的相关信息传送到可以采取行动的地方。
3. 调整网络的运行以解决拥塞问题。

当网络的流量特征不能准确描述或者当网络不提供资源预留时，适合使用闭环控制。因特网采用的就是闭环控制方法。

根据拥塞信息的反馈形式，可将闭环拥塞控制算法分为：

• 显式反馈算法：从拥塞节点（即路由器）向源点提供关于
  网络中拥塞状态的显式反馈信息。

• 隐式反馈算法：源点自身通过对网络行为的观察（例如超时重传或往返时间RTT）来推断网络是否发生了拥塞。（TCP采用）

TCP的四种拥塞控制方法

TCP的四种拥塞控制方法是慢开始（Slow-Start）、拥塞避免（Congestion Avoidance）快重传（Fast Retransmit）、快恢复（Fast Recovery）。

发送方要维护一个叫作拥塞窗口的状态变量cwnd，其值取决于网络的拥塞程度和所采用的TCP拥塞控制算法。拥塞窗口cwnd的维护原则是，网络没有出现拥塞，拥塞窗口就增大一些；网络出现拥塞，拥塞窗口就减少一些。

注：当发送方出现超时重传时，很可能是因为网络中的某个路由器“繁忙”而丢弃了一些分组，这是网络出现拥塞的征兆。

发送方除了要维护拥塞窗口cwnd变量，还要维护发送窗口的状态变量swnd。发送窗口$swnd=min(cwnd,rwnd)$。

注：不考虑流量控制时，swnd=cwnd。

除拥塞窗口cwnd和发送窗口swnd，发送方还需要维护一个叫作慢开始门限的状态变量ssthresh：

1. 当cwnd<ssthresh时，使用慢开始算法。
2. 当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法。
3. 当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

慢开始算法和拥塞避免算法

发送方的拥塞窗口cwnd的初始值为1，而发送窗口swnd的
值始终等于cwnd的值（不考虑流量控制)，因此发送方一开始只能发送1个TCP数据报文段。

使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd加倍。

当cwnd的值增大到了ssthresh值时，需要改用拥塞避免算法，每个传输轮次结束后，拥塞窗口cwnd线性加1。

假设这数据报文段在传输过程中丢失了几个。这必然会造成发送方对这些丢失报文段的超时重传。发送方以此判断网络可能出现了拥塞，需要调整自已的cwnd值和ssthresh值：

• 将ssthresh值调整为发生拥塞时cwnd值的一半。
• 将cwnd值减小为1，重新开始执行满开始算法。

“慢开始”是指一开始向网络注入的报文段少，而并不是指拥塞窗口cwnd的值增长速度慢。

“拥塞避免”也并非指完全能够避免拥塞，而是指在拥塞避免阶段将cwnd值控制为按线性规律增长，使网络比较不容易出现拥塞。

快重传算法和快恢复算法

采用快重传算法可以让发送方尽早知道发生了个别TCP报文段的丢失。

“快重传”是指使发送方尽快（尽早）进行重传，而不是等重传计时器超时再重传。

• 这要求接收方要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
• 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的重传计时器超时再重传。

与快重传算法配合使用的是快恢复算法，发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段，于是不启动慢开始算法，而是执行快恢复算法。

• 发送方将慢开始门限ssthresh的值和拥塞窗口cwnd的值都调整为当前cwnd值的一半，并开始执行拥塞避免算法。
• 也有的快恢复实现是把快恢复开始时的cwnd值再增大一些，即cwnd=新ssthresh+3。

TCP拥塞控制流程如下图所示。该流程图更加全面，说明在慢开始阶段如果出现了超时重传或出现3个重复确认，发送方应采取什么措施。

TCP拥塞控制与网际层拥塞控制的关系

路由器的输入缓存（缓存队列）通常都按照“FIFO” 的规则来处理到达的IP数据报。当队列已满时，之后再到达的所有IP数据报都将被丢弃，这就叫作尾部丢弃策略。

当网络中有大量封装了TCP报文段的IP数据报涌入某个（或某些）路由器并造成路由器进行尾部丢弃时，这些TCP报文段的多个发送方就会出现超时重传，这会使得许多TCP连接在同一时间突然都进入TCP拥塞控制的慢开始阶段。这在TCP中称为全局同步。

全局同步使得全网的通信量骤降，而在网络恢复正常后，其通信量又突然增大很多。

为了避免网络中出现全局同步问题，提出了主动队列管理（AQM）。

主动就是在路由器的队列长度达到某个阈值但还未满时就主动丢弃IP 数据报，而不是要等到路由器的队列已满时再丢弃。

主动队列管理AQM可以有不同的实现方法，其中曾流行多年的就是随机早期检测（RED），也称为随机早期丢弃（RED）。

• 路由器需要维护两个参数来实现RED：队列长度最小门限和最大门限。当每一个IP数据报到达路由器时，RED就按照规定的算法计算出当前的平均队列长度。
  • 若平均队列长度小于最小门限，则把新到达的IP数据报存入队列进行排队。
  • 若平均队列长度大于最大门限，则把新到达的IP数据报丢弃。
  • 若平均队列长度在最小门限和最大门限之间，则按照某一丢弃概率p把新到达的IP数据报丢弃（丢弃IP数据报的随机性）。

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输。

发送方在没有收到接收方确认的情况下，可以把序号落入发送窗口内的数据依次全部发送出去。

凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口后沿的移动情况有两种可能：

• 不动：没有收到新的确认，发送窗口的后沿不会移动。
• 前移：收到新的确认，发送窗口的后沿向前移动。

发送窗口的后沿不可能向后移动。因为不可能撤销掉已收到的确认。

发送窗口前沿的移动情况有三种可能：

• 前移：通常情况下，发送窗口的前沿是不断向前移动的。

• 不动：

  • 一种情况是由于没有收到新的确认，接收方通知的窗口大小也没有改变。
  • 另一种情况是收到了新的确认，可向前移动相应位置，但接收方通知的窗口缩小了，前沿应该向后回缩，如果向前移动和向后回缩的尺寸恰好相等，就会使得发送窗口的前沿不动。

• 向后收缩：这发生在接收方通知的窗口变小了。

发送窗口状态的描述、标记和维护可以使用三个指针P1、P2和
P3分别指向相应的字节序号：

• P1指向发送窗口内已发送但还未收到确认的第一个数据的序号。
• P2指向发送窗口内还未发送的第一个数据的序号。
• P3指向发送窗口前沿外的第一个数据的序号。

这样就可以用P1、P2和P3这三个指针来描述发送窗口的相关信息：

• 小于P1的就是已发送并已收到确认的部分。
• 大于等于P3的就是不允许发送的部分。
• P3-P1可以得出当前发送窗口的尺寸。
• P2-P1可以得出已发送但尚未收到确认的字节数量。
• P3-P2可以得出允许发送但当前尚未发送的字节数量（又称为可用窗口或有效窗口）。

对于TCP 可靠传输的实现，还需要做以下补充说明

（1）在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大，因为：

• 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
• 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

（2）TCP要求接收方必须有累积确认（这一点与选择重传协议不同）和捎带确认机制。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。TCP标准规定，确认推迟的时间不应超过0.5 秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认。
（3）TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。

TCP超时重传时间的选择

TCP超时重传时间RTO的选择是TCP最复杂的问题之一。

TCP的选择确认

对于TCP的快重传和可靠传输时，TCP接收方只能对按序收到的数据中的最高序号给出确认。当发送方超时重传时，接收方之前已收到的未按序到达的数据也会被重传。

TCP可以使用选择确认（SACK）。

假设这些字节的序号都在接收窗口内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不再重复发送这些数据。