我们很容易把文件系统认为是想当然就有的。我们在计算机上工作，计算机让我们能够访问打印机、照相机、数据库、远程传感器、望远镜、编译器和移动电话。这些设备几乎没什么共性 —— 实际上，其中很多都是在 Internet 得到广泛应用之后才成为了现实的（例如，综合了小型计算机功能的照相机和移动电话）。然而，它们都需要某种类型的文件系统来安全地存储和访问数据。
通常来说，我们都不会真的去问这样的问题：数据、使用数据的应用程序以及将数据呈现给我们的接口是如何存储在计算机上的？很多用户都（不无道理地）将文件系统当作是一面将自己与以位和字节形式保存的原始数据分隔开来的墙。连接文件系统所使用的协议栈对于大部分用户来说通常都是一个黑盒子，实际上对于大部分程序员来说也是如此。在所有这些设备之间进行互联也就相当于启用了文件系统之间的通信。
网络文件系统从很多方面讲，通信都不仅仅是信息的长距离传输。网络协议也并不是使通用通信成为可能的惟一手段。毕竟，每个计算机系统都必须将数据报翻译成另外一端的操作系统可以理解的内容。TCP 是一种高效的传输协议，但是它并没有被优化来协助快速文件访问和启用应用程序软件的远程控制。
分布式计算和网络计算的比较传统的网络协议对于计算在计算机之间（实际上是网络上）分发的方法所能做的贡献不多。只有那些蹩脚的程序员才会依赖于传输协议和光纤电缆来进行并行计算。相反，我们通常都依赖于一个连续模型，其中链接层的协议在连接初始化完成后进行接管，并要在网卡之间进行相当复杂的握手。并行计算和分布式文件系统都不再识别 IP 或以太网了。现在，只要事关性能，我们就可以忽略它们。然而，安全性问题却另当别论。
文件访问在计算机系统之间的组织方式仍然是个谜。现在，不管所访问的文件是在一台计算机上还是在多台合理分布的计算机上，对于访问系统来说都应该没什么区别。文件系统的语义和文件系统的数据结构现在已经成为了两个完全不同的主题。在 Plan 9 安装上的或在 Andrew 文件系统（AFS）风格的分布式文件系统上的文件系统语义隐藏了文件的组织方式和文件系统到硬件和网络的映射方式。NFS 并不需要隐藏文件和目录在远程文件系统上的存储方法，但是它也没有公开存储文件系统、目录和文件的实际硬件。
NFS：UNIX 问题的一个解决方案分布式文件系统访问需要使用多个命令来使用户可以将网络上一台计算机中的目录挂载到自己的系统上来。Sun Microsystems 在很多年之前就面临了这种挑战，当时它正开始着手推广称为 远程过程调用（RPC）的技术和 NFS。
Sun 公司需要解决的根本问题是如何将几台 UNIX 机器连接在一起，从而构成一个无缝的分布式工作环境，而不需要重新编写 UNIX 文件系统的语义，同时也不用添加太多分布式文件系统特有的数据结构。当然，要想让 UNIX 工作站的网络看起来像一个大系统是不可能的：在保留每个系统的完整性的同时，要让用户能够在其他计算机的目录上进行操作，而且不会体验到不可接受的延时或任何的工作流程限制。
当然，NFS 所做的远远不止于实现了对文本文件的访问，我们还可以通过 NFS 来分发 “可运行的” 应用程序。必须要有一些安全过程来支持网络以防对可执行程序的恶意接管。但是这一切究竟是如何实现的呢？
NFS 是一个 RPC 标准NFS 传统上是作为一个 RFC 应用程序来定义的，它要求 NFS 服务器使用 TCP 协议，NFS 客户机使用 TCP 或另外一种可以避免网络拥塞的协议。Internet 工程任务组（IETF）在 RFC 1832 发布了 PRC 的 Request for Comments (RFC)。另外一个对于 NFS 实现来说至关重要的标准则描述了 NFS 所使用的数据格式；它已经在 RFC 1831 中以 “External Data Representation”（XDR）文档的形式发布了。
其他一些 RFC 是关于在 NFS 会话过程中交换验证信息所需要的安全性和加密算法的。这里我们先来关注一下 NFS 的基本机制，相关的一个协议是 Mount 协议，它是在 RFC 1813 的附录 1 中描述的。
这个 RFC 告诉我们哪些协议让 NFS 得以工作，但是它并没有告诉我们 NFS 目前是如何工作的。 NFS 协议已经被定义为 IETF 标准的事实多少说明了它的重要性。最新的 NFS 发行版依然还是版本 3，RFC 的发展也没有超出 RFC 的描述报告阶段，因此 REC 一直被认为是一个限于 Sun Microsystems 众多的工程人员研究的对象和一种专有 UNIX 变种。Sun NFS 从 1985 年开始已经推出了很多版本，因此很多年以来一直在最当前的文件系统种类中处于领先地位。Sun Microsystems 在 1998 年将 NFS 的控制权转交给了 IETF，许多 NSF 版本 4（NFSv4）的活动都是在 IETF 的支持下进行的。
因此，现在的 RPC 和 NFS 版本反映了 Sun 公司之外的公司和兴趣团体的意愿。不过，很多 Sun 公司的工程师仍然对 NFS 的开发保持着极大的兴趣。
NFS 版本 3版本 3 的 NFS（NFSv3）是无状态的，而 NFSv4 是有状态的。现在这一事实并不会引起太大争议：尽管 NFS 构建于的 TCP/IP 世界一直都是无状态的，这也恰恰是一些流量分析和安全性软件公司运转得很好的原因之一。
NFSv3 必须要依赖于几个辅助协议实现对远程计算机上目录的无缝加载，而不会太过依赖于底层的文件系统机制。NFS 在这种尝试中并非一直都成功。举例来说， Mount 协议调用初始文件句柄，而 Network Lock Manager 协议解决文件锁定，这两个操作都需要状态，而 NFSv3 却并没有提供状态。因此，在没有提供类似的数据流机制的协议层需要进行复杂的交互。现在，如果再考虑到在 Microsoft® Windows® 中创建的文件和目录与 UNIX 上创建的文件和目录有很大的差异的这一事实，那么事情就变得更加复杂了。
NFSv3 必须要使用几个端口来协调一些辅助协议，这样端口和协议层的以及与它们相关的安全问题就更加复杂了。目前，这个操作模型已经被舍弃了，以前在各个端口上要进行的辅助协议的所有操作在 NFSv4 中都可以使用一个知名端口来进行的。
NFSv3 也已经准备好进行启用了 Unicode 的文件系统操作了 —— 这直到二十世纪九十年代还是相当理论的一个优势。总之，NFS 对于 UNIX 文件系统语义映射得非常好，并且促进了分布式文件系统实现之间的竞争，例如 AFS 和 Samba。虽然 Windows 的支持很差，不过 Samba 文件服务器已经解决了在 UNIX 和 Windows 系统之间访问共享文件的问题。
NFS 版本 4正如我们指出的一样，NFSv4 是有状态的。有几个根本的改变使之成为可能。我们前面提到过必须调用辅助协议，因为用户层的进程已经被舍弃了。相反，每个文件打开操作以及相当多的 RPC 调用都被转换成了内核层的文件系统操作。
所有的 NFS 版本都以 RPC 客户机和服务器操作的形式定义了每个任务单元。每个 NFSv3 请求都需要相当多的 RPC 调用和端口打开调用才能产生结果。版本 4 通过引入一个所谓的 复合操作 来简化了这个过程，它包含了很多文件系统对象操作。当然，这样做的直接影响是在网络上传输的 RPC 调用和数据会少很多，不过每个 RPC 调用所携带的数据都要比实际需要的数据要多。根据评估说明，NFSv3 RPC 调用所需要的次数是 NFSv4 复合 RPC 过程所需要的客户机－服务器交互次数的 5 倍。
RPC 变得已经不再那么重要，实际上它常被用作是封装在 NFSv4 堆栈中的很多操作的一个包装程序。这种变化还使得协议栈更少地依赖于底层的文件系统语义。但是这些变化并不意味着要忽视其他操作系统的文件系统操作：例如，Windows 共享就需要有状态的打开调用。有状态并不仅仅有助于进行流量分析，而且在文件系统语义中，可以更容易跟踪文件系统的操作。有状态的 打开调用让客户机可以对文件的数据和状态进行缓冲 —— 否则就必须在服务器上进行这种操作。在真实的世界中，Windows 客户机普遍存在，而 NFS 服务器可以与 Windows 无缝、透明地共享数据，因此花一些时间在 NFS 的配置上很值得。 |
