Everybody requires security and privacy these days.
If you don't believe it, take a look at Google, Facebook and Twitter. All them are using HTTPS and SSL to secure all their webpages and API calls including simple feed presentation and search page presentation.
And yes, this fact is still valid even in the post Heartbleed era.
Fact #2: Sites and Widgets are Required for Quicker than Light Loading Time
In the online business, time is money. And faster webpage load times worth a lot of money.
Fact #3: Webpages Secured by SSL have Poor Performance
When you surf for the first time to a website (or take a look at a widget), you are required to have several phases in order to view the website:
- Resolve the Site DNS.
- Call for the first Web page.
- Perform a TCP handshake.
- Perform a SSL handshake.
- Retrieve the page itself (+ encryption overhead)
- Call the embedded resources: images, CSS and JavaScript files (+ encryption overhead).
As you can see, the initial loading of a regular webpage is not short at all. Adding the SSL handshake to this process as well as the encryption and decryption and the overhead on the content, results in even longer times.
What Can be Done?
A common solution is choosing a SSL offloading device such as Radware's Alteon. This device will shorten the encryption and decryption times at the server side. However, it will not reduce the SSL handshake time or shorten the time needed to transfer the page encryption overhead.
The only way to shorten this time is shortening the round trip time between the users and your servers. If this is sounds like a CDN case study, you are right.
CDN is a Key Solution to Managing HTTPS Traffic
Modern CDN solutions support SSL termination at the edge. Therefore, the SSL handshake time can reduced from up to 1 second to several dozens of ms (see in the figures).
This is a major plus to the benefit of shortening the static files serving time by serving a cached copy from the CDN edge.
The good news are that this benefit is valid for both static files and dynamic calls.
 |
| Figure 1: Lightweight HTTP REST API Call: Local (Left waterfall) vs Remote (right waterfall), where local call was done from a server located at the same data center as the web server and the remote was done from a remote location with a 200ms round trip to the web server. As we can see most the time is due to the network round trips rather than server processing. Please neglect the initial DNS resolve time. |
 |
| Figure 2: Same call this time using HTTPS. We can see that the original waiting time was split to two, while SSL connection time doubled it. We can see that in this case as well the SSL processing time at server is neglectable (22ms) while the round trip costs us about 420ms. Please avoid the DNS resolve time in this case as well. |
CDN Selection for HTTPS Traffic Cases
While many CDN services support SSL offloading to their own domain (e.g https://your_domain.cdn_provider.com), you probably would like to use your own domain name (e.g https://your_domain.com). Therefore, you should verify that the CDN provider supports custom SSL certificates. Common cloud CDN providers such as AWS and MaxCDN are known to support it, while providers like Microsoft Azure don't.
Bottom Line
CDN are a corner stone to every web scale deployment these days, and many times you will find they solve issues you were not expecting for them before.
Keep Performing,
