从SAPI接口开始

SAPI:Server Application Programming Interface 服务器端应用编程端口。研究过PHP架构的同学应该知道这个东东的重要性，它提供了一个接口，使得PHP可以和其他应用进行交互数据。 本文不会详细介绍每个PHP的SAPI，只是针对最简单的CGI SAPI，来说明SAPI的机制。

我们先来看看PHP的架构图：

SAPI指的是PHP具体应用的编程接口， 就像PC一样，无论安装哪些操作系统，只要满足了PC的接口规范都可以在PC上正常运行， PHP脚本要执行有很多种方式，通过Web服务器，或者直接在命令行下，也可以嵌入在其他程序中。

通常，我们使用Apache或者Nginx这类Web服务器来测试PHP脚本，或者在命令行下通过PHP解释器程序来执行。 脚本执行完后，Web服务器应答，浏览器显示应答信息，或者在命令行标准输出上显示内容。

我们很少关心PHP解释器在哪里。虽然通过Web服务器和命令行程序执行脚本看起来很不一样， 实际上它们的工作流程是一样的。命令行参数传递给PHP解释器要执行的脚本， 相当于通过url请求一个PHP页面。脚本执行完成后返回响应结果，只不过命令行的响应结果是显示在终端上。

脚本执行的开始都是以SAPI接口实现开始的。只是不同的SAPI接口实现会完成他们特定的工作， 例如Apache的mod_php SAPI实现需要初始化从Apache获取的一些信息，在输出内容是将内容返回给Apache， 其他的SAPI实现也类似。

SAPI提供了一个和外部通信的接口， 对于PHP5.2，默认提供了很多种SAPI， 常见的给apache的mod_php5，CGI，给IIS的ISAPI，还有Shell的CLI，本文就从CGI SAPI入手 ，介绍SAPI的机制。 虽然CGI简单，但是不用担心，它包含了绝大部分内容，足以让你深刻理解SAPI的工作原理。

要定义个SAPI，首先要定义个sapi_module_struct, 查看 PHP-SRC/sapi/cgi/cgi_main.c：

这个结构，包含了一些常量，比如name, 这个会在我们调用php_info()的时候被使用。一些初始化，收尾函数，以及一些函数指针，用来告诉Zend，如何获取，和输出数据。

1. php_cgi_startup， 当一个应用要调用PHP的时候，这个函数会被调用，对于CGI来说，它只是简单的调用了PHP的初始化函数：

2. php_module_shutdown_wrapper ， 一个对PHP关闭函数的简单包装。只是简单的调用php_module_shutdown;

3. PHP会在每个request的时候，处理一些初始化，资源分配的事务。这部分就是activate字段要定义的，从上面的结构我们可以看出，对于CGI 来说，它并没有提供初始化处理句柄。对于mod_php来说，那就不同了，他要在apache的pool中注册资源析构函数， 申请空间， 初始化环境变量，等等。

4. sapi_cgi_deactivate, 这个是对应与activate的函数，顾名思义，它会提供一个handler, 用来处理收尾工作，对于CGI来说，他只是简单的刷新缓冲区，用以保证用户在Zend关闭前得到所有的输出数据：

5. sapi_cgibin_ub_write, 这个hanlder告诉了Zend，如何输出数据，对于mod_php来说，这个函数提供了一个向response数据写的接口，而对于CGI来说，只是简单的写到stdout：

把真正的写的逻辑剥离出来，就是为了简单实现兼容fastcgi的写方式。

6. sapi_cgibin_flush, 这个是提供给zend的刷新缓存的函数句柄，对于CGI来说，只是简单的调用系统提供的fflush;

7.NULL， 这部分用来让Zend可以验证一个要执行脚本文件的state，从而判断文件是否据有执行权限等等，CGI没有提供。

8. sapi_cgibin_getenv, 为Zend提供了一个根据name来查找环境变量的接口，对于mod_php5来说，当我们在脚本中调用getenv的时候，就会间接的调用这个句柄。而 对于CGI来说，因为他的运行机制和CLI很类似，直接调用父级是Shell， 所以，只是简单的调用了系统提供的genenv:

9. php_error, 错误处理函数, 到这里，说几句题外话，上次看到php maillist 提到的使得PHP的错误处理机制完全OO化， 也就是，改写这个函数句柄，使得每当有错误发生的时候，都throw一个异常。而CGI只是简单的调用了PHP提供的错误处理函数。

10. 这个函数会在我们调用PHP的header()函数的时候被调用，对于CGI来说，不提供。

11. sapi_cgi_send_headers, 这个函数会在要真正发送header的时候被调用，一般来说，就是当有任何的输出要发送之前：

12. NULL, 这个用来单独发送每一个header, CGI没有提供

13. sapi_cgi_read_post, 这个句柄指明了如何获取POST的数据，如果做过CGI编程的话，我们就知道CGI是从stdin中读取POST DATA的：

14. sapi_cgi_read_cookies, 这个和上面的函数一样，只不过是去获取cookie值：

15. sapi_cgi_register_variables, 这个函数给了一个接口，用以给$_SERVER变量中添加变量，对于CGI来说，注册了一个PHP_SELF,这样我们就可以在脚本中访 问$_SERVER['PHP_SELF']来获取本次的request_uri：

16. sapi_cgi_log_message ，用来输出错误信息，对于CGI来说，只是简单的输出到stderr：

经过分析，我们已经了解了一个SAPI是如何实现的了， 分析过CGI以后，我们也就可以想象mod_php, embed等SAPI的实现机制。

一次请求的开始与结束

PHP开始执行以后会经过两个主要的阶段：

• 处理请求之前的开始阶段
• 请求之后的结束阶段

开始阶段有两个过程：

第一个过程是模块初始化阶段（MINIT）， 在整个SAPI生命周期内（例如Apache启动以后的整个生命周期内或者命令行程序整个执行过程中）， 该过程只进行一次。

第二个过程是模块**阶段（RINIT），该过程发生在请求阶段， 例如通过url请求某个页面，则在每次请求之前都会进行模块**（RINIT请求开始）。 例如PHP注册了一些扩展模块，则在MINIT阶段会回调所有模块的MINIT函数。 模块在这个阶段可以进行一些初始化工作，例如注册常量，定义模块使用的类等等。

模块在实现时可以通过如下宏来实现这些回调函数：

请求到达之后PHP初始化执行脚本的基本环境，例如创建一个执行环境，包括保存PHP运行过程中变量名称和值内容的符号表， 以及当前所有的函数以及类等信息的符号表。然后PHP会调用所有模块的RINIT函数， 在这个阶段各个模块也可以执行一些相关的操作，模块的RINIT函数和MINIT回调函数类似：

请求处理完后就进入了结束阶段，一般脚本执行到末尾或者通过调用exit()或die()函数， PHP都将进入结束阶段。和开始阶段对应，结束阶段也分为两个环节，一个在请求结束后停用模块(RSHUWDOWN，对应RINIT)， 一个在SAPI生命周期结束（Web服务器退出或者命令行脚本执行完毕退出）时关闭模块(MSHUTDOWN，对应MINIT)。

5

}

一次请求生命周期

我们从未手动开启过PHP的相关进程，它是随着Apache的启动而运行的。PHP通过mod_php5.so模块和Apache相连（具体说来是SAPI，即服务器应用程序编程接口）。

PHP总共有三个模块：内核、Zend引擎、以及扩展层。

• PHP内核用来处理请求、文件流、错误处理等相关操作；
• Zend引擎（ZE）用以将源文件转换成机器语言，然后在虚拟机上运行它；
• 扩展层是一组函数、类库和流，PHP使用它们来执行一些特定的操作。

比如，我们需要mysql扩展来连接MySQL数据库； 当ZE执行程序时可能会需要连接若干扩展，这时ZE将控制权交给扩展，等处理完特定任务后再返还；最后，ZE将程序运行结果返回给PHP内核，它再将结果传送给SAPI层，最终输出到浏览器上。

深入探讨

真正的内部运行过程没有这么简单。以上过程只是个简略版，让我们再深入挖掘一下，看看幕后还发生了些什么。

Apache启动后，PHP解释程序也随之启动。PHP的启动过程有两步：

• 第一步是初始化一些环境变量，这将在整个SAPI生命周期中发生作用；
• 第二步是生成只针对当前请求的一些变量设置。

PHP启动第一步

不清楚什么第一第二步是什么？别担心，我们接下来详细讨论一下。让我们先看看第一步，也是最主要的一步。要记住的是，第一步的操作在任何请求到达之前就发生了。

启动Apache后，PHP解释程序也随之启动。PHP调用各个扩展的MINIT方法，从而使这些扩展切换到可用状态。看看php.ini文件里打开了哪些扩展吧。 MINIT的意思是“模块初始化”。各个模块都定义了一组函数、类库等用以处理其他请求。

一个典型的MINIT方法如下：

PHP启动第二步

当一个页面请求发生时，SAPI层将控制权交给PHP层。于是PHP设置了用于回复本次请求所需的环境变量。同时，它还建立一个变量表，用来存放执 行过程 中产生的变量名和值。PHP调用各个模块的RINIT方法，即“请求初始化”。一个经典的例子是Session模块的RINIT，如果在php.ini中 启用了Session模块，那在调用该模块的RINIT时就会初始化$_SESSION变量，并将相关内容读入；RINIT方法可以看作是一个准备过程， 在程序执行之间就会自动启动。 一个典型的RINIT方法如下：

PHP关闭第一步

如同PHP启动一样，PHP的关闭也分两步。一旦页面执行完毕（无论是执行到了文件末尾还是用exit或die函数中止），PHP就会启动清理程 序。它会按顺序调用各个模块的RSHUTDOWN方法。 RSHUTDOWN用以清除程序运行时产生的符号表，也就是对每个变量调用unset函数。

一个典型的RSHUTDOWN方法如下：

PHP关闭第二步

最后，所有的请求都已处理完毕，SAPI也准备关闭了，PHP开始执行第二步：PHP调用每个扩展的MSHUTDOWN方法，这是各个模块最后一次释放内存的机会。

一个典型的RSHUTDOWN方法如下：

这样，整个PHP生命周期就结束了。要注意的是，只有在服务器没有请求的情况下才会执行“启动第一步”和“关闭第二步”。

单进程SAPI生命周期

CLI/CGI模式的PHP属于单进程的SAPI模式。这类的请求在处理一次请求后就关闭。也就是只会经过如下几个环节： 开始 - 请求开始 - 请求关闭 - 结束 SAPI接口实现就完成了其生命周期。

单进程多请求则如下图所示：

Zend引擎

相信很多人都听说过 Zend Engine 这个名词，也有很多人知道 Zend Engine 就是 PHP 语言的核心，但若要问一句：Zend Engine 到底存在于何处？或者说，Zend Engine 究竟是在什么时候怎么发挥作用让 PHP 源码输出我们想要的东西的？

Zend引擎是PHP实现的核心，提供了语言实现上的基础设施。例如：PHP的语法实现，脚本的编译运行环境， 扩展机制以及内存管理等，当然这里的PHP指的是官方的PHP实现（除了官方的实现， 目前比较知名的有facebook的hiphop实现，不过到目前为止，PHP还没有一个标准的语言规范），而PHP则提供了请求处理和其他Web服务器 的接口(SAPI)。

要理解 Zend Engine 的作用，就不能不理解为什么会出现，PHP 为什么需要 Zend Engine, Zend Engine 的出现为 PHP 解决了什么问题。PHP 发展到 3.0 版本的时候，此时 PHP 已经很普及了。“在 PHP3 的顶峰，Internet 上 10% 的 web 服务器上都安装了它”，PHP Manual 如是说。广泛的应用必然带来更高的要求。但此时的 PHP3 却有些力不从心了，这主要是因为 PHP3 采用的是边解释边执行的运行方式，运行效率很受其影响。其次，代码整体耦合度比较高，可扩展性也不够好，不利于应付各种各样需求。因此，此时在 PHP 界里已经有点中流砥柱作用的 Zeev Suraski 和 Andi Gutmans 决定重写代码以解决这两个问题。最终他们俩把该项技术的核心引擎命名为 Zend Engine，Zend 的意思即为 Zeev + Andi 。

Zend Engine 最主要的特性就是把 PHP 的边解释边执行的运行方式改为先进行预编译(Compile)，然后再执行(Execute)。这两者的分开给 PHP 带来了革命性的变化：执行效率大幅提高；由于实行了功能分离，降低了模块间耦合度，可扩展性也大大增强。此时 PHP 已经能很方便的应付各种各样的 BT 需求了，而伴随 PHP 4.4.x ―可能是 PHP4 系列的最后一个分支―的发布，PHP 的大部分开发人员已经将注意力放在了 PHP5 或者 PHP6 上面，以后发布的基本上就是一些 Bug Fix Release。可以说第一代的 Zend Engine 是已经在站最后一班岗了。

2004 年 7 月，PHP 5 发布，支持 PHP5 的是 Zend Engine 2.0 版本。这个版本主要是对 PHP 的 OO 功能进行了改进（我没有提集成 SQLite、PDO 等特性是因为我们现在谈的主要是 Zend Engine 而非 PHP）。核心执行方式（非 OO 部分）较PHP4 的1.0 版本变动不大，所以 PHP5 纯粹的执行速度相对于 PHP4 没有大的提高。而预计将于本月中旬发布的 PHP 5.1 版本则会携带 Zend Engine 2.1 版本，这个版本将提供新的执行方式，执行速度也会快上许多，至少要比 PHP5.0 相对于 PHP4.x 的差别要大很多，所以，PHP 5.1 将会是一个很了很令人期待的版本。

但并非 PHP5 系列的 Zend Engine 2 就完美无缺了。前面已经提到过，Zend Engine 将代码分成编译和执行两大部分。一般情况下，我们的代码完成以后就很少再去改变了。但执行时 PHP 却不得不还得一次又一次的重复编译，这根本就是毫无必要的。而且通常情况下，编译的所花费的时间并不比执行少多少，说是五五开并不为过，因此这极大的浪费 了机器的 CPU。基于 Zend Engine 3.0 的 PHP6 将试图解决这个问题。除此之外，目前的 PHP 对多字节的字符处理也是 PHP 的一大致命缺陷。这在人们联系日益国际化的今天几乎是不可忍受的。而无数人在抨击 PHP 或 比较 ASP 等同类语言时总是不可避免的要提到这一点。同时受到 IBM 方面的压力，PHP6 也将会把对多字节字符的处理提到首要日程。这在 PHP6 的 Dev 版本中已经得到体现。

目前PHP的实现和Zend引擎之间的关系非常紧密，甚至有些过于紧密了，例如很多PHP扩展都是使用的Zend API， 而Zend正是PHP语言本身的实现，PHP只是使用Zend这个内核来构建PHP语言的，而PHP扩展大都使用Zend API， 这就导致PHP的很多扩展和Zend引擎耦合在一起了，后来才有PHP核心开发者就提出将这种耦合解开的建议。

目前PHP的受欢迎程度是毋庸置疑的，但凡流行的语言通常都会出现这个语言的其他实现版本， 这在Java社区里就非常明显，目前已经有非常多基于JVM的语言了，例如IBM的Project Zero就实现了一个基于JVM的PHP实现， .NET也有类似的实现，通常他们这样做的原因无非是因为：他们喜欢这个语言，但又不想放弃原有的平台， 或者对现有的语言实现不满意，处于性能或者语言特性等（HipHop就是这样诞生的）。

很多脚本语言中都会有语言扩展机制，PHP中的扩展通常是通过Pear库或者原生扩展，在Ruby中则这两者的界限不是很明显， 他们甚至会提供两套实现，一个主要用于在无法编译的环境下使用，而在合适的环境则使用C实现的原生扩展， 这样在效率和可移植性上都可以保证。目前这些为PHP编写的扩展通常都无法在其他的PHP实现中实现重用， HipHop的做法是对最为流行的扩展进行重写。如果PHP扩展能和ZendAPI解耦，则在其他语言中重用这些扩展也将更加容易了。

在PHP的生命周期的各个阶段，一些与服务相关的操作都是通过SAPI接口实现。 这些内置实现的物理位置在PHP源码的SAPI目录。这个目录存放了PHP对各个服务器抽象层的代码， 例如命令行程序的实现，Apache的mod_php模块实现以及fastcgi的实现等等。

在各个服务器抽象层之间遵守着相同的约定，这里我们称之为SAPI接口。 每个SAPI实现都是一个_sapi_module_struct结构体变量。（SAPI接口）。 在PHP的源码中，当需要调用服务器相关信息时，全部通过SAPI接口中对应方法调用实现， 而这对应的方法在各个服务器抽象层实现时都会有各自的实现。

下面是为SAPI的简单示意图：

以cgi模式和apache2服务器为例，它们的启动方法如下：

这里的cgi_sapi_module是sapi_module_struct结构体的静态变量。 它的startup方法指向php_cgi_startup函数指针。在这个结构体中除了startup函数指针，还有许多其它方法或字段。 其部分定义如下：

以上的这些结构在各服务器的接口实现中都有定义。如Apache2的定义：

目前PHP内置的很多SAPI实现都已不再维护或者变的有些非主流了，PHP社区目前正在考虑将一些SAPI移出代码库。 社区对很多功能的考虑是除非真的非常必要，或者某些功能已近非常通用了，否则就在PECL库中， 例如非常流行的APC缓存扩展将进入核心代码库中。

整个SAPI类似于一个面向对象中的模板方法模式的应用。 SAPI.c和SAPI.h文件所包含的一些函数就是模板方法模式中的抽象模板， 各个服务器对于sapi_module的定义及相关实现则是一个个具体的模板。

这样的结构在PHP的源码中有多处使用， 比如在PHP扩展开发中，每个扩展都需要定义一个zend_module_entry结构体。 这个结构体的作用与sapi_module_struct结构体类似，都是一个类似模板方法模式的应用。 在PHP的生命周期中如果需要调用某个扩展，其调用的方法都是zend_module_entry结构体中指定的方法， 如在上一小节中提到的在执行各个扩展的请求初始化时，都是统一调用request_startup_func方法， 而在每个扩展的定义时，都通过宏PHP_RINIT指定request_startup_func对应的函数。 以VLD扩展为例：其请求初始化为PHP_RINIT(vld),与之对应在扩展中需要有这个函数的实现：

所以， 我们在写扩展时也需要实现扩展的这些接口，同样，当实现各服务器接口时也需要实现其对应的SAPI。

Apache模块介绍

Apache概述

Apache是目前世界上使用最为广泛的一种Web Server，它以跨平台、高效和稳定而闻名。按照去年官方统计的数据，Apache服务器的装机量占该市场60%以上的份额。尤其是在 X（Unix/Linux）平台上，Apache是最常见的选择。其它的Web Server产品，比如IIS，只能运行在Windows平台上，是基于微软.Net架构技术的不二选择。

Apache支持许多特性，大部分通过模块扩展实现。常见的模块包括mod_auth（权限验证）、mod_ssl（SSL和TLS支持） mod_rewrite（URL重写）等。一些通用的语言也支持以Apache模块的方式与Apache集成。 如Perl，Python，Tcl，和PHP等。

Apache并不是没有缺点，它最为诟病的一点就是变得越来越重，被普遍认为是重量级的WebServer。所以，近年来又涌现出了很多轻量级的替 代产品，比如lighttpd，nginx等等，这些WebServer的优点是运行效率很高，但缺点也很明显，成熟度往往要低于Apache，通常只能 用于某些特定场合。

Apache组件逻辑图

Apache是基于模块化设计的，总体上看起来代码的可读性高于php的代码，它的核心代码并不多，大多数的功能都被分散到各个模块中，各个模块在 系统启动的时候按需载入。你如果想要阅读Apache的源代码，建议你直接从main.c文件读起，系统最主要的处理逻辑都包含在里面。

MPM（Multi -Processing Modules，多重处理模块）是Apache的核心组件之一，Apache通过MPM来使用操作系 统的资源，对进程和线程池进行管理。Apache为了能够获得最好的运行性能，针对不同的平台(Unix/Linux、Window)做了优化，为不同的 平台提供了不同的MPM，用户可以根据实际情况进行选择，其中最常使用的MPM有prefork和worker两种。至于您的服务器正以哪种方式运行，取 决于安装Apache过程中指定的MPM编译参数，在X系统上默认的编译参数为prefork。由于大多数的Unix都不支持真正的线程，所以采用了预派 生子进程(prefork)方式，象Windows或者Solaris这些支持线程的平台，基于多进程多线程混合的worker模式是一种不错的选择。对 此感兴趣的同学可以阅读有关资料，此处不再多讲。Apache中还有一个重要的组件就是APR（Apache portable Runtime Library），即Apache可移植运行库，它是一个对操作系统调用的抽象库，用来实现Apache内部组件对操作系统的使用，提高系统的可移植性。 Apache对于php的解析，就是通过众多Module中的php Module来完成的。

Apache的逻辑构成以及与操作系统的关系

PHP与Apache

当PHP需要在Apache服务器下运行时，一般来说，它可以mod_php5模块的形式集成， 此时mod_php5模块的作用是接收Apache传递过来的PHP文件请求，并处理这些请求， 然后将处理后的结果返回给Apache。如果我们在Apache启动前在其配置文件中配置好了PHP模块（mod_php5）， PHP模块通过注册apache2的ap_hook_post_config挂钩，在Apache启动的时候启动此模块以接受PHP文件的请求。

除了这种启动时的加载方式，Apache的模块可以在运行的时候动态装载， 这意味着对服务器可以进行功能扩展而不需要重新对源代码进行编译，甚至根本不需要停止服务器。 我们所需要做的仅仅是给服务器发送信号HUP或者AP_SIG_GRACEFUL通知服务器重新载入模块。 但是在动态加载之前，我们需要将模块编译成为动态链接库。此时的动态加载就是加载动态链接库。 Apache中对动态链接库的处理是通过模块mod_so来完成的，因此mod_so模块不能被动态加载， 它只能被静态编译进Apache的核心。这意味着它是随着Apache一起启动的。

Apache是如何加载模块的呢？我们以前面提到的mod_php5模块为例。 首先我们需要在Apache的配置文件httpd.conf中添加一行：

这里我们使用了LoadModule命令，该命令的第一个参数是模块的名称，名称可以在模块实现的源码中找到。 第二个选项是该模块所处的路径。如果需要在服务器运行时加载模块， 可以通过发送信号HUP或者AP_SIG_GRACEFUL给服务器，一旦接受到该信号，Apache将重新装载模块， 而不需要重新启动服务器。

在配置文件中添加了所上所示的指令后，Apache在加载模块时会根据模块名查找模块并加载， 对于每一个模块，Apache必须保证其文件名是以“mod_”开始的，如PHP的mod_php5.c。 如果命名格式不对，Apache将认为此模块不合法。Apache的每一个模块都是以module结构体的形式存在， module结构的name属性在最后是通过宏STANDARD20_MODULE_STUFF以__FILE__体现。 关于这点可以在后面介绍mod_php5模块时有看到。这也就决定了我们的文件名和模块名是相同的。 通过之前指令中指定的路径找到相关的动态链接库文件后，Apache通过内部的函数获取动态链接库中的内容， 并将模块的内容加载到内存中的指定变量中。

在真正**模块之前，Apache会检查所加载的模块是否为真正的Apache模块， 这个检测是通过检查module结构体中的magic字段实现的。 而magic字段是通过宏STANDARD20_MODULE_STUFF体现，在这个宏中magic的值为MODULE_MAGIC_COOKIE， MODULE_MAGIC_COOKIE定义如下：

最后Apache会调用相关函数(ap_add_loaded_module)将模块**， 此处的**就是将模块放入相应的链表中(ap_top_modules链表： ap_top_modules链表用来保存Apache中所有的被**的模块，包括默认的**模块和**的第三方模块。）

通过mod_php5支持PHP

Apache对PHP的支持是通过Apache的模块mod_php5来支持的。如果希望Apache支持PHP的话，在./configure步 骤需要指定--with-apxs2=/usr/local/apache2/bin/apxs 表示告诉编译器通过Apache的mod_php5 /apxs来提供对PHP5的解析。

在最后一步make install的时候我们会看到将动态链接库libphp5.so(Apache模块)拷贝到apache2的安装目录的modules目录下，并且还需 要在httpd.conf配置文件中添加LoadModule语句来动态将libphp5.so 模块加载进来，从而实现Apache对php的支持。

由于该模式实在太经典了，因此这里关于安装部分不准备详述了，相对来说比较简单。我们知道nginx一般包括两个用途HTTP Server和Reverse Proxy Server(反向代理服务器)。在前端可以部署nginx作为reverse proxy server，后端布置多个Apache来实现机群系统server cluster架构的。

因此，实际生产中，我们仍旧能够保留Apache+mod_php5的经典App Server，而仅仅使用nginx来当做前端的reverse proxy server来实现代理和负载均衡。 因此，建议nginx(1个或者多个)+多个apache的架构继续使用下去。

Apache2的mod_php5模块包括sapi/apache2handler和sapi/apache2filter两个目录 在apache2_handle/mod_php5.c文件中，模块定义的相关代码如下：

它所对应的是Apache的module结构，module的结构定义如下：

上面的模块结构与我们在mod_php5.c中所看到的结构有一点不同，这是由于STANDARD20_MODULE_STUFF的原因， 这个宏它包含了前面8个字段的定义。STANDARD20_MODULE_STUFF宏的定义如下：

在php5_module定义的结构中，php_dir_cmds是模块定义的所有的指令集合，其定义的内容如下：

这是mod_php5模块定义的指令表。它实际上是一个command_rec结构的数组。 当Apache遇到指令的时候将逐一遍历各个模块中的指令表，查找是否有哪个模块能够处理该指令， 如果找到，则调用相应的处理函数，如果所有指令表中的模块都不能处理该指令，那么将报错。 如上可见，mod_php5模块仅提供php_value等5个指令。

php_ap2_register_hook函数的定义如下：

以上代码声明了pre_config，post_config，handler和child_init 4个挂钩以及对应的处理函数。 其中pre_config，post_config，child_init是启动挂钩，它们在服务器启动时调用。 handler挂钩是请求挂钩，它在服务器处理请求时调用。其中在post_config挂钩中启动php。 它通过php_apache_server_startup函数实现。php_apache_server_startup函数通过调用 sapi_startup启动sapi， 并通过调用php_apache2_startup来注册sapi module struct（此结构在本节开头中有说明）， 最后调用php_module_startup来初始化PHP， 其中又会初始化ZEND引擎，以及填充zend_module_struct中 的treat_data成员(通过php_startup_sapi_content_types)等。

到这里，我们知道了Apache加载mod_php5模块的整个过程，可是这个过程与我们的SAPI有什么关系呢？ mod_php5也定义了属于Apache的sapi_module_struct结构：

这些方法都专属于Apache服务器。以读取cookie为例，当我们在Apache服务器环境下，在PHP中调用读取Cookie时， 最终获取的数据的位置是在**SAPI时。它所调用的方法是read_cookies。

对于每一个服务器在加载时，我们都指定了sapi_module，而Apache的sapi_module是 apache2_sapi_module。 其中对应read_cookies方法的是php_apache_sapi_read_cookies函数。 这也是定义SAPI结构的理由：统一接口，面向接口的编程，具有更好的扩展性和适应性。

Apache运行与钩子函数

Apache是目前世界上使用最为广泛的一种Web Server，它以跨平台、高效和稳定而闻名。按照去年官方统计的数据，Apache服务器的装机量占该市场60%以上的份额。尤其是在 X（Unix/Linux）平台上，Apache是最常见的选择。其它的Web Server产品，比如IIS，只能运行在Windows平台上，是基于微软.Net架构技术的不二选择。

Apache并不是没有缺点，它最为诟病的一点就是变得越来越重，被普遍认为是重量级的WebServer。所以，近年来又涌现出了很多轻量级的替 代产品，比如lighttpd,nginx等等，这些WebServer的优点是运行效率很高，但缺点也很明显，成熟度往往要低于Apache，通常只能 用于某些特定场合。

Apache的运行过程

Apache的运行分为启动阶段和运行阶段。 在启动阶段，Apache为了获得系统资源最大的使用权限，将以特权用户root（*nix系统）或超级管理员 Administrator(Windows系统)完成启动， 并且整个过程处于一个单进程单线程的环境中。 这个阶段包括配置文件解析(如http.conf文件)、模块加载(如mod_php，mod_perl)和系统资源初始化（例如日志文件、共享内存段、 数据库连接等）等工作。

Apache的启动阶段执行了大量的初始化操作，并且将许多比较慢或者花费比较高的操作都集中在这个阶段完成，以减少了后面处理请求服务的压力。

在运行阶段，Apache主要工作是处理用户的服务请求。 在这个阶段，Apache放弃特权用户级别，使用普通权限，这主要是基于安全性的考虑，防止由于代码的缺陷引起的安全漏洞。 Apache对HTTP的请求可以分为连接、处理和断开连接三个大的阶段。同时也可以分为11个小的阶段，依次为： Post-Read-Request，URI Translation，Header Parsing，Access Control，Authentication，Authorization， MIME Type Checking，FixUp，Response，Logging，CleanUp

Apache Hook机制

Apache的Hook机制是指：Apache 允许模块(包括内部模块和外部模块，例如mod_php5.so,mod_perl.so等)将自定义的函数注入到请求处理循环中。换句话说，模块可以在 Apache的任何一个处理阶段中挂接(Hook)上自己的处理函数，从而参与Apache的请求处理过程。

mod_php5.so/ php5apache2.dll就是将所包含的自定义函数，通过Hook机制注入到Apache中，在Apache处理流程的各个阶段负责处理php请求。

关于Hook机制在Windows系统开发也经常遇到，在Windows开发既有系统级的钩子，又有应用级的钩子。常见的翻译软件（例如金山词霸等等）的屏幕取词功能，大多数是通过安装系统级钩子函数完成的，将自定义函数替换gdi32.dll中的屏幕输出的绘制函数。

Apache 服务器的体系结构的最大特点，就是高度模块化。如果你为了追求处理效率，可以把这些dso模块在apache编译的时候静态链入，这样会提高Apache 5%左右的处理性能。

Apache请求处理循环

Apache请求处理循环的11个阶段都做了哪些事情呢？

1. Post-Read-Request阶段。在正常请求处理流程中，这是模块可以插入钩子的第一个阶段。对于那些想很早进入处理请求的模块来说，这个阶段可以被利用。
2. URI Translation阶段。Apache在本阶段的主要工作：将请求的URL映射到本地文件系统。模块可以在这阶段插入钩子，执行自己的映射逻辑。mod_alias就是利用这个阶段工作的。
3. Header Parsing阶段。Apache在本阶段的主要工作：检查请求的头部。由于模块可以在请求处理流程的任何一个点上执行检查请求头部的任务，因此这个钩子很少被使用。mod_setenvif就是利用这个阶段工作的。
4. Access Control阶段。 Apache在本阶段的主要工作：根据配置文件检查是否允许访问请求的资源。Apache的标准逻辑实现了允许和拒绝指令。mod_authz_host就是利用这个阶段工作的。
5. Authentication阶段。Apache在本阶段的主要工作：按照配置文件设定的策略对用户进行认证，并设定用户名区域。模块可以在这阶段插入钩子，实现一个认证方法。
6. Authorization阶段。 Apache在本阶段的主要工作：根据配置文件检查是否允许认证过的用户执行请求的操作。模块可以在这阶段插入钩子，实现一个用户权限管理的方法。
7. MIME Type Checking阶段。Apache在本阶段的主要工作：根据请求资源的MIME类型的相关规则，判定将要使用的内容处理函数。标准模块mod_negotiation和mod_mime实现了这个钩子。
8. FixUp阶段。这是一个通用的阶段，允许模块在内容生成器之前，运行任何必要的处理流程。和Post_Read_Request类似，这是一个能够捕获任何信息的钩子，也是最常使用的钩子。
9. Response阶段。Apache在本阶段的主要工作：生成返回客户端的内容，负责给客户端发送一个恰当的回复。这个阶段是整个处理流程的核心部分。
10. Logging阶段。Apache在本阶段的主要工作：在回复已经发送给客户端之后记录事务。模块可能修改或者替换Apache的标准日志记录。 
11. CleanUp阶段。 Apache在本阶段的主要工作：清理本次请求事务处理完成之后遗留的环境，比如文件、目录的处理或者Socket的关闭等等，这是Apache一次请求处理的最后一个阶段。

    从PHP源码目录结构的介绍以及PHP生命周期可知：嵌入式PHP类似CLI，也是SAPI接口的另一种实现。 一般情况下，它的一个请求的生命周期也会和其它的SAPI一样：模块初始化=>请求初始化=>处理请求=>关闭请求=>关闭模 块。 当然，这只是理想情况。因为特定的应用由自己特殊的需求，只是在处理PHP脚本这个环节基本一致。

    对于嵌入式PHP或许我们了解比较少，或者说根本用不到，甚至在网上相关的资料也不多， 例如很多游戏中使用Lua语言作为粘合语言，或者作为扩展游戏的脚本语言，类似的， 浏览器中的Javascript语言就是嵌入在浏览器中的。只是目前很少有应用将PHP作为嵌入语言来使用， PHP的强项目前还是在Web开发方面。

    PHP对于嵌入式PHP的支持以及PHP为嵌入式提供了哪些接口或功能呢？首先我们看下所要用到的示例源码：

    01	#include <sapi/embed/php_embed.h>

    02	#ifdef ZTS

    03	void***tsrm_ls;

    04

    #endif

    05	/* Extension bits */

    06	zend_module_entry php_mymod_module_entry = {

    07	STANDARD_MODULE_HEADER,

    08	"mymod",/* extension name */

    09	NULL,/* function entries */

    10	NULL,/* MINIT */

    11	NULL,/* MSHUTDOWN */

    12	NULL,/* RINIT */

    13	NULL,/* RSHUTDOWN */

    14	NULL,/* MINFO */

    15	"1.0",/* version */

    16	STANDARD_MODULE_PROPERTIES

    17

    };

    18	/* Embedded bits */

    19	staticvoidstartup_php(void)

    20

    {

    21	intargc = 1;

    22	char*argv[2] = {"embed5", NULL };

    23	php_embed_init(argc, argv PTSRMLS_CC);

    24	zend_startup_module(&php_mymod_module_entry);

    25

    }

    26	staticvoidexecute_php(char*filename)

    27

    {

    28	zend_first_try {

    29	char*include_script;

    30	spprintf(&include_script, 0,"include '%s'", filename);

    31	zend_eval_string(include_script, NULL, filename TSRMLS_CC);

    32	efree(include_script);

    33	} zend_end_try();

    34

    }

    35	intmain(intargc,char*argv[])

    36

    {

    37	if(argc <= 1) {

    38	printf("Usage: embed4 scriptfile";);

    39

    return-1;

    40

    }

    41	startup_php();

    42	execute_php(argv[1]);

    43	php_embed_shutdown(TSRMLS_CC);

    44

    return0;

    45

    }

    以上的代码可以在《Extending and Embedding PHP》在第20章找到（原始代码有一个符号错误，有兴趣的童鞋可以去围观下）。 上面的代码是一个嵌入式PHP运行器（我们权当其为运行器吧），在这个运行器上我们可以运行PHP代码。 这段代码包括了对于PHP嵌入式支持的声明，启动嵌入式PHP运行环境，运行PHP代码，关闭嵌入式PHP运行环境。 下面我们就这段代码分析PHP对于嵌入式的支持做了哪些工作。 首先看下第一行：

    1	#include <sapi/embed/php_embed.h>

    在sapi目录下的embed目录是PHP对于嵌入式的抽象层所在。在这里有我们所要用到的函数或宏定义。 如示例中所使用的php_embed_init，php_embed_shutdown等函数。

    第2到4行：

    1	#ifdef ZTS

    2	void***tsrm_ls;

    3

    #endif

    ZTS是Zend Thread Safety的简写，与这个相关的有一个TSRM（线程安全资源管理）的东东，这个后面的章节会有详细介绍，这里就不再作阐述。

    第6到17行：

    01	zend_module_entry php_mymod_module_entry = {

    02	STANDARD_MODULE_HEADER,

    03	"mymod",/* extension name */

    04	NULL,/* function entries */

    05	NULL,/* MINIT */

    06	NULL,/* MSHUTDOWN */

    07	NULL,/* RINIT */

    08	NULL,/* RSHUTDOWN */

    09	NULL,/* MINFO */

    10	"1.0",/* version */

    11	STANDARD_MODULE_PROPERTIES

    12

    };

    以上PHP内部的模块结构声明，此处对于模块初始化，请求初始化等函数指针均为NULL， 也就是模块在初始化及请求开始结束等事件发生的时候不执行任何操作。 不过这些操作在sapi/embed/php_embed.c文件中的php_embed_shutdown等函数中有体现。 关于模块结构的定义在zend/zend_modules.h中。

    startup_php函数：

    1	staticvoidstartup_php(void)

    2

    {

    3	intargc = 1;

    4	char*argv[2] = {"embed5", NULL };

    5	php_embed_init(argc, argv PTSRMLS_CC);

    6	zend_startup_module(&php_mymod_module_entry);

    7

    }

    这个函数调用了两个函数php_embed_init和zend_startup_module完成初始化工作。 php_embed_init函数定义在sapi/embed/php_embed.c文件中。它完成了PHP对于嵌入式的初始化支持。 zend_startup_module函数是PHP的内部API函数，它的作用是注册定义的模块，这里是注册mymod模块。 这个注册过程仅仅是将所定义的zend_module_entry结构添加到注册模块列表中。

    execute_php函数：

    1	staticvoidexecute_php(char*filename)

    2

    {

    3	zend_first_try {

    4	char*include_script;

    5	spprintf(&include_script, 0,"include '%s'", filename);

    6	zend_eval_string(include_script, NULL, filename TSRMLS_CC);

    7	efree(include_script);

    8	} zend_end_try();

    9

    }

    从函数的名称来看，这个函数的功能是执行PHP代码的。 它通过调用sprrintf函数构造一个include语句，然后再调用zend_eval_string函数执行这个include语句。 zend_eval_string最终是调用zend_eval_stringl函数，这个函数是流程是一个编译PHP代码， 生成zend_op_array类型数据，并执行opcode的过程。 这段程序相当于下面的这段php程序，这段程序可以用php命令来执行，虽然下面这段程序没有实际意义， 而通过嵌入式PHP中，你可以在一个用C实现的系统中嵌入PHP，然后用PHP来实现功能。

    1

    <?php

    2	if($argc< 2)die("Usage: embed4 scriptfile");

    3

    4	include$argv[1];

    5

    ?>

    main函数：

    01	intmain(intargc,char*argv[])

    02

    {

    03	if(argc <= 1) {

    04	printf("Usage: embed4 scriptfile";);

    05

    return-1;

    06

    }

    07	startup_php();

    08	execute_php(argv[1]);

    09	php_embed_shutdown(TSRMLS_CC);

    10

    return0;

    11

    }

    这个函数是主函数，执行初始化操作，根据输入的参数执行PHP的include语句，最后执行关闭操作，返回。 其中php_embed_shutdown函数定义在sapi/embed/php_embed.c文件中。它完成了PHP对于嵌入式的关闭操作支持。 包括请求关闭操作，模块关闭操作等。

    以上是使用PHP的嵌入式方式开发的一个简单的PHP代码运行器，它的这些调用的方式都基于PHP本身的一些实现， 而针对嵌入式的SAPI定义是非常简单的，没有Apache和CGI模式的复杂，或者说是相当简陋，这也是由其所在环境决定。 在嵌入式的环境下，很多的网络协议所需要的方法都不再需要。如下所示，为嵌入式的模块定义。

    01	sapi_module_struct php_embed_module = {

    02	"embed",                      /* name */

    03	"PHP Embedded Library",       /* pretty name */

    04

    05	php_embed_startup,             /* startup */

    06	php_module_shutdown_wrapper,  /* shutdown */

    07

    08	NULL,                         /* activate */

    09	php_embed_deactivate,          /* deactivate */

    10

    11	php_embed_ub_write,            /* unbuffered write */

    12	php_embed_flush,               /* flush */

    13	NULL,                         /* get uid */

    14	NULL,                         /* getenv */

    15

    16	php_error,                    /* error handler */

    17

    18	NULL,                         /* header handler */

    19	NULL,                         /* send headers handler */

    20	php_embed_send_header,         /* send header handler */

    21

    22	NULL,                         /* read POST data */

    23	php_embed_read_cookies,        /* read Cookies */

    24

    25	php_embed_register_variables,  /* register server variables */

    26	php_embed_log_message,         /* Log message */

    27	NULL,                          /* Get request time */

    28	NULL,                          /* Child terminate */

    29

    30	STANDARD_SAPI_MODULE_PROPERTIES

    31

    };

    32

    /* }}} */

    在这个定义中我们看到了若干的NULl定义，在前面一小节中说到SAPI时，我们是以cookie的读取为例， 在这里也有读取cookie的实现——php_embed_read_cookies函数，但是这个函数的实现是一个空指针NULL。

PHP的FastCGI

CGI全称是“通用网关接口”(Common Gateway Interface)， 它可以让一个客户端，从网页浏览器向执行在Web服务器上的程序请求数据。 CGI描述了客户端和这个程序之间传输数据的一种标准。 CGI的一个目的是要独立于任何语言的，所以CGI可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。 如php，perl，tcl等。

FastCGI是Web服务器和处理程序之间通信的一种协议， 是CGI的一种改进方案，FastCGI像是一个常驻(long-live)型的CGI， 它可以一直执行，在请求到达时不会花费时间去fork一个进程来处理(这是CGI最为人诟病的fork-and-execute模式)。 正是因为他只是一个通信协议，它还支持分布式的运算，即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。

FastCGI是语言无关的、可伸缩架构的CGI开放扩展，将CGI解释器进程保持在内存中，以此获得较高的性能。 CGI程序反复加载是CGI性能低下的主要原因，如果CGI程序保持在内存中并接受FastCGI进程管理器调度， 则可以提供良好的性能、伸缩性、Fail-Over特性等。

一般情况下，FastCGI的整个工作流程是这样的：

1. Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)
2. FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
3. 当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。 Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
4. FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时， 请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中，php-cgi在此便退出了。

PHP的CGI实现了Fastcgi协议，是一个TCP或UDP协议的服务器接受来自Web服务器的请求， 当启动时创建TCP/UDP协议的服务器的socket监听，并接收相关请求进行处理。随后就进入了PHP的生命周期： 模块初始化，sapi初始化，处理PHP请求，模块关闭，sapi关闭等就构成了整个CGI的生命周期。

以TCP为例，在TCP的服务端，一般会执行这样几个操作步骤：

1. 调用socket函数创建一个TCP用的流式套接字；
2. 调用bind函数将服务器的本地地址与前面创建的套接字绑定；
3. 调用listen函数将新创建的套接字作为监听，等待客户端发起的连接，当客户端有多个连接连接到这个套接字时，可能需要排队处理；
4. 服务器进程调用accept函数进入阻塞状态，直到有客户进程调用connect函数而建立起一个连接；
5. 当与客户端创建连接后，服务器调用read_stream函数读取客户的请求；
6. 处理完数据后，服务器调用write函数向客户端发送应答。

PHP的FastCGI使你的所有php应用软件通过mod_fastci运行，而不是mod_phpsusexec。FastCGI应用速度很快 是因为他们持久稳定，不必对每一个请求都启动和初始化。这使得应用程序的开发成为可能，否则在CGI范例是不切实际的（例如一个大型的脚本，或者一个需要 连接单个或多个数据库的应用）。

FastCGI的优点：

1. PHP脚本运行速度更快(3到30倍)。PHP解释程序被载入内存而不用每次需要时从存储器读取，极大的提升了依靠脚本运行的站点的性能。
2. 需要使用更少的系统资源。由于服务器不用每次需要时都载入PHP解释程序，你可以将站点的传输速度提升很高而不必增加cpu负担。
3. 不需要对现有的代码作任何改变。现有的一切都适用于PHP的FastCGI。

但是也会有潜在问题：

• 对所有的子目录（/home/USERNAME/public_html/php.ini）你只有一个可用的php.ini文件。这是优 化网站代码所必需的。如果你需要多个php.ini文件以适应不同的脚本需要，你可以在任何子目录禁用PHP的快速CGI，而其余的地方则继续有效。如果 你需要这样做请联系support。
• 你对PHP环境做的任何升级（如php.ini文件的改变）都有几分钟的延迟。这是因为为了更快的速度你的php.ini文件已经被载入内存，而不是每次需要时再从存储器重新读取。

  前面介绍了PHP的生命周期，PHP的SAPI，SAPI处于PHP整个架构较上层，而真正脚本的执行主要由Zend引擎来完成， 这一小节我们介绍PHP脚本的执行。

  目前编程语言可以分为两大类：

  • 第一类是像C/C++， .NET， Java之类的编译型语言， 它们的共性是：运行之前必须对源代码进行编译，然后运行编译后的目标文件。
  • 第二类比如PHP， Javascript， Ruby， Python这些解释型语言， 他们都无需经过编译即可“运行”。

  虽然可以理解为直接运行，但它们并不是真的直接就被能被机器理解， 机器只能理解机器语言，那这些语言是怎么被执行的呢， 一般这些语言都需要一个解释器， 由解释器来执行这些源码， 实际上这些语言还是会经过编译环节，只不过它们一般会在运行的时候实时进行编译。为了效率，并不是所有语言在每次执行的时候都会重新编译一遍， 比如PHP的各种opcode缓存扩展(如APC， xcache， eAccelerator等)，比如Python会将编译的中间文件保存成pyc/pyo文件， 避免每次运行重新进行编译所带来的性能损失。

  PHP的脚本的执行也需要一个解释器， 比如命令行下的php程序，或者apache的mod_php模块等等。 前面提到了PHP的SAPI接口， 下面就以PHP命令行程序为例解释PHP脚本是怎么被执行的。 例如如下的这段PHP脚本：

  1

  <?php

  2	$str="Hello, nowamagic!\n";

  3

  echo$str;

  4

  ?>

  假设上面的代码保存在名为hello.php的文件中， 用PHP命令行程序执行这个脚本：

  1	$ php ./hello.php

  这段代码的输出显然是Hello， nowamagic!， 那么在执行脚本的时候PHP/Zend都做了些什么呢？ 这些语句是怎么样让php输出这段话的呢? 下面将一步一步的进行介绍。

  程序的执行

  1. 如上例中， 传递给php程序需要执行的文件， php程序完成基本的准备工作后启动PHP及Zend引擎， 加载注册的扩展模块。
  2. 初始化完成后读取脚本文件，Zend引擎对脚本文件进行词法分析，语法分析。然后编译成opcode执行。 如过安装了apc之类的opcode缓存， 编译环节可能会被跳过而直接从缓存中读取opcode执行。

  PHP在读取到脚本文件后首先对代码进行词法分析，PHP的词法分析器是通过lex生成的， 词法规则文件在$PHP_SRC/Zend/zend_language_scanner.l， 这一阶段lex会会将源代码按照词法规则切分一个一个的标记(token)。PHP中提供了一个函数token_get_all()， 该函数接收一个字符串参数， 返回一个按照词法规则切分好的数组。 例如将上面的php代码作为参数传递给这个函数：

  1

  <?php

  2	$code=<<<PHP_CODE

  3

  <?php

  4	$str="Hello, nowamagic\n";

  5

  echo$str;

  6

  PHP_CODE;

  7

  8	var_dump(token_get_all($code));

  9

  ?>

  运行上面的脚本你将会看到一如下的输出：

  01

  array (

  02

  0 =>

  03

  array (

  04	0 => 368,      // 脚本开始标记

  05	1 => '<?php    // 匹配到的字符串

  06

  ',

  07

  2 => 1,

  08

  ),

  09

  1 =>

  10

  array (

  11

  0 => 371,

  12

  1 =>' ',

  13

  2 => 2,

  14

  ),

  15

  2 =>'=',

  16

  3 =>

  17

  array (

  18

  0 => 371,

  19

  1 =>' ',

  20

  2 => 2,

  21

  ),

  22

  4 =>

  23

  array (

  24

  0 => 315,

  25	1 => '"Hello, nowamagic

  26

  "',

  27

  2 => 2,

  28

  ),

  29

  5 =>';',

  30

  6 =>

  31

  array (

  32

  0 => 371,

  33

  1 => '

  34

  ',

  35

  2 => 3,

  36

  ),

  37

  7 =>

  38

  array (

  39

  0 => 316,

  40	1 =>'echo',

  41

  2 => 4,

  42

  ),

  43

  8 =>

  44

  array (

  45

  0 => 371,

  46

  1 =>' ',

  47

  2 => 4,

  48

  ),

  49

  9 =>';',

  这也是Zend引擎词法分析做的事情，将代码切分为一个个的标记，然后使用语法分析器(PHP使用bison生成语法分析器， 规则见$PHP_SRC/Zend/zend_language_parser。y)， bison根据规则进行相应的处理， 如果代码找不到匹配的规则，也就是语法错误时Zend引擎会停止，并输出错误信息。 比如缺少括号，或者不符合语法规则的情况都会在这个环节检查。 在匹配到相应的语法规则后，Zend引擎还会进行编译， 将代码编译为opcode， 完成后，Zend引擎会执行这些opcode， 在执行opcode的过程中还有可能会继续重复进行编译-执行， 例如执行eval，include/require等语句， 因为这些语句还会包含或者执行其他文件或者字符串中的脚本。

  例如上例中的echo语句会编译为一条ZEND_ECHO指令， 执行过程中，该指令由C函数zend_print_variable(zval* z)执行，将传递进来的字符串打印出来。 为了方便理解， 本例中省去了一些细节，例如opcode指令和处理函数之间的映射关系等。 后面的章节将会详细介绍。

  如果想直接查看生成的Opcode，可以使用php的vld扩展查看。扩展下载地址: http://pecl.php.net/package/vld。Win下需要自己编译生成dll文件。

  有关PHP脚本编译执行的细节，请阅读后面有关词法分析，语法分析及opcode编译相关内容。未完待续.......