Apache2 提供的 HTTPS 请求比通过反向代理慢答案

【问题标题】：HTTPS request served by Apache2 slower than via Reverse ProxyApache2 提供的 HTTPS 请求比通过反向代理慢
【发布时间】：2019-07-21 11:21:56
【问题描述】：

我的情况：
网站使用 ubuntu 服务器上的默认 apache2 安装托管。使用 HTTPS 和自签名证书（用于开发）在端口 443 上提供服务。

现在我有一个用 golang 编写的简单服务，它侦听端口 8080 并充当反向代理来接收 https 请求，将它们转发到本地 apache 并将响应返回给客户端。此网络服务不缓存任何文件，只转发请求。
代码：https://play.golang.org/p/tnfKVWyLuZQ

我的“问题”：
直接调用 apache，即https://foo.com/bar/ 比通过我的反向代理调用网站慢得多（200-400 毫秒），即https://foo.com:8080/bar/

为什么直接调用apache2比较慢？我预计使用反向代理会有开销，而不是加速。 -> 示例页面比较：https://i.imgur.com/TqznM2v.png

更新：显示当前设置的草图： Current Setup

关于编码：Encoding在两种情况下都是一致的：Encoding header和Content-Length在两种情况下（情况1 vs 2）相同，客户端也收到文件大小。不知道为什么在 HAR 查看器中它只在第二种情况下显示未压缩的大小。如果在 Chrome 中检查，我可以看到两种情况下的压缩大小。

更新#2：我得出的结论是，golang 实现在短时间内处理来自同一客户端的多个请求比默认配置下的 apache2 更有效。 Sicne 我只用少数客户端测试我不能说它的扩展性如何 - 我想 web 服务在负载下会落后。
我认为这已关闭，谢谢大家的帮助。

【问题讨论】：

没有足够的信息可以确定，但我敢打赌你的反向代理正在维护与 apache2 服务器的持久连接，从而防止 tcp 和 ssl 每次请求的握手开销。
好主意。但是反向代理不会有同样的问题（因为它处理与网络服务器相同的请求）？我很难相信 golang 的实现比 apache 更高效。有什么建议可以在哪里/如何收集更多信息？谢谢！
我的评论是假设 go 代理在 localhost 上运行，并且 apache2 是一些远程服务器。如果是这样，那么启动代理后的第一个请求可能是相同的速度，但后续请求将利用代理的持久连接，并避免一些开销。从浏览器到代理的连接开销可以忽略不计，如果它在本地主机上运行，就像我假设的那样。
我刚刚注意到 apache 请求的请求大小要小得多。默认情况下，Apache 可能会对您的资源进行 gzip 压缩，这也可能会增加开销。查看proxy和apache之间的http headers，看看accept-encoding header的内容是什么。
感谢这个想法，我研究了编码，并且在两种情况下都是一致的（请参阅更新的答案）。充当反向代理的 Web 服务位于服务器本身。我添加了一张图片来详细说明。

标签： apache go https webserver reverse-proxy

【解决方案1】：

据我所知。有两个可能的原因。

apache 反向代理处理了一些包含静态文件的缓存，例如图像、css 或 javascript。
当您浏览 https 网址时。将发生一个名为“ssl certificate uninstall”的过程，它可能会导致巨大的服务器负载。所以如果 web 应用和 ssl 证书部署在同一台服务器上，负载可能会导致高延迟。一般情况下，我们使用一个名为 load-balancer 的特殊设备来卸载 ssl 证书，就像反向代理一样。

【讨论】：

感谢您的回答 - 代理本身不进行任何缓存，仅转发（参见代码片段）。虽然 ssl 可能是一个瓶颈，但它应该在两种情况下都保持一致，对吧？因为我在这两种情况下都使用 https 连接到 apache 和 web 服务。