1、CLI:就是命令行，例如可以在控制台或者是shell中键入命令:
php -f index.php
然后获取输出
2、CGI:以下是不同的说法与理解
公共网关接口”(Common Gateway Interface)，HTTP服务器 与你的或其它机器上的程序 进行 “交谈”的一种工具 ，其程序 须运行在网络 服务器 上。在服务器 环境中，为“程序 ”提供标准 的接口，通过这个接口，“程序 ”可以对服务器 与客户端 交换的信息 做一些事情 。“程序 ”的语 言并没有要求。程序 对接口进行 操作。服务器 要支持 CGI就要提供CGI中要求的环境变量 ，或者还有别的。
HTTP Server和一个独立的进程之间的协议，把HTTP Request的Header设置成进程的环境变量，HTTP Request的正文设置成进程的标准输入，而进程的标准输出就是HTTP Response包括Header和正文。
这个 Web 服务器使用了 UNIX shell 环境变量 来保存从 Web 服务器传递出去的参数，然后生成一个运行 CGI 的独立进程。
不同类型语言写的程序只要符合cgi标准，就能作为一个cgi程序与web服务器交互
以CGI方式运行时,web server将用户请求以消息的方式转交给PHP独立进程,PHP与web服务之间无从属关系。
个人理解:CGI规定了php与web server交流的规则，相当于执行了response = exec("php -f index.php -url=xxx -cookie=xxx -xxx=xxx")。
关于CGI与CLI区别可以查看官方文档说的挺不错的:
文中阐述了CGI与CLI的显著区别:
以下为 CLI SAPI 和其它 CLI SAPI 模块相比的显著区别：
-
与 CGI SAPI 不同，其输出没有任何头信息。
尽管 CGI SAPI 提供了取消 HTTP 头信息的方法，但在 CLI SAPI 中并不存在类似的方法以开启 HTTP 头信息的输出。
CLI 默认以安静模式开始，但为了保证兼容性，-q 和 --no-header 参数为了向后兼容仍然保留，使得可以使用旧的 CGI 脚本。
在运行时，不会把工作目录改为脚本的当前目录（可以使用 -C 和 --no-chdir 参数来兼容 CGI 模式）。
出错时输出纯文本的错误信息（非 HTML 格式）。
3、FastCGI:CGI有很多缺点，每接收一个请求就要fork一个进程处理，只能接收一个请求作出一个响应。请求结束后该进程就会结束。而FastCGI会事先启动起来，作为一个cgi的管理服务器存在，预先启动一系列的子进程来等待处理，然后等待web服务器发过来的请求，一旦接受到请求就交由子进程处理，这样由于不需要在接受到请求后启动cgi，会快很多。FastCGI使用进程/线程池来处理一连串的请求。这些进程/线程由FastCGI服务器管理，而不是Web服务器。 当进来一个请求时，Web服务器把环境变量和这个页面请求通过一个Socket长连接传递给FastCGI进程。FastCGI像是一个常驻型的CGI，它可以一直执行，在请求到达时不会花费时间去fork一个进程来处理(这是CGI对位人诟病的fork-and-execute模式)。正是因为它只是一个通信协议，它还支持分布式的运算，即FastCGI程序可以在网站服务器以外的主机上执行并且接受来自其他网站服务器的请求
FastCGI整个流程:
-
-
Web server启动时载入FastCGI进程管理器
-
FastCGI自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web server的请求
-
当请求Web server时，Web server通过socket请求FastCGI进程管理器，FastCGI进程管理器选择并连接到一个CGI解释器，Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi
-
FastCGI子进程处理请求完成后将标准输出和错误从同一连接返回给Web server，当FastCGI子进程结束后请求便结束。FastCGI子进程接着等待处理来自FastCGI进程管理器的下一个连接，在CGI模式中，php-cgi在此便退出了。
-
php-fpm:PHP的FastCGI进程管理器
4、mod_php：即apache的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文件的功能。