一.RACK概述 RACK(Recent ACKnowledgment)是一种新的基于时间的丢包探测算法,RACK的目的是取代传统的基于dupthresh门限的各种快速重传及其变种.前面介绍的各种基于dup ACK的快速重传算法及其变种通过修改dupthresh门限等手段,有些可以迅速的探测到丢包,有些可以精确的探测丢包,但是没有能同时达到迅速和精确两个目标的算法. RACK基本思想:如果发送端收到的确认包中的SACK选项确认收到了一个数据包,那么在这个数据包之前发送的数据包要么是在传输过程中发

一.概述 这里主要简单分析一个丢包重传并恢复的场景,通过不同的设置让这个相同的场景分别触发RACK重传和前向重传,通过对比说明以下问题: Forward Retransmit可以产生只有重传标记的数据包,也可以产生同时具有重传标记和SACK标记的数据包,注意这里说的这些数据包是没有Lost标记的,这是前向重传与之前介绍的快速重传及其变种的差异,进而会对in_flight的统计产生影响. Recovery状态,FACK会利用一个dup ACK来前向标记丢失的数据包. RACK可以利用重传在时间域来

一.概述 这篇文章介绍一下TCP从Recovery状态恢复到Open状态的时候cwnd的更新.我们在tcp重传部分的文章中曾经介绍过虚假重传的概念,Linux在探测到虚假重传的时候就会执行拥塞撤销操作.所谓的拥塞撤销是指撤销虚假的快速重传或者RTO超时重传对拥塞窗口的影响.有多种方法可能会触发拥塞撤销如前面介绍的DSACK和FRTO以及后面要介绍的Eifel算法以及本文介绍的SACK关闭场景下的拥塞撤销,本文先介绍一种SACK关闭场景下的拥塞撤销.首先在介绍几个新的linux状态变量 undo_

) return;    delta = ssthresh - in_flight;     prr_delivered += newly_acked_sacked; if (delta < 0) {  //注意下面的除法要向下取整 sndcnt = (ssthresh * prr_delivered + prior_cwnd - 1)/prior_cwnd - prr_out } else if (ack number新确认了之前重传的数据且RACK没有标记重传报文丢失) { sndcnt =

一.概述 forward retransmit相关的内容在RFC6675中有描述,可以参考RFC6675 section 4中NextSeg ()的定义.forward retransmit中文名可以叫做前向重传,我这里简单说一下linux实现上的前向重传 在快速重传(包括快速重传的各种变种)到达Recovery point之前,都会尝试重传标记为lost的数据包,当把标记为lost的数据包重传完毕后,如果同时满足下面几个条件: 1.当前拥塞控制处于Recovery状态,且在尝试重传数据包的时候

一.TCP选项概述 在前面介绍TCP头的时候,我们说过tcp基本头下面可以带有tcp选项,其中有些选项只能在连接过程中随着SYN包发送,有些可以延后.下表汇总了一些tcp选项 其中我标记为红色的部分是常见的TCP选项,我们仅针对这些红色的TCP选项进行介绍(主要是非红色的我也不太了解~~~),另外RFC1323已经被RFC7323取代,这里给出的是TCP选项原始定义的RFC 按照RFC793规定,一个TCP选项只需要单字节对齐,但是在实现上一般是两字节对齐或者会通过NOP选项实现四字节对齐,例如

一.概述 在RFC2861中,区分了TCP连接数据传输的三种状态   After sending a data segment:       If tcpnow - T_last >= RTO           (The sender has been idle.)           ssthresh =  max(ssthresh, 3*cwnd/4)           For i=1  To (tcpnow - T_last)/RTO               win =  min(

WeTest 导读 云真机已经支持手机端的画面投影.云真机实时操作,对延迟的要求比远程视频对话的要求更高(100ms以内).在无线网络下,如何更实时.更可靠的传输视频流就成了一个挑战.通过websocket.RTMP.UDP的比较,最后选择了可靠的UDP协议KCP来进行实时音视频的传输. 1 简介 KCP是一个快速可靠协议,能以比 TCP浪费10%-20%的带宽的代价,换取平均延迟降低 30%-40%,且最大延迟降低三倍的传输效果.纯算法实现,并不负责底层协议(如UDP)的收发,需要使用者自己定

开放系统互联(OSI)模型 是由国际标准化组织(ISO)于1984年提出的一种标准参考模型,是一种关于由不同供应商提供的不同设备和应用软件之间的网络通信的概念性框架结构.它被公认为是计算机通信和 internet 网络通信的一种基本结构模型. OSI 七层参考模型中的ISO协议(ISO Protocols) 当今使用的大多数网络通信协议都是基于 OSI 模型结构.OSI 模型将通信处理过程定义为七层,并将网络计算机间的移动信息任务划分为七个更小的.更易管理的任务组.各个任务或任务组被分配到 IS

一.介绍 FACK的全称是forward acknowledgement,FACK通过记录SACK块中系列号最大(forward-most)的SACK块来推测丢包信息,在linux中使用fackets_out这个状态变量来记录FACK信息.我们之前介绍SACK重传时候说过在SACK下需要3个dup ACK来触发快速重传(3个为默认值),而SACK下的dup ACK的定义与传统的非SACK下定义又略有不同(详细请参考前面的文章和示例).当使能FACK的时候,实际上我们可以通过一个SACK块信息来推

我们之前介绍SACK选项的时候说过,SACK可以把接收端系列号空间的洞反映给发送端,因此发送端可以更充分的理解接收端的情况,而进行更好的重传恢复过程.这种过程有时候也叫做advanced loss recovery. 一.数据接收端SACK行为 我们通过一个wireshark示例来说明接收端的SACK行为:   如上图,为了方便在info列中查看SACK信息,我把info列中TSopt的信息隐藏了,同时把源地址列和目的地址列一起隐藏了.client依次发送P1(1-6).P2(25-30).P3

重传机制     慢启动相关的几个状态说明该     SACK机制     窗口在TCP传输机制中的作用

TCP拥塞控制算法之NewReno和SACK 2018年05月23日 19:10:03 吃吃爱学习 阅读数:1446    版权声明:程序媛吃吃的博客 https://blog.csdn.net/m0_38068229/article/details/80417503 一.TCP Reno拥塞控制算法回顾 二.基于TCP Reno拥塞控制算法的改进 改进原因分析 TCP Reno 提出的快速恢复算法提高了丢失报文后的吞吐量和顽健性,但是: 仅考虑了每次拥塞发生时只丢失一个报文的情形. 实际网络中

TCP的实现中,SACK和DSACK是比较重要的一部分. SACK和DSACK的处理部分由Ilpo Järvinen (ilpo.jarvinen@helsinki.fi) 维护. tcp_ack()处理接收到的带有ACK标志的数据段时,如果此ACK处于慢速路径,且此ACK的记分牌不为空,则调用 tcp_sacktag_write_queue()来根据SACK选项标记发送队列中skb的记分牌状态. 笔者主要分析18和37这两个版本的实现. 相对而言,18版本的逻辑清晰,但效率较低:37版本的逻辑

主要内容:TCP定时器概述,超时重传定时器.ER延迟定时器.PTO定时器的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd Q:一条TCP连接会使用多少个定时器呢? A:目前的答案是9个: 超时重传定时器,持续定时器,ER延迟定时器,PTO定时器,ACK延迟定时器, SYNACK定时器,保活定时器,FIN_WAIT2定时器,TIME_WAIT定时器. 数据结构 几种定时器的标识: #define ICSK_TIME_RETRANS 1 /* R

上篇文章中我们主要说明如何skip到一个SACK块对应的开始段,如何walk这个SACK块包含的段,而没有涉及到 如何标志一个段的记分牌.37版本把给一个段打标志的内容独立出来,这就是tcp_sacktag_one(). 本文主要内容:tcp_sacktag_one(),给一个段打上标志. Author:zhangskd @ csdn 标志一个包 tcp_sacktag_walk()用于遍历块中的数据包,最终会调用tcp_sacktag_one()来标志一个数据包的记分牌, 即TCP_SKB_C

18版本对于每个SACK块,都是从重传队列头开始遍历.37版本则可以选择性的遍历重传队列的某一部分,忽略 SACK块间的间隙.或者已经cache过的部分.这主要是通过tcp_sacktag_skip()和tcp_sacktag_walk()完成的. tcp_sacktag_skip()可以直接找到包含某个序号的skb,通常用于定位SACK块的开头. tcp_sacktag_walk()则遍历两个序号之间的skb,通常用于遍历一个SACK块. 本文主要内容:SACK的遍历函数tcp_sacktag

和18版本不同,37版本把DSACK的检测部分独立出来,可读性更好. 37版本在DSACK的处理中也做了一些优化,对DSACK的两种情况分别进行处理. 本文主要内容:DSACK的检测.DSACK的处理. Author:zhangskd @ csdn dsack检测 根据RFC 2883,DSACK的处理流程如下: 1)look at the first SACK block : -If the first SACK block is covered by the Cumulative Ackno

和18版本相比,37版本的SACK和DSACK的实现做了很多改进,最明显的就是需要遍历的次数少了, 减少了CPU的消耗.37版的性能提升了,代码有大幅度的改动,逻辑也更加复杂了. 本文主要内容:37版tcp_sacktag_write_queue()的实现,也即37版SACK和DSACK的实现. Author:zhangskd @ csdn 数据结构 /* This defines a selective acknowledgement block. */ struct tcp_sack_blo

在tcp_clean_rtx_queue()中,并非对每个ACK都进行时延采样.是否进行时延采样,跟这个ACK是否为 重复的ACK.这个ACK是否确认了重传包,以及是否使用时间戳选项都有关系. 本文主要内容:tcp_clean_rtx_queue()的一些细节,时延采样的条件. 内核版本:3.2.12 Author:zhangskd @ csdn 记分牌 TCP_SKB_CB(skb)->sacked称为skb的记分牌,用于跟踪skb的状态. 以下是skb记分牌可能的取值: #define TC