Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP

[Willy Tarreau <[e-mail]>]

[ I thought you also forwarded my response to the list but it seems
  not, so here it comes again, please keep the list CCed in future
  conversations, that's useful for everyone ]

On Sat, Mar 05, 2016 at 08:26:53AM +0100, Willy Tarreau wrote:
> Hello Kari,
> 
> On Sat, Mar 05, 2016 at 08:26:27AM +0200, Kari Hurtta wrote:
> > 
> > ( not posted to list )
> > 
> > https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0330.html
> > 
> > > What 17-year old wheels ? The only one I know about consists in patching
> > > kernels to force shorter timewaits in order not to block outgoing
> > > connections when the rate approaches 1000/s. Until we have 32 bits for
> > > the source port, these are the only two options. At some point one must
> > > not wonder why more and more the transport is migrating to userland :-/
> > 
> > 
> > Not actually, if talk is about reverse-proxy which sits front
> > of web server pool.
> > 
> > These two are not ONLY options.
> > 
> > One possiblity: (which certain devices uses)
> > 
> > * Do not "nat" connection from reverse proxy to webserver to 
> >   proxy's local address. Instead use same source address on that 
> >   connection than what was on http -request which reverse
> >   proxy reserved from client.
> >   
> >   In that may there equal number (or bigger number) of available 
> >   (source address, source port, target address, target port)
> >   tupples than what was on client which sent request to
> >   reverse proxy (*).
> 
> Yes but this is limited to very few deployment scenarios, where
> the reverse proxy can be installed in cut-through between all
> the clients and the servers. This type of deployment is very
> rare nowadays because applications look more like a set of
> components which all interact together and which have to pass
> through the LB as well to reach another server on the same LAN,
> possibly coming back to the same machine.
> 
> This is not usable in cloud environments (flat networks), with
> CDNs (remote proxies) nor in all environments where the proxies
> are more application servers than infrastructure components and
> which do not run with root priviledges.
> 
> >   Web servers neeed to be default route (for connections
> >   received to that interface which sits on network between
> >   reverse proxy and webserver) to poit to reverse proxy.
> 
> Yep definitely. Also there's another issue which comes with
> doing this, it's that you have to have as short a TIME_WAIT
> timeout as your shorter client's, otherwise some clients will
> not get the reverse-proxy to forward their connection to the
> server as it will act as sort of a "time-wait amplifier",
> keeping these states longer than the client.
> 
> >   Reverse proxy need to able open TCP connection whit
> >   any source address (not just local address).
> >   
> >   Actually from this there is variations:
> >   
> >   # reuse connection from proxy to web server for several
> >     http request. On that situation web server does not
> >     see original source address address of client (but
> >     instead of some unrelated client -- this have some
> >     affects to access control)
> 
> This is a no-go in most environments, especially when it comes
> to logging or DoS/brute-force protection. Also many proxy to
> server connection cannot safely be shared between incoming
> clients because normally you should only send an idempotent
> request over pre-existing connections if it's the first one
> of this connection, since the proxy is not allowed to replay
> non-idempotent ones and the client will not replay the first
> one on failure. And some protocols do not allow connections
> to be shared. For example, SSL advertises the SNI or presents
> the client's cert during the handshake. That connection sort
> of becomes "private" at this point.
>    
> >   # "Nat" source address, but use pool of source addresses
> >     instead. If you use say 500 different source address,
> >     then you quite many available (source address, 
> >     source port, target address, target port), so you can
> >     handle to 500 * 1000 connections per second from
> >     reverse proxy to webserver.
> 
> That's what is done in environments which need more than 64k
> connections per server, but you'll agree that it's an aberration
> to consume a lot of internet addresses that remain unused most
> of the time just to work around a timing issue!
> 
> > You can guess what reverse proxy product uses these
> > kind solutions.  Perhaps there is also others.
> 
> Oh yes I know quite well what type of proxy supports this, as I
> have implemented this type of transparent proxying into haproxy.
> However I note that while it was an absolute requirement about
> 5 years ago for various deployment situations, nowadays we don't
> see any more demand for this nor situations where it can still
> be deployed since networks are less hierarchical and flatter
> with some DMZ. The *only* remaining case is SMTP/IMAP, and even
> some SMTP servers have implemented haproxy's proxy protocol to
> get rid of the shortcomings of transparent proxying.
> 
> > So it is not that you have only two options.
> 
> Absolutely, your points should also be noted in the doc, it's
> too bad you didn't post to the list :-)
> 
> Regards,
> Willy
>