思考重点
- TCP具有那些性能优化机制?
- 滑动窗口的特色?
- 滑动窗口发生丢包怎麽办?
核心知识
一系列的优化机制
起初的TCP採用一问一答模式,也就是说发送方一定要等到接收方返回ACK消息才能进行下一个封包的发送,撇除逾时不说,在等待的过程中等于发送方什麽事也不能做,白白浪费了这一段时间。
为了解决这个问题,发明了滑动视窗控制,使得在等待的过程中也可以持续发送封包消息,并且滑动视窗拥有比逾时重传更高效的高速重送机制,大大提升了效率问题
实现滑动视窗目的: 提高通讯效率问题
但问题来了,这麽高密度的传送封包,接收方可以承受得住吗?其实接收方有配备一个专门用来接收封包的缓冲区,若是发送来的封包来不及处理,可以先暂时储存到缓冲区中,等待之后应用程式来捞数据。问题看似解决了,其实没有。
当发送方的封包到达速率远远大于接收方处理封包的速率,就会造成缓冲区溢出问题,因此需要引入了流量控制,还记得前面提到的视窗大小吗?引入流量控制会依据接收方缓冲区当前剩馀的容量来告知发送方发送封包的限制大小
实现流量控制目的: 依照接收方缓冲区大小调整封包的视窗大小
既然我们实现了高效的通讯机制以及及时调整视窗大小的功能,大抵上应该没有任何问题了吧?
请大家不要忽略了封包现实传送中的状况,以上两点的判断背景都是假设封包在传送路途中没有历经各种网路塞车问题,换言之就是将封包往返时间看成一个不变的定值,也可以说是完美的状态。
但在现实场景,网路的连线品质是一直在变动的。由于这个问题,我们不得不考虑接收方计算出来的视窗大小是否符合当前网路的连线能力,有点像高速公路目前只能容忍10台车,这时候你硬要派20台车上路,结果可想而知
实现壅塞控制目的: 依照真实情景调整允许的视窗大小,若视窗大小超过上限,则以上限为主
视窗控制
视窗控制的目的就是为了提高单位时间内发送封包的效率,而视窗控制使用了视窗大小这个概念,由接收方判断当前缓冲区可以储存多长的资料,再透过ACK告知发送方。右图中假设视窗大小为