max-connections-per-server not respected

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
15 years ago
3 years ago

People

(Reporter: jwbaker, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

2.45 KB, text/html
Details
158.86 KB, application/octet-stream
Details
(Reporter)

Description

15 years ago
I have found a case where max-connections-per-server is not respected.  I have a
page with a script function that adds hundreds of images to the page in an
onClick handler.  The images are added by cloning an <img> node and setting the
src.  During this test Mozilla will open hundreds of parallel connections to the
server.  This is not ideal, it can basically DoS the remote end.  I'll attach a
simplified testcase.

Comment 1

15 years ago
Sounds pretty bad.  I'm looking forward to seeing your testcase.
(Reporter)

Comment 2

15 years ago
Created attachment 150390 [details]
Testcase

The testcase creates 41 <img> elements quickly.  On my local configuration
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Galeon/1.3.15
(Debian package 1.3.15-2)), Mozilla sends 41 SYN packets immediately, implying
41 simultaneous requests.

Before running the test, I disabled my proxy and cleared my cache.

Comment 3

15 years ago
Hmm... I cannot reproduce the problem.  Can you please provide a HTTP log using
the steps described here:

http://www.mozilla.org/projects/netlib/http/http-debugging.html

thanks!

It would also help if you tested Mozilla 1.7rc2 or a recent trunk build.  I
doubt Mozilla 1.6 has this problem since very little has changed in the HTTP
backend.

Perhaps this has something to do with Galeon??
(Reporter)

Comment 4

15 years ago
Created attachment 150393 [details]
HTTP log

I don't know how to interpret this log, so I don't know if it's helpful or not.
 Mozilla runs much more slowly with the logging turned on, so I can't be sure
that it's even possible to reproduce the problem with logging.

However, I did see the problem during this log capture, as you can see from
this tcpdump output (a couple dozen uninterrupted SYNs):

16:57:53.968429 65.198.37.66.11796 > ichart1.finance.vip.dcn.yahoo.com.www: S
2055934905:2055934905(0) win 5840 <mss 1460,sackOK,timestamp 2416879667
0,nop,wscale 0> (DF)
16:57:53.972911 65.198.37.66.12264 > ichart1.finance.vip.dcn.yahoo.com.www: S
3151344535:3151344535(0) win 5840 <mss 1460,sackOK,timestamp 2416879671
0,nop,wscale 0> (DF)
16:57:53.977304 65.198.37.66.4176 > ichart1.finance.vip.dcn.yahoo.com.www: S
4238120410:4238120410(0) win 5840 <mss 1460,sackOK,timestamp 2416879676
0,nop,wscale 0> (DF)
16:57:53.982157 65.198.37.66.9294 > ichart1.finance.vip.dcn.yahoo.com.www: S
215664004:215664004(0) win 5840 <mss 1460,sackOK,timestamp 2416879680
0,nop,wscale 0> (DF)
16:57:53.986617 65.198.37.66.9466 > ichart1.finance.vip.dcn.yahoo.com.www: S
3941967128:3941967128(0) win 5840 <mss 1460,sackOK,timestamp 2416879685
0,nop,wscale 0> (DF)
16:57:53.991179 65.198.37.66.16316 > ichart1.finance.vip.dcn.yahoo.com.www: S
1375406457:1375406457(0) win 5840 <mss 1460,sackOK,timestamp 2416879689
0,nop,wscale 0> (DF)
16:57:53.995613 65.198.37.66.5628 > ichart1.finance.vip.dcn.yahoo.com.www: S
330267474:330267474(0) win 5840 <mss 1460,sackOK,timestamp 2416879694
0,nop,wscale 0> (DF)
16:57:54.000323 65.198.37.66.12046 > ichart1.finance.vip.dcn.yahoo.com.www: S
1458686685:1458686685(0) win 5840 <mss 1460,sackOK,timestamp 2416879699
0,nop,wscale 0> (DF)
16:57:54.004774 65.198.37.66.15240 > ichart1.finance.vip.dcn.yahoo.com.www: S
3625759585:3625759585(0) win 5840 <mss 1460,sackOK,timestamp 2416879703
0,nop,wscale 0> (DF)
16:57:54.009263 65.198.37.66.11216 > ichart1.finance.vip.dcn.yahoo.com.www: S
3658496684:3658496684(0) win 5840 <mss 1460,sackOK,timestamp 2416879708
0,nop,wscale 0> (DF)
16:57:54.013716 65.198.37.66.5190 > ichart1.finance.vip.dcn.yahoo.com.www: S
2054946667:2054946667(0) win 5840 <mss 1460,sackOK,timestamp 2416879712
0,nop,wscale 0> (DF)
16:57:54.018213 65.198.37.66.7452 > ichart1.finance.vip.dcn.yahoo.com.www: S
1238227813:1238227813(0) win 5840 <mss 1460,sackOK,timestamp 2416879716
0,nop,wscale 0> (DF)
16:57:54.022888 65.198.37.66.12232 > ichart1.finance.vip.dcn.yahoo.com.www: S
147668223:147668223(0) win 5840 <mss 1460,sackOK,timestamp 2416879721
0,nop,wscale 0> (DF)
16:57:54.027457 65.198.37.66.8074 > ichart1.finance.vip.dcn.yahoo.com.www: S
2235374099:2235374099(0) win 5840 <mss 1460,sackOK,timestamp 2416879726
0,nop,wscale 0> (DF)
16:57:54.032241 65.198.37.66.4416 > ichart1.finance.vip.dcn.yahoo.com.www: S
2288311124:2288311124(0) win 5840 <mss 1460,sackOK,timestamp 2416879731
0,nop,wscale 0> (DF)
16:57:54.036668 65.198.37.66.6150 > ichart1.finance.vip.dcn.yahoo.com.www: S
3144029861:3144029861(0) win 5840 <mss 1460,sackOK,timestamp 2416879735
0,nop,wscale 0> (DF)
16:57:54.041165 65.198.37.66.13532 > ichart1.finance.vip.dcn.yahoo.com.www: S
3077412308:3077412308(0) win 5840 <mss 1460,sackOK,timestamp 2416879739
0,nop,wscale 0> (DF)
16:57:54.045647 65.198.37.66.6850 > ichart1.finance.vip.dcn.yahoo.com.www: S
3747047117:3747047117(0) win 5840 <mss 1460,sackOK,timestamp 2416879744
0,nop,wscale 0> (DF)
16:57:54.050337 65.198.37.66.8564 > ichart1.finance.vip.dcn.yahoo.com.www: S
3292011289:3292011289(0) win 5840 <mss 1460,sackOK,timestamp 2416879749
0,nop,wscale 0> (DF)
16:57:54.054854 65.198.37.66.15706 > ichart1.finance.vip.dcn.yahoo.com.www: S
3659735193:3659735193(0) win 5840 <mss 1460,sackOK,timestamp 2416879753
0,nop,wscale 0> (DF)
(Reporter)

Comment 5

15 years ago
This bug may be more weird than I originally thought.  On my machine, Mozilla
causes one failed TCP connection for every success, like this

SYN
SYN,ACK
RST
SYN
SYN,ACK
ACK
...

The resets are caused by Mozilla connect()ing to the remote server, then
immediately closing the fd, as seen in this strace snippet:

[pid  9614] 1086829025.543631 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 40
[pid  9614] 1086829025.543825 connect(40, {sa_family=AF_INET,
sin_port=htons(80), sin_addr=inet_addr("66.218.71.161")}, 16) = -1 EINPROGRESS
(Operation now in progress)
[pid  9614] 1086829025.544662 close(40) = 0

What you see above is Mozilla opening and closing a socket in the space of 1
millisecond.  By the time the SYN,ACK comes back from yahoo, this socket is long
gone, and the kernel generates a RST.

This is very ill behavior!

Comment 6

15 years ago
Could you try creating a fresh profile?  The HTTP log shows a lot of channels
getting canceled for a variety of reasons.  Does the page finally load?

Comment 7

15 years ago
Could you also please test Mozilla 1.7 rc3?
(Reporter)

Comment 8

15 years ago
I can also reproduce the problem on a fresh profile and with 1.7rc3 (20040608).

Comment 9

15 years ago
Does the page finally load?
(Reporter)

Comment 10

15 years ago
Yep, always loads.  The problem is never failed requests, just spurious
connect() and DoSing the server.

Comment 11

13 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking

Comment 12

7 years ago
Oliver, could you perhaps test this?
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.