cgi考古

ddatsh

dev #cgi

工作至今还未亲自写过 cgi,今天考个古

历史

古早HTML 页面都是静态的,无交互式

1993 年 NCSA 发布 HTTPd 服务器,包含 CGI 的实现。最初为能让 Web 服务器调用外部应用程序,从而实现动态网页的生成

1996 年,CGI 标准正式纳入 IETF 的 RFC 文档中

本质

其工作本质:

环境变量名如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 程序处理完毕后就退出了

优点:

  1. 独立性:不限语言,不同OS和平台上运行

  2. 可扩展性:通过使用外部程序或库,可以实现各种复杂的操作,例如数据库访问、文件上传等

  3. 可移植性:CGI 程序可以在不同的 Web 服务器上运行,可以轻松地实现 Web 应用程序的移植

缺点:

  1. 性能问题:每次请求都需要启动一个独立的进程,会造成额外的负担,影响网站的性能。

  2. 安全问题:CGI 程序通常会接收来自 Web 浏览器的输入数据,如果没有进行足够的安全性检查,可能会导致安全漏洞

  3. 可维护性问题:可用不同语言编写,维护可能会变得非常困难

一个 FastCGI 进程可以处理若干请求(FastCGI 进程驻留),Web Server 还可限制其空闲时间(一段时间内没有请求就自动退出)、或 fpm 控制 FastCGI 进程数量

FastCGI

FastCGI 是一套协议,不再是通过简单的环境变量、标准输入和标准输出来接收和传递数据了。一般用 TCP 或者 命名管道 (Named Pipe) 传输数据

Php-fpm

php fastcgi 进程管理器

各种 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 这样的现代框架