> This only works when you're buying _a lot_ of bandwidth or you're buying cheap bandwidth (which usually has sub-standard routing). If you host your app servers on a standard cloud like AWS you're paying dollars per TB (but you're on a damn good network).
Sure. This is why I explicitly stated single-homed. For datacenter blend, you typically pay between $1 and $5 per TB, and most providers don't add much (if any) on top of that in terms of costs. That's considerably cheaper than what AWS charges, for comparable routing.
> DDoS mitigation services in many cases consist primarily of "we'll blackhole your IP if one happens". DDoS mitigation services that are affordable and leave your site running are costly.
That's just plain wrong. If nullrouting happens upon attack, then it was never a DDoS mitigation to begin with (and yes, I am aware that some sketchy hosts try to sell this as "DDoS protection"). None of the options I've listed fall into that category.
> The web is _maybe_ generally Fast Enough when you're lucky to be on an ISP and network connection that gives you a decent path to wherever your content is hosted but that's not a given, particularly these days when the majority of most services' users are mobile, users are increasingly geographically distributed and consumer ISPs are increasingly hostile towards service providers (e.g. if your transit was through Cogent, Comcast's Netflix dispute may have interfered).
I'm taking all of these into account in my assertions.
> You haven't provided nearly enough evidence to backup this statement.
I've addressed all the arguments I've commonly heard, and offered to cover any other usecases through e-mail or the comments. What more are you expecting? Magic?
> So what you're saying is that a DDoS isn't hitting my servers and my users still get their content? That's called DDoS mitigation. Just because it doesn't work the way you're used to doesn't mean it's not working.
Nope. The moment somebody locates your origin - and somebody will - you're boned, with no way to mitigate it whatsoever. DDoS mitigation can only be effective if it actually isolates the backend, which CloudFlare doesn't (and cannot) do.
> Preventing automated systems from making requests to your site when you're in the middle of a DDoS seems sensible enough.
It's not. You don't want to prevent automated traffic, you want to prevent attacker traffic. Completely different category.
> If it's truly necessary (and permitted), contact the site and ask for the IP of the backend. If your work is appreciated, they'll give it to you.
How do you propose a search engine spider does this, exactly?
> As a site operator, if you want to archive my site, I'd rather you contact me. I'll give you my backend IP and hell, might even give you rsync access or something.
We did, in the particular case I am referring to. The operator ignored our messages.
> Archiving through a browser is the least desirable way to have my stuff archived.
That's not true from an archival perspective, even if it is true from a resource usage perspective; you ideally want to archive all content like it is presented to the user, so that you can replicate it later (which is what eg. the Wayback Machine does, and why WARC is the canonical format for this).
> I'm located in Silicon Valley and a ping to Germany takes 172ms, a ping to Canada takes 90, a ping to Amsterdam takes 154 and so on. A ping to San Jose where my nearest CloudFlare/Akamai/everything POP is located takes 14ms.
Okay, and?
> This is incredibly optimistic. Open up the Network tab in Chrome's dev tools and open Amazon, Facebook, even a WordPress blog sometime. Hell, HN's front page barely loads that fast.
Have a look at what's causing the delays. Hint: it's usually not the static assets of the site itself.
> CloudFlare is a CDN. Why not use CloudFlare as a CDN for your static assets? CloudFlare isn't making you turn it on for all your domains. You can totally turn CloudFlare on for static.mysite.com and leave mysite.com on your own server.
Sure, possible. But who actually does this? And why would they, if it takes extra work? And why would you expect people to do that if the whole selling point of CloudFlare is not having to think about this kind of stuff?
How it can be used in theory doesn't really matter. The practical consequences do. And those are not pretty, at all. If CloudFlare wants to become less of a threat to the web, then perhaps they should take the first step in preventing the harmful ways of using it.
> This is the same for every CDN and like every CDN, you're relying on the CDN's internal network to get somewhere faster than your own would, and for the CDN's cache to eliminate the need even to do the round trip. If the content is already in Asia, the CDN doesn't need to make the request back to the origin at all. That eliminates entire intercontinental round trips and that's massive.
I am aware. That section is referring specifically to dynamic content, static content having already been covered by the bit on CDNs.
> No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people.
These "philosophies and concerns" are core to the web and how it was designed to work, and it'd probably be a good idea to try and understand why they are as they are.
It's a cheap cop-out to just wave everything away as "well, that's just, like, your opinion, man" and pretend that that somehow makes all the real-world consequences go away. It doesn't.
And yes, I am aware that these features are beneficial to many people. That's why I provided alternatives that didn't have the same issues.
Sure. This is why I explicitly stated single-homed. For datacenter blend, you typically pay between $1 and $5 per TB, and most providers don't add much (if any) on top of that in terms of costs. That's considerably cheaper than what AWS charges, for comparable routing.
> DDoS mitigation services in many cases consist primarily of "we'll blackhole your IP if one happens". DDoS mitigation services that are affordable and leave your site running are costly.
That's just plain wrong. If nullrouting happens upon attack, then it was never a DDoS mitigation to begin with (and yes, I am aware that some sketchy hosts try to sell this as "DDoS protection"). None of the options I've listed fall into that category.
> The web is _maybe_ generally Fast Enough when you're lucky to be on an ISP and network connection that gives you a decent path to wherever your content is hosted but that's not a given, particularly these days when the majority of most services' users are mobile, users are increasingly geographically distributed and consumer ISPs are increasingly hostile towards service providers (e.g. if your transit was through Cogent, Comcast's Netflix dispute may have interfered).
I'm taking all of these into account in my assertions.
> You haven't provided nearly enough evidence to backup this statement.
I've addressed all the arguments I've commonly heard, and offered to cover any other usecases through e-mail or the comments. What more are you expecting? Magic?
> So what you're saying is that a DDoS isn't hitting my servers and my users still get their content? That's called DDoS mitigation. Just because it doesn't work the way you're used to doesn't mean it's not working.
Nope. The moment somebody locates your origin - and somebody will - you're boned, with no way to mitigate it whatsoever. DDoS mitigation can only be effective if it actually isolates the backend, which CloudFlare doesn't (and cannot) do.
> Preventing automated systems from making requests to your site when you're in the middle of a DDoS seems sensible enough.
It's not. You don't want to prevent automated traffic, you want to prevent attacker traffic. Completely different category.
> If it's truly necessary (and permitted), contact the site and ask for the IP of the backend. If your work is appreciated, they'll give it to you.
How do you propose a search engine spider does this, exactly?
> As a site operator, if you want to archive my site, I'd rather you contact me. I'll give you my backend IP and hell, might even give you rsync access or something.
We did, in the particular case I am referring to. The operator ignored our messages.
> Archiving through a browser is the least desirable way to have my stuff archived.
That's not true from an archival perspective, even if it is true from a resource usage perspective; you ideally want to archive all content like it is presented to the user, so that you can replicate it later (which is what eg. the Wayback Machine does, and why WARC is the canonical format for this).
> I'm located in Silicon Valley and a ping to Germany takes 172ms, a ping to Canada takes 90, a ping to Amsterdam takes 154 and so on. A ping to San Jose where my nearest CloudFlare/Akamai/everything POP is located takes 14ms.
Okay, and?
> This is incredibly optimistic. Open up the Network tab in Chrome's dev tools and open Amazon, Facebook, even a WordPress blog sometime. Hell, HN's front page barely loads that fast.
Have a look at what's causing the delays. Hint: it's usually not the static assets of the site itself.
> CloudFlare is a CDN. Why not use CloudFlare as a CDN for your static assets? CloudFlare isn't making you turn it on for all your domains. You can totally turn CloudFlare on for static.mysite.com and leave mysite.com on your own server.
Sure, possible. But who actually does this? And why would they, if it takes extra work? And why would you expect people to do that if the whole selling point of CloudFlare is not having to think about this kind of stuff?
How it can be used in theory doesn't really matter. The practical consequences do. And those are not pretty, at all. If CloudFlare wants to become less of a threat to the web, then perhaps they should take the first step in preventing the harmful ways of using it.
> This is the same for every CDN and like every CDN, you're relying on the CDN's internal network to get somewhere faster than your own would, and for the CDN's cache to eliminate the need even to do the round trip. If the content is already in Asia, the CDN doesn't need to make the request back to the origin at all. That eliminates entire intercontinental round trips and that's massive.
I am aware. That section is referring specifically to dynamic content, static content having already been covered by the bit on CDNs.
> No, you have opinions biased by (valid but not universal) philosophies and concerns. These features are desired and beneficial to many people.
These "philosophies and concerns" are core to the web and how it was designed to work, and it'd probably be a good idea to try and understand why they are as they are.
It's a cheap cop-out to just wave everything away as "well, that's just, like, your opinion, man" and pretend that that somehow makes all the real-world consequences go away. It doesn't.
And yes, I am aware that these features are beneficial to many people. That's why I provided alternatives that didn't have the same issues.