8 ms·

I assume a load balancing / caching solution that is available on an anycast IP address. The TLS termination happens at the (ideally) closest point of presence

I assume a load balancing / caching solution that is available on an anycast IP address. The TLS termination happens at the (ideally) closest point of presence (PoP). The idea is to reduce the RTT from client to its termination point. Think CloudFlare CDN or the Google Cloud Load Balancer. Edit Mistyped RTT as TTL.

bogomipz 9y ago
Sure, you can reduce the RTT by moving the edge closer to the eyeballs but that's not the same as avoiding an RTT as the OP stated. That's what all I was commenting on. There are mechanisms however to do that such as sessions tickets/resumption but that's not something specific to load balancers.
- kelnos 9y ago
  The OP didn't claim using a "global" LB would eliminate round-trips, just that you should use one because of the round trips.
  - bogomipz 9y ago
    The OP stated: >"There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL." "Avoiding" means not incurring them, so yes they did claim a "global" LB would eliminate round trips.
    - mrkurt 9y ago
      That actually wasn't what I meant to claim, but it's too late to edit! It was an awkward sentence for sure. The simpler sentence is: minimize round trip cost by getting close to users. Also avoid round trips if you can. :)
      - bogomipz 9y ago
        If you are terminating TLS on an edge network then you are likely caching the content there as well so as not to incur the latency in fetching it from origin. This is called a CDN not a load balancer.
        mrkurt 9y ago
        There are a bunch of relatively pure global load balancer services available out there. Google Cloud's load balancer, for example. It works pretty well to terminate SSL close to visitors then maintain connections from load balancers back to app instances.
- hueving 9y ago
  You avoid an RTT to the web server by having TLS terminate in the load balancer.
  - deleted 9y ago
    [deleted]

bogomipz 9y ago

Sure, you can reduce the RTT by moving the edge closer to the eyeballs but that's not the same as avoiding an RTT as the OP stated. That's what all I was commenting on. There are mechanisms however to do that such as sessions tickets/resumption but that's not something specific to load balancers.

kelnos 9y ago
The OP didn't claim using a "global" LB would eliminate round-trips, just that you should use one because of the round trips.
- bogomipz 9y ago
  The OP stated: >"There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL." "Avoiding" means not incurring them, so yes they did claim a "global" LB would eliminate round trips.
  - mrkurt 9y ago
    That actually wasn't what I meant to claim, but it's too late to edit! It was an awkward sentence for sure. The simpler sentence is: minimize round trip cost by getting close to users. Also avoid round trips if you can. :)
    - bogomipz 9y ago
      If you are terminating TLS on an edge network then you are likely caching the content there as well so as not to incur the latency in fetching it from origin. This is called a CDN not a load balancer.
      - mrkurt 9y ago
        There are a bunch of relatively pure global load balancer services available out there. Google Cloud's load balancer, for example. It works pretty well to terminate SSL close to visitors then maintain connections from load balancers back to app instances.
hueving 9y ago
You avoid an RTT to the web server by having TLS terminate in the load balancer.
- deleted 9y ago
  [deleted]