石家庄seo网站排名,网站制作公司哪家专业,wordpress 目录书,渠道游戏官网上文浅谈TCP#xff08;1#xff09;#xff1a;状态机与重传机制介绍了TCP的状态机与重传机制。本文介绍流量控制#xff08;Flow Control#xff0c;简称流控#xff09;与拥塞控制#xff08;Congestion Control#xff09;。TCP依此保障网络的QOS#xff08;Quali…上文浅谈TCP1状态机与重传机制介绍了TCP的状态机与重传机制。本文介绍流量控制Flow Control简称流控与拥塞控制Congestion Control。TCP依此保障网络的QOSQuality of Service。
TCP的流量控制
RTT算法
根据前文对TCP超时重传机制的介绍我们知道Timeout的设置对于重传非常重要 设长了重发就慢丢了老半天才重发没有效率性能差。 设短了会导致可能并没有丢就重发。于是重发的就快会增加网络拥塞导致更多的超时更多的超时导致更多的重发。
而且这个超时时间在不同的网络环境下不同必须动态设置。为此TCP引入了RTTRound Trip Time环回时间一个数据包从发出去到回来的时间。这样发送端就大约知道正常传输需要多少时间据此计算RTORetransmission TimeOut超时重传时间。听起来似乎很简单在发送方发包时记下t0收到接收方的Ack时记一个t1于是RTT t1 – t0。然而这只是一个采样不能代表网络环境的普遍情况。
经典算法
RFC793 中定义了一个经典算法 首先采样RTT记下最近几次的RTT值。 然后使用加权移动平均算法Weighted Moving Average Method做平滑计算SRTTSmoothed RTT 1 SRTT ( α * SRTT ) ((1- α) * RTT) (通常取0.8≤α≤0.9α越大收敛速度越快) 最后计算RTO RTO min [ UBOUND, max [ LBOUND, (β * SRTT) ] ] (通常取1.3≤β≤2.0)
Karn / Partridge 算法
经典算法描述了RTO计算的基本思路但还有一个重要问题RTT的采样取“第一次发Seq收Ack的时间”还是“重传Seq收Ack的时间”
如图 情况a中RTT的采样取“第一次发Seq收Ack的时间”。假设第一次发的Seq彻底丢包了则采样到的时间多算了“从第一次发到重传的间隔”。 情况b中RTT的采样取“重传Seq收Ack的时间”。假设是Ack传输的慢导致恰好刚重传就收到了接收方之前发出的Ack则采样到的时间少算了“从第一次发到重传的间隔”。
问题的本质是发送方无法区分收到的Ack对应第一次发的Seq还是重传的Seq进入网络就都一样了。针对该问题Karn / Partridge算法选择回避重传的问题忽略重传的样本RTT的采样只取未产生重传的样本。
简单的忽略重传样本也有问题假设当前的RTO很小突然发生网络抖动延时剧增导致要重传所有的包由于忽略重传样本RTO不会被更新于是继续重传使网络更加拥堵拥堵导致更多的重传恶性循环直至网络瘫痪。Karn / Partridge算法用了一个取巧的办法只要一发生重传就将现有的RTO值翻倍指数回退策略待网络恢复后再仿照经典算法逐渐平滑以降低RTO。
该算法已经做到可用然而网络抖动对性能的影响比较大。
Jacobson / Karels 算法
前面两种算法均使用加权移动平均算法做平滑这种方法的最大问题是很难发现RTT值上的较大波动因为被平滑掉了1 - a比较小即最新RTT的权重小。针对该问题Jacobson / Karels算法引入了最新采样的RTT值和平滑过的SRTT值的差距做因子即DevRTTDeviation RTTRTT的偏离度同时考虑SRTT带来的惯性和DevRTT带来的波动 1 2 3 SRTT SRTT α(RTT – SRTT) —— 计算SRTT DevRTT (1-β)*DevRTT β*(|RTT-SRTT|) —— 计算SRTT和最新RTT的差距加权移动平均 RTO µ * SRTT ∂ *DevRTT —— 同时考虑SRTT惯性与DevRTT波动
Linux 2.6采用该算法计算RTO默认取α 0.125, β 0.25, μ 1, ∂ 4玄学调参你懂的。
TCP滑动窗口
TCP使用滑动窗口Sliding Window做流量控制与乱序重排。乱序重排在TCP的重传机制中已经介绍下面介绍流量控制。
TCP头里有一个字段叫Window或Advertised Window用于接收方通知发送方自己还有多少缓冲区可以接收数据。发送方根据接收方的处理能力来发送数据不会导致接收方处理不过来是谓流量控制。暂且把Advertised Window当做滑动窗口更容易理解滑动窗口如何完成流量控制后面介绍拥塞控制时再说明二者的区别。
观察TCP协议的发送缓冲区和接收缓冲区 假设位置序号从左向右增长常见的读、写缓冲区设计解释一下 发送方LastByteAcked指向收到的连续最大Ack的位置LastByteSent指向已发送的最后一个字节的位置LastByteWritten指向上层应用已写完的最后一个字节的位置。 接收方LastByteRead指向上层应用已读完的最后一个字节的位置NextByteExpected指向收到的连续最大Seq的位置LastByteRcvd指向已收到的最后一个字节的位置。可以看到NextByteExpected与LastByteRcvd中间有些Seq还没有到达对应空白区。
据此在接收方计算AdvertisedWindow在发送方计算EffectiveWindow 接收方在Ack中记录自己的AdvertisedWindow MaxRcvBuffer – (LastByteRcvd - LastByteRead)随Ack回复到发送方。 发送方根据Ack中的AdvertisedWindow值需保证LastByteSent - LastByteAcked ≤ AdvertisedWindow则窗口内剩余可发送的数据大小EffectiveWindow AdvertisedWindow - (LastByteSent - LastByteAcked)以保证接收方可以处理。
AdvertisedWindow与EffectiveWindow
AdvertisedWindow衡量接收方还能接收的数据量发送方要根据AdvertisedWindow决定接下来发送的数据量上限即EffectiveWindow可能为0。
ADVERTISEDWINDOW的计算
由于乱序问题的存在LastByteRcvd可能指向Seq(LastByteSent)而Seq(LastByteAcked 1)至Seq(LastByteSent - 1)都还在路上即将到达接收方最好的情况是不丢包丢包后会重传则LastByteRcvd之后、接收缓冲区边界之前的空间就是发送方下一次发送数据的长度上限重传不属于下一次发送因此AdvertisedWindow MaxRcvBuffer – (LastByteRcvd - LastByteRead)。
EFFECTIVEWINDOW的计算
LastByteRcvd还可能指向Seq(LastByteAcked)一个新包都没有收到显然AdvertisedWindow的公式不变而Seq(LastByteAcked 1)至Seq(LastByteSent)都还在路上未来将到达接收方进入接收缓冲区则“还在路上的Seq(LastByteAcked 1)至Seq(LastByteSent)”不应超过接收缓冲区的剩余空间AdvertisedWindow目前等于MaxRcvBuffer这要求的是上一次发送满足LastByteSent - LastByteAcked ≤ AdvertisedWindow那么LastByteSent之后、接收缓冲区剩余空间边界之前的空间就是发送方窗口内剩余可发送数据的长度上限因此EffectiveWindow AdvertisedWindow - (LastByteSent - LastByteAcked)。 当然EffectiveWindow最小取0。 示例1
以下是一个发送缓冲区的滑动窗口 上图分为4个部分 #1是已发送已确认的数据即LastByteAcked之前的区域。 #2是已发送未确认的数据即LastByteAcked与LastByteSent之间的区域大小不超过AdvertisedWindow。 #3是窗口内未发送的数据即LastByteSent与窗口右界之间的区域大小等于EffectiveWindow可能为0。 #4是窗口外未发送的数据即窗口右界与LastByteWritten之间的区域。
其中#2 #3组成了滑动窗口总大小不超过AdvertisedWindow二者比例受到接收方的处理速度与网络情况的影响如果丢包严重或处理速度慢于发送速度则#2:#3会越来越大。
示例2
以下是一个AdvertisedWindow的调整过程EffectiveWindow随之变化 Zero Window 理解有问题不要求掌握。 上图我们可以看到一个处理缓慢的Server接收端是怎么把Client发送端的发送窗口size给降成0的。对于接收方来说此时接收缓冲区确实已经满了因此令发送方的发送窗口size降为0以暂时禁止发送是合理的。那么等接收方的接收缓冲区再空出来怎么通知发送方新的window size呢
针对这个问题为TCP设计了ZWP技术Zero Window Probe零窗通告发送方在窗口变成0后会发ZWP的包给接收方让接收方来Ack他的Window尺寸ZWP的重传也遵循指数回退策略默认重试3次如果3次后window size还是0则认为接收方出现异常发RST重置连接部分文章写的是重试到window size正常。
注意只要有等待的地方都可能出现DDoS攻击Zero Window也不例外。一些攻击者会在和服务端建好连接发完GET请求后就把Window设置为0于是服务端就只能等待进行ZWP然后攻击者再大量并发发送ZWP把服务器端的资源耗尽。客户端等待怎么耗服务端
TCP的拥塞控制 通信中的拥塞指 到达通信子网中某一部分的分组数量过多使得该部分网络来不及处理以致引起这部分乃至整个网络性能下降的现象严重时甚至会导致网络通信业务陷入停顿即出现死锁。 为什么要进行拥塞控制假设网络已经出现拥塞如果不处理拥塞那么延时增加出现更多丢包触发发送方重传数据加剧拥塞情况继续恶性循环直至网络瘫痪。可知拥塞控制与流量控制的适应场景和目的均不同。
拥塞发生前可避免流量过快增长拖垮网络拥塞发生时唯一的选择就是降低流量。主要使用4种算法完成拥塞控制 慢启动 拥塞避免 拥塞发生 快速恢复
算法1、2适用于拥塞发生前算法3适用于拥塞发生时算法4适用于拥塞解决后相当于拥塞发生前。
rwnd与cwnd
在正式介绍上述算法之前先补充下rwndReceiver Window接收者窗口与cwndCongestion Window拥塞窗口的概念 rwnd是用于流量控制的窗口大小即上述流量控制中的AdvertisedWindow主要取决于接收方的处理速度由接收方通知发送方被动调整详细逻辑见上。 cwnd是用于拥塞处理的窗口大小取决于网络状况由发送方探查网络主动调整。
介绍流量控制时我们没有考虑cwnd认为发送方的滑动窗口最大即为rwnd。实际上需要同时考虑流量控制与拥塞处理则发送方窗口的大小不超过min{rwnd, cwnd}。下述4种拥塞控制算法只涉及对cwnd的调整同介绍流量控制时一样暂且不考虑rwnd假定滑动窗口最大为cwnd但读者应明确rwnd、cwnd与发送方窗口大小的关系。
4种拥塞控制算法
慢启动算法
慢启动算法Slow Start作用在拥塞产生之前对于刚刚加入网络的连接要一点一点的提速不要妄图一步到位。如下 连接刚建好初始化cwnd 1当然通常不会初始化为1太小表明可以传一个MSS大小的数据。 每收到一个ACKcwnd线性增长。 每经过一个RTTcwnd cwnd * 2指数增长主要增长来源。 还有一个ssthreshslow start threshold当cwnd ssthresh时就会进入拥塞避免算法见后。
因此如果网速很快的话Ack返回快RTT短那么这个慢启动就一点也不慢。下图说明了这个过程 拥塞避免算法
前面说过当cwnd ssthresh通常ssthresh 65535时就会进入拥塞避免算法Congestion Avoidance缓慢增长小心翼翼的找到最优值。如下 每收到一个Ackcwnd cwnd 1/cwnd显然cwnd 1时无增长。 每经过一个RTTcwnd线性增长主要增长来源。
慢启动算法主要呈指数增长粗犷型速度快“慢”是相对于一步到位而言的而拥塞避免算法主要呈线性增长精细型速度慢但更容易在不导致拥塞的情况下找到网络环境的cwnd最优值。
拥塞发生时的算法
慢启动与拥塞避免算法作用在拥塞发生前采取不同的策略增大cwnd如果已经发生拥塞则需要采取策略减小cwnd。那么TCP如何判断当前网络拥塞了呢很简单如果发送方发现有Seq发送失败表现为“丢包”就认为网络拥塞了。
丢包后有两种重传方式对应不同的网络情况也就对应着两种拥塞发生时的控制算法 超时重传。TCP认为这种情况太糟糕调整力度比较大 ssthresh cwnd /2 cwnd 1重新进入慢启动过程网络糟糕要慢慢调整 快速重传。TCP认为这种情况通常比RTO超时好一些主流实现TCP Reno的调整力度更柔和TCP Tahoe的实现和RTO超时一样暴躁 ssthresh cwnd /2 cwnd cwnd /2进入快速恢复算法网络没那么糟可以快速调整见下
可以看到不管是哪种重传方式ssthresh都会变成cwnd的一半仍然是指数回退待拥塞消失后再逐渐增长回到新的最优值总体上在最优值动态附近震荡。
回退后根据不同的网络情况可以选择不同的恢复算法。慢启动已经介绍过了下面介绍快速恢复算法。
快速恢复算法
如果触发了快速重传即发送方收到至少3次相同的Ack那么TCP认为网络情况不那么糟也就没必要提心吊胆的可以适当大胆的恢复。为此设计快速恢复算法Fast Recovery下面介绍TCP Reno中的实现。
回顾一下进入快速恢复之前cwnd和sshthresh已被更新 ssthresh cwnd /2 cwnd cwnd /2
然后进入快速恢复算法 cwnd ssthresh 3 * MSS 尝试一步到位 重传重复Ack对应的Seq 如果再收到该重复Ack则cwnd线性增长缓慢调整 如果收到了新Ack则cwnd ssthresh 然后就进入了拥塞避免的算法了为什么收到新Ack要降低sshthresh 可暂时忽略的内容 这种实现也有问题依赖于3个重复Ack。回忆上文讨论的“重传一个还是重传所有的问题”3个重复Ack并不代表只丢了一个数据包很有可能是丢了好多包。显然快速恢复算法选择“重传一个”而剩下的那些包只能等到RTO超时。于是超时一个窗口就减半一下多个超时会超成TCP的传输速度指数级下降同时超时重传不会触发快速恢复算法慢启动很容易加剧超时的情况进入恶性循环。 示例
下面看一个简单的图示感受拥塞控制过程中的cwnd变化 一个有趣的面试题 问 使用wget的时候通常刚开始速度慢一些然后逐渐上升到满速。可能是什么原因导致 猴子面试时遇到这个问题懵逼了几秒钟想到一个CDN pre load的原因面试官看我懵逼就提醒“可能跟tcp协议有关”瞬间明白考点 wget使用HTTP协议构建传输层使用TCP协议而TCP的拥塞控制会从慢启动开始逐渐试探增长到一个足够大又不至导致拥塞的速度。
接下来还可以补充CDN的原因但不是主要原因了 很多下载服务都使用了CDNCDN属于缓存一定也存在一些pre load策略显然运行一段时间缓存命中率才能上升到最高。 参考 TCP 的那些事儿下 网络基础3-传输层 原文地址 浅谈TCP2流量控制与拥塞控制
