如何理解字节流？

之所以会说TCP是面向字节流的协议，UDP是面向报文的协议，是因为操作系统对TCP和UDP协议的发送方的机制不同，也就是问题原因在发送方

为什么UDP协议是面向报文的协议？

 当用户消息通过UDP协议传输时，操作系统不会对消息进行拆分，在组装好UDP头部后就交给网络层来处理，所以发出去的UDP报文中的数据部分就是完整的用户消息，也就是每个UDP报文就是一个用户消息的边界，这样接收方在接收到UDP报文后，读取一个UDP报文就能读取到完整的用户消息。

操作系统在接收到UDP报文后，会将其插入到队列里，队列里的每一个元素都是一个UDP报文，这样当用户调用recvfrom()系统调用读数据的时候，就会从队列中取出一个数据，然后从内核里拷贝给用户缓冲区。

 为什么说TCP是面向字节流的协议？

当用户消息通过TCP协议传输时，消息可能会被操作系统分组成多个的TCP报文，也就是一个完整的用户消息被拆分成多个TCP报文进行传输。

这时，接收方的程序如果不知道发送方发送的消息长度，也就是不知道消息的边界时，是无法读出一个有效的用户消息的，因为用户消息被拆分成多个TCP报文后，并不能像UDP那样，一个UDP报文就能代表一个完整的用户消息。

eg：

发送方准备发送[Hi]和[I am Xiaolin]两个消息。

在发送端，当我们调用send函数完成数据“发送”后，数据并没有真正从网络上发送出去，只是从应用程序拷贝到了操作系统的内核协议栈中。

至于什么时候真正被发送，取决于发送窗口、拥塞窗口以及当前发送缓冲区的大小等条件。也就是说，我们不能认为每次send调用发送的数据，都会作为一个完整的消息被发出。

如果考虑实际网络传输过程中的各种影响，假设发送端陆续调用send函数先后发送[Hi]和[I am Xiaolin]报文，那么实际的发送情况可能是以下几种：

1. 两个消息被分到同一个TCP报文

2. [I am Xiaolin]报文的部分随[Hi]在一个TCP报文中发送出去

3. [Hi]的部分随[I am Xiaolin]报文中发送出去

因此，不能认为一个用户消息对应一个TCP报文，正因为这样，TCP是面向字节流的协议。

当两个消息的某个部分内容被分到同一个TCP报文时，就是常说的TCP粘包问题，这时，接收方不知道消息的边界的话，是无法读出有效消息的。

---

如何解决粘包

粘包的问题出现是因为不知道一个用户消息的边界在哪，如果知道了边界在哪，接收方就可以通过边界来划分出有效的用户消息。

一般有三种方式：

• 固定长度的消息
• 特殊字符作为边界
• 自定义消息结构