Changeset 2127 for draft-ietf-httpbis-http2/latest
- Timestamp:
- 19/01/13 00:18:13 (10 years ago)
- Location:
- draft-ietf-httpbis-http2/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html
r2125 r2127 406 406 } 407 407 @bottom-center { 408 content: "Expires July 2 0, 2013";408 content: "Expires July 22, 2013"; 409 409 } 410 410 @bottom-right { … … 447 447 <meta name="dct.creator" content="Melnikov, A."> 448 448 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest"> 449 <meta name="dct.issued" scheme="ISO8601" content="2013-01-1 6">449 <meta name="dct.issued" scheme="ISO8601" content="2013-01-18"> 450 450 <meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified."> 451 451 <meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified."> … … 467 467 </tr> 468 468 <tr> 469 <td class="left">Expires: July 2 0, 2013</td>469 <td class="left">Expires: July 22, 2013</td> 470 470 <td class="right">Google, Inc</td> 471 471 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">January 1 6, 2013</td>490 <td class="right">January 18, 2013</td> 491 491 </tr> 492 492 </tbody> … … 521 521 in progress”. 522 522 </p> 523 <p>This Internet-Draft will expire on July 2 0, 2013.</p>523 <p>This Internet-Draft will expire on July 22, 2013.</p> 524 524 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 525 525 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 569 569 </ul> 570 570 </li> 571 <li><a href="#rfc.section.3.5">3.5</a> <a href="#rfc.section.3.5">Data flow</a></li> 571 <li><a href="#rfc.section.3.5">3.5</a> <a href="#flowcontrol">Stream Flow Control</a><ul> 572 <li><a href="#rfc.section.3.5.1">3.5.1</a> <a href="#fc-principles">Flow Control Principles</a></li> 573 <li><a href="#rfc.section.3.5.2">3.5.2</a> <a href="#fc-basic">Basic Flow Control Algorithm</a></li> 574 </ul> 575 </li> 572 576 <li><a href="#rfc.section.3.6">3.6</a> <a href="#rfc.section.3.6">Control frame types</a><ul> 573 577 <li><a href="#rfc.section.3.6.1">3.6.1</a> <a href="#SYN_STREAM">SYN_STREAM</a></li> … … 934 938 There is no reason to send a RST_STREAM for each frame in succession). 935 939 </p> 936 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> Data flow 937 </h2> 938 <p id="rfc.section.3.5.p.1">Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must 939 intelligently interleave data messages for concurrent sessions. 940 </p> 940 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="flowcontrol" href="#flowcontrol">Stream Flow Control</a></h2> 941 <p id="rfc.section.3.5.p.1">Multiplexing streams introduces contention for access to the shared TCP connection. Stream contention can result in streams 942 being blocked by other streams. A flow control scheme ensures that streams do not destructively interfere with other streams 943 on the same TCP connection. 944 </p> 945 <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a> <a id="fc-principles" href="#fc-principles">Flow Control Principles</a></h3> 946 <p id="rfc.section.3.5.1.p.1">Experience with TCP congestion control has shown that algorithms can evolve over time to become more sophisticated without 947 requiring protocol changes. TCP congestion control and its evolution is clearly different from HTTP/2.0 flow control, though 948 the evolution of TCP congestion control algorithms shows that a similar approach could be feasible for HTTP/2.0 flow control. 949 </p> 950 <p id="rfc.section.3.5.1.p.2">HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms without requiring protocol changes. 951 The following principles guide the HTTP/2.0 design: 952 </p> 953 <ol> 954 <li>Flow control is hop-by-hop, not end-to-end.</li> 955 <li>Flow control is based on window update messages. Receivers advertise how many octets they are prepared to receive on a stream. 956 This is a credit-based scheme. 957 </li> 958 <li>Flow control is directional with overall control provided by the receiver. A receiver MAY choose to set any window size that 959 it desires for each stream [[TBD: ... and for the overall connection]]. A sender MUST respect flow control limits imposed 960 by a receiver. Clients, servers and intermediaries all independently advertise their flow control preferences as a receiver 961 and abide by the flow control limits set by their peer when sending. 962 </li> 963 <li>Flow control can be disabled by a receiver. A receiver can choose to either disable flow control, or to declare an infinite 964 flow control limit. [[TBD: determine whether just one mechanism is sufficient, and then which alternative]] 965 </li> 966 <li>HTTP/2.0 standardizes only the format of the window update message (<a href="#WINDOW_UPDATE" title="WINDOW_UPDATE">Section 3.6.8</a>). This does not stipulate how a receiver decides when to send this message or the value that it sends. Nor does it specify 967 how a sender chooses to send packets. Implementations are able to select any algorithm that suits their needs. An example 968 flow control algorithm is described in <a href="#fc-basic" title="Basic Flow Control Algorithm">Section 3.5.2</a>. 969 </li> 970 </ol> 971 <p id="rfc.section.3.5.1.p.3">Implementations are also responsible for managing how requests and responses are sent based on priority; choosing how to avoid 972 head of line blocking for requests; and managing the creation of new streams. Algorithm choices for these could interact with 973 any flow control algorithm. 974 </p> 975 <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a> <a id="fc-basic" href="#fc-basic">Basic Flow Control Algorithm</a></h3> 976 <p id="rfc.section.3.5.2.p.1">This section describes a basic flow control algorithm. This algorithm is provided as an example, implementations can use any 977 algorithm that complies with flow control requirements. 978 </p> 979 <p id="rfc.section.3.5.2.p.2">[[Algorithm TBD]]</p> 941 980 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> Control frame types 942 981 </h2> … … 1983 2022 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Acknowledgements 1984 2023 </h1> 1985 <p id="rfc.section.9.p.1">Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the design and evolution of SPDY: 1986 Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe 1987 Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton. 1988 </p> 2024 <p id="rfc.section.9.p.1">This document includes substantial input from the following individuals: </p> 2025 <ul> 2026 <li>Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe 2027 Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). 2028 </li> 2029 <li>Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)</li> 2030 <li>William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon, Rob Trace (Flow control principles)</li> 2031 <li>Mark Nottingham and Julian Reschke</li> 2032 </ul> 1989 2033 <h1 id="rfc.references"><a href="#rfc.section.10" id="rfc.section.10">10.</a> Normative References 1990 2034 </h1> … … 2080 2124 <p id="rfc.section.A.1.p.5">Added section on starting HTTP/2.0, including upgrade mechanism.</p> 2081 2125 <p id="rfc.section.A.1.p.6">Removed unused references.</p> 2126 <p id="rfc.section.A.1.p.7">Added flow control principles (<a href="#fc-principles" title="Flow Control Principles">Section 3.5.1</a>) based on <<a href="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01">http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01</a>>. 2127 </p> 2082 2128 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2> 2083 2129 <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p> -
draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml
r2125 r2127 431 431 </section> 432 432 433 <section title="Data flow"> 434 <t>Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must intelligently interleave data messages for concurrent sessions.</t> 435 </section> 433 <section anchor="flowcontrol" title="Stream Flow Control"> 434 <t> 435 Multiplexing streams introduces contention for access to the shared TCP connection. Stream 436 contention can result in streams being blocked by other streams. A flow control scheme ensures 437 that streams do not destructively interfere with other streams on the same TCP connection. 438 </t> 439 440 <section anchor="fc-principles" title="Flow Control Principles"> 441 <t> 442 Experience with TCP congestion control has shown that algorithms can evolve over time 443 to become more sophisticated without requiring protocol changes. TCP congestion control and its 444 evolution is clearly different from HTTP/2.0 flow control, though the evolution of TCP congestion 445 control algorithms shows that a similar approach could be feasible for HTTP/2.0 flow control. 446 </t> 447 <t> 448 HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms 449 without requiring protocol changes. The following principles guide the HTTP/2.0 design: 450 <list style="numbers"> 451 <t> 452 Flow control is hop-by-hop, not end-to-end. 453 </t> 454 <t> 455 Flow control is based on window update messages. Receivers advertise how many octets they are 456 prepared to receive on a stream. This is a credit-based scheme. 457 </t> 458 <t> 459 Flow control is directional with overall control provided by the receiver. A receiver MAY 460 choose to set any window size that it desires for each stream [[TBD: ... and for the overall 461 connection]]. A sender MUST respect flow control limits imposed by a receiver. Clients, 462 servers and intermediaries all independently advertise their flow control preferences as a 463 receiver and abide by the flow control limits set by their peer when sending. 464 </t> 465 <t> 466 Flow control can be disabled by a receiver. A receiver can choose to either disable flow 467 control, or to declare an infinite flow control limit. [[TBD: determine whether just one 468 mechanism is sufficient, and then which alternative]] 469 </t> 470 <t> 471 HTTP/2.0 standardizes only the format of the <xref target="WINDOW_UPDATE">window update 472 message</xref>. This does not stipulate how a receiver decides when to send this message or 473 the value that it sends. Nor does it specify how a sender chooses to send packets. 474 Implementations are able to select any algorithm that suits their needs. An example flow 475 control algorithm is described in <xref target="fc-basic"/>. 476 </t> 477 </list> 478 </t> 479 <t> 480 Implementations are also responsible for managing how requests and responses are sent based on 481 priority; choosing how to avoid head of line blocking for requests; and managing the creation of 482 new streams. Algorithm choices for these could interact with any flow control algorithm. 483 </t> 484 485 </section> 486 <section anchor="fc-basic" title="Basic Flow Control Algorithm"> 487 <t> 488 This section describes a basic flow control algorithm. This algorithm is provided as an example, 489 implementations can use any algorithm that complies with flow control requirements. 490 </t> 491 <t> 492 [[Algorithm TBD]] 493 </t> 494 </section> 495 </section> 436 496 437 497 <section title="Control frame types"> … … 1313 1373 1314 1374 <section title="Acknowledgements"> 1315 <t> 1316 Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the 1317 design and evolution of SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa 1318 Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin 1319 Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton. 1375 <t>This document includes substantial input from the following individuals: 1376 <list style="symbols"> 1377 <t> 1378 Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, 1379 William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, 1380 Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors). 1381 </t> 1382 <t> 1383 Gabriel Montenegro and Willy Tarreau (Upgrade mechanism) 1384 </t> 1385 <t> 1386 William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon, 1387 Rob Trace (Flow control principles) 1388 </t> 1389 <t> 1390 Mark Nottingham and Julian Reschke 1391 </t> 1392 </list> 1320 1393 </t> 1394 1321 1395 </section> 1322 1396 </middle> … … 1543 1617 </t> 1544 1618 <t> 1545 Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>. 1619 Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref 1620 target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>. 1546 1621 </t> 1547 1622 <t> … … 1553 1628 <t> 1554 1629 Removed unused references. 1630 </t> 1631 <t> 1632 Added <xref target="fc-principles">flow control principles</xref> based on <eref 1633 target="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01"/>. 1555 1634 </t> 1556 1635 </section>
Note: See TracChangeset
for help on using the changeset viewer.