Changeset 1837 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- Aug 19, 2012, 11:04:26 PM (7 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1836 r1837 293 293 <x:dfn>messages</x:dfn> (<xref target="http.message"/>) across a reliable 294 294 transport or session-layer 295 "<x:dfn>connection</x:dfn>" . An HTTP "<x:dfn>client</x:dfn>" is a296 program that establishes a connection to a server for the purpose of297 sending one or more HTTP requests. An HTTP "<x:dfn>server</x:dfn>" is a298 program that accepts connections in order to service HTTP requests by299 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. 300 300 </t> 301 301 <iref primary="true" item="user agent"/> … … 363 363 a message body containing the payload body (if any, 364 364 <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"/>. 365 369 </t> 366 370 <t> … … 424 428 before proceeding can me met via advance configuration choices, 425 429 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 or432 session-layer connection protocol(s). HTTP only presumes a reliable433 transport with in-order delivery of requests and the corresponding434 in-order delivery of responses. The mapping of HTTP request and435 response structures onto the data units of the underlying transport436 protocol is outside the scope of this specification.437 </t>438 <t>439 The specific connection protocols to be used for an interaction440 are determined by client configuration and the target URI441 (<xref target="target-resource"/>).442 For example, the "http" URI scheme443 (<xref target="http.uri"/>) indicates a default connection of TCP444 over IP, with a default TCP port of 80, but the client might be445 configured to use a proxy via some other connection port or protocol446 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"/>.451 430 </t> 452 431 </section> … … 2133 2112 <iref primary="true" item="target resource"/> 2134 2113 <iref primary="true" item="target URI"/> 2114 <x:anchor-alias value="target resource"/> 2115 <x:anchor-alias value="target URI"/> 2135 2116 <t> 2136 2117 HTTP is used in a wide variety of applications, ranging from … … 2187 2168 "https" (<xref target="https.uri"/>) schemes. 2188 2169 </t> 2170 <t> 2171 HTTP requirements regarding connection management are defined in 2172 <xref target="connection.management"/>. 2173 </t> 2189 2174 </section> 2190 2175 2191 2176 <section title="Request Target" anchor="request-target"> 2192 2177 <t> 2193 Once an inbound connection is obtained 2194 (<xref target="connection.management"/>), 2178 Once an inbound connection is obtained, 2195 2179 the client sends an HTTP request message (<xref target="http.message"/>) 2196 2180 with a request-target derived from the target URI. … … 2663 2647 2664 2648 <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> 2665 2678 2666 2679 <section title="Connection" anchor="header.connection"> … … 2670 2683 <x:anchor-alias value="connection-option"/> 2671 2684 <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. 2683 2709 </t> 2684 2710 <t> … … 2691 2717 <t> 2692 2718 Connection options are compared case-insensitively. 2693 </t>2694 <t>2695 A proxy or gateway &MUST; parse a received Connection2696 header field before a message is forwarded and, for each2697 connection-option in this field, remove any header field(s) from2698 the message with the same name as the connection-option, and then2699 remove the Connection header field itself or replace it with the2700 sender's own connection options for the forwarded message.2701 2719 </t> 2702 2720 <t> … … 2739 2757 <t> 2740 2758 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"/>). 2743 2761 </t> 2744 2762 <t> … … 2754 2772 2755 2773 <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: 2772 2791 <list style="symbols"> 2773 2792 <t> 2774 By opening and closing fewer TCPconnections, CPU time is saved2793 By opening and closing fewer connections, CPU time is saved 2775 2794 in routers and hosts (clients, servers, proxies, gateways, 2776 tunnels, or caches), and memory used for TCPprotocol control2795 tunnels, or caches), and memory used for protocol control 2777 2796 blocks can be saved in hosts. 2778 2797 </t> 2779 2798 <t> 2780 HTTPrequests and responses can be pipelined on a connection.2799 Most requests and responses can be pipelined on a connection. 2781 2800 Pipelining allows a client to make multiple requests without 2782 waiting for each response, allowing a single TCPconnection to2783 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. 2784 2803 </t> 2785 2804 <t> 2786 2805 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. 2789 2809 </t> 2790 2810 <t> 2791 2811 Latency on subsequent requests is reduced since there is no time 2792 spent in TCP'sconnection opening handshake.2812 spent in the connection opening handshake. 2793 2813 </t> 2794 2814 <t> 2795 HTTP can evolve more gracefully, since errors can be reported2796 without the penalty of closing the TCPconnection. Clients using2815 HTTP can evolve more gracefully, since most errors can be reported 2816 without the penalty of closing the connection. Clients using 2797 2817 future versions of HTTP might optimistically try a new feature, 2798 2818 but if communicating with an older server, retry with old … … 2804 2824 HTTP implementations &SHOULD; implement persistent connections. 2805 2825 </t> 2806 </section>2807 2826 2808 2827 <section title="Overall Operation" anchor="persistent.overall"> … … 4291 4310 </reference> 4292 4311 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 4316 4312 <reference anchor='RFC1919'> 4317 4313 <front> … … 4683 4679 </front> 4684 4680 <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>4714 4681 </reference> 4715 4682
Note: See TracChangeset
for help on using the changeset viewer.