【每日一记11】+第8天:彻底弄懂TCP协议:从三次握手说起(八)
  

易逝的信仰 654

{{ttag.title}}
【2】TCP 的重传机制

通过上面我们可以知道,TCP 的重传是由超时触发的,这会引发一个重传选择问题,假设 TCP 发送端连续发了 1、2、3、4、5、6、7、8、9、10 共 10 包,其中 4、6、8 这 3 个包全丢失了,由于 TCP 的 ACK 是确认最后连续收到序号,这样发送端只能收到 3 号包的 ACK,这样在 TIME_OUT 的时候,发送端就面临下面两个重传选择:[1].仅重传 4 号包 [2].重传 3 号后面所有的包,也就是重传 4~10 号包

对于,上面两个选择的优缺点都比较明显。方案[1],优点:按需重传,能够最大程度节省带宽。缺点:重传会比较慢,因为重传 4 号包后,需要等下一个超时才会重传 6 号包。方案[2],优点:重传较快,数据能够较快交付给接收端。缺点:重传了很多不必要重传的包,浪费带宽,在出现丢包的时候,一般是网络拥塞,大量的重传又可能进一步加剧拥塞。

上面的问题是由于单纯以时间驱动来进行重传的,都必须等待一个超时时间,不能快速对当前网络状况做出响应,如果加入以数据驱动呢?TCP 引入了一种叫 Fast Retransmit(快速重传)的算法,就是在连续收到 3 次相同确认号的 ACK,那么就进行重传。这个算法基于这么一个假设,连续收到 3 个相同的 ACK,那么说明当前的网络状况变好了,可以重传丢失的包了。

快速重传解决了 timeout 的问题,但是没解决重传一个还是重传多个的问题。出现难以决定是否重传多个包问题的根源在于,发送端不知道那些非连续序号的包已经到达接收端了,但是接收端是知道的,如果接收端告诉一下发送端不就可以解决这个问题吗?于是,RFC2018 提出了 Selective Acknowledgment(SACK,选择确认)机制,SACK 是 TCP 的扩展选项,包括(1)SACK 允许选项(Kind=4,Length=2,选项只允许在有 SYN 标志的 TCP 包中),(2)SACK 信息选项 Kind=5,Length)。一个 SACK 的例子如下图,红框说明:接收端收到了 0-5500,8000-8500,7000-7500,6000-6500 的数据了,这样发送端就可以选择重传丢失的 5500-6000,6500-7000,7500-8000 的包。



SACK 依靠接收端的接收情况反馈,解决了重传风暴问题,这样够了吗?接收端能不能反馈更多的信息呢?显然是可以的,于是,RFC2883 对对 SACK 进行了扩展,提出了 D-SACK,也就是利用第一块 SACK 数据中描述重复接收的不连续数据块的序列号参数,其他 SACK 数据则描述其他正常接收到的不连续数据。这样发送方利用第一块 SACK,可以发现数据段被网络复制、错误重传、ACK 丢失引起的重传、重传超时等异常的网络状况,使得发送端能更好调整自己的重传策略。D-SACK,有几个优点:

1)发送端可以判断出,是发包丢失了,还是接收端的 ACK 丢失了。(发送方,重传了一个包,发现并没有 D-SACK 那个包,那么就是发送的数据包丢了;否则就是接收端的 ACK 丢了,或者是发送的包延迟到达了);2)发送端可以判断自己的 RTO 是不是有点小了,导致过早重传(如果收到比较多的 D-SACK 就该怀疑是 RTO 小了);3)发送端可以判断自己的数据包是不是被复制了。(如果明明没有重传该数据包,但是收到该数据包的 D-SACK);4)发送端可以判断目前网络上是不是出现了有些包被 delay 了,也就是出现先发的包却后到了。

疑症(9)TCP 的流量控制

我们知道 TCP 的窗口(window)是一个 16bit 位字段,它代表的是窗口的字节容量,也就是 TCP 的标准窗口最大为 2^16-1=65535 个字节。另外在 TCP 的选项字段中还包含了一个 TCP 窗口扩大因子,option-kind 为 3,option-length 为 3 个字节,option-data 取值范围 0-14。窗口扩大因子用来扩大 TCP 窗口,可把原来 16bit 的窗口,扩大为 31bit。

这个窗口是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。也就是,发送端是根据接收端通知的窗口大小来调整自己的发送速率的,以达到端到端的流量控制。尽管流量控制看起来简单明了,就是发送端根据接收端的限制来控制自己的发送就好了,但是细心的同学还是会有些疑问的。

1)发送端是怎么做到比较方便知道自己哪些包可以发,哪些包不能发呢?2)如果接收端通知一个零窗口给发送端,这个时候发送端还能不能发送数据呢?如果不发数据,那一直等接收端口通知一个非 0 窗口吗,如果接收端一直不通知呢?3)如果接收端处理能力很慢,这样接收端的窗口很快被填满,然后接收处理完几个字节,腾出几个字节的窗口后,通知发送端,这个时候发送端马上就发送几个字节给接收端吗?发送的话会不会太浪费了,就像一艘万吨油轮只装上几斤的油就开去目的地一样。对于发送端产生数据的能力很弱也一样,如果发送端慢吞吞产生几个字节的数据要发送,这个时候该不该立即发送呢?还是累积多点在发送?

打赏鼓励作者,期待更多好文!

打赏
1人已打赏

新手229660 发表于 2020-9-11 10:42
  
感谢分享
伊利丹·怒风 发表于 2021-6-24 16:02
  

感谢楼主的精彩分享,有助工作
伊利丹·怒风 发表于 2021-6-24 16:03
  

感谢楼主的精彩分享,有助工作
伊利丹·怒风 发表于 2021-6-27 23:05
  
多谢楼主的分享,期待你的更多技术贴
发表新帖
热门标签
全部标签>
每日一问
每周精选
技术盲盒
技术笔记
2024年技术争霸赛
产品连连看
干货满满
2023技术争霸赛专题
技术咨询
标准化排查
新版本体验
通用技术
技术晨报
秒懂零信任
自助服务平台操作指引
文档捉虫活动
信服课堂视频
每日一记
GIF动图学习
答题自测
功能体验
SDP百科
技术圆桌
排障笔记本
专家问答
在线直播
安装部署配置
测试报告
运维工具
存储
畅聊IT
MVP
网络基础知识
升级
安全攻防
上网策略
日志审计
问题分析处理
流量管理
云计算知识
用户认证
原创分享
解决方案
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
迁移
加速技术
产品预警公告
玩转零信任
信服圈儿
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
深信服技术支持平台
社区帮助指南
答题榜单公布
纪元平台
卧龙计划
华北区拉练
天逸直播
以战代练
山东区技术晨报
齐鲁TV
华北区交付直播
北京区每日一练

本版版主

461
245
13

发帖

粉丝

关注

本版达人

feeling

本周分享达人

新手29676...

本周提问达人