Some real world SSL stats for websockets/sockjs

1,542 views
Skip to first unread message

Eric Mill

unread,
Dec 9, 2012, 9:47:37 PM12/9/12
to SockJS
Hi all,

I've been running an experiment on my site where I connect every visitor to my sockjs server to stream their mouse motion. I wanted to see how switching using SSL would affect connectivity. I know it's already the consensus to use SSL, but I haven't seen anyone post actual numbers in a while.

Results of switching to SSL for a day: https://gist.github.com/4247942

The results compare the number of visits as reported in Google Analytics (as a control to measure overall change in visitors), and the number of people who managed to get through to my server via either websockets, xhr-streaming, or xdr-streaming (for IE9). 

Because I'm doing mouse motion streaming, I don't enable polling-based transports, which wouldn't be fast enough. I do enable iframe-eventsource, but the number of Opera users is too small for me to bother doing aggregation.

The gist has more details, but I'll repeat the upshot:
  • Switching to https/wss significantly boosted connectivity. Adjusted for overall change in visitors, Chrome's chance of getting through improved by 25%, Firefox by 5%, and iOS by 95%. IE10 seemed to show a big improvement, though the #'s are too small to be definitive.
  • Chrome, Firefox, and perhaps IE10 also saw the success rate of WS compared to XHR improve (fewer clients had to fallback to XHR). The proportion of WS to XHR on iOS stayed the same, even though connectivity through both of them doubled.
  • IE9, which can only connect through xdr-streaming, could not get through to an https URL. I observed a CORS cross domain error in the browser when I checked it out. The cert for the server belongs to my host and appears to be perfectly valid.
As a result of this, I'm going to leave SSL on for all but IE9 users. Hope others find this info useful!

-- Eric

Marek Majkowski

unread,
Dec 10, 2012, 2:55:55 AM12/10/12
to konk...@gmail.com, SockJS
On Mon, Dec 10, 2012 at 2:47 AM, Eric Mill <konk...@gmail.com> wrote:
> IE9, which can only connect through xdr-streaming, could not get through to
> an https URL. I observed a CORS cross domain error in the browser when I
> checked it out. The cert for the server belongs to my host and appears to be
> perfectly valid.
>
> As a result of this, I'm going to leave SSL on for all but IE9 users. Hope
> others find this info useful!

Many thanks for the excellent comparison!

I have some comments:
1) IE9 on https - that looks wrong.
a) did you set 'sockjs_url' option to https:// url
on the server side? (to avoid mixed-content-warning)
(nope, you don't:
https://github.com/isitchristmas/sockets/blob/66f900d33c8fbcbb7d84ccdbc126ba09cfca673d/app.js#L128)
b) doesn't it fall back to jsonp?
c) if we could prove that more browsers than usual
fall back to jsonp, you could increase this number
from 2 to 3 (ie: give xdr-streaming more time to finish
handshake)
https://github.com/sockjs/sockjs-client/blob/master/lib/trans-xhr.js#L66
2) Why for https chrome "visits in GA" < "websockets" ?
3) It would be nice to see a mean-time-to-connect for
SockJS vs mean-time-on-the-site.
Maybe the connections failed because
user left the site too quickly?

Thanks again for taking time to prepare this comparison,
it is very interesting :)

Cheers,
Marek

Eric Mill

unread,
Dec 10, 2012, 10:38:08 AM12/10/12
to Marek Majkowski, SockJS
On Mon, Dec 10, 2012 at 2:55 AM, Marek Majkowski <maj...@gmail.com> wrote:

I have some comments:
1) IE9 on https - that looks wrong.
  a) did you set 'sockjs_url' option to https:// url
      on the server side? (to avoid mixed-content-warning)
      (nope, you don't:
https://github.com/isitchristmas/sockets/blob/66f900d33c8fbcbb7d84ccdbc126ba09cfca673d/app.js#L128)

Ah, I hadn't thought to try that - I hadn't needed it without SSL. I'll try it out.
 
  b) doesn't it fall back to jsonp?

I'm doing mouse sharing, so jsonp-polling is not useful for me. Only streaming transports are, so I disable all polling transports.
 
  c) if we could prove that more browsers than usual
      fall back to jsonp, you could increase this number
      from 2 to 3 (ie: give xdr-streaming more time to finish
      handshake)
      https://github.com/sockjs/sockjs-client/blob/master/lib/trans-xhr.js#L66

That'd be a good thing to test - maybe someone else who can use polling will test it out.
 

2) Why for https chrome "visits in GA" < "websockets" ?

I don't know how GA measures "visits" - it's smaller than the number of raw hits ("pageviews"), because they group some hits together as a single visit. My connections number increases with every raw hit to my page that establishes a connection, so it's certainly possible that, with a sufficiently high connection success rate, the number of successful sockjs connections could be higher than the number of visits.

I would have listed pageviews instead of visits in my comparison, except I couldn't figure out how to get GA to break down pageviews by browser or OS - just visits.
 
3) It would be nice to see a mean-time-to-connect for
    SockJS vs mean-time-on-the-site.
    Maybe the connections failed because
    user left the site too quickly?

That's possible - it'd require fancier coordination between my client and server in order to record the mean-time-to-connect, though. FWIW, in my own testing connections have all been very quick. (Of course, people often leave the site quite quickly as well.)
 

Thanks again for taking time to prepare this comparison,
it is very interesting :)

Glad I could contribute.
 

Cheers,
    Marek

theyak

unread,
Dec 11, 2012, 1:41:43 AM12/11/12
to soc...@googlegroups.com
Thanks for sharing your data! I'll be testing SSL soon so I'll be comparing.

> Bear in mind: some people report that switching one's WebSocket port from port 80 to anything improves connection success rates.

I found this to be true as well. Switching from port 80 to 4000 improved my rate from about 90% to 95% success using sockjs-node. I had about 75-80% with sockjs-tornado, which for some as of yet unknown reason failed to allow IE to connect on port 80. This is exactly the opposite of what I originally expected as I know many schools and other public places block almost all ports except 80 and 443.

I believe a possible reason for greater success using SSL is that if someone loads your page with https://, and you aren't using SSL with SockJS, then often times the browser will cause a security exception in the background. That old "some components on this page are not secure" error.

Eric Mill

unread,
Dec 15, 2012, 4:43:26 PM12/15/12
to Marek Majkowski, SockJS
I don't think me not using sockjs_url is what's preventing IE9 from connecting via xdr-streaming over SSL. sockjs_url is only used for transports using iframes. For right now, I'm going to just have IE9 use the non-SSL URL, but I'll let you know if I figure out what the underlying issue is.


On Mon, Dec 10, 2012 at 2:55 AM, Marek Majkowski <maj...@gmail.com> wrote:

Eric Mill

unread,
Dec 15, 2012, 4:51:05 PM12/15/12
to Marek Majkowski, SockJS
I should've waited just a few more minutes to post - found the evidence I was looking for. IE8 and IE9, in their zeal to prevent HTTPS pages from fetching HTTP resources through XDR, mistakenly prevent HTTP pages from fetching HTTPS resources through XDR. There's even a Microsoft blog post acknowledging that it was a mistake:


I don't think there's a feasible workaround for sockjs, so it's just the way it's gonna be. Fortunately, in my situation I can simply drop IE9 users down to using a http:// address, since I'm using SSL only for increased connectivity success rates.

-- Eric

theyak

unread,
Dec 18, 2012, 12:37:18 PM12/18/12
to soc...@googlegroups.com, Marek Majkowski
I've encountered the same issue, although I have a lot more than just IE failing, but IE is always failing with https.

How do you configure sockjs to accept both http and https connections? When I simply change the connection url to http://, it aborts the connection when trying to connect to sockjs.

Eric Mill

unread,
Dec 18, 2012, 12:38:10 PM12/18/12
to yakk...@gmail.com, SockJS, Marek Majkowski
I'm running sockjs behind node-http-proxy on nodejitsu, and they terminate SSL at the proxy layer. So my sockjs server never has to actually deal with https itself, from its vantage point, everything is http. I would recommend something similar.

theyak

unread,
Dec 18, 2012, 1:34:06 PM12/18/12
to soc...@googlegroups.com, yakk...@gmail.com, Marek Majkowski
Thanks. Sadly, IE still isn't working for me when page is loaded with https:// and sockjs connection is downgraded to http://.

I have something like:


    // node-http-proxy is listening on 4443 and proxying to SockJS listening on 4080.
    if (/MSIE (\d+\.\d+);/.test(navigator.userAgent)) {
        var ieversion = new Number(RegExp.$1);
        if (ieversion <= 9) {
            server = "http://socket.example.com:4080/sockjs";
        }
    }

    var socket = new SockJS(server);

Is this similar what you have? I have verified that the server variable is properly being set to the http:// version.

Marek Majkowski

unread,
Dec 18, 2012, 1:36:54 PM12/18/12
to theyak, soc...@googlegroups.com
On Tue, Dec 18, 2012 at 6:34 PM, theyak <yakk...@gmail.com> wrote:
> Thanks. Sadly, IE still isn't working for me when page is loaded with
> https:// and sockjs connection is downgraded to http://.

I'm lost, why would you do that?

SockJS http:// --> http:// will work.
SockJS https:// --> https:// will work (but remember about the
sockjs_url option on the server side).

Why are you trying to do https:// --> http:// ?

Eric Mill

unread,
Dec 18, 2012, 2:00:42 PM12/18/12
to Majek _, theyak, SockJS
IE9 will not load http:// resources from a https:// page. This is intentional, and correct - no browser should. It's a security concern.

If your page is https://, you must run sockjs from an https:// streaming server. IE9 should handle that fine, as Marek said.

theyak

unread,
Dec 18, 2012, 4:23:34 PM12/18/12
to soc...@googlegroups.com, Majek _, theyak
Now I'm super confused.

Based on "Fortunately, in my situation I can simply drop IE9 users down to using a http:// address" it sounded like you were connecting to sockjs with http:// even when web page was loaded with https://. What exactly are you doing?

I was not able to get IE 9 to work at all with https, whether directed to an https:// sockjs url or http:// url. The latter I would not expect to work but the former I would expect to, but unfortunately, it did not. A lot, but not all of Chrome connections were failing as well with https. Firefox seemed good.

Marek Majkowski

unread,
Dec 18, 2012, 4:36:17 PM12/18/12
to theyak, soc...@googlegroups.com
On Tue, Dec 18, 2012 at 9:23 PM, theyak <yakk...@gmail.com> wrote:
> I was not able to get IE 9 to work at all with https, whether directed to an
> https:// sockjs url or http:// url. The latter I would not expect to work
> but the former I would expect to, but unfortunately, it did not. A lot, but
> not all of Chrome connections were failing as well with https. Firefox
> seemed good.

Can you try this on your IE9:
https://sockjs.popcnt.org/example-cursors.html
https://sockjs.cloudfoundry.com/example-cursors.html


Marek

Eric Mill

unread,
Dec 18, 2012, 5:52:41 PM12/18/12
to Larry Evans, SockJS, Majek _
Sorry for the confusion - on my site I drop IE9 users down to using an http:// connection to the streaming server.

So for most people:

For IE9 users:

That direction (http -> https) is what IE9 is *supposed* to support (and what everyone else supports), but they don't. The other direction (https->http) is what no one supports, and what no one should.

Hope that helps - again, sorry for not being clear.

-- Eric

P.S. If you want to see it in action - the site is http://isitchristmas.com, and it's live now.

theyak

unread,
Dec 18, 2012, 8:33:50 PM12/18/12
to soc...@googlegroups.com
Thanks. Got IE working.

Majek, the first link you provided failed on IE, the second worked with iframe-htmlfile. Surprisingly, with my app, I'm getting xdr-streaming with both http: and https:.

However, unlike Eric, I am not seeing a better connect rate by using SSL. In fact, the success rate is about 2% lower than usual, but I'm not overly concerned with that.

Marek Majkowski

unread,
Dec 19, 2012, 3:12:02 PM12/19/12
to yakk...@gmail.com, soc...@googlegroups.com
On Wed, Dec 19, 2012 at 1:33 AM, theyak <yakk...@gmail.com> wrote:
> Thanks. Got IE working.
>
> Majek, the first link you provided failed on IE, the second worked with
> iframe-htmlfile. Surprisingly, with my app, I'm getting xdr-streaming with
> both http: and https:.

That may be due to higher-than-usual latency from US to EU + SSL overhead.
It's possible that sockjs transport just hit a timeout.

Unless your server requires cookies, xdr shall be used.

> However, unlike Eric, I am not seeing a better connect rate by using SSL. In
> fact, the success rate is about 2% lower than usual, but I'm not overly
> concerned with that.

Interesting. Please do gather some data and share the numbers!

Marek
Message has been deleted

theyak

unread,
Dec 25, 2012, 9:52:31 PM12/25/12
to soc...@googlegroups.com
Ran the tests again. You can see the codebase at https://gist.github.com/766833e32b319755c47b/06f33614e3a15d47adb78803540902d0fa82d369 to let me know if I'm doing something stupid.

Test 1:
Using http:// when page load is http://:

94.388% success


Test 2:
Always using https:// no matter the page load protocol*:

 88.495% success


* Except IE 1-9


Nothing really noticed based on browser type or anything. Android and Nokia did significantly worse when always using https:// but they are both such a small percentage of hits that they do not affect the results much.

Actual results for test 1:

all
  Trials: 50107
  Connects: 48380
  Disconnects: 1013
  Messages: 47270
  Success Rate: 94.338

chrome
  Trials: 23205
  Connects: 22665
  Disconnects: 321
  Messages: 22150
  Success Rate: 95.454

msie
  Trials: 9067
  Connects: 8709
  Disconnects: 146
  Messages: 8543
  Success Rate: 94.221

firefox
  Trials: 10508
  Connects: 10162
  Disconnects: 285
  Messages: 9923
  Success Rate: 94.433

safari
  Trials: 3402
  Connects: 3108
  Disconnects: 83
  Messages: 2984
  Success Rate: 87.713

  Trials: 1708
  Connects: 1677
  Disconnects: 42
  Messages: 1657
  Success Rate: 97.014

opera
  Trials: 1256
  Connects: 1232
  Disconnects: 36
  Messages: 1211
  Success Rate: 96.417

android
  Trials: 32
  Connects: 22
  Disconnects: 0
  Messages: 20
  Success Rate: 62.500

iphone
  Trials: 738
  Connects: 727
  Disconnects: 19
  Messages: 722
  Success Rate: 97.832

nokia
  Trials: 185
  Connects: 74
  Disconnects: 80
  Messages: 57
  Success Rate: 30.811

other
  Trials: 6
  Connects: 4
  Disconnects: 1
  Messages: 3
  Success Rate: 50.000


Actual results for test 2:

all
  Trials: 50404
  Connects: 45147
  Disconnects: 3085
  Messages: 44605
  Success Rate: 88.495

firefox
  Trials: 11280
  Connects: 9584
  Disconnects: 1281
  Messages: 9469
  Success Rate: 83.945

chrome
  Trials: 23099
  Connects: 21788
  Disconnects: 695
  Messages: 21601
  Success Rate: 93.515

msie
  Trials: 8228
  Connects: 7549
  Disconnects: 248
  Messages: 7432
  Success Rate: 90.326

safari
  Trials: 3647
  Connects: 2479
  Disconnects: 541
  Messages: 2406
  Success Rate: 65.972

ipad
  Trials: 1976
  Connects: 1797
  Disconnects: 156
  Messages: 1787
  Success Rate: 90.435

iphone
  Trials: 974
  Connects: 860
  Disconnects: 116
  Messages: 841
  Success Rate: 86.345

opera
  Trials: 1112
  Connects: 1071
  Disconnects: 11
  Messages: 1055
  Success Rate: 94.874

nokia
  Trials: 26
  Connects: 0
  Disconnects: 11
  Messages: 0
  Success Rate: 0.000

android
  Trials: 35
  Connects: 18
  Disconnects: 2
  Messages: 13
  Success Rate: 37.143

other
  Trials: 27
  Connects: 1
  Disconnects: 24
  Messages: 1
  Success Rate: 3.704


Eric Mill

unread,
Dec 29, 2012, 12:39:38 AM12/29/12
to Larry Evans, SockJS
Are all the connection attempts in your tests local? The reason SSL helps websockets connections is because of the state of the Internet's network topology all over the world. The only reasonable way to test this kind of thing is on a real-world data sample of random visitors from unpredictable ISPs and proxies. This is why Google's test data from Chrome users, and my own data silently collected from steady and random worldwide traffic to my website, are useful measures. They're not perfect, and the test's assumptions may be incomplete (like how my IE9 SSL connection problem was a separate issue entirely), but they are useful.


On Tue, Dec 25, 2012 at 9:46 PM, theyak <yakk...@gmail.com> wrote:
Ran the tests again. You can see the codebase at https://gist.github.com/766833e32b319755c47b/06f33614e3a15d47adb78803540902d0fa82d369 to let me know if I'm doing something stupid.

Test 1:
Using http:// when page load is http://:

94.388% success


Test 2:
Always using https:// no matter the page load protocol*:

 88.495% success


* Except IE 1-9


Nothing really noticed based on browser type or anything. Android and Nokia did significantly worse when always using https:// but they are both such a small percentage of hits that they do not affect the results much.

Actual results for test 1:

all
  Trials: 50107
  Connects: 48380
  Disconnects: 1013
  Messages: 47270
  Success Rate: 94.338

other
  Trials: 6
  Connects: 4
  Disconnects: 1
  Messages: 3
  Success Rate: 50.000

chrome
  Trials: 23205
  Connects: 22665
  Disconnects: 321
  Messages: 22150
  Success Rate: 95.454

safari
  Trials: 28911
  Connects: 28041
  Disconnects: 465
  Messages: 27379
  Success Rate: 94.701

msie
  Trials: 9091
  Connects: 8733
  Disconnects: 146
  Messages: 8567
  Success Rate: 94.236


firefox
  Trials: 10508
  Connects: 10162
  Disconnects: 285
  Messages: 9923
  Success Rate: 94.433

ipad

  Trials: 1708
  Connects: 1677
  Disconnects: 42
  Messages: 1657
  Success Rate: 97.014

android
  Trials: 620
  Connects: 472
  Disconnects: 10
  Messages: 407
  Success Rate: 65.645


opera
  Trials: 1256
  Connects: 1232
  Disconnects: 36
  Messages: 1211
  Success Rate: 96.417

iphone
  Trials: 738
  Connects: 727
  Disconnects: 19
  Messages: 722
  Success Rate: 97.832

nokia
  Trials: 190
  Connects: 79
  Disconnects: 80
  Messages: 60
  Success Rate: 31.579

blackberry
  Trials: 6
  Connects: 6
  Disconnects: 0
  Messages: 6
  Success Rate: 100.000



Actual results for test 2:

all
  Trials: 50404
  Connects: 45147
  Disconnects: 3085
  Messages: 44605
  Success Rate: 88.495

other
  Trials: 27
  Connects: 1
  Disconnects: 24
  Messages: 1
  Success Rate: 3.704

firefox
  Trials: 11280
  Connects: 9584
  Disconnects: 1281
  Messages: 9469
  Success Rate: 83.945

chrome
  Trials: 23099
  Connects: 21788
  Disconnects: 695
  Messages: 21601
  Success Rate: 93.515

safari
  Trials: 29615
  Connects: 26846
  Disconnects: 1508
  Messages: 26557
  Success Rate: 89.674

msie
  Trials: 8249
  Connects: 7570
  Disconnects: 248
  Messages: 7453
  Success Rate: 90.350

android
  Trials: 1037
  Connects: 461
  Disconnects: 132
  Messages: 410
  Success Rate: 39.537


ipad
  Trials: 1976
  Connects: 1797
  Disconnects: 156
  Messages: 1787
  Success Rate: 90.435

iphone
  Trials: 974
  Connects: 860
  Disconnects: 116
  Messages: 841
  Success Rate: 86.345

opera
  Trials: 1112
  Connects: 1071
  Disconnects: 11
  Messages: 1055
  Success Rate: 94.874

nokia
  Trials: 36
  Connects: 1
  Disconnects: 19
  Messages: 1
  Success Rate: 2.778

blackberry
  Trials: 37
  Connects: 35
  Disconnects: 1
  Messages: 34
  Success Rate: 91.892

theyak

unread,
Dec 29, 2012, 2:15:14 AM12/29/12
to soc...@googlegroups.com, Larry Evans
Data is from a live site.


Eric Mill

unread,
Dec 29, 2012, 2:46:07 AM12/29/12
to Larry Evans, SockJS
Sorry about that, my mistake. Logging failures is better instrumentation than I'm using, since I'm only implying the existence of failed connections by comparing successful connections day-to-day and then looking at what GA reports for overall visits from day to day. There's lots of room for uncertainty in my results. I'll try to do a test like yours at some point.

Marek Majkowski

unread,
Jan 8, 2013, 7:28:56 AM1/8/13
to yakk...@gmail.com, soc...@googlegroups.com
On Wed, Dec 26, 2012 at 3:52 AM, theyak <yakk...@gmail.com> wrote:
> Ran the tests again. You can see the codebase at
> https://gist.github.com/766833e32b319755c47b/06f33614e3a15d47adb78803540902d0fa82d369
> to let me know if I'm doing something stupid.
>
> Test 1:
> Using http:// when page load is http://:
>
> 94.388% success
>
> Test 2:
> Always using https:// no matter the page load protocol*:
>
> 88.495% success
>
> * Except IE 1-9
>
>
> Nothing really noticed based on browser type or anything. Android and Nokia
> did significantly worse when always using https:// but they are both such a
> small percentage of hits that they do not affect the results much.

Very interesting indeed!

Those numbers are much lower than what I'd anticipate :)

With nokia / androind over SSL: it's likely that some timeouts in sockjs are not
tweaked properly and that sockjs just timeouts on slow platforms. Or even
more probable - they are over 3G and network just sucks.

Can you collect an average RTT value for failed / succeeded connections?
(you could reuse sockjs-client conn._options.rtt value:
https://github.com/sockjs/sockjs-client/blob/master/lib/sockjs.js#L256 )


Additionally, you seem to be running sockjs on port 4000, that'll not work
for your clients behind corporate firewalls as they usually only allow
port 80 and 443.

Marek

theyak

unread,
Jan 10, 2013, 7:08:31 PM1/10/13
to soc...@googlegroups.com
Can you post more information on how to collect the rtt value? I dumped both my socket object list as well as the server variable and was unable to find any rtt value. Also, when should I check for this?

Also, I tried ports 80/443 previously and had even worse connection rates (85%) so I switched to 4000/4002.


On Sunday, December 9, 2012 6:47:37 PM UTC-8, Eric Mill wrote:

Marek Majkowski

unread,
Jan 11, 2013, 5:19:07 AM1/11/13
to yakk...@gmail.com, soc...@googlegroups.com
On Fri, Jan 11, 2013 at 12:08 AM, theyak <yakk...@gmail.com> wrote:
> Can you post more information on how to collect the rtt value? I dumped both
> my socket object list as well as the server variable and was unable to find
> any rtt value. Also, when should I check for this?

conn._options.rtt
or
conn._options.info.rtt

should work. They should be available onopen or onclose.

> Also, I tried ports 80/443 previously and had even worse connection rates
> (85%) so I switched to 4000/4002.

That's intriguing! I can't say I understand that.

Marek

theyak

unread,
Jan 14, 2013, 7:01:26 PM1/14/13
to soc...@googlegroups.com, yakk...@gmail.com
Sorry, I still can not find the rtt value. Here is what I have
on connections:

{ _session:
   { session_id: undefined,
     heartbeat_delay: 25000,
     disconnect_delay: 5000,
     prefix: '/sockjs',
     send_buffer: [],
     is_closing: false,
     readyState: 1,
     timeout_cb: [Function],
     to_tref:
      { _idleTimeout: 25000,
        _idlePrev: [Object],
        _idleNext: [Object],
        _onTimeout: [Function],
        _idleStart: Mon Jan 14 2013 23:49:26 GMT+0000 (UTC) },
     connection: [Circular],
     emit_open: null,
     recv:
      { ws: [Object],
        connection: [Object],
        thingy: [Object],
        thingy_end_cb: [Function],
        session: [Circular] } },
  id: '78b32ed8-a383-4582-97ed-7d16dc9ff1ae',
  headers: {},
  prefix: '/sockjs',
  remoteAddress: 'xx.xxx.xxx.xxx',
  remotePort: 60028,
  address: { address: 'xx.xxx.xx.xxx', family: 'IPv4', port: 80 },
  url: '/sockjs/424/mroq4sx9/websocket',
  pathname: '/sockjs/424/mroq4sx9/websocket',
  protocol: 'websocket' }



And what I have on the close event:

Closing 6092b56d-6b85-44ee-b071-7c24edc6f8e1
{ _session:
   { session_id: 'h7e0xu79',
     heartbeat_delay: 25000,
     disconnect_delay: 5000,
     prefix: '/sockjs',
     send_buffer: [],
     is_closing: false,
     readyState: 3,
     timeout_cb: [Function],
     to_tref: null,
     connection: [Circular],
     emit_open: null,
     recv: null },
  id: '26f110c3-1e27-456c-b7ce-e85ebdaa98e9',
  headers: {},
  prefix: '/sockjs',
  remoteAddress: 'xx.xxx.xx.xx',
  remotePort: 59508,
  address: { address: 'xx.xxx.xx.xxx', family: 'IPv4', port: 443 },
  url: '/sockjs/980/h7e0xu79/xhr_streaming?t=1358207483243',
  pathname: '/sockjs/980/h7e0xu79/xhr_streaming',
  protocol: 'xhr-streaming',
  _events: {} }



   { prefix: '',
     response_limit: 131072,
     websocket: true,
     jsessionid: false,
     heartbeat_delay: 25000,
     disconnect_delay: 5000,
     log: [Function],
  _events: { connection: [Function] } }

theyak

unread,
Jan 14, 2013, 7:16:54 PM1/14/13
to soc...@googlegroups.com
This is my latest 80/443 test. There wasn't enough overall difference between the two method to recommend one over the other.

Always connecting to port 443, using SSL, except for IE 6-9 which connects
to port 80 if the web page load was to http://

Browser Trials  Connects  Disconnects Messages    Success Rate

msie     13920   13246       202        12958        93.089
chrome   34116   32455       831        32111        94.123
firefox  16883   14265      1885        14059        83.273
safari    5733    4002       942         3932        68.585
ipad      3024    2866       132         2830        93.585
iphone     987     853       113          822        83.283
opera     1600    1450        56         1373        85.813
nokia       23       0        18            0         0.000
android     29      20         6           19        65.517
other      151      92        11           65        43.046

http     69393   62472      3985        61423        88.515
https     7073    6777       211         6746        95.377

all      76466   69249      4196        68169        89.149


Connect to port 80 if page load was http:// or port 443 if page load was https://.

Browser Trials  Connects  Disconnects Messages    Success Rate
chrome   76041   72209      1989        69372        91.230
firefox  34473   31270      1384        29687        86.117
ipad      7041    6883       144         6779        96.279
msie     28713   26583       644        25780        89.785
safari   13086   11697       897        10545        80.582
iphone    2473    2266        95         2177        88.031
opera     2636    1450       894         1422        53.945
nokia      143      66         5            5         3.497
android     92      65         1           50        54.348
blackberry   1     0       0            0         0.000
other      367     203        18          143        38.965

http    151167  139545      5652       132932        87.937
https    13899   13147       419        13028        93.733

all     165066  152692      6071       145960        88.425

Marek Majkowski

unread,
Jan 16, 2013, 7:55:28 PM1/16/13
to yakk...@gmail.com, soc...@googlegroups.com
On Mon, Jan 14, 2013 at 4:01 PM, theyak <yakk...@gmail.com> wrote:
> Sorry, I still can not find the rtt value. Here is what I have
> on connections:
>
> { _session:
> { session_id: undefined,

Ah, sorry. My fault - I should be more explicit. The rtt is in the
_client_ connection's object! (in sockjs-client not in sockjs-node)

Marek

Marek Majkowski

unread,
Jan 16, 2013, 8:00:28 PM1/16/13
to yakk...@gmail.com, soc...@googlegroups.com
On Mon, Jan 14, 2013 at 4:16 PM, theyak <yakk...@gmail.com> wrote:
> This is my latest 80/443 test. There wasn't enough overall difference
> between the two method to recommend one over the other.

Interesting! Thanks for sharing the numbers. Although I'm not sure
what the conclusion is. SockJS is not reliable on Opera or Safari?
7-10% of users don't succeed no matter what?

Marek

eeis...@auburnschl.edu

unread,
Jun 4, 2015, 11:15:46 AM6/4/15
to soc...@googlegroups.com, konk...@gmail.com
Hello Eric,

I used OpenSSL to generate public and private keys for SSL.  Could you suggest a tutorial for setting up SSL with SockJS?  I have an application my high school students are working on and would like them to convert it to SSL before the year ends.  Also, I'm switching to SockJS from Socket.io.

Best Regards,
Eric Eisaman
Reply all
Reply to author
Forward
0 new messages