Ignore:
Timestamp:
Dec 5, 2012, 9:42:21 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) improvements to persistent connections section; addresses #396

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2031 r2032  
    27792779</t>
    27802780<t>
    2781    A client that does not support persistent connections &MUST;
     2781   A client that does not support <x:ref>persistent connections</x:ref> &MUST;
    27822782   send the "close" connection option in every request message.
    27832783</t>
    27842784<t>
    2785    A server that does not support persistent connections &MUST;
     2785   A server that does not support <x:ref>persistent connections</x:ref> &MUST;
    27862786   send the "close" connection option in every response message that
    27872787   does not have a <x:ref>1xx (Informational)</x:ref> status code.
     
    27892789</section>
    27902790
    2791 <section title="Persistent Connections" anchor="persistent.connections">
    2792   <x:anchor-alias value="persistent connections"/>
    2793 <t>
    2794    HTTP was originally designed to use a separate connection for each
    2795    request/response pair. As the Web evolved and embedded requests became
    2796    common for inline images, the connection establishment overhead was
    2797    a significant drain on performance and a concern for Internet congestion.
    2798    Message framing (via <x:ref>Content-Length</x:ref>) and optional
    2799    long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order
    2800    to improve performance for some requests. However, these extensions were
    2801    insufficient for dynamically generated responses and difficult to use
    2802    with intermediaries.
    2803 </t>
    2804 <t>
    2805    HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",
    2806    which allow multiple requests and responses to be carried over a single
    2807    connection. The "<x:ref>close</x:ref>" connection-option is used to
    2808    signal that a connection will close after the current request/response.
    2809    Persistent connections have a number of advantages:
    2810   <list style="symbols">
    2811       <t>
    2812         By opening and closing fewer connections, CPU time is saved
    2813         in routers and hosts (clients, servers, proxies, gateways,
    2814         tunnels, or caches), and memory used for protocol control
    2815         blocks can be saved in hosts.
    2816       </t>
    2817       <t>
    2818         Most requests and responses can be pipelined on a connection.
    2819         Pipelining allows a client to make multiple requests without
    2820         waiting for each response, allowing a single connection to
    2821         be used much more efficiently and with less overall latency.
    2822       </t>
    2823       <t>
    2824         For TCP connections, network congestion is reduced by eliminating the
    2825         packets associated with the three way handshake and graceful close
    2826         procedures, and by allowing sufficient time to determine the
    2827         congestion state of the network.
    2828       </t>
    2829       <t>
    2830         Latency on subsequent requests is reduced since there is no time
    2831         spent in the connection opening handshake.
    2832       </t>
    2833       <t>
    2834         HTTP can evolve more gracefully, since most errors can be reported
    2835         without the penalty of closing the connection. Clients using
    2836         future versions of HTTP might optimistically try a new feature,
    2837         but if communicating with an older server, retry with old
    2838         semantics after an error is reported.
    2839       </t>
    2840     </list>
    2841 </t>
    2842 <t>
    2843    HTTP implementations &SHOULD; implement persistent connections.
    2844 </t>
    2845    
    28462791<section title="Establishment" anchor="persistent.establishment">
    28472792<t>
     
    28492794   are established via various transport or session-layer protocols.
    28502795   Each connection applies to only one transport link.
     2796</t>
     2797</section>
     2798
     2799<section title="Persistence" anchor="persistent.connections">
     2800   <x:anchor-alias value="persistent connections"/>
     2801<t>
     2802   HTTP/1.1 defaults to the use of "<x:dfn>persistent connections</x:dfn>",
     2803   which allow multiple requests and responses to be carried over a single
     2804   connection. The "<x:ref>close</x:ref>" connection-option is used to signal
     2805   that a connection will not persist after the current request/response.
     2806   HTTP implementations &SHOULD; support persistent connections.
    28512807</t>
    28522808<t>
     
    28722828   implemented by many HTTP/1.0 clients).
    28732829</t>
    2874 </section>
    2875 
    2876 <section title="Reuse" anchor="persistent.reuse">
    28772830<t>
    28782831   In order to remain persistent, all messages on a connection &MUST;
     
    28802833   of the connection), as described in <xref target="message.body"/>.
    28812834</t>
     2835</section>
     2836
     2837<section title="Reuse" anchor="persistent.reuse">
    28822838<t>
    28832839   A server &MAY; assume that an HTTP/1.1 client intends to maintain a
     
    30663022   be found in other transport connection protocols.
    30673023</t>
    3068 </section>
    30693024</section>
    30703025
Note: See TracChangeset for help on using the changeset viewer.