網絡文件系統

網絡文件系統（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 調用之間的任何文件信息。 所以它是無狀態的。

執行查找調用而不是打開。 這將返回一個文件“句柄”，其中包含服務器上大容量存儲設備的索引節點號和設備號。 通過這個句柄可以在服務器上唯一標識一個文件。 在 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 現在可用于唯一標識 cs.example.net 域中所有計算機上的用戶，即使用戶 user 在服務器上具有 Unix 用戶 ID 1050，例如 B. 1100。如果不保持一致的用戶編號，這會導致早期 NFS 版本出現問題。 例如，Linux 下的 rpc.idmapd（ID 映射器守護進程）服務和 FreeBSD 下的 nfsuserd（NFS 用戶守護進程）守護進程負責將新的 NFS 用戶名轉換為（Unix）用戶 ID（用于服務器端和客戶端） ). 僅當服務器和客戶端具有相同的域時，用戶名才能正確分配，否則 nobody.nogroup 被指定為所有者。

由于某些文件系統不允許有效實現唯一文件句柄，因此引入了僅在一定時間內可用的臨時句柄。 在 Unix 下，您可以輕松地從設備和 編號構造句柄。 現在支持不區分大小寫的文件系統和自定義文件屬性。