【理論課程FTP協議與NFS協議】
實驗目的
1、NFS協議的應用范圍
？？文件讀寫的時候？
2、NFS掛載操作的原理
整個協議，與文件的讀寫有什么關聯？？
3、NFS的安全機制
NFS的安全機制到底是啥？？
SSL這種原理有借鑒之處嗎？ 如果有，效率是如何保障的？
4、NFS讀寫操作的原理
讀？寫操作會有什么不一樣？一樣？
5、學習使用Wireshark分析NFS的方法
【請忽略以上腦殘問題！O(∩_∩)O哈哈~】
實驗環境
操作機：Windows XP
實驗工具
wireshark
學習NFS協議的掛載
這里我們結合着Wireshark來分析一下NFS協議數據，來學習一下它的掛載過程、安全機制以及讀寫過程，以直觀的方式進行學習。首先分析一下協議的掛載時所捕獲的數據包：
上圖中，IP地址為10.32.106.159是客戶端，10.32.106.62則為服務器端，我們逐條分析一下每個數據包：
1、客戶端想連接服務器的NFS進程，於是詢問應該使用哪個端口（GETPORT）。“Replay In 2”，說明2號數據包就是對於這個數據包的回應。
2、服務器回應客戶端：NFS端口是2049（隨機端口）。“Call In 1”說明這是對1號數據包的回應。
3、客戶端嘗試連接服務器的NFS進程、判斷2049端口是否被防火牆攔截、NFS服務是否已經開啟。
4、服務器回應：我已收到請求，你可以連接我了。
5、客戶端想連接服務器的mount服務，詢問該服務的端口。但由於mount端口是隨機生成的，因此客戶端需要先進行詢問。
6、服務器回應：我的mount服務端口是1234.
7、客戶端嘗試連接mount進程、判斷1234端口是否被防火牆攔截、mount服務是否已經開啟。
8、服務器響應請求：你可以連接我了。
9、客戶端提出要求，請求掛載（MNT）”/code”這個共享目錄。NFS主要提供了 /code、/document這兩個共享目錄，分貝被掛載到多台客戶端的本地目錄上。 當用戶在這些本地目錄進行文件的讀寫時，實際上實在NFS的服務器上進行。
10、服務器同意了客戶端的請求，服務器端要求客戶端使用file handle 0x75a18429進行目錄的訪問 (查看wireshark的封包詳情)。
11、客戶端嘗試服務器端的NFS進程是否能連接上。
12、服務器回應可以連接。其實【11、12】完全沒有必要，因為NFS一直處理連接的狀態。
13、客戶端要求查看文件句柄為0x75a18429的文件的屬性。
14、服務器端為客戶端提供了該文件系統的大小和空間使用率等屬性，之后就可以在客戶端看到這些信息了。
15、客戶端要求查看文件句柄為0x75a18429的文件屬性。
16、服務器為客戶端提供該文件的屬性。
利用portmap請求沒有得到回復，這就說明很可能是防火牆相對端口進行了攔截；如果發現mount請求服務被拒絕，可以考慮檢查共享目錄的權限設置。
了解NFS的安全機制
NFS的安全機制主要包括對客戶端的訪問控制及對用戶的權限控制。
a. 客戶端的訪問控制：通過IP地址實現。創建關鍵共享目錄時可以指定哪些IP允許讀寫，哪些IP只允許讀操作，哪些IP不給予任何權限。
b. 客戶端的訪問控制：下面借助試驗來理解，試驗場景【一個客戶端上的用戶admin在/code目錄里新建了一個名為abc.txt 的文件，該文件的owner正常顯示為admin。但是在另一台客戶端上查看該文件時，owner卻變成了nasadmin.】
我們關注一下第4個數據包。從上圖中的Credentials中可以看到，用戶在創建文件時並沒有使用admin這個用戶名，而是使用了admin的UID 501來代表自己的身份。而NFS協議是只認UID不認用戶名的。當admin通過客戶端創建了一個文件，那么UID 501就會被寫到文件里面，成為了owner的信息。而當另一個客戶端上的用戶查看該文件的屬性時，看到的就是UID 501。但是不同的客戶端上UID值與其所對應的名稱往往是不一致的。因此創建文件的客戶端的UID 501表示的就是admin，但是換了客戶端，UID就對應着nasadmin了。那么為了防止這樣的問題，需要大家在實際的操作中，保證每個客戶端的UID與用戶名的映射是一致的。
了解NFS的讀文件過程
篩選出NFS協議，研究NFS協議讀取文件abc.txt的過程：
1、 客戶端向服務器詢問：我可以ACCESS為0x75a18429嗎【也就是進入/code】？
2、服務器端回應：允許進入。
3、客戶端想要查看這個目錄里的文件和文件的句柄。
4、服務器回應：客戶端索要的信息【在wireshark封包詳情中查看】。
可見abc.txt的file handle為0x056560e1。
5、客戶端詢問file handle為0x056560e1的文件屬性是什么。
6、服務器回應了該文件的權限、UID、GID以及文件的大小等信息。
7、客戶端詢問是否可以打開file handle為0x056560e1的文件。
8、服務器同意了請求，並給予了相應的權限。
9、從0x056560e1的偏移量為0的位置，也就是abc.txt文件的開頭位置，讀取（READ）131072字節的數據。
10、從0x056560e1的偏移量為131072的位置，再讀取131072字節的數據。
148、服務器回應客戶端，允許讀取131072字節的數據。
288、同上。
這樣，NFS就完成了文件的讀操作。
了解NFS的寫文件操作
將名為abc.txt的文件寫入NFS共享文件夾的過程。首先依舊加入篩選條件nfs：
1、客戶端向服務器發出請求，要求進入0x75a18429，也就是/code目錄。
2、服務器接受請求。
4、客戶端詢問服務器，查找（LOOKUP）名為abc.txt的文件。因為在創建一個文件之前，需要首先檢查一下是否有同名文件的存在。如果不存在同名文件，才能夠繼續寫入，否則要詢問用戶是否覆蓋原文件。
5、服務器回應沒有這個文件。
6、客戶端要求創建（CREATE）一個名為abc.txt的文件。
7、服務器答應了請求。在wireshark封包詳情s面板中展開就可以找到文件的file handle為0x056560e1。
69、客戶端要求從0x056560e1的偏移為0的位置，也就是abc.txt文件的開頭，寫入（WRITE）131072個字節。
104、服務器回應：我已經寫完了。
130、客戶端要求從0x056560e1的偏移為131072的位置，即abc.txt文件的開頭，寫入（WRITE）131072個字節。接下來的兩個數據包同理。
302、服務器回復已經寫入。下面兩個數據包同理。
306、客戶端詢問，剛才所寫的數據是否已經存盤，也就是COMMIT操作，只有經過COMMIT過的數據才算是真正的寫好了。
307、服務器回應都保存好了。
308、客戶端要求查看剛才所寫入的文件的屬性（GETATTR）。
309、服務器將文件的權限、UID、GID以及文件的大小等信息交給客戶端。
由這個例子可以發現，寫操作是多個WRITE Call連續發送過去的。其實我們剛才的讀文件的操作也是如此。同時將多個請求一起發出，接下來等待回應的這種方法，比發一條回復一條，發一條回復一條的方式要更加有效率。特別是在高帶寬高延遲的情況下，NFS的這種讀寫特性的優勢就會非常的明顯。對於寫操作而言，如果我們在掛載的時候沒有指定任何參數，那么就會采用默認的async（異步）寫的方式。而與之相對應的是sync（同步）方式。如果在掛載時指定了sync參數，那么客戶端就會先發送一個WRITE Call，等到收到Reply之后再發送下一個請求，也就是說，請求和回應是交替出現的。對於我們這個捕獲文件而言，由於采用的是默認掛載方式，所以數據包的WRITE操作會有一個UNSTABLE，表示的是異步的方式。如果是同步方式，則會出現FILE_SYNC的標志。