网络文件系统

网络文件系统（NFS，也称为网络文件服务）- 是由 Sun Microsystems 开发的一种协议，允许通过网络访问文件。 这些文件不像例如使用 FTP，但用户可以访问位于远程计算机上的文件，就像它们存储在本地硬盘上一样。

这个 Unix 网络协议是一个 Internet 标准（RFC 1094、RFC 1813、RFC 3530、RFC 7530），也被称为分布式文件系统。

NFS 的等价物在 Windows 和 OS/2 环境中称为服务器消息块 (SMB)。SMB 对用户进行身份验证，而更流行的 NFSv3 对客户端机器进行身份验证，只有 NFSv4 启用用户身份验证。 NFS 服务也可用于 Microsoft Windows 服务器，允许 UNIX 工作站访问其文件，但混合环境大多在 Unix 端使用 SMB 和 Samba。

NFS 最初与无状态 UDP 一起工作在 IP 网络协议上。 同时，还有基于 TCP 的 NFS。 NFSv4 只与 TCP 一起工作，并且只需要一个端口（2049），这样更容易穿过防火墙进行操作。 NFSv4 主要由 IETF 在 Sun 放弃开发后开发。

旧的无状态 NFS 的 NFS 通信的基本顺序，直到并包括版本 3，如下所述。 场景：客户端计算机的用户想要打开一个远程目录（/directory）并显示其中的一个文件（test）。

为了在 NFS 服务器和客户端之间交换数据，必须启动 NFS 服务器并向端口映射程序注册。

• 客户端在端口 111 上联系端口映射器并请求挂载守护程序 (mountd) 的端口
• Portmapper 为 mountd 发布端口号。 通常为 694。
• 客户端联系 mountd 并请求 /directory 的文件句柄，这是客户端要挂载的服务器目录。
• mountd 返回一个文件句柄 0 作为要挂载的服务器目录的根文件句柄
• 客户端联系端口映射器并请求 NFS (nfsd) 的端口。 通常为 2049。
• Portmapper 为 nfsd 发布端口号
• 客户端使用参数文件句柄 0 和文件名（测试）执行 LOOKUP 过程
• nfsd 发布文件句柄 1（测试）
• Client 使用参数 Filehandle 1 执行 READ 过程
• nfsd 返回文件内容（测试）（数据）

程序通过系统调用访问文件系统。 在 Unix 上，最重要的系统调用是：

• 打开、关闭 - 打开和关闭文件
• 读，写——读和写
• 创建、取消链接 - 创建和删除
• mkdir、rmdir - 创建和删除目录
• readdir - 读取目录条目

网络文件系统必须将这些调用打包成网络数据包并将它们发送到服务器。 然后用适当的信息或错误进行响应。

Sun Microsystems 开发人员最初决定采用远程过程调用模型。 XDR 将 RPC 的参数转换为与机器无关的格式，然后通过 RPC 机制将访问视为正常的子程序调用。

但是，系统调用不会直接转换为 RPC 调用，因为用 open 打开的文件也必须在服务器上打开。 对于许多客户端，服务器很快就会超载，因为在 20 世纪 80 年代中期，机器的内存仍然相对较少。 服务器的任务因此保持尽可能简单，服务器不会记住两次 RPC 调用之间的任何文件信息。 所以它是无状态的。

执行查找调用而不是打开。 这将返回一个文件“句柄”，其中包含服务器上大容量存储设备的索引节点号和设备号。 通过这个句柄可以在服务器上xxx标识一个文件。 在 Unix 下，通过这两个数字可以高效、清晰地获取文件信息，而无需费时的搜索。

后续调用（如读取或写入）必须始终传输偏移量，以便服务器也可以在不知道先前操作的情况下传递所需的信息。

该协议的其他属性是

• 目录信息和文件属性的缓存时间很短（几秒钟）
• 没有数据缓存
• 使用无连接用户数据报协议 (UDP) 可选 TCP（仅限 NFSv4 TCP）
• Lock 和 M通过额外的辅助协议计数操作
• 使用 Unix 文件属性（例如 user-uid）

由于设计简单，NFS 在正常环境下运行良好：

• 响应时间短的本地网络
• 在本地网络上运行程序
• 正常用户活动（编辑、编译程序）
• 内存相对较少的服务器

行为不太好

• 文件共享
• 通过互联网使用（响应时间长，安全性差）
• 使用防火墙（UDP，由于端口映射器而没有固定端口）（在 NFSv4 下不再是问题；所有通信都通过端口 2049/TCP 运行）

该协议是在 20 世纪 80 年代后期制定的。 当时，即使是昂贵的工作站也只有几兆字节的 RAM，通常约为 4 到 8 MiB。 由于设计原因，NFS 服务器仍然可以在此类机器上高效运行。

因为服务器是无状态的，所以可以在不丢失数据的情况下关闭和重启。 程序不会崩溃，用户只需等待服务器恢复即可。

工作计算机（工作站）可以通过NFS在没有硬盘的情况下运行，操作系统和运行参数可以通过BOOTP、TFTP等协议加载。 一个特殊的内核（例如 Linux）已经可以通过 NFS 访问 Unix 下的根驱动器。 Sun 在 1990 年代提供了特殊的无盘工作站（diskless workstations）。

好处包括减少维护、共享存储空间以及更简单、更便宜的客户端工作站（瘦客户端）。 然而，对于许多客户端，服务器负载很重，并且在大多数情况下通过网络访问速度较慢。

Sun 和其他公司也在 1990 年代为运行 Windows 的 PC 提供了 NFS 客户端软件，称为 PC-NFS。 服务器仍然必须是 Unix 工作站。 在 Windows for Workgroups 之前，Windows 上的网络访问不是操作系统的一部分。 这使得在 Unix 环境中使用 PC 变得更加容易。

PC-NFS 不得不与 DOS/Windows 系统的不同概念作斗争。 当时的 Windows 版本只允许最多八个字符的文件名和一个由句点分隔的三个字符的扩展名（例如 AUTOEXEC.BAT，即所谓的 8.3 表示法），而 Unix 允许 255 个字符的路径名。 与 DOS 不同，文件名区分大小写。 所以 PC-NFS 必须在文件名概念之间进行转换。

Unix 文件名 file.txt 在 Windows/DOS 上显示为 FILE.TXT，而文件名 documentation.txt 被翻译成类似 DOKUME~1.TXT 的形式。

NFS 版本 4 代表了一种新的实现，它考虑了更新的要求。 它在 RFC 7530 中被标准化。

尽可能减少早期版本的 Unix-heavy 特性。 UNIX 用户和组号被替换为更独特的 user@domain 字符串。 user 是服务器上的用户名，domain 是服务器的域，即主机名中不标识服务器本身的部分（srv.cs.example.net → cs.example.net）。 标识符 user@cs.example.net 现在可用于xxx标识 cs.example.net 域中所有计算机上的用户，即使用户 user 在服务器上具有 Unix 用户 ID 1050，例如 B. 1100。如果不保持一致的用户编号，这会导致早期 NFS 版本出现问题。 例如，Linux 下的 rpc.idmapd（ID 映射器守护进程）服务和 FreeBSD 下的 nfsuserd（NFS 用户守护进程）守护进程负责将新的 NFS 用户名转换为（Unix）用户 ID（用于服务器端和客户端） ). 仅当服务器和客户端具有相同的域时，用户名才能正确分配，否则 nobody.nogroup 被指定为所有者。

由于某些文件系统不允许有效实现xxx文件句柄，因此引入了仅在一定时间内可用的临时句柄。 在 Unix 下，您可以轻松地从设备和 inode 编号构造句柄。 现在支持不区分大小写的文件系统和自定义文件属性。