Re: [tcpm] TCP Tuning for HTTP - update

"Adrien de Croy" <> Wed, 17 August 2016 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E92712D0AC for <>; Wed, 17 Aug 2016 15:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ehPZ2GoCal74 for <>; Wed, 17 Aug 2016 15:55:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55CC612B016 for <>; Wed, 17 Aug 2016 15:55:57 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ba9gi-0007dZ-Mz for; Wed, 17 Aug 2016 22:51:56 +0000
Resent-Date: Wed, 17 Aug 2016 22:51:56 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ba9gc-0007cJ-46 for; Wed, 17 Aug 2016 22:51:50 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ba9ga-0006cB-9N for; Wed, 17 Aug 2016 22:51:49 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v9.0.0 (Build 5855)) with SMTP id <>; Thu, 18 Aug 2016 10:51:18 +1200
From: Adrien de Croy <>
To: Joe Touch <>, Willy Tarreau <>
Cc: Mark Nottingham <>, "" <>, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
Date: Wed, 17 Aug 2016 22:51:18 +0000
Message-Id: <embe2271fe-c61d-4c7c-84fd-bac7efa56593@bodybag>
In-Reply-To: <>
Reply-To: Adrien de Croy <>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-0.514, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ba9ga-0006cB-9N 8b92da9f28ef10b2c5604d412f4e3ffe
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32292
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

------ Original Message ------
From: "Joe Touch" <>

>They want something different for a variety of reasons - the same kind
>of airtight logic by which TBL developed HTTP instead of using FTP (he
>said that you'd only typically need one file from a location, so why
>open 2 connections? now we're stuck trying to mux control and data
>rather than having a proper solution that already existed at the time -
>it took nearly a decade for HTTP servers to catch up to the performance
>of FTP).
Whilst I've been finding this discussion very informative and 
interesting, I have to raise an objection on this point.

FTP was never going to be suitable for the web, and a very simple RTT 
analysis shows that.

Apart from initial 3 way TCP handshake and close, which is the same for 
both, with http you have a request and a response, whereas FTP requires 
you to wait for the server welcome, log in, negotiate another port, set 
up a data connection in addition to retrieving the file

So it's at minimum 5 round trips more.

Then try adding all the firewall issues due to transmitting data 
connection endpoint information over the control connection and it's no 
surprise FTP is not favoured for downloads.
So FTP was never going to be a "proper solution" for the web without a 
complete re-architecture.