第一十零章 三足鼎立——DAS、SAN 和NAS

 

    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请求的回应