3 ms·

> 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 alternativ

> 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.

manigandham 10y ago
> Unless you control the TLS terminators Nope, this is all about trusting vendors. Unless you're building your own computer chips and laying your own fiber, you're just blaming a vendor for what seems like personal issues. > problem is generally not in the network latency Again years of research has shown this is one of the biggest issues on the web. Read https://www.igvita.com/ https://www.igvita.com/ for some good info. > Yes, both technically use reverse proxying technology in their stack, but in the end they are completely different approaches. Nope, this clearly shows you don't have any understanding. CF is a CDN. That's it. Instead of like other CDNs that offer a CNAME that you point your DNS to, they just offer a free DNS service that automates the CNAME entry into a single button. All CDNs today are reverse proxies that will either return a cached response or proxy the request to the origin if the cache is empty. You can also use every CDN to proxy dynamic requests and many do. And yes, there are a few that offer a push model where you upload assets explicitly but this is the exception, not the standard. You're talking about CF as if they're something unique when they do exactly the same thing as everyone else. Use them on a subdomain if you want and leave the main domain unproxied, use them only for static files or for dynamic requests, use them to proxy everything or cache everything including HTML. It's all just configuration. Why is this such a problem for you?

manigandham 10y ago

> Unless you control the TLS terminators Nope, this is all about trusting vendors. Unless you're building your own computer chips and laying your own fiber, you're just blaming a vendor for what seems like personal issues. > problem is generally not in the network latency Again years of research has shown this is one of the biggest issues on the web. Read https://www.igvita.com/ https://www.igvita.com/ for some good info. > Yes, both technically use reverse proxying technology in their stack, but in the end they are completely different approaches. Nope, this clearly shows you don't have any understanding. CF is a CDN. That's it. Instead of like other CDNs that offer a CNAME that you point your DNS to, they just offer a free DNS service that automates the CNAME entry into a single button. All CDNs today are reverse proxies that will either return a cached response or proxy the request to the origin if the cache is empty. You can also use every CDN to proxy dynamic requests and many do. And yes, there are a few that offer a push model where you upload assets explicitly but this is the exception, not the standard. You're talking about CF as if they're something unique when they do exactly the same thing as everyone else. Use them on a subdomain if you want and leave the main domain unproxied, use them only for static files or for dynamic requests, use them to proxy everything or cache everything including HTML. It's all just configuration. Why is this such a problem for you?