目录
1、拥塞控制
2、延时应答
3、捎带应答
4、面向字节流
5、异常情况处理
5.1、其中一方出现了进程崩溃
5.2、其中一方出现关机（正常流程的关机）
5.3、其中一方出现断电（直接拔电源，也是关机，更突然的关机）
5.4、网络断开
1、拥塞控制
和流量控制一样，也是用来限制发送方的发送速率的。
如果当前接收方处理速度很快，但是中间的通信路径出现问题，某个地方出现了“堵车”现象，此时发送的速度再快也没有（反而发的越快丢包丢的越多）。
将中间路径的所有设备视为一个整体，如果按照某个窗口大小发送数据后出现了丢包，就视为中间路径存在拥堵，就减少窗口大小；没有出现丢包，就视为中间路径不存在拥堵，就增加窗口大小。
拥塞控制的流程：
- 慢启动。由于刚开始网络的拥塞情况未知，如果一上来就搞很大，可能就让原本不富裕的网络宽带雪上加霜，因此此时刚启动的传输时速率比较小，采用的窗口大小（拥塞窗口）也比较小。
- 如果在慢启动环节没有出现丢包现象，此时说明网络比较通畅，就使用指数增大的方式逐步增大窗口大小。
- 指数增长增长的速度非常快，因此不会一直持续，这里引入了一个“阈值”，当拥塞窗口达到阈值之后，此时指数增长就变成了“线性增长”。
- 线性增长积累到一定时间后，由于传输塑速率不断增大，到达某一时刻时可能就会出现丢包，一旦出现丢包，就把拥塞窗口重置成较小的值。以前的做法是：回到最初的“慢启动”过程，然后重新开始。但是这个做法启动的起点太低了，平均速率不快。现在的做法是：启动“快恢复”，设置一个新的“阈值”，回到新的阈值，然后再继续线性增长。
2、延时应答
也是基于滑动窗口，是要尽可能的再提高一点效率。
结合滑动窗口以及流量控制，通过延时应答 ack 的方式，把返回的“窗口大小”的数值变大一些，核心在于在允许的范围内，让窗口尽可能的大。【通过修改窗口大小提升效率】
接收方收到数据之后，不会立即返回 ack，而是等待一定时间再返回 ack，相当于给接收方的应用程序里腾出了更多的时间，来消费这里的数据，使接收缓冲区的空闲空间更大一些（因为被消费掉了），又由于流量控制中“接收方会按照自身接收缓冲区的剩余空间大小作为 ack 中窗口大小的数值，发送方就能根据该数值调整窗口大小。”的机制，此时返回的窗口大小就是一个相对大的值。
前面也讨论过，滑动窗口下，如果 ack 丢了，不会有什么影响。而此处的“延时应答”也一样，可以按照“ack 丢了”的方式来处理。正常每个数据都有 ack，此时就可以每隔几个数据或每隔一定时间再返回一个 ack（起到延时应答的效果），减少了 ack 传输的数量，起到了节省开销的效果
3、捎带应答
基于延时应答引入的机制，能够提升传输效率。尽可能的把能合并的数据包进行合并，从而提高效率。
本身 ack 也不携带载荷，只要把报头中的 ack 标志位设为1，并且设置确认序号以及窗口大小，而这几个属性，response 报文本身也用不到，因此不会产生冲突。
在捎带应答的加持下，后续的每次传输请求响应，都可能触发捎带应答，都可能把接下来要传输的业务数据和上次的 ack 合二为一。（并不一定触发，主要取决于下一个数据来的时间，如果来的快就可能触发合并，来的慢就无法触发）
因为“延时应答”和“捎带应答”，使四次挥手可能合并成“三次挥手”。
4、面向字节流
由于 TCP 面向字节流，会引起“粘包问题”，粘包就类似于一段文字里没有任何标点符号，导致无法正确断句，产生非常多的歧义，包是“TCP载荷中的应用数据包”。
由于 TCP 连接中接收方整个读取过程非常灵活，可能会使代码中无法区分出当前的数据从哪到哪是一个完整的应用数据包。TCP 本身不会解决“粘包问题”，需要程序员在写应用层逻辑的时候自己去进行处理。
粘包问题，不是 TCP 独有的问题，只要面向字节流，都会有粘包问题。
解决粘包问题的关键，就是“明确包之间的边界”：
1、通过特殊符号，作为分隔符。
2、指定出包的长度。比如把包的开始位置加上一个长度表示数据长度。
5、异常情况处理
在网络连接的过程中，接收方和发送方之间可能会因为某些原因出现严重的丢包，甚至是网络直接出现故障的情况，对于这些情况该如何处理？
5.1、其中一方出现了进程崩溃
进程无论是正常结束，还是异常崩溃，都会触发“四次挥手”进行回收文件资源和关闭文件（系统自动完成）。
TCP 连接的生命周期，可以比进程更长一些， 这就使得进程虽然已经退出，但是 TCP 连接还在，仍然可以进行“四次挥手”。（虽然说是异常崩溃，实际上和正常的四次挥手结束流程，没有什么区别，进程不在了就通过系统中仍然持有的连接信息，完成后续的挥手流程）
5.2、其中一方出现关机（正常流程的关机）
当一个主机触发关机操作，就会先强制终止所有的进程（类似于上述的进程崩溃，对进程进行强杀操作）
那么根据 情况1 可以知道，终止进程自然会触发“四次挥手”。
而与 情况1 不同的是，虽然进程会自动触发“四次挥手”，但是因为系统马上就关闭，四次挥手不一定能挥完。如果挥得快，能够顺利挥完，此时本端和对端都能正常删除连接信息，完成四次挥手；如果挥得慢，至少能把第一个 fin 发送到对端，至少能告诉对方我这边要结束了，对端收到 fin 之后，就会进入释放连接的流程，并返回 ack 和 fin，而此时对端发送的 fin 不会得到 ack 回应（因为本端关机了），没有收到 ack，势必会进行重传，当重传时间达到阈值，就会单方面释放连接信息。
5.3、其中一方出现断电（直接拔电源，也是关机，更突然的关机）
如果直接断电，机器瞬间关机，此时肯定来不及发送 fin 。（突然断电的情况非常伤硬盘，尤其机械硬盘）。
a）断电是接收方，发送方就会突然发现没有 ack 返回了，就进行重传，几次重传后还是无回应，就会尝试使用 TCP 中的“复位报文段”进行“复位”连接（清楚原有 TCP 中的各种临时数据，重新连接）。
此时发送的 RST 也不会有 ack，复位连接也不行，就会单方面放弃连接。
b）断电是发送方。由于接收方始终都是在阻塞等待发送方的消息，此时就需要区分，发送方是暂时没法消息，还是挂了。因此 TCP 就引入了“心跳包”概念，每隔一段时间询问对方状态，当发现对方挂了（没有心跳），则按照流程执行复位连接并单方面释放连接。
5.4、网络断开
本质上就是 情况3 中的 a）和 b）的结合。
对 JVM 的类加载机制以及寻找字节码文件的“双亲委派模型”的理解-CSDN博客
https://blog.csdn.net/zzzzzhxxx/article/details/136529700?spm=1001.2014.3001.5501
JVM 的垃圾回收机制以及垃圾回收算法的详解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136530845?spm=1001.2014.3001.5501【网络编程】理解客户端和服务器并使用Java提供的api实现回显服务器-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136322678?spm=1001.2014.3001.5501
如果觉得作者写的不错，求给博主一个大大的点赞支持一下，你们的支持是我更新的最大动力！
如果觉得作者写的不错，求给博主一个大大的点赞支持一下，你们的支持是我更新的最大动力！
如果觉得作者写的不错，求给博主一个大大的点赞支持一下，你们的支持是我更新的最大动力！
