OT: How to tell an HTTP client to limit parallel connections?

[Grant Edwards]

On 2013-11-08, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, Nov 9, 2013 at 7:48 AM, Grant Edwards <invalid at invalid.invalid> wrote:
>> All I have control over is the server. I have no influence over the
>> client side of things other than what I can do in the HTTP server.
>
> Hmm. Then the only way I can think of is a reverse proxy that can
> queue, handle security, or whatever else is necessary. Good luck. It's
> not going to be easy, I think. In fact, easiest is probably going to
> be beefing up the hardware.
>
> Oooh.... crazy thought just struck me. What's your source of entropy?
> Is it actually the mathematical overhead of cryptography that's taking
> 2-3 seconds,

Yes.  AFAICT, it is.  Some of the key-exchange options are pretty
taxing.  I can speed things up by about a factor of 4 by disabling the
key-exchange algorithms that have the highest overhead, but those are
the algorithms that the SSL clients seem to prefer.  I'm reluctant to
force them further down their preference list, lest I end up not being
able to support some clients.

> or are your connections blocking for lack of entropy?

Nope. The cyrpto libraries we're using don't do that.  I'm not
entirely happy with the entropy generation used.  I wish I had more
sources of "real" randomness, but at least they don't block.

> You might be able to add another source of random bits, or possibly
> reduce security a bit by allowing less-secure randomness from
> /dev/urandom.

It's not Unix-like OS, but that's more or less what's happening.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm sitting on my
                                  at               SPEED QUEEN ... To me,
                              gmail.com            it's ENJOYABLE ... I'm WARM
                                                   ... I'm VIBRATORY ...