2

I have a Go server that is currently running with Kubernetes on AWS. The website sits under a route-53 and an ELB that manages the SSL termination. Now, I want to support HTTP/2 in my web-server in order to push resources to the clients, and I saw that HTTP/2 requires that the web-server will use HTTPS. I have a few questions according to that.

  • HTTP/2 requires HTTPS - In my case the HTTPS logic is in the ELB and it manages for me the SSL termination. My application gets the decrypted data as a simple HTTP request. Do I need to remove the ELB in order to enable HTTP/2 in my web-server? Is there any way to leave the ELB there and enable HTTP/2 in my web-server?

  • In my local development I use openssl to generate certificate. If I deploy the web-server I need to get the CA certificate from AWS and store it somewhere in the Kubernetes certificate-manager and inject to my web-server in the initialization. What is the recommended way to do this?

I feel like I miss something, so I'll appreciate any help. Thanks

mux
  • 455
  • 5
  • 10

2 Answers2

2

The new ELB supports HTTP/2 (https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/) but not the Push attribute (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-configuration): “You can't use the server-push feature of HTTP/2”

If you want to use Push you can use the ELB as a level four TCP LoadBalancer and enable this at your webserver. For HaProxy it is also possible to still offset SSL/TLS with this set up (HTTP/2 behind reverse proxy) but not sure if similar is possible under ELB (probably not). This is because while HTTP/2 requires HTTPS from all the major browsers it is not a requirement of the protocol itself so load balancer -> server can be over HTTP/2 without HTTPS (called h2c).

However I would say that HTTP/2 Push is very complicated to get right - read this excellent post by Jake Archibald of Google on this: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/. It’s generally been found to benefit in a few cases and cause no change in most and even cause degradation in performance in others. Ultimately it’s a bit of a let down in HTTP/2 features, though personally I don’t think it’s been explored enough so may be some positives to come out of it yet.

So if you don’t want Push then is there still a point in upgrading to HTTP/2 on the front end? Yes in my opinion as detailed in my answer here: HTTP2 with node.js behind nginx proxy. This also shows that there is no real need to have HTTP/2 on the backend from LB to webserver meaning you could leave it as a HTTPS offloading loaf balancer.

It should be noted that there are some use cases where HTTP/2 is slower:

  1. Under heavy packet loss (i.e. a very bad Internet connection). Here the single TCP connection used by HTTP/2 and it’s TCP Head of Line Blocking means the connection suffers more than 6 individual HTTP/1 connections. QUIC which is a even newer protocol then HTTP/2 (so new it’s not even out yet, so not really available except on Google servers) addresses this.
  2. For large packets due to AWS’s specific implementation. Interesting post here on that: https://medium.com/@ptforsberg/on-the-aws-application-load-balancer-http-2-support-fad4bc67b21a. This is only really an issue for truely large downloads most likely for APIs and shouldn’t be an issue for most websites (and if it is then you should optimise your website cause HTTP/2 won’t be able to help much anyway!). Could be easily fixed by upgrading the HTTP/2 window size setting but looks like ELB does not allow you to set this.
Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Barry, I find you answer interesting. Instead of clearly disputing my answer, you interject forward facing technologies such as QUIC which does not exist yet in AWS. You also discuss problems (limitations) with AWS that agrees with my answer, you just used different wording - yet you find my answer wrong. Your counter answer is also flawed. Here is my proposal, let's create a new question that you and I can debate under. The topic will be HTTP/2 on AWS. No technical theory about HTTP/2 tomorrow, just how AWS implements HTTP/2 in the real world today. – John Hanley Jul 30 '18 at 08:06
  • My answer WASN'T given to dispute your answer, but to answer the question, and also provide extra information which I thought might be interesting and relevant (much like the last part of your answer). My comment on your answer WAS to dispute 2 specific parts of your answer which I think were incorrect. Maybe they are "correct" in terms of what is supported on AWS at this time and if you update your answer to reflect this, then I'll happily withdraw my reservations and delete my comments as I do not think it is clear now. If you have flaws in my answer then do let me know so I can correct. – Barry Pollard Jul 30 '18 at 08:18
  • Agreed. I will comment further tomorrow. – John Hanley Jul 30 '18 at 08:20
1

There is no benefit to deploying HTTP2 on an AWS load balancer if your backend is not HTTP2 also. Technically HTTP2 does not require HTTPS, but nobody implements HTTP2 for HTTP. HTTP2 is a protocol optimization (simple viewpoint) that removes round trips in the SSL negotiation, improves pipelining, etc. If the load balancer is communicating with your backend via HTTP, there will not be any improvement. The load balancer will see a small decrease in load due to reduced round trips during HTTPS setup.

I recommend that you configure your backend services to only use HTTPS (redirect clients to HTTPS) and use an SSL certificate. Then configure HTTP2, which is not easy by the way. You can use Let's Encrypt for SSL which works very well. You can also use OpenSSL self-signed certificates (which I don't recommend). You cannot use AWS services to create SSL certificates for your backend services, only for AWS managed services (CloudFront, ALB, etc.).

You can also setup the load balancer with Layer 4 (TCP) listeners. This is what I do when I setup HTTP2 on my backend servers. Now the entire path from client to backend is using HTTP2 without double SSL encryption / decryption layers.

One of the nice features of load balancers is called "SSL offloading". This means that you enable SSL on the load balancer and only enable HTTP on your backend web servers. This goes against HTTP2. Therefore think thru what you really want to accomplish and then design your services to meet those objectives.

Another point to consider. Since you are looking into HTTP2, at the same time remove support in your services for the older TLS versions and unsafe encryption and hashing algorithms. Dropping TLS 1.0 should be mandatory today and I recommend dropping TLS 1.1 also. Unless you really need to support ancient browsers or custom low-end hardware, TLS 1.2 should be the standard today. Your logfiles can tell you if clients are connecting via older protocols.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • 3
    There are plenty of benefits to having the front end only (https://stackoverflow.com/questions/41637076/http2-with-node-js-behind-nginx-proxy). HTTP/2 also does not improve the SSL negotiation other than to not require it for additional streams. QUIC which is currently being worked on is a further improvement which does improve this but not available yet. – Barry Pollard Jul 30 '18 at 06:16
  • @BarryPollard - links for HTTP2 on AWS services that show my answer is wrong. I will happily update my answer. – John Hanley Jul 30 '18 at 06:18
  • Links that prove your answer please. It is incorrect in a couple of places. – Barry Pollard Jul 30 '18 at 06:19
  • @BarryPollard - Please post your own answer to better help the community. – John Hanley Jul 30 '18 at 06:21
  • 1
    @BarryPollard - You just sold one of your books. I will read it. For the sake of argument, please comment on exactly what I have wrong. I know HTTP2 very well also. – John Hanley Jul 30 '18 at 06:26
  • Thanks. Added my answer below. The two points I raised in my original comment are the things I think are wrong. Plenty of good info in your answer but those two are wrong IMHO. Most benefits of HTTP/2 are over high latency client to LB connection not over internal LB -> server connections so I think still worth HTTP/2 on load balancer only. And it doesn’t change round trip for SSL on initial connection (though the fact it uses one connection does save round trips on subsequent connections if that is what you meant?). – Barry Pollard Jul 30 '18 at 06:52
  • 1
    @BarryPollard - Both of us could write answers that are so technical that few will read them. The key is not the theory but what happens in the real world. I read your answer in detail. I still don't see an error in my answer. However, I am enjoying your significant number of posts on HTTP2. I will defer to you as the resident expert. +1 vote from me. – John Hanley Jul 30 '18 at 06:57
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/176999/discussion-between-barry-pollard-and-john-hanley). – Barry Pollard Jul 30 '18 at 08:19
  • Amazon directly addressed this question in their [docs](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html): "Application Load Balancers provide native support for HTTP/2 with HTTPS listeners. You can send up to 128 requests in parallel using one HTTP/2 connection. The load balancer converts these to individual HTTP/1.1 requests and distributes them across the healthy targets in the target group. Because HTTP/2 uses front-end connections more efficiently, you might notice fewer connections between clients and the load balancer." – hemp Jun 16 '20 at 19:42
  • The use of "might" in AWS docs suggests they believe the benefits are negligible. Nonetheless, sophisticated users will want to see that pleasing "h2" in their browser's network tab and not seeing it may raise (unfounded) doubts about the site's administration. – hemp Jun 16 '20 at 19:46