什么是简单英语的 WSGI 和 CGI？

Question

每次我读到 WSGI 或 CGI 时，我都会畏缩。 我以前试过阅读它，但没有真正卡住。

用简单的英语来说，它到底是什么？

它只是将请求通过管道传输到终端并重定向输出吗？

Answer 1

从完全后退的角度来看，Blankman，这是我的 Web 服务器网关接口的“介绍页面”：

第一部分：网络服务器

Web 服务器提供响应。 他们围坐在一起，耐心地等待着，然后在没有任何警告的情况下，突然：

• 客户端进程发送请求。 客户端进程可以是 Web 服务器、机器人、移动应用程序等。 它只是“客户”
• Web 服务器收到此请求
• 故意咕哝各种事情发生（见下文）
• Web 服务器向客户端发回一些东西
• 网络服务器再次出现

Web 服务器（至少，更好的服务器）非常擅长这一点。 他们根据需求扩大和缩小处理规模，他们通过非常糟糕的网络可靠地与最不稳定的客户进行对话，我们从来不用担心。 他们只是继续服务。

这就是我的观点：网络服务器就是：服务器。 他们对内容一无所知，对用户一无所知，事实上除了如何长时间等待和可靠回复之外一无所知。

您对 Web 服务器的选择应反映您的交付偏好，而不是您的软件。 您的网络服务器应该负责服务，而不是处理或逻辑的东西。

第二部分：（Python）软件

软件不会闲置。 软件只存在于执行时。 当涉及到环境中的意外变化（文件不在预期位置、参数被重命名等）时，软件并不是非常适应。 尽管优化应该是您设计的核心原则（当然），但软件本身并没有优化。 开发商优化。 软件执行。 软件会完成上面“故意咕哝”部分中的所有内容。 可以是任何东西。

您对软件的选择或设计应该反映您的应用程序、您对功能的选择，而不是您对 Web 服务器的选择。

这就是将语言“编译”到 Web 服务器的传统方法变得痛苦的地方。 您最终将代码放入您的应用程序中以应对物理服务器环境，或者至少被迫选择一个合适的“包装器”库以在运行时包含，以产生跨 Web 服务器统一的错觉。

那么什么是 WSGI？

那么，最后，什么是 WSGI？ WSGI 是一套规则，写成两半。 它们的编写方式使得它们可以集成到任何欢迎集成的环境中。

第一部分，为 Web 服务器端编写，说“好的，如果你想处理一个 WSGI 应用程序，这就是软件在加载时的想法。这是你必须让应用程序可用的东西，这里是您可以期望每个应用程序都具有的界面（布局）。此外，如果出现任何问题，这就是应用程序的思考方式以及您可以期望它的行为方式。”

第二部分，为 Python 应用程序软件编写，说“好的，如果你想与 WSGI 服务器打交道，这是服务器在联系你时的想法。这是你必须向服务器提供的东西，以及这是您可以期望每台服务器都拥有的界面（布局）。此外，如果出现任何问题，这就是您应该如何表现以及您应该告诉服务器的内容。

所以你明白了——服务器将是服务器，软件将是软件，这是一种他们可以相处得很好的方式，而不必为另一个的细节留出任何余地。 这就是 WSGI。

另一方面，mod_wsgi 是 Apache 的一个插件，它允许它与 WSGI 兼容的软件对话，换句话说，mod_wsgi 是上述规则手册第一部分规则的一个实现- 在 Apache 中。

至于CGI....问别人:-)

Answer 2

WSGI 在 Web 服务器启动时运行 Python 解释器，作为 Web 服务器进程的一部分（嵌入式模式）或作为单独的进程（守护程序模式），并将脚本加载到其中。 每个请求都会导致调用脚本中的特定函数，并将请求环境作为参数传递给该函数。

CGI 将脚本作为每个请求的单独进程运行，并使用环境变量、stdin 和 stdout 与其“通信”。

Answer 3

CGI 和 WSGI 都定义了程序可以用来处理 Web 请求的标准接口。 CGI 接口处于比 WSGI 更低的级别，并且涉及服务器设置环境变量，其中包含来自 HTTP 请求的数据，程序返回一些格式非常类似于裸 HTTP 服务器响应的内容。

另一方面，WSGI 是特定于 Python 的、稍微高级的接口，允许程序员编写与服务器无关的应用程序，并且可以包装在其他 WSGI 应用程序（中间件）中。

Answer 4

如果你不清楚这个领域的所有术语，让我们面对现实吧，这是一个令人困惑的缩写词，还有一个很好的背景阅读器，以官方 python HOWTO的形式讨论了 CGI vs. FastCGI vs. WSGI 等等在。 我希望我先阅读它。