CGI 是通用网关接口。顾名思义，它是所有内容的 “通用” 网关接口。从名称来看，它是如此琐碎而幼稚。我感到自己理解了，每次遇到这个词时都会感到。但坦率地说，我没有。我还是很困惑。
我是一位具有 Web 开发经验的 PHP 程序员。
用户（客户端）对页面的请求 ---> webserver（-> 嵌入式 PHP 解释器）----> 服务器端（PHP）脚本 ---> MySQL 服务器。
现在说我的 PHP 脚本可以从 MySQL 服务器，MATLAB 服务器和其他服务器获取结果。
那么，现在 PHP Script 是 CGI 吗？因为它的接口用于 Web 服务器与所有其他服务器之间？我不知道。有时他们称 CGI 为技术，而有时又称 CGI 为程序或其他服务器。
CGI 到底是什么？
/cgi-bin/*.cgi什么大不了的？这是怎么回事？我不知道服务器上的cgi-bin目录是做什么的。我不知道他们为什么有 * .cgi 扩展名。
为什么 Perl 总是妨碍您。 CGI 和 Perl（语言）。我也不知道这两个怎么了。几乎我一直都在不断听到 “CGI＆Perl” 的组合。这本书是使用 Perl 进行 CGI 编程的另一个很好的例子。为什么不使用 PHP / JSP / ASP 进行 CGI 编程？我从未见过这样的事情。
C 语言中的 CGI 编程 ，让我很困惑。 “ 在 C 中 ”？认真吗？我不知道该说些什么。我很困惑。 “ 在 C 中 ”？这改变了一切。程序需要编译和执行。这完全改变了我对 Web 编程的看法。我什么时候编译？程序如何执行（因为它将是机器代码，因此必须作为独立的进程执行）。它如何与 Web 服务器通信？ IPC？并使用套接字编程与所有服务器（在我的示例 MATLAB＆MySQL 中）接口？我迷路了！！
人们说 CGI 已被弃用，不再使用。是这样吗？最新更新是什么？
有一次，我遇到了不得不向 Web 服务器（Apache HTTPD）授予 HTTP PUT 请求访问权限的情况。它的后背很长。因此，据我所记得，这就是我所做的：
编辑了 Apache HTTPD 的配置文件，以告知 Web 服务器将所有 HTTP PUT 请求传递给某个
put.php（我必须编写此 PHP 脚本）实现 put.php 来处理请求（将文件保存到上述位置）
人们说我写了一个 CGI 脚本。说真的，我不知道他们在说什么。
我希望你理解我的困惑。 （因为我自己不知道我在哪里困惑）。我要求你们保持答案尽可能简单。我真的不明白任何花哨的技术术语。至少不是这种情况。
编辑：
我发现了这个很棒的教程“CGI 编程很简单！”。 -CGI 教程 ，以最简单的方式解释了这些概念。阅读本文之后，您可能需要阅读《 C 语言中的 CGI 编程入门》，以通过实际的代码示例补充您的理解。我还将这些链接添加到了本教程的 Wikipedia 文章： http : //en.wikipedia.org/wiki/Common_Gateway_Interface
CGI 是一个告诉 Web 服务器如何与应用程序之间进行数据传递的接口。更具体地说，它描述了如何在环境变量（例如请求类型，远程 IP 地址）中传递请求信息，如何通过标准输入传递请求主体以及如何通过标准输出传递响应。您可以参考CGI 规范以获取详细信息。
要使用您的图片：
user (client) request for page ---> webserver ---[CGI]----> Server side Program ---> MySQL Server.
大多数（如果不是全部）网络服务器可以配置为以 “CGI” 的身份执行程序。这意味着网络服务器在收到请求后会将数据转发到特定程序，通过标准输入和标准输出设置一些环境变量并编组参数，以便程序可以知道要查找的位置和内容。
主要的好处是，只要 Web 服务器和程序都知道 CGI 的工作原理，就可以从 Web 运行任何可执行代码。这就是为什么您可以使用启用了 CGI 的常规 Web 服务器以 C 或 Bash 编写 Web 程序的原因。这样，并且大多数编程环境都可以轻松使用标准输入，标准输出和环境变量。
在您的情况下，您极有可能使用了另一种特定于 PHP 的脚本和 Web 服务器之间的通信方式，正如您在问题中所提到的，这是一种称为 mod_php 的嵌入式解释器。
因此，回答您的问题：
CGI 到底是什么？
往上看。
/cgi-bin/*.cgi 有什么大不了的？这是怎么回事？我不知道服务器上的 cgi-bin 目录是做什么的。我不知道他们为什么有 * .cgi 扩展名。
这是 CGI 程序的传统场所，许多 Web 服务器都预先配置了此目录，以将其中的所有二进制文件作为 CGI 程序执行。 .cgi 扩展名表示期望通过 CGI 工作的可执行文件。
为什么 Perl 总是妨碍您。 CGI 和 Perl（语言）。我也不知道这两个怎么了。几乎我一直都在不断听到 “CGI＆Perl” 的组合。本书是使用 Perl 进行 CGI 编程的另一个很好的例子，为什么不介绍 “使用 PHP / JSP / ASP 进行 CGI 编程”。我从未见过这样的事情。
因为 Perl 很古老（比 CGI 早就诞生的 PHP，JSP 和 ASP 都古老，所以 Perl 在 CGI 刚出现时就已经存在），并因其是一种非常好的语言通过 CGI 服务动态网页而闻名。如今，还有其他替代方法可以在 Web 服务器上运行 Perl，主要是mod_perl 。
C 语言中的 CGI 编程使我非常困惑。在 C ?? 认真吗？我不知道该说些什么。我只是感到困惑。“在 C 中” ?? 这会改变一切。程序需要编译和执行。这完全改变了我对 Web 编程的看法。我何时编译？程序如何执行（因为它将是一个机器代码，因此它必须作为独立的进程执行。）它如何与 Web 服务器通信，IPC 和如何使用套接字编程与所有服务器（在我的示例 MATLAB 和 MySQL 中）进行接口连接，我迷路了！
编译可执行文件一次，Web 服务器将执行该程序，并将请求中的数据传递给该程序，然后输出接收到的响应。 CGI 指定每个请求将启动一个程序实例。这就是为什么 CGI 如今效率低下且过时的原因。
他们说 CGI 已过时。它不再使用。是这样吗？最新更新是什么？
当性能不是最重要的并且需要一种简单的执行代码的方法时，仍会使用 CGI。由于前面提到的原因，它效率低下，并且在网络环境中有更现代的方法可以执行任何程序。当前最著名的是FastCGI 。
CGI 到底是什么？
Web 服务器从程序（而不是文件）获取其数据的一种手段。
/cgi-bin/*.cgi 有什么大不了的？
没什么大不了的。这只是一个约定。
我不知道服务器上的 cgi-bin 目录是做什么的。我不知道他们为什么有 * .cgi 扩展名。
服务器必须知道如何处理文件（即，将其视为要执行的程序，而不是简单地处理文件）。具有. html 扩展名告诉它使用 text / html 内容类型。具有. cgi 扩展名告诉它以程序运行。
将可执行文件保存在单独的目录中可以提供一些额外的保护，以防止执行错误的文件和 / 或将 CGI 程序作为原始数据提供服务，以防服务器配置错误。
为什么 Perl 总是妨碍您。
没有。 Perl 和 CGI 一样大，而且很受欢迎。
我已经好多年没有使用 Perl CGI 了。我使用 mod_perl 已有很长时间了，这些天我倾向于使用 FastCGI 使用 PSGI / Plack。
本书是使用 Perl 进行 CGI 编程的另一个很好的例子，为什么不介绍 “使用 PHP / JSP / ASP 进行 CGI 编程”。
CGI 不是很有效。与 Web 服务器进行程序通信的更好方法是在大约同一时间出现的。 JSP 和 ASP 是与程序对话的不同方法。
C 语言中的 CGI 编程使我非常困惑。在 C ?? 认真吗？
这是一种编程语言，为什么不呢？
我什么时候编译？
程序如何执行（因为它将是机器代码，因此必须作为独立的进程执行）。
它不必作为独立的进程执行（您可以用 C 编写 Apache 模块），但是 CGI 的整个概念是它启动了一个外部进程。
它如何与 Web 服务器通信？ IPC？
STDIN / STDOUT 和环境变量 - 在 CGI 规范中定义。
并使用套接字编程与所有服务器（在我的示例 MATLAB＆MySQL 中）接口？
使用您喜欢和支持的任何方法。
他们说 CGI 已贬值。它不再使用。是这样吗？
CGI 效率低下，缓慢且简单。它很少使用，使用时是因为它很简单。如果性能没什么大不了的话，那么简单就值得很多。
最新更新是什么？
1.1
CGI 是 Web 服务器（HTTP 服务器）和处理特定请求的某种类型的可执行程序之间的接口规范。
它描述了应如何将该请求的某些属性传达给该程序的环境，以及该程序应如何将该响应传达回服务器，以及服务器应如何 “完成” 响应以形成对原始 HTTP 请求的有效回复。
有一段时间，CGI 是 IETF Internet 草案，因此有一个有效期。它已过期且没有更新，因此没有 CGI“标准”。现在它是一个参考性的 RFC，但是正因为如此，它记录了通用做法，而不是标准本身。 rfc3875.txt ， rfc3875.html
可以在目标计算机上以可运行的任何语言编写实现 CGI 接口的程序。他们必须能够访问环境变量 ，通常是标准输入，并且它们必须在标准输出上生成其输出 。
诸如 C 之类的编译语言与诸如 perl 之类的脚本语言一样，通常被使用，通常使用库来简化对 CGI 环境的访问。
CGI 的主要缺点之一是为每个请求生成了一个新程序，因此在请求之间保持状态可能是一个主要的性能问题。状态可以用 cookie 处理或用 URL 编码，但是如果状态变大，则必须将其存储在其他位置，并从编码的 url 信息或 cookie 中键入密钥。然后，每个 CGI 调用都必须从某个地方的商店重新加载存储的状态。
因此，对于请求和会话的界面非常简单，Web 服务器和应用程序之间更好的集成环境变得更加流行。诸如使用 apache 的现代 php 实现之类的环境将目标语言与 Web 服务器更好地集成在一起，并提供对有效处理 HTTP 请求所需的请求和会话对象的访问。它们提供了一种更轻松，更丰富的方式来编写 “程序” 以处理 HTTP 请求。
是否编写 CGI 脚本取决于解释。当然可以做到这一点，但是将 php 作为模块运行的情况要普遍得多，其中脚本和服务器之间的接口严格来说不是 CGI 接口。