什么是简单的英文WSGI和CGI？
每当我读WSGI或CGI时，我都会畏缩。 我已经尝试过阅读，但没有真正卡住。
简单的英语是什么？
它只是pipe道请求到terminal并redirect输出？
WSGI在Web服务器启动时运行Python解释器，既可以作为Web服务器进程的一部分（embedded模式），也可以作为单独的进程（守护进程模式）运行，并将脚本加载到其中。 每个请求都会在被调用的脚本中产生一个特定的函数，请求环境作为parameter passing给函数。
CGI将脚本作为一个单独的进程运行，并使用环境variablesstdin和stdout与其进行通信。
从完全退一步的angular度来看，Blankman，这里是我的Web服务网关接口的“Intro Page”
第一部分：WEB服务器
Web服务器提供响应。 他们坐下来，耐心地等待，然后突然没有任何警告：
- 一个客户进程发送一个请求。 客户端进程可能是一个Web服务器，一个机器人，一个移动应用程序，无论如何。 这只是“客户”
- networking服务器收到这个请求
- 故意咕 various各种事情发生（见下文）
- networking服务器发回一些东西给客户端
- Web服务器再次坐
Web服务器（至less，更好的）是非常非常擅长的。 他们根据需求扩大和缩小处理，他们可靠地与最客气的客户进行对话，而不必担心这个问题。 他们只是继续服务。
这是我的观点：Web服务器就是这样的：服务器。 他们对内容一无所知，对用户一无所知，事实上除了如何等待并且可靠地回复。
您select的Web服务器应该反映您的交付偏好，而不是您的软件。 您的networking服务器应负责服务，而不是处理或逻辑的东西。
第二部分：（PYTHON）软件
软件不坐。 软件只存在于执行时间。 当涉及到环境的意外变化（文件不在预期的位置，参数被重命名等）时，软件并不是非常适应。 虽然优化应该是您devise的核心原则（当然），但是软件本身并不能优化。 开发人员优化。 软件执行。 软件在上面的“故意嘟</s>”部分中做了所有的事情。 可能是任何事情。
您的select或软件devise应该反映您的应用程序，您select的function，而不是您select的Web服务器。
这是传统的“编译”语言到Web服务器的方法变得痛苦的地方。 您最终将代码放在应用程序中，以应付物理服务器环境，或者至less被迫select一个适当的“包装”库来包含在运行时间，以便给出networking服务器上统一的错觉。
那么什么是WSGI？
那么，最后是什么WSGI？ WSGI是一组规则 ，分为两部分。 他们的写作方式可以融入任何欢迎融合的环境。
第一部分是为Web服务器端编写的，他说：“好的，如果你想要处理一个WSGI应用程序，下面就是这个软件在加载的时候会怎样想，下面是你必须提供给应用程序的东西。是每个应用程序所需的接口（布局），而且，如果出现任何问题，应用程序将如何思考以及如何预期它的行为。
第二部分是为Python应用软件编写的，他说：“好吧，如果你想要处理一个WSGI服务器，服务器在联系你的时候会怎么想，下面是你必须提供给服务器的东西，这里是每个服务器所需要的接口（布局），而且，如果出现任何问题，下面是应该如何处理的问题，以及如何告诉服务器。
所以你有它 – 服务器将是服务器和软件将是软件，这是一种方式，他们可以相处得很好，而不必为了另一方的具体情况而做任何补贴。 这是WSGI。
另一方面，mod_wsgi是Apache的一个插件，它可以与WSGI兼容的软件进行交互，换句话说，mod_wsgi是Apache规则中的规则之一。
至于CGI ….问别人:-)
如果你对这个领域的所有术语都不清楚，让它面对，它是一个令人困惑的首字母缩略词，还有一个很好的背景阅读器，以官方的Python HOWTO的forms讨论CGI与FastCGI与WSGI等在： http : //docs.python.org/howto/webservers.html 。 我希望我会先读它。
CGI和WSGI都定义了程序可以用来处理Web请求的标准接口。 CGI接口的级别低于WSGI，并且涉及服务器设置包含来自HTTP请求的数据的环境variables，程序返回的格式非常像一个纯粹的HTTP服务器响应。
另一方面，WSGI是一个特定于Python的稍高一级的接口，允许程序员编写与服务器无关的应用程序，并且可以将其封装在其他WSGI应用程序（中间件）中。
