【理论课程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的标志。