做任务刷王者皮肤网站,一般网站建设多少钱,互联网产品推广,阳高网站建设文章目录 1. listen的第二个参数2. 滑动窗口3. 流量控制4. 拥塞控制5. 延迟应答6. 捎带应答7. 面向字节流7.1 粘包问题 8. TCP异常情况10. TCP小结 1. listen的第二个参数
listen的第二个参数#xff0c;叫做底层的全连接队列的长度#xff0c;算法是#xff1a;n1#xf… 文章目录 1. listen的第二个参数2. 滑动窗口3. 流量控制4. 拥塞控制5. 延迟应答6. 捎带应答7. 面向字节流7.1 粘包问题 8. TCP异常情况10. TCP小结 1. listen的第二个参数
listen的第二个参数叫做底层的全连接队列的长度算法是n1表示在不accept的情况下你最多能够维护多少个链接。
假设我们传的listen的第二个参数是2那么最多维护全连接的个数是3个超过3个将不让我们成功3次握手。而是以 SYN_SENT状态给我们保留当有全连接退出了才会继续连接。
为什么要这样设置呢 这样排队的策略可以让服务器在闲置的情况下直接从底层拿取连接进行连接处理。但是排队的长度不能太长原因是1.对客户的体验不友好。2.在系统层面上整个服务器的可用硬件资源是确定的。如果维护的队列太长会影响服务器的原来的效率。
2. 滑动窗口
在上一篇文章中讨论了确认应答策略 对每一个发送的数据段都要给一个ACK确认应答收到ACK后再发送下一个数据段。这样做有一个比较大的缺点 就是性能较差尤其是数据往返的时间较长的时候。 但是TCP协议没有采用这样的方式但是采用了这样的思想。 既然这样一发一收的方式性能较低那么我们一次发送多条数据就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。 那么主机A如何知道主机B的接受能力根据流量控制来判断。
那么如果客户端给对方发送数据可能会丢包但是我们有超时重传机制在此期间我们需要把数据先保存到发送方的发送缓冲区。
下面就详细介绍一下发送缓冲区 这个是发送缓冲区的一个基本结构。发送过程如下 当我们发送的数据被应答后我们就可以把窗口向右移动这样左边就为已经发送确认应答中间就为已经发送没有应答右边就为待发送数据。
那么如何理解缓冲区和滑动窗口 我们可以把缓冲区看成一个大数组用两个int来代表开始下标(start)和结束下标(end)当下标超过范围时就用取余来形成环形结构。
滑动窗口的大小是由谁来决定的 目前是由对方的接受的能力决定也就是我们收到的TCP报头中的窗口大小。窗口越大则网络的吞吐率就越高。
假设发送方的缓冲区大小是4KB接收方此时也是4KB我们把数据发送过去如果对方不把数据拿上来就放在缓冲区里对方响应的TCP报头里窗口大小就为0。那么我们的滑动窗口end不变start向后移动到end同样的位置这样滑动窗口就为0。也就说明滑动窗口变小滑动窗口不一定会向右移动因为end不动。如果此时数据全部拿出接收缓冲区的大小变为16KB那么我们的滑动窗口也会变大。所以滑动窗口是会变大或者变小的。
那么滑动窗口是如何移动的呢 当我们收到TCP报头时开始下标就等于确认序号结束下标就等于开始下标报头里16位窗口大小(不准确先这样理解)。 假设我们发送了1001到2000的数据下一步开始下标就到2001结束下标不变。当发送了2001到3001的数据下一步开始下标就为3001结束下标不变。当窗口大小为0的时候开始下标和结束下标同时在5001位置。如果窗口大小突然增大开始下标不变结束下标往后。
如果发送的一批数据中只收到了2001和5001应答3001和4001应答没有收到该怎么办呢 答案是窗口大小的开始下标依旧是5001因为报头中的确认序号规定只有前面的报文收到了才会变成5001。如果真的当中的3000和4000的报文丢失了那么返回的确认序号里只到2001。接下来发送方就会进入超时重传机制。
不理解的可以看下面的图片 情况一: 数据包已经抵达ACK被丢了。 这种情况下部分ACK丢了并不要紧因为可以通过后续的ACK进行确认。
情况二: 数据包就直接丢了。 当某一段报文段丢失之后发送端会一直收到 1001 这样的ACK就像是在提醒发送端 我想要的是 1001一样。如果发送端主机连续三次收到了同样一个 “1001” 这样的应答就会将对应的数据 1001 - 2000 重新发送。这个时候接收端收到了 1001 之后再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了被放到了接收端操作系统内核的接收缓冲区中。这种机制被称为 “高速重发控制”(也叫 “快重传”)。
3. 流量控制
接收端处理数据的速度是有限的如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力来决定发送端的发送速度。这个机制就叫做流量控制。 变到0的时候主机A就不会给主机B再发送消息了。但是需要定期发送一个窗口探测数据段使接收端把窗口大小告诉发送端不过接收端也会主动发送给发送端这是一个双赴的过程。窗口探测数据段其实是没有有效载荷的TCP报头。
16位数字最大表示65535那么TCP窗口最大就是65535字节么? TCP首部40字节选项中还包含了一个窗口扩大因子M实际窗口大小是窗口字段的值左移 M 位。
4. 拥塞控制
虽然TCP有了滑动窗口能够高效可靠的发送大量的数据但是如果在刚开始阶段就发送大量的数据仍然可能引发问题。 因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。
我们如何判断是网络出现了问题呢 因为前面学习过的确认应答超时重传序号滑动窗口流量控制都是确保发送方和接收方的稳定性。如果我们发送1000报文但有999个报文丢失说明就是网络出现了问题并且不能立即重传。
为什么网络出现问题不能立即进行重传 原因是不仅仅是一台主机进行网络发送可能有许多主机同时在网络中发送数据那么网络已经非常拥堵了如果还有大量主机进行超时重传的话就会加剧网络拥堵。
解决办法TCP引入 慢启动 机制先发少量的数据摸清当前的网络拥堵状态再决定按照多大的速度传输数据。
此处引入一个概念程为拥塞窗口在这个拥塞窗口大小以内不会拥塞超出可能拥塞。
那么一次向目标主机发送的量(滑动窗口的大小)对方16位窗口大小和拥塞窗口大小的较小值。那么滑动窗口的结束下标开始下标对方16位窗口大小和拥塞窗口大小的较小值。
拥塞窗口增长速度是指数级别的。“慢启动” 只是指初使时慢但是增长速度非常快。
为了不增长的那么快因此不能使拥塞窗口单纯的加倍此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候不再按照指数方式增长而是按照线性方式增长。 当TCP开始启动的时候慢启动阈值等于窗口最大值在每次超时重发的时候慢启动阈值会变成原来的一半同时拥塞窗口置回1。
为什么一开始要指数增长 指数增长前期慢意味着前期全部主机都可以发送少量数据。当摸清当前的网络拥堵状态如果都可以发送成功就需要尽快恢复网络通信的正常速度。当增长到一定程度就让它正常的线性增长。
5. 延迟应答
如果接收数据的主机立刻返回ACK应答这时候返回的窗口可能比较小。假设接收端缓冲区为1M一次收到了500K的数据如果立刻应答返回的窗口就是500K。但实际上可能处理端处理的速度很快10ms之内就把500K数据从缓冲区消费掉了在这种情况下接收端处理还远没有达到自己的极限即使窗口再放大一些也能处理过来如果接收端稍微等一会再应答比如等待200ms再应答那么这个时候返回的窗口大小就是1M。
一定要记得窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
那么所有的包都可以延迟应答么? 肯定不是。数量限制: 每隔N个包就应答一次。或者时间限制: 超过最大延迟时间就应答一次。具体的数量和超时时间依操作系统不同也有差异一般N取2超时时间取200ms。 这幅图就是以每隔2个包就应答一次。
6. 捎带应答
在延迟应答的基础上我们发现很多情况下 客户端服务器在应用层也是 “一发一收” 的意味着客户端给服务器说了 “How are you” 服务器也会给客户端回一个 “Fine, thank you”那么这个时候ACK就可以搭顺风车和服务器回应的 “Fine, thank you” 一起回给客户端。
7. 面向字节流
创建一个TCP的socket同时在内核中创建一个发送缓冲区和一个接收缓冲区。调用write时数据会先写入发送缓冲区中如果发送的字节数太长会被拆分成多个TCP的数据包发出。如果发送的字节数太短就会先在缓冲区里等待 等到缓冲区长度差不多了 或者其它合适的时机发送出去。接收数据的时候数据也是从网卡驱动程序到达内核的接收缓冲区然后应用程序可以调用read从接收缓冲区拿数据。另一方面TCP的一个连接既有发送缓冲区也有接收缓冲区那么对于这一个连接既可以读数据也可以写数据这个概念叫做全双工。
由于缓冲区的存在TCP程序的读和写不需要一一匹配。例如写100个字节数据时可以调用一次write写100个字节也可以调用100次write每次写一个字节。读100个字节数据时也完全不需要考虑写的时候是怎么写的既可以一次read100个字节也可以一次read一个字节重复100次。
7.1 粘包问题
首先要明确粘包问题中的 “包”是指的应用层的数据包。 在TCP的协议头中没有如同UDP一样的 “报文长度” 这样的字段但是有一个序号这样的字段。站在传输层的角度TCP是一个一个报文过来的按照序号排好序放在缓冲区中。站在应用层的角度 看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。
那么如何避免粘包问题呢? 明确两个包之间的边界。 1.对于定长的包保证每次都按固定大小读取即可。 2.对于变长的包可以在包头的位置约定一个包总长度的字段从而就知道了包的结束位置。对于变长的包还可以在包和包之间使用明确的分隔符。
对于UDP协议来说是否也存在 “粘包问题” 呢? 对于UDP 如果还没有上层交付数据UDP的报文长度仍然在。 同时UDP是一个一个把数据交付给应用层。就有很明确的数据边界。站在应用层的角度使用UDP的时候要么收到完整的UDP报文要么不收不会出现半个的情况。
8. TCP异常情况
当主机间正常通信的时候突然进程终止(比如服务器崩溃了)该怎么办呢 进程终止(机器重启)会释放文件描述符因为文件描述符是跟着进程的在此之前仍然可以发送FIN和正常关闭没有什么区别。
机器掉电/网线断开接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会进行reset。即使没有写入操作TCP自己也内置了一个保活定时器会定期询问对方是否还在。如果对方不在也会把连接释放。
10. TCP小结
为什么TCP这么复杂? 因为要保证可靠性同时又尽可能的提高性能。 可靠性16位校验和(校验和不通过则认为数据有问题。可以防止比特位的翻转)、序列号(按序到达、去重)、确认应答(确保之前的数据被收到了)、超时重发、连接管理(必须3次握手和4次挥手)、流量控制、拥塞控制(让包在往里走不大量丢失)。
提高性能滑动窗口、快速重传、延迟应答、捎带应答。
