运输层

最新推荐文章于 2023-02-27 19:40:40 发布

ease_07

最新推荐文章于 2023-02-27 19:40:40 发布

阅读量871

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/weixin_44125957/article/details/105072854

版权

计算机网络专栏收录该内容

1 篇文章 0 订阅

订阅专栏

运输层

1. 进程间的通信

从通信和信息处理角度看，运输层向应用层提供通信服务，属于面向通信部分的最高层，用户功能中的最低层。

网络边缘部分的主机的协议栈才有运输层

网络核心部分中的路由器在转发分组时只用到下三层

主机之间的通信指主机间的进程之间通信，即端到端的通信。简称计算机之间通信

运输层为相互通信的的应用进程提供了逻辑通信，向高层用户屏蔽了网络核心的细节

网络层为主机之间提供逻辑通信

当运输层采用面向连接的TCP协议时，下面的网络是不可靠的（只提供尽最大努力服务），此时逻辑通信相当于一条全双工的可靠信道

无连接的UDP协议，逻辑通信信道不可靠

2. TCP与UDP

两个对等运输实体在通信时传送的数据单位–运输协议数据单元TPDU

TCP传送的数据单位协议–TCP报文段

UDP传送的数据单位协议–UDP报文/用户数据报

UDP	TCP
1.无连接的协议，提供无连接服务	1.面向连接的协议，提供面向连接服务
2.传送的运输协议单元TPDU是UDP报文/用户数据包	2.TPDU是TCP报文(segment)
3.支持单播，多播，广播	3.支持点对点单播，不支持多播，广播
4.不提供可靠交付	4.提供可靠交付
5.简单。适用于很多应用，比如多媒体应用等	5.复杂。用于大多数应用。如万维网，电子邮件，文件传送等

UDP应用&应用层协议	TCP应用&应用层协议
域名解析服务 DNS	万维网 HTTP
动态主机配置 DHCP	电子邮件 SMTP
路由选择 RIP	文件传送 FTP

IP数据报经过互连网中的路由器存储转发(网际层)

UDP用户数据包是运输层的端到端抽象的逻辑信道中传送的

TCP报文段在运输层抽象的端到端逻辑信道中传送(可靠的全双工通信)，此信道不知经过了哪些路由器以及运输层是否建立了TCP连接

端口代表通信的终点，（端口的产生由于各个OS的进程标识符不一致，无法统一）剩下交付工作由TCP完成

软件端口：应用层各协议进程与运输实体进行层间交互的一种地址

硬件端口：不同硬件设备之间交互的接口

端口用16位端口号进行标志，共有65535个不同的端口号

端口号具有本地意义，即只为了标记本计算机应用层中的各进程

两大类端口

服务器使用端口号
- 熟知端口：0~1023，IANA负责分配
- 登记端口号，1024~49151,为无熟知端口的应用程序使用。此范围需在IANA登记以防止重复
客户端使用端口号
- 短暂端口号，49152~65535

UDP

UDP只在IP数据报服务之上增加了功能：

复用分用
差错检测

特点：

无连接，减少开销及发送时延
UDP使用尽最大努力交付，不保证可靠交付，因此主机不需要维持复杂的连接状态表
面向报文。对应用层交下来的报文，添加首部后向下交付IP层。既不合并也不拆分，保留报文边界。一次交付一个完整报文
无拥塞控制，网络出现的拥塞不会使原主机的发送速率降低。适用于实时应用，比如多媒体通信
支持一对一，一对多，多对多的交互通信
首部开销小，只有8个字节，比TCP的20个字节首部短

应用程序需选择合适大小的报文，报文太长则IP层传送时需要进行分片，降低了IP层的效率，报文太短则IP层数据包首部的相对长度太大，降低了IP层的效率

UDP首部格式

用户数据报有两个字段，数据字段和首部字段

首部字段有8个字节，由4个字段组成，每个字段都是2个字节。

源端口	目的端口	长度	检验和
2	2	2	2

UDP首部前面的伪首部：（用于计算检验和）

	源IP地址	目的IP地址	0	17	UDP长度
字节	4	4	1	1	2

TCP

面向连接
每一条TCP连接只有两个端点（endpoint),每一条TCP连接只能是点对点的（一对一）
提供可靠交付，在无连接，不可靠的IP网络服务基础上提供可靠交付服务
提供全双工通信
面向字节流
- 流(stream)指流入或流出进程的字节序列
- 含义指应用程序与TCP 的交互是一次一个数据块，但TCP把应用程序交下来的数据仅看成一串无结构的字节流

TCP不保证接收方应用程序收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系

但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样

注意：

TCP是一条虚连接而非物理连接
TCP对应进程一次把多长的报文发送到TCP的缓存中是不关心的
TCP 根据对方给出的窗口值和当前网络拥塞程度决定一个报文段包含多少字节（UDP报文长度由应用进程给出）
TCP可把过长数据块分短再传送or过短积累足够多字节再发送

TCP的连接的端点叫做套接字socket或插口（IP地址:port）

每一条TCP连接唯一地被通信两端的两个端点（socket）确定

TCP连接::=｛socket1, socket2｝={(IP1:port1),(IP2:port2)}

socket的多种含义

应用编程接口API称为socket API，简称socket
socket API中使用的一个函数名也叫做socket
调用socket函数的端点称为socket
调用socket函数时其返回值称为socket描述符，可简称为socket
OS内核中连网协议的Berkley实现，称为socket实现

3. 可靠传输的工作原理

理想传输条件特点：

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

为达目的，需采用一些可靠协议，在不可靠的传输信道实现可靠传输

1.停止等待协议：每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组

2.出现差错（A->B）

B接收M1时检测出差错，丢弃M1，不做其他
M1在传输过程中丢失，B不知道，什么都不用做

这两种情况B不发任何信息，但A都必须重发分组，直到B正确接受为止，这样才能实现可靠通信

2.1 A如何知道B是否正确收到M1？=》超时重传

2.2 若分组正确到达B，但B回送的确认丢失或延迟了， A未收到B的确认，会超时重发。B如何知道收到了重复分组，需要丢弃？=》编号

（A为每一个分组进行编号，B收到重复编号丢弃并发送ACK。A根据确认及其编号，若有重复确认，将其丢弃）确认丢失&确认迟到

注意：

发送完一个分组后，必须暂时保留已发送的分组副本，以备重发
分组和确认分组都必须进行编号
超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

自动重传请求ARQ，重传的请求是自动进行

3.1 信道利用率

当往返时间RTT远大于分组发送时间T时，信道的利用率会非常低
若出现重传，则对传送有用的数据信息来说，信道利用率更要降低

为提高传输效率，发送方可采用流水线传输——发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方确认。

停止等待要点

停止等待。每次只发送一个分组。在收到确认后再发送下一个分组
编号。对发送的分组和确认都进行编号
自动重传请求。发送方为每个发送的分组设置一个超时定时器。超时重传
简单。但信道利用率太低

信道利用率 U = T分组 / (T分组+RTT+T确认)

3.2 连续ARQ协议

思想

发送方一次可发出多个分组
使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号
每收到一个确认，发送方就把发送窗口向前滑动
接收方一般采用累积确认方式。不必对收到的分组逐个发送确认，对按序到达的最后一个分组发送确认——表明到这个分组为止的所有分组都正确收到了
采用回退(Go-Back-N)方法进行重传，如果有分组丢失，需退回到此分组重传此分组至之后的N个分组

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

3.3 TCP可靠通信的具体实现

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

	连续ARQ协议	停止等待协议
发送的分组数量	一次发送多个分组	一次一个分组
传输控制	滑动窗口协议	停等-等待
确认	单独确认+累积确认	单独确认
超时定时器	每个发送的分组	每个发送的分组
编号	每个发送的分组	每个发送的分组
重传	回退N，多个分组	一个分组

3.3.1 连续ARQ协议

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

3.3.2 累积确认

不必对收到的分组逐个发送确认，对按序到达的最后一个分组发送确认——表明到这个分组为止的所有分组都正确收到了

4. TCP报文段的首部格式

TCP面向字节流，数据单元是报文段
一个TCP报文段分为首部和数据两部分，TCP的全部功能体现在他首部中各字段的作用
TCP报文段首部的前20个字节是固定的，后面4n字节根据需要而增加。TCP首部最小长度是20字节

端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

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

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

数据偏移——首部长度,占4位

保留——6位，保留为今后使用，目前应置为0

URG——当URG为1时，表明紧急字段有效。他告诉系统次报文段中有紧急数据，应尽快传送（相当于高优先级的数据）

ACK——为1时确认号字段才有效，为0时无效。

PSH(PuSH)——为1 时尽快交付接收应用进程，不再等到整个缓存都填满后再向上交付。

RST(ReSeT)——为1时，表明TCP连接中出现严重差错(如由于主机崩溃或其他原因)，必须释放连接，再重新简历运输连接。

SYN——为1 时表示这是一个连接请求or连接接收报文

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

窗口——2字节，用于让对方设置发送窗口的依据，单位为字节。

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

紧急指针——16位，本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面)

选项字段——长度可变。TCP最初规定最大报文段长度MSS。缓存所能接收的报文段的数据字段的最大长度是MSS个字节。长度得减去TCP首部长度。

为什么要规定MSS？

MSS与接收窗口值没有关系
较小，网络利用率低
较长则IP传输时就有可能分解成多个短数据报片。终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传。开销增大

其他选项

窗口扩大选项——3字节，字节S表示移位值。新的窗口值等于TCP首部中的窗口位数增大到（16+S)，相当于把窗口值向左移动S位后获得实际的窗口大小。
时间戳选项——占10字节，其中最主要的字段时间戳字段（4字节）和时间戳回送回答字段（4字节）
选择确认选项

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

5. TCP可靠传输的实现

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

TCP采用流水线传输和滑动窗口协议实现高效，可靠传输
TCP的滑动窗口以字节为单位
发送方A和接收方B分别维持一个发送窗口和一个接收窗口
发送窗口表示：在没有收到确认时，可连续把窗口内的数据全部发送出去
接收窗口表示：只允许接收落入窗口内的数据

发送窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而获得更高的传输效率

发送缓存——发送方把应用程序的字节流写入TCP的发送缓存。发送窗口通常只发送缓存的一部分。暂存：

发送应用程序传送给发送方TCP准备发送的数据
TCP已发送但尚未收到确认的数据

接收缓存——接收方的应用进程从TCP的接收缓存中读取字节流

按序到达但尚未被接收应用程序读取的数据
不按序到达的数据

注意

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

接收方发送确认

可以在合适的时候发送确认，也可以在有数据发送时捎带确认信息

接收方不应过分推迟发送确认，否则会导致发送方不必要的重传
捎带确认实际上并不经常发送，大多数程序很少在两个方向上发送数据

5.2 超时重传时间的选择

TCP每发送一个报文段，就对这个报文段设置一次计时器
重传时间到却没有收到确认，就要重传这一报文段
时间过短引起报文段的不必要的重传，使网络负荷增大
时间过长空闲时间增大，降低了传输效率
TCP采用自适应算法，记录一个报文段发出的时间，以及收到相应的确认时间。时间差就是报文段的往返时间RTT

加权平均往返时间（平滑的往返时间）

每次测量到RTT样本时，RTTs值取其值。以后没测量新的RTT，按下式重新计算RTTs
新的RTTs=（1-α）*（旧的RTTs）+α * (新的RTT样本)
0<=α<1，若其很接近于0，表示RTT值更新较慢。若其接近于1，则表示RTT值更新较快
RFC推荐α取1/8 = 0.125

超时重传时间RTO（Retransmission Time-Out）应略大于RTTs

RFC6298 推荐侠士计算RTO：

RTO = RTTs + 4*RTTd(RTT的偏差的加权平均值)

RFC6298 建议RTTd的计算：

第一次取RTT样本值的一半
新的RTTd = （1-b)*（旧的RTTd）+ b * | RTTs - 新的RTT样本 |
b<1，推荐1/4

报文段1没有收到确认，重传后收到确认，如何判断是对谁的确认=》Karn

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

=>当时延增大，原来的重传时间内，不会收到确认，Karn不考虑重传，超时重传时间无法更新

=》修正Karn

报文段每重传一次，就把RTO增大一些
新的RTO = r *（旧的RTO）
r典型值为2
当不再发生报文段重传时，才根据往返时延更新平均往返时延RTT和重传时间RTO的数值

5.3 选择确认SACK (Selective ACK)

解决=》若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，能否设法只传缺少的数据，首部中的确认号字段用法不变，添加SACK选项以报告收到的不连续的字节块的边界，占4个字节

6. TCP的流量控制

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

**流量控制（flow control）**让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞
滑动窗口机制使TCP连接实现流量控制

死锁——（B向A发送零窗口的报文段不久后，B的接收缓存又有了一些存储空间），B向 A发送接收窗口rwnd=400的报文段丢失，导致A一直等待B发送非零窗口通知，而B也一直等待A发送的数据，导致死锁

解决=》TCP为每一个连接设有一个持续计时器(persistence timer)

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

6.1.1 传输速率三种机制

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

糊涂窗口综合症：每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变低

这样发送一个字节需要形成41字节长的IP数据报。效率很低=》Nagle算法
在这里插入图片描述

接收方窗口糊涂症

若接收方应用进程交互方式每次只读取一个字节，发送了窗口大小为1字节的报文，发送方硬要发送了一个字节的数据（IP数据报41字节,IP 数据报首部20字节，TCP报文段首部20字节），接收窗口又满了，循环往复。接收方应用进程消耗数据太慢
解决=》让接收方等待一段时间，1.使得或接受缓存已有足够空间容纳一个最长的报文段或2.接收缓存已有一半空闲的空间。接收方发送确认报文并通知发送方当前窗口大小

7. TCP的拥塞控制

7.1 拥塞控制的一般原理

在某段时间，若对网络中的某资源需求超过供给，则网络的性能就要变坏——拥塞（congestion）=>系统崩溃

拥塞产生原因：总体对资源的需求 > 可用资源

点缓存的容量太小
链路容量不足
处理机处理速率太慢
拥塞本身会进一步加剧拥塞

增加资源能解决拥塞吗？不能，可能使网络性能更坏

网络拥塞因素

增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间增加，引起大量超时重传，解决不了拥塞
提高处理机处理速率会将瓶颈转移到其他地方

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

拥塞控制	流量控制
防止过多数据注入到网络中，使网络中的路由器或链路不致过载	抑制发送端发送数据的速率，以使接收端来得及接收
一个全局性过程，涉及到与降低网络传输性能有关的所有因素	点对点通信量的控制，是端到端的问题

拥塞控制的一般原理

前提：网络能承担现有的网络负荷
动态问题
分组丢失是网络发生拥塞的征兆
拥塞控制本身引起网络性能恶化，甚至引起死锁

开环控制与闭环控制

开环控制	闭环控制
设计网络上，事先考虑周全，力求工作时不发生拥塞	基于反馈环路的概念
思路：力求避免发生拥塞	根据网络当前的运行状态采取相应控制措施
	思路：发生拥塞后，采取措施进行控制，消除拥塞

闭环控制措施

检测网络系统，以便检测到拥塞在何时何处发生
将拥塞发生信息传送到可采取行动的地方
调整网络系统运行

检测网络拥塞指标：

由于缺少缓存空间而被丢弃的分组的百分数
平均队列长度
超时重传的分组数
平均分组时延
分组时延的标准差等

以上标志着拥塞增长

传递拥塞通知

发送通知拥塞发生的分组
在分组中保留表示拥塞状态的字段
周期性的发出探测分组等

采取行动的时机

过于频繁，会使系统产生不稳定的振荡
过于赤化采取行动布局有任何实用价值

解决拥塞的两条思路

增加网络可用资源
减少用户对资源的需求

7.2 TCP的拥塞控制方法

TCP采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法
TCP发送方维持一个拥塞窗口cwnd（Congestion Window）
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量
发送窗口大小取决于接收方窗口&网络的拥塞状况

发送窗口值 = Min(接收方窗口，拥塞窗口值）

控制拥塞窗口原则

只要网络没有出现拥塞，拥塞窗口可增大，以便把更多分组发出去，提高网络利用率
只要网络出现拥塞或可能出现拥塞，就减小窗口，以减少注入到网络中的分组数，以缓解网络出现的拥塞

拥塞判断

重传定时器超时	收到三个重复的ACK
网络已经发生了拥塞	预示网络可能出现拥塞(可能还未发生拥塞)

TCP拥塞控制方法

慢开始(slow-start)
拥塞避免(congestion avoidance)
快重传(fast retransmit)
快恢复(fast recovery)

7.2.1 慢开始

慢开始——确定网络的负载能力or拥塞程度

算法思路：由小到大逐渐增大拥塞窗口数值

两个变量：

拥塞窗口——初始拥塞窗口值：2种设置方法

1-2个最大报文段（旧标准）

2-4个最大报文段 (RFC 5681)

窗口值逐渐增大
慢开始门限——防止拥塞窗口增长过大引起网络拥塞

慢开始

拥塞窗口控制cwnd方法:每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS值

拥塞窗口cwnd每次的增加量 = min(N, SMSS)
其中N是原先未被确认，但现在被刚收到的确认报文段所确认的字节数
当N<SMSS时，拥塞窗口每次增加量要小于SMSS

发送方每收到一个对新报文段的确认（重传不算在内）使cwnd加1

传输轮次

使用慢开始算法后，每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍
一个传输轮次所经历的时间是RTT
“传输轮次”强调：把拥塞窗口cwnd索允许发送的报文段都连续发送出去，并收到对已发送的最后一个字节的确认
eg:传输窗口cwnd=4,这时RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认总共经历的时间

设置慢开始门限状态变量ssthresh用法

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

拥塞避免算法

思路：让拥塞窗口cwnd缓慢增大，避免出现拥塞
超时之前，每经过一个传输轮次，拥塞窗口cwnd+=1
使拥塞窗口cwnd按线性规律缓慢增长
在拥塞避免阶段，具有“加法增大”(Additive Increase)的特点

当网络出现拥塞时(重传定时其超时)，

ssthresh = max(cwnd/2, 2)
cwnd = 1
执行慢开始算法

目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有充足时间把队列中积压的分组处理完毕

拥塞避免：指在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞

7.2.2 快重传

发送方只要一连收到三个重复确认，就知道接收方没有收到报文段，因而立即执行重传，这样就不会超时，发送方也不会误认为出现了网络拥塞
使用快重传可使整个网络吞吐量提高20%

快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段

快重传算法

可尽早让对方知道发生了个别报文段的丢失
要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，

即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认

慢开始门限ssthresh = 当前拥塞窗口cwnd/2
新拥塞窗口cwnd = 慢开始门限ssthresh
开始执行拥塞避免算法，使拥塞窗口缓慢的线性增大

加法增大，乘法减小(AIMD)

拥塞避免阶段，拥塞窗口线性规律增大——加法增大(Additive Increase)
出现超时或3个重复的确认时，就要把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值——乘法减小(Multiplicative Decrease)
二者结合就是AIMD算法

发送窗口的上限值

当发送方窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd中较小值

发送窗口上限值 = Min[rwnd, cwnd]
rwnd<cwnd时，接收方的接受能力限制发送窗口的最大值
cwnd<rwnd时，网络的拥塞限制发送窗口的最大值

7.3 主动队列管理AQM

若路由器对某些分组的处理时间特别长，TCP报文段经过很长时间到达终点，引起发送方超时重传
重传使TCP连接的发送端认为网络拥塞，实际上并没有
对TCP拥塞控制影响最大的路由器的分组丢弃策略

先进先出FIFO处理规则

路由器队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组排在队尾）都将被丢弃——尾部丢弃策略(tail-drop policy)
路由器尾部丢弃导致一连串分组丢失，使发送方出现超时重传，使TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降到很小

全局同步

连接中的报文段通常是复用在网络层的IP数据报中传送的
这种情况下，如果发生了路由器的尾部丢弃，可能同时影响很多TCP连接，结果使许多TCP连接同一时间进入到慢开始状态——全局同步
全局同步使全网的通信量突然下降很多，而在网络恢复正常后，其通信量又突然增大很多

若路由器进行了尾部丢弃，所有到达的分组都被丢弃，不论它们属于哪个TCP连接

主动队列管理AQM

“主动”——不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），主动丢弃到达的分组
AQM 有不同实现方法，eg：随机早期检测RED(Random Early Detection)

随机早期检测RED

使路由器维持两个参数：队列长度最小门限THmin和最大门限Thmax
RED对每一个到达的分组都先计算平均队列长度Lav
1. 若平均队列长度<最小门限THmin，则将新到达的分组放入队列进行排队
2. 若平均队列长度>最大门限THmax，则将新到达的分组丢弃
3. 若平均队列长度在最小门限和最大门限之间，则按照某一概率p将新到达的分组丢弃
  - Lav<Thmin，丢弃概率p=0
  - Lav>Thmax,丢弃概率p=1
  - Thmin>Lav<Thmax,0<p<1

AQM 实际上就是对路由器中的分组排队进行智能管理，并不是简单把队尾丢弃

8. TCP的运输连接管理

运输连接的三个阶段

TCP面向连接
TCP连接有3个阶段
1. 连接建立
2. 数据传送
3. 连接释放
TCP的连接管理就是使TCP连接的建立和释放都能正常进行

TCP连接建立过程中要解决的3个问题

双方要知道对方的存在
允许双方协商一些参数（如最大窗口值，是否使用窗口扩大选想和时间戳悬心爱过以及服务质量等）
可对运输实体资源（如缓存大小，连接表中的项目等）进行分配

客户—服务器模式

TCP连接建立采用客户服务器模式
发起连接——客户端
等待连接——服务器

8.1 TCP的连接建立

TCP建立连接的过程叫做握手
握手需要在客户和服务器之间交换3个TCP报文段，称之为3报文握手
采用3报文握手是为了防止已失效的连接请求报文段突然又传送到了而产生错误

B的TCP服务器先创建传输控制块TCB，准备接收客户进程的连接请求
A的TCP向B发出连接请求报文段，其首部中的同步位SYN=1，并选择序号seq=x,表明传送数据时的第一个数据字节的序号是x
B的TCP收到连接请求报文段后，如同意，则发回确认

B在确认报文段中应使SYN=1，ACK=1，其确认号ack = x+1,自己选择的序号seq=y
A收到此报文段后向B给出确认，其ACK=1，确认号ack = y+1

A的TCP通知上层应用进程，连接已经建立
B的TCP收到主机A的确认后，也通知其上层应用进程TCP连接已经建立

8.2 TCP的连接释放

数据传输结束后，通信沙u哪个发哪个都可释放连接
TCP连接释放过程是四报文握手

A应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接

Ａ把连接释放报文段首部的FIN＝１，seq＝ｕ，等待Ｂ的确认
Ｂ发出确认，确认号ack＝ｕ＋１，而这个报文段自己的序号seq＝ｖ

TCP服务器进程通知高层应用进程

Ａ到Ｂ方向的连接就释放了，TCP连接处于半关闭状态，Ｂ若发送数据，Ａ仍要接收
若Ｂ已没有要向A发送的数据

其应用进程就通知TCP释放连接
Ａ收到连接释放报文段后，必须发出确认

确认报文段中ACK＝１，确认号ack＝ｗ＋１，自己的序号seq＝ｕ＋１