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 © 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.

## 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-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.

## 6. Tail Loss Probes

draft

## 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.

## 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, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[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>.

## Author's Address

Daniel Stenberg
EMail: daniel@haxx.se
URI: http://daniel.haxx.se