rfc2227.txt

中、英文RFC文档大全打包下载完全版 .

   This specification does not constrain how P3 divides up that
   allocation among itself and the other proxies.  For example, P3 could
   retain all of max-use allocation for itself.  In that case, it would
   forward the response to P1 and/or P2 with

       Meter: max-uses=0

   P3 might also divide the allocation equally among P1 and P2,
   retaining none for itself (which may be the right choice if P3 has
   few or no other clients).  In this case, it could send

       Meter: max-uses=5

   to the proxy (P1 or P2) that made the initial request, and then
   record in some internal data structure that it "owes" the other proxy
   the rest of the allocation.

   Note that this freedom to choose the max-uses value applies to the
   origin server, as well.  There is no requirement that an origin
   server send the same max-uses value to all caches.  For example, it
   might make sense to send "max-uses=2" the first time one hears from a
   cache, and then double the value (up to some maximum limit) each time
   one gets a "use-count" from that cache.  The idea is that the faster
   a cache is using up its max-use quota, the more likely it will be to
   report a use-count value before removing the cache entry.  Also, high
   and frequent use-counts imply a corresponding high efficiency benefit
   from allowing caching.

   Again, the details of such heuristics would be outside the scope of
   this specification.

4 Analysis

   This section includes informal analyses of several aspects of hit-
   metering:

      1. the accuracy of results when applied to counting users
         (section 4.1).

      2. the problem of counting users whose browsers do not
         include caches, such as Network Computers (section 4.2).



Mogul & Leach               Standards Track                    [Page 17]

RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      3. delays imposed on "critical paths" for HTTP operations
         (section 4.3).

4.1 Approximation accuracy for counting users

   For many (but not all) service operators, the single most important
   aspect of the request stream is the number of distinct users who have
   retrieved a particular entity within a given period (e.g., during a
   given day).  The hit-metering mechanism is designed to provide an
   origin server with an approximation of the number of users that
   reference a given resource.  The intent of the design is that the
   precision of this approximation is consistent with the goals of
   simplicity and optional implementation.

   Almost all Web users use client software that maintains local caches,
   and the state of the art of local-caching technology is quite
   effective.  (Section 4.2 discusses the case where end-client caches
   are small or non-existent.)  Therefore, assuming an effective and
   persistent end-client cache, each individual user who retrieves an
   entity does exactly one GET request that results in a 200 or 203
   response, or a 206 response that includes the first byte of the
   entity. If a proxy cache maintains and reports an accurate use-count
   of such retrievals, then its reported use-count will closely
   approximate the number of distinct users who have retrieved the
   entity.

   There are some circumstances under which this approximation can break
   down.  For example, if an entity stays in a proxy cache for much
   longer than it persists in the typical client cache, and users often
   re-reference the entity, then this scheme will tend to over-count the
   number of users. Or, if the cache-management policy implemented in
   typical client caches is biased against retaining certain kinds of
   frequently re-referenced entities (such as very large images), the
   use-counts reported will tend to overestimate the user-counts for
   such entities.

   Browser log analysis has shown that when a user revisits a resource,
   this is almost always done very soon after the previous visit, almost
   always with fewer than eight intervening references [11].  Although
   this result might not apply universally, it implies that almost all
   reuses will hit in the end-client cache, and will not be seen as
   unconditional GETs by a proxy cache.

   The existing (HTTP/1.0) "cache-busting" mechanisms for counting
   distinct users will certainly overestimate the number of users behind
   a proxy, since it provides no reliable way to distinguish between a
   user's initial request and subsequent repeat requests that might have
   been conditional GETs, had not cache-busting been employed.  The



Mogul & Leach               Standards Track                    [Page 18]

RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   "Cache-control: s-maxage=0" feature of HTTP/1.1 does allow the
   separation of use-counts and reuse-counts, provided that no HTTP/1.0
   proxy caches intervene.

   Note that if there is doubt about the validity of the results of
   hit-metering a given set of resources, the server can employ cache-
   busting techniques for short periods, to establish a baseline for
   validating the hit-metering results.  Various approaches to this
   problem are discussed in a paper by James Pitkow [9].

4.2 What about "Network Computers"?

   The analysis in section 4.1 assumed that "almost all Web users" have
   client caches.  If the Network Computers (NC) model becomes popular,
   however, then this assumption may be faulty: most proposed NCs have
   no disk storage, and relatively little RAM.  Many Personal Digital
   Assistants (PDAs), which sometimes have network access, have similar
   constraints.  Such client systems may do little or no caching of HTTP
   responses.  This means that a single user might well generate many
   unconditional GETs that yield the same response from a proxy cache.

   First note that the hit-metering design in this document, even with
   such clients, provides an approximation no worse than available with
   unmodified HTTP/1.1: the counts that a proxy would return to an
   origin server would represent exactly the number of requests that the
   proxy would forward to the server, if the server simply specifies
   "Cache-control:  s-maxage=0".

   However, it may be possible to improve the accuracy of these hit-
   counts by use of some heuristics at the proxy.  For example, the
   proxy might note the IP address of the client, and count only one GET
   per client address per response.  This is not perfect: for example,
   it fails to distinguish between NCs and certain other kinds of hosts.
   The proxy might also use the heuristic that only those clients that
   never send a conditional GET should be treated this way, although we
   are not at all certain that NCs will never send conditional GETs.

   Since the solution to this problem appears to require heuristics
   based on the actual behavior of NCs (or perhaps a new HTTP protocol
   feature that allows unambiguous detection of cacheless clients), it
   appears to be premature to specify a solution.

4.3 Critical-path delay analysis

   In systems (such as the Web) where latency is at issue, there is
   usually a tree of steps which depend on one another, in such a way
   that the final result cannot be accomplished until all of its
   predecessors have been.  Since the tree structure admits some



Mogul & Leach               Standards Track                    [Page 19]

RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   parallelism, it is not necessary to add up the timings for each step
   to discover the latency for the entire process.  But any single path
   through this dependency tree cannot be parallelized, and the longest
   such path is the one whose length (in units of seconds) determines
   the overall latency.  This is the "critical path", because no matter
   how much shorter one makes any other path, that cannot change the
   overall latency for the final result.

   If one views the final result, for a Web request, as rendering a page
   at a browser, or otherwise acting on the result of a request, clearly
   some network round trips (e.g., exchanging TCP SYN packets if the
   connection doesn't already exist) are on the critical path.  This
   hit-metering design does add some round-trips for reporting non-zero
   counts when a cache entry is removed, but, by design, these are off
   any critical path:  they may be done in parallel with any other
   operation, and require only "best efforts", so a proxy does not have
   to serialize other operations with their success or failure.

   Clearly, anything that changes network utilization (either increasing
   or decreasing it) can indirectly affect user-perceived latency.  Our
   expectation is that hit-metering, on average, will reduce loading and
   so even its indirect effects should not add network round-trips in
   any critical path.  But there might be a few specific instances where
   the added non-critical-path operations (specifically, usage reports
   upon cache-entry removal) delay an operation on a critical path.
   This is an unavoidable problem in datagram networks.

5 Specification

5.1 Specification of Meter header and directives

   The Meter general-header field is used to:

      - Negotiate the use of hit-metering and usage-limiting among
        origin servers and proxy caches.

      - Report use counts and reuse counts.

   Implementation of the Meter header is optional for both proxies and
   origin servers.  However, any proxy that transmits the Meter header
   in a request MUST implement every requirement of this specification,
   without exception or amendment.

   The Meter header MUST always be protected by a Connection header.  A
   proxy that does not implement the Meter header MUST NOT pass it
   through to another system (see section 5.5 for how a non-caching
   proxy may comply with this specification).  If a Meter header is




Mogul & Leach               Standards Track                    [Page 20]

RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   received in a message whose version is less than HTTP/1.1, it MUST be
   ignored (because it has clearly flowed through a proxy that does not
   implement Meter).

   A proxy that has received a response with a version less than
   HTTP/1.1, and therefore from a server (or another proxy) that does
   not implement the Meter header, SHOULD NOT send Meter request
   directives to that server, because these would simply waste
   bandwidth.  This recommendation does not apply if the proxy is
   currently hit-metering or usage-limiting any responses from that
   server.  If the proxy receives a HTTP/1.1 or higher response from
   such a server, it should cease its suppression of the Meter
   directives.

   All proxies sending the Meter header MUST adhere to the "metering
   subtree" design described in section 3.

       Meter = "Meter" ":" 0#meter-directive

       meter-directive = meter-request-directive
                       | meter-response-directive
                       | meter-report-directive

       meter-request-directive =
                         "will-report-and-limit"
                       | "wont-report"
                       | "wont-limit"

       meter-report-directive =
                       | "count" "=" 1*DIGIT "/" 1*DIGIT

       meter-response-directive =
                         "max-uses" "=" 1*DIGIT
                       | "max-reuses" "=" 1*DIGIT
                       | "do-report"
                       | "dont-report"
                       | "timeout" "=" 1*DIGIT
                       | "wont-ask"

   A meter-request-directive or meter-report-directive may only appear
   in an HTTP request message.  A meter-response-directive may only
   appear in an HTTP response directive.

   An empty Meter header in a request means "Meter: will-report-and-
   limit".  An empty Meter header in a response, or any other response
   including one or more Meter headers without the "dont-report" or
   "wont-ask" directive, implies "Meter:  do-report".




Mogul & Leach               Standards Track                    [Page 21]

RFC 2227            Hit-Metering and Usage-Limiting         October 1997


   The meaning of the meter-request-directives are as follows:

   will-report-and-limit
                   indicates that the proxy is willing and able to
                   return usage reports and will obey any usage-limits.

   wont-report     indicates that the proxy will obey usage-limits but
                   will not send usage reports.

   wont-limit      indicates that the proxy will not obey usage-limits
                   but will send usage reports.

   A proxy willing neither to obey usage-limits nor to send usage
   reports MUST NOT transmit a Meter header in the request.

   The meaning of the meter-report-directives are as follows:

   count "=" 1*DIGIT "/" 1*DIGIT
                   Both digit strings encode decimal integers.  The
                   first integer indicates the count of uses of the
                   cache entry since the last report; the second integer
                   indicates the count of reuses of the entry.

   Section 5.3 specifies the counting rules.

   The meaning of the meter-response-directives are as follows:

   max-uses "=" 1*DIGIT
                   sets an upper limit on the number of "uses" of the
                   response, not counting its immediate forwarding to