cgi考古
ddatsh
工作至今还未亲自写过 cgi，今天考个古
历史
1993 年 NCSA 发布 HTTPd 服务器，包含 CGI 的实现。最初为能让 Web 服务器调用外部应用程序，从而实现动态网页的生成。当年HTML 页面都是静态的，没有办法动态地生成网页内容
1996 年，CGI 标准正式纳入 IETF 的 RFC 文档中
本质
其工作本质：
- 从环境变量 (environment variables) 和标准输入 (standard input) 中读取数据
- 处理数据
- 向标准输出 (standard output) 输出数据
环境变量名如QUERY_STRING、PATH_INFO 之类，由 Web Server 通过环境变量传递给 CGI 程序，CGI 程序也是从环境变量中读取的
标准输入中存放的往往是用户通过 GET 或者 POST 提交的数据，也由 Web Server 传过来
C 写个 Hello World，也可以作为一个合法的 CGI 程序
#include <stdio.h>
void main() {
printf("Content-type:text/html\n\n");
printf("hello");
}
客户端请求能触发 Web 服务器运行另一个外部程序，客户端输入的数据传给这个外部程序，该程序运行结束后会将生成的 HTML 和其他数据通过 Web 服务器再返回给客户端（即动态请求）
下载
nginx跑php那是fastCGI，古早的cgi得apache httpd
win版都沦落到官方not provide binary releases of software
就第2个靠谱点，其他都已经奇奇怪怪了，
配置
编译 运行
特点、优缺
每个 CGI 进程只处理一个请求/每个请求都需要创建一个 CGI 进程处理/CGI 程序处理完毕后就退出了
优点：
-
独立性：不限语言，不同OS和平台上运行
-
可扩展性：通过使用外部程序或库，可以实现各种复杂的操作，例如数据库访问、文件上传等
-
可移植性：CGI 程序可以在不同的 Web 服务器上运行，可以轻松地实现 Web 应用程序的移植
缺点：
-
性能问题：每次请求都需要启动一个独立的进程，会造成额外的负担，影响网站的性能。
-
安全问题：CGI 程序通常会接收来自 Web 浏览器的输入数据，如果没有进行足够的安全性检查，可能会导致安全漏洞
-
可维护性问题：可用不同语言编写，维护可能会变得非常困难
一个 FastCGI 进程可以处理若干请求（FastCGI 进程驻留)，Web Server 还可限制其空闲时间(一段时间内没有请求就自动退出）、或 fpm 控制 FastCGI 进程数量
FastCGI
FastCGI 是一套协议，不再是通过简单的环境变量、标准输入和标准输出来接收和传递数据了。一般用 TCP 或者 命名管道 (Named Pipe) 传输数据
Php-fpm
php fastcgi 进程管理器
-
动态调整 cgi 数量，有效使用内存
-
平滑重载 php 配置
-
用 Unix-Socket 和服务器通讯，不用再配置 cgi 端口
-
更好的状态输出和 slowlog 日志，502 的时候能给出更多的错误细节
各种 GI
WSGI / uwsgi / uWSGI/ASGI
WSGI （一种 Web 服务器网关接口），是 Web 服务器（如 Nginx，uWSGI 等）与 Web 应用（如 Flask 框架写的程序）通信规范
Web 框架如 Bottle，Flask，Django
WSGI 协议实现服务器如 uWSGI 和 Gunicorn
ASGI 对于 WSGI 原有的模式的支持和 WebSocket 的扩展，即 ASGI 是 WSGI 的扩展
时代
CGI 那个年代 Perl 火是因为 1990 年代几乎只有 Perl 可用。当时Perl 有点像现在的 Python，引发行业变革的事物
后来 200X 年各种 web 框架是一个时代，而今则又是一个新时代
圈子里基本是前端 js/css 一统天下，后端提供 rest api 。一定程度上Perl/Python/Ruby 又被拉回了同一起跑线
PHP、Ruby on Rails 相关技术框架和社区快速发展，Perl Web 开发框架数量少，先进程度也不够
Perl 学习曲线比较陡峭，入门和精通都相对不易
现在 Perl 有 Mojilicious/Dancer 这样的现代框架