Re: [tcpm] TCP Tuning for HTTP - update

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "Joe Touch" <[e-mail]>
To: "Adrien de Croy" <[e-mail]>; "Willy Tarreau" <[e-mail]>
Cc: "Mark Nottingham" <[e-mail]>; "[e-mail]" <[e-mail]>; 
"HTTP Working Group" <[e-mail]>; "Patrick McManus" 
<[e-mail]>; "Daniel Stenberg" <[e-mail]>
Sent: 18/08/2016 11:01:57 AM
Subject: Re: [tcpm] TCP Tuning for HTTP - update

>This is a bit of a side track, but...
>
>On 8/17/2016 3:51 PM, Adrien de Croy wrote:
>>
>>
>>  ------ Original Message ------
>>  From: "Joe Touch" <[e-mail]>
>>
>>>  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
>
>That's only the first time you go somewhere new. You don't need to 
>close
>both ports so quickly; the control channel can stay open and you thus
>avoid HOL blocking between data and control (and thus the need to
>chunk-and-mux within persistent HTTP), which increases other delays for
>HTTP.
You still need to send another PORT/PASV and wait for the response 
before making another TCP connection for data, since you can't re-use 
this one.

So subsequent requests to the same server will be quicker, still at 
least 3 round-trips more than a subsequent http request on a persistent 
connection.

>
>Neither protocol matches exactly what is really needed for a true
>transaction-oriented protocol.
We are probably in agreement here.

>
>>  ...
>>  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.
>
>FTP had a passive mode even back then that avoids this issue. It also
>had suspend/resume, compression, and format conversion.

Those all take more round trips to negotiate.  As for format 
conversion..... bad idea, never should have been the server's job.

We've seen a lot of server-side firewall problems with PASV as well.

Adrien


>
>Joe