Frame2（如图10-13所示）：为NFS服务端对Frame1的回应。通过ERR_NOENT可以判断出当前目录并没有名为 a的文件。
图10-13 Lookup请求的回应
Frame4（如图10-14所示）：客户端随即发起了“Create Call”，创建“a”文件。
图10-14 客户端的Create请求
Frame5（如图10-15所示）：NFS服务端对客户端Frame4的回应。创建成功，服务端返回File Handle（FH）的hash值为0xf03ce91c。FH与DH一样，在数据包中实际上也为一个32字节长的字段。为了表示方便，抓包软件将其hash成一个4字节的值。随后的交互中客户端不会用文件名来向服务端请求操作，而全部用这个File Handle来指代。
图10-15 Create请求的回应
Frame6（如图10-16所示）：文件“a”创建成功之后，出于保险起见，应用程序一般都会紧接着查询一下文件属性，顺便确认文件是否创建成功。“GetAttr Call”就是用来查询文件属性用的一种RPC call。从图中可以看到对应的FH值为0xf03ce91c，NFS服务端收到这个值就会自动对应成文件“a”。
图10-16 客户端的GetAttr请求
Frame7（如图10-17所示）：NFS服务端对Frame6的回应。包中可以看到文件的umask访问权限以及atime、mtime、ctime属性。
图10-17 GetAttr请求的回应
Frame8（如图10-18所示）：紧接着NFS客户端发起了一个查询/mnt目录属性的请求。因为Handle的值为0x98f8d6bb，所以可以判断这个GetAttr Call是针对/mnt目录的。
图10-18 客户端针对/mnt目录的GetAttr请求
Frame9（如图10-19所示）：NFS服务端对Frame8的回应。
图10-19 针对GetAttr请求的回应
Frame10（如图10-20所示）：NFS客户端发起一个在/mnt目录中查找文件“a”的请求。这里由于是查找操作，客户端会假设不知道“a”文件的FH值，而只知道/mnt目录的DH值，所以文件名“a”使用的就是ASCII码的“a”。
图10-20 客户端的Lookup请求
Frame11（如图10-21所示）：NFS服务端根据Frame10中请求的回应找到这个文件，FH值是0xf03ce91c。
图10-21 针对Lookup请求的回应
购买
在线阅读
需求中心
AI助手
联系我们
返回顶部