停止等待ARQ协议
-
早期的停止等待ARQ协议
1、发送方发送一个数据包给接收方，等待接收方回复确认收到的响应后再发送下一个数据包。
2、如果接收方收到的数据有问题会丢弃，不会回复确认收到响应，发送方长时间未收到确认响应则重新发送这个数据包。
ARQ (Automatic Repeat -reQuest)，自动重传请求
停止等待ARQ协议.png
-
确认丢失
发送方发给接收方数据包后如果没有收到确认回复就会超过一段时间重新发送。接收方收到重复的数据包会丢弃掉，重新发送确认回复。 -
确认迟到
发送方如果延迟了一段时间才收到上次的发送数据包确认回复，但是已经重新发送过数据包了，就什么都不做。
重传.png
疑问
Q:若有个包重传了N次还是失败，会一直持续重传到成功为止么?
A:这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文(RST) 断开TCP连接
重传次数过多.png
连续ARQ协议+滑动窗口协议
-
早期的停止等待ARQ协议
每次发送一个数据后都要等待，非常耗费时间所以很低效 -
连续ARQ协议+滑动窗口协议
接收方会告诉发送方自己的接收窗口有多大，下次请发送这么大的数据给我。发送方的发送窗口每次会发送多个数据包，等待收到确认回复后，发送窗口滑到下一次需要发送的多个数据包处，再发送多个包。 -
如果接收窗口最多能接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包?
接收方会等待一定时间后没有第3个包，就会返回确认收到2个包给发送方
对比图.png
SACK（选择性确认）
-
数据分组
1、例如要发送的是一个1200字节的数据包
2、现在假设每一组数据是100个字节，代表一个数据段的数据
3、每一组给一个编号，分批次发送出去
分段图.png
- 在TCP通信过程中，如果发送序列中间某个数据包丢失(比如1、2、3、4、5中的3丢失了)
- TCP会通过重传最后确认的分组后续的分组(最后确认的是2,会重传3、4、5)
- 这样原先已经正确传输的分组也可能重复发送(比如4、5)，降低了TCP性能
-
为改善.上述情况，发展出了SACK (Selective acknowledgment,选择性确认)技术
1.告诉发送方哪些数据丢失，哪些数据已经提前收到
2.使TCP只重新发送丢失的包(比如3)，不用发送后续所有的分组(比如4、5)
SACK结构.png
-
SACK信息会放在TCP首部的选项部分
1.Kind: 占1字节。值为5代表这是SACK选项
2.Length:占1字节。表明SACK选项一共占用多少字节
3.Left Edge:占4字节,左边界
4.Right Edge: 占4字节,右边界
image.png
-
一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以
1.SACK选项最多携带4组边界信息
2.SACK选项的最大占用字节数= 4*8+ 2 = 34
思考
-
为什么选择在传输层就将数据"大卸八块”分成多个段,而不是等到网络层再分片传递给数据链路层?
1.因为可以提高重传的性能
2.需要明确的是:可靠传输是在传输层进行控制的
3.如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传
4.如果在传输层分了段,一旦出现数据丢失，只需要重传丢失的那些段即可
网友评论