关于nginx:关于nginx-fastcgipass-phpfpm-fastcgi-cgi-之间的一些关联

咱们晓得，nginx 作为 webserver，自身只能解决动态资源文件；
对于动静的 PHP 申请，须要调用相应的 PHP 解释器来执行；
因而须要配置 fastcgi_pass，以实现 nginx 与 php-fpm 过程间的通信。

nginx 与 php-fpm 过程间的通信有两种形式：

• 1、TCP
  就是 IP 加端口；
  长处是能够跨服务器；毛病是相比上面的办法要慢；
  配置示例：
  php-fpm.conf: listen = 127.0.0.1:9000
  nginx.conf: fastcgi_pass = 127.0.0.1:9000
• 2、UDS
  UDS 就是 UNIX Domain Socket 协定的缩写；
  长处是速度相比 TCP 要快，因为它不通过传输层 (5 层网络模型之一)；
  毛病是只实用于 nginx 和 php-fpm 在同一服务器的场景。
  配置示例：
  php-fpm.cnf: listen = /run/php/php-fpm.sock
  nginx.conf: listen = unix:/run/php/php-fpm.sock

那么，为什么 UDS 比 TCP 要快？
一般而言，socket 编程，是建设在传输层根底上的，就是下面的第一种通信形式，但在 Unix 零碎上，存在一种非凡的 socket，这种 socket 无需应用传统的 IP 地址 + 端口形式，而是间接应用文件来进行程序间的数据交互；

在 Unix 操作系统中，所有都能够看做是文件，天然包含程序运行的一些信息。因此，能够间接借助于这些程序运行时产生的文件来进行不同程序之间的数据交互，这就是 UDS 形式（此种 socket 只能在 unix 零碎上应用）。

UDS 形式，对于程序自身来说，只需读取和写入共享的 socket 文件即可 (又分为【StreamSocket- 流套接字】和【DatagramSocket- 数据包套接字】)，可用在两个没有关联关系的过程之间，间接通过 socket 文件进行数据交互；
时下大火的一种容器技术，docker，和实体机进行数据传输和信息替换应用的也正是 UDS。

其特点如下：

• 1) 传输不通过网络协议栈(也就是那 5 层网络模型)，不须要打包拆包，只是数据间的拷贝；
• 2) 因为是在本机通过内核通信，不会丢包也不会呈现发送包的秩序和接管包的秩序不统一的问题;
• 基于以上特点，其传输速度更快，有文章称是 TCP 的两倍，没有深刻理解，不予置评。
  但 UDS 作为目前比拟宽泛应用的 IPC 机制，传输速度更快是必定的，毕竟网络协议是为不牢靠通信设计的，而 IPC 机制实质上是牢靠通信，免去了这些繁琐的牢靠校验步骤。

UDS 与 TCP 连贯形式简略示意：

UDS 形式：
nginx <=> socket <=> php-fpm
TCP 本机形式：
nginx <=> socket <=> TCP/IP <=> socket <=> php-fpm
TCP 跨服务器形式：
nginx <=> socket <=> TCP/IP <=> 物理层 <=> 路由器 <=> 物理层 <=> TCP/IP <=> socket <=> php-fpm

nginx 应用 UDS 与 php-fpm 过程间通信的益处 ：
这种通信形式产生在零碎内核里，不会在网络中流传，它不会走到 TCP 的那一层，间接以 stream-socket 文件模式通信；
从而 防止了频繁创立 TCP 短链接而导致的 TIME_WAIT 连贯过多 的问题。

当然了，UDS 不能跨服务器也是最显著的毛病之一，至于如何抉择，需各位看官本人斟酌。

谈谈 php-fpm、fastcgi、cgi 之间的关系

CGI (Common Gateway Interface)：是一种通用的 Web 服务器和内部应用程序之间进行数据交互的标准协议，它定义了 Web 服务器和内部应用程序之间传递数据的格局和标准。在 CGI 模式下，PHP 程序每次申请都须要启动一个新的过程来解决申请，包含 ini，加载扩大配置等，并在申请处理完毕后完结过程，因而效率较低；
FastCGI(Fast Common Gateway Interface)：是对 CGI 的一种改良，它能够在过程池中保护多个 PHP 过程，并与 Web 服务器放弃长连贯，以进步性能。在 FastCGI 模式下，PHP 过程只在启动时创立一次，并放弃运行状态，不须要每次申请都重新启动过程；
php-fpm (PHP FastCGI Process Manager)：是一个独立的 PHP 过程管理器，能够治理 FastCGI 模式下的 PHP 过程池，并提供过程调度、过程监控、申请解决等性能。php-fpm 能够独立于 Web 服务器运行，也能够与 Nginx、Apache 等 Web 服务器配合应用。

联合括号中的英文全拼就比拟容易了解了，简略来说：
CGI 和 FastCGI 是两个协定，或者叫行业标准，FastCGI 又是 CGI 的降级款计划 。
任何语言编写的程序都能够通过 FastCGI/CGI 协定来提供 Web 服务，不是专属于 PHP 的，这样了解就很清晰了。

php-fpm 是对 FastCGI 这种标准的实现，也就是成品 (SAPI)；
它会启一个 master 主过程，初始化执行环境；依据须要 (配置文件)fork 出多个 worker 子过程解决申请，这样就防止了重复劳动，效率天然高;
当 worker 不够用时，master 能够依据配置事后启动几个 worker 等着；当闲暇 worker 太多时，会干掉一些，这样就节约了资源;
当更新配置文件 (php.ini) 时，新的 worker 用新的配置，正在解决申请的 worker 解决完手上的活就下岗，也就实现了平滑重启；

对了，还有个比拟蛊惑人的 php-cgi，这里也一并说下:
php-cgi 是同时实现了 CGI 和 FastCGI 两种标准协定的成品，它和 php-fpm 的角色一样。
CGI 和 FastCGI 都是设计方案，php-cgi 和 php-fpm 都是依据计划制作的成品。
并且，php-cgi 是亲生的（PHP 官网自带），但它不太好用，比方不能平滑重启，批改 php.ini 后需 kiil 掉原来的过程能力失效；
php-fpm 尽管好用，怎奈不是亲生，须要用户手动装置，俗称打补丁；
起初佛祖 (PHP 官网) 发现这妖猴有想法，敢打徒弟，前面搞不好是个劲敌，索性就收了封个斗战败佛吧，于是在 v5.3.2 版本之后继承了进去。