#每天一记#TCP的七种定时器
  

SXF星海 7951人觉得有帮助

{{ttag.title}}
今天给大家分享的是TCP的定时器,算上今天的这次分享,TCP的分享我一共分享了四篇,大家看完之后,基本可以算TCP的入门。首先,声明一下,这不是我原创,因为我学习的时候,我只学习了四种,但是TCP有四种,所以我就找了一个比较全的,来分享给大家,文中最后,我同样会附上文章摘抄的原处。

TCP中的7种定时器:
建立连接定时器(connection-establishment timer)
重传定时器(retransmission timer)
延迟应答定时器(delayed ACK timer)
坚持定时器(persist timer)
保活定时器(keepalive timer)
FIN_WAIT_2定时器(FIN_WAIT_2 timer)
TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

1、建立连接定时器(connection-establishment timer)
  顾名思义,这个定时器是在建立连接的时候使用的, 我们知道, TCP建立连接需要3次握手, 如下图所示:

建立连接的过程中,在发送SYN时, 会启动一个定时器(默认应该是3秒),如果SYN包丢失了, 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器, 设置成6秒超时),当然也不会一直没完没了的发SYN包, 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。

2、重传定时器(retransmission timer)
  重传定时器在TCP发送数据时设定,在计时器超时后没有收到返回的确认ACK,发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则:
当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器;   
如果队列为空则停止计时器,否则重启计时器;
当计时器超时后,TCP会重传发送队列最前端的报文段;
当一个或者多个报文段被累计确认后,这个或者这些报文段会被清除出队列
  重传计时器保证了接收端能够接收到丢失的报文段,继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

3、延迟应答定时器(delayed ACK timer)
  延迟应答也被成为捎带ACK, 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢? 延迟应答是为了提高网络传输的效率。
   举例说明,比如服务端收到客户端的数据后, 不是立刻回ACK给客户端, 而是等一段时间(一般最大200ms),这样如果服务端要是有数据需要发给客户端,那么这个ACK就和服务端的数据一起发给客户端了, 这样比立即回给客户端一个ACK节省了一个数据包。

4、坚持定时器(persist timer)
  我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为 0会发生什么情况呢?这将有效地阻止发送方传送数据,直到窗口变为非0为止。接收端窗口变为非0后,就会发送一个确认ACK指明需要的报文段序号以及窗口大小。
   如果这个确认ACK丢失了,则双方就有可能因为等待对方而使连接终止:接收方等待接收数据(因为它已经向发送方通告了一个非0的窗口),而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生,发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询,以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

5、保活定时器(keepalive timer)
  在TCP连接建立的时候指定了SO_KEEPALIVE,保活定时器才会生效。如果客户端和服务端长时间没有数据交互,那么需要保活定时器来判断是否对端还活着,但是这个其实很不实用,因为默认是2小时没有数据交互才探测,时间实在是太长了。如果你真的要确认对端是否活着, 那么应该自己实现心跳包,而不是依赖于这个保活定时器。

6、FIN_WAIT_2定时器(FIN_WAIT_2 timer)
  主动关闭的一端调用完close以后(即发FIN给被动关闭的一端, 并且收到其对FIN的确认ACK)则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因,导致主动关闭的一端不能收到被动关闭的一端发来的FIN,主动关闭的一段总不能一直傻等着,占着资源不撒手吧?这个时候就需要FIN_WAIT_2定时器出马了, 如果在该定时器超时的时候,还是没收到被动关闭一端发来的FIN,那么不好意思, 不等了, 直接释放这个链接。FIN_WAIT_2定时器的时间可以从/proc/sys/net/ipv4/tcp_fin_timeout中查看和设置。

7、TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)
  TIME_WAIT是主动关闭连接的一端最后进入的状态, 而不是直接变成CLOSED的状态, 为什么呢?第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK, 则会重发最后的FIN,2MSL(报文段最大生存时间)等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK;另外一个原因是在2MSL等待时间时,任何迟到的报文段会被接收并丢弃,防止老的TCP连接的包在新的TCP连接里面出现。不可避免的,在这个2MSL等待时间内,不会建立同样(源IP, 源端口,目的IP,目的端口)的连接。

链接:https://www.cnblogs.com/Jummyer/p/11069241.html

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

打赏
1人已打赏

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

本版版主

12
185
6

发帖

粉丝

关注

本版达人

LoveTec...

本周分享达人

新手24116...

本周提问达人