TCP超时重传
TCP超时重传
TCP中的4个计时器
TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单,但重传时间的选择却是TCP最复杂的问题之一。在这之前先了解一下TCP中用到的一些计时器。
TCP传输过程中需要用到4个计时器,重传计时器、坚持计时器、保活计时器、时间等待计时器。
重传计时器(retransmission timer)
为了控制丢失报文端或者丢弃报文段。这段时间为对报文段的等待确认时间。在TCP发送报文段时创建重传计时器。下面会重点介绍。
坚持计时器(persistent timer)
主要解决零窗口大小通知可能导致的死锁问题。
死锁问题产生的原因:
当A的接收窗口大小为0时,A向B发送一个零窗口报文段,B即停止向对端发送数据。当A缓存区有空间时,则会更新报文中的窗口字段。但此条报文可能会丢失,并且A无法感知到。而B没收到A的确认报文,不会发送新的数据。此时双方陷入等待死锁
当B收到窗口为零的报文段时,就会启动坚持计时器。当时间超过限制,B主动发送一个特殊报文告诉对方确认已丢失,让A重新发送确认报文段。
保活计时器(Keeplive timer)
为了防止两个TCP连接出现长时间的空闲。当客户端与服务器建立TCP连接之后,很长时间内客户端都没有向服务器端发送数据,此时可能是客户端故障,而服务端会一直处于等待状态。
每当服务器端收到客户端的数据时,都将保活计时器重新设置(通常设置为2小时)。过了2小时后,服务器端如果没有收到客户端的数据,会发送探测报文段给客户端,并且每隔75秒发送一个,当连续发送10次以后,仍没有收到对端的来信,则服务器端认为客户端出现故障,并会终止连接。
时间等待计时器(time_wait timer)
时间等待计时器是在连接终止期间使用的。
当TCP断开连接时被动断开连接的一方并不是立即进入CLOSED已断开状态(总结四次挥手时提到过)
RTO
超时重传的时间需要巧妙设计,如果时间设置太短,就会引起很多报文段的不必要重传,使网络符合增大。但若把超时重传时间设置过长,则又使网络的空闲时间增大,降低了传输效率。
因此TCP采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs(这又成为平滑的往返时间,S表示smoothed)。当第一次测量到RTT样本时,RTTs值就取为所测量到的RTT样本值。
超时计时器设置的超时重传时间RTO(retransmission Time-out)应略大于上面得到的加权往返时间RTTs。
选择确认SACK
上篇提到滑动窗口内有些报文时未按序到达的。那么有没有一种方法只重传缺少的数据不重传已经正确到达接收方的数据?选择确认就是一种可行的处理方法。
TCP首部前20个字节已经固定好了, 这种方式需要在TCP首部选项可变字段里加一个SACK的东西,它可以将缓存信息发给对方,这样发送方就知道哪些数据收到了,哪些数据没收到。知道了这些数据就可以只传送未收到的数据了。
2、本资源基本为原创,部分来源其他付费资源平台或互联网收集,如有侵权请联系及时处理。
3、本站大部分文章的截图来源实验测试环境,请不要在生产环境中随意模仿,以免带来灾难性后果。
转载请保留出处: www.zh-cjh.com珠海陈坚浩博客 » TCP超时重传
作者: cjh
手机扫一扫,手机上查看此文章: |
一切源于价值!
其他 模板文件不存在: ./template/plugins/comment/pc/index.htm