Security 3,167 VIEWS
Posted Thursday, August 18, 2016 by Pete Mastin
READ MORE: http://www.cedexis.com/...
Everything and everyone is going mobile. We all hear it every day. We see people wondering around parks looking for Pokémon. Increasingly, we see people using mobile devices to replace desktops and laptops professionally.
How are architectures for application performance evolving to keep up with the shift to mobile?
Let’s look at two trends that are conspiring to make this pivot more interesting and challenging: the move to Secure Sockets Layer (SSL) and how Content Delivery Networks (CDNs) can help with mobile.
Secure Sockets Layer - SSL
The move to SSL as a delivery platform, over HTTP, is driven by a number of factors, which include:
- MITM (Man in the Middle) – to protect against snooping or tampering with responses
- Privacy – a lock which implies providers care about their client’s privacy
- Hardware Capacity – modern servers can handle the crypto burden much more than in the past
- Certificate Management – systems and processes have been built to manage the storage and administration of certificates
- Search Engine Rankings – search engines evaluate HTTPS sites over HTTP
These reasons are all good ones. Google is currently 75 percent HTTPS across all of its services and it has expressed a commitment to reaching 100 percent.
But as Tim Willis, HTTPS Evangelist at Google points out, there are challenges:
“For large sites, it usually involves a non-trivial amount of engineering work, figuring out what changes you need to make and working with others,” says Willis. “For example, do your ad networks support HTTPS? Does your content delivery network charge more for HTTPS? Is third-party content on your site offered over HTTPS? Answering these questions takes time and involves multiple rounds of ‘test-break-fix’ to get it right.”
One significant issue that Willis failed to point out is performance.
Content Delivery Networks
Traditionally application performance was maintained by the use of Content Delivery Networks (CDNs). CDNs are a best practice for performance. CDNs are very good at delivering lot of bits – but until recently their delivery of SSL was more limited. This makes sense; SSL was not traditionally a large part of most sites, but rather it was limited to the ‘shopping cart’ section of the site. For this reason, CDNs had different “maps” for the SSL than they did for HTTP delivery. These maps really just amount to the number of servers servicing SSL, the number of Points of Presence (PoPs) that SSL server exists in, and the peering or anycast networks that these POPs are connected with.
But these SSL maps do not always perform as well as their HTTP counterparts. The reasons SSL performance might be challenging is because of the following:
- SSL Handshake – HTTPS takes 3.5 more round-trips prior to request than HTTP
- Loss of cache ability at intermediate or transparent caches – Large file downloads lose opportunity for bandwidth savings from local caching
- Not all PoPs have SSL for every CDN – The maps for HTTP and SSL are not identical (usually HTTPS is a subset of HTTP)
- Less SSL Capacity at the PoP than HTTP – This could be because of fewer servers or just the fact that SSL requires higher processor utilization
- Server Costs - CPU burden on CDN scale SSL is significant and can result in latency as CPU oversubscription increases
Now, let’s take a look at what the data shows us about the difference in HTTP maps on CDNs and SSL maps.
In a recent study where data was taken from Cedexis Radar (a platform that measures every CDN and cloud globally more than 7 billion times a day), six global CDNs, including both their HTTP maps and their SSL map worldwide, were examined. Here is what was found (note this is latency – so the lower the number, the better):
The CDNs were renamed to be Greek philosophers to avoid angering various CDN companies. But note, every CDNs’ SSL performance from a latency perspective is worse on SSL than it is on HTTP. The six CDNs surveyed included:
These latency numbers did not include the SSL handshake. So in general, it’s actually worse than this. But the numbers vary by location as well. So if we combine the six CDNs SSL maps and HTTP maps and look at it regionally we see the following:
So you can see that while SSL is terrible in Asia and South America – it is actually close to on par in Europe and better than HTTP in North America.
While some site owners may take solace in this result, there are some other concerns that you need to know about.
SSL over Wireless networks on a CDN – bringing it all together
So far we have seen that SSL can have some performance problems, but in North America those problems are less than in the rest of the world. But that result is true when viewed broadly over the entire internet. But the internet is made of up different kinds of ISPs -some are cellular and some are copper and cable. What happens when we look at these results through that lens?
For this experiment, measurements were limited to only the U.S. The measurements were then subdivided to be from only known wireline and wireless providers. Networks were excluded that have the same ASN for both and the same six CDNs were used. Here is what was discovered:
According to the findings, the wireless network’s latency in the U.S. is much higher when running against the SSL vs. the HTTP maps of these six CDNs. On average, you could be adding 133 milliseconds per transaction to your page load time to your mobile customers by deploying on SSL.
As you can see – there are a number of important things to consider as you move your mobile app to SSL. The results include:
- HTTP maps on CDNs are Faster than HTTPS maps on CDNs Worldwide when measured on all ISPs.
- SSL maps are on par with HTTP maps in the U.S./EU when measured on all ISPs.
- The performance impact of SSL on wireless users in the U.S. is substantial when using CDN SSL maps.
These results are averages and it’s important to understand how your users experience your site. That being said there are clear challenges to deploying a mobile app on SSL above and beyond the items listed at the beginning of this article. Know your users, know your CDN, know your network and proceed with caution.
READ MORE: http://www.cedexis.com/...