福建建设中心网站,顺庆移动网站建设,网页交互设计报价,前沿的设计网站文章目录四、滑动窗口二、流量窗口三、拥塞控制四、滑动窗口
前面我们学习了 确认应答#xff0c;超时重传#xff0c;连接管理#xff0c;这些机制都为我们TCP的可靠性提供了保证#xff0c;当然在保证TCP的可靠性的同时#xff0c;传输效率也受到了一定的影响#xff… 文章目录四、滑动窗口二、流量窗口三、拥塞控制四、滑动窗口
前面我们学习了 确认应答超时重传连接管理这些机制都为我们TCP的可靠性提供了保证当然在保证TCP的可靠性的同时传输效率也受到了一定的影响我们的TCP也将尽可能的提高传输效率大家注意这里的提高传输效率实际上是尽量的降低效率的亏损无论我们如何提高都不可能比UDP这种不考虑可靠性的效率高我们要做的是尽量让TCP效率高一些。 对于我们基本的确认应答来言每次发一个数据后都需要收到一个ack后才发下一个数据。 滑动窗口的本质就是批量发送一组数据然后使用一份时间来等待多个ack这样就可以大大的提高性能。 窗口大小 不需要等待直接可以发送的数据最大的量。 我们在这里并不是等所有的ack到达后才继续往下发而是到一个ack就继续往下发一条操作系统内核为了维护这个滑动窗口需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉。窗口越大网络的吞吐率就越高。 比如这里我们等待的ack是1001-5000我们收到了2001这个ack证明2001之前的数据(1001-2000)已经确定了我们接下来就可以立即再发一条也就是5001-6000的数据此时意味着我们等待的ack的范围就是2001-6000了 上面的情况都是理想状态那如果出现了丢包了怎么办? 1. ack丢了 如果是ack丢了我们不做任何处理也没事为什么? 就需要我们弄清楚ack的含义是什么。 ack代表的是该序号之前的所有数据都确认到达了。 比如我们这里的1001的ack丢失了但是我们的2001ack顺利到达了2001到达的含义就是2001之前的所有数据都确认到达了(1-1000 和 1001-2000都已到达)2001这个ack已经覆盖了上一个丢失的1001ack的信息了。
2. 数据丢了 我们这里的2001-3000丢包了接下来3001-4000到达接收方之后接收方给发送端的ack确认序号仍然是2001表达的意思就是在索要2001开头的数据我们可以发下下面的几个ack返回的都是2001这时候发送端就会发现虽然已经发了许多数据了但是接收端一直在反复索要2001开头的数据证明2001-3000是没有收到的需要重传了。 等我们重传2001-3000的数据之后由于2001-8000的数据都已经接收到了于是接下来接收端索要的数据就是8001了。 快速重传 就是我们上述丢包后重传的情况也可以理解为超时重传机制在滑动窗口场景的变形。 有的同学可能会问到那这样接收端接收的数据不就乱序了吗 这个不必担心因为我们TCP有接收缓冲区会在缓冲区根据序号进行重新排序。
二、流量窗口
简单理解一下我们流量窗口就是干涉滑动大小的机制。 随着滑动窗口的变大我们的传输效率也在变高但能无限增大吗?
如果无限大相当于不等ack那么可靠性能否保证窗口太大会消耗大量的系统资源接收方的处理能力能否跟得上?
我们接收方的处理能力是我们滑动窗口大小的一个很重要的约束条件我们流量控制要进行的工作就是根据接收方的处理能力来协调我们发送方的放松速度。 衡量接收方的处理能力是一个非常复杂的问题可以从多个角度去衡量比如去计算我们接受方的处理速度但这种方式太麻烦了于是我们这里有一个更简单的方法就是判断接收方缓冲区的剩余大小。 我们接收方每次接收到数据之后都需要计算一个水桶剩余的容量然后将这个值通过ack报文返回给发送方然后发送方就能根据这个值来决定接下来发送的速率大小(窗口大小)是多少了。 16位的窗口大小是否意味着窗口大小最大是64kb了? 并不是我们的TCP在选项部分引入了一个窗口扩展因子 比如当我们窗口大小已经是64kb了但是仍然不够于是在选项里的扩展因子写了个2就代表64kb 2 256 kb这样就可以动态调整窗口大小了。 由于我们接收端的缓冲区剩余容量是一直动态变化的所以每次返回的ack的窗口大小也是在不断变化的。
接收端一旦发现自己的缓冲区快满了会将窗口大小设置成一个更小的值通知发送端发送端发现会随着接收端ack报文中的窗口大小减小而减慢自己的发送速度如果接收端缓冲区慢了就会将窗口设置为0发送方将不再发送数据会定期发送一个窗口探测数据段使接收端发送一个新的窗口大小给发送端
三、拥塞控制
拥塞控制和流量控制共同去决定发送方的窗口大小为多大我们刚刚学习的流量控制考虑的是接收方的处理能力而我们拥塞控制考虑的是传输过程中各个结点的处理能力。 我们刚刚只考虑了B的处理能力越没有考虑这些中间结点的因素决定A发送速度是有这两者最差的一个决定的也就是典型的木桶效应。 我们中间的结点是错综复杂的不太好衡量但是大佬们总是有办法想出了一个实验的方式来 测试出一个合适的值。 拥塞控制 本质上就是通过实验的方式来逐渐找到了一个合适的窗口大小。 慢启动 我们可以发现0轮时窗口大小是1(1不是一字节而是一个单位具体代表多少不是我们考虑的范围)以非常慢的速度发送数据如果发现没有丢包就扩大窗口。第一轮窗口大小为2扩大了一倍初始阶段由于窗口大小比较小只要每一轮不丢包窗口都扩大一倍(指数增长)。 阈值 因为指数方式增长的很快为了不增长那么快引入了一个慢启动的阈值当拥塞窗口超过这个阈值的时间不再按照指数增长而是按照线性方式增长。 在接下来如果传输过程中一旦出现了丢包如果是极少量的丢包仅仅触发超时重传如果大量丢包我们就认为网络拥堵到达了发送速率的极限此时就将窗口大小一次性缩到很小的值然后重复上述的指数增长和线性增长的过程因为我们的拥塞窗口不是固定的值而是一直动态变化的。
流量控制和拥塞窗口共同决定了发送方实际发送的窗口大小(流量控制和拥塞控制的较小值)
