tcp协议的延迟应答(介绍+原则),拥塞控制(拥塞窗口,网络出现拥塞时,滑动窗口的大小如何确定,慢启动,阈值)
目录
延迟应答
引入
介绍
原则
拥塞控制
引入
网络出现拥塞
引入
介绍
介绍
拥塞窗口
介绍
决定滑动窗口的大小
慢启动
介绍
为什么要有慢启动
阈值
算法
总结
延迟应答
引入
发送方一次发送更多的数据,发送效率就越高
- 因为要写入网卡
- 硬件的io速度很慢,尽量少访问硬件,io效率会提高
而发送的数据量取决于对方的接收能力(窗口大小)
- 那么,如何让接收方向对方通告一个更大的窗口呢?
介绍
也就是让接收方先不着急返回应答,等一等,给上层留时间读取数据
- 这样就有较大概率可以有更大的窗口
- 当然,效率提高不是一定的,因为上层读不读我们没法控制
所以,这也给我们有一定的启示
- 编写基于tcp的服务器代码时,要尽快把数据读上来
- 这样就能提供更大的接收窗口->对方的滑动窗口大小增大->对方就可以发送更多的数据
原则
- 不同os有不同的具体设置,一般N=2,最大延迟时间=200ms
- 这个[最大延迟时间]要比[超时时间]短的多
拥塞控制
引入
之前介绍的策略,都是作用在双方主机上的
- 但是,数据包大部分时间都在网络中,所以网络信道也对通信有影响
- 所以,tcp还需要对网络制定策略
- 但是因为网络不属于客户端/服务端的范畴,所以这俩没法对网络直接做些什么,只是一些策略
网络出现拥塞
引入
对于网络拥塞问题,我们可以做个比喻:
- 如果一场考试,只有几个人挂科,那只能说明是这几个没好好学
- 如果班上大部分人都挂科了,只有几个及格,不免让人怀疑这场考试有问题
网络也是如此:
- 出现少量丢包是正常的
- 但如果大面积丢包,可能就是通信过程中有什么问题了
一是对方可能来不及接收,导致丢包
- 但是有流量控制,所以应当不会
二是网络有问题
- 可能是硬件设备有问题
- 或是数据量过大,引起阻塞
- 这两个问题也可能是一个问题,因设备问题导致数据阻塞
所以,在通信过程中,不仅要考虑双方如何,也要考虑网络如何,也就是需要评估网络的健康状态
介绍
如果通信时出现了大量丢包
- tcp就认为是网络出了问题(网络阻塞)
如果知道大量丢包(即滑动窗口内有大量的数据都超时了,连应答都没有)
- 大部分可能自己过一会儿会缓过来,但我们也不能坐以待毙啊,总得做点什么,也就有了拥塞控制
- 如果网络大量瘫痪,tcp协议也救不了,那就只能让工程师来维修了(毕竟tcp制定的机制并不是万能的)
介绍
所以,对于这些大量超时的数据,发送方该如何呢?
- 首先,肯定是不能立即重传的(少量重传倒是没问题,因为只是个例)
- 而大量丢包必然是哪里出了问题
- 如果是设备出错,即使发了也是白发
- 如果是数据拥塞,那重发了岂不是会更加重拥塞程度
- 所以,发送方需要先等等
这样的话,所有遵守tcp协议的主机遇到网络拥塞时都等一等
- 在网络中传递的数据量一下子就少了,拥塞自然很快就能消减
- 这属于是用tcp协议实现了多主机面对网络出现拥塞问题的共识
当然,也不是所有主机都能识别到网络拥塞,也就不会触发拥塞控制,可能它发送的数据少,丢包的就少
- 网络拥塞程度越严重,影响的主机越多,就有更多的主机触发拥塞控制,减少数据量的发送
- 如果网络拥塞并不严重,也就只会带动少量的主机
- 挺巧妙的
当识别到网络拥塞时,我们需要引入一个新概念 -- 慢启动
同时也要引入一个新窗口 -- 拥塞窗口
拥塞窗口
介绍
初始值为1,以指数级增长
- 在慢启动阶段，拥塞窗口的大小会随着每次收到一个ACK而指数增长，直到达到慢启动阈值
决定滑动窗口的大小
每次发送报文时,不仅要考虑对方的接收能力,也要考虑网络的拥塞情况
- 所以,实际发送数量 = min( 拥塞窗口大小,对方的接收窗口大小 )
而我们知道,发送数据的量取决于滑动窗口的大小
- 所以,我们就能修改之前对滑动窗口大小的认知了:
- 滑动窗口大小=min(拥塞窗口大小,对方的接收窗口大小)
因为即使对方的接收能力很强,网络容纳不下也是白搭
- 所以也需要动态考虑网络的接收能力
- 反过来也是如此
- 所以,需要以最小限度作为限制
同样的,滑动窗口的右指针的计算方式也要变
- 因为要考虑网络状况,所以end = min( 接收窗口大小,有效数据大小,拥塞窗口大小 )
慢启动
介绍
慢启动是TCP连接建立后的初始阶段
- 其目的是为了迅速估计网络的可用带宽和避免拥塞
- 在慢启动阶段，发送方以指数增长的方式增加拥塞窗口的大小，从而逐渐增加发送的数据量，直到达到一个阈值
- 慢启动只是初始值增长的慢,一段时间后就很恐怖了
所以,为什么慢启动可以控制发送方发送的数据量?
- 因为它可以限制滑动窗口大小
- 也就是上面说的,滑动窗口大小的取决因素里,有拥塞窗口的存在
为什么要有慢启动
因为需要在前期发送少量报文
- 用于试探网络状态
如果发送的报文基本都有应答,说明此时网络很健康
- 那么就该加大发送力度,就不能让拥塞窗口大小限制住数据发送量了
- (中后期拥塞窗口很大,计算实际发送量时,只取决于对方的接收能力)
阈值
当然,拥塞窗口也不能这样一直增大下去,超变量范围了怎么办
- 所以要引入慢启动的阈值
超过这个阈值后,窗口大小将以线性方式增长,也就退出慢启动阶段
如果在增长的过程中出现了网络拥塞
- 就以此时的窗口大小作为基准值,进行某一运算后得到新的阈值
- 然后以新的阈值重新进行慢启动,达到阈值后就变为线性增长
但是,也不一定就会出现网络阻塞
- 并且当滑动窗口大小取决于接收窗口大小时,阻塞窗口更不更新就不重要了
算法
新阈值=导致拥塞的窗口大小/2
- /2可能是经过实验得到的比较合适的算法
- 策略/原理啥的都需要经过测试,测试得出来确实是效率更高,所以就采用了
总结
所以,我们现在拥有三个窗口,接收窗口,滑动窗口,拥塞窗口
拥塞窗口 --- 主机衡量网络健康状态的指标
- 因为网络是动态变化的,所以拥塞窗口本身就不是静态的
- 如果发送数据量超过拥塞窗口大小,就会引起网络拥塞