计算机网络之运输层

本章讨论TCP/IP体系中运输层最重要的两种协议：UDP和TCP。必须弄清TCP的各种机制（如面向连接的可靠服务、流量控制、拥塞控制等），以及TCP连接管理和状态图的概念。

一、运输层协议概述

 

从TCP开始往后看思维导图

1.进程之间的通信

IP协议是把分组送到目的主机，但这个分组还停留在主机的网络层而没有交付给主机中的应用进程。从运输层角度看，通信的真正端点并不是主机而是主机中的进程。

复用（multiplexing）——发送方不同的应用进程都可以使用同一个运输层协议传送数据（当然需要加上适当的首部）

分用（demultiplexing）——接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。

运输层提供应用进程间的逻辑通信：指运输层之间的通信好像是沿水平方向传送数据，但事实上这两个运输层之间并没有一条水平方向的物理连接。要传送的数据是沿着图中的虚线方向（经过多个层次）传送的。

运输层还要对收到的报文进行差错检测。在网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。

两种不同协议：①面向连接的TCP：尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。②无连接的UDP协议：仍是不可靠信道。

2.运输层的两个主要协议

（1）用户数据报协议UDP（user datagram protocol）

在传送数据之前不需要先建立连接，远地主机的运输层在收到UDP报文后，不需要给出任何确认。不提供可靠支付。

（2）传输控制协议TCP（transmission control protocol）

提供可靠的、面向连接的服务。在传送数据之前必须先建立连接，数据传送后要释放连接。不提供广播或多播服务。

两种协议在协议栈中的位置

按OSI术语，两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU（transport protocol data unit）。但在TCP/IP体系中，则根据所使用的协议是TCP或UDP，分别称之为TCP报文段或UDP用户数据报。

3.运输层的端口

Ⅰ、运输层的复用——应用层所有的应用进程都可以通过运输层再传到IP层

运输层的分用——运输层从IP层收到数据后必须交付给指明的应用进程

Ⅱ、为什么要在运输层使用协议端口号（protocol port number，或端口）？

给应用层的每个应用进程赋予一个非常明确的标志很重要。在单个计算机中的进程是用进程标识符来标志的。但在因特网环境下，就不行了，因为在因特网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标志符。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法（而这种方法必须与特定操作系统无关）对TCP/IP体系的应用进程进行标志。

但是，把一个特定机器上运行的特定进程指明为因特网上通信最后的终点还是不可行的。这是因为进程的创建和撤销都是动态的，通信的一方几乎无法识别对方机器上的进程。另外，我们往往需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个。

解决这个问题的方法就是在运输层使用协议端口号。虽然通信的终点是应用进程，但我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付给目的进程）就由TCP来完成。

Ⅲ、端口认知

这种在协议栈层间抽象的协议端口是软件端口，软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。

路由器或交换机上的硬件端口是不同硬件设备进行交互的接口。

Ⅳ、端口号

只具有本地意义，只是为了标志本计算机应用层中的各个进程和运输层交互时的层间接口。在因特网不同计算机中，相同的端口号是没有关联的。

两计算机中的进程通信时，不仅需要知道对方的IP地址（为了找到对方的计算机），还要知道对方的端口号（为了找到对方计算机中的应用进程）。因特网上的计算机通信采用客户—服务器方式，于是运输层的端口号可分为：

（1）服务器端使用的端口号

①熟知端口号（well-known port number）或系统端口号

IANA把这些端口号指派给了TCP/IP最重要的一些应用程序，让所有的客户都知道。当一种新的应用程序出现后，IANA必须为它指派一个熟知端口，否则因特网上的其他应用进程就无法和它进行通信。

②登记端口号

是为没有熟知端口号的应用程序使用的，使用这类端口号必须在IANA按照规定的手续登记，以防止重复。

（2）客户端使用的端口号（短暂端口号）

仅在客户进程运行时才动态选择，留给客户进程选择时暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在。这个端口号就可以供其他客户进程以后使用。

二、用户数据报协议UDP

1.UDP概述

只在IP的数据服务之上增加了很少一点功能，这就是复用和分用、差错检测。

主要特点：（1）无连接的。发送数据之前不需要建立连接（发送完可释放）（2）使用尽最大努力交付，即不保证可靠交付，主机不需要维持复杂的连接状态表。（3）面向报文的。UDP一次交付一个完整的报文，因此应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP层的首部的相对长度太大，这也降低了IP层的效率。

（4）没有堵塞控制

网络出现的堵塞不会使源主机的发送速率降低，这对某些实时应用很重要，比如实时视频会议要求源主机以恒定的速率发送数据，并且允许在网络发生堵塞时丢失一些数据，但却不允许数据有太大的时延。

但当很多源主机同时向网络发送高速率的实时视频流时，网络就有可能发生堵塞，结果大家都无法正常接收。还有些实时应用需要对它的不可靠传输进行适当的改造，以减少数据的丢失。

（5）支持一对一、一对多、多对一、多对多的交互通信

（6）首部开销小，只有8个字节

2.UDP的首部格式

用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节，由四个字段组成，每个字段的长度都是两个字节。各字段：

（1）源端口：源端口号，在需要对方回信时选用，不需要时可用全0。

（2）目的端口：目的端口号，这在终点交付报文时必须要使用到。

（3）长度：UDP用户数据报的长度，其最小值是8（只有首部）。

（4）检验和：检测UDP用户数据报在传输中是否有差错，有错就丢弃。

当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点——应用进程。下图是UDP基于端口的分用的示意图。

如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方。我们在上一章4.4.2节讨论traceroute时，就是让发送的UDP用户数据报故意使用一个非法的UDP端口，结果ICMP就返回“端口不可达”差错报文，因而达到了测试的目的。

检验和的计算方法：

（1）伪首部——12字节，它不是UDP用户数据报真正的首部，只是用于计算检验和而临时添加的，它既不向下传送也不向上递交。

（2）和IP数据报首部检验和的方法的不同——IP数据报的检验和只检验IP数据报的首部，而UDP的检验和是把首部和数据部分一起都检验。

（3）发送方——先把全零放入检验和字段，再把伪首部以及UDP用户数据报看成是由许多16位的字串接起来。若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零字节（但此字节不发送）。然后按二进制反码计算出这些16位字的和。将此和的二进制反码写入检验和字段后，就发送这样的UDP用户数据报。

（4）接收方——把收到的UDP用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些16位字的和。当无差错时结果应全1。否则就表明有差错实现，接收方就丢弃这个UDP用户数据报（也可以上交给应用层，但附上出现差错的警告）。

（5）评价——检错能力不强，但简单、处理起来较快。

伪首部的第3字段全是0，第4字段是IP首部中的协议字段的值。以前已讲过，对于UDP，此协议字段值为17。第5字段是UDP用户数据报的长度。因此，这样的检验和，既检查了UDP用户数据报的源端口和目的端口号以及UDP用户数据报的数据部分，又检查了IP数据报的源IP地址和目的地址。

接收方例子

三、传输控制协议TCP概述

1.TCP最重要的特点
 

（1）是面向连接的运输层协议：传送数据完毕后，必须释放已建立的TCP连接。

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

（3）提供可靠交付的服务——无差错、不丢失、不重复、且按序到达。

（4）全双工通信——TCP允许通信双方的应用进程在任何时候都能发送数据，TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

（5）面向字节流

“流”是指流入到进程或从进程流出的字节序列。面向字节流的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义，它不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

解释上图：TCP连接是一条虚连接而不是一条真正的物理连接。TCP报文段先要传送到IP层，加上IP首部后，再传送到数据链路层。再加上数据链路层的首部和尾部后，才离开主机发送到物理链路。

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

2.TCP的连接

TCP把连接作为最基本的抽象，TCP的许多特性都与TCP是面向连接的这个基本特性有关。

每一条TCP连接有两个端点，它不是主机、不是主机的IP地址、不是应用进程、不是运输层的协议端口，而是套接字（是端口号拼接到IP地址即构成了套接字）。套接字socket=（IP地址：端口号）

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

TCP连接：：={socket1，socket2}={（IP1：port1），（IP2：port2）}

TCP连接就是由协议软件所提供的一种抽象，是应用进程之间建立的。TCP连接的端点是套接字，即（IP地址：端口号）。同一个IP地址可以有很多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接中。

注意：socket有很多意思。

四、可靠传输的工作原理

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

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

在这样的理想传输条件下，不需要采取任何措施就能实现可靠传输。达不到时，我们可以使用可靠传输协议。当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。

1.停止等待协议

因为这里是讨论可靠传输的原理，因此把传送的数据单元都称为分组，而不考虑数据是在哪一层次上传送的。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

Ⅰ、无差错情况

A在收到了对M1的确认后，就再发送给下一个分组M2。

Ⅱ、出现差错

B接收M1时检测出了差错，就丢弃M1，其他什么也不做（不通知A收到有差错的分组），也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚刚发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。

要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。在a图中，A为每一个已发送的分组都设置了一个超时计时器，但A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。

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

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

③超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。如果重传时间设定长了，通信效率就低；如果短了，产生不必要的重传，浪费了网络资源。设定准确的重传时间是复杂的，因为已发送出的分组到底会经过哪些网络，以及时延，都是不确定因素。

Ⅲ、确认丢失和确认迟到

图a：B收到重传分组M1时，采取两行动，一是丢弃这个重复的分组M1，不向上层支付；二是向A发送确认，不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M1的确认。

图b：确认迟到了，收到就丢弃。如果A不断重传分组但总是收不到确认，说明通信线路太差，不能进行通信。

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

Ⅳ、信道利用率

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

假定A发送分组需要的时间是Td（=分组长度/数据率）；分组正确到达B后，B处理分组的时间可以忽略不计，同时立即发回确认；B发送确认分组需要时间Ta。如果A处理确认分组的时间也可以忽略不计，那么A在经过时间（Td+RTT+Ta）后就可以再发送下一个分组，这里的RTT是往返时间。因为仅仅是在时间Td内才用来送有用的数据（包括分组的首部），因此信道的利用率U可以用下式计算：

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。看下图，它就是发送方可连续发送多个分组，不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然，这样可获得很高的信道利用率。

当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议（5.6节讨论）。

2.连续ARQ协议

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

根据ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。图b表示发送方收到了对第一个分组的确认，于是把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。

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

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

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

五、TCP报文段的首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。因此，弄清首部各字段作用才能弄清它的工作原理。

前20字节固定，后4N（N是整数）字节是根据需要而增加的选项。

（1）源端口和目的端口：TCP的分用是通过端口实现的。

（2）序号

序号范围[0,2^32-1]，序号增加到最大值时，下一个序号就又回到0。TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段（也叫作报文段序号）值则指的是本报文段所发送的数据的第一个字节的序号。

（3）确认号：是期望收到对方下一个报文段的第一个数据字节的序号。若确认号=N，则表明：到序号N-1为止的所有数据都已正确收到。

（5）数据偏移：占4位，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上指出TCP报文段的首部长度。（首部中还有长度不确定的选项字段）

（6）保留：占6位，保留为今后用，但目前设置为0。

（7）紧急URG

当URG置1时，发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据，这时要与首部中紧急指针（urgent pointer）字段配合使用。

（8）确认ACK（ACKnowlegment）

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

（9）推送PSH（push）

当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。这时，发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。得少用。

（10）复位RST（ReSeT）

为1时表明TCP连接中出现严重差错（如主机崩溃），必须释放连接，然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。也成为重建位或重置位。

（11）同步SYN（SYNchronization）

在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此，SYN置1就表示这是一个连接请求或连接接受报文。

（12）终止FIN（FINis）

用来释放一个连接。为1时表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。

（13）窗口

窗口值是[0,2^16-1]之间的整数。明确指出了现在允许对方发送的数据量，窗口值作为接收方让发送方设置其发送窗口的依据。有这个限制是因为接收方的数据缓存空间是有限的。

（14）检验和

检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6（TCP的协议号是6），把第5字段中的UDP长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用IPv6，则相应的伪首部也要改变。

（15）紧急指针

仅在URG=1时才有意义，指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。当所有紧急数据处理完时，TCP就告诉应用程序恢复到正常操作。即使窗口为零时也可以发送紧急数据。

（16）选项

长度可变，最长可达40字节。没有使用选项时，TCP首部长度是20字节。有以下几种：

①最大报文段长度MSS（maximum segment size）

理解——它是每一个TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是整个TCP报文段的最大长度，而是“TCP报文段长度减去TCP首部长度”。

出现缘由——并不是考虑接收方的接收缓存可能放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少加上40字节的首部（TCP首部20字节和IP首部20字节，这里都还没有考虑首部中的选项部分），才能组装成一个IP数据报。MISS长度小时，网络的利用率低。长度大时，IP层传输时就有可能要分解成多个短数据报片，在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时要重传，这些使开销增大。

因此，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。而IP数据报所经历的路径是动态变化的，因此这条路径不用分片下条路径可能要分片，于是最佳MSS难确定。在连接建立过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传送数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则MSS的默认值是536字节长。因此，所有在因特网上的主机都应能接受的报文段长度是536+20（固定首部长度）=556字节。

②窗口扩大选项

为了扩大窗口。占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口数从16增大到（16+S），这相当于把窗口值向左移动S位后获得实际的窗口大小。移位值允许使用的最大值是14，相当于窗口最大值增大到2^（16+14）-1。

窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0的选项，使窗口大小回到16。

③时间戳选项

占10字节，最主要的字段时间戳字段（4字节）和时间戳回送回答字段（4字节）。功能：一是用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确计算出RTT来。二是处理TCP序号超过2^32的情况，这又称为防止序号绕回PAWS（protect against wrapped sequence nambers），可以使接收方能够把新的报文段和迟到很久的报文段区分开。

④选择确认选项

5.6.3节介绍

六、TCP可靠传输的实现

首先介绍以字节为单位的滑动窗口。为了讲述可靠传输原理的方便，假定数据传输只在一个方向进行，即A发送数据，B给出确认。

1.以字节为单位的滑动窗口

Ⅰ、概述

①发送窗口

表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因为可能有较高的传输效率。但接收方必须来得及处理这些收到的数据。

发送窗口的位置由窗口前沿和后沿的位置共同确定。

②发送窗口后沿

它的变化情况有两种，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销已收到的确认。

③发送窗口前沿

通常是不断向前移动，也有可能不移动，这对应于两种情况，一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。发送窗口前沿也有可能向后收缩，这发生在对方通知的窗口缩小了，但TCP标准不赞成这样做，因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据，现在收缩会产生一些错误。

Ⅱ、发送窗口和接收窗口

假定A发送了序号为31~41的数据，这时发送窗口位置并未改变。三个指针：P1、P2、P3。

P3-P1=A的发送窗口（又称为通知窗口）

P2-P1=已发送但尚未收到确认的字节数

P3-P2=允许发送但尚未发送的字节数（又称为可用窗口或有效窗口）

再看一下B的接收窗口。到30号为止的数据是已经发送过确认，并且已经交付给主机了，此时B可以不再保留这些数据。32和33号数据没有按序到达，而B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31（即期望收到的序号），而不能是32或33。

现假定B收到了31号数据，并把31~33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号（图5-17），同时给A发送确认，其中窗口值仍为20，但确认号是34。A收到B的确认后，就可以把发送窗口向前滑动3个序号，但指针P2不动。A的可用窗口增大了，可发送的序号范围是42~53。

A在继续发完42~53的数据后，指针P2向前移动和P3重合，发送窗口内的序号都已用完，但还没有再收到确认（图5-18）。由于A的发送窗口已满，可用窗口已减小到零，因此必须停止发送。请注意，存在下面这种可能性：就是发送窗口内所有的数据都已正确到达B，B也早已发出来确认。但不幸的是，所有这些确认都滞留在网络中。在没有收到B的确认时，A在经过一段时间后（由超时计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。如果A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。

Ⅲ、发送缓存和接收缓存

缓存空间和序号空间都是有限的，并且都是循环使用的。

发送缓存暂时用来存放：①发送应用程序传送给发送方TCP准备发送的数据；②TCP已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分，已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：①按序到达的、但尚未被接收应用程序读取的数据；②未按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最短不能超过接收缓存的大小。

注意：

①虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后，另外发送方A还可能根据网络当时的拥堵情况适当减小自己的发送窗口数值。

②对于不按序到达的数据应如何处理，TCP标准无明确规定。如果接收方把不按序到达的数据一律丢弃，则这样对网络资源的利用不利（因为发送方会重复传送较多的数据）。因此，TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付非上层的应用进程。

③TCP要求接收方必须有累积确认的功能，这样可减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但请注意两点： 第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。TCP标准规定，确认推迟时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就要发送一个确认。第二，捎带确认实际上并不经常发生，因为大多数应用程序不同时在两个方向上发送数据。

2.超时重传时间的选择

Ⅰ、背景

设置短了，会引起报文段不必要的重传，使网络负荷增大。设置长了，网络空闲时间大，降低了传输效率。于是TCP采用了一种自适应算法。

Ⅱ、自适应算法

它记录一个报文段发出的时间，以及收到相应的确认的时间，这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs（又称为平滑往返时间，S代表smoothed）。

新的RTTs=（1-α）*（旧的RTTs）+α*（新的RTT样本）

上式中，0≦α﹤1。若α接近0，则表示新的RTTs值和旧的RTTs值相比变化不大，而对新的RTT样本影响不大（RTT值更新较慢）。若α接近1，则表示新的RTTs值受新的RTT样本的影响较大（RTT更新较快）。RFC 2988推荐的α值为1/8，即0.125。

显然，超时计时器设置的超时重传时间RTO（retransmission time-out）应略大于上面得出的加权往返时间RTTs。

RTO=RTTs+4*RTTd

RTTd——RTT的偏差的加权平均值

新的RTTd=（1-β）*（旧的RTTd）+β*| RTTs - 新的RTT样本 |

β推荐值为1/4，即0.25。

Ⅲ、问题及解决

往返时间测量是复杂的——比如，发送一个报文段，重传时间到了，还没收到确认，于是重传报文段。经过一段时间，收到了报文段。问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？正确的判定对确认加权平均RTTs的值关系很大。

解决——Karn提出，在计算加权平均RTTs时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均RTTs和RTO就较准确。

新问题——设想报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是重传报文段，但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

修正——报文段每重传一次，就把超时重传时间RTO增大一些。典型做法是取新的重传时间为2倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的式子计算超时重传时间。

3.选择确认SACK

Ⅰ、背景

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

Ⅱ、工作原理

我们知道，TCP的首部没有哪个字段能够提供上述这些字节块的边界信息。RFC 2018规定，如果要使用选择确认，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好，如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。

由于首部选项的长度最多只有40字节，而指明一个边界就要用掉4字节（因为序号有32位，需要使用4个字节表示），因此在选项中最多只能指明4个字节块的边界信息。这是因为4个字节块共有8个边界，因而需要用32字节来描述。另外还需要两个字节。一个字节用来指明是SACK选项，另一个字节是指明这个选项要占用多少字节。如果要报告五个字节块的边界信息，那么至少需要42字节。这就超过了选项长度的40字节的上限。RFC 2018还对报告这些边界信息的格式都做出来非常明确的规定。

然而，SACK文档并没有指明发送方应当怎样响应SACK，因此大多数的实现还是重传所有未被确认的数据块。

七、TCP的流量控制

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

流量控制——flow control，让发送方的发送速率不要太快，要让接收方来得及接收。不然就会造成数据丢失。

举例——设A向B发送数据。在建立连接时，B告诉了A：“我的接收窗口rwnd=400”（receiver window）。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP的窗口单位是字节，不是报文段。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1（见图seq=1）。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。只有在ACK=1时确认号字段才有意义。接收方的主机B进行了三次流量控制。

问题——B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

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

注：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段。

2.必须考虑传输效率

Ⅰ、三种机制来控制TCP报文段的发送时机

应用进程把数据报传送到TCP的缓存后，剩下的发送任务就由TCP来控制了。可以用不同的机制来控制TCP报文段的发送时机。

第一种：TCP维持一个变量，它等于最大报文长度MSS。只要缓存中存放的数据达到MSS时，就组装成一个TCP报文段发送出去。

第二种：由发送方的应用进程指明要求发送报文段，即TCP支持的推送（push）操作。

第三种：发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不超过MSS）发送出去。

Ⅱ、如何控制TCP发送报文段的时机

为什么要控制——当只发送一个字符时，传送效率不高，所以应适当推迟发回确认报文，并尽量使用捎带确认的方法。

Nagle算法——若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。此算法还规定，当到达的数据已到达发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

糊涂窗口综合症——silly window syndrome，有时也会使TCP的性能变坏。

定义：当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。 极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症。

设想一种情况：TCP接收方的缓存已满，而交互式的应用进程一次只从接受缓存中读取1个字节（这就使接收缓存空间仅腾出1个字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长）。接着，发送方又发来1个字节的数据（请注意，发送方发送的IP数据报是41字节长）。接收方发回确认，仍然将窗口设置为1个字节。这样进行下去，网络的效率很低。

解决：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的时间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存空间的一半大小。

八、TCP的拥塞控制

1.拥塞控制的一般原理

Ⅰ、拥塞原因

网络资源有：计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等。

拥塞条件：∑对资源的需求>可用资源

结点缓存——如果太小，到达该结点的分组因无存储空间暂存而不得不丢弃。如果太大，凡是到达该结点的分组均可在结点的缓存队列中排队，不受任何限制，但输出链路的容量和处理机的速度并未提高，导致这队列中的绝大多数分组的排队等待时间太长，上层软件只好把它们重传（因为早就超时了），从而加剧拥塞。

处理机——速度太慢会因此网络拥塞。太快则会将瓶颈转移到其他地方。问题实质是整个系统的各个部分不匹配。

Ⅱ、拥塞控制与流量控制的关系

拥塞控制——防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制前提是：网络能够承受现有的网络负荷。它是全局性的问题，涉及到所有的主机、所有的路由信息、以及与降低网络传输性能有关的所有因素。但TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想哪里有堵塞，不知是什么原因。

流量控制——指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制就是要抑制发送端发送数据的速率，以便使接收端来得及接收。

相似之处——某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点和流量控制是相似的。

Ⅲ、拥塞控制所起的作用

①理想的拥塞控制

提供的负载：offered load，也叫输入负载、网络负载，代表单位时间内输入给网络的分组数目

吞吐量：throughput，代表单位时间内从网络输出的分组数目

在吞吐量达到饱和前，吞吐量=提供的负载。但当负载超过某一限度时，由于网络资源受限，吞吐量不再增长。这表明提供的负载中有一部分损失掉了（例如，输入到网络的某些分组被某个结点丢弃了）。虽然如此，在理想的拥塞控制作用下，网络的吞吐量仍然维持在其所能达到的最大值。

②实际的拥塞控制

在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显小于理想的吞吐量时，网络就进入了轻度拥塞的状态。

当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这是网络就进入了拥塞状态。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络已无法工作。这就是死锁（deadlock）。

Ⅳ、如何进行拥塞控制

增大网络的某些可用资源、减少一些用户对某些资源的需求。拥塞控制难以设计是因为它是一个动态问题。分组丢失是网络发生拥塞的征兆而不是原因，许多情况下正是拥塞控制机制本身成为引起网络性能恶化甚至发生死锁的原因。

①开环控制

在设计网络时事先将有关发生拥堵的因素考虑周到，力求网络在工作时不产生堵塞。但一旦整个系统运行起来，就不再中途进行改正了。

②闭环控制

（a）监测网络系统以便检测到拥塞在何时、何处发生

主要指标有：平均队列长度、超时重传的分组数、平均分组时延

（b）把拥塞发生的信息传送到可采取行动的地方

一般发送到产生分组的源站，当然会更加堵塞；或者是在路由器转发的分组中保留一个比特或字段，用来表示网络没有堵塞或产生了堵塞；或由一些主机或路由器周期性地发出探测分组，以询问拥塞是否发生。

频繁采取行动会使系统产生不稳定的振荡，迟缓采取行动又不具有任何实用价值。因此，要折中采取正确的时间是想当困难的。

（c）调整网络系统的运行以解决出现的问题

2.拥塞控制方法——慢开始（slow-start）和拥塞避免（congestion avoidance）

Ⅰ、预备

假定：（1）数据是单方向传送，而另一个方向只传送确认；

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

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量，它的大小取决于网络的拥塞程度，并且在动态变化。发送方让自己的发送窗口等于拥塞窗口。考虑到接收方的接收能力，发送窗口要小于拥塞窗口。

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

发送方怎么知道网络出现了拥塞——发送方没有按时收到应当到达的确认报文

下面讨论拥塞窗口cwnd的大小是怎样变化的。

Ⅱ、慢开始算法的思路

当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。经验证明，最好是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文时，把cwnd设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值（通常是指数倍）。

为方便起见，我们用报文段的个数作为窗口大小的单位（实际上，TCP是用字节作为窗口的单位）。看下图，首先发送方先设置cwnd=1，发送一个报文段M1。发送方每收到一个对新报文段的确认（重传的不算在内）就使发送方的拥塞窗口加1。每经过一个传输轮次，拥塞窗口就加倍。传输轮次更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

慢开始的“慢”不是指cwnd的增长速度慢，而是指TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后逐渐增大cwnd。这比一下子把许多报文段突然注入到网络中要“慢得多”。

慢开始门限ssthresh状态变量：

当cwnd<ssthresh时，使用上述的慢开始算法；

当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法；

当cwnd=ssthresh时，两种方法都可以用。

慢开始门限是为防止拥塞窗口增长过大引起网络拥塞，如何设置，后面要讲。

Ⅲ、拥塞避免算法的思路

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

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

Ⅳ、慢开始和拥塞避免算法的实现举例

上图中，当TCP连接初始化时，把拥塞窗口cwnd置为1（不使用字节而使用报文段的个数）。

乘法减小——指不论在慢开始阶段还是拥塞避免阶段，只要出现超时（即很可能出现了网络拥塞），就把慢开始门限值减半，即设置为当前的拥塞窗口的一半（与此同时，执行慢开始算法）。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。

加法增大——是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。

上述两种合称为AIMD算法（加法增大乘法减小）。注意：拥塞避免并非指完全避免了拥塞，只是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

3.拥塞控制方法——快重传（fast retransmit）快恢复（fast recovery）

Ⅰ、快重传

不使用快重传时，如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。于是，TCP马上把拥塞窗口cwnd减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。

使用快重传时，要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等待自己发送数据时才进行确认。看下例，接收方不能确认M4因为它是收到的失序报文段（M3还没有收到）。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待为M3设置的重传计时器到期。

Ⅱ、快恢复

过程有以下两个要点：（1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生堵塞。请注意，接下来不执行慢开始算法。

（2）由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连好几个报文段连续到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处就是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

注意：也有的快重传是把开始时的拥塞窗口cwnd值再增大一些（增大3个报文段的长度），即等于ssthresh+3*MSS。这样做的理由是：既然发送方收到三个重复确认，就表明有三个分组已离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中（接收方发送出三个重复的确认就证明了这个事实）。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当地把拥塞窗口扩大些。

在使用快恢复算法时，慢开始算法这是在TCP连接建立和网络出现超时时采用。

Ⅲ、拥塞控制方法假定条件

在一开始我们假定接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。但实际上接收方的缓存空间是有限的。接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口（advertised window）。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口值rwnd。

发送窗口的上限值=Min[rwnd，cwnd]

rwnd和cwnd中较小的一个控制发送方发送数据的速率。

4.随机早期检测RED

Ⅰ、背景

TCP拥塞控制和网络层采取的策略有密切的关系。

路由器处理分组时间长→发送方对这些分组中的数据部分（即报文段）重传→使TCP连接的发送端认为网络发生拥塞→发生端采取拥塞控制策略（实际上未拥塞）

尾部丢弃策略——网络层的策略对TCP拥塞控制影响最大的是路由器的分组控制丢弃策略。简单情况下，路由器队列“先进先出”，队列满时，后面的分组丢弃。

全局同步（global syncronization）——尾部丢弃→一连串分组丢失→发送方超时重传→TCP进入拥堵控制的慢开始状态→TCP连接的发送方突然把数据的发送速率降低到很小的数值，更为严重的是，在网络层有很多的TCP连接中的报文段是复用在网络层的UP数据报中传送→影响到很多条TCP连接→TCP连接在同一时间突然进入慢开始状态→全网通信量突然下降很多，网络正常后，通信量又突然增大。

为避免全局同步，路由器采用随机早期检测的措施。

Ⅱ、随机早期检测RED原理

使路由器的队列维持两个参数，即队列长度最小门限THmin和最大门限THmax。当每一个分组到达时RED组就先计算平均队列长度Lav（后面讲如何计算）。RED算法是：

（1）若平均队列长度小于最小门限THmin，则把新到达的分组放入队列进行排队。

（2）若平均队列长度超过最大门限THmax，则把新到达的分组丢弃。

（3）若平均队列长度在最小门限THmin和最大门限THmax之间，则按某一概率p将新到达的分组丢弃。

随机早期检验RED中的“随机”体现在算法（3），它不是等到已经发生网络堵塞后才把所有在队列尾部的分组全部丢弃，而是在检测到网络拥塞的早期征兆时（即路由器的平均队列长度超过一定的门限值时），就先以概率p随机丢弃个别的分组，让拥塞控制只在个别的TCP连接上进行，因为避免发生全局性的拥塞控制。

Ⅲ、最小门限THmin、最大门限THmax、p的选择

最小门限THmin必须足够大，以保证连接路由器的输出链路有较高的利用率。THmin和THmax之差也应当足够大，使得在一个TCP往返时间RTT中队列的正常增长仍在最大门限THmax之内。经验表明，使最大门限THmax等于最小门限THmin值的两倍是最合适的。如果门限值设定的不好，则会引起类似于尾部丢弃那样的全局振荡。

p的选择有以下三原则：

①平均队列长度Lav<THmin，p=0；

②平均队列长度Lav>THmax，p=1；

③THmin<平均队列长度Lav<THmax，0<p<1。

假设，p按照线性变化，从0变到pmax。看下图。

Ⅳ、为什么使用平均队列长度

数据有突发性特点→路由器中的队列长度经常会出现很快的起伏变化，如果丢弃概率p是按照瞬时队列长度来计算，那就可能出现一些不合理的现象。比如，很短的突发数据不太可能使队列溢出，造成不必要的拥塞控制。

平均队列长度Lan=（1-δ）*（旧的Lan）+δ*（当前的队列长度样本）

Ⅴ、p怎么求

P=Ptemp/（1-count*Ptemp）

count是一个变量，代表新到达的分组有多少个已经进去到了队列（没有被丢弃）；Ptemp是过渡的分组丢弃概率：

Ptemp=Pmax*（Lav-THmin）/（THmax-THmin）

分组丢弃概率p不仅与平均队列长度有关，而且还随着队列中不被丢弃的分组数目的增多而逐渐增大，就可以避免分组的丢弃过于集中。

Ⅵ、评价

好处就是当平均队列长度超过门限值THmin时，就会有少量的分组被丢弃，这就使得有少量的TCP连接会减小其窗口值，使得到达路由器的分组的数量减少。结果，队列平均长度就减小了，从而避免了网络拥塞的发生。应当注意到，网络的吞吐量仍然保持在较高的数值，因此丢弃的分组的数量是很少的。

路由器在某一时刻的瞬时队列长度完全可能远远超过平均队列长度。算出的丢弃概率很小，但路由器的队列已经没有空间可接纳新到达的分组，这时RED的操作和“尾部丢弃”的方式是一样的。RED只是在可能的条件下尽量使“尾部丢弃”不要发生。

RED机制使得路由器可以更好地管理其队列长度。但多长的队列是最佳长度仍然有待进一步的研究。

九、TCP的运输连接管理

运输连接三阶段：连接建立、数据传送、连接释放

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

①要使每一方能够确知对方的存在；

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

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

TCP连接的建立采用客户服务器方式。客户——主动发起连接建立的应用进程。服务器——被动等待连接建立的应用进程。

1.TCP的连接建立

图片发自简书App

三次握手过程如下：

第一次握手：建立连接，客户端A发送SYN包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器B确认。

第二次握手：服务器收到SYN包，必须确认客户端A的SYN包（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包。此时服务器进入SYN_RECV状态。

第三次握手：客户端A收到服务器B的SYN+ACK包，向服务器B发送确认包ACK(ack=y+1),此包发送完毕，客户端A

和服务器端B都进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器端开始传送数据。

疑问：为什么是三次握手而不是两次握手？

防止已失效的连接请求报文段突然又传到了B，因此产生错误。

已失效的连接请求报文段是这样产生的。譬如，A发出请求，但丢失未收到确切，又重传一次，后收到确认建立了连接，这是正常情况。异常情况是，A发出的请求时延了，B误认为是A又发出的一次新的连接请求，于是向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。由于A并没有发出建立连接的请求，因此不会理睬B的确认也不会向B发送数据，但B误以为连接建立了，并等A发送数据，这样B的资源浪费了。

2.TCP连接的断开

图片发自简书App

四次挥手过程如下：

连接的一个A的某个应用程序首先调用close，执行主动关闭。他的TCP发送一个FIN分节，表示数据发送完毕；

接受的到的这个FIN分节的对端B执行被动关闭，并由其TCP确认这个FIN(向A发送确认)。然后将这个FIN作为文件结束符发送给他自身的应用进程；

一点时间后（中间有个close-waite），B调用close关闭套接字，并由其TCP发送一个FIN给A；

接受到这个FIN的A端TCP发送ACK确认这个FIN;

注意：TCP连接还没有释放时，必须经过时间等待计时器（time wait timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命。

为什么要等待2MSL的时间？

理由一：为了保证A发送的最后一个ACK报文段能够到达B（可能重传）

理由二：防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

保活计时器——设想：客户已主动与服务器建立了TCP连接，到后来客户端出现故障，服务器以后不再收到客户发来的数据。因此，必须有措施使服务器不再白白等待下去。这就是保活计时器，服务器每收到一次客户的数据，就重新设置保活计时器，发送一个探测报文段。若10个探测报文段没有响应，服务器就认为客户端出了故障，接着就关闭这个连接。

3.TCP的有限状态机

粗实线剪头：对客户进程的正常变迁

粗虚线剪头：对服务器进程的正常变迁

细线剪头：异常变迁