Re: something I don't get about the current plan...

On 18/11/13 11:02 AM, Willy Tarreau wrote:
> Hi Yoav,
>
> On Mon, Nov 18, 2013 at 10:49:54AM +0200, Yoav Nir wrote:
>> On 18/11/13 7:14 AM, Willy Tarreau wrote:
>>> On Sun, Nov 17, 2013 at 06:56:37PM +0100, Roland Zink wrote:
>>>> 5) Using a separate port would help to separate HTTP/1 and HTTP/2
>>>> infrastructures and will make the solution more reliable
>>> In theory you're right. In practice it is more difficult to get a new
>>> port working in the short term. While using an existing port immediately
>>> tells you the other part is not willing to upgrade (but will not always
>>> tell you so), another port will require a long timeout to expire before
>>> realizing that the port is closed. Worse, with some SYN-protection
>>> firewalls, the connection will establish but nothing will pass, making
>>> you think the connection to the server was possible and that the server
>>> is slow to respond.
>> I disagree. With port 80, you have some chance of sneaking HTTP/2 by the
>> firewall, so if HTTP/2 goes to port 100 there will be less HTTP/2
>> initially. That is certain.
> Huh ? That's what I meant : "it is more difficult to get a new port working
> in the short term".
Depends on what you mean by "difficult". To me, anything where the user 
gets the resources at either HTTP/1 or HTTP/2 speeds is OK. Having cases 
where the user looks at a blank screen while the browser tries to use 
HTTP/2 when only HTTP/1 is available - that's difficult.
>
>> But there is no need at all for a timeout. Servers already have HTTP/1
>> on port 80. They would be able to add HTTP/2 on port 100, so both
>> services are available. Port 80 will be used by old clients and clients
>> that are stuck behind old middleboxes, whereas port 100 will be used by
>> new clients on the open Internet or behind new middleboxes.
> I meant the timeout on the client side! You don't know you're filtered
> until you try to escape.
You can optimize this the same way browsers detect proxies - you send a 
request to a well-known HTTP/1 + HTTP/2 site, and see which one (or 
both) return.  Then you can try HTTP/1 to the site you really want, and 
if you get an alt-svc header, move to HTTP/2 and cache which sites 
support HTTP/2. This is slightly slower than the happy eyeballs 
approach, and implementers can decide which suits them better.
>> A new client would start both connections at the same time. It will only
>> give up on one of them after they receive a good reply from the other.
> Sending two connections when you need only one is definitely not friendly
> to the existing infrastructure. I've already helped people whose server
> got knocked down by some browsers' pre-connect features, I can imagine
> that doubling the number of connections would not be nice at all...
Browsers already open several connections in HTTP/1. Opening one for 
each of HTTP/1 and HTTP/2 would not be worse.
>
>> And by "good reply" I don't mean ACK. I mean an HTTP response with
>> actual content.
> So you can only do this for idempotent requests then because you'd
> possibly send the same request twice. Also in mobile environments
> it will be an issue to have to download some objects twice.
>
>> So if all you get on port 80 is a redirect, you keep
>> going on both ports until at least one has yielded actual content. This
>> is similar to how many platforms do IPv6 vs IPv4, and it adds
>> complexity, not latency.
> Except that on IPv6 vs IPv4, only TCP connectivity is attempted and
> the first one wins, the request is not sent to both servers in parallel.
>
I kind of agree with that. Clients can make their own policy about 
whether they begin with HTTP/1 and wait for an alt-svc, or they try 
both, or they optimistically try for HTTP/2, and only fall back to 
HTTP/1 if that's not available. The only thing I'm pretty sure of, is 
that trying to mux both protocols on the same port is going to lead to 
more hurt, and specifically, harder-to-fix hurt.

Yoav