



Network Working Group                                        D. Stenberg
Internet-Draft                                           October 1, 2015
Intended status: Best Current Practice
Expires: April 3, 2016


                    TCP Performance Tuning for HTTP
                     draft-stenberg-httpbis-tcp-00

Abstract

   This document records current best practice for using all versions of
   HTTP over TCP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 3, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Stenberg                  Expires April 3, 2016                 [Page 1]

Internet-Draft                TCP for HTTP                  October 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2
   2.  TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Initial Congestion Window . . . . . . . . . . . . . . . . . .   3
   4.  Packet Pacing . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Explicit Congestion Control . . . . . . . . . . . . . . . . .   3
   6.  Tail Loss Probes  . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Slow Start after Idle . . . . . . . . . . . . . . . . . . . .   3
   8.  Nagle's Algorithm . . . . . . . . . . . . . . . . . . . . . .   3
   9.  Half-close  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   10. Abort . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   11. Keep-alive  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   4
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   4
     14.2.  Informative References . . . . . . . . . . . . . . . . .   4
     14.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   HTTP [RFC7230] is currently defined to use TCP [RFC0793], and its
   performance can depend greatly upon how TCP is configured.  This
   document records best current practice for using HTTP over TCP, with
   a focus on improving end-user perceived performance.

   These practices are generally applicable to HTTP/1 as well as HTTP/2,
   although some may note particular impact or nuance regarding a
   particular protocol version.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  TCP Fast Open

   TCP Fast Open (a.k.a.  TFO, [RFC7430]) allows data to be sent on the
   TCP handshake, thereby allowing a request to be sent without any
   delay if a connection is not open.

   TFO requires both client and server support, and additionally
   requires application knowledge, because the data sent on the SYN
   cannot be idempotent.  Therefore, TFO can only be used on non-



Stenberg                  Expires April 3, 2016                 [Page 2]

Internet-Draft                TCP for HTTP                  October 2015


   idempotent, safe methods (e.g., GET and HEAD), or with intervening
   negotiation (e.g, using TLS).

   Support for TFO is growing in client platforms, especially mobile,
   due to the significant performance advantage it gives.

3.  Initial Congestion Window

   [RFC6928] specifies an initial congestion window of 10, and is now
   fairly widely deployed server-side.  There has been experimentation
   with larger initial windows, in combination with packet pacing.

4.  Packet Pacing

   TBD

5.  Explicit Congestion Control

   Apple deploying in iOS and OSX [1].

6.  Tail Loss Probes

   draft [2]

7.  Slow Start after Idle

   net.ipv4.tcp_slow_start_after_idle = 0

8.  Nagle's Algorithm

   Most implementations disable

9.  Half-close

   Client or server is free to half-close after a request or response
   has been completed; or when there is no pending stream in HTTP/2.

10.  Abort

   No client abort for HTTP/1.1 after the request body has been sent.
   Delayed full close is expected following an error response to avoid
   RST on the client.

11.  Keep-alive

   TCP keep-alive likely disabled.  App-level keep-alive is required for
   long-lived requests to detect failed peers.




Stenberg                  Expires April 3, 2016                 [Page 3]

Internet-Draft                TCP for HTTP                  October 2015


12.  IANA Considerations

   This document does not require action from IANA.

13.  Security Considerations

14.  References

14.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing", RFC
              7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

14.2.  Informative References

   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/
              RFC6928, April 2013,
              <http://www.rfc-editor.org/info/rfc6928>.

   [RFC7430]  Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
              Raiciu, "Analysis of Residual Threats and Possible Fixes
              for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/
              RFC7430, July 2015,
              <http://www.rfc-editor.org/info/rfc7430>.

14.3.  URIs

   [1] https://developer.apple.com/videos/wwdc/2015/?id=719

   [2] http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01

Author's Address

   Daniel Stenberg

   Email: daniel@haxx.se
   URI:   http://daniel.haxx.se




Stenberg                  Expires April 3, 2016                 [Page 4]
