4 ms·

> It’s about improving end-user performance through things like having edge termination of TLS. Err, wouldn't the CDN itself still need to do the same TLS hand

> It’s about improving end-user performance through things like having edge termination of TLS. Err, wouldn't the CDN itself still need to do the same TLS handsake with the end server?

tailspin2019 5y ago
In my case I use Cloudflare Tunnel [0] which is an actual agent installed on my web servers that creates a reverse tunnel back to Cloudflare's network. This creates a complete disconnection between whatever TLS handshakes are happening between the client and my CDN (Cloudflare) and whatever's going on locally between the tunnel daemon and my local web server process. For example you can choose to run these tunnels without HTTPS at all on your local webserver (bearing in mind that you have no inbound firewall ports open to the webserver box - no traffic leaves that box unencrypted), the daemon directly proxies your local-only HTTP port on the machine over an encrypted tunnel to Cloudflare and via whatever flavour of Cloudflare TLS you like to your end-users. [0] https://www.cloudflare.com/en-gb/products/tunnel/ https://www.cloudflare.com/en-gb/products/tunnel/
q3k 5y ago
Most CDNs out there maintain a pool of HTTPS keep-alive'd connections to backing services. This eliminates the roundtrip needed for establishing a TCP connection and the roundtrip (or two) needed for setting up TLS. Another reason a no-caching CDN can help is when that CDN has a higher quality connection to the backing service than the user has. A lot of eyeball networks out there might have terrible transit connectivity to the global Internet during peak hours (because that cost money), but generally have high quality settlement-free peering with CDNs. By paying a CDN, you're effectively paying them to provide better Internet connectivity to your users.
- nrmitchi 5y ago
  This is, unfortunately, such a good point that I hadn't considered in the past.
  - q3k 5y ago
    Mind you though, I'm not blindly advocating for CDNs. :) In fact, I think that the performance gain is not worth the extra complexity for most sites out there. The recent fastly outage, klarna outage, ... all show that CDNs are no silver bullet.
  - glenngillen 5y ago
    A somewhat (I’m clutching approximate recollections from memory) relevant example from a customer I was helping while at a previous employer: All infrastructure ran in us-east-1. A considerable percentage (but not the majority) of their customers were based in Australia, and quite a few of them were complaining about sluggish performance. HTTP/1.1 + TLS meant connection handshake alone took over 5 seconds! Before the first useful bit of content was sent. Add in the additional pain of a web framework that was still splitting assets across multiple asset hosts (to compensate for old browser “feature” that limited the number of concurrent requests to a single domain”). Over 30 seconds of connection setup, some of it in parallels, almost all of it blocking page render because it was for HTML or dependent scripts. Add in a CDN (no caching) and edge termination meant single-digit millisecond handshakes to a POP in the closest major city. Also had the ability enable HTTP/2 at the edge without needing to change anything else which meant improved connection pooling for clients and less connection setup overhead. Backhaul connection reuse also has the benefit of pooling all requests via a specific POP rather than each individual client. We got rid of the asset host thing while we were at it. Just a CDN, no caching, and a greater than ~30000ms reduction in request times for anyone far from us-east-1!
otterley 5y ago
CDN edge servers maintain a warm pool of TCP/TLS connections to origin servers, which eliminates the need for a handshake and significantly improves performance.
CogitoCogito 5y ago
I'm not an expert, but if the TLS handshake occurs closer (as in latency) to the client and the actual request/response payload is small (or if the CDN's network is better), then it seems like terminating in a CDN could certainly be better than not.

> It’s about improving end-user performance through things like having edge termination of TLS. Err, wouldn't the CDN itself still need to do the same TLS handsake with the end server?

tailspin2019 5y ago

In my case I use Cloudflare Tunnel [0] which is an actual agent installed on my web servers that creates a reverse tunnel back to Cloudflare's network. This creates a complete disconnection between whatever TLS handshakes are happening between the client and my CDN (Cloudflare) and whatever's going on locally between the tunnel daemon and my local web server process. For example you can choose to run these tunnels without HTTPS at all on your local webserver (bearing in mind that you have no inbound firewall ports open to the webserver box - no traffic leaves that box unencrypted), the daemon directly proxies your local-only HTTP port on the machine over an encrypted tunnel to Cloudflare and via whatever flavour of Cloudflare TLS you like to your end-users. [0] https://www.cloudflare.com/en-gb/products/tunnel/ https://www.cloudflare.com/en-gb/products/tunnel/

q3k 5y ago

Most CDNs out there maintain a pool of HTTPS keep-alive'd connections to backing services. This eliminates the roundtrip needed for establishing a TCP connection and the roundtrip (or two) needed for setting up TLS. Another reason a no-caching CDN can help is when that CDN has a higher quality connection to the backing service than the user has. A lot of eyeball networks out there might have terrible transit connectivity to the global Internet during peak hours (because that cost money), but generally have high quality settlement-free peering with CDNs. By paying a CDN, you're effectively paying them to provide better Internet connectivity to your users.

nrmitchi 5y ago
This is, unfortunately, such a good point that I hadn't considered in the past.
- q3k 5y ago
  Mind you though, I'm not blindly advocating for CDNs. :) In fact, I think that the performance gain is not worth the extra complexity for most sites out there. The recent fastly outage, klarna outage, ... all show that CDNs are no silver bullet.
- glenngillen 5y ago
  A somewhat (I’m clutching approximate recollections from memory) relevant example from a customer I was helping while at a previous employer: All infrastructure ran in us-east-1. A considerable percentage (but not the majority) of their customers were based in Australia, and quite a few of them were complaining about sluggish performance. HTTP/1.1 + TLS meant connection handshake alone took over 5 seconds! Before the first useful bit of content was sent. Add in the additional pain of a web framework that was still splitting assets across multiple asset hosts (to compensate for old browser “feature” that limited the number of concurrent requests to a single domain”). Over 30 seconds of connection setup, some of it in parallels, almost all of it blocking page render because it was for HTML or dependent scripts. Add in a CDN (no caching) and edge termination meant single-digit millisecond handshakes to a POP in the closest major city. Also had the ability enable HTTP/2 at the edge without needing to change anything else which meant improved connection pooling for clients and less connection setup overhead. Backhaul connection reuse also has the benefit of pooling all requests via a specific POP rather than each individual client. We got rid of the asset host thing while we were at it. Just a CDN, no caching, and a greater than ~30000ms reduction in request times for anyone far from us-east-1!

otterley 5y ago

CDN edge servers maintain a warm pool of TCP/TLS connections to origin servers, which eliminates the need for a handshake and significantly improves performance.

CogitoCogito 5y ago

I'm not an expert, but if the TLS handshake occurs closer (as in latency) to the client and the actual request/response payload is small (or if the CDN's network is better), then it seems like terminating in a CDN could certainly be better than not.