计网----累积应答，TCP的流量控制--滑动窗口，粘包问题，心跳机制，Nagle算法，拥塞控制，TCP协议总结，UDP和TCP对比，中介者模式-CSDN博客

计网----累积应答TCP的流量控制–滑动窗口粘包问题心跳机制Nagle算法拥塞控制TCP协议总结UDP和TCP对比中介者模式

一.累积应答

1.什么是累计应答

每次发一些包收到这些包之后统一回复一个ACK累计到一定数量的包后统一给一个回复告诉前面的包都收到了

2.累计应答用在哪

累计应答用在TCP的流量控制–滑动窗口

二.TCP的流量控制–滑动窗口

TCP的流量控制是通过滑动窗口来实现的

1.什么是窗口

窗口概念

TCP是没发送一个数据都要进行一次确认应答。当上一个数据包收到了应答了再发送下一个。这个模式就有点像我和你面对面聊天你一句我一句。但这种发放的缺点是效率比较低的

有了窗口就可以指定窗口的大小。窗口大小就是指无需等待确认应答而可以继续发送数据的最大值

2.滑动窗口

看下图进行了解

提示

1.图中每一个数字就是一个包

2.图中蓝色的框就是滑动窗口这里的滑动窗口的大小是20

3.滑动窗口前面的数据是已发送并收到ACK确认的数据

分析

发送方统一发送滑动窗口中的数据包如果接收方收到了滑动窗口中所有的包就统一回复一个ACK这里是回复一个52的ACK

注意

如果发送方所发送的数据丢失了这里假设39号包丢失了其他的包都收到了那么就会返回一个39的ACK告诉发送方下一次从39号的数据包开始发39号之后已经处理的包就不再处理了因为已经处理过了

如果发送方所发送的数据丢失了这里假设39号包40号包50号包丢失了其他的包都收到了那么会返回一个39的ACK返回的ACK的值是能收到的连续的序号的最大的那个告诉发送方下一次从39号的数据包开始发并且已经处理的包就不再处理了因为已经处理过了

3.流量控制

1.什么是流量控制

所谓流量控制主要是接收方收递信息给发送方使其不要发送数据太快是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口大小并且利用大小来控制发送方的数据发送

看下图进行了解

注意当接收窗口变为0时发送窗口也会变为0发送端就会暂停发送数据。然后等应用程序从接收缓冲区里读出数据的时候接收端的接收窗口就会变大然后告诉发送端发送端的发送窗口也会变大之后发送端就可以继续发送数据了

三.粘包问题

1.什么是粘包

tcp是字节流传输是一种没有边界的可以合并的传输数据方式。

合并就要能拆开拆不开就是粘包

举例接收方接收数据之后存在接收缓冲区里等待应用程序来读但如果第一次接收的数据应用程序没有读第二次接收的数据会写在第一次接收的数据的后面那这样数据就变成一块了然后当应用程序来读的时候就没有办法区分这些数据哪些是第一次接收的数据哪些是第二次接收的数据。

2.解决粘包问题

1.设置标志位起始/结束标志位

起始标志位缺点只有一个包没收到第二个包不知道什么时候第一个包结束

起始/结束标志位的共同缺点没有办法避免用户发的包里面的内容和标志位重复

应用场景已知要发送的内容都是什么

2.固定包大小

缺点当用户发送的单个包的数据小于固定包大小就会浪费空间

应用场景下载文件文件比较大

3.先发数据长度然后再发数据包

缺点多发了一个数据长度的包浪费了时间和空间

应用场景

4.短连接 每次连接发送一个包然后就断开

缺点每次连接和断开都会花时间

应用场景访问网站

注意解决粘包问题没有最好的方法只有最合适的方法

四.心跳机制

1.应用场景

在长连接下有可能很长一段时间都没有数据连接。理论上来说这个连接时一直保持连接的但是实际情况中如果中间节点出现什么故障时难以知道的。更要命的是有的节点防火墙会自动把一定时间之内没有数据交互的连接给断掉。在这个时候就需要我们的心跳包了用于维持长连接保活

2.什么是心跳机制

就是每隔几分钟自己设定时间发送一个固定消息给服务端服务端收到后回复一个固定消息。如果服务端几分钟内没有收到客户端信息则视客户端断开

3.心跳包的发送通常有两种技术

1.应用层自己实现的心跳包比较灵活

2.使用SO_KEEPALIVE套接字选项TCP协议提供的比较固定

五.Nagle算法

1.Nagle算法的作用

Nagle算法是为了尽可能发送大块数据避免网络中充斥这许多小数据块

路由器转发数据的时候不论数据包多大转发的时间都是相同的如果包的个数多的话那路由器转发的时间就多

2.Nagle算法的规则

1.如果包长度达到MSS最大报文长度则允许发送

2.如果该包含有FIN则允许发送

3.设置了TCP_NODELAY选项时相当于关闭了Nagle算法则允许发送

4.设置了TCP_CORK选项时若所有发出去的小数据包包长度小于MSS均被确认则允许发送

5.上述条件都未满足但发生了超时一般为200ms则立即送出。

​ Nagle算法默认是打开的如果对于一些需要小数据包交互的场景的程序比如telnet或ssh这样的交互性比较强的程序则需要关闭Nagle算法。关闭Nagle算法的方法

int value=1;
setsockopt(sock_fd,IPPROTO_TCP,TCP_NODELAY,(char*)&value,sizeof(int));

六.拥塞控制

1.什么是拥塞

网络中的链路容量和交换节点中的缓存和处理及都有着工作的极限当网络的需求超过它们的工作极限时就出现了拥塞。网络中出现拥塞时如果继续发送大量数据包可能会导致数据包时延、丢失等这时TCP就会重传数据但是一重传就会导致网络的负担更重于是会导致更大的延迟以及更多的丢包这个情况就会进入恶性循环被不断地放大…

所以我们就需要用到拥塞控制用了拥塞控制之后输入负载与吞吐量之间的关系

2.拥塞控制

TCP的四种拥塞控制算法

慢开始、拥塞避免、快重传、快恢复

1.慢开始与拥塞避免

1.拥塞窗口

发送方维持一个叫做拥塞窗口cwnd(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口另外考虑到接收方的接收能力发送窗口可能小于拥塞窗口

注意发送方能发送的最大数据量取决于滑动窗口和拥塞窗口二者中小的那个

2.慢开始算法

慢开始算法的思路就是不要一开始就发送大量的数据先探测一下网络的拥塞成都也就是说由小到大逐渐增加拥塞窗口的大小。

为了防止cwnd增加过大引起网络拥塞还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下

当cwnd<ssthresh时使用慢开始算法

当cwnd>ssthresh时改用拥塞避免算法。

当cwnd=ssthresh时慢开始与拥塞避免算法任意。

3.拥塞避免算法

拥塞避免算法让拥塞窗口缓慢增长即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长

4.看图理解慢开始算法和拥塞避免算法

提示

​ 1.当使用慢开始算法下一传输伦次所得的拥塞窗口的值大于了ssthresh值那下一传输伦次所得的拥塞窗口的值变为ssthresh的值接下来改用拥塞避免算法

​ 2.当发生超时重传时图中拥塞窗口为24那一点发生了超时重传判断网络可能出现拥塞进行图中的那两个步骤

2.快重传和快恢复

注意快重传比超时重传快

1.快重传

看图理解快重传

图中发送方发送的M3丢失了发送方继续发送了M4M5M6这时接收方就会连续重新确认M2那就会立即重传M3

2.快恢复

快恢复就是在触发快重传之后将cwnd变为ssthresh+3

3.看图理解快重传和快恢复

提示图中当拥塞窗口为12那一点发生了超时重传

注意慢开始、拥塞避免快重传和快恢复这四个算法是一起使用从而实现拥塞控制的

七.TCP协议总结

1.TCP协议是面向连接的、可靠的传输基于字节流的传输方式

2.面向连接指发送数据之前必须在双端建立连接建立连接使用“三子握手”

3.可靠传输sep和ack

4.基于字节流的传输粘包问题

解决方案1.先发数据长度然后再发数据包 2.设置标志位起始/结束标志位3.固定包大小 4.短连接 每次连接发送一个包然后就断开

5.为什么TCP是可靠的

1.三次握手和四次回收

2.重传和确认机制

3.合理的手段

4.校验重新排序

5.滑动窗口----流量控制

6.拥塞窗口----4中拥塞控制算法

6…TCP可以发广播吗

TCP是一对一传输的理论上是不能发广播的

问题一微信用的是TCP协议为什么可以一次跟很多人聊天

我们每个人客户端都只跟服务端聊天然后服务端帮我们转发给其他人其他客户端

问题二QQ是使用UDP实现的那为什么我们在使用QQ的时候不会出现数据丢失

在应用层做seq和ack的功能保证传输数据可靠

使用一个队列把我们要发送的数据放到队列中去并编上号然后把包发出去包发出去的同时起一个定时器进行计时当接收端收到之后返回一个ack看是否超时没超时就继续发下面的包超时了就重新发送一次

问题三QQ是使用UDP实现的为什么要在应用层实现seq和ack的功能保证传输数据可靠为什么不直接用TCP呢

因为UDP比TCP快因为我们只需要使用TCP的一部分功能UCP加上TCP的一部分功能还是比TCP快

八.UDP和TCP对比

看下图

九.中介者模式

设计模式入门中一个模式叫做中介者模式mediator。用一个中介对象来封装一系列的对象交互。中介者是各个对象不需要显示地相互引用从而使其耦合松散而且可以独立地改变它们之间的交互。简单来说就是解决多组件之间的通信问题使得组件之间的通信变得简单

看下图进行理解