有了TCP为什么还需要HTTP？再用RPC？这次彻底讲明白了

小盟發表於 2025-11-24 23:39:00

有了TCP为什么还需要HTTP？再用RPC？这次彻底讲明白了

<blockquote>
掘金原文（个人技术文章优先在掘金发布）：https://juejin.cn/post/7559981310472470562 
记得刚工作那会儿，第一次接触RPC概念时，我内心满是疑惑——明明HTTP用得好好的，为什么要搞出个RPC？直到参与了几个微服务项目后，我才真正能理解它们各自的价值。今天，就让我们一起理清这些协议之间的关系。
</blockquote>
<h2 id="从网络基础说起tcp的能力与局限">从网络基础说起：TCP的能力与局限</h2>
刚开始接触网络编程时，我觉得TCP已经足够完美——它能够建立稳定的连接、保证数据可靠传输、处理网络拥塞，这似乎就是网络通信的全部需求。
但在实际开发中，我遇到了一个基础却关键的问题：
<pre><code class="language-java">// 发送方连续发送两条独立消息
socket.write("Hello");
socket.write("World");

// 接收方可能一次收到："HelloWorld"
// 完全无法区分原始的消息边界
</code></pre>
这一现象常被称作TCP粘包问题，但这其实是一种误解。其本质是TCP作为字节流协议的无边界特性：TCP只负责可靠地传输字节序列，却不关心这些字节应该如何被组织成有意义的业务消息。
TCP的三个核心特性：
<ul>
<li>面向连接：通信前需要通过三次握手建立连接</li>
<li>可靠传输：通过确认、重传、排序等机制保证数据可靠送达</li>
<li>基于字节流：数据没有自然边界，只是连续的字节序列（二进制）</li>
</ul>
个人理解： TCP就像是一个可靠的物流系统，保证把所有的货物（字节）都按顺序送达，但它会把所有货物都装进一条连续的传送带（字节流）——货物确实都到了，但接收方需要自己根据包裹上的信息（应用层协议）来重新拆分和识别每个独立的包裹。
<blockquote>
所谓“粘包”，其实是一个伪命题。TCP传输的是字节流，而非消息包。如何在流中界定消息，是应用层协议需要解决的问题。
</blockquote>
<h2 id="http协议的出现为数据赋予意义">HTTP协议的出现：为数据赋予意义</h2>
面对TCP的局限性，应用层协议应运而生。HTTP协议通过在TCP之上定义明确的报文格式，解决了消息边界和语义表达的问题。
HTTP通过标准的报文结构定义消息边界：
<pre><code>HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 48

{"name": "Alice", "email": "alice@example.com"}
</code></pre>
关键就在于<code>Content-Length: 48</code>这个头部——它明确告诉接收方消息体的确切长度，从而解决了TCP的粘包问题。
HTTP协议的主要价值：
<ul>
<li>定义消息边界：通过Content-Length或chunked编码标识消息范围</li>
<li>标准化通信语义：GET、POST、PUT、DELETE等标准方法</li>
<li>丰富的能力扩展：缓存控制、内容协商、状态管理</li>
<li>通用兼容性：被所有主流平台和语言支持</li>
</ul>
结论： TCP解决了"可靠传输"的问题，而HTTP等应用层协议解决了"传输什么"和"如何解析"的问题。
<h2 id="新的困惑为什么要在http之上再引入rpc">新的困惑：为什么要在HTTP之上再引入RPC？</h2>
随着分布式系统的发展，大家都能发现基于HTTP的服务间调用会存在一些不便：
<pre><code class="language-java">// 基于HTTP的服务调用需要大量样板代码
HttpClient client = HttpClients.createDefault();
HttpPost post = new HttpPost("http://user-service/getUser");
post.setHeader("Content-Type", "application/json");

String jsonBody = "{\"user_id\": 123}";
post.setEntity(new StringEntity(jsonBody));

HttpResponse response = client.execute(post);
if (response.getStatusLine().getStatusCode() == 200) {
String responseBody = EntityUtils.toString(response.getEntity());
User user = objectMapper.readValue(responseBody, User.class);
}
// 太多的底层细节需要处理！
</code></pre>
每次调用都需要处理HTTP状态码、异常情况、序列化反序列化等重复工作。这让我们开始思考：能否让远程服务调用像调用本地方法一样简单？
<h2 id="rpc的核心理念透明化的远程调用">RPC的核心理念：透明化的远程调用</h2>
RPC（Remote Procedure Call），又叫做远程过程调用，其目标就是让远程服务调用对开发者透明。
<pre><code class="language-java">// 理想的RPC调用方式
User user = userService.getUser(123);

// 而不是处理各种网络通信细节
</code></pre>
重要概念澄清（基于个人理解）： 
RPC本身不是具体的协议，而是一种调用范式或技术思想。它的核心目标是让程序员能够像调用本地方法那样调用远程服务。
但是我们不能说“使用RPC协议”，因为RPC本身不是协议。
正确的表述方式：
<ul>
<li>✅ "我们使用gRPC协议进行RPC调用"</li>
<li>❌ "我们使用RPC协议"</li>
</ul>
因为RPC本身不是协议，而gRPC、Thrift、Dubbo等才是具体的协议实现。
<h2 id="rpc与http的关系不同维度的技术">RPC与HTTP的关系：不同维度的技术</h2>
RPC与HTTP的关系这是最容易产生混淆的地方。通过学习和实践，我个人理解为：
RPC和HTTP根本不在同一个技术层级：
<ul>
<li>RPC是一种调用范式，对标的是本地方法调用</li>
<li>HTTP是一种具体的应用层协议</li>
<li>RPC可以通过HTTP实现，也可以通过自定义的TCP或UDP协议实现</li>
</ul>
比如gRPC选择基于HTTP/2协议实现，而很多早期的RPC框架使用自定义的TCP二进制协议。
<h2 id="rpc协议与rpc框架的完整生态">RPC协议与RPC框架的完整生态</h2>
<h3 id="rpc协议通信的基础规范">RPC协议：通信的基础规范</h3>
协议主要定义三个核心方面：
<ol>
<li>消息格式：定义消息如何开始、结束，头部和体部的结构</li>
<li>序列化方式：规定数据如何编码和解码</li>
<li>传输规则：确定通信流程和交互模式</li>
</ol>
<h3 id="rpc框架基于协议的完整解决方案">RPC框架：基于协议的完整解决方案</h3>
现代RPC框架在基础协议之上提供了企业级的能力：
<ul>
<li>核心层：实现通信协议本身</li>
<li>组件层：提供序列化、服务发现、负载均衡等基础组件</li>
<li>治理层：包含容错、监控、注册中心等运维能力</li>
<li>应用层：让开发者透明地进行远程方法调用</li>
</ul>
总结： 协议定义了机器之间如何对话，框架让开发者无需关心对话过程而专注业务逻辑。
<h2 id="现代架构中的技术选型各司其职的分工">现代架构中的技术选型：各司其职的分工</h2>
通过参与实际项目，我逐渐理解了HTTP和RPC在现代架构中的分工原则。针对大部分公司而言，基本上都是如此。
<h3 id="内部服务调用rpc框架的优势领域">内部服务调用：RPC框架的优势领域</h3>
在微服务架构内部，RPC框架因其性能优势成为首选：
RPC的高性能主要源于：
<ol>
<li>
高效的序列化
<pre><code class="language-java">// JSON序列化：可读性好但体积大
{"id": 123, "name": "Alice", "age": 30}// 约40字节

// Protobuf二进制：体积小，解析快
\x08\x7B\x12\x05Alice\x18\x1E// 仅11字节
// 体积减少70%以上，序列化速度提升明显
</code></pre>
</li>
<li>
协议开销优化
<ul>
<li>长连接减少TCP握手开销</li>
<li>多路复用提升连接利用率</li>
<li>头部压缩减少传输数据量</li>
</ul>
</li>
<li>
专为性能设计
<ul>
<li>精简的协议头设计</li>
<li>二进制编码效率</li>
<li>零拷贝等技术应用</li>
</ul>
</li>
</ol>
<h3 id="对外api暴露http协议的不可替代性">对外API暴露：HTTP协议的不可替代性</h3>
当需要向外部提供API时，HTTP协议展现出其独特价值：
HTTP的通用性优势：
<ul>
<li>无与伦比的生态系统：所有平台、语言、设备都支持HTTP</li>
<li>成熟的工具链：浏览器、Postman、curl等调试工具</li>
<li>网络友好性：80/443端口普遍开放</li>
<li>易于测试调试：直接通过浏览器或命令行工具测试</li>
</ul>
<pre><code class="language-javascript">// 前端调用HTTP API简单直接
fetch('/api/users/123')
.then(response => response.json())
.then(user => {
displayUser(user);
});
</code></pre>
<h2 id="真实世界的架构实践">真实世界的架构实践</h2>
现代互联网公司的典型架构体现了清晰的分层设计：
<img src="https://img2024.cnblogs.com/blog/3703499/202511/3703499-20251124233355527-369747172.png">
这种架构的智慧：
<ul>
<li>内外有别：对外保证兼容性，对内追求性能</li>
<li>关注点分离：网关处理横切关注点，业务服务专注核心逻辑</li>
<li>协议转换：在网关层完成HTTP到RPC的协议转换</li>
</ul>
<h2 id="总结与核心观点">总结与核心观点</h2>
针对文章内容，整体总结一下：
技术演进脉络：
<ol>
<li>TCP层：解决网络层的可靠传输问题</li>
<li>HTTP层：解决应用层的消息格式和语义问题</li>
<li>RPC层：优化分布式系统的服务调用体验</li>
</ol>
现代架构的最佳实践：
<ul>
<li>
公司内部服务调用：优先采用RPC框架（如gRPC、Dubbo）
<ul>
<li>核心原因：极致性能。二进制编码、协议开销低、长连接复用</li>
</ul>
</li>
<li>
对外暴露接口：普遍采用HTTP协议（及RESTful风格）
<ul>
<li>核心原因：无与伦比的通用性。生态系统成熟，客户端兼容性好</li>
</ul>
</li>
</ul>
核心结论： 
这是一个"内外有别"的最佳实践——性能至上的内部集群采用RPC框架，兼容性优先的对外开放接口采用HTTP协议。
<blockquote>
本文内容是作者在学习过程中的个人理解和总结，可能存在不准确或理解有误的地方，欢迎倔友们指正。
当然我也已经练习长达两年半了😄，理论上🤌应该没问题。 
<img src="https://img2024.cnblogs.com/blog/3703499/202511/3703499-20251124233417535-1141321522.png">
</blockquote>
<hr>
<blockquote>
文章的最后，想和你多聊两句。
技术之路，常常是热闹与孤独并存。那些深夜的调试、灵光一闪的方案、还有踩坑爬起后的顿悟，如果能有人一起聊聊，该多好。
为此，我建了一个小花园——我的微信公众号「[努力的小郑]」。
这里没有高深莫测的理论堆砌，只有我对后端开发、系统设计和工程实践的持续思考与沉淀。它更像我的数字笔记本，记录着那些值得被记住的解决方案和思维火花。
如果你觉得今天的文章还有一点启发，或者单纯想找一个同行者偶尔聊聊技术、谈谈思考，那么，欢迎你来坐坐。 
<img src="https://img2024.cnblogs.com/blog/3703499/202601/3703499-20260105210259813-964799315.jpg">
愿你前行路上，总有代码可写，有梦可追，也有灯火可亲。
</blockquote> 
来源：https://www.cnblogs.com/xzqcsj/p/19266220

頁: [1]

琼殿技术论坛's Archiver

有了TCP为什么还需要HTTP？再用RPC？这次彻底讲明白了