问在AWS上使用Kubernetes部署HTTP/2 web服务器

EN

如果后端也不是HTTP2，那么在AWS负载均衡器上部署HTTP2没有好处。从技术上讲，HTTP2不需要HTTPS，但是没有人为HTTP实现HTTP2。HTTP2是一种协议优化(简单观点)，它消除了SSL协商中的往返，改进了流水线等。如果负载均衡器通过HTTP与后端通信，则不会有任何改进。由于HTTPS设置期间往返行程的减少，负载均衡器将看到负载的小幅下降。

我建议您将后端服务配置为只使用HTTPS (将客户端重定向到HTTPS)并使用SSL证书。然后配置HTTP2，这并不容易。您可以使用让我们加密SSL，这是非常好的工作。您还可以使用OpenSSL自签名证书(我不建议使用这种证书)。不能使用AWS服务为后端服务创建SSL证书，只能用于AWS托管服务(CloudFront、ALB等)。

您还可以使用第4层(TCP)侦听器设置负载均衡器。这就是我在后端服务器上设置HTTP2时所做的事情。现在，从客户端到后端的整个路径都是使用HTTP2，而没有双SSL加密/解密层。

负载平衡器的一个好特性称为"SSL卸载“。这意味着在负载均衡器上启用SSL，并且只在后端web服务器上启用HTTP。这与HTTP2背道而驰。因此，通过你真正想要完成的事情来思考，然后设计你的服务来实现这些目标。

另一点需要考虑。由于您正在研究HTTP2，同时在您的服务中删除对旧的TLS版本以及不安全的加密和哈希算法的支持。今天应该强制删除TLS 1.0，我建议也删除TLS 1.1。除非您确实需要支持古老的浏览器或自定义的低端硬件，否则TLS 1.2应该是当今的标准。您的日志文件可以告诉您客户端是否正在通过旧协议进行连接。

新的ELB支持HTTP/2 (https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/)，但不支持Push属性(https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-configuration)：“您不能使用HTTP/2的服务器推送功能”

如果您想使用Push，您可以使用ELB作为四级TCP LoadBalancer，并在您的ELB服务器上启用它。对于HaProxy，仍然可以使用此设置(HTTP/2 behind reverse proxy)来偏移SSL/TLS，但不确定在ELB下是否可能出现类似的情况(可能不会)。这是因为虽然HTTP/2需要来自所有主要浏览器的HTTPS，但它并不是协议本身的要求，因此负载均衡器->服务器可以在HTTP/2上运行，而不需要HTTPS (称为h2c)。

然而，我要说，HTTP/2推送是非常复杂的，要正确阅读这篇由谷歌的杰克·阿奇博尔德撰写的优秀文章：https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/。通常情况下，它在少数情况下是有益的，并且在大多数情况下不会改变，在其他情况下甚至会导致性能下降。说到底，HTTP/2的特性有点令人失望，不过我个人认为还没有对它进行足够的探索，因此可能还会有一些积极的方面。

因此，如果您不想要推送，那么在前端升级到HTTP/2还有什么意义吗？是的，在我看来，正如我在这里回答的那样：HTTP2 with node.js behind nginx proxy。这还表明，从LB到need服务器的后端没有真正的HTTP/2需要，这意味着您可以将它保留为HTTPS卸载面包平衡器。

应该注意的是，有些用例中HTTP/2速度较慢：

1. 在严重的数据包丢失(即一个非常糟糕的互联网连接)。这里，HTTP/2所使用的单个TCP连接及其TCP线阻塞头意味着该连接存在6个以上的单独HTTP/1连接。QUIC是一个更新的协议，然后是HTTP/2 (所以它还没有推出，所以除了在Google服务器上还没有真正可用)解决了这个问题。
2. 由于AWS的特定实现而导致的大数据包。这里有一个有趣的帖子：https://medium.com/@ptforsberg/on-the-aws-application-load-balancer-http-2-support-fad4bc67b21a。这只是一个真正的问题，真正的大规模下载，最有可能的API，不应该是一个问题，对大多数网站(如果是，如果它是，你应该优化你的网站，因为HTTP/2不会有多大帮助！)可以很容易地通过升级HTTP/2窗口大小设置来修复，但是看起来ELB不允许您设置此设置。