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

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

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

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

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

Willy

Received on Monday, 18 November 2013 09:03:08 UTC