Some real world SSL stats for websockets/sockjs
1,538 views
Skip to first unread message
Eric Mill
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
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!
> 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!
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
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
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.
> 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
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
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
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
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
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.
var server = "https://socket.example.com:4443/sockjs";
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
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?
> Thanks. Sadly, IE still isn't working for me when page is loaded with
> https:// and sockjs connection is downgraded to http://.
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
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
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
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:
> 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.
https://sockjs.popcnt.org/example-cursors.html
https://sockjs.cloudfoundry.com/example-cursors.html
Marek
Eric Mill
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
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
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.
> 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:.
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.
Marek
Message has been deleted
theyak
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
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
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
Dec 29, 2012, 2:15:14 AM12/29/12
to soc...@googlegroups.com, Larry Evans
Data is from a live site.
Eric Mill
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
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!
> 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.
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
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?
On Sunday, December 9, 2012 6:47:37 PM UTC-8, Eric Mill wrote:
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
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
> 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?
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.
Marek
theyak
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],
sockjs_url: 'http://cdn.sockjs.org/sockjs-0.3.min.js' },
_events: { connection: [Function] } }
theyak
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
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
> Sorry, I still can not find the rtt value. Here is what I have
> on connections:
>
> { _session:
> { session_id: undefined,
_client_ connection's object! (in sockjs-client not in sockjs-node)
Marek
Marek Majkowski
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
> This is my latest 80/443 test. There wasn't enough overall difference
> between the two method to recommend one over the other.
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
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