计网----累积应答，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算法的方法：
c++
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丢失了，发送方继续发送了M4，M5，M6，这时接收方就会连续重新确认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）。用一个中介对象来封装一系列的对象交互。中介者是各个对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。简单来说就是解决多组件之间的通信问题，使得组件之间的通信变得简单
看下图进行理解
