Closed Bug 246093 Opened 20 years ago Closed 8 years ago

max-connections-per-server not respected

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jwbaker, Unassigned)

Details

Attachments

(2 files)

2.45 KB, text/html
Details
158.86 KB, application/octet-stream
Details
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.
Sounds pretty bad.  I'm looking forward to seeing your testcase.
Attached file 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.
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??
Attached file 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)
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!
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?
Could you also please test Mozilla 1.7 rc3?
I can also reproduce the problem on a fresh profile and with 1.7rc3 (20040608).
Does the page finally load?
Yep, always loads.  The problem is never failed requests, just spurious
connect() and DoSing the server.
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Oliver, could you perhaps test this?
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: