5 ms·

While I agree with many of the points made, his estimation of the number of round trips is way off. For a start, TLS negotiation requires several round trips b

While I agree with many of the points made, his estimation of the number of round trips is way off. For a start, TLS negotiation requires several round trips before you even start speaking HTTP. Secondly, browsers (depending on vendor, version and number of domains) have a limit to the number of in flight requests. Thirdly, many pages load some assets via javascript execution, which adds another set of round trips. As Cloudflare are very widely peered (I think they are now the most widely peered company), and as such are almost certainly closer to the end user than the origin server. This does really matter when making lots of round trips, which is in practice closer to inevitable (unless you have a small SPDY or HTTP/2 site, which is approximately no one).

joepie91_ 10y ago
> While I agree with many of the points made, his estimation of the number of round trips is way off. It was admittedly a simplified equation, more for illustrative purposes than for argumentative purposes. > For a start, TLS negotiation requires several round trips before you even start speaking HTTP. While true, I'm using just-HTTP as a baseline. There are various techniques for reducing TLS roundtrip time, and it's so heavily dependent on the environment that it doesn't make for a practical baseline. > Secondly, browsers (depending on vendor, version and number of domains) have a limit to the number of in flight requests. Correct. But this is typically solved by bundling assets (on the server side) or increasing that amount (on the client side). On a well-designed site, this should not pose issues. > As Cloudflare are very widely peered (I think they are now the most widely peered company), and as such are almost certainly closer to the end user than the origin server. The point is that the same applies to Anycast CDNs (which CloudFlare is not, really, it's a proxy), but without the privacy issues. CF isn't really a good solution to this.
- giovannibajo1 10y ago
  I don't think anybody is arguing that Cloudflare provides unique features that can't be obtained otherwise. The point is that CF is VERY convenient to use compared to having to do everything you mentioned through different services and then even some more. With Cloudflare you essentially get distributed DNS, a very fast and universally peered CDN, SSL support, IPv6 support, DNSSEC support, HTTP/2 support, website optimizations like responsive images or JS packing, all essentially with one click and for free, and without having to change a line in your code. And if you hit a DDOS, you swipe your card and you are done. This is their USP. Stating that "you can write code and/or do/configure/buy things so that in the end you can avoid using it" is true, but it's a hard sell for an average business. The only way to avoid the Cloudflare monoculture is that true competitors arise. As much as you can hate it, a reverse proxy seems like what people want for this, and Cloudflare has even developed a workaround for the trust issues (keyless SSL) that competitors could offer to non enterprise costumers. I think there's space in that market.
  - joepie91_ 10y ago
    This is essentially arguing that "letting a centralized gatekeeper do all this is easier". While technically true, it also completely misses the point of the web and how it was designed - namely, to be decentralized and not require this. The thing is that "ease of use" isn't the only metric that matters, even if it's the easiest metric to sell. More often than not - especially in more recent 'startup culture' - something being 'easier' just means that it's not doing it correctly, and that somebody somewhere is conveniently ignoring the tradeoffs.
    - giovannibajo1 10y ago
      No, what I am arguing is that the CF design of "glorified reverse proxy" is basically a very good product with strong market demand that faces close to zero competition. Compare this to AWS. AWS also "runs" shitloads of the web today; but still, the "centralization" problem is less mentioned in the context of AWS because there is fierce competition (Google, and also OpenStack and all the OpenStack clouds from major vendors). Reverse proxies are "centralized gatekeepers" but no more than a hosting provider is, and we accept those as normal (right?). What if there were 5-6 big players in the "reverse proxy" market, plus a hundred of smaller offerings? Wouldn't that basically solve all the issues of those worried about the "open web"?
- manigandham 10y ago
  > There are various techniques for reducing TLS roundtrip time, and it's so heavily dependent on the environment that it doesn't make for a practical baseline. One of the best techniques is using a CDN to get the TLS termination closer to the user. This is done by every major company. There is no practical alternative if you serve a global audience. > But this is typically solved by bundling assets (on the server side) or increasing that amount (on the client side). On a well-designed site, this should not pose issues. It's not just the number of requests but the latency involved. Having a request done in 20ms from a local cache vs 500ms from a far away server makes a massive difference in web performance. You are just making up these scenarios where there are countless discussions, tests, studies, reports and conferences that talk about best practices for performance which is exactly the opposite of everything you state. > The point is that the same applies to Anycast CDNs (which CloudFlare is not, really, it's a proxy), but without the privacy issues. CF isn't really a good solution to this. Every major CDN is an anycast reverse proxy today, name one that isnt. I dont think you understand what a "proxy" is.
  - joepie91_ 10y ago
    > One of the best techniques is using a CDN to get the TLS termination closer to the user. This is done by every major company. There is no practical alternative if you serve a global audience. "Best"? Absolutely not. Unless you control the TLS terminators (which is the case for major companies), this completely breaks the security that TLS is supposed to provide. Fastest? Perhaps. > It's not just the number of requests but the latency involved. Having a request done in 20ms from a local cache vs 500ms from a far away server makes a massive difference in web performance. You are just making up these scenarios where there are countless discussions, tests, studies, reports and conferences that talk about best practices for performance which is exactly the opposite of everything you state. Those same tests show that the problem is generally not in the network latency, and that the optimizations needed to get performance to an acceptable level are usually of an entirely different nature - compressing images, bundling assets, loading order, not loading megabytes of JS at once, using CSS for styling rather than JS, and so on. Note that I am talking about acceptable here, not optimal (from a performance perspective). Yes, you may be able to optimize performance beyond what you need, but at what cost? And is this really worth it if you've already hit the 'acceptable' point anyway? What's the point? > Every major CDN is an anycast reverse proxy today, name one that isnt. I dont think you understand what a "proxy" is. I'm not talking about something being technically classifiable as a "reverse proxy". I'm talking about things that function as a reverse proxy for a site. Many CDNs offer plans where the only thing they are caching are the static assets, and they need to be explicitly referenced through a CDN URL. Some CDNs - in particular those handling video - even just let the customer upload the content to their infrastructure, and then proxy to their own backend storage, sometimes with transcoding services included. CloudFlare works differently, and proxies the actual requests on the main domain of the site itself, caching some of the requests but not others. This has fundamentally different implications, because now suddenly dynamic data is proxied without any caching whatsoever, personal data is going through them, and so on. Yes, both technically use reverse proxying technology in their stack, but in the end they are completely different approaches.

joepie91_ 10y ago

> While I agree with many of the points made, his estimation of the number of round trips is way off. It was admittedly a simplified equation, more for illustrative purposes than for argumentative purposes. > For a start, TLS negotiation requires several round trips before you even start speaking HTTP. While true, I'm using just-HTTP as a baseline. There are various techniques for reducing TLS roundtrip time, and it's so heavily dependent on the environment that it doesn't make for a practical baseline. > Secondly, browsers (depending on vendor, version and number of domains) have a limit to the number of in flight requests. Correct. But this is typically solved by bundling assets (on the server side) or increasing that amount (on the client side). On a well-designed site, this should not pose issues. > As Cloudflare are very widely peered (I think they are now the most widely peered company), and as such are almost certainly closer to the end user than the origin server. The point is that the same applies to Anycast CDNs (which CloudFlare is not, really, it's a proxy), but without the privacy issues. CF isn't really a good solution to this.

giovannibajo1 10y ago
I don't think anybody is arguing that Cloudflare provides unique features that can't be obtained otherwise. The point is that CF is VERY convenient to use compared to having to do everything you mentioned through different services and then even some more. With Cloudflare you essentially get distributed DNS, a very fast and universally peered CDN, SSL support, IPv6 support, DNSSEC support, HTTP/2 support, website optimizations like responsive images or JS packing, all essentially with one click and for free, and without having to change a line in your code. And if you hit a DDOS, you swipe your card and you are done. This is their USP. Stating that "you can write code and/or do/configure/buy things so that in the end you can avoid using it" is true, but it's a hard sell for an average business. The only way to avoid the Cloudflare monoculture is that true competitors arise. As much as you can hate it, a reverse proxy seems like what people want for this, and Cloudflare has even developed a workaround for the trust issues (keyless SSL) that competitors could offer to non enterprise costumers. I think there's space in that market.
- joepie91_ 10y ago
  This is essentially arguing that "letting a centralized gatekeeper do all this is easier". While technically true, it also completely misses the point of the web and how it was designed - namely, to be decentralized and not require this. The thing is that "ease of use" isn't the only metric that matters, even if it's the easiest metric to sell. More often than not - especially in more recent 'startup culture' - something being 'easier' just means that it's not doing it correctly, and that somebody somewhere is conveniently ignoring the tradeoffs.
  - giovannibajo1 10y ago
    No, what I am arguing is that the CF design of "glorified reverse proxy" is basically a very good product with strong market demand that faces close to zero competition. Compare this to AWS. AWS also "runs" shitloads of the web today; but still, the "centralization" problem is less mentioned in the context of AWS because there is fierce competition (Google, and also OpenStack and all the OpenStack clouds from major vendors). Reverse proxies are "centralized gatekeepers" but no more than a hosting provider is, and we accept those as normal (right?). What if there were 5-6 big players in the "reverse proxy" market, plus a hundred of smaller offerings? Wouldn't that basically solve all the issues of those worried about the "open web"?
manigandham 10y ago
> There are various techniques for reducing TLS roundtrip time, and it's so heavily dependent on the environment that it doesn't make for a practical baseline. One of the best techniques is using a CDN to get the TLS termination closer to the user. This is done by every major company. There is no practical alternative if you serve a global audience. > But this is typically solved by bundling assets (on the server side) or increasing that amount (on the client side). On a well-designed site, this should not pose issues. It's not just the number of requests but the latency involved. Having a request done in 20ms from a local cache vs 500ms from a far away server makes a massive difference in web performance. You are just making up these scenarios where there are countless discussions, tests, studies, reports and conferences that talk about best practices for performance which is exactly the opposite of everything you state. > The point is that the same applies to Anycast CDNs (which CloudFlare is not, really, it's a proxy), but without the privacy issues. CF isn't really a good solution to this. Every major CDN is an anycast reverse proxy today, name one that isnt. I dont think you understand what a "proxy" is.
- joepie91_ 10y ago
  > One of the best techniques is using a CDN to get the TLS termination closer to the user. This is done by every major company. There is no practical alternative if you serve a global audience. "Best"? Absolutely not. Unless you control the TLS terminators (which is the case for major companies), this completely breaks the security that TLS is supposed to provide. Fastest? Perhaps. > It's not just the number of requests but the latency involved. Having a request done in 20ms from a local cache vs 500ms from a far away server makes a massive difference in web performance. You are just making up these scenarios where there are countless discussions, tests, studies, reports and conferences that talk about best practices for performance which is exactly the opposite of everything you state. Those same tests show that the problem is generally not in the network latency, and that the optimizations needed to get performance to an acceptable level are usually of an entirely different nature - compressing images, bundling assets, loading order, not loading megabytes of JS at once, using CSS for styling rather than JS, and so on. Note that I am talking about acceptable here, not optimal (from a performance perspective). Yes, you may be able to optimize performance beyond what you need, but at what cost? And is this really worth it if you've already hit the 'acceptable' point anyway? What's the point? > Every major CDN is an anycast reverse proxy today, name one that isnt. I dont think you understand what a "proxy" is. I'm not talking about something being technically classifiable as a "reverse proxy". I'm talking about things that function as a reverse proxy for a site. Many CDNs offer plans where the only thing they are caching are the static assets, and they need to be explicitly referenced through a CDN URL. Some CDNs - in particular those handling video - even just let the customer upload the content to their infrastructure, and then proxy to their own backend storage, sometimes with transcoding services included. CloudFlare works differently, and proxies the actual requests on the main domain of the site itself, caching some of the requests but not others. This has fundamentally different implications, because now suddenly dynamic data is proxied without any caching whatsoever, personal data is going through them, and so on. Yes, both technically use reverse proxying technology in their stack, but in the end they are completely different approaches.