能够代理请求的 HTTP 服务器答案

【问题标题】：HTTP Server capable of proxying requests能够代理请求的 HTTP 服务器
【发布时间】：2013-03-31 02:08:51
【问题描述】：

出于性能原因，我不得不重写部分网络基础架构。

为此，我将关键部分编写为 C++ 中的 Web 应用程序。此 Web 应用程序侦听给定端口，一次只接受一个 TCP 连接，并处理它在当前连接上接收到的所有 HTTP 请求。

你可以这样启动它来监听 8080 端口：

./webapp 8080

虽然它可以完美运行并且比以前快得多，但它的局限性在于应用程序的一次连接一次的性质。您不能仅通过一个应用程序实例通过多个连接同时提供 HTML 页面、Javascript 和图像。

为了克服这个限制，我想运行一个前端反向代理 HTTP 服务器，它侦听端口 80，并将传入的 HTTP 请求均匀地重定向到我在后台运行的 Web 应用程序的多个实例上。这些实例可以像这样在启动时创建：

./webapp 10000
./webapp 10001
./webapp 10002
./webapp 10003
./webapp 10004
./webapp 10005
./webapp 10006
./webapp 10007
./webapp 10008
./webapp 10009

前端应配置为在启动时与每个网络应用建立永久 HTTP 连接，然后将传入的 HTTP 请求转发到正在运行的网络应用之一，均匀分布。

反向代理也应该支持从客户端到自身的 SSL。支持 SPDY 将是一个加分项，但不是必须的。

我的问题是：在我的场景中，哪些 HTTP 反向代理可以用作前端？如果你知道的不止一个，每个的优缺点是什么？

【问题讨论】：

标签： apache http https proxy

【解决方案1】：

您拥有一个仅连接的服务器的动机是什么？对于网络服务器来说，这听起来像是一个糟糕的选择。当您的网站出现时，每个客户端浏览器通常会并行发送数十个请求。

如果你通过 TCP 连接产生一个进程，你最终会表现不佳。确实，您在这里寻找的是多线程服务器而不是多进程基础架构（拥有不同进程的意义何在？）

不过，你可以走几条路：

如果您真的想拥有单独的进程，则每次收到请求时都分叉您的webapp。这在性能方面不会很好，但它是我能想到的最接近你最初的问题。
您使用单线程 webapp，但您维护了一个您侦听的套接字列表，并将它们与他们的“伙伴套接字”配对，这是他们将流量转发到的那些（请注意，它有效双向）。尽管如此，这仍不是最佳性能，因为您可能会受到内核调用的限制。
您为每个请求生成一个新线程，然后仅在该线程中处理该请求，就像您在单线程架构中所做的那样。

如果我是你，我会直接转向解决方案 3，因为它是最好的选择。这并没有太大的麻烦，因为它与您的单线程方法（只是一对套接字）很接近，并且它不会对整个地方的分叉进程造成性能影响。

我认为您不会找到适合您需求的网络服务器，因为它不是处理此类情况的标准方法，我怀疑是否有人花时间开发它:)

编辑：

好的，通过您的编辑，我了解您的问题。

不过，对我来说，要解决的问题仍然是一样的：您需要一个将流量分派到您的进程的进程。我认为您不会找到开箱即用的这种调度程序，因此您需要使用我提到的三种技术之一来实现它。

如果您考虑一下，您实际上是在尝试实现代理的一侧，而另一侧是转发到您的webapp。所以你应该使用代理技术恕我直言。

【讨论】：

感谢您的努力，但老实说，我什至认为您没有阅读我的问题。拥有单个连接服务器的动机是我不想重新发明轮子。我只想重写性能关键部分，并将连接池等留给更成熟的现有 Web 服务器。我不想为每个 TCP 连接生成一个新进程。这就是为什么我说我想在启动时生成我的进程，并且应该将前端配置为在启动时建立到每个 Web 应用程序的永久 HTTP 连接。
本质上，我正在寻找一个好的en.wikipedia.org/wiki/Reverse_proxy（见右图和示例）。
我编辑了问题以使其更清晰。我希望它有所帮助。

【解决方案2】：

听起来您不一定需要反向代理，而是需要负载平衡器。我设置了HAProxy，以便每个 webapp 进程都算作一个后端，然后进行循环平衡，以便每个新连接都转到列表中的下一个进程。

Nginx 也可以做这些事情，但我不确定它是否带有开箱即用的负载平衡，或者它是否是一个附加模块。 Nginx 的好处是可以缓存 CSS 和图片等静态资源。

【讨论】：

【解决方案3】：

Nginx 是个不错的选择

优点：

支持 SSL 终止
开箱即用支持load balancing
Upstream keepalive 连接
有 SPDY 支持（虽然没有服务器推送）。最新版本添加了 http2 支持并删除了 spdy。

缺点：

您必须在您的 nginx 配置中硬编码上游服务器，如下所示。如果动态更新它们，则没有简单的方法可以通过环境变量读取上游服务器设置。

http {
    upstream myapp1 {
        server localhost:10000;
        server localhost:10001;
        server localhost:10002;
    }
    server {
        listen 443 ssl spdy;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

【讨论】：