Frame12（如图10-22所示）：NFS客户端发起一个SetAttr Call的请求，这个请求的目的是为了改变文件属性。可以看到客户端请求将文件的atime和mtime改为服务端当前的系统时间。
图10-22 客户端的SetAttr请求
Frame13（如图10-23所示）：对Frame12的回应。可以看到atime、ctime在之前和之后的不同，当然，时间差别都在微妙级，因为这一连串的请求其实是在很短的时间里发出去并得到应答的。
图10-23 针对SetAttr请求的回应
Frame15（如图10-24所示）：由于在客户端执行了“rm a”的命令，所以客户端发起一个对/mnt目录的访问请求。其实客户端在抓包期间一直处于/mnt目录中，至于为何要重新发起Access请求，与具体应用程序的代码有关，可能开发者为了确认/mnt目录的DH值没有过期，所以重新试探访问。
图10-24 客户端针对/mnt目录的Access请求
Frame16（如图10-25所示）：NFS服务端对Frame15的回应。
图10-25 针对Access请求的回应
Frame18（如图10-26所示）：此时，客户端由于输入了“rm a”命令，所以客户端首先要查询一下文件“a”的权限，因此客户端发起一个GetAttr的请求来查询文件“a”的权限。
图10-26 客户端的GetAttr请求
Frame19（如图10-27所示）：NFS服务端对Frame18的回应。
图10-27 针对GetAttr请求的回应
Frame20（如图10-28所示）：NFS客户端发起对文件“a”的Access请求。至于为何在删除文件之前要发起Access请求，与编码习惯有关。
图10-28 客户端的Access请求
Frame21（如图10-29所示）：NFS服务端对Frame20的回应。
图10-29 针对Access请求的回应
Frame23（如图10-30所示）：NFS客户端发起Remove请求。可以看到Remove请求中并没有使用FH，而是直接使用了文件名。
图10-30 客户端的Remove请求
Frame24（如图10-31所示）：NFS服务端对Frame23的回应。
图10-31 针对Remove请求的回应
可以看到，基于NAS的数据访问，客户端并不关心文件存放在磁盘的哪些扇区，这些逻辑全部由NAS服务端处理，客户端向NAS设备发送的只有各种文件操作请求以及实际的文件流式数据。大家可以在本书12.4节看到有关ISCSI的抓包分析，可以作一下对比，两者交互的语言完全不同。
购买
在线阅读
需求中心
AI助手
联系我们
返回顶部