javaEE 初阶 — 传输层 TCP 协议中的异常情况与面向字节流的粘包问题

TCP 的十个特性：

确认应答机制

超时重传机制

连接管理机制

滑动窗口

流量控制与拥塞控制

延迟应答与捎带应答

1 粘包问题

1.1 什么是粘包问题

面向字节流引入了一个比较麻烦的粘包问题。

这里张三和小红进行了多次的交互，张三的接收缓冲区，其实是把刚才这里收到的多个数据都放到一起了。

如果应用程序调用 read 方法读取的时候，该读到那里才算是一个完整的应用层数据报呢？

由于 TCP 是字节流的，一次读一个字节或是读多个字节都是可以的。
这就导致一次读到数据有可能是半个应用层数据报，可能是一个应用层数据报，也有可能是多个应用层数据报。

就好比，过年吃饺子的时候，碗里如果没放饺子汤。过了一会儿，一碗饺子就会粘到一起了。
这个时候夹一筷子，就有可能夹到半个饺子，有可能夹到一个饺子，也有可能夹到多个饺子。
这个现象就叫做 粘包问题。

应用程序调用 read 方法，此处的 read 方法就是InputStream 里的 read 方法。

如果读的是 6 个字节，此时就正好读到了 aaaaaa，这是一个完整的应用层数据报。
如果读的是 10 个字节，此时读到的是 aaaaaabbbb，此时读到的是 “一个半” 的应用层数据报。
如果读的是 4 个字节，此时读到的 aaaa ，此时读到的就是 半个应用层数据报。

在 TCP 层次中，没有 socket api 中告诉我们应该读几个字节和具体怎么读，这完全是程序猿自己决定的。

1.2 如何解决粘包问题

我们期望的当然是读到一个完整的应用层数据报，因为这样后续才好处理。

既然是应用层，约定好应用层协议即可，尤其是明确好应用层数据报个应用层数据报之间的边界就好了。

有两个方案：

1、约定好分隔符

2、约定好每个包的长度

这两种方法二者取一即可。

采取分隔符的方法就是，在一个完整的数据报末尾加上一个例如 \n 这样的符号来进行分割。
设计分割符的时候，不能是要发送的数据报包含的吗，这样会造成误读。



约定长度就是，提前算好每个数据报的长度。

2 异常情况

异常情况，也就是传输过程中出现了不可抗力。

这里分为四个情况：

1、进程崩溃了

如果是进程没了，对应的 PCB 就没了，对应的文件描述符表就释放了，相当于是 socket.close()。
此时内核会继续完成四次挥手，此时其实仍然是一个正常断开的流程。

2、主机关机（按照正常情况关机）

主机关机要先杀进程，然后才正式关机。（杀死进程的过程中，也是和上面一样触发四次挥手）

3、主机掉电

假设是接收方掉电了，发送方仍然在继续发数据，发完数据要等待 ACK ，不过肯定是等不到的。
这个时候引发超时重传，不过肯定再怎么重传也是收不到 ACK 的，重传几次后，还没有应答，此时尝试 重置 tcp 连接。
显然这个重置也会失败，此时就会放弃连接了。（单方面放弃了）

假设是发送方掉电了，接收方发现没数据了。
此时站在接收方的角度看待，没发数据是发送方挂了？还是发送方要组织下语言，稍等会再发？
接收方是不知道的，此时会先等会儿。接收方会周期性的给发送方发送一个消息确认下对方是否还是工作正常的。


给发送方周期性的发送一条消息的这个操作叫做 保活机制，发送的消息形象的称为心跳包，因为心跳也是周期性的，
如果心跳无了，说明就寄了。

心跳包来确认通信双方是处于正常的工作状态中。

4、网线断开

这个和主机掉电是一样的，只不过一个主机是接收方掉电了，作为发送方的主机会尝试超时重传，最后放弃连接。
另一个主机是发送方掉电了，会尝试心跳包的方式来确认对方是否还是正常工作的。