杂记 | 我看 CGI

写点旧东西，最近一直再看 django 源代码，发现对运行机制仍是蛮感兴趣的（太懒了，这块一直没有深刻研究过），由于扯到了 wsgi 规范，就想到了原始的 cgi 接口规范, 这里就先写写我对 cgi 接口规范 的认知，同时也为了下次组内分享预留个开头。

1 远古时代

1991年8月6日，这是个伟大的日子，web 页面首次在因特网上登场，回去早期，web 服务器主要是用来共享静态数据，只是简单的响应浏览器发来的 http 请求，并将存储在服务器上的静态文件返给浏览器。因此早期的 web 服务器的结构以下：

由于早期的用户只有高大上的科学家，这样的架构无可厚非，毕竟只是为了共享本身的一些资料，方便交流。

2 CGI 时代

随着时间的推移，互联网逐渐平民化，技术在进化，网站愈来愈复杂，远古时代的架构已经不能知足用户的需求。针对用户强烈的动态交互需求，另一方面，服务器本身并不能运行相似 python 脚本文件，既然服务器无法作，只能联合第三方一块儿搞，此时与第三方通讯仍是须要有个约定的，服务器给第三方参数，第三方返回给服务器结果，最后服务器把结果返回给客户端，此后名扬江湖的 CGI(Common Gateway Interface) 诞生了。

CGI 定义了 Web服务器 与外部应用程序之间的通讯接口标准，所以 Web服务器 能够经过 CGI 执行外部程序，让外部程序根据Web请求内容生成动态的内容。Perl 由于跨操做系统和易于修改的特性成为 CGI 的主要编写语言。固然，CGI 能够用任何支持标准输入输出和环境变量的语言编写，好比 Shell 脚本, C/C++ 语言，只要符合接口标准便可。好比你用C 语言编写 CGI 程序，你把但愿返回的 HTML 内容经过 printf 输出就能够发送给Web服务器，进而返回给用户。

CGI 脚本与服务器通讯

服务器与 CGI 脚本通讯是经过标准的输入输出和环境变量完成的。

CGI 脚本工做流程

• 浏览器经过HTML表单或超连接请求指向一个 CGI 应用程序的 URL。

• 服务器收发到请求。

• 服务器执行所指定的 CGI 应用程序。

• CGI 应用程序执行所须要的操做，一般是基于浏览者输入的内容。

• CGI 应用程序把结果格式化为网络服务器和浏览器可以理解的文档（一般是 HTML网页）。

• web 服务器 把结果返回到浏览器中。

CGI 模式性能
CGI 的跨平台性能极佳，几乎能够在任何操做系统上实现。CGI 方式在遇到链接请求（用户请求）先要建立 CGI 的子进程，激活一个 CGI 进程，而后处理请求，处理完后结束这个子进程。这就是 fork-and-execute 模式。因此用 CGI 方式的服务器有多少链接请求就会有多少 CGI 子进程，子进程反复加载是 CGI 性能低下的主要缘由。当用户请求数量很是多时，会大量挤占系统的资源如内存，CPU 时间等，形成效能低下。

3 例子

web 服务器： lighttpd，脚本语言: python， 平台: mac

脚本代码

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import os

print "Content-Type: text/plain;charset=utf-8\n"

print os.environ.get('SERVER_PROTOCOL')
print os.environ.get('QUERY_STRING')
print "Hello World!"

浏览器端

输入 url 以下：

http://127.0.0.1:8080/cgi-bin/test.py?name=kycool&id=0989238423

返回结果：

HTTP/1.1
name=kycool&id=0989238423
Hello World!

debug 工具中打开

4 小结

经过例子就会发现，运行模式以下：

例子较为简单，复杂的业务若是写完，估计本身能够造个框架轮子了，由于 CGI 性能低下的缘由，python 相关的 wsgi 出现了......

参考文章
https://www.w3.org/CGI/
https://en.wikipedia.org/wiki/Common_Gateway_Interface
http://www.tianmaying.com/blog/8ab3eda84daf4e54014daf68ff09000b