如何获取当前运行模式

1
php_sapi_name()

CLI:（command-line interface）命令行接口

可以在控制台或者是shell中键入命令。如：

1
php index.php

CGI ：(Common Gateway Interface)公共网关接口

CGI实际上是一种程序之间的交互协议，通常作为HTTP Server和“程序”进行“交谈”的一种工具。这里的“程序”即实现了CGI协议的程序，我们可以称之为CGI程序，CGI程序的实现语言并没有要求。例如PHP-CGI就是实现了CGI协议的CGI程序，而HTTP Server本身也要实现CGI协议才能和PHP-CGI交互。

通过CGI协议，保证了HTTP Server传递过来的数据是标准格式的，以方便CGI程序的编写者。服务器要支持CGI就要提供CGI中要求的环境变量。该协议要求HTTP Server把HTTP Request的Header设置成CGI程序的环境变量，HTTP Request的正文设置成CGI程序的标准输入，而CGI程序的标准输出就是HTTP Response，包括Header和正文。

再进一步具体举例来讲的话，php以CGI方式运行时，web server（比如说nginx）根据配置文件知道这个不是静态文件，需要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP-CGI。Nginx会传哪些数据给PHP-CGI呢？url要有吧，查询字符串也得有吧，POST数据也要有，HTTP header不能少吧，好的，CGI协议就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。将用户请求以消息的方式转交给PHP-CGI独立进程。
实际上上面这个流程也说明了一个问题就是PHP与web服务之间并不是从属关系。

那么，CLI和CGI有哪些显著区别呢？

  1. CLI与CGI SAPI不同，CLI其输出没有任何头信息。
    尽管CGI SAPI 提供了取消 HTTP 头信息的方法，但在 CLI SAPI 中并不存在类似的方法以开启 HTTP 头信息的输出。
  2. CLI 默认以安静模式开始，但为了保证兼容性，-q 和 --no-header 参数为了向后兼容仍然保留，使得可以使用旧的CGI脚本。
  3. CLI在运行时，不会把工作目录改为脚本的当前目录（可以使用-C和--no-chdir 参数来兼容CGI模式）。
  4. CLI出错时输出纯文本的错误信息（非 HTML 格式）。

FastCGI：(Fast Common Gateway Interface)快速公共网关接口

顾名思义，FastCGI是CGI的升级版本，运行速度更快。传统的CGI程序有很多缺点，比如每接收一个请求就要fork一个新的进程去处理，每次只能接收一个请求作出一个响应，请求结束后该进程就会结束。而FastCGI程序会事先启动起来，作为一个cgi程序的管理服务器存在，预先启动一系列的子进程来等待处理，然后等待web服务器发过来的请求，一旦接受到请求就交由子进程处理，这样由于不需要在接受到请求后启动cgi程序，所以会快很多。

FastCGI使用进程/线程池来处理一连串的请求。这些进程/线程由FastCGI服务器管理，而不是Web服务器。当进来一个请求时，Web服务器把环境变量和这个页面请求通过一个Socket长连接传递给FastCGI进程。FastCGI进程像是一个常驻型的CGI进程，它可以一直执行，在请求到达时不会花费时间去fork一个进程来处理(这是CGI最为人诟病的fork-and-execute模式)。正是因为它只是一个通信协议，它还支持分布式的运算，即FastCGI程序可以在网站服务器以外的主机上执行并且接受来自其他网站服务器的请求。

FastCGI整个流程

  1. Web server启动时载入FastCGI进程管理器
  2. FastCGI自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web server的请求
  3. 当请求Web server时，Web server通过socket请求FastCGI进程管理器，FastCGI进程管理器选择并连接到一个PHP-CGI，Web server将CGI环境变量和标准输入发送到FastCGI子进程PHP-CGI
  4. FastCGI子进程处理请求完成后将标准输出和错误从同一连接返回给Web server，当FastCGI子进程结束后请求便结束。FastCGI子进程接着等待处理来自FastCGI进程管理器的下一个连接。（在CGI模式中，php-cgi在此便退出了）。

PHP-FPM：(PHP Fast CGI Process Manager)PHP-FastCGI进程管理器

PHP-FPM是一个实现了FastCGI协议的程序，被PHP官方收了。也可以说php-fpm是实现了FastCGI协议的php-cgi进程的管理器，用来管理FastCGI进程的。

通过上面我们知道，php-cgi只是一个CGI程序，本身只能解析请求，返回结果，不会进程管理。所以就出现了一些能够调度php-cgi进程的程序，比如说由lighthttpd分离出来的spawn-fcgi。所以PHP-FPM也是这么个东东，在长时间的发展后，逐渐得到了大家的认可（要知道，前几年大家可是抱怨PHP-FPM稳定性太差的），也越来越流行。

mod_php：即apache的php模块

Mod_php模式将PHP做为web-server的子进程控制,两者之间有从属关系.最明显的例子就是在CGI模式下,如果修改了PHP.INI的配置文件,不用重启web服务便可生效,而模块模式下则需要重启web服务。以mod_php模式运行PHP，意味着php是作为apache的一个模块来启动的，因此只有在apache启动的时候会读取php.ini配置文件并加载扩展模块，在apache运行期间是不会再去读取和加载扩展模块的

Apache的工作模式prefork的工作原理

一个单独的控制进程(父进程)负责产生子进程，这些子进程用于监听请求并作出应答。Apache总是试图保持一些备用的 (spare)或是空闲的子进程用于迎接即将到来的请求。这样客户端就无需在得到服务前等候子进程的产生。在Unix系统中，父进程通常以root身份运行以便邦定80端口，而 Apache产生的子进程通常以一个低特权的用户运行。User和Group指令用于配置子进程的低特权用户。运行子进程的用户必须要对他所服务的内容有读取的权限，但是对服务内容之外的其他资源必须拥有尽可能少的权限。

worker的工作原理

每个进程能够拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程能够建立ThreadsPerChild数量的服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用(spare)或是空闲的服务线程池。这样，客户端无须等待新线程或新进程的建立即可得到处理。在Unix中，为了能够绑定80端口，父进程一般都是以root身份启动，随后，Apache以较低权限的用户建立子进程和线程。User和Group指令用于配置Apache子进程的权限。虽然子进程必须对其提供的内容拥有读权限，但应该尽可能给予他较少的特权。另外，除非使用了suexec ，否则，这些指令配置的权限将被CGI脚本所继承

个人理解:这种模式把php嵌入到apache中，相当于给apache加入了解析php文件的功能。

基于fast-cgi协议模式的nginx和php-fpm交互细节

Nginx与PHP-fpm之间通过socket进行通讯，主要有两种通信方式unix socket和tcp socket

  1. nginx配置比较

    • unix socket需要在nginx配置文件中填写php-fpm运行的pid文件（即sock文件）地址

      1
      2
      3
      4
      5
      6
      location ~ \.php$ {
      	include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;
             fastcgi_pass unix:/var/run/php5-fpm.sock;
             fastcgi_index index.php;
         }

    • tcp socket需要在nginx配置文件中填写php-fpm运行的ip地址和端口号

      1
      2
      3
      4
      5
      6
      location ~ \.php$ {
          include fastcgi_params;
          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;;
          fastcgi_pass 127.0.0.1:9000;
          fastcgi_index index.php;
      }

  2. 特点比较

    unix socket减少了不必要的tcp开销，而tcp需要经过loopback，还要申请临时端口和tcp相关资源。但是，unix socket高并发时候不稳定，连接数爆发时，会产生大量的长时缓存，在没有面向连接协议的支撑下，大数据包可能会直接出错不返回异常。tcp这样的面向连接的协议，多少可以保证通信的正确性和完整性。

选择建议：如果是在同一台服务器上运行的nginx和php-fpm，并发量不超过1000，选择unix socket，因为是本地，可以避免一些检查操作(路由等)，因此更快，更轻。 如果面临高并发业务，我会选择使用更可靠的tcp socket，以负载均衡、内核优化等运维手段维持效率。

nginx和php配合处理请求的通用流程：

  1. nginx.conf配置webserver参数, 请求PHP类应用可配置fastcgi_pass，指明监听端口或socket地址
  2. php-fpm.conf中listen地址与nginx.conf fastcgi_pass字段配置一致（sock文件或是端口），表明php-fpm worker进程监听目标
  3. 启动后，请求先到达nginx server端口，分发到对应位置，若配置了fastcgi-pass，则被转到对应端口或socket，php-fpm master进程监听到，再创建fork worker进程实际运行，运行结束返回给nginx。即如下所示：
     www.example.com =》
 Nginx =》
 路由到www.example.com/index.php =》
 加载nginx的fast-cgi模块 =》
 fast-cgi监听127.0.0.1:9000地址=》
 www.example.com/index.php请求到达127.0.0.1:9000 =》
 php-fpm 监听127.0.0.1:9000 =》
 php-fpm 接收到请求，启用worker进程处理请求 =》
 php-fpm 处理完请求，返回给nginx =》
 nginx将结果通过http返回给浏览器

所以综上所述，Nginx和phpcgi都是实现了cgi协议的cgi程序，cgi协议规定了交互（输入和输出）的数据格式和方式，这个方式就是socket