text: golang-Socket编程入门
  什么是粘包，拆包？TCP的粘包和拆包问题往往出现在基于TCP协议的通讯中，比如RPC框架在使用TCP进行数据传输时，由于TCP是基于字节流的协议，而不是基于消息的协议，可能会出现粘包（多个消息粘在一起）和拆包（一个消息被拆分成多个部分）的问题。这些问题可能会导致数据解析错误或数据不完整。为什么UDP没有粘包？由于UDP没有像TCP那样的流控制和拥塞控制机制，它不会对数据进行缓冲或重组。因此，在UDP中，每个数据报都是独立传输的（接收端一次只能接受一条独立的消息），不存在多个消息粘在一起的问题，也就没有粘包的概念。由于UDP是不可靠的传输协议，它无法保证数据的可靠传输和顺序传输。数据包可能会丢失、重复或乱序到达。在使用UDP时，应该自行处理这些问题，比如使用应答机制、超时重传等手段来保证数据的可靠性和正确性。粘包拆包发生场景因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。关于粘包和拆包可以参考下图的几种情况：理想状况：两个数据包逐一分开发送粘包：两个包一同发送，拆包：Server接收到不完整的或多出一部分的数据包常见的解决方案固定长度：发送端将每个消息固定为相同的长度，接收端按照固定长度进行拆包。这样可以确保每个消息的长度是一致的，但是对于不同长度的消息可能会浪费一些空间。分隔符：发送端在每个消息的末尾添加一个特殊的分隔符（比如换行符或特殊字符），接收端根据分隔符进行拆包。这种方法适用于消息中不会出现分隔符的情况。消息长度前缀：发送端在每个消息前面添加一个固定长度的消息长度字段，接收端先读取消息长度字段，然后根据长度读取相应长度的数据。这种方法可以准确地拆分消息，但需要保证消息长度字段的一致性。代码实现固定长度发送端将每个包都封装成固定的长度，比如20字节大小。如果不足20字节可通过补0或空等进行填充到指定长度；服务端客户端分隔符发送端在每个包的末尾使用固定的分隔符，例如\n服务端客户端消息长度前缀将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息；代码实现这段代码中，我们启动了一个TCP服务器，等待客户端连接。客户端在连接成功后，发送消息给服务器，服务器接收到消息后，返回一个响应。在发送消息时，我们首先计算消息的长度，并将长度以4字节的大端字节序写入到头部。然后，将消息体写入总结TCP 不管发送端要发什么，都基于字节流把数据发到接收端。这个字节流里可能包含上一次想要发的数据的部分信息。接收端根据需要在消息里加上识别消息边界的信息。不加就可能出现粘包问题UDP 是基于数据报的传输协议，每个数据报都是独立传输的（接收端一次只能接受一条独立的消息），不会有粘包问题。原文链接：TCP的粘包、拆包、解决方案以及Go语言实现_CoLiuRs的博客-CSDN博客