Changeset 2032 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 05/12/12 17:42:21 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2031 r2032 2779 2779 </t> 2780 2780 <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; 2782 2782 send the "close" connection option in every request message. 2783 2783 </t> 2784 2784 <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; 2786 2786 send the "close" connection option in every response message that 2787 2787 does not have a <x:ref>1xx (Informational)</x:ref> status code. … … 2789 2789 </section> 2790 2790 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 each2795 request/response pair. As the Web evolved and embedded requests became2796 common for inline images, the connection establishment overhead was2797 a significant drain on performance and a concern for Internet congestion.2798 Message framing (via <x:ref>Content-Length</x:ref>) and optional2799 long-lived connections (via Keep-Alive) were added to HTTP/1.0 in order2800 to improve performance for some requests. However, these extensions were2801 insufficient for dynamically generated responses and difficult to use2802 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 single2807 connection. The "<x:ref>close</x:ref>" connection-option is used to2808 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 saved2813 in routers and hosts (clients, servers, proxies, gateways,2814 tunnels, or caches), and memory used for protocol control2815 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 without2820 waiting for each response, allowing a single connection to2821 be used much more efficiently and with less overall latency.2822 </t>2823 <t>2824 For TCP connections, network congestion is reduced by eliminating the2825 packets associated with the three way handshake and graceful close2826 procedures, and by allowing sufficient time to determine the2827 congestion state of the network.2828 </t>2829 <t>2830 Latency on subsequent requests is reduced since there is no time2831 spent in the connection opening handshake.2832 </t>2833 <t>2834 HTTP can evolve more gracefully, since most errors can be reported2835 without the penalty of closing the connection. Clients using2836 future versions of HTTP might optimistically try a new feature,2837 but if communicating with an older server, retry with old2838 semantics after an error is reported.2839 </t>2840 </list>2841 </t>2842 <t>2843 HTTP implementations &SHOULD; implement persistent connections.2844 </t>2845 2846 2791 <section title="Establishment" anchor="persistent.establishment"> 2847 2792 <t> … … 2849 2794 are established via various transport or session-layer protocols. 2850 2795 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. 2851 2807 </t> 2852 2808 <t> … … 2872 2828 implemented by many HTTP/1.0 clients). 2873 2829 </t> 2874 </section>2875 2876 <section title="Reuse" anchor="persistent.reuse">2877 2830 <t> 2878 2831 In order to remain persistent, all messages on a connection &MUST; … … 2880 2833 of the connection), as described in <xref target="message.body"/>. 2881 2834 </t> 2835 </section> 2836 2837 <section title="Reuse" anchor="persistent.reuse"> 2882 2838 <t> 2883 2839 A server &MAY; assume that an HTTP/1.1 client intends to maintain a … … 3066 3022 be found in other transport connection protocols. 3067 3023 </t> 3068 </section>3069 3024 </section> 3070 3025
Note: See TracChangeset
for help on using the changeset viewer.