If your website is well-coded and administered, does CloudFlare offer any performance benefit? (leaving aside security for now)
If a page is static, then CloudFlare can cache it. But if you set your cache headers appropriately, and use efficient serving code like nginx, I imagine serving static content is pretty darn cheap.
If a page is dynamic, then how can CloudFlare really speed it up? You don't want them serving stale pages to users. So it has to hit your server every time, in which case the user might as well hit your server. In that case, I don't really see how CloudFlare improves things.
Am I misunderstanding how CloudFlare works? It seems like if you follow typical performance tips like [1] then most of CloudFlare's benefit is eliminated.
I guess [1] does tell you to use a CDN. You can save end user network latency for cached static pages, since they cache them in multiple geographic locations. But if you have a simple site with 1 .js and 1 .css file per page, and compress and minify everything, I wonder if it's worth it.
1. SSL is terminated near the user - the multiple round trips to do a TLS handshake for a user in Sydney will never leave the city, instead of having to traverse the pacific.
2. Static content is served locally from their CDN. Same thing, your JPEG served to a guy mombasa is coming from a few miles away, not half a world away.
3. If your clients are using old browsers without keepalive, CloudFlare will still keep connections alive from their local endpoint to your servers - making the new-connection cost only occur on the first couple of hops.
4. For dynamic content you can use a special proxy they created which keeps a synchronized cache with the far end so it can ships diffs. If you generate a page thats mostly similar to another page it can just send "Same As Cache Object 124567 except Line 147 says "Welcome chubot" instead of "Welcome orionhenry". A significant percentage of dynamic responses can traverse the world as a single TCP packet.
5. Their devs are really ruthless about keeping the crypto certs as small as possible, with the goal of all handshakes taking a single packet per step.
> If a page is static, then CloudFlare can cache it. But if you set your cache headers appropriately, and use efficient serving code like nginx, I imagine serving static content is pretty darn cheap.
With the static content it's not the cost of serving it, it's the fact that Cloudflare is serving it from a large bunch of distributed servers that are likely to offer far lower latency to the end-user than your servers. With modern web pages often containing hundreds of objects, this can make a big difference to page load times.
If all your customers are in one geography this is less of an issue, but if you have a global audience this can make a huge difference.
OK, but this is just the benefit of any CDN, not just CloudFlare right?
So I guess the selling point of CloudFlare is that it's like a normal CDN, plus it offers security services like DDOS protection?
With a normal CDN, you don't change your DNS to point at their servers right? DNS points to your server, but you change your code to have <img src="" > and so forth pointing at their servers. To me that just seems a lot less invasive, but admittedly then you can't get the security features.
Well, routing everything through them via DNS obviously means less code in your application, so that's nice.
Also, a CDN which routes all of your traffic via DNS can also take advantage of a private network to get the packets to your users faster, i.e. Cloudflare could potentially own a faster link between Virginia and Berlin than the public internet would take, and lower response time that way. I think that's what point two on the benefits list here is about: https://blog.cloudflare.com/cloudflare-is-now-a-google-cloud...
A faster link, but also an already open TCP and SSL connection. By moving the TCP and SSL handshake to an edge-based server, you have much lower-latency when starting a request for the client. The long-haul high-latency connection between the edge and your server is already open, no extra roundtrips required.
I'd say that the historic Akamai model (from the last bubble) counts as "a normal CDN", and in that case, you do change your DNS to point straight at Akamai's DNS servers. For well over a decade now, `www.microsoft.com` has been a CNAME for something run by Akamai.
My rough and uninformed impression is that for small-time users, where "small-time" includes the scale of Reddit, CloudFlare can do what Akamai does at a much more reasonable price.
But yes, that's a different sense of "CDN" from e.g. Google-hosted jQuery.
I assume its for this reason (and others) that even Amazon.com still uses Akamai. Stuff like product images/banners still get served from domains like g-ecx.images-amazon.com (which resolve to Akamai)
There is something which Akamai does and CloudFlare doesn't want to (at the moment): pay big sums to those big ISPs which refuse to peer and want to sell very expensive direct connections.
Akamai has direct connections to those "difficult" ISPs, CloudFlare uses transit to reach them.
To provide an example: transit to DTAG via GTT (CloudFlare) is always saturated at peak hours. So Akamai has a big advantage (direct connection) if you want to reach Deutsche Telekom customers.
Do you know of any docs describing the algorithm Akamai or CloudFlare use to decide whether to hit your origin server? I'm a stickler for correctness but it seems to be pretty easy to get into the situation where your users aren't getting what you intended. HTTP cache headers are a mess.
To me it seems safer to code your application so the HTML points to JS/CSS/PNG with content hashes in the URL. Then you don't have any cache expiry issues -- nothing ever expires, but you control the assets exactly through your dynamic HTML.
I think it's important to have fast and reliable rollbacks. You can imagine some situation where private content or offensive text is accidentally included with some static asset... I would like some guarantee about when users stop seeing it (preferably as soon as the application is redeployed).
I was using CloudFlare on a site that has a wide overseas following with a lot of visitors from different continents. I was getting a lot of complaints that the site was terribly slow. When I went back to just serving the site directly from it's server in Atlanta, the complaints ceased.
You get a lot of "testing your browser" delays if you're from certain regions, also the annoying captcha gateway if behind a big mobile NAT that was blacklisted somewhere because of one spammer or maliscious user, or if using some VPNs/Tor especially the free tier VPNs
Oh so that's what it is. I think Namecheap must be using it too because I see this darn message every time I load their site "We're testing if you're human or robot" and it wastes like 10 seconds of my time.
People think that "loading gears" animation on Google blog is annoying, think if it showed up every time for 10 seconds on a company's homepage.
It is the only reason I've considered leaving Namecheap so many times (but haven't because except for this they are better at everything else)
> if you set your cache headers appropriately, and use efficient serving code like nginx, I imagine serving static content is pretty darn cheap
If the website is serving content (i.e. articles, images, movies, you know, the normal use-case) then most people visiting a page will be first time visitors on that page. The cache headers you mention are only good for returning visitors and even so, the local cache is not reliable on mobile phones where the cache is being purged regularly to make room. Consider that there are mobile web developers that have decided to not use JQuery for this reason, even though JQuery is probably the most cached piece of JS in the world.
Also serving content from a properly configured Nginx doesn't help with network latency. Say, if your server is in the US and your visitors are in Japan or China, then the added network latency can be measured in seconds. The problem gets even worse for HTTPS connections because of that handshake. And consider that Google found an extra .5 seconds of latency in delivering their search result costs them a 20% drop in traffic, or that for Amazon 100ms of added latency costs them 1% in sales.
> If a page is dynamic, then how can CloudFlare really speed it up?
Even if the page contains dynamic content, you always have static content that you want to serve from a CDN.
You also forgot probably the biggest benefit for us - bandwidth ends up being freaking expensive and if you get a lot of traffic, then a CDN can save you a lot of money.
There's a nice facebook study on how frequently people were not receiving cached images, and it was around 44% of all users (25% of all hits). If you figure that Facebook is going to have some of the better numbers for that metric, it supports your conclusion: https://code.facebook.com/posts/964122680272229/web-performa....
There was a similar exercise done with hosted versions of jquery, but I can't remember who did it or find a link, I'm afraid.
we use it on our image heavy startup. reduces the load on the server by a fair margin, and since images are loaded on S3 it also reduces the operating cost quite a bit
additionally it's geolocated, so we get that for free, which is nice.
How are you using CloudFlare for S3 images? Are you using Flexible SSL?
The problem I ran into was setting up a CNAME for an S3 bucket requires the bucket name to have periods in it, but https:// access no longer works for buckets with that naming convention[1]. So I ended up having to use CloudFront instead for my images.
we have a document store backed by S3 running on EC2 instances, the instances are behind one of amazon balancing routers and that's what the cloudflare cname points at
currently the beta env runs flexible ssl and production runs with strict.
If you use s3.amazonaws.com then you aren't using a CNAME anymore, meaning you can't use CloudFlare to accelerate the traffic. CloudFlare needs to control the DNS.
That being said, I've seen CloudFlare cutting down DNS lookup from 800ms to 60ms for a tiny website.
Another thing is that it depends if you're really concerned with visitors far from your server. I had some WordPress websites hosted in LA and with some really basic optimization page speed was almost as good as Google's home page.
Don't drink the paint, I guess :) It may not be worth it, it may be great. Test it. Of course, CF has other benefits too, it's not just about the page speed.
Don't get me wrong. I'm not claiming anything here. It's just a quick rant and a screenshot. Don't take it too seriously.
Other than that, it is becoming somewhat concerning just how much traffic goes through CloudFlare. Nothing against you CF guys. Just good ol' paranoia :)
EDIT:
For most places CloudFlare does a great, well, amazing job and keeps the page speed down to <1s, often <500ms. But again, it really depends where your visitor are. Check the History tab here http://tools.pingdom.com/fpt/#!/blmbP5/http://cloudflare.com
The biggest win from CDNs like CloudFlare as compared to just using properly-configured in-house servers is global distribution. Downloading a JS file from a server a mile from your house is a lot faster (often by hundreds of milliseconds) than downloading one from hundreds or thousands of miles away, and CloudFlare probably has a server a mile from your house. And it's prohibitively expensive to build your own global network that compares to CloudFlare's scale unless you're a very large company like Apple.
As for dynamic page caching, CloudFlare offers a service called Railgun that only sends the diffs of a page when it's been changed, rather than the full page, and then re-hydrates it at the edge of their network before handing it off to end-users. Theoretically this would reduce network time by sending less traffic inside the network. I've never personally used it so I can't vouch for it, but it sounds neat.
If you leave aside security, of course Cloudflare is not going to look like a great benefit. Security is what Cloudflare provides as a service. The "CDN" benefits are a nice consequence of the security, but CDNs and static caching can be had for pretty cheap.
The real question is: why would you leave aside security?
Silly question: How does CloudFlare make any money?
Any random can put any site behind their (very fully featured) free services and get free CDN, free antimalware, and free $other_services, with no seeming limits as to the amount of traffic you get. This has no impact on the target site. There are no ads or any other such. Their enterprise products only offer a few more features at a massive cost hike.
How are the bandwidth costs not eating them alive, and how are the free users being subsidized?
The consumer freemium model is probably negligible money in the grand scheme of things. Here is an article about how Cloudflare developed a keyless SSL tool to bring Goldman Sachs on as a client:
Downtime is expensive for large companies, including financial institutions. A DDOS that takes down the site could cause a dip in the stock price. CloudFlare technology (should) prevent DDOS and other basic security issues. It does this without appliances and without having access to private SSL keys.
Imagine the opportunity cost of a bank going offline, and you can start to understand just how much money CloudFlare stands to make from large corporations.
I don't know for sure, but they likely have to provide a private key to these providers. Other big disadvantage of a "DDOS-proof hosting provider" is that they likely are not distributed, so absorbing large DDOS is hard.
Just to set a baseline: Nothing is DDoS-proof. (even CloudFlare).
What you want is DDoS resistance which is as strong as possible, and sufficiently strong for your application.
It's essentially impossible to have a single location anywhere in the world which is able to resist the largest attacks today (many hundreds of gigabits per second); even if your site somehow has 10Tbps of interconnects, the networks near you will get saturated. (And I don't think you could buy 10Tbps of interconnect to various networks at a single building today)
You could accomplish bigger-than-single-site DDoS resistance in three ways:
1) Direct private connections to users (there are systems which are unsuited for the public Internet!)
2) Buying lots of long-haul off-Internet transport to networks around the world; running your own private network which interconnects in-core in various important networks around the world.
3) Building a highly redundant global distributed front end which then backhauls traffic (over public networks, private networks, some combination), and potentially handles some or all of that traffic at the edge directly (cache, and maybe someday edge processing...)
(#3 can also be accomplished with an application having a loosely coupled front end; if you're just serving static content this is trivial. If you can deal with eventual consistency, it's also relatively easy. It becomes incredibly difficult for regular web apps or anything with lots of writes which need to be globally atomic. There's a lot of great CS work to be done, and then tool development, to make truly distributed web apps possible, then easy...)
#1 and #2 are incredibly expensive as the number of users scales up. #3 is what ~everyone does, even the biggest DDoS targets. CloudFlare and other providers are good at doing #3 for you so you don't have to, but theoretically a large company with a lot of money could do this themselves. It's probably not a core competency of a large financial institution to do this, so modulo trust issues, it makes sense for them to pay a provider to do it. We're working particularly hard at technical solutions to the trust issues, cost, etc. to make it a good solution for anyone.
I pay them $20 a month. I needed HTTPS back in the days before that was part of their free plan and kept on with the paid plan.
I'm not sure what features the free plan lacks, but $20 a month isn't going to break the bank. I found their application firewall very useful for stopping spam registrations.
My guess is that if you need a CDN, it's highly likely that you will at least need their Pro plan, most likely a business plan. Other than geeks, I don't really see too many people consuming their free offering to a limit where it becomes a financial burden for them.
I wondered about this too, especially since their marketing makes a huge deal about how "We never charge for bandwidth" [1]. It turns out that enterprise plans don't exactly charge per-gigabyte like other CDNs, but the cost does increase based on your bandwidth usage.
There aren't a ton of explicitly called out features that require an enterprise deal, but I expect a customer of any significant size will be under one (or encouraged to do so). It's the only way to get an SLA and to modify the terms of your contract with them, among other things that businesses care about.
As a result of the difference in price between the plan types, I would speculate that the service is subsidized by the enterprise customers. However, the free or lower cost customers were probably essential to building their peering relationships before they had significant enterprise users, and that has a very direct relationship with their cost to serve traffic.
They have the answer about bandwidth here [1] and on some blog posts [2].
> We buy our bandwidth through the wholesale market, which means we're paying for the size of our pipe, not for each byte we serve through it. We also peer with other networks wherever possible in order to drive the cost of bandwidth as close to zero as possible.
You would be right if most of the small sites would need it, but the sites that use CDN usually have lots of traffic or at least bigger than average small blogging site.
for them, the paid option is a better one.
Half the internet is behind CloudFlare now. Since they can't easily "own" the Internet, they could as well own CloudFlare.
Not impressed and I hate all this hiding behind Cloudflare and other proxy services; most of the cases are just hipster/hype powered, rather than in actual need.
I noticed this when they started requiring ridiculously complicated CAPTCHAs for tor users (which they luckily toned down, I believe after the tor project guys got in touch with them). It basically broke the internet for tor users, because so many sites are behind CloudFlare.
It's sad that a single party has such power over such a large part of the internet. But of course, DDoS protection services inherently require large scale, so it's a tricky problem.
It's pretty amusing that the DNS has such a distributed design yet everyone wants to centralise their authoritative nameservers on services like Route 53 and Cloudflare. Latency shouldn't really be an argument in the case of DNS because it was designed such that folks would be using their ISPs low-latency caches/recursors
In theory, HTTP could have been the same way, if it wasn't for for complete lack of respect caching got once the web moved to dynamic database-driven designs and the temptation for middleboxes to overstep their remit.
Are you saying that Route 53 and Cloudflare don't have distributed DNS? How could they not be, when my OLD PAL 4.2.2.2 has been distributed since the 90s?
It depends on what you mean by "distributed". There are many servers behind Cloudflare's DNS servers, but they are all controlled by one organization.
Best practice is to have your DNS servers in different AS. This is not only to have many servers all over the world, which Cloudflare solves for you, but to have them accessible over different routes, not controlled by the same people. That way a configuration error somewhere (or a bad BGP route, which happens) can not put your DNS out of service.
DNS service is cheap and plentiful, and you might even have it included in your ISP deal. You might as well use it.
Also note that if you secure your records with DNSSEC, none of your DNS secondaries can tamper with your data. This is by design. You do not need to place trust in the organizations running them, so that part can be left out of your SLA.
It is also best practice to have all your public DNS servers mirror your primary master, which is not public. This is to make sure all your public servers are kept running even when you have operations issues with your primary.
I'm sure they have geographically distributed and anycasted servers. I'm talking more the moral or sociological impact, post-Snowden, of relinquishing control of our services to a handful of third parties en masse. It seems that building systems that are designed to be distributed, federated and cooperative isn't actually enough to overcome our natural tendency to want to pool resources and build communal lines of defence against the perceived 'Big Bad'.
Broken middleboxes meant HTTP/2 needed to become TLS-only, which now means middleboxes can't be used at all, which means no caching, which means we all go to Cloudflare or another CDN as a professional MITM service. It's all fairly ludicrous. In principle the idea of ISP web caches was a good one, just like how ISP provided DNS caches are essential in keeping the Internet as we know it reliable.
How do you know about actual need? They offer free DNS + CDN + SSL + bandwidth + security/DDOS which alone can save lots of cost and speed up plenty of sites. Doesn't sound "hipster" to me.
Yes there are always issues with a single company being such a big part of the internet but this applies to many other large tech companies as well in all layers, many that are quite invisible to most online users.
Is Amazon competing in this space? Since AWS is used heavily in the startup world, it seems like a no brainer to also provide cloudflare functionality, more so given that they have servers all over the world.
Well, that alone makes the move to CloudFlare even more unlikely at all. More huge investors means more control over what CF does and what CF will do with all the data they see flowing through. Bigest MITM just got bigger, at least financial wise.
Why Qualcomm? They make mobile chips. Are we going to see SoCs specially optimized for communicating with CloudFlare servers? That sounds like a potentially bad idea.
I'm guessing it's something like this: CloudFlare makes the Internet fast, which makes mobile Internet fast, which helps sell mobile phones, which use Qualcomm chips.
Both MS and QC have jointly invested in CDN mobile video streaming before like “DASH: Dynamic Adaptive Streaming for Better Mobile Video User Experience.”
Since Cloudflare has full China access the goal would be to take over the local streaming market I guess, sell Xiaomi or MS phones with streaming packages that likely MS will provide or lease out.
Sort of. CloudFlare is eating into the bottom third of Akamai's business. A skeptic on that might say that Akamai's is an enterprise, high-end solution, and that CloudFlare is for everything else - and so they don't really compete. My contention is that CloudFlare will climb upwards, taking ever great amounts of their business (as so often happens in tech).
I think that it usually is easier to climb up. Climbing down means you are fighting for lower margin customers, and have to execute flawlessly to turn a profit. It might be a bit dated by now, but The Innovators Dillema makes a strong case for the power of disruption from below.
Uber's moving down from Uber Black to UberX, Pool, etc., but wasn't really an "incumbent" (they are young), and it was fundamentally cheaper-than-limo even from the beginning (by letting you pay by the ride vs. per time block).
This is more about big established companies. It's not really even technical; it's protecting their revenue, employee/management structures, etc. built around high-end from low end.
It would be interesting to find organizations which did historically build super high end stuff which moved down into consumer. Both successful and unsuccessful examples.
iRobot MIGHT be an example -- moved down from DARPA and Packbot to the Roomba; but they weren't really established, and those were different sectors.
Apple has sort of moved downmarket from computers (and, expensive ones) to cheaper ones to phones. But those were mostly adjacent sectors, not in their core product.
I'd love some counter examples where it was within the same product, an established company (say, 10+ years selling the old product), and moved in at the low end.
Tesla is on that trajectory. But the plan was always to go for the lower market eventually and use the higher end markets to incubate the technology, so I don't know if it counts. I think you just need some serious institutional discipline to make it work.
Someone on Twitter suggested Nokia; the entire cellphone market definitely moved from high-cost to high-volume. Nokia was amazingly strong right before smartphones. Even through the smartphone days, they got costs down so the delivered cost of a Nokia phone in Africa was less than Apple pays to ship an iPhone 6S to me from China...
Curious why you say that of Sucuri? Have you tried us recently?
We have some very very large sites using our services now with great performance. During the last 6-12 months we basically rewrote our entire stack, built our anycast network and focused a lot on performance optimization and expanding out services.
Following this iOS Content Blocker furore, a CloudFlare-type service could be an ideal place from which to inject and serve ads; as opposed to the client-perf-sapping script tags the industry has been using so far.
One of their future business plans is/could be to replace your low performing ads with their higher performing ads in far-flung locations you're not optimizing for.
Personally I dislike CloudFlare for the simple reason that they encourage site owners to use their lossless image optimisation service, which isn't lossless. Thus many images appear different than intended when hosted behind CloudFlare. I wrote about this earlier: https://news.ycombinator.com/item?id=10192587
Quote from their website.
The Lossless mode removes all the unnecessary bloat from an image file, such as the image header and meta data, without removing any image data. This means images will appear exactly the same as they would have before.
The last sentence is false, at least for images with color profiles on all non-mobile browsers. There are other possible minor cases.
So does Cloudflare now get around the slowness of passing through the Great Firewall? (Currently, I don't use CF and our website is slow from inside China.)
I'd love to see more transparency in the way Cloudflare, or CDNs in general, decide to cache or not cache your content. For example: Cloudflare publishes crawl frequencies in their pricing table but what do they actually do with that content? Push it to all their edges? I'd doubt that. I guess it's based on website traffic, your website pricing plan, ... but it seems quite arbitrary to me.
All of this is answered in their documentation [1] and admin console help text.
Most CDNs only cache in the local POP on the first request and respect the headers the origin sends. The crawl frequencies are for keeping things available if your origin is offline and depends on your plan as listed on the site.
I liked the CloudFlare concept (protecting good people) until I found it protects bad people as well: scammers, thieves, cybersquatters, phishing. CloudFlare makes it very difficult to contact the web host cloaked by CloudFlare.
CloudFlare is helping the scum of the Internet. They need to be held accountable for what they're serving, if they're not going to reveal who is hosting the site. If there's a way to find the originating IP of these scumbags, I would like to know. Obviously traceroute doesn't work because the IPs show up as CloudFlare.
The way I see it, CloudFlare should be required to publish who is hosting the websites they cloak. Otherwise you're encouraging a lawless Internet where anything goes without any consequences. I sincerely hope these larger companies address this problem.
I hope some journalists dig into this because I think there's a good story here. Maybe CloudFlare doesn't have the staff to review the activities of the sites they're protecting? That's a serious problem, in my opinion, because their cloaking technology is very effective.
Have you thought about that beyond your knee-jerk reaction? One of the primary reasons for using cloudflare is resistance to denial of service attacks, and you want cloudflare to helpfully publish the real IP of the server CF is proxying for?
Scammers, thieves, phishing, and cybersquatting are weak or nonsensical reasons for demanding that CF reveal the IP they're proxying for. If a site is breaking the law, use the legal system to request the real server IP from cloudflare.
I suppose you're also against Tor, because it cloaks client-side evildoers like CF cloaks server-side evildoers?
I should be able to easily contact the web host and say, "Heads up, your server is doing some bad stuff." This works because hosts don't want to be in business with scum. They take care of it. Because it's the right thing to do, or because they would rather not be involved in a lawsuit, on the wrong side of a PR nightmare. Pretty basic, Internet 101. If I email abuse@cloudflare.com nobody gives a shit. It's irresponsible.
A lawsuit should be a last resort.
I'm not advocating a more or less anonymous Internet by criticizing CloudFlare.
I am a long-standing CF partner and supporter. This really does not fill me with happy, warm thoughts. I love the CF tech and offering, but am going to be forced to look around for alternatives.
“The world is looking for their Android,” Prince says. “We’re the Android of cloud services.”
I can't tell if this is inane exec-speak or if this means they really intend to branch out into stuff like a dropbox/gdrive storage product and a compute/ec2 like service.
full disclosure: I start work for a competitor at the end of the month
I think it's more like they're part of the "Android ecosystem" where you have a lot of choice around fundamental components, as compared to the iOS ecosystem.
I get your point that Android, broadly, is a competitor to Apple. But, I think he's not just highlighting that the world needs an Amazon alternative (it has several).
I think he's saying the world needs a more open ecosystem where they have the choice of best-of-breed components from different companies. And, in that world, you might be able to pick the world's best compute stack from one company, use Cloudflare as the world's best edge/networking stack, etc.
If a page is static, then CloudFlare can cache it. But if you set your cache headers appropriately, and use efficient serving code like nginx, I imagine serving static content is pretty darn cheap.
If a page is dynamic, then how can CloudFlare really speed it up? You don't want them serving stale pages to users. So it has to hit your server every time, in which case the user might as well hit your server. In that case, I don't really see how CloudFlare improves things.
Am I misunderstanding how CloudFlare works? It seems like if you follow typical performance tips like [1] then most of CloudFlare's benefit is eliminated.
I guess [1] does tell you to use a CDN. You can save end user network latency for cached static pages, since they cache them in multiple geographic locations. But if you have a simple site with 1 .js and 1 .css file per page, and compress and minify everything, I wonder if it's worth it.
[1] http://www.amazon.com/dp/0596529309