为什么RPC通常基于TCP而不是WebSocket或者HTTP2，处理粘包、拆包、压缩、长度等问题？ 在网络通信中，RPC（远程过程调用）是一种常见的通信方式，它允许应用程序在不同的计算机或进程之间进行交互。
在选择通信协议时，为什么RPC通常选择基于TCP而不是WebSocket或者HTTP2？这其中涉及到处理粘包、拆包、压缩、长度等问题。
首先，我们需要了解一些基础知识。
WebSocket和HTTP2都是应用层协议，它们都是基于TCP协议的。

而TCP是一种可靠的、面向连接的传输协议，它提供了数据传输的可靠性和顺序性。
相比之下，WebSocket和HTTP2是在TCP之上的应用层协议，它们在传输数据时会添加一些额外的头部信息，这可能会增加网络传输的开销。
那么为什么RPC通常选择基于TCP而不是WebSocket或者HTTP2呢？原因有以下几点： 1. 处理粘包、拆包问题：在TCP通信中，数据是以流的形式进行传输的。
发送端发送的数据可能会被接收端分成多个包接收，也可能将多个包合并成一个包接收。

这就涉及到了粘包和拆包问题。
为了解决这个问题，RPC通常会在应用层定义自己的协议，通过在数据中添加长度或者特定的分隔符来标识数据的边界。
这样接收端就可以根据协议解析数据，从而正确处理粘包和拆包的情况。
而WebSocket和HTTP2并没有提供类似的机制，处理粘包和拆包问题会更加复杂。

2. 压缩和长度问题：在网络通信中，数据的传输效率是非常重要的。
RPC通常会使用压缩算法对数据进行压缩，以减少数据的传输量，提高传输效率。
此外，RPC通常还会在数据中添加长度信息，以便接收端正确解析数据。
而WebSocket和HTTP2并没有提供原生的压缩和长度信息的支持，需要额外的处理来实现这些功能。

3. 性能和效率考虑：TCP是一种成熟的传输协议，它在可靠性和效率方面有着较好的表现。
相比之下，WebSocket和HTTP2在传输数据时会添加额外的头部信息，这可能会增加网络传输的开销。
而RPC通常需要高效地传输大量的数据，因此选择基于TCP的RPC通常能够更好地满足性能和效率的需求。
综上所述，RPC通常选择基于TCP而不是WebSocket或者HTTP2，主要是因为TCP在可靠性、顺序性、处理粘包和拆包问题等方面有着较好的支持。

虽然WebSocket和HTTP2也可以用于RPC通信，但它们在处理粘包、拆包、压缩和长度等问题上相对复杂，不如基于TCP的RPC通信直接、高效。
因此，选择基于TCP的RPC通常是更为常见的选择。
。