JavaEE初阶---网络原理之TCP篇（二）

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)]