粘包问题 以及 异常处理
一. 粘包问题
注意：不仅 TCP 存在粘包问题，其他面向字节流的机制也存在粘包问题。
- 首先要明确，粘包问题中的 “包” ，是指的应用层的数据包。
- 在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段。
- 站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在接收缓冲区中。
- 接着传输层对报文进行分用，意味着把 TCP 报文进行解析，取出其中的应用层数据，放到缓冲区中，以备应用层来取。
- 站在应用层的角度，看到的只是一串连续的字节数据。
- 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包，这就是 粘包问题。
那么如何避免粘包问题呢？归根结底就是一句话，明确两个包之间的边界。
-
对于定长的包，保证每次都按固定大小读取即可；
-
对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；
-
对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；
TCP 报头中不是有说明数据长度的字段么 ？
- 首先，TCP 报头中没有说明数据长度的字段，TCP 报头中只有首部的长度，TCP 报文 - 首部长度 就能得到数据的长度，所以传输层能够准确的取出数据。
- 虽然 传输层能够 知道数据的长度，但是 应用层去取数据的时候，数据已经被分用了，不带 TCP 报头了，从应用层看就是 一串连续的字节数据， 所以有粘包问题。
（粘包问题实际上是应用层的问题。）
思考：对于UDP协议来说，是否也存在 “粘包问题” 呢？
- 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
- 站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现"半个"的情况。
二. TCP异常情况
-
进程终止：进程终止会释放文件描述符，仍然可以发送FIN。和正常关闭没有什么区别。
因为 建立的 TCP 连接，是通过 Socket 建立的，Socket 本质上是进程打开的一个文件，文件就存在于 进程的 PCB 里面的一个文件描述符表，直接杀死进程，PCB 也就没了，此处的 文件相当于自动关闭了，这个过程其实和 手动调用 socket.close() 一样，都会触发 四次挥手。 -
机器关机/重启：和进程终止的情况相同。因为机器关机 / 重启，会杀死所有的进程。
-
机器掉电/网线断开：
操作系统没有任何反应时间，更不会有任何处理措施。
接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。
即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。
另外，应用层的某些协议，也有一些这样的检测机制。例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ断线之后，也会定期尝试重新连接。
好啦！ 以上就是对 TCP 粘包问题 以及 异常处理的讲解，希望能帮到你 ！
评论区欢迎指正 !
