asp网站开发工具,wordpress建的大型网站,最好的网站模板网站,表格在网站后台是居中可到前台为什么不居中一、总述
TCP#xff0c;Transmission Control Protocol#xff0c;是一个面向连接、基于流式传输的可靠传输协议#xff0c;考虑到的内容很多#xff0c;比如数据包的丢失、损坏、分片和乱序等#xff0c;TCP协议通过多种不同的机制来实现可靠传输。今天#xff0c;重点…一、总述
TCPTransmission Control Protocol是一个面向连接、基于流式传输的可靠传输协议考虑到的内容很多比如数据包的丢失、损坏、分片和乱序等TCP协议通过多种不同的机制来实现可靠传输。今天重点分析重传机制、滑动窗口以及拥塞控制。
二、重传机制
在三握四挥的过程中服务器和客户端之间就通过带有不同标志位的TCP报文来通知或判断对端或本地是否成功建立、断开连接。
接收主机在接收到数据之后往往都会返回一个应答消息网络错综复杂面对随时可能发生的数据丢失问题TCP使用重传机制解决。常见的重传机制有以下四种
超时重传快速重传SACKD_SACK
(一) 超时重传
超时重传顾名思义在发送数据时会设定一个定时器当超过指定的时间过后没有收到对端的ACK确认应答报文就会重写发送该数据。而这又可以分为两种情况
数据包丢失ACK确认应答丢失
在了解如何设置超时时间之前先来看看什么是RTTRound-Trip Time往返时延。 RTT往返时延数据从一端到另一端。其中往返这个词是表明了什么范围是所需的时间。
知道了RTT在来看点相关的RTORetransmission Timeout直译“超时重传时间”。这个时间的设置毫无疑问关系到我们重传机制的效率高低看以下两种情况
RTORTT重发慢没有效率RTORTT包可能还没到就开始重发重发出去的包数量多了网络无疑会拥塞超时的包越来越多恶性循环。
那么结论显而易见——RTO的值应该略大于RTT。
很容易想到的是报文往返的RTT值会是经常变化的所以RTO也应该是一个动态变化的值。在Linux中通常会采样RTT的值然后加权算平均不详细谈了
而在超时时TCP的策略是超时间隔加倍。
(二) 快速重传
Fast Retransmit快速重传不以时间为驱动而以数据驱动重传。 在上图中Seq2一直没有成功被接收方收到当发送端收到三个Ack2的确认就会在定时器过期之前重传丢失的Seq2。
不过发送方并不知道Ack2是谁传回来的那么是重传Seq2还是把之前的所有包都重传呢根据TCP实现的不同上述两种情况都是可能的。
(三) SACK
SACK是指Selective Acknowledgment选择性确认这种方式通过在TCP头部选项字段添加一个SACK把缓存的地图发送给发送方这样发送方就知道哪些数据需要重传了。 如果要支持SACK双方都要支持在Linux下通过net.ipv4.tcp_sack这个参数打开Linux2.4后默认打开。
(四) Duplicate SACK
D_SACK主要使用SACK来通知发送方有哪些数据被重复接收了下面通过两个例子来说明这个Duplicate到底有什么妙用。
ACK丢包 发送端通过ACK和SACK就可以明确是发出去的包丢了还是接收方返回的ACK确认报文丢了。
网络延时
在判定网络延迟时Duplicate的含义才更加明显地体现了出来即复制的、完全一样的。 如上图中提及在经历了网络延迟和三次相同ACK触发快速重传后网络延迟的包终于送达此时返回ACK3000SACK1000~1500注意之前的SACK范围总是大于ACK就知道了这个SACK是D_SACK是重复的包。
三、滑动窗口流量控制
(一) 滑动窗口
滑动窗口Sliding Window是一种流量控制机制同时也是一种保持通信效率的技术。已知的是每当有一个数据包发出发送端总盼望得到一个ACK确认那么要是在得到ACK之前不做任何动作效率的高低明显可见。
为此TCP引入了窗口的概念通过指定窗口大小数据最大值来进行无需等待确认应答的通信。
在实际实现时是由操作系统开辟一个缓存空间。在发送方得到确认应答前已发送的数据都会保存在缓冲区如果按期收到确认应答此时数据就可以从缓冲区清除。
如此一来有了累计确认或累计应答模式 那么引申出一个问题——窗口的大小由哪一方决定
TCP报头中有一个16位的字段窗口尺寸Window这个字段是由接收方通知发送方自己还有多少缓冲区可以用来接收数据。以免接收方无法正常接收到数据。
发送方滑动窗口分为4个部分 它的工作方式很容易想到ACK确认一部分可用窗口就扩大一部分当发送窗口满了在接收ACK之前就不再发送数据。
接收方滑动窗口分为3个部分 值得注意的是两个窗口的大小是约等于的关系而不是一模一样。因为滑动窗口不是一成不变的。如果接收方的读取速度有了很大提升会通过TCP报文通知发送方新的窗口大小。
(二) 窗口关闭问题
TCP中通过接收方指定窗口尺寸来进行流量控制。在通信中当接收方窗口被填满会向发送方说明窗口尺寸位0等处理好数据后才会又通告一个窗口非0的ACK报文。不过要是这个非0报文丢失就会陷入死锁的状态双方同时等待。
窗口探测报文
为了解决这个问题TCP为每个连接设置了一个持续计时器只要收到0窗口通告就启动计时器。当计时器超时就会发送窗口探测报文这个报文的用意显而易见。窗口探测的次数一般是3次。
(三) 糊涂窗口问题
糊涂窗口是指接收方在处理数据时的速度过慢导致窗口的尺寸不断变小的现象。实际上就是两个动作让这个现象出现
接收方通告小窗口发送方发送小数据
想要避免这种现象解决上述两个问题就好了。
在接收方当窗口小于min(MSS, 缓存空间/2)就会告知对方0窗口到后面合适的时机再通知非0窗口。在发送方使用Nagle算法进行延时处理要等到发送窗口大小MSS或者接收到ACK确认报文才会停止囤积数据。这个算法是默认打开的在使用telnet和ssh等交互性比较强的程序时通过TCP_NODELAY来关闭。
四、拥塞控制
(一) 什么是拥塞
上文的流量控制是避免发送方的数据填满接收方的缓存而拥塞控制则是为了避免在整个网络环境处于拥堵时还继续发送大量数据包的手段可能导致数据包时延、丢失等重传也会加重拥塞。
那么很明显拥塞控制是在发送端实现的。为了调节发送数据的量定义了“拥塞窗口”的概念。
(二) 什么是拥塞窗口
拥塞窗口是一个由发送方维护的状态变量根据网络的拥塞程度动态变化。前面的发送窗口和接收窗口在有了拥塞窗口的加入以后是这样的关系
发送min(拥塞接收)
拥塞窗口的动态变化也很简答有拥塞就变小没拥塞就变大。
(三) 如何判断拥塞
只要发送方没在规定的时间内接收到ACK确认报文发生超时重传就会认为网络出现了拥塞。
(四) 拥塞控制算法——慢启动
TCP在刚建立完连接后会经历慢启动逐步提高发送数据包的数量。规则是
发送方每收一个ACK拥塞窗口cwnd的大小就增加1。
所以这个增长是指数性的。
那什么时候是个头呢——当达到慢启动门限(slow start threshold)后就会使用拥塞避免算法。
(五) 拥塞避免算法
慢启动门限ssthresh一般的大小为65535字节在进入拥塞避免算法后窗口增长的规则是
每当收到一个ACKcwnd增加1/cwnd。
如此一来线性增长。
在此后一直增长网络就会进入拥塞的状态出现丢包和丢包重传触发了重传也就进入了拥塞发生算法。
(六) 拥塞发生
在上文提到过重传的机制也有两种1. 超时重传2. 快速重传。接下来进行分述
超时重传的拥塞发生算法
ssthresh设置为cwnd/2cwnd重置为1然后重新开始慢启动。不过这种方式会突然减少数据流可能网络卡顿就像是急刹车。
快速重传的拥塞发生算法
在快速重传时接收方发送三次前一个包的ACK通知发送端重传大部分没丢只丢了小部分。
cwndcwnd/2ssthreshcwnd然后进入快速恢复算法。
(七) 快速恢复
快速重传一般和快速恢复算法同时使用这种情况会判断网络情况并不是特别严峻反映也不会像RTO那样强烈。
快速恢复算法
cwndssthresh3重传丢失的数据包如果再收到重复的ACKcwnd1如果收到新ACK说明D_SACK时的数据全部收到恢复过程结束cwndssthresh恢复到之前二点拥塞避免状态。
本文作为笔记图片来源
30 张图解 面试必问的 TCP 重传、滑动窗口、流量控制、拥塞控制_面试回答 tcp流量控制-CSDN博客https://blog.csdn.net/qq_34827674/article/details/105606205
