OT: limit number of connections from browser to my server?

[Rob Gaddi]

Grant Edwards wrote:

> On 2016-05-16, Rob Gaddi <rgaddi at highlandtechnology.invalid> wrote:
>
>> Grant, the bad news is that I know this because our firware guy had
>> _exactly_ this problem, with exactly your scenario, about a month ago.
>> http, not https, but the problem remains the same but for some heavy
>> math. After a lot of door knocking, poking, prodding, and hoping, the
>> conclusion he reached was that what you want can't be done,
>
> Bummer.
>
>> and he had to gut and redesign the web server to support parallel
>> connections.
>
> Mine does (in effect) support parallel connections.  With HTTP it all
> works fine: browser opens 4-5 connections in parallel; sends requests
> on all of them; responses come back on all of them.  A few of the
> connections then get reused for additional requests, and so on.
>
>> Turned a 45 second page load into south of one, but it wasn't pretty and
>> chewed up a bunch of RAM.  We had 256K to play in; I'm assuming you've
>> got closer to 32K.
>
> I've actually got plenty of RAM.  I just can't afford the CPU time it
> takes to do the public-key crypto stuff that happens each time an SSL
> connection starts up.
>
> I'm hoping that if I refuse additional connections (or stall them
> before the SSL handshake), I can convince the browser to make use of
> extant connections.
>
> However, in my case, there are some cases where a connection can't be
> re-used because the server doesn't know how big the reply is going to
> be and the only way to identy "end of reply" is for the server to
> close the connection.  In theory I can fix that by adding support to
> the server for chunked encoding in the cases where the reply size is
> unknown.  But that won't do me any good if the browser opens 4 more
> connections before it's even seen the response from the first one.
>

That's easy then.  Redesign the product to outsource the crypto to a
custom-designed FPGA which pretends to be DDR on the memory bus to
maximize data throughput.  By the time you're done with all of that, the
HTTP standards should have evolved to obviate the original problem.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.