rfc2054.txt

RFC 的详细文档！

Network Working Group                                       B. Callaghan
Request for Comments: 2054                        Sun Microsystems, Inc.
Category: Informational                                     October 1996


                      WebNFS Client Specification

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document describes a lightweight binding mechanism that allows
   NFS clients to obtain service from WebNFS-enabled servers with a
   minimum of protocol overhead.  In removing this overhead, WebNFS
   clients see benefits in faster response to requests, easy transit of
   packet filter firewalls and TCP-based proxies, and better server
   scalability.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
   2.    TCP vs UDP . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.    Well-known Port  . . . . . . . . . . . . . . . . . . . . . 2
   4.    NFS Version 3  . . . . . . . . . . . . . . . . . . . . . . 3
   4.1     Transfer Size  . . . . . . . . . . . . . . . . . . . . . 3
   4.2     Fast Writes  . . . . . . . . . . . . . . . . . . . . . . 4
   4.3     READDIRPLUS  . . . . . . . . . . . . . . . . . . . . . . 4
   5.    Public Filehandle  . . . . . . . . . . . . . . . . . . . . 5
   5.1     NFS Version 2 Public Filehandle  . . . . . . . . . . . . 5
   5.2     NFS Version 3 Public Filehandle  . . . . . . . . . . . . 5
   6.    Multi-component Lookup . . . . . . . . . . . . . . . . . . 6
   6.1     Canonical Path vs. Native Path . . . . . . . . . . . . . 6
   6.2     Symbolic Links . . . . . . . . . . . . . . . . . . . . . 7
   6.2.1     Absolute Link  . . . . . . . . . . . . . . . . . . . . 8
   6.2.2     Relative Link  . . . . . . . . . . . . . . . . . . . . 8
   6.3     Filesystem Spanning Pathnames  . . . . . . . . . . . . . 9
   7.    Contacting the Server  . . . . . . . . . . . . . . . . . . 9
   8.    Mount Protocol . . . . . . . . . . . . . . . . . . . . . . 11
   9.    Exploiting Concurrency . . . . . . . . . . . . . . . . . . 12
   9.1     Read-ahead . . . . . . . . . . . . . . . . . . . . . . . 12
   9.2     Concurrent File Download . . . . . . . . . . . . . . . . 13
   10.   Timeout and Retransmission . . . . . . . . . . . . . . . . 13
   11.   Bibliography . . . . . . . . . . . . . . . . . . . . . . . 15
   12.   Security Considerations  . . . . . . . . . . . . . . . . . 16



Callaghan                    Informational                      [Page 1]

RFC 2054              WebNFS Client Specification           October 1996


   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16
   14.   Author's Address . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction

   The NFS protocol provides access to shared filesystems across
   networks.  It is designed to be machine, operating system, network
   architecture, and transport protocol independent.  The protocol
   currently exists in two versions: version 2 [RFC1094] and version 3
   [RFC1813], both built on Sun RPC [RFC1831] at its associated eXternal
   Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].

   WebNFS provides additional semantics that can be applied to NFS
   version 2 and 3 to eliminate the overhead of PORTMAP and MOUNT
   protocols, make the protocol easier to use where firewall transit is
   required, and reduce the number of LOOKUP requests required to
   identify a particular file on the server. WebNFS server requirements
   are described in RFC 2055.

2. TCP vs UDP

   The NFS protocol is most well known for its use of UDP which performs
   acceptably on local area networks.  However, on wide area networks
   with error prone, high-latency connections and bandwidth contention,
   TCP is well respected for its congestion control and superior error
   handling.  A growing number of NFS implementations now support the
   NFS protocol over TCP connections.

   Use of NFS version 3 is particularly well matched to the use of TCP
   as a transport protocol.  Version 3 removes the arbitrary 8k transfer
   size limit of version 2, allowing the READ or WRITE of very large
   streams of data over a TCP connection.  Note that NFS version 2 is
   also supported on TCP connections, though the benefits of TCP data
   streaming will not be as great.

   A WebNFS client must first attempt to connect to its server with a
   TCP connection.  If the server refuses the connection, the client
   should attempt to use UDP.

3. Well-known Port

   While Internet protocols are generally identified by registered port
   number assignments, RPC based protocols register a 32 bit program
   number and a dynamically assigned port with the portmap service which
   is registered on the well-known port 111.  Since the NFS protocol is
   RPC-based, NFS servers register their port assignment with the
   portmap service.




Callaghan                    Informational                      [Page 2]

RFC 2054              WebNFS Client Specification           October 1996


   NFS servers are constrained by a requirement to re-register at the
   same port after a server crash and recovery so that clients can
   recover simply by retransmitting an RPC request until a response is
   received.  This is simpler than the alternative of having the client
   repeatedly check with the portmap service for a new port assignment.
   NFS servers typically achieve this port invariance by registering a
   constant port assignment, 2049, for both UDP and TCP.

   To avoid the overhead of contacting the server's portmap service, and
   to facilitate transit through packet filtering firewalls, WebNFS
   clients optimistically assume that WebNFS servers register on port
   2049.  Most NFS servers use this port assignment already, so this
   client optimism is well justified. Refer to section 8 for further
   details on port binding.

4. NFS Version 3

   NFS version 3 corrects deficiencies in version 2 of the protocol as
   well as providing a number of features suitable to WebNFS clients
   accessing servers over high-latency, low-bandwidth connections.

4.1 Transfer Size

   NFS version 2 limited the amount of data in a single request or reply
   to 8 kilobytes.  This limit was based on what was then considered a
   reasonable upper bound on the amount of data that could be
   transmitted in a UDP datagram across an Ethernet.  The 8k transfer
   size limitation affects READ, WRITE, and READDIR requests. When using
   version 2, a WebNFS client must not transmit any request that exceeds
   the 8k transfer size.  Additionally, the client must be able to
   adjust its requests to suit servers that limit transfer sizes to
   values smaller than 8k.

   NFS version 3 removes the 8k limit, allowing the client and server to
   negotiate whatever limit they choose.  Larger transfer sizes are
   preferred since they require fewer READ or WRITE requests to transfer
   a given amount of data and utilize a TCP stream more efficiently.

   While the client can use the FSINFO procedure to request the server's
   maximum and preferred transfer sizes, in the interests of keeping the
   number of NFS requests to a minimum, WebNFS clients should
   optimistically choose a transfer size and make corrections if
   necessary based on the server's response.

   For instance, given that the file attributes returned with the
   filehandle from a LOOKUP request indicate that the file has a size of
   50k, the client might transmit a READ request for 50k.  If the server
   returns only 32k, then the client can assume that the server's



Callaghan                    Informational                      [Page 3]

RFC 2054              WebNFS Client Specification           October 1996


   maximum transfer size is 32k and issue another read request for the
   remaining data.  The server will indicate positively when the end of
   file is reached.

   A similar strategy can be used when writing to a file on the server,
   though the client should be more conservative in choosing write
   request sizes so as to avoid transmitting large amounts of data that
   the server cannot handle.

4.2 Fast Writes

   NFS version 2 requires the server to write client data to stable
   storage before responding to the client.  This avoids the possibility
   of the the server crashing and losing the client's data after a
   positive response.  While this requirement protects the client from
   data loss, it requires that the server direct client write requests
   directly to the disk, or to buffer client data in expensive non-
   volatile memory (NVRAM).  Either way, the effect is poor write
   performance, either through inefficient synchronous writes to the
   disk or through the limited buffering available in NVRAM.

   NFS version 3 provides clients with the option of having the server
   buffer a series of WRITE requests in unstable storage.  A subsequent
   COMMIT request from the client will have the server flush the data to
   stable storage and have the client verify that the server lost none
   of the data.  Since fast writes benefit both the client and the
   server, WebNFS clients should use WRITE/COMMIT when writing to the
   server.

4.3 READDIRPLUS

   The NFS version 2 READDIR procedure is also supported in version 3.
   READDIR returns the names of the entries in a directory along with
   their fileids.  Browser programs that display directory contents as a
   list will usually display more than just the filename; a different
   icon may be displayed if the entry is a directory or a file.
   Similarly, the browser may display the file size, and date of last
   modification.

   Since this additional information is not returned by READDIR, version
   2 clients must issue a series of LOOKUP requests, one per directory
   member, to retrieve the attribute data.  Clearly this is an expensive
   operation where the directory is large (perhaps several hundred
   entries) and the network latency is high.

   The version 3 READDIRPLUS request allows the client to retrieve not
   only the names of the directory entries, but also their file
   attributes and filehandles in a single call.  WebNFS clients that



Callaghan                    Informational                      [Page 4]

RFC 2054              WebNFS Client Specification           October 1996


   require attribute information for directory entries should use
   READDIRPLUS in preference to READDIR.

5. Public Filehandle

   NFS filehandles are normally created by the server and used to
   identify uniquely a particular file or directory on the server.  The
   client does not normally create filehandles or have any knowledge of
   the contents of a filehandle.

   The public filehandle is an an exception.  It is an NFS filehandle
   with a reserved value and special semantics that allow an initial
   filehandle to be obtained.  A WebNFS client can use the public
   filehandle as an initial filehandle rather than using the MOUNT
   protocol.  Since NFS version 2 and version 3 have different
   filehandle formats, the public filehandle is defined differently for
   each.

   The public filehandle is a zero filehandle.  For NFS version 2 this
   is a filehandle with 32 zero octets.  A version 3 public filehandle
   has zero length.

5.1 NFS Version 2 Public Filehandle

   A version 2 filehandle is defined in RFC 1094 as an opaque value
   occupying 32 octets.  A version 2 public filehandle has a zero in
   each octet, i.e. all zeros.

    1                                                             32
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 NFS Version 3 Public Filehandle

   A version 3 filehandle is defined in RFC 1813 as a variable length
   opaque value occupying up to 64 octets.  The length of the filehandle
   is indicated by an integer value contained in a 4 octet value which
   describes the number of valid octets that follow. A version 3 public
   filehandle has a length of zero.

   +-+-+-+-+
   |   0   |
   +-+-+-+-+







Callaghan                    Informational                      [Page 5]

RFC 2054              WebNFS Client Specification           October 1996


6. Multi-component Lookup

   Normally the NFS LOOKUP request (version 2 or 3) takes a directory
   filehandle along with the name of a directory member, and returns the
   filehandle of the directory member.  If a client needs to evaluate a
   pathname that contains a sequence of components, then beginning with
   the directory filehandle of the first component it must issue a
   series of LOOKUP requests one component at a time.  For instance,
   evaluation of the Unix path  "a/b/c" will generate separate LOOKUP
   requests for each component of the pathname "a", "b", and "c".

   A LOOKUP request that uses the public filehandle can provide a
   pathname containing multiple components.  The server is expected to
   evaluate the entire pathname and return a filehandle for the final