1.断开连接–四次挥手
创建连接：一般是我们的客户端发起的；
断开连接：我们的客户端和服务器都可以断开链接；
1.1 TCP状态
listen:表示的就是我们的这个服务器已经创建这个socket对象，端口号什么的已经全部处理惩罚好了，这个时间就可以答应我们的客户端举行连接了；
establist状态：表示我们的服务器和客户端之间的这个链接已经创建完成，这个时间可以开始举行通信了；
1.2四次挥手的过程
下面的这个就是我们的四次握手的过程，我们的这个fin就是结束报文段：表示我要和你断开连接了，这个中心的B向A发送的这个ack和fin是不可以举行合并的；
A：我要把你删除了啊~~
B：我要把你删除了啊~~
这个其实可以明白为这个两个人相互拉黑的过程~~
四次挥手两步不可以合并：这个过程的B向A发送的ack和这个fin不可以合并，因为两个触发的时间不是一样的，我们的这个ack是有这个内核发送的，这个速度是很快的，但是我们的这个fin是当我们的传输对象socket实行这个close方法的时间，这个中心还会履历一段时间，因此这两步不可以举行合并的操作；
三次握手内里可以合并：三次握手的时间这个ack,syn是同时触发的，因此这个三次握手的时间两个消息是可以举行合并的，这个也是一个区别；
延时应答：当这个ack的回应时间滞后，这个时间我们的两个ack,fin就大概会一起实行，转换为这个三次挥手；
1.3time_wait等候
这个等候主要是为了防止我们的这个ack(最后一次发送的这个ack)丢失，假如丢失了，我们须要举行重传，但是我们的这个左边的已经释放连接，重传也是无人可以处理惩罚的；
我们引入这个time_waited就是为了等候一段时间，保证我们的这个右边的没有信息发送过来，保证右边没有重传；
这个其实也是出于我们的这个两者通信的可靠性举行考虑，但是我们的这个time_wait不会无限的等候，最多是2MSL（这个是我们的网络上面的两个节点之间的这个通信斲丧的最大时间），但是这个一般不会到达2MSL的时间；
1.4三次四次的总结
如何精确的明白这个握手和挥手的过程，我认为下面的这个图片足够了，加上自己的明白，应该不会有太大的问题；
2.前段时间总结
确认应答机制：ack数据包；
超时重传机制：就是出现丢包的情况，我们会举行二次发送设置是多次发送；
连接管理机制：就是我们的三次握手，四次挥手的过程；
上面的这三个机制就是为了办理我们的这个可靠性问题，下面的这个是为了进步服从，和这三个机制是有本质的区别的，这个是可靠性，下面的这个是安全性；
3.滑动窗口—传输服从机制
3.1原理分析
TCP引入可靠性，因此这个服从就会降低，我们通过这个滑动窗口，就是为了缩短和UDP的传输的服从的差距，这个相当于就是一个亡羊补牢的操作；
下面的这个就是我们的滑动窗口和平常传输方式的一个对比：滑动窗口是为了举行数据的批量传输，因为左边的这个情况下，我们的举行等候的时间是两段时间：一个是我们的这个发已往的时间，一个是我们的这个ack返回的时间，我们的滑动窗口是为了减少这个等候时间的斲丧；
我们的这个滑动窗口是批量处理惩罚数据，这个批量也会有限制的，当我们的发送数据量到达最大的时间，我们须要等候，等候一个ack返回之后，我们开始发下一个，而不是等候全部的全部回来再发送，而是回来一个发一个，这个就是滑动窗口的英华；
在这个视觉效果上面，好像就是这个窗口不停的移动，这个就给人一个滑动的感觉，这个就是滑动窗口的名字由来；
3.2丢包的处理惩罚
下面的这个就是两个丢包的情况：一个是我们的这个ack丢了，或者这个响应数据包丢了；
第一个情况，我们是不用处理惩罚的，例如我们的第一次应答ack是1001，就是想要索取这个1001开始的数据，但是后来我们的第二次和第三次的数据ack丢失了，这个时间直接返回这个4001，这个时间我们的主机A就明白之前的这个100-3000的数据，我们的这个主机B是收到的，因为不然的话这个序号不会是这个4001，只不过这个ack中心丢了，这个时间我们不用举行处理惩罚的；
但是这个数据包丢了：我们须要举行处理惩罚，1001-2000丢了，这时间主机A不知道，接下来只要这个主机A发数据，我们就返回这个1001，就一直问这个主机A索要这个1001，直到这个主机A给了我们（这个过程我们的主机A就会知道，这个B一直问我要1001，肯定是我的这个数据没有发送成功）这个时间他就会重传数据；
3.3快速重传
我们的这个哪个数据包丢失了，我们就重新传输那一个数据包，这个是快速重传，使我们之前的超时重传的变种；
当这个数据量很大的时间，我们可以使用，可以使用滑动窗口内里的这个快速重传；
假如是这个数据量不是很大，这个时间我们就可以使用之前介绍这个超时重传举行处理惩罚；
上面的两个重传的机制有各自的这个应用的场景，这个并不辩说；
4.流量控制—吸收方安全机制
4.1流量控制思路
这个还是书接上回：我们的窗口不停的发送数据，但是我们的这个B根原来不及担当，担当的本领超出了B上限，纵然我们窗口传输的服从很高，这个也是没用的；
我们的流量控制，就是对于这个发送方的发送速率举行控制，让他刹刹车，不要发的很快，要顺应我们的这个担当的本领；
这个其实也是我们的生产者消费者模型的一个使用，就是我们的这个B从这个自己的这个担当缓冲区取出来数据，这样纵然我们的这个发送速率很快，也不会影响我们的这个B担当数据，处理惩罚数据的服从；
4.2剩余空间巨细
就是衡量我们的吸收方的处理惩罚的本领：我们的这个B举行应答的时间，会把这个剩余缓冲空间的巨细包含在这个ack内里去，当我们的这个ack内里写的这个缓冲区见很小的时间，
下面的这个16位窗口巨细：就是我们的这个ack返回内里指明的这个剩余空间巨细；
但是这个不意味着我们的这个剩余空间最大就是16位，我们的这个选项内里可以对于这个剩余空间巨细举行动态的调整，我们的这个A根据我们的这个剩余空间巨细对于A发送的数据举行调整，
4.3探测包的机制
就是我们的这个探测包是探测一下我们的这个剩余空间是不是大于0，原本我们的这个剩余空间已经是0了，这个时间A就会使用探测包，实时对于这个剩余空间巨细举行查看；
这个探测包就是为了看看我们的这个B内里是不是有空间了，假如有了我们就会开始发送数据包，没有的话我们就会接着等候，再使用探测包不停的探测这个剩余空间巨细，以此类推；
5.拥塞控制—考虑中心节点
5.1机制的考量
上面的是考虑的我们的吸收方的担当处理惩罚本领，但是我们的这个考虑的就是我们的传输过程路径中的经过的节点的处理惩罚本领，中心经过的这个节点的处理惩罚本领到达上限，这个也是不可的；
中心节点的结构复杂，不好举行控制，我们可以先让这个A以一个小的窗口发送数据，看看是不是丢包，在这个根本上面 不停的扩大这个滑动窗口，假如出现丢包，我们在缩减这个滑动窗口的巨细；
假如不丢包了，我们就变大窗口，丢包就减小这个窗口巨细，不停的举行调整这个滑动窗口的巨细，这个做法就是通过实行的方式找到我们的这个中心节点的传输瓶颈参数—进而确定窗口巨细；
5.2壅闭情况图像分析
下面的这个就是我们的窗口巨细随着我们的传输过程的调整过程：刚开始是指数增长，然后就是线性增长，出现丢包（图上面的网络拥堵），我们就减小窗口的巨细，再重新举行这个指数增大，线性增加，重复举行下去；
们的窗口巨细随着我们的传输过程的调整过程：刚开始是指数增长，然后就是线性增长，出现丢包（图上面的网络拥堵），我们就减小窗口的巨细，再重新举行这个指数增大，线性增加，重复举行下去；
[外链图片转存中…(img-iOLNIv6E-1730292373618)]
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
