Ignore:
Timestamp:
Aug 19, 2012, 11:04:26 PM (7 years ago)
Author:
fielding@…
Message:

start the plow through connection management

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1836 r1837  
    293293   <x:dfn>messages</x:dfn> (<xref target="http.message"/>) across a reliable
    294294   transport or session-layer
    295    "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a
    296    program that establishes a connection to a server for the purpose of
    297    sending one or more HTTP requests.  An HTTP "<x:dfn>server</x:dfn>" is a
    298    program that accepts connections in order to service HTTP requests by
    299    sending HTTP responses.
     295   "<x:dfn>connection</x:dfn>" (<xref target="connection.management"/>).
     296   An HTTP "<x:dfn>client</x:dfn>" is a program that establishes a connection
     297   to a server for the purpose of sending one or more HTTP requests.
     298   An HTTP "<x:dfn>server</x:dfn>" is a program that accepts connections
     299   in order to service HTTP requests by sending HTTP responses.
    300300</t>
    301301<iref primary="true" item="user agent"/>
    … …  
    363363   a message body containing the payload body (if any,
    364364   <xref target="message.body"/>).
     365</t>
     366<t>
     367   A connection might be used for multiple request/response exchanges,
     368   as defined in <xref target="persistent.connections"/>.
    365369</t>
    366370<t>
    … …  
    424428   before proceeding can me met via advance configuration choices,
    425429   run-time options, or simply not proceeding with the unsafe action.
    426 </t>
    427 </section>
    428 
    429 <section title="Connections and Transport Independence" anchor="transport-independence">
    430 <t>
    431    HTTP messaging is independent of the underlying transport or
    432    session-layer connection protocol(s).  HTTP only presumes a reliable
    433    transport with in-order delivery of requests and the corresponding
    434    in-order delivery of responses.  The mapping of HTTP request and
    435    response structures onto the data units of the underlying transport
    436    protocol is outside the scope of this specification.
    437 </t>
    438 <t>
    439    The specific connection protocols to be used for an interaction
    440    are determined by client configuration and the target URI
    441    (<xref target="target-resource"/>).
    442    For example, the "http" URI scheme
    443    (<xref target="http.uri"/>) indicates a default connection of TCP
    444    over IP, with a default TCP port of 80, but the client might be
    445    configured to use a proxy via some other connection port or protocol
    446    instead of using the defaults.
    447 </t>
    448 <t>
    449    A connection might be used for multiple HTTP request/response exchanges,
    450    as defined in <xref target="persistent.connections"/>.
    451430</t>
    452431</section>
    … …  
    21332112  <iref primary="true" item="target resource"/>
    21342113  <iref primary="true" item="target URI"/>
     2114  <x:anchor-alias value="target resource"/>
     2115  <x:anchor-alias value="target URI"/>
    21352116<t>
    21362117   HTTP is used in a wide variety of applications, ranging from
    … …  
    21872168   "https" (<xref target="https.uri"/>) schemes.
    21882169</t>
     2170<t>
     2171   HTTP requirements regarding connection management are defined in
     2172   <xref target="connection.management"/>.
     2173</t>
    21892174</section>
    21902175
    21912176<section title="Request Target" anchor="request-target">
    21922177<t>
    2193    Once an inbound connection is obtained
    2194    (<xref target="connection.management"/>),
     2178   Once an inbound connection is obtained,
    21952179   the client sends an HTTP request message (<xref target="http.message"/>)
    21962180   with a request-target derived from the target URI.
    … …  
    26632647
    26642648<section title="Connection Management" anchor="connection.management">
     2649<t>
     2650   HTTP messaging is independent of the underlying transport or
     2651   session-layer connection protocol(s).  HTTP only presumes a reliable
     2652   transport with in-order delivery of requests and the corresponding
     2653   in-order delivery of responses.  The mapping of HTTP request and
     2654   response structures onto the data units of an underlying transport
     2655   protocol is outside the scope of this specification.
     2656</t>
     2657<t>
     2658   As described in <xref target="connecting.inbound"/>, the specific
     2659   connection protocols to be used for an HTTP interaction are determined by
     2660   client configuration and the <x:ref>target URI</x:ref>.
     2661   For example, the "http" URI scheme
     2662   (<xref target="http.uri"/>) indicates a default connection of TCP
     2663   over IP, with a default TCP port of 80, but the client might be
     2664   configured to use a proxy via some other connection, port, or protocol.
     2665</t>
     2666<t>
     2667   HTTP implementations are expected to engage in connection management,
     2668   which includes maintaining the state of current connections,
     2669   establishing a new connection or reusing an existing connection,
     2670   processing messages received on a connection, detecting connection
     2671   failures, and closing each connection.
     2672   Most clients maintain multiple connections in parallel, including
     2673   more than one connection per server endpoint.
     2674   Most servers are designed to maintain thousands of concurrent connections,
     2675   while controlling request queues to enable fair use and detect
     2676   denial of service attacks.
     2677</t>
    26652678
    26662679<section title="Connection" anchor="header.connection">
    … …  
    26702683  <x:anchor-alias value="connection-option"/>
    26712684<t>
    2672    The "Connection" header field allows the sender to specify
    2673    options that are desired only for that particular connection.
    2674    Such connection options &MUST; be removed or replaced before the
    2675    message can be forwarded downstream by a proxy or gateway.
    2676    This mechanism also allows the sender to indicate which HTTP
    2677    header fields used in the message are only intended for the
    2678    immediate recipient ("hop-by-hop"), as opposed to all recipients
    2679    on the chain ("end-to-end"), enabling the message to be
    2680    self-descriptive and allowing future connection-specific extensions
    2681    to be deployed in HTTP without fear that they will be blindly
    2682    forwarded by previously deployed intermediaries.
     2685   The "Connection" header field allows the sender to indicate desired
     2686   control options for the current connection.  In order to avoid confusing
     2687   downstream recipients, a proxy or gateway &MUST; remove or replace any
     2688   received connection options before forwarding the message.
     2689</t>
     2690<t>
     2691   When a header field is used to supply control information for or about
     2692   the current connection, the sender &SHOULD; list the corresponding
     2693   field-name within the "Connection" header field.
     2694   A proxy or gateway &MUST; parse a received Connection
     2695   header field before a message is forwarded and, for each
     2696   connection-option in this field, remove any header field(s) from
     2697   the message with the same name as the connection-option, and then
     2698   remove the Connection header field itself (or replace it with the
     2699   intermediary's own connection options for the forwarded message).
     2700</t>
     2701<t>
     2702   Hence, the Connection header field provides a declarative way of
     2703   distinguishing header fields that are only intended for the
     2704   immediate recipient ("hop-by-hop") from those fields that are
     2705   intended for all recipients on the chain ("end-to-end"), enabling the
     2706   message to be self-descriptive and allowing future connection-specific
     2707   extensions to be deployed without fear that they will be blindly
     2708   forwarded by older intermediaries.
    26832709</t>
    26842710<t>
    … …  
    26912717<t>
    26922718   Connection options are compared case-insensitively.
    2693 </t>
    2694 <t>
    2695    A proxy or gateway &MUST; parse a received Connection
    2696    header field before a message is forwarded and, for each
    2697    connection-option in this field, remove any header field(s) from
    2698    the message with the same name as the connection-option, and then
    2699    remove the Connection header field itself or replace it with the
    2700    sender's own connection options for the forwarded message.
    27012719</t>
    27022720<t>
    … …  
    27392757<t>
    27402758   in either the request or the response header fields indicates that
    2741    the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
    2742    after the current request/response is complete.
     2759   the connection &SHOULD; be closed after the current request/response
     2760   is complete (<xref target="persistent.connections"/>).
    27432761</t>
    27442762<t>
    … …  
    27542772
    27552773<section title="Persistent Connections" anchor="persistent.connections">
    2756 
    2757 <section title="Purpose" anchor="persistent.purpose">
    2758 <t>
    2759    Prior to persistent connections, a separate TCP connection was
    2760    established for each request, increasing the load on HTTP servers
    2761    and causing congestion on the Internet. The use of inline images and
    2762    other associated data often requires a client to make multiple
    2763    requests of the same server in a short amount of time. Analysis of
    2764    these performance problems and results from a prototype
    2765    implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and
    2766    measurements of actual HTTP/1.1 implementations show good
    2767    results <xref target="Nie1997"/>. Alternatives have also been explored, for example,
    2768    T/TCP <xref target="Tou1998"/>.
    2769 </t>
    2770 <t>
    2771    Persistent HTTP connections have a number of advantages:
     2774  <x:anchor-alias value="persistent connections"/>
     2775<t>
     2776   HTTP was originally designed to use a separate connection for each
     2777   request/response pair. As the Web evolved and embedded requests became
     2778   common for inline images, the connection establishment overhead was
     2779   a significant drain on performance and a concern for Internet congestion.
     2780   Message framing (via <x:ref>Content-Length</x:ref>) and optional
     2781   long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order
     2782   to improve performance for some requests. However, these extensions were
     2783   insufficient for dynamically generated responses and difficult to use
     2784   with intermediaries.
     2785</t>
     2786<t>
     2787   HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",
     2788   which allow multiple requests and responses to be carried over a single
     2789   connection.
     2790   Persistent connections have a number of advantages:
    27722791  <list style="symbols">
    27732792      <t>
    2774         By opening and closing fewer TCP connections, CPU time is saved
     2793        By opening and closing fewer connections, CPU time is saved
    27752794        in routers and hosts (clients, servers, proxies, gateways,
    2776         tunnels, or caches), and memory used for TCP protocol control
     2795        tunnels, or caches), and memory used for protocol control
    27772796        blocks can be saved in hosts.
    27782797      </t>
    27792798      <t>
    2780         HTTP requests and responses can be pipelined on a connection.
     2799        Most requests and responses can be pipelined on a connection.
    27812800        Pipelining allows a client to make multiple requests without
    2782         waiting for each response, allowing a single TCP connection to
    2783         be used much more efficiently, with much lower elapsed time.
     2801        waiting for each response, allowing a single connection to
     2802        be used much more efficiently and with less overall latency.
    27842803      </t>
    27852804      <t>
    27862805        Network congestion is reduced by reducing the number of packets
    2787         caused by TCP opens, and by allowing TCP sufficient time to
    2788         determine the congestion state of the network.
     2806        caused by connection establishment and tear-down, and by allowing
     2807        sufficient time for send/receive windows to adjust to the
     2808        available network bandwidth.
    27892809      </t>
    27902810      <t>
    27912811        Latency on subsequent requests is reduced since there is no time
    2792         spent in TCP's connection opening handshake.
     2812        spent in the connection opening handshake.
    27932813      </t>
    27942814      <t>
    2795         HTTP can evolve more gracefully, since errors can be reported
    2796         without the penalty of closing the TCP connection. Clients using
     2815        HTTP can evolve more gracefully, since most errors can be reported
     2816        without the penalty of closing the connection. Clients using
    27972817        future versions of HTTP might optimistically try a new feature,
    27982818        but if communicating with an older server, retry with old
    … …  
    28042824   HTTP implementations &SHOULD; implement persistent connections.
    28052825</t>
    2806 </section>
    28072826
    28082827<section title="Overall Operation" anchor="persistent.overall">
    … …  
    42914310</reference>
    42924311
    4293 <reference anchor="Nie1997" target="http://doi.acm.org/10.1145/263105.263157">
    4294   <front>
    4295     <title>Network Performance Effects of HTTP/1.1, CSS1, and PNG</title>
    4296     <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"/>
    4297     <author initials="J." surname="Gettys" fullname="J. Gettys"/>
    4298     <author initials="E." surname="Prud'hommeaux" fullname="E. Prud'hommeaux"/>
    4299     <author initials="H." surname="Lie" fullname="H. Lie"/>
    4300     <author initials="C." surname="Lilley" fullname="C. Lilley"/>
    4301     <date year="1997" month="September"/>
    4302   </front>
    4303   <seriesInfo name="ACM" value="Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication SIGCOMM '97"/>
    4304 </reference>
    4305 
    4306 <reference anchor="Pad1995" target="http://portal.acm.org/citation.cfm?id=219094">
    4307   <front>
    4308     <title>Improving HTTP Latency</title>
    4309     <author initials="V.N." surname="Padmanabhan" fullname="Venkata N. Padmanabhan"/>
    4310     <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"/>
    4311     <date year="1995" month="December"/>
    4312   </front>
    4313   <seriesInfo name="Computer Networks and ISDN Systems" value="v. 28, pp. 25-35"/>
    4314 </reference>
    4315 
    43164312<reference anchor='RFC1919'>
    43174313  <front>
    … …  
    46834679  </front>
    46844680  <seriesInfo name="ACM Transactions on Internet Technology" value="Vol. 1, #2"/>
    4685 </reference>
    4686 
    4687 <reference anchor="Spe" target="http://sunsite.unc.edu/mdma-release/http-prob.html">
    4688   <front>
    4689     <title>Analysis of HTTP Performance Problems</title>
    4690     <author initials="S." surname="Spero" fullname="Simon E. Spero"/>
    4691     <date/>
    4692   </front>
    4693 </reference>
    4694 
    4695 <reference anchor="Tou1998" target="http://www.isi.edu/touch/pubs/http-perf96/">
    4696   <front>
    4697   <title>Analysis of HTTP Performance</title>
    4698   <author initials="J." surname="Touch" fullname="Joe Touch">
    4699     <organization>USC/Information Sciences Institute</organization>
    4700     <address><email>touch@isi.edu</email></address>
    4701   </author>
    4702   <author initials="J." surname="Heidemann" fullname="John Heidemann">
    4703     <organization>USC/Information Sciences Institute</organization>
    4704     <address><email>johnh@isi.edu</email></address>
    4705   </author>
    4706   <author initials="K." surname="Obraczka" fullname="Katia Obraczka">
    4707     <organization>USC/Information Sciences Institute</organization>
    4708     <address><email>katia@isi.edu</email></address>
    4709   </author>
    4710   <date year="1998" month="Aug"/>
    4711   </front>
    4712   <seriesInfo name="ISI Research Report" value="ISI/RR-98-463"/>
    4713   <annotation>(original report dated Aug. 1996)</annotation>
    47144681</reference>
    47154682
Note: See TracChangeset for help on using the changeset viewer.