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

Grant Edwards invalid at invalid.invalid
Fri Nov 8 22:14:44 CET 2013

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

More information about the Python-list mailing list