码迷,mamicode.com
首页 > 其他好文 > 详细

【协议森林】图说TCP之滑动窗口和拥塞窗口

时间:2020-11-23 12:27:08      阅读:6      评论:0      收藏:0      [点我收藏+]

标签:连接   避免   简单   coding   res   协议   探测   初始化   分时   

我们大部分业务都建立在TCP之上,而且都经过框架层层的封装,让人很难看清其中的奥妙。但在和外部机构(如银行)交互的过程中,有很多采用的是自研的基于TCP的协议。此时无法依赖框架,我们就只能自己去编写基于TCP的代码,如果充分了解TCP的种种特性,和他们对接起来就会事半功倍。相信大家在开发TCP代码的过程中,也肯定了解了粘包、长短连接这些概念。粘包和TCP窗口有关、长短连接性能优劣和TCP传输策略有关。这篇文章着重介绍TCP窗口。

TCP发送窗口由slide_window(滑动窗口)、congestion_window(拥塞窗口)两者决定,代码如下(4.4BSD-Lite2):
技术图片

滑动窗口

上面的snd_wnd、snd_una、snd_nxt三个字段组成了滑动窗口。 如下图所示
技术图片

发送窗口

发送端窗口随时间滑动图(不考虑重传)例如下所示:
技术图片
图2 发送窗口随时间滑动图
(1)我们一共需要发送900字节数据。可发送数据为1-500字节,尚未发送数据。假设首先发送400字节的数据。
(2)发送了400字节后,对端返回一个ack表示收到200序号之内的数据且窗口通告为500。于是如图示,窗口向前滑动了200字节。当前已发送未确认字节序号为200-400,可发送字节序号为401-700,假设在此尚未发送数据。
(3)对端返回一个ack表示收到400序号内的数据且窗口通告为400。于是如图示,窗口向前滑动了200字节。已确认数据序号为1-400,可发送数据为401-800。

接收窗口

snd_wnd此字段主要由接收端的窗口通告决定,接收端窗口通告由当前接收端剩余多少空闲的剩余缓存决定。如下图所示:
技术图片

图3 接收窗口通告

(1)发送端:写入2KB的数据[seq=0]。
(2)接收端:收到数据,初始化接收端缓冲区4K,写入后还剩2K,于是通告ack[seq=2048,win=2048]。
(3)发送端:接收到窗口通告为2048,于是最多只能写入2K的数据,将2K数据写入[seq=2048]。
(4)接收端:应用层尚未消费缓冲区。接收到2K数据后,缓冲区满。于是通告窗口为0,返回ack[seq=4096,win=0]。
(5)发送端:由于发送窗口为0,不能发送任何数据。此时发送端就需要定时的发送0字节的数据去探测接收端窗口。所需的定时器即为持续定时器(TCPT_PERSIST)。
(6)发送端:发送0字节的探测数据。
(7)接收端:缓冲区满,窗口通告为0,ack[seq=4096,win=0]。
(8)发送端:继续发送0字节的探测数据。
(9)接收端:缓冲区被应用层消费了2K,缓冲区可用字节为2K,通告窗口为2048,ack[seq=4096,win=2048]。
(10)发送端:继续写入1K的数据。

拥塞窗口

TCP用拥塞窗口(cwnd)来进行拥塞控制,主要利用了慢启动、拥塞避免、快速重传和快速恢复这四个算法。

慢启动和拥塞避免

拥塞避免算法和慢启动算法是两个目的不同、独立的算法。慢启动的目的是:防止一开始速率过快,导致耗尽中间路由器存储空间,从而严重降低TCP连接的吞吐量。拥塞避免的目的是:当拥塞发生时,降低网络的传输速率。这可以通过调用慢启动的动作来降低网络的传输速率。所以在实际中这两个算法通常在一起实现。

下述代码描述的是慢启动的过程(4.4BSD-Lite2)。
技术图片
其将win置为现有窗口的大小,同时慢启动门限tp->snd_ssthresh设置为现有窗口大小的一半。snd_cwnd(拥塞窗口)被设定为只能容纳一个报文t_maxseg),这样就强迫TCP执行慢启动。之后拥塞窗口会先以指数形式增长,达到慢启动门限snd_ssthressh之后,再线性增长。

线性增长的过程即是拥塞避免算法。

此过程如以下代码注释所示(4.4BSD-Lite2):
技术图片
慢启动图例:
技术图片
图中Cwnd指数增长的阶段,即从1到ssthresh时间段是过程是慢启动。
图中Cwnd线性增长的阶段,即从ssthresh到max的时间段是拥塞避免的过程。

值得注意的是,TCP连接刚建立时刻也会有慢启动的过程。如果用的是短连接(即发送一个请求之后即抛弃此连接)且发送数据较少的话,大部分时间都耗在了慢启动上面,并没有充分的利用带宽。再加上建立连接所需要三次握手的消耗,导致短连接的效率要远低于长连接。

快速重传和快速恢复

  • 快速重传和快速恢复算法各自独立,但一般都在一起实现。
  • 快速重传:在接收到相同ACK后,推断出丢失报文段起始序号,然后立即重传此报文
    快速恢复:在快速重传的基础上,如果发生了快速重传,则执行拥塞避免算法而非慢启动。
    快速重传和快速恢复图例:
    技术图片
    图5 快速重传和快速恢复
    从上图中我们可以看到,快速恢复的时候tcp窗口仅仅降低到ssthresh而后线性增加,即只进行了拥塞避免算法。

TCP粘包

经过上述讨论,可知TCP窗口的大小取决于当前的网络状况、对端的缓冲大小等等因素,TCP将这些都从底层屏蔽。开发者无法从应用层获取这些信息。这就意味着,当你在接收TCP数据流的时候无法知道当前接收了有多少数据流,数据可能在任意一个比特位(seq)上。这就是所谓的"粘包"问题。开发者必须小心的组织帧格式来解决"粘包"。

推荐阅读:

精心整理 | 2017下半年文章目录
分布式之消息队列复习精讲(下)
面试之链表问题集锦(下)
数学分析告诉我们什么?
C++中的类型转换
Stack Overflow 10个关于程序员有趣的调查

专注服务器后台技术栈知识总结分享

欢迎关注交流共同进步

技术图片

码农有道 coding

码农有道,为您提供通俗易懂的技术文章,让技术变的更简单!

【协议森林】图说TCP之滑动窗口和拥塞窗口

标签:连接   避免   简单   coding   res   协议   探测   初始化   分时   

原文地址:https://blog.51cto.com/15006953/2552049

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!