Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #108667 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-16 16:06 +0000
    Re: OT: limit number of connections from browser to my server? Steven D'Aprano <steve@pearwood.info> - 2016-05-17 03:11 +1000
      Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-16 19:28 +0000
      Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-16 22:09 +0000
        Re: OT: limit number of connections from browser to my server? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-17 18:06 +1200
          Re: OT: limit number of connections from browser to my server? Marko Rauhamaa <marko@pacujo.net> - 2016-05-17 09:23 +0300
            Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-17 14:23 +0000
          Re: OT: limit number of connections from browser to my server? Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-17 14:22 +0000

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

This is not Python specific, though I'm turning to Python to do some
experimentation and to try to prototype a solution.

Is there any way to limit the number of connections a browser uses to
download a web page?  Browser writers seems to assume that all https
servers are massively parallel server farms with hardware crypto
support.

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.

When we first added https support years ago, this wasn't a problem.  A
browser would open _an_ SSL connection (handshake time around 2
seconds), and then send mutliple HTTP requests over that connection to
grab a half-dozen files.  Each HTTP request would take a few tens of
milliseconds, and life was good.

Now that 2-second page load takes up to 10-15 seconds because of all
the SSL connection setup overhead involved in handling a half-dozen
"parallel" connections.

I was _hoping_ there was an HTTP header or HTML meta tag that could be
used to smack the browser with a clue bat, but there doesn't seem to
be.  [Please tell me I'm wrong...]

Some browsers used to have a global "max parallel connections" setting
that the user could control, but a) that seems to be gone from recent
versions of browsers I've looked at, and b) we can't ask customers to
change that setting just for the benefit of our devices.

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?

-- 
Grant Edwards               grant.b.edwards        Yow! What's the MATTER
                                  at               Sid? ... Is your BEVERAGE
                              gmail.com            unsatisfactory?

[toc] | [next] | [standalone]

#108674

On Tue, 17 May 2016 02:06 am, Grant Edwards wrote:

> This is not Python specific, though I'm turning to Python to do some
> experimentation and to try to prototype a solution.
> 
> Is there any way to limit the number of connections a browser uses to
> download a web page?

Well, you control the server. It's your own server, right? Can you not tell
the server to limit how many connections it accepts from any one client?

That's not a rhetorical question -- I don't know the answer, and I know
nothing about HTTPS server. But I would imagine that they don't allow
unlimited connections from each client. Can you tell your server to only
allow N connections from each client, where N is small enough?

I suppose that's your question, right? Of you were using Apache, this might
point you in the right direction...

http://serverfault.com/questions/252555/limit-simultaneous-connections-per-ip-with-apache2



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#108688

On 2016-05-16, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 17 May 2016 02:06 am, Grant Edwards wrote:
>
>> This is not Python specific, though I'm turning to Python to do some
>> experimentation and to try to prototype a solution.
>> 
>> Is there any way to limit the number of connections a browser uses to
>> download a web page?
>
> Well, you control the server. It's your own server, right? Can you
> not tell the server to limit how many connections it accepts from
> any one client?

Definitely.

> That's not a rhetorical question -- I don't know the answer, and I
> know nothing about HTTPS server. But I would imagine that they don't
> allow unlimited connections from each client. Can you tell your
> server to only allow N connections from each client, where N is
> small enough?

Yep, I should be able to do that.  I can even reduce it to a simpler
case of only allowing N connections total.  Saying we only support one
browser session at a time is probably acceptable if it solves the long
https page load times.

Before I go to the effort of hacking up the server to change how/when
it accepts connections[1], I want to try prototyping something like
that Python to make sure that refusing or stalling a "parallel"
connection won't cause the browser to throw up its hands and tell the
user "this page can't be loaded."

[1] We didn't write the server.  We licensed source from somebody
    yonks ago.  It was then abaondoned and maintined by us and by
    applying patches we got from other users in our situation.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm RELIGIOUS!!
                                  at               I love a man with
                              gmail.com            a HAIRPIECE!!  Equip me
                                                   with MISSILES!!

[toc] | [prev] | [next] | [standalone]

#108702

On 2016-05-16, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 17 May 2016 02:06 am, Grant Edwards wrote:
>
>> This is not Python specific, though I'm turning to Python to do some
>> experimentation and to try to prototype a solution.
>> 
>> Is there any way to limit the number of connections a browser uses to
>> download a web page?
>
> Well, you control the server. It's your own server, right? Can you not tell
> the server to limit how many connections it accepts from any one client?

I tried two approaches on Linux using a Python server prototype that
has some code I wrote that accepts connections and then calls
SimpleHTTPRequestHandler.  For starters I'm sticking with HTTP (no
SSL) and just stuck a 2-second (delay to simulate SSL startup time)
between the accept() returning and the call to the request handler .

 1) Refuse to accept more than one connection at a time by closing the
    listening socket while there is an active connection.  On both
    Firefox and Chrome, this gets you the initial HTML page and
    perhaps one addition file (css, js, png, whatever).  The files
    that the browser normally requests using the addition 4-5 requests
    simply fail (broken img, missing css and js files).  The Chrome
    network monitor thingy shows those as "failed".  In my test case,
    only allowing a single connection resulted in 7 failed files out
    of the 9 which are loaded for the page.

 2) Limit the listen() backlog to 0.  On Linux, a 0 backlog doesn't
    prevent the stack from sending back a SYN/ACK in response to a
    SYN.  It just prevents the connection from ACKing anything else
    that's sent by the client.  This makes the client think the
    connection is open. In my tests, the browser then sits there
    waiting for a response on what it _thinks_ is an open TCP
    connection.  It eventually times out and fails.

It looks to me like the browsers decide how many connections to use
(in my test case it's usually around 5), assigns individual files to
each connection, and then presses "go".  If any connection fails,
stalls, or falls over, the files assigned to that connection are
failed rather than fetched from an extant working connection.

Next I'll try adding the SSL layer -- perhaps stalling the connection
after the accept() and before the SSL handshake will have a different
affect on the browser that stalling a plaintext TCP connection before
responding to the request.

-- 
Grant Edwards               grant.b.edwards        Yow! PARDON me, am I
                                  at               speaking ENGLISH?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#108717

Is there some way you can get more stuff into a single
html page? For example, use inline css and image data
instead of delivering them as separate files.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#108719

Gregory Ewing <greg.ewing@canterbury.ac.nz>:

> Is there some way you can get more stuff into a single
> html page? For example, use inline css and image data
> instead of delivering them as separate files.

Better yet, is there some way you could send less stuff?

    There are two points of note here.

    1. The top ten sites are significantly lighter than the rest (worth
       noting if you want to be a top website).

    2. While the web in general is steadily getting heavier, the top
       sites have turned the corner.

    <URL: https://mobiforge.com/research-analysis/the-web-is-doom>


Marko

[toc] | [prev] | [next] | [standalone]

#108741

On 2016-05-17, Marko Rauhamaa <marko@pacujo.net> wrote:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>
>> Is there some way you can get more stuff into a single
>> html page? For example, use inline css and image data
>> instead of delivering them as separate files.
>
> Better yet, is there some way you could send less stuff?

No.  Somebody else decides what the pages look like and behaves.  I
don't get to toss out logos, background images, customized checkbox
glyphs, etc.  I get to make it work. :)

-- 
Grant Edwards               grant.b.edwards        Yow! I have a very good
                                  at               DENTAL PLAN.  Thank you.
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#108740

On 2016-05-17, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Is there some way you can get more stuff into a single
> html page? For example, use inline css and image data
> instead of delivering them as separate files.

Yes.  That's one option that's still on the table, and that's probably
what the smart money is betting on: use server-side includes for css
and javascript files.  For image data, I'd need to add a
server-side-include-and-base64-encode capability, but that shouldn't
take more than a couple hours.


Then the HTML editing starts...

I've seen examples of including base64 image data in HTML <img> tags,
but don't know how to do it in CSS for things like backgrounds.

That said, I've got two more things to try to see if I can convince
browsers to behave:

 1) Stall the connection after the TCP connection opens but before the
    SSL handshake.

 2) Try listen(0) on my BSD-derived network stack to limit the number
    of TCP connections.  IIRC, BSD behaves differently than Linux when
    the listen queue overflows.

I doubt either one will help -- and even if they do, it'll probably
all fall apart again when new browser versions come out.

I'm also looking into SSL session resumption.  My SSL stack appears to
support it, but I can't tell if it's being used or not by browsers.

It may be a moot point.  All of the descriptions I've read about SSL
session resumption say it's for low-overhead reopening of a previously
closed connection.  That's not what I need: I need to speed up opening
of a new connection while the first connection is still open.

-- 
Grant Edwards               grant.b.edwards        Yow! Mary Tyler Moore's
                                  at               SEVENTH HUSBAND is wearing
                              gmail.com            my DACRON TANK TOP in a
                                                   cheap hotel in HONOLULU!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web