几种通讯协议的比较

Posted 2020-08-05 52NewBlog-正能量

几种通讯协议的比较 
一、综述 
本文比较了RMI，Hessian，Burlap，Httpinvoker，web service等5种通讯协议的在不同的数据结构和不同数据量时的传输性能。 
RMI是java语言本身提供的远程通讯协议，稳定高效，是EJB的基础。但它只能用于JAVA程序之间的通讯。 
Hessian和Burlap是caucho公司提供的开源协议，基于HTTP传输，服务端不用开防火墙端口。协议的规范公开，可以用于任意语言。 
Httpinvoker是SpringFramework提供的远程通讯协议，只能用于JAVA程序间的通讯，且服务端和客户端必须使用SpringFramework。 
Web service是连接异构系统或异构语言的首选协议，它使用SOAP形式通讯，可以用于任何语言，目前的许多开发工具对其的支持也很好。 

测试结果显示，几种协议的通讯效率依次为： 
RMI > Httpinvoker >= Hessian >> Burlap >> web service 
RMI不愧是JAVA的首选远程调用协议，非常高效稳定，特别是在大数据量的情况下，与其他通讯协议的差距尤为明显。 
HttpInvoker使用java的序列化技术传输对象，与RMI在本质上是一致的。从效率上看，两者也相差无几，HttpInvoker与RMI的传输时间基本持平。 
Hessian在传输少量对象时，比RMI还要快速高效，但传输数据结构复杂的对象或大量数据对象时，较RMI要慢20%左右。 
Burlap仅在传输1条数据时速度尚可，通常情况下，它的毫时是RMI的3倍。 
Web Service的效率低下是众所周知的，平均来看，Web Service的通讯毫时是RMI的10倍。 




二、结果分析 
1、直接调用 
直接调用的所有毫时都接近0，这说明程序处理几乎没有花费时间，记录的全部时间都是远程调用耗费的。 
2、RMI调用 
与设想的一样，RMI理所当然是最快的，在几乎所有的情况下，它的毫时都是最少的。特别是在数据结构复杂，数据量大的情况下，与其他协议的差距尤为明显。 
为了充分发挥RMI的性能，另外做了测试类，不使用Spring，用原始的RMI形式（继承UnicastRemoteObject对象）提供服务并远程调用，与Spring对POJO包装成的RMI进行效率比较。结果显示：两者基本持平，Spring提供的服务还稍快些。 
初步认为，这是因为Spring的代理和缓存机制比较强大，节省了对象重新获取的时间。 
3、Hessian调用 
caucho公司的resin服务器号称是最快的服务器，在java领域有一定的知名度。Hessian做为resin的组成部分，其设计也非常精简高效，实际运行情况也证明了这一点。平均来看，Hessian较RMI要慢20%左右，但这只是在数据量特别大，数据结构很复杂的情况下才能体现出来，中等或少量数据时，Hessian并不比RMI慢。 
Hessian的好处是精简高效，可以跨语言使用，而且协议规范公开，我们可以针对任意语言开发对其协议的实现。目前已有实现的语言有：java, c++, .net, python, ruby。还没有delphi的实现。 
另外，Hessian与WEB服务器结合非常好，借助WEB服务器的成熟功能，在处理大量用户并发访问时会有很大优势，在资源分配，线程排队，异常处理等方面都可以由成熟的WEB服务器保证。而RMI本身并不提供多线程的服务器。而且，RMI需要开防火墙端口，Hessian不用。 
4、Burlap调用 
Burlap与Hessian都是caucho公司的开源产品，只不过Hessian采用二进制的方式，而Burlap采用xml的格式。 
测试结果显示，Burlap在数据结构不复杂，数据量中等的情况下，效率还是可以接受的，但如果数据量大，效率会急剧下降。平均计算，Burlap的调用毫时是RMI的3倍。 
我认为，其效率低有两方面的原因，一个是XML数据描述内容太多，同样的数据结构，其传输量要大很多；另一方面，众所周知，对xml的解析是比较费资源的，特别对于大数据量情况下更是如此。 
5、HttpInvoker调用 
HttpInvoker是SpringFramework提供的JAVA远程调用方法，使用java的序列化机制处理对象的传输。从测试结果看，其效率还是可以的，与RMI基本持平。 
不过，它只能用于JAVA语言之间的通讯，而且，要求客户端和服务端都使用SPRING框架。 
另外，HttpInvoker 并没有经过实践的检验，目前还没有找到应用该协议的项目。 
6、web service调用 
       本次测试选用了apache的AXIS组件作为WEB SERVICE的实现，AXIS在WEB SERVICE领域相对成熟老牌。 
为了仅测试数据传输和编码、解码的时间，客户端和服务端都使用了缓存，对象只需实例化一次。但是，测试结果显示，web service的效率还是要比其他通讯协议慢10倍。 
如果考虑到多个引用指向同一对象的传输情况，web service要落后更多。因为RMI，Hessian等协议都可以传递引用，而web service有多少个引用，就要复制多少份对象实体。 
Web service传输的冗余信息过多是其速度慢的原因之一，监控发现，同样的访问请求，描述相同的数据，web service返回的数据量是hessian协议的6.5倍。另外，WEB SERVICE的处理也很毫时，目前的xml解析器效率普遍不高，处理xml <-> bean很毫资源。从测试结果看，异地调用比本地调用要快，也从侧面说明了其毫时主要用在编码和解码xml文件上。这比冗余信息更为严重，冗余信息占用的只是网络带宽，而每次调用的资源耗费直接影响到服务器的负载能力。（MS的工程师曾说过，用WEB SERVICE不能负载100个以上的并发用户。） 
测试过程中还发现，web service编码不甚方便，对非基本类型需要逐个注册序列化和反序列化类，很麻烦，生成stub更累，不如spring + RMI/hessian处理那么流畅简洁。而且，web service不支持集合类型，只能用数组，不方便。

 

 

基于HTTP的轻量级远程调用协议- hessian

 简单就是美，介绍基于HTTP的轻量级远程调用协议- hessian

远程方法调用有很多途径：RMI，HTTP Invoker，XML-RPC（webservice）等。这里再介绍一个由caucho公司开发的hessian协议，比起上面所列的协议它的特点是：简单，高效。它采用apache授权。

它有多简单？请看下面例子：

l 服务端
1）为服务创建一个接口：
  public interface BasicAPI {
      public String hello();
  }

2）实现这个接口，注意它是作为一个servlet实现的：
  public class BasicService extends HessianServlet 
  implements BasicAPI {
      public String hello() {
          return "Hello, world";
      }
  }

3）发布这个服务：
在web.xml中登记并映射BasicService ，比如映射到 /hello 这个url。这个过程与普通的servlet没有区别。
注意：服务端需要Hessian.jar类库
l 客户端的调用
   String url = " http://localhost/hello";
  HessianProxyFactory factory = new HessianProxyFactory();
  BasicAPI basic = (BasicAPI) factory.create(BasicAPI.class, url);
  System.out.println(basic.hello());

    注意：客户端需要BasicAPI.class和Hessian.jar类库。

 

 

序列化：serializable,hessian,protobuf性能对比

通信调用 2010-06-13 14:02:40 阅读202 评论0   字号：大中小 订阅

分布式应用系统中，系统之间的通讯的质量决定了系统的可用性，当然很多可以选择的技术：XML-RPC，RMI，SOAP，CORBA，JMS，EJB，NIO等。在传输数据的过程中，数据包越小，占用的带宽就越少，同等条件下资源利用就会越小。目前基于SOA的ESB系统中，很多采用NIO来传输数据，就涉及到对象的序列化的问题。

    本文主要讨论jdk自带序列化，hessian，Google的protobuf之间的性能比较，主要指标有以下三个：（执行序列化测试1次;1个数据对象，100个，1000个）

1.        序列化文件大小

2.        序列化的读取读取性能

3.        序列化的平均写入性能

    性能指标结果（纵坐标为耗时）

 

    文件大小：hessian最小，传输带宽方面占有优势。

 

    写操作：写操作在大批量的时候，protobuf比hessian和jdk有优势。

 

    读操作：读取方面protobuf仍然占有优势，但是总体上来书，hessian和protobuf差距不大。

    性能外的问题：

1：易用性：hessian比protobuf使用起来要简单的多，google需要预先生成一个*.proto文件，使用的时候需要依赖它的build接口，和GAE中的web.py的模板文件一样，预处理真是方便的框架，并没有让用户觉得爽。这方面hessian占优势。

2：学习成本：老牌hessian在java平台上广结良缘，文档和FAQ相当齐全，学习成本相对较低。google搜索protobuf google显示21.1W条，而hessian java却有54.4W条。

3：跨平台：hessian支持的语言：java,c++,python,php,erlang,ruby等，主要是针对java平台的，C++版本是05年的和python版本是07年的，更新都较慢；protobuf这块做的就比较好，如果系统中需要不同语言的就选择protobuf了，单java语言的还是选择hessian比较好。

    其他方面的知识：

    二进制协议比基于xml协议（Burlap和apache XML-RPC）的效率要高的多（ORMI的HTTP隧道启用除外），XML-RPC经过测试无论是文件大小和速度都没有优势。

原文链接: http://www.longtask.com/blog/?p=542