站长统计app下载免费,高端品牌服装,潍坊网站建设价格,wordpress上的php技术目录
1.停止等待协议
2.连续ARQ协议
3.TCP报文段的首部格式
4.TCP的滑动窗口机制
#xff08;1#xff09;发送窗口
#xff08;2#xff09;接收窗口
#xff08;3#xff09;发送缓存
5.超时重传时间的选择
6.选择确认SACK(Selective ACK)
7.使用滑动窗口实现…目录
1.停止等待协议
2.连续ARQ协议
3.TCP报文段的首部格式
4.TCP的滑动窗口机制
1发送窗口
2接收窗口
3发送缓存
5.超时重传时间的选择
6.选择确认SACK(Selective ACK)
7.使用滑动窗口实现流量控制
1 流量控制原理编辑
2TCP的传输效率
8.拥塞控制
1拥塞控制的基本原理
2TCP的拥塞控制方法
3发送方判断拥塞的方法
4TCP拥塞控制算法
9.主动队列管理AQM 1.停止等待协议
每发送完一个分组就停止发送等待对方的确认。在收到确认后再发送下一个分组。 A 发送完分组 M1 后就暂停发送等待 B 的确认 (ACK)。
B 收到 M1 向 A 发送 ACK。
A 在收到了对 M1 的确认后就再发送下一个分组 M2。 在以下两种情况下B不会向A发送确认信息 1.B接收M1时检测出了差错就丢失M1其他什么也不做不通知A收到有差错的分组
2.M1在传输过程中丢失。 针对B丢失M1不通知A的问题A如何知道B是否正确收到M1答案是超时重传 1.A 为每一个已发送的分组设置一个超时计时器。
2.A 只要在超时计时器到期之前收到了相应的确认就撤销该超时计时器继续发送下一个分组 M2。
3.若A在超时计时器规定时间内没有收到 B 的确认就认为分组错误或丢失就重发该分组。
4.假定B正确收到A重传的分组M1B会采取以下两个行动
(1)丢弃这个重复的分组 M1不向上层交付。 (2) 向A 发送确认。 如果B发送的确认丢失或迟到怎么办 1.B 对分组M1的确认迟到了因此A在超时计时器到期后重传M1。
2.B 会收到重复的 M1丢弃重复的 M1并重传确认分组。
3.A 会收到重复的确认。对重复的确认的处理: 丢弃。
针对往返时间RRT
当往返时间 RTT 远大于分组发送时间 T时信道的利用率会非常低 所以停止等待协议虽然简单但是信道利用率很低
总结一下停止等待协议的要点
•停止等待:发送方每次只发送一个分组。在收到确认后再发送下一个分组
•暂存:在发送完一个分组后发送方必须暂存已发送的分组的副本以备重发
•编号:对发送的每个分组和确认都进行编号超时重传。发送方为发送的每个分组设置一个超时计时器。若超时计时器超时位收到确认发送方会自动超时重传分组
•超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些防止不必要的重传
•简单但信道利用率太低 2.连续ARQ协议
为了提高效率提出了连续ARQ协议其采用流水线传输即在收到确认之前发送方连续发出多个分组。
补充滑动窗口协议和连续ARQ协议一样都采用流水线传输方式。 ARQ协议有以下几个要点
•发送窗口: 发送方维持一个发送窗口位于发送窗口内的分组都可被连续发送出去而不需要等待对方的确认。 •发送窗口滑动: 发送方每收到一个确认就把发送窗口向前滑动一个分组的位置 •累积确认: 接收方对按序到达的最后一个分组发送确认表示:到这个分组为止的所有分组都已正确收到了。 ARQ协议又分为选择重传ARQ和回退ARQ
回退ARQ
重传方式当发送方发现有数据丢失或损坏时会重传从该数据段开始之后的所有未确认的数据段。
选择重传ARQ
重传方式当发送方发现有数据丢失或损坏时只会重传丢失或损坏的那个数据段而不是将后续的数据段全部重传。
实现方法
1.发送方维持着一个窗口包含可发送或已发送但未被确认的序号。 2.接收方维持着一个窗口包含可接收的序号每个序号还保留一个缓冲区。与每个缓冲区项相关联的还有一个标志位用来指明缓冲区是满的还是空的。 3.每到达一个帧接收方通过检查它的序号看是否落在窗口内。如果确实落在窗口内且之前没有接收过则接收该分组然后保存在缓冲区并返回一个确认。等前面这些帧都到达后一起交付给上层。
4.发送端每个发送缓冲都设有一个超时一个超时计时器一个超时事件发生后相应缓冲区的帧就会被重发
但是非顺序接收也引发了一些特殊问题。
假设我们用3bit的序号0~ 7那么发送方允许发送8个帧然后开始等待确认。刚开始时发送方和接收方的窗口如图所示 现在发送方发出0~ 7号帧接收方的窗口接收任何序号落在0~7之间的帧。 这8个帧全部到达后接收方发送确认发送方还未收到并且向前移动它的窗口允许下一次接收0、1、2、3、4、567号帧 这时会存在两个场景
情景一 发送方收到了全部确认发送窗口前移然后继续发送后面的数据0号帧 这时接收方会收到一个0号帧
情景二 假如第一次发出的所有确认都丢失了所以接收方在超时之后便会重传0号帧其他帧也会重传只不过0号帧先被发送、先超时、先重传
因为接收方已经接收了0~7号帧并已发送了确认(虽然发送方未收到)所以窗口会向前移动允许下一次接收0、1、2、3、4、567号帧。 此时接收方也能收到一个0号帧
两种情况下接收方都能收到0号帧一个是重传的一个是新发送的接收方没法区分这两个0号帧。
这个问题通常通过设置窗口大小来解决
1.让接收窗口大小等于发送窗口大小大了会溢出小了没意义 2.发送窗口接收窗口2^(n-1) n表示用多少bit来表示允许发送的帧序号上文发送了8个帧2 ^3 也就是3bit所以窗口大小应该小于等于2 ^(3-1)4即序列号的一半
———————————————— 原文链接https://blog.csdn.net/aaahuahua/article/details/119965804 3.TCP报文段的首部格式 •源端口和目的端口:各占 2 字节32位。端口是运输层与应用层的服务接口运输层的复用和分用功能通过端口实现。
•序号: 占 4 字节。TCP 连接中传送的数据流中的每一个字节都有一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
•确认号: 占 4 字节是期望收到对方的下一个报文段的数据的第一个字节的序号
注若确认号 N则表明: 到序号 N - 1 为止的所有数据都已正确收到
•数据偏移 (即首部长度): 占 4 位指出 TCP 报文段的数据起始处距离TCP 报文段的起始处有多远。单位是 32 位字 (以 4 字节为计算单位)
•保留占6位保留为今后使用但目前应置为0
•紧急 URG: 控制位当 URG 1 时表明紧急指针字段有效告诉系统此报文段中有紧急数据应尽快传送(相当于高优先级的数据)
•确认 ACK: 控制位只有当 ACK 1 时确认号字段才有效。当ACK 0 时确认号无效。
•推送 PSH (PuSH)控制位接收 TCP 收到 PSH 1 的报文段后就尽快 (即“推送”向前)交付接收应用进程而不再等到整个缓存都填满后再交付。
•复位 RST(ReSet): 控制位。当 RST1 时表明 TCP 连接中出现严重差错(如主机崩溃或其他原因)必须释放连接然后再重新建立运输连接。
•同步 SYN (SYNchronization): 控制位。同步 SYN 1 表示这是一个连接请求或连接接受报文。当 SYN 1ACK 0时表明这是一个连接请求报文段。当 SYN 1ACK 1 时表明这是一个连接接受报文段。
•终止 FIN (Finish): 控制位。用来释放一个连接。FIN1 表明此报文段的发送端的数据已发送完毕并要求释放运输连接。
•窗口: 占2 字节。窗口值告诉对方: 从本报文段首部中的确认号算起接收方目前允许对方发送的数据量 (以字节为单位)
注窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。
•检验和:占 2 字节。检验和字段检验的范围包括首部和数据这两部分在计算检验和时要在 TCP 报文段的前面加上 12 字节的伪首部。
在计算检验和时临时把 12 字节的“伪首部”和 TCP 报文段连接在一起。伪首部仅仅是为了计算检验和。 紧急指针占2 字节。在 URG 1时指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)指出了紧急数据的末尾在报文段中的位置。
选项长度可变最长可达40个字节。
TCP的选项字段包括很多内容这里只讲主要的如果想详细了解http://t.csdnimg.cn/UIb7P
•选项2最大报文段长度MSS
MSS(Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度数据字段加上 TCP 首部才等于整个的 TCP 报文段所以MSS是“TCP 报文段长度减去 TCP 首部长度。这个数据字段与接收窗口值没有关系。 对于MSS有以下要求
•不能太小网络利用率降低。例如:仅 1 个字节。利用率就不会超过1/41。
•不能太大开销增大IP 层传输时要分片终点要装配。分片传输出错时要整个分组。
•满足IP 层传输时不再分片。默认值 536字节报文段长度 536 20 556 字节IP 数据报长度 556 20 576 字节
•选项3窗口扩大
窗口扩大选项: 占3 字节其中一个字节表示移位值 S。
新的窗口值位数从 16 增大到(16 S)相当于把窗口值向左移动 S 位。移位值允许使用的最大值是 14窗口最大值增大到 2的(16 14)次方 - 1 2的30次方 - 1。窗口扩大选项可以在双方初始建立TCP 连接时进行协商。 •选项8时间戳
占10 字节。最主要的 2个字段时间戳值字段 (4字节)和时间戳回送回答字段 (4字节) 2个主要功能: 1.计算往返时间 RTT 2.防止序号绕回 PAWS(Protect Against Wrapped Sequencenumbers) 序号重复时为了使接收方能够把新报文段和迟到很久的旧报文段区分开可以在报文段中加上时间戳。
填充使整个TCP首部长度使4字节的整数倍。 4.TCP的滑动窗口机制
1发送窗口
•A 根据 B 给出的窗口值构造出自己的发送窗口。
•发送窗口里面的序号表示允许发送的序号。
•窗口越大发送方就可以在收到对方确认之前连续发送更多的数据因而可能获得更高的传输效率。 发送窗口包含的内容
假定A发送了序号为31~41共11个字节的数据。 P1 后沿P2 当前P3 前沿
P3-P1A的发送窗口 (又称为通知窗口)
P2-P1已发送但尚未收到确认的字节数
P3- P2允许发送尚未发送的字节数 (又称为可用窗口)
2接收窗口 B 收到了序号为32和33的数据但未收到序号为 31的数据因此因此发送的确认报文段中的确认号是 31 (即期望收到的序号)
3窗口滑动
确认号为31表示31之前的数据已发送并收到确认 由于32和33数据确认接收但是未收到序号31的数据所以接收方的序号为31表示期望收到31 接收方的滑动窗口前移 发送窗口继续发送粉色框代表已发送未确认 发送窗口未收到确认有两种可能 1.B未发送
2.B已经发送但是未到达A 此时为保证可靠传输
A 只能认为 B 还没有收到这些数据。A 经过一段时间后 (由超时计时器控制)就重传这部分数据重新设置超时计时器直到收到 B 的确认为止。
如果 A 按序收到落在发送窗口内的确认号就使发送窗口向前滑动并发送新的数据。 3发送缓存
可以看到发送窗口只是发送缓存的一部分: 图中的发送应用程序即发送方的应用程序把字节流写入TCP发送缓存不能太快否则发送缓存会溢出
TCP发送缓存中暂存着
(1)发送应用程序传送给发送方 TCP准备发送的数据。
(2) TCP 已发送出但尚未收到确认的数据。
发送缓存中的字节数发送应用程序最后写入缓存的字节-最后被确认的字节 4接收缓存 这里的接收应用程序即接收方的应用程序从TCP接收缓存中读取尚未被读取的字节。
接收缓存暂时存放着
(1)按序到达的、但尚未被接收应用程序读取的数据;
(2)未按序到达的数据。
注若不能及时读取缓存最终会被填满使接收窗口减小到零。如果能够及时读取接收窗口就可以增大但最大不能超过接收缓存的大小。
对发送方和接收方需要注意 (1)发送窗口是根据接收窗口设置的但在同一时刻发送窗口并不总是和接收窗口一样大因为有一定的时间滞后。 (2)TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中等到字节流中所缺少的字节收到后再按序交付上层的应用进程。 (3)TCP 要求接收方必须有累积确认的功能以减小传输开销。接收方可以在合适的时候发送确认也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认否则会导致发送方不必要的重传捎带确认实际上并不经常发生。 5.超时重传时间的选择
重传时间的选择是一个比较复杂的问题。TCP采用了一种自适应算法它记录一个报文段发出的时间以及收到相应确认的时间。
这两个时间之差就是报文段的往返时间RTT。
•加权平均往返时间。又称为平滑的往返时间 其中0a1,若 a--0表示 RTT 值更新较慢。若a--1表示RTT 值更新较快。
RFC 6298推荐的a值为1/8即0.125
•是偏差的加权平均值 其中:b是个小于1的系数其推荐值是 1/4即 0.25
•超时重传时间RTO应略大于加权平均往返时间。 超时重传报文段后如何判定此确认报文段是对原来的报文段的确认还是对重传报文段的确认? (1)Karn算法
通过不采用重传报文段的往返时间样本Karn算法可以避免对丢失或延迟的报文段进行误判从而更准确地计算平均往返时间。
算法原理:
•在发送方发送一个报文段后它会启动一个计时器来测量往返时间RTT即发送方发送报文段到接收方收到确认消息之间的时间。
•如果发送方在计时器超时之前收到了确认消息说明报文段成功到达接收方并且RTT可以被准确测量。发送方将测量到的RTT样本纳入平均值的计算中。
•如果发送方在计时器超时后才收到确认消息说明报文段丢失或延迟较大。由于无法准确测量这个丢失或延迟的报文段的RTT为了避免错误地计算平均值Karn算法不采用该报文段的往返时间样本。
但会出现新的问题
当报文段的时延突然增大很多时在原来得出的重传时间内不会收到确认报文段于是就重传报文段。但根据 Karn 算法不考虑重传的报文段的往返时间样本。这样超时重传时间就无法更新造成很多不必要的重传。 2修正的Karn算法
报文段每重传一次就把 RTO 增大一些 系数y的典型值 2 当不再发生报文段的重传时才根据报文段的往返时延更新平均往返时延RTT和超时重传时间 RTO的数值。 6.选择确认SACK(Selective ACK)
若收到的报文段无差错只是未按序号中间还缺少一些序号的数据那么只传送缺少的数据而不重传已经正确到达接收方的数据。
对于SACK要注意
如果要使用选择确认在建立TCP 连接时要在TCP首部的选项中加上允许 SACK 选项且双方必须事先商定好。 如果使用选择确认原来首部中的确认号的用法仍然不变(累积确认)。只是在TCP 首部中都增加了 SACK 选项以便报告收到的不连续的字节块的边界。 注左边界第一个字节的序号右边界最后一个字节序号1
例如SACK报告需重传数据的左边界和有边界 7.使用滑动窗口实现流量控制
1 流量控制原理
但是也可能发生死锁
B在告诉A接收窗口大小时报文丢失 这时就需要持续计时器
持续计时器 (persistence timer): 只要 TCP 连接的一方收到对方的零窗口通知就启动该持续计时器。
•若持续计时器设置的时间到期就发送一个零窗口探测报文段 (仅携带1字节的数据)对方在确认这个探测报文段时给出当前窗值。
•若窗口仍然是零收到这个报文段的一方就重新设置持续计时器。
•若窗口不是零则死锁的僵局就可以打破了。 2TCP的传输效率
应用进程把数据传送到 TCP 的发送缓存后剩下的发送任务就由TCP来控制了。可以用不同的机制来控制 TCP 报文段的发送时机。例如第一种机制是 TCP维持一个变量它等于最大报文段长度 MSS只要缓存中存放的数据达到MSS字节时就组装成一个TCP 报文段发送出去。第二种机制是由发送方的应用进程指明要求发送报文段即TCP 支持的推送(push)操作。第三种机制是发送方的一个计时器期限到了这时就把当前已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。
但是如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。例如一个交互式用户使用一条TELNET连接(运输层为TCP协议)。假设用户只发1个字符加上20字节的首部后得到21字节长的TCP 报文段。再加上20字节的IP首部形成41字节长的IP数据报。在接收方TCP立即发出确认构成的数据报是40字节长(假定没有数据发送)。若用户要求远地主机回送这一字符则又要发回41 字节长的 IP 数据报和40字节长的确认IP 数据报。这样用户仅发1个字符时线路上就需传送总长度为162字节共4个报文段。当线路带宽并不富裕时这种传送方法的效率的确不高。因此应适当推迟发回确认报文并尽量使用捎带确认的方法。 在TCP的实现中广泛使用 Nagle 算法。算法如下:若发送应用进程把要发送的数据逐个字节地送到 TCP的发送缓存则发送方就把第一个数据字节先发送出去把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后再把发送缓存中的所有数据组装成一个报文段发送出去同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时用这样的方法可明显地减少所用的网络带宽。Nagle 算法还规定当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时就立即发送一个报文段。这样做就可以有效地提高网络的吞吐量。 另一个问题叫作糊涂窗口综合征(silly windowsyndrome)有时也会使TCP的性能变坏。设想一种情况:TCP接收方的缓存已满而交互式的应用进程一次只从接收缓存中读取1个字节(这样就使接收缓存空间仅腾出1个字节然后向发送方发送确认并把窗口设置为1个字节(但发送的数据报是40字节长)。接着发送方又发来1个字节的数据(请注意发送方发送的IP数据报是 41字节长)。接收方发回确认仍然将窗口设置为1个字节。这样进行下去使网络的效率很低。 每次只读取一个字节 要解决这个问题可以让接收方等待一段时间使得或者接收缓存已有足够空间容纳一个最长的报文段或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一接收方就发出确认报文并向发送方通知当前的窗口大小。此外发送方也不要发送太小的报文段而是把数据积累成足够大的报文段或达到接收方缓存的空间的一半大小。 上述两种方法可配合使用。使得在发送方不发送很小的报文段的同时接收方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。 8.拥塞控制
1拥塞控制的基本原理
在某段时间若对网络中某资源的需求超过了该资源所能提供的可用部分网络的性能就要明显变坏整个网络的吞吐量将随输入负荷的增大而下降。这种现象称为拥塞(congestion)。
最坏结果则系统崩溃。 拥塞控制产生的条件 可能是因为
1.节点缓存容量太小 2.链路容量不足 3.处理机处理速率太慢 4.拥塞本身会进一步加剧拥塞。
注增加资源不能解决拥塞
1.增大缓存但未提高输出链路的容量和处理机的速度排队等待时间将会大大增加引起大量超时重传解决不了网络拥塞。
2.提高处理机处理的速率会将瓶颈转移到其他地方
3.拥塞引起的重传并不会缓解网络的拥塞反而会加剧网络的拥塞。 2TCP的拥塞控制方法
TCP 采用基于滑动窗口的方法进行拥塞控制TCP 发送方维持一个拥塞窗口 cwnd (Congestion Window)拥塞窗口的大小取决于网络的拥塞程度并且是动态变化的。发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量发送窗口大小不仅取决于接收方窗口还取决于网络的拥塞状况 真正的发送窗口值 发送窗口的数值不能超过接收窗口和拥塞窗口中的较小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此当接收窗口小于拥塞窗口时发送窗口的大小取决于流量控制即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时则发送窗口的大小取决于拥塞控制即取决于整个网络的拥塞状况。 •当rwndcwnd 时是接收方的接收能力限制发送窗口的最大值。 •当cwnd rwnd 时是网络拥塞限制发送窗口的最大值。 控制窗口变化的原则
•只要网络没有出现拥塞拥塞窗口就可以再增大一些以便把更多的分组发送出去提高网络的利用率。
•但只要网络出现拥塞或有可能出现拥塞就必须把拥塞窗口减小-些以减少注入到网络中的分组数缓解网络出现的拥塞。
3发送方判断拥塞的方法
超时重传计时器超时网络已经出现了拥塞收到 3 个重复的确认预示网络可能会出现拥塞
注因传输出差错而丢弃分组的概率很小 (远小于1 %)因此发送方在超时重传计时器启动时就判断网络出现了拥塞。
4TCP拥塞控制算法
•慢开始(slow-start)
•拥塞避免(congestion avoidance)
•快重传(fast retransmit)
•快恢复(fast recovery)
慢开始算法和拥塞避免 发送方维护一个叫做拥塞窗口cwnd的状态变量其值取决于网络的拥塞程度并且动态变化
•拥塞窗口cwnd的维护原则:只要网络没有出现拥塞拥塞窗口就再增大一些;但只要网络出现拥塞拥塞窗口就减少一些
•判断出现网络拥塞的依据: 没有按时收到应当到达的确认报文 (即发生超时重传)
发送方将拥塞窗口作为发送窗口swnd即swnd cwnd 维护一个慢开始门限ssthresh状态变量: •当cwndssthresh时使用慢开始算法;
•当cwndssthresh时停止使用慢开始算法而改用拥塞避免算法;
•当cwndssthresh时既可以使用慢开始算法也可以拥塞避免算法;
1在TCP双方建立逻辑连接关系时拥塞窗口的值被设置为1并设置慢开始门限的初始值这里采用16。
2在进行慢开始算法时发送方每接收到一个对新报文段的确认时就把拥塞窗口值大小加倍并开始下一轮的传输。
3当拥塞窗口值增长到慢开始门限值时就改用拥塞避免算法由于发送方当前的拥塞窗口值是1而发送窗口值拥塞窗口值因此发送方此时只能发送一个TCP报文段。即拥塞窗口值是几就能发送几个数据报文段。
现在我们通过展现拥塞窗口随传输轮次的变化来理解
传输轮次
发送方给接收方发送数据报文后接收方给发送方发回相应的确认报文段一个传输轮次所经历的时间其实就是往返时间。
注往返时间并非是恒定的数值使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去并收到了对已发送的最后一个报文段的确认。
步骤一 发送方到收到确认后将拥塞窗口值1此时窗口值为2这样拥塞窗口就可以发送2个数据报文段当发送方收到2个报文段的确认后将窗口值2(224),接下来就可以发送4个数据报文段以此类推....即拥塞窗口值为24816 步骤二
现在增大到了慢开始门限值改用拥塞避免算法
每个传输轮次结束后拥塞窗口值只能线性1发送方给接收方发送17个数据报文段若收到接收方返回的确认后继续线性1 如图所示 步骤三
当拥塞窗口为24时若发送的数据报部分丢失发送方就会对这些报文段进行超时重传
并且确定网络出现拥塞做一下操作
1.ssthresh值更新为发生拥塞时cwnd值的一半注ssthresh max (cwnd/22)如图则为12
2.将拥塞窗口值减小为1并重新开始慢开始算法当拥塞窗口达到新的门限值时则改用拥塞避免算法 注
1.慢开始是指一开始向网络注入的报文段少并不是指拥塞窗口cwnd增长速度慢
2.“拥塞避免”并非指完全能够避免拥塞而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长使网络比较不容易出现拥塞。
快重传和快恢复 有时个别报文段会在网络中丢失但实际上网络并未发生拥塞这将导致发送方超时重传并误认为网络发生了拥塞。于是发送方将拥塞窗口减少为1并错误地启动慢开始算法因而降低了传输效率。 快重传
所谓快重传就是使发送方尽快进行重传而不是等超时重传计时器超时再重传采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
这就要求接收端
•接收方不要等待自己发送数据时才进行捎带确认而是要立即发送确认;
•即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
•发送方一旦收到3个连续的重复确认就将相应的报文段立即重传而不是等该报文段的超时重传计时器超时再重传。 这样就不会造成对报文3的超时重传而是提早进行了重传对于个别丢失的报文段发送方不会出现超时重传也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20% 快恢复
发送方一旦收到3个重复确认就知道现在只是丢失了个别的报文段。于是不启动慢开始算法而执行快恢复算法。
•发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半; 开始执行拥塞避免算法•也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些即等于新的ssthresh 3。既然发送方收到3个重复的确认就表明有3个数据报文段已经离开了网络;这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。 例题
一个TCP连接总是以1KB的最大段长发送TCP段发送方有足够多的数据要发送。当拥塞窗口为16KB时发生了超时如果接下来的4个RTT(往返时间)内的TCP段的传输都是成功的那么当第4个RTT时间内发送的所有TCP段都得到肯定应答时拥塞窗口大小是9KB 9.主动队列管理AQM
TCP 拥塞控制和网络层采取的策略有密切联系。
例如假定一个路由器对某些分组的处理时间特别长那么这就可能使这些分组中的数据部分(即 TCP 报文段)经过很长时间才能到达终点结果引起发送方对这些报文段的重传。根据前面所讲的重传会使 TCP 连接的发送端认为在网络中发生了拥塞。于是在TCP的发送端就采取了拥塞控制措施但实际上网络并没有发生拥塞。
FIFO先进先出 网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略。在最简单的情况下路由器的队列通常都按照“先进先出”FIFO(First In First Out)的规则处理到来的分组。由于队列长度总是有限的因此当队列已满时以后再到达的所有分组(如果能够继续排队这些分组都将排在队列的尾部)将都被丢弃。这就叫作尾部丢弃策略。
若路由器进行了尾部丢弃所有到达的分组都被丢弃不论它们属于哪个TCP连接。
路由器的尾部丢弃往往会导致一连串分组的丢失这就使发送方出现超时重传使TCP进入拥塞控制的慢开始状态结果使TCP连接的发送方突然把数据的发送速率降低到很小的数值。 全局同步
更为严重的是在网路中通常有很多的 TCP 连接(它们有不同的源点和终点)。这些连接中的报文通常是复用在网络层的 IP 数据报中传送的。在这种情况下若发生了路由器中的尾都丢弃就可能会同时影响到很多条 TCP 连接结果使这许多 TCP 连接一时间突然都进入到慢开始状态。这在 TCP 的术语中称为全局同步(lobal synchronization),全局同步使得全网的通信量突然下降了很多而在网络恢复正常后其通信量又突然增大很多。
为了避免发生网络中的全局同步现象提出了主动队列管理AQM (ACti多。Queue Management)。所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值(即当网络拥塞有了某些拥塞征兆时)就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率因而有可能使网络拥塞的程度减轻甚至不出现网络拥塞。
AQM 可以有不实现方法其中曾流行多年的就是随机早期检测RED(Random Early Detection)。RED还几个不同的名称如Random EarlyDrop或Random Early Discard(随机早期丢弃)。
实现 RED时需要路由器队列维持两个参数: 队列长度最小门限 THmin 队列长度最大门限THmax。
RED 对每一个到达的分组都先计算平均队列长度 。
1.若平均队列长度小于最小门限 THmin则将新到达的分组放入队列进行排队。
2.若平均队列长度超过最大门限 THmax则将新到达的分组丢弃。
3.若平均队列长度介于在最小门限 THmin和最大门限 THax 之间则按照某一概率 p 将新到达的分组丢弃。 由此可见RED不是等到已经发生网络拥塞后才把所有在队列尾部的分组全部丢弃而是在检测到网络拥塞的早期征兆时(即路由器的平均队列长度达到一定数值时)就以概率p丢弃个别的分组让拥塞控制只在个别的 TCP连接上进行因而避免发生全局性的拥塞控制。 在RED的操作中最难处理的就是丢弃概率p的选择因为p并不是个常数。对每个到达的分组都必须计算丢弃概率p的数值。IETF曾经推荐在互联网中的路由器使用RED机制[RFC2309]但多年的实践证明RED的使用效果并不太理想。因此在2015年公布的RFC7567已经把过去的RFC2309列为“陈旧的”并且不再推荐使用 RED。对路由器进行主动队列管理 AQM 仍是必要的。AQM 实际上就是对路由器中的分组排队进行智能管理而不是简单地把队列的尾部丢弃。现在已经有几种不同的算法来代替旧的 RED但都还在实验阶段。目前还没有一种算法能够成为IETF 的标准。
