Closed Bug 79154 Opened 23 years ago Closed 23 years ago

We do a new SSL negotiation for each image

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: jesup, Assigned: dougt)

References

(
URL
)

Details

(Keywords: perf) 

Note: this may be a PSM issue; I'm not sure if necko or PSM controls this, or if
it's a necko<->psm interface issue.

From the news article in netscape.public.mozilla.performance
20010507101508.27595.qmail@nwcst338.netaddress.usa.net
written by subhash_chopra@usa.net (Subhash Chopra):


Outputs from SSLDump with Mozilla and various other browsers(ie IE,Opera
    etc....) revealed the following facts:

    In case of a HTTPS request for a web site with say 4 gifs, mozilla opens
up 4
    TCP connections and do the SSL handshake including the clientkeyexchange,
    server certificates .... for each one of them. 
    While other browsers like IE 5 or opera 5, open up 1 TCP connection and do
a
    complete SSL handshake on it... and then these browsers reuse use the
session
    id and negotiated values of this first TCP session for the other 3
    connections which are opened for each gif ( for the other 3 TCP
connections
    it only performs HELLO and CHANGECIPHERSPEC protocol ).
    This approach adds to performance in terms of the size of bandwidth and
time.

    I just wonder........ why mozilla is doing it differently as the resuse
of
    negotiated keys would result less turnaround time.
    I am not able to figure out the reason for this anomolus behaviour.
Keywords: mozilla0.9.1, perf
This has been reported before.  I can not find a possible dupe candidate though...
cc'ing pavlov
this would either be http or psm.. not sure which.
-->psm
Assignee: neeti → mstoltz
Component: Networking → Security: General
QA Contact: tever → ckritzer
really ->PSM
Component: Security: General → Client Library
Product: Browser → PSM
Version: other → 2.0
QA > junruh
Assignee: mstoltz → ddrinan
QA Contact: ckritzer → junruh
Target Milestone: --- → 2.0
I've read several reports that this is happening in PSM 1.x, 
but have not received any that it is happening in PSM 2.x.
If we're still fixing bugs in PSM 1.x, then I think this bug
should be investigated and fixed.  I think it would also be
good for someone to investigate whether PSM 2.x is doing this
or not.  

The "normal" flow of events is that the browser contacts the 
https server and gets an https/html page.  Then it starts to 
download the images.  If the images come from the same https
server that served the html page, the connections to fetch
the images will reuse the SSL session established when the 
web page was fetched.  

If the images are fetched from a different server than the one
that served the html page, and the connections to the image
server are all launched in parallel, then the behavior described
above can and does occur.  Each connection creates a new SSL
session because there is no other SSL session already established
when it begins the SSL handshake.  This behavior is not a defect
in the SSL code.  

One solution to the problem of multiple images coming from a 
separate https image server would be to make sure that the first
image (or style sheet or java or java script, or whatever) is
fetched before any other requests to the same image server are
initiated.  This does not require serialization of all the image
requests to the image server.  It only requires that all but one
of the requests be held off until the first request has been 
succesfully sent.  
2 more thoughts.

= After the first request to an https server has been sent,
all the other requests to that server can be lauched in parallel.

- I'd think the logic to do this would NOT be in PSM, but rather
in higher level code (e.g. http, or the browser proper).  But 
that's a guess on my part.
Reassigning this bug to necko.
Component: Client Library → Networking: HTTP
Product: PSM → Browser
Target Milestone: 2.0 → mozilla0.9.1
Version: 2.0 → other
Assiging to necko module owner, gagan.
Assignee: ddrinan → gagan
This bug needs more investigation in order to figure out where the problem is.

1. The problem described occurs only when the images come from a separate server 
than the one that serves the html page,  or

2. The problem occurs regardless of which server serves the images; that is it 
even occurs when the images come from the same server as the html page itself.

In the first case, the problem is probably in necko.

In the second case, this is a bug in psm and/or NSS, and the security team 
should fix it.

Can anyone conclusively demonstrate where the problem is i.e. case 1 or case 2?
lets keep this investigation going...  if we get something for 0.9.1
lets bring it back in to that release.  else -> 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Let me clarify something.

The investigation is to determine wether there are two bugs, or merely one.

We _know_ that if images come from a different server than the html page,
then the behavior described above will occur.  That is why this bug is now
assigned to necko.  This is a known bug.

We don't (yet) know whether or not it also occurs when the images come from 
the same server as the html page.  If we find that it is, then there is 
ALSO a PSM/NSS bug.  
Created two pages. One has local images the other gets its
images from another https server.
Hope this helps figuring out whether this is also
a PSM bug.
https://beaver.netscape.com/bug97154-same_domain.html
https://beaver.netscape.com/bug97154-mixed_domain.html

Terry and I believe that this is caused by the
NSPR bug #83845.
Depends on: 83845
->dougt (need your ssl hat here doug)
Assignee: gagan → dougt
Priority: -- → P2
John, can you verify that this?  Sounds like wtc and terry believe it is fixed.
Marking fixed. Tested on the 2001060509 WinNT, Mac, Win98, and Linux commercial 
builds. An SSL test page I have setup in-house with 100 pictures on it downloads 
in an estimated 15-20% of the time as compared to yesterday's builds. I don't 
think SSL speed will be a major complaint anymore.
Even Win98 turned in a time of 4.18 seconds as compared to 2 minutes for 
Netscape 6.0.
URL: https://junruh.mcom.com/knox/color/co...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.