一 TCP 为什么需要重传

因为网络层有可能出现数据包丢失,数据包重复或者无序的情况。为了保证数据传输正确,不重复和有序,所以TCP才提供可靠的数据传输服务。为了保证数据传输的正确性,所以TCP重传它认为已经丢失的包。

TCP如何确认呢?TCP根据接收端返回至发送端的一系列确认信息来判断是否出现丢包。当数据段或确认信息信息丢失,则TCP触发重传操作。

二 重传机制

TCP拥有两套独立机制来完成重传,一是基于时间,而是基于确认信息的构成。

2.1 基于计时器的重传

一旦TCP发送端获取到了基于时间变化的RTT(Round Trip Time:就是数据段发送到收到确认包之间时间)测量值,就可以据此设置RTO(Retransmission Timeout: 重传超时时间,即从发送数据段开始到第一次重传开始之间的时间段)

在TCP发送端需要设置一个计时器以及记录被计时的数据段序列号,如果发送端及时收到了该数据段的确认,那么计时器取消。然后有新的数据段需要发送,在设定一个新的计时器,并记录新序列号。

所以每一个TCP连接的发送端不断地设定和取消一个重传计时器;如果没有数据丢失,则不会出现计时器超时。若在RTO设定的时间内,没有收到该数据段的确认,将会触发超时重传。

一般RTO的设置通常大于RTT(约2倍或者更大),因此基于计时器的重传会导致网络利用率下降。

2.2 快速重传

快速重传是基于接收端的反馈信息来引发重传,而非重传计时器的超时,和超时重传相比,快速重传能够更加及时和有效的修复丢包情况。

当接收端收到比期望序列号大的报文段的时候,便会重复发送最近一次确认的报文段的确认号,我们也称为重复ACK(duplicate ACK)

我们从图中可以接收端并没有收到1461开始的数据段,那么当第一个数据包到达接收端的时候,ack number=1461,这个1461也是接收端期望的报文段序列号,如果不是当新的报文段来的时候,还是返回之前重复的ack number。

如果超时重传定时器超时之前,接受到三个连续的重复ACK,便知道哪一个报文段丢失了,于是重发该报文段,不需要等到超时,大大提高了重传效率。

但是这里还有个问题就是,假设报文段来的时候有顺序问题,比如2021报文段先到来,1461后到来,并没有丢失这个报文段,无非排下顺序就好,所以我们通过一个duplicate ACK并不能确认是发生了丢包还是顺序乱了,所以设置一个阀值,叫做dupthresh。当TCP收到的duplicate ACK个数超过这个dupthresh的时候就认为丢包。默认应该是3,Linux系统可以通过/proc/sys/net/ipv4/tcp_reordering来设置默认值。

2.3 选择确认重传(SACK)

2.3.1 什么是SACK

SACK: Selective Acknowledgement缩写,即选择性确认。指的就是在确认的时候,将对失序数据,只重传丢失的数据,对于没有丢失的数据,我们通过在首部指定其左右边界,就可以在重传的时候,避免再发送一次,提高重传效率。

核心思想: 不重传已经正确接收的数据

那么SACK到底是什么样子呢?

SACK: 包含以下属性

第一:kind, 1个字节

第二:length, 1个字节

第三:left edge(左边界)4个字节

第四:right edge(右边界)4个字节

每一个SACK块都是10个字节

SACK是TCP选项部分的字段,因为TCP选项部分最多可以是40个字节,所以最多只可以有4个SACK块,也就是说最多只允许不重传4个数据段

结构如下:

如上图所示:接收端返回ack numer是4381,因为5841被正确接收,所以我们指明5841这个报文段的它的边界:左边界5841,右边界7301.

2.3.2 为什么使用SACK

我们知道,为了提升效率,我们可以使用快速重传机制,快速重传的核心就是判断接受到的数据段的序列号(seq)和期望的确认号(ack number) 是否一致,如果不一致,则有可能数据丢失或者迟到了,所以设置一个dupthresh阀值,如果超过了则个阀值就认为是数据丢失。

最后返回这个ack number,然后到期后,从这个ack number开始重传之后的报文段,因为可能有些报文段,已经被确认了,所以这会带来性能问题,效率不高。所以就需要一种机制,将只是丢失的数据重传。

2.3.3 SACK重传在接收端和发送端是如何工作的?

接收端:

#1 没当缓存存在失序数据时候,接收端就可以生成SACK.(假设数据丢失,并不是顺序问题)

#2 第一个SACK块里包含最近收到的报文段序列号范围,其余的也是按照接收的先后顺序依次排列

发送端:

发送端应该使用接收端生成的SACK块进行丢失重传,这个过程也叫作选择性重传(selective retransmission)或者(selective repeat)选择性重发。

然后在重传的时候,会根据SACK提供的序列号范围以及ACK信息,避免那些已经被接收端正确接收的数据然后重复发送。当然这也仅限于4个块,多了还是要重复发送。

四 如何确定超时重传时间(RTO)

如果RTO设置较短,有的报文段可能因为网络延迟大而已,这样就会造成不必要的重传;如果设置较大,有可能使得发送端需要等待超时时间过长才会发现数据丢失,影响网络传输效率。

一般来说RTO = RTT + 一部分调整时间

4.1 如何确定RTT时间

4.1.1 通过时间戳选项

#1在发送端发送报文段的时候,把当前时钟放入时间戳字段

#2接收端接受到报文段确认的时候,把这个时间戳复制到确认包中的时间戳

4.1.2 RTT时间调整

如果我们仅用上一次的RTT作为RTO计算标准是否可行? 很明显不好,偶然性太大,比如本来网络好好的,突然这一次发送慢了很多,那如果以这次慢的作为RTT时间,那如果下一次又回到以前水平呢。

所以引入了SRTT(Smooth RTT ),计算公式如下:

SRTT = (α * SRTT) + ( (1 -α) *RTT)

第一次SRTT = 采样的RTT, 后面的采样计算时候SRTT就是前面迭代计算出来的SRTT.

但是这个有个问题,就是在重传的时候的确认的时间是减去这个报文段第一次发送的时间还是重新发送的时间,如果是第一次发送时间,那么RTT值就大了,如果是重新发送时间,又有点小。

所以又有了Karn提出来一个算法,采集RTT的时候直接忽略重传。但是还是有有问题。假设在某个时间,网络突然不好,由快变得很慢,导致所有的很多包都要重传。因为前面一直很通畅,所以必然RTO很小,那么你又说重传的包不参与RTT的采样, RTO永远不会更新,只会不断的重传,情况会越来越糟。而Karn针对这个提出了一个解决方案,只要重传,那么RTO就翻倍,这样就保证了在极端情况下不会导致越来越糟。

但是还是比较不友好的,后面又有人提出了改进方法,也是现在TCP协议使用的方式,新采样的RTT和平滑过的SRTT的差距来作为另一个影响因子。

SRTT = SRTT + α * (RTT - SRTT)

DevRTT = (1-β) * DevRTT + β *(|RTT - SRTT|)

RTO = μ * SRTT + δ * DevRTT

Linux中取值: α是取0.125,β是0.25,μ 是1,δ是4

网络协议:超时与重传机制相关推荐

  1. TCP超时与重传机制与拥塞避免

    TCP超时与重传机制 TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制. 基本原理:在发送一个数据之后,就开启一个定时器,若是 ...

  2. TCP超时与重传机制

    TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制.其基本原理:在发送一个数据之后,就开启一个定时器 ...

  3. 网络协议:TCP保活机制和Nagle算法

    一 Nagle算法背景 有时候,我们可能会遇到一些很小的分组,比如,20字节的IP首部,20字节的TCP首部和1字节的数据,如果很多这样的小分组数据,在局域网一般不会出现拥塞,但是在广域网就可有可能. ...

  4. TCP协议可靠性保证(确认应答机制,超时重传机制,流量控制,拥塞窗口)

    上一次我们知道了TCP协议通过连接管理机制保证可靠性,今天我们继续来看一看TCP协议中其他几种保证可靠性的方法. · 确认应答机制  · 超时重传机制  · 流量控制  · 拥塞窗口 确认应答机制  ...

  5. TCP协议-TCP超时重传机制

    一.前言 在TCP通信中,既要保证在网络正常的情况下提供可靠的交付服务,又要保证在网络异常的情况下也提供可靠的交付服务.而TCP的超时重传机制就是解决在网络异常情况下的可靠传输问题的. 二.通过序列号 ...

  6. 网络协议 TCP 数字编号和重传机制

    网络协议 TCP 数字编号和重发 1. TCP 的数字编号 2. TCP 确认机制的特点 2.1 TCP一次可发送多个数据包 2.2 仅对连续接收的数据段进行确认 2.3 不连续的数据将先缓存 3. ...

  7. 4-5:TCP协议之确认应答(ACK)机制和超时重传机制

    文章目录 一:TCP的确认应答(ACK)机制 二:超时重传机制 一:TCP的确认应答(ACK)机制 在TCP中,当发送端的数据达到接收主机时,接收端主机会返回一个已收到消息的通知,这个消息叫做ACK( ...

  8. TCP之超时重传机制

    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错.超时丢包等问题TCP设计了超时重传机制,其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送 ...

  9. TCP/IP协议栈:TCP超时重传机制

    目录 基础概念 重传超时时间RTO RTO的设定 连接往返时间RTT RTT的计算 Karn算法 往返时间测量 重传 拥塞避免算法 快速重传和快速恢复算法 重新分组 网络数据包丢失,重传和重复确认 是 ...

最新文章

  1. Ruby调用shell命令
  2. 使用Redis 管理事务(Java)
  3. testNG入门详解
  4. 苏杰专访:产品创新好方向=几十年不变的需求+硬科技赋能
  5. php显示几个字符串,比较php中的两个字符串并显示字符差异
  6. Css中部分知识点整理【笔记整理】
  7. totoisegit不显示对勾_暗黑2画质不满意?教你简单安装高分辨率补丁
  8. 用typescript完成倒计时_「2019 JSConf.Hawaii - Brie.Bunge」大规模应用 TypeScript
  9. 【OpenCV入门指南】第七篇 线段检测与圆检测
  10. hadoop无法停止
  11. 明汯投资掌门人裘慧明:今年特别难,未来两三年也难
  12. linux 文本编辑器Vim/Vi详细介绍
  13. Notepad2 v4.22.03 (r4130) 轻量级文本编辑器。可替换系统记事本
  14. cboard企业版源码_CBoard的部署与使用
  15. 数据库复习-3.常用的概念模型
  16. 在计算机操作中粘贴的快捷键是什么,复制粘贴的快捷键,详细教您电脑怎么使用快捷键复制粘贴...
  17. 1000+常用Python库大全,太实用了!
  18. 【WPF、UWP】搜索蓝牙设备
  19. 【论文翻译】Learning from Few Samples: A Survey 小样本学习综述
  20. java实现word、pdf、excel文件下载功能

热门文章

  1. python web性能不如php_Python比PHP更加适合网络开发的原因
  2. k8s调度 原理_开源爆款,阿里P7技术笔记《k8s+docker》,图文并茂,理论与实战齐飞!...
  3. php apache很慢,Apache 服务器 首次访问特别慢的解决过程,php环境
  4. Django返回数据给ajax,Django返回JsonResponse并在ajax请求中捕获数据
  5. elasticsearch 条件去重_Elasticsearch学习之查询去重
  6. html5缓动下拉菜单,HTML5 Canvas鼠标跟随的缓动效果
  7. mysql geometry 附近的人_mysql中geometry类型的简单使用(搜索附近的人)
  8. MySQL InnoDB 存储引擎文件
  9. SpringCloud Consul Config 配置中心(一)
  10. python-kafka多线程快速读取consumer消费者数据,同时使用批读取与无限流读取改进