网站做短信验证需要多少钱,网站建设报价分析,哈尔滨无障碍网站建设,网站轮播效果目录 前言1. TCP的超时重传机制2. TCP的流量控制机制3. TCP的滑动窗口机制4. TCP的拥塞控制机制5. TCP的延迟应答机制6. TCP的捎带应答机制7. 总结以及思考 前言
强烈建议先看传输层协议详解(上)后再看这篇文章. 上一篇文章讲到TCP协议为了保证可靠性而做的一些策略, 这篇文章… 目录 前言1. TCP的超时重传机制2. TCP的流量控制机制3. TCP的滑动窗口机制4. TCP的拥塞控制机制5. TCP的延迟应答机制6. TCP的捎带应答机制7. 总结以及思考 前言
强烈建议先看传输层协议详解(上)后再看这篇文章. 上一篇文章讲到TCP协议为了保证可靠性而做的一些策略, 这篇文章会深度解析剩下的策略.
1. TCP的超时重传机制
主机 A 发送数据给 B 之后可能因为网络拥堵等原因数据无法到达主机 B;如果主机 A 在一个特定时间间隔内没有收到 B 发来的确认应答就会进行重发。这种操作叫做 超时重传。 就是我收到ACK对方收到数据,但是我没有收到ACK对方没有收到数据. 不管是数据丢了还是应答丢了发送方的策略都是超时之后进行补发. 那么就有下面两个问题:
1.应答丢包后发送方进行补发那接收方就有两个一样的报文了怎么去重呢? 一样的报文说明32位序号是一样的所以序号也有去重的功能! 并且如果有不同的多个报文序号也可以用来排序使之按序到达. 2.那么超时的时间如何确定? 这个时间的长短随着网络环境的不同是有差异的. 如果超时时间设的太长会影响整体的重传效率; 如果超时时间设的太短有可能会频繁发送重复的包。 2. TCP的流量控制机制
接收端处理数据的速度是有限的.如果发送端发的太快导致接收端的缓冲区被打满 这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。 因此TCP支持根据接收端的接收能力来决定发送端的发送速度这个机制就叫做流量控制. 通过下面的若干个问题进行讲解:
接收方的接受能力是什么? 可以认为是: 接受缓冲区中剩余空间的大小! 发送方怎么知道对方的接受能力是多少? 发送方每次发送报文给接收方接收方都会返回ACK应答就是一个报头此时接收方会把自己的剩余空间填入 16位窗口大小 这一字段再返回给发送方! 那双方第一次发送信息的时候呢又没有ACK应答怎么控制? 三次握手期间已经协商交换过了双方的接受能力! 16位窗口大小表示的数字最大是65535那么 TCP 窗口最大就是 65535 字节么? 实际上TCP首部40字节选项中还包含了一个窗口扩大因子M实际窗口大小是窗口字段的值左移 M 位。 接收方的剩余空间为0了发送方会等待那过后接收方又有空间了发送发送方怎么及时知道? 接收方会给发送方传递窗口更新通知其实就是一个报文或是发送方间隔进行窗口探测也是一个报文。这两种方式一般是同时使用的。 那如果对方一直不进行窗口更新呢? 就要用到报头里的另一个标记位:PSH.就是告诉对方把缓冲区里的数据赶快取走. 当然如果我们想让对方尽快处理数据都可以设置PSH不一定非要是0的时候. 这里再来讲一下最后一个标记位URG和16位紧急指针这个字段: URG: 紧急指针标记位.URG置为0时报头里的 16位紧急指针 这一字段无意义置1时才有意义. 16位紧急指针: 标识哪部分数据是紧急数据. 所以在流量控制机制中我们学习了以下几个字段:
16位窗口大小PSH标记位URG标记位16位进阶指针
3. TCP的滑动窗口机制
上篇文章中讲到, 服务器每收到一次数据都会回一个ACK确认应答. 但是这样是不是效率有点低下了?由其是数据往返时间比较长的时候. 有没有什么方法可以一次性发送多条数据呢? 当然TCP协议也考虑到了这一点:
滑动窗口: 可以将发送缓冲区想象成一个数组, 滑动窗口的本质就是此数组中的两个元素下标, 这两个下标会维护一段数据, 我们就可以将这份维护的数据一次性发给对方, 能大大的提高效率. 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).发送前四个段的时候, 不需要等待任何ACK, 直接发送;收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;窗口越大, 则网络的吞吐率就越高;
所以下面两个问题就有了答案: (1)根据流量控制机制发送方已经知道了对方的接收能力那具体该如何发送? 流量控制就是通过滑动窗口实现的! (2)在超时重传时超时时间以内已经发送的报文不能被丢弃而是要保存起来!保存在哪里? 保存在滑动窗口中! 4. TCP的拥塞控制机制
虽然是TCP有滑动窗口这一大杀器来提高效率和可靠性, 但是我们始终在关心的是, 对端怎么怎么样, 对端的接受能力怎么样, 对端是否收到了信息. 我们从来没有考虑过网络本身的情况, 万一网络本身就不好, 还一次性发送了大量数据, 丢包了怎么办? . 当然这一切都在TCP协议的预料之中.
拥塞控制: 因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的. TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据. 其实你只用知道, TCP的拥塞控制是用来关心当前网络状态的, 并且它采用的慢启动机制, 虽然这其中还有很多细节可以挖掘, 但是作为从事后端开发的大学生而言, 学到这个地方已经是有点东西了.
(有兴趣的同学可以看看下面对慢启动的的图像以及一点理解)
5. TCP的延迟应答机制
若接收数据后立刻返回ACK应答, 返回窗口会比较小.
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率; 说白了, 有时候立刻应答并不是一种高效率的体现.
6. TCP的捎带应答机制
捎带应答机制其实就是: ACK应答数据 一起返回去. 要注意的是: 三次握手里的前两次握手是不能捎带应答的,因为此时连接还没有建立好,只有建立成功了才可以通信.但是第三层握手ACK可以捎带数据了. 至此,TCP协议报头里的所有重要字段及其它们的作用机制都讲解完毕!
7. 总结以及思考
现在再来看, TCP是面向字节流的就大概能理解了. TCP只管迅速的给对端发包, 不管一个数据要分几次发, 一次性发多少, 总之它只管尽快将包发过去. 换句话说,就是站在TCP的角度,没有报文的概念,所有的数据都是放在一个字符数组的缓冲区里,只是单纯的把数据推送过去,但是到底有没有推完一个,一个半…)都由网络决定. 虽然这样大大的提升了效率, 但是会带来粘包问题. 也就是说对端收到数据后, 它并不知道这个数据是否是完整的一个, 还是半个, 甚至是两个半都有可能.
TCP小结:
TCP和UDP的对比: 我们说了TCP是可靠连接那么是不是TCP一定就优于UDP呢? 当然不是! TCP和UDP之间的优点和缺点不能简单绝对的进行比较。
(1)TCP 用于可靠传输的情况应用于文件传输重要状态更新等场景; (2)UDP 用于对高速传输和实时性要求较高的通信领域例如早期的 QQ视频传输等。另外 UDP 可以用于广播;
