3 ms·

Oh, not biased at all. Just mindful of the additional overhead and computational load it places on the server. It can be very significant, as the paper below in

Oh, not biased at all. Just mindful of the additional overhead and computational load it places on the server. It can be very significant, as the paper below indicates: http://www.bsc.es/media/389.pdf http://www.bsc.es/media/389.pdf

epi0Bauqu 19y ago
Sorry to suggest that you were biased. Bad diction on my part. I didn't mean it like that. That link isn't working for me, but, from experience, I really don't think using SSL just for authentication will hamper your server resources that much.
- jsjenkins168 19y ago
  I actually assumed the same thing. The computational load is intense in the handshake process, but then not really much more so afterwards. But if every user is re-authenticating each time they log into the site, the server can fall flat on its face very quickly. The issue is compounded if the client has a connection timeout. As the server load increases and response time starts to exceed the defined timeout, the client sends more connection requests, increasing server load exponentially. Its like a snowball effect. Check out the graphs in the paper from my previous reply and you'll see what I'm talking about. I like mdakin's proposed solution b/c it apparently alleviates the need for a connection request each time the user logs in. At least until the cookie expires.
  - epi0Bauqu 19y ago
    The link still isn't working. But this is not an assumption on my part. It is from experience. At my last startup, we ran the entire most everything over https because it yielded better sign up numbers and payment conversions (pre-payment page). We had at some points over 50K people signing up daily (and of course many many more hitting the initial sign up page and current users logging in and clicking around). The registration # is to give you an idea of scope. All of this still ran fine one dual CPU machine, i.e. all the https didn't hit the server too hard to where it mattered. So I guess I'm not disputing https takes a lot more CPU than http, but in the aggregate, with a decent machine, it just isn't going to matter. This is especially true if you just do it for authentication, and yes I was thinking of the same cookie process as described by mdakin when making the original comment.

epi0Bauqu 19y ago

Sorry to suggest that you were biased. Bad diction on my part. I didn't mean it like that. That link isn't working for me, but, from experience, I really don't think using SSL just for authentication will hamper your server resources that much.

jsjenkins168 19y ago
I actually assumed the same thing. The computational load is intense in the handshake process, but then not really much more so afterwards. But if every user is re-authenticating each time they log into the site, the server can fall flat on its face very quickly. The issue is compounded if the client has a connection timeout. As the server load increases and response time starts to exceed the defined timeout, the client sends more connection requests, increasing server load exponentially. Its like a snowball effect. Check out the graphs in the paper from my previous reply and you'll see what I'm talking about. I like mdakin's proposed solution b/c it apparently alleviates the need for a connection request each time the user logs in. At least until the cookie expires.
- epi0Bauqu 19y ago
  The link still isn't working. But this is not an assumption on my part. It is from experience. At my last startup, we ran the entire most everything over https because it yielded better sign up numbers and payment conversions (pre-payment page). We had at some points over 50K people signing up daily (and of course many many more hitting the initial sign up page and current users logging in and clicking around). The registration # is to give you an idea of scope. All of this still ran fine one dual CPU machine, i.e. all the https didn't hit the server too hard to where it mattered. So I guess I'm not disputing https takes a lot more CPU than http, but in the aggregate, with a decent machine, it just isn't going to matter. This is especially true if you just do it for authentication, and yes I was thinking of the same cookie process as described by mdakin when making the original comment.