这个答案是对其他答案的补充，并解释了为什么Unicorn需要nginx在它前面。
TL; DR 之所以通常将Unicorn与诸如nginx之类的反向代理一起部署，是因为其创建者是故意设计的，因此需要权衡简单性。
首先，有没有什么让你从部署麒麟无反向代理。但是，这不是一个好主意。让我们看看为什么。
Unicorn遵循Unix的哲学，即做一件事并做得很好，那就是为快速，低延迟的客户端提供服务（我们将在后面看到这意味着什么）。Unicorn专为快速，低延迟的客户端而设计的事实也表明，对于慢速，高延迟的客户端，这不是很好，这的确是事实。这是独角兽的薄弱环节之一，它是其中一个反向代理的用武之地：它坐落在麒麟面前，照顾那些缓慢的客户（我们将看到怎样后面）。
幸运的是，这样的反向代理已经存在，称为nginx。
只处理快速客户端的决定极大地简化了Unicorn的设计，并允许更简单和更小的代码库，但以部署部门增加一些复杂性为代价（即，除了Unicorn之外，您还必须部署nginx）。
另一种选择是，以不需要反向代理的方式设计Unicorn。但是，这意味着它必须实现额外的功能才能完成nginx现在要做的所有事情，从而导致更复杂的代码库和更多的工程工作。
取而代之的是，它的创建者决定使用经过实践检验和设计精良的现有软件，并避免在其他软件已经解决的问题上浪费时间和精力。
但是，让我们获取技术知识并回答您的问题：
为什么Unicorn需要与nginx一起部署？
以下是一些关键原因：
独角兽使用阻止I / O的客户端
依靠反向代理意味着Unicorn 不需要使用非阻塞I / O。取而代之的是，它可以使用阻塞I / O，这本来就更容易被程序员采用。
同样在DESIGN文档中指出：
[使用阻塞的I / O]允许在Ruby解释器中遵循更简单的代码路径，并减少系统调用。
但是，这也会产生一些后果：
关键点1：独角兽在缓慢的客户群体中效率不高
（为简单起见，我们假设设置了一名Unicorn工人）
由于使用了阻塞I / O，因此Unicorn工作者一次只能服务一个客户端，因此，速度较慢的客户端（即连接速度较慢的客户端）将有效地使该工作者忙于更长的时间（比快速客户端更忙）。 ）。同时，其他客户端只会等到工作人员再次空闲时（即，请求会堆积在队列中）。
为了解决这个问题，在Unicorn的前面部署了一个反向代理，该代理完全缓冲传入的请求和 应用程序响应，然后将它们分别一次发送 （即通过汤匙输入）到Unicorn和客户端。在这方面，您可以说反向代理可以“屏蔽”独角兽免受慢速网络客户端的攻击。
幸运的是，Nginx可以有效地处理成千上万的并发客户端，因此非常适合担任此角色。
至关重要的是，反向代理应该与Unicorn位于同一局域网内（通常在与通过Unix域套接字与Unicorn进行通信的同一台物理计算机中），以便将网络延迟保持在最低水平。
因此，这样的代理有效地扮演了 Unicorn最初设计的快速客户的角色，因为它代理了对Unicorn的快速请求，并且使工作人员在最短的时间内保持忙碌（相比于一个客户有多少时间）连接速度较慢）。
关键点2：Unicorn不支持HTTP / 1.1保持活动状态
由于Unicorn使用阻塞I / O，这也意味着它不支持HTTP / 1.1保持活动功能，因为慢速客户端的持久连接将迅速占用所有可用的Unicorn工作者。
因此，要利用HTTP保持活动状态，请猜测以下内容：使用了反向代理。
另一方面，nginx仅使用几个线程就可以处理数千个并发连接。因此，它没有像Unicorn这样的服务器的并发限制（这基本上限制了工作进程的数量），这意味着它可以很好地处理持久连接。在这里可以找到更多有关其实际工作原理的信息。
这就是nginx接受来自客户端的保持活动连接并通过通常通过Unix套接字通过普通连接将其代理到Unicorn的原因。
要点3：Unicorn不太擅长提供静态文件
再说一次，提供静态文件是Unicorn 可以做的事情，但并不是为了有效地做。
另一方面，反向代理（例如nginx）在此方面要好得多（即sendfile(2)＆缓存）。
更多
哲学文档中还概述了其他要点（请参阅“通过反向代理提高性能”）。
另请参见nginx的一些基本功能。
我们看到，通过利用现有软件（即nginx）并遵循Unix的“做一件事情，做好事”的哲学，Unicorn能够遵循更简单的设计和实现，同时保持高效地服务于Rack应用程序（例如您的Rails应用）。
有关更多信息，请参阅Unicorn的理念和设计文档，其中更详细地解释了Unicorn设计背后的选择以及为什么Nginx被认为是Unicorn的良好反向代理。
