前文我们介绍了NFS的整体架构，其核心是将主机端的函数调用通过网络传输到服务端，并转化为服务端的函数调用。其主要实现是主机端与服务端的一一对应的存根。那么这种转化是如何进行的呢？这就涉及到RPC协议了。
在Linux NFS中，将网络文件系统分为两层，其中RPC协议承载了NFS协议。由于RPC协议的存在，是的NFS协议变得非常简单。
RPC协议的全称为Remote Procedure Call，翻译成中文是远程过程调用。也就是通过该协议，可以实现一个远程的函数调用，这样在客户端调用一个函数，可以在服务端完成业务处理。而对于客户端来说并不关心该函数是在客户端还是服务端。
这里的函数是经过特殊方式实现的，在NFS中称为存根（stub）。以Linux内核中的实现为例，文件系统的所有操作都对应着一个存根函数，具体如下所示。
而客户端的这些存根函数在服务端也是有一一对应的存根函数的。Linux NFS中服务端的存根函数如下所示。
所以，当客户端文件系统希望完成某一个文件操作时，比如创建子目录。那么在文件系统层面可以直接调用客户端的存根函数，比如nfs3_proc_mkdir。而该函数会将请求封装后通过RPC发送到服务端，服务端的程序会根据解析后的消息调用服务端对应的存根函数完成客户端期望的操作，然后给客户端反馈。
那么这个流程是如何实现的呢？这就涉及到RPC协议的内容了。RPC的原理其实非常简单，如下是RPC数据包的格式，可以看出该格式中包含很多字段。这些字段就是用来描述存根函数的。
Sun的RPC协议在设计的时候期望实现对多种服务的支持，比如NFS协议、挂载协议和NLM等。因此在设计RPC协议的时候，RPC有3个相关的字段来进行标识，其中Program字段标识程序，区分NFS、MOUNT和NLM等其它程序类型；Program Version字段标识程序版本，考虑升级的兼容性；Procedure字段则标识程序中的过程（函数），也就是存根函数。
通过上述Program和Procedure等关键信息，当服务端收到该消息时就可以知道应该由哪个版本的哪个程序来处理该消息，而且进一步知道应该调用哪个存根函数（函数指针）来进行处理。
上面的介绍更多的是理论层面的，我们通过WireShark抓个包看看Sun RPC是如何传输数据的，以及数据的格式。如图5‑8所示是我们抓取的挂载命令的数据包，我们可以对比一下该数据包的内容与协议的关系。
可以看到，这里Program是100005；Program版本是3，也就是NFS v3的数据；Procedure的值为1。由于WireShark是支持RPC和NFS协议的，因此在图5‑8中上半部分可以看到具体的描述信息。在该图的下半部分则是原始的数据包数据。
正是由于在RPC数据包中包含的这些关键信息，当主机端发送的消息被服务端接收后，服务端根据这些信息就能知道应该调用哪个存根函数。
