RPC、RMI、Http 相关介绍

可能大家对RPC、REST、Dubbo、HTTP、RMI等概有些了解，但是对于这些名词之间的区别和联系却一直没有一个系统性的认识。下面对其做些总结。

一、概念介绍

RPC（Remote Procedure Call）是远程过程调用，是一种思想，也是一种协议规范。简单地说就是能使应用像调用本地方法一样的调用远程的过程或服务，可以应用在分布式服务、分布式计算、远程服务调用等许多场景。

RPC 的实现方式多样化：如http、webservice、rmi

此外业界有很多开源的优秀 RPC 框架，例如 Dubbo、Thrift、gRPC、Hprose 等等。

下面介绍每种 RPC 实现的侧重点：

1.HTTP

HTTP（HyperText Transfer Protocol）是一种超文本传输协议。是WWW浏览器和WWW服务器之间的应用层通讯协议。

HTTP是应用层通信协议，使用标准语义访问指定资源（图片、接口等），网络中的中转服务器能识别协议内容。

HTTP 协议是一种资源访问协议，通过 HTTP 协议可以完成远程请求并返回请求结果。

HTTP 的优点是简单、易用、可理解性强且语言无关，在远程服务调用中包括微博有着广泛应用。HTTP 的缺点是协议头较重，一般请求到具体服务器的链路较长，可能会有 DNS 解析、Nginx 代理等。

HTTP 是一种 RPC 的实现，也可以说HTTP 是 RPC 框架的传输协议。

2.RMI

RMI（Remote Method Invocation）是指 Java 语言中的远程方法调用，RMI 中的每个方法都具有方法签名，RMI 客户端和服务器端通过方法签名进行远程方法调用。RMI 只能在 Java 语言中使用，可以把 RMI 看作面向对象的 Java RPC。

RMI使用JRMP协议，JRMP又是基于TCP/IP。

3.Web Service

Web Service 是一种基于 Web 进行服务发布、查询、调用的架构方式，重点在于可以为不同的异构系统提供服务。相对http 协议来说http协议传输的都是字符串，webservice则是包装成了更复杂的对象。Web Service 一般通过 WSDL 描述服务，使用 SOAP协议通过 HTTP 调用服务。

4.Thrift、gRPC、Hessian、Hprose 、apache avro、zeroc ice

重点关注于服务的跨语言调用，能够支持大部分的语言进行语言无关的调用，非常适合于为不同语言提供通用远程服务的场景。但这类框架没有服务发现相关机制，实际使用时一般需要代理层进行请求转发和负载均衡策略控制

Hessian是一套用于建立web service的简单的二进制协议，用于替代基于XML的web service，是建立在RPC上的，Hessian有一套自己的序列化格式将数据序列化成流，然后通过http协议发送给服务器，看源码发现其实是使用HttpURLConnection和servlet建立连接，然后发送流。

5 .Dubbo、motan、 淘宝HSF、亚马逊coral service

除了有 RPC 的功能，服务发现及治理功能，适用于大型服务的微服务化拆分以及管理，对于特定语言（Java）的项目可以十分友好的透明化接入。但缺点是语言耦合度较高，跨语言支持难度较大

6 .Socket

Socket通常也称作"套接字",实现服务器和客户端之间的物理连接，并进行数据传输，主要有UDP和TCP两个协议,使用时可以指定协议TCP、UDP。Socket处于网络协议的传输层。

Socket传输的特点：
优点：

• 传输数据为字节级，传输数据可自定义，数据量小（对于手机应用讲：费用低）。
• 传输数据时间短，性能高。
• 适合于客户端和服务器端之间信息实时交互。
• 可以加密,数据安全性强。

缺点：

• 需对传输的数据进行解析，转化成应用级的数据。
• 对开发人员的开发水平要求高。
• 相对于http协议传输，增加了开发量。

UDP协议：广播式数据传输，不进行数据验证。
TCP协议：传输控制协议，一种面向连接的协议，给用户进程提供可靠的全双工的字节流。

二、区别

RPC 与 REST

同事跟你讲RPC与REST的时候，他心里想的应该是“API设计风格”。这样讲没错，但是不准确。我们先来看这两种“API设计风格”有什么区别：

如果我开了一个小餐馆，想设计一个订餐的API：

两种风格的API区别，总结一下其实非常简单：

• RPC面向过程，只发送 GET 和 POST 请求。GET用来查询信息，其他情况下一律用POST。请求参数是动词，直接描述动作本身。
• RESTful面向资源，使用 POST、DELETE、PUT、GET 请求，分别对应增、删、改、查操作。请求参数是名词，这个名词就是“增删改查”想要操作的对象。

前面提到，这样对比RPC与REST并不完全准确，原因在于RPC不仅仅是一种API设计风格，它的概念比这要广得多。PRC全称是Remote Procedure Call，即远程过程调用。我发送了一个RPC请求比如 POST /removeItem?itemId=456，实际上是调用了服务端的一个方法 removeItem(int itemId)。在我本地电脑上可以调用一个远在服务端的方法，所以叫远程过程调用。这个"远"的概念也不一定是跨越网络的，同一台主机的两个进程之间相互交流也完全可以是RPC。

RPC与RMI

RPC 不支持对象，采用http协议

RMI支持传输对象。采用JRMP(Java Remote Method Protocol)通讯协议，是构建在TCP/IP协议上的一种远程调用方法。

RMI只限于Java语言，RPC跨语言。

RPC和RMI的简单比较：

• 在RMI和RPC之间最主要的区别在于方法是如何被调用的。在RMI中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被RMI客户方所调用。在RPC中，当一个请求到达RPC服务器时，这个请求就包含了一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向RPC服务器表明，被请求的方法在为 “classname”的类中，名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

• 分布式计算系统要求运行在不同地址空间不同主机上的对象互相调用。各种分布式系统都有自己的调用协议，如CORBA的IIOP(InternetInterORB Protocol), MTS的DCOM。那么EJB组件呢？在Java里提供了完整的sockets通讯接口，但sockets要求客户端和服务端必须进行应用级协议的编码交换数据，采用sockets是非常麻烦的。
  一个代替Sockets的协议是RPC(Remote Procedure Call), 它抽象出了通讯接口用于过程调用，使得编程者调用一个远程过程和调用本地过程同样方便。RPC系统采用XDR来编码远程调用的参数和返回值。

• 但RPC 并不支持对象，而EJB构造的是完全面向对象的分布式系统，所以，面向对象的远程调用RMI(Remote Method Invocation)成为必然选择。采用RMI，调用远程对象和调用本地对象同样方便。RMI采用JRMP(Java Remote Method Protocol)通讯协议，是构建在TCP/IP协议上的一种远程调用方法。

• RMI 采用stubs 和skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的。

RPC 与 Dubbo

上一小节中提到，RPC虽然经常被当作API设计风格进行讨论，但它更多的是一种通信方式或概念（RPC不是协议！）。而Dubbo是实现了RPC概念的框架，使得调用远程服务就像调用本地方法一样，用过Dubbo的人肯定明白。所以RPC与Dubbo是实现与被实现的关系。我们常说Dubbo是阿里巴巴开源的RPC框架，就是这个道理。

这里需要提到的一点，就是Dubbo框架与Dubbo协议，一开始把我给弄混了。如果只说Dubbo一词，其实是有歧义的，因为Dubbo可以是框架也可以是协议。Dubbo框架默认使用的是Dubbo协议，这个协议是阿里巴巴自己实现的一种应用层协议，传输层还是TCP。所以Dubbo协议与HTTP、FTP，SMTP这些应用层协议是并列的概念。除了默认的Dubbo协议，Dubbo框架还支持RMI、Hessian、HTTP等协议。

RPC 与 HTTP

RPC是一种API，HTTP是一种无状态的网络协议。RPC可以基于HTTP协议实现，也可以直接在TCP协议上实现。

RPC主要是用在大型网站里面，因为大型网站里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。HTTP主要是用在中小型企业里面，业务线没那么繁多的情况下。

HTTP开发方便简单、直接。开发一个完善的RPC框架难度比较大。

HTTP发明的初衷是为了传送超文本的资源，协议设计的比较复杂，参数传递的方式效率也不高。开源的RPC框架针对远程调用协议上的效率会比HTTP快很多。

HTTP需要事先通知，修改Nginx/HAProxy配置。RPC能做到自动通知，不影响上游。

HTTP大部分是通过Json来实现的，字节大小和序列化耗时都比Thrift要更消耗性能。RPC，可以基于Thrift实现高效的二进制传输。

Dubbo、RMI、HTTP

如果将Dubbo与RMI、HTTP并列在一起，那么这个Dubbo就是指Dubbo框架默认的Dubbo协议。这个别再弄混了。

提一句RMI吧。这是一种古老的协议，在JDK1.1中就被实现了，我不知道那个时候RPC概念有没有被提出，但是RMI其实就是一种RPC的实现，比Dubbo要早得多。RMI的通信方式是把Java对象序列化为二进制格式，接收方收到以后再进行反序列化，所以局限性就是用RMI通信的系统都必须是用Java语言编写的。

RMI与SOCKET

RMI是面向对象的，而SOCKET不是。

RMI是与语言相绑定的。比如当你使用Java RMI技术的时候，客户端与服务器端都必须使用Java开发(在java.rmi.*包)。而socket的网络编程是使用独立于开发语言的，甚至独立于平台。基于socket的网络编程，客户端与服务器端可以使用不同开发语言和不同的平台。

从网络协议栈的观点来看，RMI与socket的网络编程处于不同层次上。基于socket的网络编程位于TCP协议之上，而RMI在TCP协议之上，又定义了自己的应用协议，其传输层采用的是Java远程方法协议(JRMP)。可见，在网络协议栈上，基于RMI的应用位置更高一些，这也决定了，与socket的网络编程相比，RMI会丧失一些灵活性和可控性，但是好处是它带给了应用开发者更多的简洁，方便和易用。比如：如果你用的是RMI,你不需要关心消息是怎么序列化的，你只需要像本地方法调用一样，使用RMI。代价是：应用开发者无法很好地控制消息的序列化机制。

RMI与TCP based socket相比，传输相同的有效数据，RMI需要占用更多的网络带宽（protocoloverhead）。从这里，我们可以得出一个一般性的结论：RMI主要是用于远程方法的”调用“（RMI是多么的名符其实:)，其技术内涵强调的是“调用”，基于此，我能想到的是：移动计算，和远程控制，当你的应用不需要在client与server之间传输大量的数据时，RMI是较好的选择，它简洁、易于开发。但是，一旦你的应用需要在client与server之间传输大量的数据，极端的，比如FTP应用，则RMI是不适合的，我们应该使用socket。

HTTP与SOCKET

1、TCP连接

要想明白Socket连接，先要明白TCP连接。手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。

建立起一个TCP连接需要经过“三次握手”：

第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）

2、HTTP连接

HTTP协议即超文本传送协议(HypertextTransfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。

2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

3、SOCKET原理

3.1套接字（socket）概念

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。

应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

3.2 建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket。

套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。

客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。

连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

4、SOCKET连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

5、Socket连接与HTTP连接

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用中，客户端到服务器之间的通信往往需要穿越多个中间节点，例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

---

参考文章:
什么是RPC协议？RPC协议与HTTP协议的区别？
rpc 协议规范 之 rmi http webservice 和 一些框架
http、RMI、socket、rpc、hessian比较
通俗易懂 RPC、REST、Dubbo、HTTP、RMI 的区别与联系