RPC
一 基本介绍
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。
二 协议结构
远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。
三 工作原理
运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：
1.调用客户端句柄；执行传送参数
2.调用本地系统内核发送网络消息
3.消息传送到远程主机
4.服务器句柄得到消息并取得参数
5.执行远程过程
6.执行的过程将结果返回服务器句柄
7.服务器句柄返回结果，调用远程系统内核
8.消息传回本地主机
9.客户句柄由内核接收消息
10.客户接收句柄返回的数据
nfs-rpc
nfs-rpc是一个集成了各种知名通信框架的高性能RPC框架，目前其最好的性能为在采用grizzly作为通信框架，采用pb作为序列化/反序列化时，tps为168k次/秒。
其支持的功能主要为：
1、透明的调用远端服务器提供的功能，例如UserService.getUserNameById;
2、单连接或多连接；
3、连接复用，因此在多线程获取连接时无需阻塞；
4、同步调用；
5、超时机制；
6、支持多种通信框架（Mina/Netty/Grizzly），支持多种序列化/反序列化（Java/Hessian/PB）；
7、支持自定义通信协议，可完全替换NFS-RPC自带的协议。
疑问：http是rpc?
HTTP并不是RPC
人们常常错误地将HTTP称作一种远程过程调用（RPC）[23]机制，仅仅是因为它包括了请求和响应。调用远程机器上的一个过程（procedure）的观念，是RPC与其他形式的基于网络的应用通信的区别所在。RPC的协议识别出过程并且传递给它固定的一组参数，然后等待在使用相同接口返回的一个消息中提供的回答。远程方法调用（RMI）也是类似的，除了过程被标识为一个｛对象，方法｝的组合，而不是一个简单的服务过程（service procedure）。被代理的RMI添加了名称服务的间接层和少量其他的技巧（trick），但是接口基本上是相同的。将HTTP和RPC区分开的并不是语法，甚至也不是使用一个流作为参数所获得的不同的特性，尽管它帮助解释了为何现有的RPC机制对于Web来说是不可用的。使得HTTP与RPC存在重大不同的是：请求是使用具有标准语义的通用的接口定向到资源的，这些语义能够被中间组件和提供服务的来源机器进行解释。结果是使得一个应用支持分层的转换（layers of transformation）和间接层（indirection），并且独立于消息的来源，这对于一个Internet规模、多个组织、无法控制的可伸缩性的信息系统来说，是非常有用的。与之相比较，RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。
HTTP并不是一种传输协议
HTTP并不是被设计为一种传输协议（transport protocol），它是一种转移协议（transfer protocol）（译者注：非常不幸，HTTP刚刚传入我国时，即被翻译为“超文本传输协议”，因为“transport”和“transfer”在中文中都具有“传输”的含意，之后以讹传讹贻害无穷。为了以示区别，译文中一律将“transfer”翻译为“转移”）。在HTTP协议中，消息通过在那些资源的表述上的转移和操作，来对资源执一些动作，从而反映出Web架构的语义。使用这个非常简单的接口来获得广泛的功能是完全有可能的，但是必须要遵循这个接口，以便
HTTP的语义被保持为对于中间组件是可见的。这就是为何HTTP可以穿越防火墙的原因。大多数当前提议的对于HTTP的扩展，除了WebDAV[60]以外，仅仅使用HTTP作为一种使其他的应用协议穿越防火墙的方法，这从根本上来说是一种有误导性的想法。不仅仅是因为这种扩展方式挫败了拥有一个防火墙的目的，而且从长远来看它将无法工作，因为防火墙的厂商将会不得不执行额外的协议过滤。因此这种扩展方式对于那些在HTTP之上的扩展而言是没有意义的，因为在这种情况下HTTP所完成的唯一的事情就是添加了来自一个遗留语法的负载（译者注：即添加了额外的HTTP协议负载）。一个真正的HTTP应用应该将协议用户的动作映射到能够使用HTTP语义来表达的某个事物，以这种方式创建一个基于网络的API来提供服务，能够被用户代理和中间组件所理解，而不需要知道关于应用的任何知识。