idnits 2.17.1 draft-nottingham-http2-ops-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2014) is 3618 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Akamai Technologies 4 Intended status: Informational May 30, 2014 5 Expires: December 1, 2014 7 HTTP/2: Operational Considerations for Servers 8 draft-nottingham-http2-ops-00 10 Abstract 12 This document gives advice regarding performance and operability to 13 servers deploying HTTP/2. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 1, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 51 2. TCP Configuration . . . . . . . . . . . . . . . . . . . . . . 3 52 3. TLS Configuration . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Load Balancing and Failover . . . . . . . . . . . . . . . . . 4 54 5. Use of HPACK . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Use of Flow Control . . . . . . . . . . . . . . . . . . . . . 5 56 7. Use of Prioritisation . . . . . . . . . . . . . . . . . . . . 5 57 8. Use of Server Push . . . . . . . . . . . . . . . . . . . . . 5 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 11.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 HTTP/2 [I-D.ietf-httpbis-http2] does not change the semantics of HTTP 68 [I-D.ietf-httpbis-p2-semantics], but it does substantially change how 69 they are mapped to the underlying protocols. 71 While some of these changes can enhance performance and/or 72 operability on their own, getting the full benefit of the new 73 protocol requires changes beyond the scope of just the Web server. 75 Likewise, HTTP/2 offers new in-protocol mechanisms like header 76 compression, flow control, prioritisation and server push. Used 77 effectively, they can improve the performance characteristics of the 78 protocol, but they can also cause operability issues if used 79 incorrectly. 81 This document gives advice about both cases; how to configure lower- 82 layer protocols, as well as how to use HTTP/2's in-built mechanisms 83 effectively. 85 It is primarily focused on the needs of origin servers, since there 86 are generally many more instances of origin servers than there are 87 unique client deployments. It is also primarily focused on the Web 88 browsing use case; however, much of the advice here is applicable to 89 non-browsing uses as well. 91 Note that the advice here is specific to when it was written; changes 92 in underlying protocols, deployment practices, and HTTP itself may 93 obsolete it at any time. As such, it is not intended to be long- 94 lived, but instead to aid initial deployment of the new protocol. 96 1.1. Notational Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. TCP Configuration 104 HTTP/2 has been designed to use a single TCP connection, whereas 105 current practice for HTTP/1 is to use multiple connections to achieve 106 parallelism (generally, between four and eight). 108 The change has a number of benefits. Using fewer TCP connections to 109 load a Web page consumes less server-side resources, and it also 110 reduces the chance of a congestion event caused by a large number of 111 connections simultaneously starting (overcoming TCP Slow Start), and 112 returns HTTP to being a "fair" protocol. Using a single connection 113 also enables better efficiency with header compression. 115 However, using a single connection can also lead to unfavorable 116 performance, as compared with HTTP/1's use of multiple connections, 117 primarily due to side effects of TCP congestion control. 119 In particular, a single HTTP/2 connection with an initcwnd of 3 can 120 only have three unacknowledged packets during the startup phase of 121 the connection, whereas (for example) six HTTP/1 connections would 122 have as many as 18 packets outstanding. This places HTTP/2 at a 123 significant disadvantage compared to HTTP/1, but can be mitigated by 124 adopting an initcwnd of 10 for HTTP/2 connections, as outlined in 125 [RFC6928]. 127 Similarly, a congestion event on a HTTP/2 connection can cause 128 disproportionate havoc, as compared to HTTP/1, in those cases where 129 the event only affects a subset of open connections (such as random 130 packet loss). TBD: mitigation 132 Key recommendations: * HTTP/2 servers SHOULD adopt an initcwnd of 10, 133 as per [RFC6928]. 135 3. TLS Configuration 137 Beyond the typical performance and operational considerations of 138 deploying TLS [RFC5246], a concern specific to HTTP/2 is the TLS 139 record size; because HTTP/2 is a multiplexed protocol, a large record 140 size can cause packet loss to affect a disproportionate number of 141 streams, due to an individual record not being available until it is 142 complete. 144 Therefore, small record sizes are preferred for HTTP/2; if a record 145 is sent within a single packet, the chances of blocking are 146 minimized. That said, records ought not be much smaller, since this 147 will increase processing overhead, and in some circumstances (e.g., 148 non-interactive applications, downloads), it may be reasonable to 149 have larger record sizes. 151 Key recommendations: * HTTP/2 servers SHOULD use a small TLS record 152 size; ideally, small enough that a record fits completely in a single 153 packet. 155 4. Load Balancing and Failover 157 It's common to use multiple servers to server a single HTTP origin, 158 in order to provide a scalable and reliable service. DNS is also 159 commonly used to direct clients to the best (by some metric) server 160 available. 162 In HTTP/1, the transition from one server to another in these 163 scenarios is often done between connections; because HTTP/1 164 connections are generally short-lived, it's possible to load balance 165 clients as they re-connect. 167 HTTP/2, however, is designed to have fewer, longer-lived connections, 168 and it's anticipated that clients will be keeping them open much more 169 aggressively. This provides fewer opportunities for servers to shift 170 traffic. If a server breaks connections pre-emtively in order to 171 load balance or failover, it can also have a greater negative effect, 172 since more than one request can be "in flight" simultaneously. 174 The new protocol accommodates these situations in a few ways, 175 improving operability along the way. 177 Firstly, the GOAWAY frame allows servers to announce that they will 178 not serve additional requests on a connection, while still completing 179 those that preceed the GOAWAY. This allows a connection to be shut 180 down in an orderly fashion, and its use is required in HTTP/2. 182 Additionally, the ALTSVC frame allows a server to redirect traffic to 183 another location, without changing the resource's URL. This can be 184 used for load balancing (both local and global), as well as 185 controlled failover of services. 187 5. Use of HPACK 189 TBD 191 6. Use of Flow Control 193 TBD 195 7. Use of Prioritisation 197 TBD 199 8. Use of Server Push 201 TBD 203 9. Security Considerations 205 This document introduces no unique security considerations beyond 206 those discussed in HTTP/2 itself. 208 10. Acknowledgements 210 TBD 212 11. References 214 11.1. Normative References 216 [I-D.ietf-httpbis-http2] 217 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 218 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 219 progress), April 2014. 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 225 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 227 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 228 "Increasing TCP's Initial Window", RFC 6928, April 2013. 230 11.2. Informative References 232 [I-D.ietf-httpbis-p2-semantics] 233 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 234 (HTTP/1.1): Semantics and Content", draft-ietf- 235 httpbis-p2-semantics-26 (work in progress), February 2014. 237 Author's Address 239 Mark Nottingham 240 Akamai Technologies 242 Email: mnot@mnot.net 243 URI: http://www.mnot.net/