在计算机世界里，服务间的通信就像一场精心设计的快递接力赛。HTTP和RPC都是这场比赛的“快递员”，但它们的送货方式大不相同。为什么有了HTTP还要用RPC？ 答案藏在协议栈的层次里：HTTP是“标准物流公司”，而RPC是“定制化闪送团队”。
协议的本质：从“信封格式”到“二进制暗号”
HTTP协议本质上是一套通信格式规范。它像标准信封一样，规定请求必须包含“请求行、请求头、请求体”，响应必须遵循“状态行、响应头、响应体”。这种设计让浏览器和服务器的对话像中文交流一样统一，但代价是“信封”里塞了大量冗余信息，比如HTTP头部的Content-Type、Cookie等字段。而RPC则像密码本，能用更紧凑的二进制协议（如Protobuf）压缩数据，甚至省去“浏览器兼容”这类无关逻辑，直接让服务与服务“说黑话”，传输体积比HTTP小50%以上。
性能之争：TCP直连 vs HTTP绕路
虽然HTTP和RPC底层都依赖TCP，但RPC能跳过HTTP协议栈的“收费站”。以调用用户服务为例：
- HTTP调用：需要先打包成HTTP报文，经过DNS解析、Nginx代理，最后拆包解析。
- RPC调用：通过TCP长连接直达目标服务，用连接池复用链路，还能用零拷贝技术绕过内核态-用户态的数据搬运。
就像用高铁运输快递，HTTP每趟车都要重新调度车厢，而RPC直接把货物装进专列，延迟降低30%-70%。
微服务时代的“隐形管家”
RPC的杀手锏是服务治理。它像分布式系统的神经系统，内置服务发现（Consul/Etcd）、熔断降级（Hystrix）、负载均衡（加权轮询）等能力。当一个订单服务调用用户服务时，RPC框架能自动感知节点状态，避开故障机器，而HTTP需要手动配置Nginx，运维成本飙升。更厉害的是，RPC支持异步流式调用，像Kafka消息队列一样边传边处理，而HTTP的请求-响应模型只能干等结果。
适用场景：对外“讲礼貌”，对内“拼速度”
- HTTP：是对外的“外交官”，用JSON/XML兼容各种客户端（浏览器/APP），靠HTTPS和OAuth保障安全。
- RPC：是对内的“特种兵”，用Thrift/gRPC实现毫秒级响应，适合每秒百万级调用的支付系统或推荐引擎。
用一句话总结：HTTP是互联网的普通话，RPC是技术团队的黑话。当性能成为瓶颈时，RPC的“二进制匕首”会比HTTP的“文本大锤”更锋利——毕竟，效率是工程学的第一性原理。