Dubbo问题
Dubbo基于TCP长连接+NIO，比HTTP短连接效率更高，为什么？
Dubbo 效率更高，是因为“复用连接（省握手） + NIO 高并发（省线程） + 二进制序列化（省带宽）”三者叠加。但这主要适用于“内部高频小请求”场景，对外暴露或低频调用时，HTTP 的通用性和易用性反而更有优势。
- 网络层面的“效率”差异（你提到的点）
HTTP（短连接）：每次请求都要经历TCP 三次握手 + 可能还有 TLS/SSL 加密握手。如果一次请求只传几十 KB 数据，光是建立连接的开销就占了很大比例。
Dubbo（长连接）：连接建立后复用，省去了重复握手的网络 RTT（往返时延）和 CPU 加解密开销。
👉这个差异在“高并发小数据量”场景下非常明显，但在“大文件传输”场景下，传输时间会淹没握手时间，差异反而不大。
- 更核心的差异：通信模型（BIO vs NIO）
你提到了 Dubbo 基于 NIO，这是比“长连接”更关键的因素：
HTTP 1.1（传统）：虽然是长连接（Keep-Alive），但底层 Servlet 容器大多基于BIO（阻塞 I/O）或简单线程池。一个请求独占一个线程直到响应返回。如果服务处理慢，线程就被挂起，导致线程资源浪费。
Dubbo（Netty + NIO）：基于Reactor模型。IO 线程只负责收发数据，不执行业务逻辑。业务逻辑交给业务线程池异步处理。一个线程可以同时处理成千上万个连接，IO 利用率极高。
- 协议本身的序列化效率
这也是容易被忽略的一点：
HTTP：通常使用JSON/XML（文本协议），包含大量冗余字段（如
{"name":"test"}中的大括号、引号），体积大，序列化/反序列化耗 CPU。Dubbo：默认使用Hessian2或可选的Protobuf（二进制协议）。数据体积更小，解析速度更快，网络传输时间更短。
- 关键前提：“效率更高”是有场景限制的
Dubbo 的高效是有代价的，并不是绝对碾压：
适用场景：内部微服务高频调用（QPS 高、数据包小）。此时 Dubbo 优势明显。
不适用的场景：
跨公网调用（NAT/防火墙）：HTTP/HTTPS 穿透性更好，Dubbo 自定义协议容易被拦截。
前端浏览器调用：浏览器只支持 HTTP/WebSocket，无法直接使用 Dubbo 协议。
大文件/大报文：此时传输带宽是瓶颈，协议差异可忽略，HTTP 的生态工具反而更丰富。