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

[Rob Gaddi]

Chris Angelico wrote:

> On Tue, May 17, 2016 at 2:06 AM, Grant Edwards
> <grant.b.edwards at gmail.com> wrote:
>> So, when a browser wants to load a page that has the main html file, a
>> css file, a javascript library or two, and a few icons and background
>> bitmaps, they browser opens up a half-dozen SSL connections in
>> parallel.
>>
>> That's fine when the server is Facebook's server farm.
>>
>> But when it's a small embedded device running at 40MHz with a
>> single-threaded web server and software crypto, it turns a 2-second
>> page load time into a 15-second page load time.
>> ...
>> So now I'm going to set up a simple Python HTTP server to try some
>> other approaches:
>>
>>   1) Only allow the listening socket to accept 1 connection at a time.
>>
>>   2) Accept the TCP connection, but don't allow the SSL handshaking to
>>      start on the "extra" connections.
>>
>>   3) ???
>>
>>   4) Profits!
>>
>> Any ideas?
>
> If your server is single-threaded, it ought to be processing only one
> connection at a time anyway. Are you sure parallel connections are the
> problem here?
>
> The solution might actually be to move all your static files
> elsewhere. Slap 'em up onto github.io or something, and then the
> browser is free to make all the parallel connections it likes; your
> embedded device can just serve the stuff that actually varies
> (presumably the main HTML file). I know that isn't what you asked for,
> but it's something to consider :)
>
> ChrisA

Oooof.  Not to be rude, Chris, but your "software guy" is showing. 
Grant's got the right of it; if you're shipping a box with an RJ-45 and
a webpage, and you want the customer to be able to always make it
work, then it needs to be a self-contained entity.  The belief that your
external dependancies will always be there is why leftpad was able to
break everything, and why Google just bricked a bunch of people's
expensive Revolv Hubs.

The problem with processing one connection at a time is that TCP
doesn't transmit your data when you ask it to, it holds onto it for a
couple hundred ms to make sure you didn't have anything else to say on
that socket.  Those build up, and you get horrific page load times
because the system is having to single track all the files.

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, and he had
to gut and redesign the web server to support parallel connections. 
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.

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