FastCGI解析HTTP请求过程

　　Apache服务器运行在linux系统上，FastCGI以Apache为平台来运行，每一个客户端发起的HTTP请求都会由Apache交给FastCGI来处理。HTTP协议属于应用层协议，建立在TCP(网络层)协议上，它并不关心其上一层协议做了什么，只需做自己被定义的，本文档只针对HTTP协议层寻找问题答案，因此，在后续的讲述中，客户端是如何找到服务器，服务器又是如何将数据返回给客户端，数据是通过哪些被定义的函数来处理传输的，传输实现的细节是什么等等，这些都已经被TCP协议所定义，不进行叙述。我们只需知道域名+端口就可以唯一地确定网络中某台服务器的某个进程即可

　　谈谈http如何实现： HTTP在请求之前先通过TCP的三次握手建立与服务器的连接，连接成功后发送请求，请求方式有GET、POST、PUT、DELET等，常用的却只有GET、POST方式，若服务器接收请求后受理业务并成功返回，客户端则会显示请求内容，同时服务器断开连接。 网上常会出现一些对GET、POST不负责任的言论，关于GET与POST ，客户端中URL提交方式有三种：地址栏直接输入、点击链接、form表单对URL重写提交，无论哪种其本质都将URL传输重写为以下格式(已做验证，后续会实验结果共享)：

<request-line>　　　　#请求行，标识请求类型(GET，POST，PUT，DELET)、要访问的资源、使用的HTTP版本等

<headers>　　　　　　#消息报头，附加信息(别急，稍后会实例说明它是什么)， 以回车换行符/r/n标识结束，/r/n既<CRLF>

[<request-body>]　　 #请求正文，通常是POST提交方式的表单FORM包数据，其编码方式由<headers>中的Content-type指定，长度由Content-Length指定，同样以<CRLF>为标志结束(GET请求没有此信息，数据会直接暴露在URL中)。

　　在HTTP协议中，无论GET还是POST都能进行表单提交，区别是参数传输放置位置不同，GET不能将参数放置在request-body中，POST则两者都可以。有的地方说GET参数暴漏在外不安全，然而POST表单提交方式不是一样也能通过工具看到吗，至于传输数据长度是否受限制，没做试验验证(网上有种说法是传输长度不限制，只会由浏览器决定)。 以上这些可以方便我们知道数据是从哪来，到哪去，是通过什么传输的，从而能针对不同的BUG进行调试，了解整个服务器框架各个部分的衔接方式，优化性能。

　　CGI（common Gateway interface ）通用网关接口，一种动态网页实现技术，它与Perl一样古老，因编程困难，效率低下，修改复杂一系列缺点，逐渐被更为流行的ASP、JSP、PHP等代替(不流行的技术也许更安全，这正是CGI的优点)。CGI并非常驻内存，对于每次请求服务器都会FORK()载入CGI程序，初始化相关的数据结构，因此高并发请求时会占用大量磁盘I/O操作，所以被FastCGI所替代，FastCGI是CGI的升级版，实现了对CGI进程的内存管理，FastCGI启动后先自我初始化，开启多个CGI进程(多进程导致占用大量内存)，轮番让空闲的CGI进程接收及响应请求，从而达到减少因反复加载所进行的I/O操作、多进程、持续数据库连接、分布式运算等目的。

　　CGI中的Request方法用于处理client发出的GET、POST、PUT、DELET四 种请求，常用的只有GET、POST两种，且FastCGI实现的前 提是已经通过listen侦听了一个端口，然后再去调用accept函数。

你可能会有一下疑问：

1 FastCGI请求的端口是如何获取的，

2 怎么才能知道FastCGI的进程个数，如何确定哪些进程是空闲的以分配给它们客户端传来的请求，

3 FastCGI既然是多进程，运行在内存中，如何实现一次编码，然后能不断的接收请求的，为什么CGI不行，

4 FastCGI的效率怎么样。

解释如下：

1 其实服务器会一直监听某个端口号(HTTP不说明情况下默认为80)，因为FastCGI是独立的，它也会侦听某个端口(一般是相同的端口，在配置中已经指定)，所以每个FastCGI都可以进行accept连接，只要它空闲web服务器就允许其处理一个请求，否则可能是因为并发量太大，暂时处理不了。

2 如果FastCGI是由服务器直接启动，作为父进程当然知道子进程个数，并进行控制，如果是通过其它程序间接启动，父进程就不再是服务器，此时就无法知道进程个数，但是其相关父进程也会有一套相应的实现机制，不影响整个工作流程。

3 FastCGI有自己的内存管理机制，启动后一直停留在内存中，但处于挂起状态，只在有HTTP请求时，FastCGI才会响应执行，完成后断开连接，继续挂起，等待下一次的请求。

4 作为解释行语言，FastCGI虽然很方便，却对编程人员有着较高的要求，不同人员编写的程序速度相差很大，且修改起来困难，在效率上也比编译型语言慢上很多。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（原创博文，转载请标明出处。）