1.运输层协议概述
1.进程之间的通信
- 从IP层来说，通信的两端是两台主机。但是严格来讲，两台主机之间的通信就是两台主机中的应用进程相互通信。
- 从运输层的角度，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。
1.网络层和运输层的区别
概括的来说，就是网络层根据IP地址只能找到对应的是哪台主机，而运输层能够找到该主机上的具体哪个应用进程进行通信。
2.运输层的作用
- 在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信，这就表明运输层有一个很重要的功能——复用和分用。
- 根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP。
3.基于端口的分用和复用功能
复用是在发送端实现的，把多个应用进程的任务放在同一条信道上传输；分用是在接收端实现的。为了区分不同进程，还引入了端口号，在复用和分用时都会用到，保证不会出现发送端的A进程的数据发送给接收端的B进程。
3.两种不同的运输协议
2.运输层的两个主要协议
- 两个对等运输实体在通信时传送的数据单位叫做运输协议数据单元TPDU。
- TCP传送的数据单位协议是TCP报文段，UDP传送的数据单位协议是UDP报文或UDP用户数据报**。
TCP和UDP：
3.运输层的端口
- 运行在计算机中的进程使用进程标识符来标志的。
- 但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。因为计算机操作系统的多样性，为了使运行不同操作系统的计算机的应用进程能够相互通信，必须用统一的方法对TCP/IP体系的应用进程进行标志。
解决这个问题的方法就是在运输层使用协议端口号。
1.软件端口和硬件端口：
硬件端口是不同的硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
- 在协议栈层间的抽象的协议端口是软件端口。
- 路由器或交换机上的端口是硬件端口。
2.TCP/IP运输层端口
- 端口用一个16位端口号进行标志。
- 端口号具有本地意义，即端口号只是为了标志本计算机应用层中的各个进程。在互联网中，不同计算机的相同端口号是没有联系的。由此可见，两个计算机中的进程要相互通信，不仅必须知道对方的IP地址(为了找到对方的计算机)，而且还要知道对方的端口号(为了找到对方计算机中的应用进程)。
3.两大类端口
- (1)服务器使用的端口号
熟知端口：1-1023
登记端口号：1024-49151，为没有熟知端口号的应用程序使用，使用这个范围内的端口号必须在IAN登记防止重复。 - (2).客户端使用的端口号
又称为短暂端口，数值为49152-65535，留给客户进程选择暂时使用。
常用的熟知端口：
2.用户数据报协议UDP
1.UDP概述
UDP只在IP数据报服务至上增加了很少一点功能：复用和分用，差错检测(对数据部分)。
1.UDP的主要特点
2.面向报文的UDP
- 发送方UDP对应用程序交下来的报文，在添加首部后就向下交付IP层，UDP对应用层交下来的报文，既不合并，也不拆分，而是仅仅添加一个UDP首部，保留这些报文的边界。应用层交给UDP多长的报文，UDP就照常发送，即一次发送一个报文。
- 接收方UDP对IP层交上来的UDP用户数据，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。另外，应用程序必须选择合适大小的报文。报文太长的话，IP层在传输时可能要进行分片，这会降低IP层的效率；报文太短，IP层首部的相对长度太大，也会降低IP层的效率。
2.UDP的首部格式
源端口和目的端口字段就是用来复用和分用的；长度字段指的是整个UDP用户数据报的长度；检验和字段是用来对数据部分进行差错检测的。伪首部仅仅是用来计算检验和的，实际上并不会发送给接收方。
计算UDP检验和：
如上图，在没有计算得到检验和之前，首部的检验和字段全为0；UDP首部共8个字节，数据部分共7个字节，这与总长度15个字节相同说明正确。在计算检验和的时候，我们把伪首部，首部，数据部分都划分为16位(2个字节)，因此当数据部分不足2字节的整数倍时可以用0位进行填充。
3.传输控制协议TCP概述
1.TCP最主要的特点
- TCP是面向连接的运输层协议。
- 每一条TCP连接只能有两个端点，每一条TCP的连接只能是点对点的(一对一)。
- TCP提供可靠交付的服务。
- TCP提供全双工通信。
-
面向字节流。
它的含义是虽然应用程序和TCP的交互是一个数据块，但是TCP把应用程序交下来的数据看成仅仅是一连串的无结构的数字流。
TCP面向流的概念：
- TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(可能被拆分或合并)。
- 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。
注意，当发送端发送数据到发送缓存中后，并不能一口气将它们全部发送出去，同样的接收方在接收数据时也是将数据先放入接收缓存，如果接收缓存是满的，那么此时再发送进来的数据就会丢失。假设接收缓存中还能再接收2个字节的数据，那么如果发送缓存中的数据大于2个字节，不能全部发送，只能拆分发送。当发送缓存中的数据小于接收缓存中的最大数据量时，发送缓存中的数据就会合并一起发送出去。其余的数据在发送缓存中等待下一次发送。等到接收缓存中的数据被读取完了之后，发送缓存中的数据才发送。
2.TCP的连接
- TCP把连接作为最基本的抽象。
- 每一条TCP连接有两个端点。
- TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口。而是套接字或插口。所谓套接字就是端口号拼接到IP地址后面就构成了套接字。
注意，同一个IP地址可以有多个不同的TCP连接(多个不同的端口)，同一个端口也可以出现在多个不同的TCO连接中。
4.可靠传输的工作原理
1.停止等待协议
-
理想的传输条件有以下两个特点：
(1).传输信道不产生差错。
(2).不管发送发以多快的速度发送数据，接收方总是来得及处理收到的数据。 - 再这样的理想传输条件下，不需要采用任何措施就能够实现可靠传输。
- 然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。
"停止等待"就是每发送完一个分组就立即停止发送，等待对方确认之后再发送下一个分组(全双工通信的双方既是发送方又是接收方)。
1.无差错情况
注意只需要发送方收到一次来自接收方的确认即可，不需要来回反复确认。
2.出现差错
当A发送给B的分组出现比特差错时，B就无法接收到正确的分组，也就不会发送确认给A，A在没有收到B的确认的情况下，也就不会继续发送下一个分组。就这样，B在等待A重新发送新的正确的分组，而A在等待B的确认，如果没有外力干扰，它们会一直等待下去直到天荒地老海枯石烂😂😂😂(这种情况可以叫做死锁)。因此就需要一个外力——超时器。如果超过了超时器规定的时间还没收到确认，A就会重新发送一次分组——超时重发。
当出现分组丢失的情况(比如放在缓存中的分组被丢弃)，此时B根本就不知道A给自己发送过数据，那么也就不会发送确认，因此还是和前面一样会出现发送方和接受方都在等对方的消息的情况，解决办法还是超时器。
3.确认丢失和确认迟到
在上面说到的接收方B如果收到发送方A发送的分组之后会发送回一个确认。那么这个确认在发送的过程中也会出现错误情况，例如确认丢失和确认迟到。
确认丢失：当发送方A发送分组给B并且B收到之后，B会发送一个确认给A，但是这个确认在途中碰到了问题，A没有收到B的确认就不会发送下一个分组，因此A就会超时重发，重发的分组和这个之前的分组是一样的。这里就有两个问题：第一个分组我在第一次发送的时候已经发送出去了，那我重发的分组(和之前的一样)从哪来呢？？？解决办法就是：当A发送完第一个分组之后，不要丢弃它，而是保留它留着下一次超时重发的时候用。另外一个问题时，在A超时重发后，B实际上是接收了两次同一个分组，那么B该怎么去判断两次接收到的分组是否是重复的，又怎么判断重发后的分组接受到了呢？？？解决办法：给每个分组编号，编号相同说明重复，我已经正确接收过了，接收方就会不要重复的分组，但是同时必须给出一个确认。那么问题又来了，这个多个确认我啷个晓得是不是来自同一个分组的确认呢？很简单，还是编号就完事了。编号机制无敌。
确认迟到：B在发送确认的时候是"2G网"，太慢了导致A以为B没接收到，于是超时重发了，这下分组和确认会"碰头"，结果第一次的确认还是很慢，B都接收到A超时重发的分组，并发现重复丢弃之后再发送一个和第一次那个龟速的确认一样的确认，结果确认2先到，A收到确认2之后发送下一个分组，此时确认1来了，通过编号机制，A知道这个姗姗来迟的确认1和我刚才接收到的确认2是同一个分组的确认，于是舍弃了确认1。其实，确认1就相当于没发一样，一点用都没有，因为它太慢了！！！还有应该注意一点，超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一点。
自动重传请求ARQ：
自动重传请求ARQ：在上面的例子中，A重传的原因从来都不是B向A发送了重传请求，而是A在超时重传时间后自动重传。
4.信道利用率
停止等待协议的优点是简单，缺点是信道利用率太低。
A正确发送一个分组到B确认收到A可以发送下一个分组所经过的时间包括四部分，(1).A将分组发送到信道上的发送时延TD；(2).分组从A发送到B的传播时延；(3).确认从B发送到信道上的发送时延TA；(4).确认从B发送到A的传播时延；，其中(2)(4)合起来就是往返时间RTT。在上述过程中真正有数据发送到信道上的时间为TD，因此信道利用率很低。若出现重传，则对于传送有用的数据信息来说，信道利用率更低(TD/TD+RTT+TD+RTT+TA)。
5.流水线传输
2.连续ARQ协议
在通信双方A，B中都有两个窗口，发送窗口和接收窗口。发送方可以不必等待确认而连续发送分组，只要是在发送窗口中的分组都能连续发送出去，而连续发送的分组的个数是由接收方决定的(因为要考虑接收方的接收能力)。如下图：
连续ARQ协议的工作原理
在(a)图中，发送窗口中的1-5号分组都位于发送窗口内，因此是都可以连续发送的。当1号分组发送出去并且A接收到B发回来的确认之后，发送窗口就会往前移(滑)动一个分组的位置(因为你既然已经接收到1号分组了，这个分组再保留就没有任何意义了)。另外，还有一个机制叫做累计确认：
累计确认
所谓的累计确认就是位于发送窗口的一组分组全部接收到了之后才发送一个确认。表示在此之前的分组我都收到了。下一次的分组发送从这一组的后一个开始发送。累计确认的优点就是当我收到3号分组的确认之后，发送方就认为在3号分组之前的分组全部已经正确接收到了，因此即使2号分组的确认丢失了也没关系。当然按序到达的最后一个分组的确认千万不能丢失。否则发送方就会重新发送这个分组，累计确认的缺点就在这里体现。另外，它还存在一个机制，回退。就是如果发送方发送的前5个分组中的第3个分组丢失了，这时接收方只能对前两个分组发出确认，发送方无法知道后面三个分组的下落，因此只好把后三个都重传一遍，这就叫做回退，表示需要向后退回重传已经发送过的N个分组。
5.TCP报文段的首部格式
源端口和目的端口字段：各16位，源端口用来实现复用，目的端口用来实现分用；序号字段：4个字节，就是之前说的编号机制，TCP连接中传送的数据流中的每一个字节都编上一个序号，首部中的序号字段指的就是第一个字节的序号；确认号字段：4个字节，是期望收到的对方的下一个报文段的数据的第一个字节的序号；数据偏移字段：即首部长度，4位，指的是数据部分起始处距离整个报文的起始处间的距离，计算单位是4个字节；保留字段：6位，保留为今后使用目前置为0；
紧急URG：当URG=1时，表明报文段中有紧急数据，这些数据需要优先传送，当然还需要知道紧急数据的位置的话光靠这个字段是不够的，还需要紧急指针。
确认ACK：当ACK=1时，确认号字段(ack)才有效；ACK=0时，确认号无效。
推送PSH：当接收到TCP=1的报文段就应该尽快交付不必要等缓存填满再交付。
复位RST：当RST=1时，表明TCP连接中出现严重差错，必须释放连接再重新连接。
同步SYN：当SYN=1时，表明这是一个连接请求或者连接接收报文。
种植FIN：用来释放一个连接。FIN=1表示此报文段发送端的数据已经发送完毕，要求释放连接。
窗口字段：2字节，用来让对方设置发送窗口的依据，也就是接收窗口的大小；检验和字段：2字节，检验的部分包括首部和数据部分；紧急指针字段：16位，指出紧急数据共多少字节，放在本报文段数据的最前面；选项字段：长度可变，MSS是TCP报文段中的数据字段的最大长度；
对于MSS，一般情况应该控制在范围(64B-14B-4B-20B)-(1500B-18B)内，14B和4B是帧首帧尾，20B的IP层首部，1500B是I层最大长度MTU，MTU还会因为网络的不同而不同。
6.TCP可靠传输的实现
1.以字节为单位的滑动窗口
- TCP的滑动窗口是以字节为单位的。
- 现假定A收到了B发来的确认报文，其中窗口值是20字节，而确认号是31(这表明B期望收到的下一个序号是31)，而到序号30为止的数据已经接收到了)。
- 根据这两个数据，A就构造出自己的发送窗口(从31号开始，到50结束共20字节)。
发送窗口的起始位置叫做后沿，结束位置叫做前沿。后沿只能前移或者不动，而前沿可以有三种行为：收缩，不动和前移。在收到确认之后，一般情况下后沿和前沿都会向前移动，例如窗口值20，确认号34。当确认号34而窗口值为17时，此时前沿不会移动。同理，当窗口值更小之后，前沿就会向后收缩。
在上图中，A发送了11字节的数据。这位于发送窗口中的11字节数据不能马上移出发送窗口，因为可能发送出去的分组会超时以便于重传。还有另外9个字节的数据允许发送但没被发送。这样发送窗口中的数据就被分为了两类数据，分别给三个临界点标注P1，P2，P3这三个指针。P3-P2也可以称为可用窗口。当可用窗口的数据长度为0时，说明整个发送窗口的数据已经被全部发送出去，如果此时还没有收到确认，必须停止继续发送直到收到确认为止。
发送缓存：
发送方的应用进程把字节流写入TCP缓存。发送窗口仅仅是发送缓存中的一部分。如上图中，粉色部分就是已经发送但未收到确认的数据，蓝色部分就是允许发送但是尚未发送的数据，灰色部分就是不允许发送的数据，它没有在发送窗口中。
发送缓存用来暂时存放：发送应用程序传送给发送方TCP准备发送的数据；TCP已经发送出但尚未收到确认的数据。
接收缓存：
接收方的应用程序从TCP的接收缓存中读取字节流。接收窗口仅仅是接收缓存中的一部分。如上图中，粉色部分就是已收到的并读取的数据，蓝色部分就是已收到未读取的部分。蓝色部分中的一点粉色部分就是未按序到达的数据。接收缓存用来暂时存放：按序到达，但尚未被接收应用程序读取的数据；不按序到达的数据。
- A的发送窗口并不总是和B的接收窗口一样大，因为有一定的时间滞后(单程的传播延迟)。因为A只有在发送连接请求之后并收到确认，再根据B的接收窗口来确定自己的发送窗口。
- TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层。
- TCP要求接收方必须有累计确认的功能，这样可以减小传输开销。
注意，接收方发送确认可以有两种方式，第一种最常见的就是正常的发送确认，第二种就是捎带确认，也就是在下一次自己要发送数据的时候捎带上确认。
2.超时重传时间的选择
重传时间的选择时TCP最复杂的问题之一，这个时间一般比往返传播时延稍长一点，并且往返传播时延很难确认，也就是往返时延的方差很大。另外，由于发送方对接收方发来的确认无法分别出到底是第一次发送的的确认还是重传后的确认，因此往返时延变得很难确定与计算。
3.选择确认SACK
当发送方发送数据1,2,4,5，而3在途中丢失的情况下，接收方无法给出数据3的确认，但是数据4,5的确认已经被发送方给接收了。因此在发送方会找不到数据3以数据3后面的数据，会选择从3开始往后全部重传，怎么避免这样的问题，使得只重传第3个数据。方法就是：选择确认。
例如上图，前1-1000位的是连续的字节流，按照累计确认的原则，只要接收到第1000位的确认，就认为前1000位全部接收到了。但是后面并不是连续的字节流了，而是不连续的字节块。每一个字节块都有左右两个边界。
选择确认SACK
7.TCP的流量控制
之前说过发送方发送数据的速度取决于接收方能够接收的速度。一旦当发送方的发送速度过快时，接收方就会来不及接收，那么就可能造成数据的丢失，这个传输就不可靠了。流量控制就是接收方告诉发送方，你发送的数据太快了我来不及接收。这个时候就要用到滑动窗口。
1.利用滑动窗口实现流量控制
例如上图，首先B会发送给A自己的接收窗口大小为400，确认号为1(就是起始位置)，A收到之后就开始构建自己的发送窗口，其起始位置就是确认号1，长度就是400。将位于发送窗口中的400个字节的数据分为4个TCP报文段，每个100长度。这些数据都位于发送窗口内，因此都是可以连续发送的。假设第三个报文段(序号为201)在传输过程中丢失了，那么B就会给A发送一个确认，内容就是在201之前的数据我全部已经接收到了，接下去你给我发送从201开始的数据，而且接收窗口的大小调整为300(这里就是流量控制)，因此发送窗口中的数据可以被划分为3个TCP报文段，分别是序号201,301,401。等到A将这3个报文段的数据全部发送完了之后，就会停下来等B的确认然后再次发送数据。所以，整个过程就是建立链接，确定发送窗口，发送数据，确定发送窗口，发送数据...，发送窗口是在不断的调整的，也就是流量控制。直到A的发送窗口变为0，假如过一段时间后B又发送给A报文，窗口不为0，但是这个报文在传输过程中丢失了，那么就会导致A在等B的不为0的发送窗口报文，B在等A重新发送数据(B以为自己发送的报文A接受到了实际上是丢失了)这样的死锁局面。
持续计时器
2.TCP的传输效率
8.TCP的拥塞控制
就好比你去食堂打饭，窗口只有10个，但人数却有1000，因此好多人就得排队等待，这个时候假如增加几个凳子，那么等待的人可以坐下来等不会很累，但是增加凳子这个做法对于提高打饭速度没有任何帮助，另外如果你多开几个窗口，也不会提高打饭速度，你还必须要多配几个打饭人员才行。这就说明了网络拥塞是一个非常复杂的问题，它是由许多因素引起的，并不能通过简单的增加某个资源量来解决这个问题，甚至会起到反作用。
拥塞控制和流量控制的区别：
拥塞控制所起的作用：
如上图，理想的拥塞控制的前半段曲线就是y=x，即有多少数据流入网络就有多少数据流出网络，这样不会对网络上的设备造成过大的负载。
1.拥塞控制的一般原理
- 实践证明，拥塞控制是很难设计的，因为它是一个动态的（而不是静态的）问题。
- 当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。拥塞的原因是对资源的需求量超过了现有的资源量。
- 在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。这点应特别引起重视。
检测网络的拥塞的指标：
- 由于缺少缓存空间而被丢弃的分组的百分数；
- 平均队列长度；
- 超时重传的分组数；
- 平均分组时延；
- 分组时延的标准差，等等。
2.TCP的拥塞控制方法
1.概述
TCP 采用基于窗口的方法进行拥塞控制。TCP发送方维持一个拥塞窗口CWND(Congestion Window)。
- 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。
- 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
- 所以，发送窗口大小不仅取决于接收方公告的接收窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：Min(公告窗口值，拥塞窗口值)
2.控制拥塞窗口的原则
控制拥塞窗口的原则就是：只要网络没有出现拥塞，拥塞窗口就可以增大一点，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
3.拥塞的判断
-
重传定时器超时
现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的(远小于1%)，只要出现了超时，就可以猜想网络可能出现了拥塞。 -
收到三个重复确认
个别报文段会在网络中丢失，预示可能会出现拥塞(实际未发生拥塞)，因此可以尽快采取控制措施，避免拥塞。
4.TCP拥塞控制算法
- 慢开始 (slow-start)
- 拥塞避免 (congestion avoidance)
- 快重传 (fast retransmit)
- 快恢复 (fast recovery)
慢开始 (slow-start)
慢开始 (slow-start)
慢开始 (slow-start)
慢开始中拥塞窗口的值增加的非常快，指数增长，因此当增大到一定程度之后就需要降低它的增速，但它还是在增长。这个值就是慢开始门限ssthresh，用来防止拥塞窗口cwnd增长过大引起网络拥塞。具体用法如下：当cwnd<ssthresh时，使用慢开始算法；当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法；当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免 (congestion avoidance)
拥塞避免算法：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。
当网络出现拥塞时，就执行：ssthresh = max(cwnd/2，2)；cwnd = 1；执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
拥塞避免算法举例
如上图，刚开始拥塞窗口值为1，慢开始门限为16，然后每经过一个轮次，拥塞窗口的值就翻一倍1-2-4-8-16，等到拥塞窗口的值变为16时，即等于慢开始门限时，执行拥塞避免算法，之后拥塞窗口+1按线性规律增长，到了24之后发现此时网络出现拥塞情况，于是，将拥塞窗口的值/2=12，12就是更新之后的慢开始门限，而拥塞窗口的值重新被置为1，再执行慢开始算法。
快重传 (fast retransmit)
采用快重传FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失，也就是在超时重传的时间之前就进行告知。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。发送方只要一连收到三个重复确认(因为累积确认只需要对按序到达的最后一个分组进行确认，而下图例子中的按序的最后一个分组是M2)，就知道接收方确实没有收到报文段，因而应当立即进行重传(即“快重传”)，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。如下图：
快重传举例
快恢复 (fast recovery)
当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：(1) 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；(2) 新拥塞窗口 cwnd = 慢开始门限 ssthresh (这里和慢开始算法不同的就是新的拥塞窗口并不是变为1，这样省去了前面慢开始算法的几个轮次)；(3) 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
5.加法增大，乘法减小
6.TCP拥塞控制流程图
7.发送窗口的上限值
3.主动队列管理AQM
1.先进先出FIFO处理规则
2.全局同步
所谓的主动队列管理AQM就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时(即当网络拥塞有了某些拥塞征兆时)，就主动丢弃到达的分组。AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测RED(Random Early Detection)。
3.随机早期检测RED
9.TCP的运输连接管理
1.TCP的连接建立
1.TCP建立连接的过程中要解决的三个问题：
- (1) 要使每一方能够确知对方的存在。
- (2) 要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)。
- (3) 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
2.客户-服务器方式
- TCP连接的建立采用客户-服务器方式。
- 主动发起连接建立的应用进程叫做客户(client)。
- 被动等待连接建立的应用进程叫做服务器(server)。
3.握手
- TCP建立连接的过程叫做握手。
- 握手需要在客户和服务器之间交换三个TCP报文段，称之为三报文握手。
- 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误(就是假设第一次发送的请求没有按时到，等到两台主机都发送完数据了才到而造成再次连接)。
x+1的原因是因为请求建立连接的报文和确认报文不能携带数据，反而会消耗一个序号的数据。另外，建立连接时，客户端和服务器端并不是同步的。有一定的时延。
2.TCP的连接释放
- TCP连接释放过程比较复杂
- 数据传输结束后，通信的双方都可以释放连接。
- TCP连接释放过程是四报文握手(因为通信是双向的，通信的双方都可以释放连接，而每一条连接断开需要一个请求和一个确认)
假设现在A要给B发送的数据都已经发送完了，那么A就可以断开与B的连接，此时A就会向B发送一个连接释放请求报文，其中的
FIN字段=1 ，seq=u就是A发送给B的最后一个数据的序号。这个连接释放请求报文不能携带数据但是会消耗掉一个序号，因此B发回的确认号为u+1，等到A收到确认，此时A到B的这条通信已经断开了，即A不能向B的发送数据了。但是B到A的通信连接还没断，B还能给A发送数据。此时TCP的连接处于半关闭的状态。同时等到B发送完数据之后也需要断开连接时，过程同A断开连接一样。当B收到A的确认之后B就会马上进入CLOSED状态，但是A发回确认之后还需要等待2MSL的时间，这个时间通常是单程传播时延。为什么要等待2MSL时间？
A必须等待2MSL时间
