[转帖]4000字详解TCP超时与重传,看完没收获算我输

4000字详解TCP超时与重传,看完没收获算我输

https://network.51cto.com/art/202001/608869.htm

上一篇介绍 TCP 的文章「TCP 三次握手,四次挥手和一些细节」反馈还不错,还是蛮开心的,这次接着讲一讲关于超时和重传那一部分。

我们都知道 TCP 协议具有重传机制,也就是说,如果发送方认为发生了丢包现象,就重发这些数据包。很显然,我们需要一个方法来「猜测」是否发生了丢包。最简单的想法就是,接收方每收到一个包,就向发送方返回一个 ACK,表示自己已经收到了这段数据,反过来,如果发送方一段时间内没有收到 ACK,就知道很可能是数据包丢失了,紧接着就重发该数据包,直到收到 ACK 为止。

你可能注意到我用的是「猜测」,因为即使是超时了,这个数据包也可能并没有丢,它只是绕了一条远路,来的很晚而已。毕竟 TCP 协议是位于传输层的协议,不可能明确知道数据链路层和物理层发生了什么。但这并不妨碍我们的超时重传机制,因为接收方会自动忽略重复的包。

超时和重传的概念其实就是这么简单,但内部的细节却是很多,我们最先想到的一个问题就是,到底多长时间才能算超时呢?

一、超时是怎么确定的?

一刀切的办法就是,我直接把超时时间设成一个固定值,比如说 200ms,但这样肯定是有问题的,我们的电脑和很多服务器都有交互,这些服务器位于天南海北,国内国外,延迟差异巨大,打个比方:

  • 我的个人博客搭在国内,延迟大概 30ms,也就是说正常情况下的数据包,60ms 左右就已经能收到 ACK 了,但是按照我们的方法,200ms 才能确定丢包(正常可能是 90 到 120 ms),这效率实在是有点低。
  • 假设你访问某国外网站,延迟有 130 ms,这就麻烦了,正常的数据包都可能被认为是超时,导致大量数据包被重发,可以想象,重发的数据包也很容易被误判为超时。。。雪崩效应的感觉

所以设置固定值是很不可靠的,我们要根据网络延迟,动态调整超时时间,延迟越大,超时时间越长。

在这里先引入两个概念:

  • RTT(Round Trip Time):往返时延,也就是**数据包从发出去到收到对应 ACK 的时间。**RTT 是针对连接的,每一个连接都有各自独立的 RTT。
  • RTO(Retransmission Time Out):重传超时,也就是前面说的超时时间。

比较标准的 RTT 定义:

Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number (segments sent do not have to match segments received). This measured elapsed time is the Round Trip Time (RTT).

1. 经典方法

最初的规范「RFC0793」采用了下面的公式来得到平滑的 RTT 估计值(称作 SRTT):

  1. SRTT  <-  α·SRTT +(1 - α)·RTT

RTT 是指最新的样本值,这种估算方法叫做「指数加权移动平均」,名字听起来比较高大上,但整个公式比较好理解,就是利用现存的 SRTT 值和最新测量到的 RTT 值取一个加权平均。

有了 SRTT,就该设置对应的 RTO 的值了,「RFC0793」是这么算的:

  1. RTO = min(ubound, max(lbound, (SRTT)·β))

这里面的 ubound 是 RTO 的上边界,lbound 为 RTO 的下边界,β 称为时延离散因子,推荐值为 1.3 ~ 2.0。这个计算公式就是将 (SRTT)·β 的值作为 RTO,只不过另外限制了 RTO 的上下限。

这个计算方法,初看是没有什么问题(至少我是这么感觉的),但是实际应用起来,有两个缺陷:

There were two known problems with the RTO calculations specified in RFC-793. First, the accurate measurement of RTTs is difficult when there are retransmissions. Second, the algorithm to compute the smoothed round-trip time is inadequate [TCP:7], because it incorrectly assumed that the variance in RTT values would be small and constant. These problems were solved by Karn‘s and Jacobson‘s algorithm, respectively.

这段话摘自「RFC1122」,我来解释一下:

当出现数据包重传的情况下,RTT 的计算就会很“麻烦”,我画了张图来说明这些情况:

图上列了两种情况,这两种情况下计算 RTT 的方法是不一样的(这就是所谓的重传二义性):

但是对于客户端来说,它不知道发生了哪种情况,选错情况的结果就是 RTT 偏大/偏小,影响到 RTO 的计算。(最简单粗暴的解决方法就是忽略有重传的数据包,只计算那些没重传过的,但这样会导致其他问题。。详见 Karn‘s algorithm)

  • 情况一:RTT = t2 - t0
  • 情况二:RTT = t2 - t1

另一个问题是,这个算法假设 RTT 波动比较小,因为这个加权平均的算法又叫低通滤波器,对突然的网络波动不敏感。如果网络时延突然增大导致实际 RTT 值远大于估计值,会导致不必要的重传,增大网络负担。( RTT 增大已经表明网络出现了过载,这些不必要的重传会进一步加重网络负担)。

2. 标准方法

说实话这个标准方法比较,,,麻烦,我就直接贴公式了:

  • SRTT <- (1 - α)·SRTT + α·RTT //跟基本方法一样,求 SRTT 的加权平均
  • rttvar <- (1 - h)·rttvar + h·(|RTT - SRTT |) //计算 SRTT 与真实值的差距(称之为绝对误差|Err|),同样用到加权平均
  • RTO = SRTT + 4·rttvar //估算出来的新的 RTO,rttvar 的系数 4 是调参调出来的

这个算法的整体思想就是结合平均值(就是基本方法)和平均偏差来进行估算,一波玄学调参得到不错的效果。如果想更深入了解这个算法,参考「RFC6298」。

二、重传——TCP的重要事件

1. 基于计时器的重传

这种机制下,每个数据包都有相应的计时器,一旦超过 RTO 而没有收到 ACK,就重发该数据包。没收到 ACK 的数据包都会存在重传缓冲区里,等到 ACK 后,就从缓冲区里删除。

首先明确一点,对 TCP 来说,超时重传是相当重要的事件(RTO 往往大于两倍的 RTT,超时往往意味着拥塞),一旦发生这种情况,TCP 不仅会重传对应数据段,还会降低当前的数据发送速率,因为TCP 会认为当前网络发生了拥塞。

简单的超时重传机制往往比较低效,如下面这种情况:

假设数据包5丢失,数据包 6,7,8,9 都已经到达接收方,这个时候客户端就只能等服务器发送 ACK,注意对于包 6,7,8,9,服务器都不能发送 ACK,这是滑动窗口机制决定的,因此对于客户端来说,他完全不知道丢了几个包,可能就悲观的认为,5 后面的数据包也都丢了,就重传这 5 个数据包,这就比较浪费了。

2. 快速重传

快速重传机制「RFC5681」基于接收端的反馈信息来引发重传,而非重传计时器超时。

刚刚提到过,基于计时器的重传往往要等待很长时间,而快速重传使用了很巧妙的方法来解决这个问题:服务器如果收到乱序的包,也给客户端回复 ACK,只不过是重复的 ACK。就拿刚刚的例子来说,收到乱序的包 6,7,8,9 时,服务器全都发 ACK = 5。这样,客户端就知道 5 发生了空缺。一般来说,如果客户端连续三次收到重复的 ACK,就会重传对应包,而不需要等到计时器超时。

但快速重传仍然没有解决第二个问题:到底该重传多少个包?

3. 带选择确认的重传

改进的方法就是 SACK(Selective Acknowledgment),简单来讲就是在快速重传的基础上,返回最近收到的报文段的序列号范围,这样客户端就知道,哪些数据包已经到达服务器了。

来几个简单的示例:

case 1:第一个包丢失,剩下的 7 个包都被收到了。

当收到 7 个包的任何一个的时候,接收方会返回一个带 SACK 选项的 ACK,告知发送方自己收到了哪些乱序包。注:Left Edge,Right Edge 就是这些乱序包的左右边界。

  1. Triggering    ACK      Left Edge   Right Edge
  2. Segment
  3. 5000         (lost)
  4. 5500         5000     5500       6000
  5. 6000         5000     5500       6500
  6. 6500         5000     5500       7000
  7. 7000         5000     5500       7500
  8. 7500         5000     5500       8000
  9. 8000         5000     5500       8500
  10. 8500         5000     5500       9000

case 2:第 2, 4, 6, 8 个数据包丢失。

  • 收到第一个包时,没有乱序的情况,正常回复 ACK。
  • 收到第 3, 5, 7 个包时,由于出现了乱序包,回复带 SACK 的 ACK。

因为这种情况下有很多碎片段,所以相应的 Block 段也有很多组,当然,因为选项字段大小限制, Block 也有上限。

  1. Triggering  ACK    First Block   2nd Block     3rd Block
  2. Segment            Left   Right  Left   Right  Left   Right
  3. Edge   Edge   Edge   Edge   Edge   Edge
  4. 5000       5500
  5. 5500       (lost)
  6. 6000       5500    6000   6500
  7. 6500       (lost)
  8. 7000       5500    7000   7500   6000   6500
  9. 7500       (lost)
  10. 8000       5500    8000   8500   7000   7500   6000   6500
  11. 8500       (lost)

不过 SACK 的规范「RFC2018」有点坑爹,接收方可能会在提供一个 SACK 告诉发送方这些信息后,又「食言」,也就是说,接收方可能把这些(乱序的)数据包删除掉,然后再通知发送方。以下摘自「RFC2018」:

Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space.

最后一句是说,当接收方缓冲区快被耗尽时,可以采取这种措施,当然并不建议这种行为。。。

由于这个操作,发送方在收到 SACK 以后,也不能直接清空重传缓冲区里的数据,一直到接收方发送普通的,ACK 号大于其最大序列号的值的时候才能清除。另外,重传计时器也收到影响,重传计时器应该忽略 SACK 的影响,毕竟接收方把数据删了跟丢包没啥区别。

4. DSACK 扩展

DSACK,即重复 SACK,这个机制是在 SACK 的基础上,额外携带信息,告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断,是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。

关于 DSACK,「RFC2883」里举了很多例子,有兴趣的读者可以去阅读一下,我这里就不讲那么细了。

原文地址:https://www.cnblogs.com/jinanxiaolaohu/p/12156722.html

时间: 2024-10-12 13:50:00

[转帖]4000字详解TCP超时与重传,看完没收获算我输的相关文章

OSI七层模型详解 TCP/IP协议

总结 OSI中的层 功能 TCP/IP协议族 应用层 文件传输,电子邮件,文件服务,虚拟终端 TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet 等等 表示层 数据格式化,代码转换,数据加密 没有协议 会话层 解除或建立与别的接点的联系 没有协议 传输层 提供端对端的接口 TCP,UDP 网络层 为数据包选择路由 IP,ICMP,OSPF,EIGRP,IGMP 数据链路层 传输有地址的帧以及错误检测功能 SLIP,CSLIP,PPP,MTU 物理层 以二进制数据形式在物理媒体上

详解TCP连接的“三次握手”与“四次挥手”(下)

上文链接: 详解TCP连接的"三次握手"与"四次挥手"(上) 四.TCP的四次挥手(Four-Way Wavehand) 0.前言 对于"三次握手"我们耳熟能详,因为其相对的简单.但是,我们却不常听见"四次挥手",就算听过也未必能详细地说明白它的具体过程.下面就为大家详尽,直观,完整地介绍"四次挥手"的过程. 1."四次挥手"的详解 所谓的四次挥手即TCP连接的释放(解除).连接的释放必

详解fragment(一):从源代码看fragment的生命周期

前面讲了那么多xml,我们缓一下,现在讲从代码角度来看fragment的创建. 我们通常会在FragmentActivity中通过如下方法: getSupportFragmentManager().beginTransaction().replace(R.id.content, fragment, tag).commit(); getSupportFragmentManager().beginTransaction().add(R.id.content, fragment, tag).commi

TCP超时与重传机制

TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制.其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号.  这里比较重要的是重传超时时间,怎样设置这个定时器的时间(RTO),从而保证对网络资源最小的浪费.因为若RTO太小,可能有些报文只是遇到拥堵或网络不好延迟较大而已,这样就会造成

Linux下套接字详解(十)---epoll模式下的IO多路复用服务器

epoll模型简介 epoll可是当前在Linux下开发大规模并发网络程序的热门人选,epoll 在Linux2.6内核中正式引入,和select相似,其实都I/O多路复用技术而已,并没有什么神秘的. 其实在Linux下设计并发网络程序,向来不缺少方法,比如典型的Apache模型(Process Per Connection,简称PPC),TPC(Thread PerConnection)模型,以及select模型和poll模型,那为何还要再引入Epoll这个东东呢?那还是有得说说的- 常用模型

[转帖]Linux文件系统详解

Linux文件系统详解 https://www.cnblogs.com/alantu2018/p/8461749.html 贼复杂.. 从操作系统的角度详解Linux文件系统层次.文件系统分类.文件系统的存储结构.不同存储介质的区别(RAM.ROM.Flash).存储节点inode.本文参考: http://blog.chinaunix.net/uid-8698570-id-1763151.html http://www.iteye.com/topic/816268 http://soft.ch

[转帖]ps 命令详解

ps 命令详解 https://www.jianshu.com/p/cba22cce2f97 ps 概述 Linux中的ps命令是Process Status的缩写.ps命令用来列出系统中当前运行的那些进程.ps命令列出的是当前那些进程的快照,就是执行ps命令的那个时刻的那些进程,如果想要动态的显示进程信息,就可以使用top命令. linux上进程有5种状态: 运行(正在运行或在运行队列中等待) 中断(休眠中, 受阻, 在等待某个条件的形成或接受到信号) 不可中断(收到信号不唤醒和不可运行, 进

[转帖]iostat 命令详解

iostat 命令详解 https://www.jianshu.com/p/5fed8be1b6e8 概述 iostat 主要用于输出磁盘IO 和 CPU的统计信息. iostat属于sysstat软件包.可以用yum install sysstat 直接安装. iostat 用法 用法:iostat [选项] [<时间间隔>] [<次数>] 如下图: iostat 用法 命令参数: -c: 显示CPU使用情况-d: 显示磁盘使用情况-N: 显示磁盘阵列(LVM) 信息-n: 显示

[转帖]pidstat 命令详解

pidstat 命令详解 https://www.jianshu.com/p/3991c0dba094 pidstat -r -u -d -p 各种参数非常好用. pidstat 概述 pidstat是sysstat工具的一个命令,用于监控全部或指定进程的cpu.内存.线程.设备IO等系统资源的占用情况.pidstat首次运行时显示自系统启动开始的各项统计信息,之后运行pidstat将显示自上次运行该命令以后的统计信息.用户可以通过指定统计的次数和时间来获得所需的统计信息. pidstat 安装