cgi考古
ddatsh
工作至今还未亲自写过 cgi,今天考个古
历史
古早HTML 页面都是静态的,无交互式
1993 年 NCSA 发布 HTTPd 服务器,包含 CGI 的实现。最初为能让 Web 服务器调用外部应用程序,从而实现动态网页的生成
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 这样的现代框架