2

I have an api into which ill get quite a few requests in https. Since its restful, each time the api is sent , it requires a full ssl handshake. On enabling http-keepalive , the latency of the request is reduced greatly (first request takes same time, but subsequent requests are as fast as http).

Now, I was experimenting with amazon's elb (I will also use cloud front). My question is, how will keep alive work in the same setup , where the request coming from a client can be routed to different machines randomly ?
Or is it not possible at all to prevent an ssl handshake each time a request is made ?

harveyslash
  • 129
  • 2
  • 10
  • 1
    Note SSL/TLS (including HTTPS) connections between the same endpoints within a reasonable time (often an hour) _should_ be able to use an _abbreviated_ handshake (aka Session Resumption) not a _full_ handshake. That said, keep-alive (or equivalent) gives _no_ handshake, which is even better. – dave_thompson_085 Jun 18 '16 at 13:33

1 Answers1

6

Yes, AWS ELB will re-use open connections to backends when possible, while still trying to distribute the load as it's configured to do so. AWS even recommends this as a best practice in their docs:

For HTTP and HTTPS listeners, we recommend that you enable the keep-alive option in your EC2 instances, which enables the load balancer to re-use the connections to your instances for multiple client requests. This reduces the load on your web server and improves the throughput of the load balancer. The keep-alive timeout should be at least 60 seconds to ensure that the load balancer is responsible for closing the connection to your instance.

ETA: Note that the ELB doesn't actually hand a client connection off to a back-end. All requests between the client and the backend still get passed through the ELB in both directions. You can either have the ELB terminate SSL from the client (assuming that's HTTPS) and then creates or re-uses its own HTTPS connection (if configured to do so) to the backend, or you can choose to terminate SSL at the backend only.

Karen B
  • 534
  • 3
  • 7
  • so does elb know that a client had connected earlier , and then it forwards its connection to the right server that has the http connection open for that client ? – harveyslash Jun 18 '16 at 08:21
  • The client never has a direct network connection to a backend. You can enable the ELB to send requests from a previous client to the same backend (note that the request, though, not the actual network connection, goes to the backend) with sticky sessions (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html), though, but again, the ELB remains in the middle through the whole transaction. – Karen B Jun 18 '16 at 08:29
  • but then , will https handshakes be required everytime without sticky sessions? or will keep alive work and prevent it ? – harveyslash Jun 18 '16 at 08:31
  • If you want to keep your client connected to the ELB to re-use the connection, you can do that, too. http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html Just keep in mind that you have two connections to think about now: one from the client to the ELB, and one from the ELB to the backend. (The client never has a direct connection to a backend instance.) – Karen B Jun 18 '16 at 08:32
  • ohhh, so whatever keep alive ness I need to reduce latency has nothing to do with my ec2 at all ? the elb should do the keep alive for fewer ssl handshakes ? – harveyslash Jun 18 '16 at 08:34
  • 1
    You have to handle both ends, so you do need to set the keepalive on the back EC2 instance and the ELB for that connection, but it sounds like you also want to do the same for the client->ELB connection. Both are configurable, although not in the same place. (You need to set the instance keepalive in the instance's web server and OS, and the ELB keepalive in that configuration: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-idle-timeout.html) – Karen B Jun 18 '16 at 08:57
  • @harvey_slash note also that sticky sessions have nothing at all to do with keep-alive or "connections" in the general sense. Stickiness only means that the ELB will send subsequent requests from the same client ("same" means a client presenting the same cookie) to the same back-end instance (when there is more than one), whether it is within the time frame of a single kept-alive connection, or at some point in the near future. If you have only one back-end, sticky sessions have no impact at all. – Michael - sqlbot Jun 18 '16 at 16:03