Nginx-->进阶-->原理-->Nginx+php+fastcgi的原理与关系

一、用户对动态PHP网页访问过程

用户浏览器发起对网页的访问:http://192.168.1.103/index.php

用户和nginx服务器进行三次握手进行TCP连接(忽略包括nginx访问控制策略、nginx防火墙等访问控制策略)

第一步:用户将http请求发送给nginx服务器

第二步:nginx会根据用户访问的URI和后缀对请求进行判断

1.例如用户访问的index.php,nginx则会根据配置文件中的location进行匹配,例如:

[email protected]:/data/web# cat /etc/nginx/conf.d/blog.conf
server {
    root /data/web/blog/;
    index index.html index.htm;
    server_name www.fwait.com;
    location / {
        try_files $uri $uri/ /index.html;
    }
    location /blog/ {
        #alias /usr/share/doc/;
        auth_basic "authorized users only";
        auth_basic_user_file /etc/nginx/passwd.conf;
        #autoindex on;
        allow 192.168.1.103;
        deny all;
    }
    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass 127.0.0.1:9000;
    }

}

用户访问的是index.php,则会匹配到location ~ \.php$,这个的含义是对用户通过URI访问的资源进行区分大小的匹配,并且访问的资源是以.php结尾的。

nginx根据用户请求的资源匹配到具体的location后,会执行location对应的动作,location中动作的含义是:

include /etc/nginx/fastcgi_params; #表示nginx会调用fastcgi这个接口

fastcgi_intercept_errors on; #表示开启fastcgi的中断和错误信息记录

fastcgi_pass 127.0.0.1:9000; # 表示nginx通过fastcgi_pass将用户请求的资源发给127.0.0.1:9000进行解析,这里的nginx和php脚本解析服务器是在同一台机器上,所以127.0.0.1:9000表示的就是本地的php脚本解析服务器。

根据nginx服务器的配置,可以看出,用户访问的是动态的php资源,nginx会调用php相关脚本解析程序对用户访问的资源进行解析。

第三步:通过第二步可以看出,用户请求的是动态内容,nginx会将请求交给fastcgi客户端,通过fastcgi_pass将用户的请求发送给php-fpm

如果用户访问的是静态资源呢,那就简单了,nginx直接将用户请求的静态资源返回给用户。

第四步:fastcgi_pass将动态资源交给php-fpm后,php-fpm会将资源转给php脚本解析服务器的wrapper

第五步:wrapper收到php-fpm转过来的请求后,wrapper会生成一个新的线程调用php动态程序解析服务器

如果用户请求的是需要读取例如MySQL数据库等,将会触发读库操作;

如果用户请求的是如图片/附件等,PHP会触发一次查询后端存储服务器如通过NFS进行存储的存储集群;

第六步:php会将查询到的结果返回给nginx

第七步:nginx构造一个响应报文将结果返回给用户

这只是nginx的其中一种,用户请求的和返回用户请求结果是异步进行,即为用户请求的资源在nginx中做了一次中转,nginx可以同步,即为解析出来的资源,服务器直接将资源返回给用户,不用在nginx中做一次中转。

二、相关疑问

1.是不是每次用户对动态资源的请求都需要触发一次完整的动态资源解析过程?

不是,可以有两种方法解决这个问题:

第一,启用nginx本身具备的缓存功能,将动态资源解析结果缓存起来,下次用户进行对应资源访问时,nginx进行本次缓存查询,如果查询成功,则直接动态资源被解析后的静态资源返回给用户;

第二,在nginx后端部署缓存机器,如部署varnish缓存集群,对资源进行缓存,用户请求的资源,可以先在缓存集群上进行查找;

2.用nginx做缓存是否可行?看实际情况,如果在整个web架构中,nginx不是瓶颈的前提下,nginx可以用来做缓存,但是不建议这么做,因为nginx是用户请求和应答用户请求的必经之路,如果nginx出现了瓶颈,后端的其他如存储集群等性能再好也没用,所以在实际的部署中,不建议启用nginx的缓存功能(在将nginx作为http server的情况下)。因为启用nginx缓存功能,一是会降低nginx性能,二是会消耗部署nginx的对应服务器的硬件资源。

3.如果用一张图表示nginx fastcgi wrapper php之间的关系

4.fastcgi具体是个什么东西

CGI全称通用网关接口 Commmon Gateway Interface

用于HTTP服务上的程序服务通信交流的一种工具,CGI程序须运行在网络服务器上。

传统CGI接口方式性能较差,由于每次HTTP服务器遇到动态程序需要重启解析器来执行解析,然后结果被返回给HTTP服务器。这在处理高并发时,几乎是不可能的,因此诞生了FastCGI。另外传统的CGI接口方式安全性也很差

一个可伸缩地。高速地在HTTP服务器和动态脚本语言间通信的接口

接口在linux下是socket(这个socket可以是文件socket也可以是ip socket)

主要优点把动态语言和HTTP服务器分离开来。多数流行的HTTP服务器都支持FsatCGI包括Apache/Nginx/lighttpd等

支持语言比较流行的是PHP,接口方式采用C/S架构,可以将HTTP服务器和脚本解析器分开,同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。

当HTTP服务器每次遇到动态程序时,可以将其直接交付给FastCGI进程来执行,然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端,这在很大程度上提高了整个应用系统的性能。

5.具体的nginx + php的nginx相关配置

[email protected]:/data/web# cat /etc/nginx/nginx.conf|egrep -v "#|^$"
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
    worker_connections 768;
}
http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    gzip on;
    gzip_disable "msie6";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
[email protected]:/data/web#
[email protected]:/data/web# cat /etc/nginx/conf.d/blog.conf
server {
    root /data/web/blog/;
    index index.html index.htm;
    server_name www.fwait.com;
    location / {
        try_files $uri $uri/ /index.html;
    }
    location /blog/ {
        #alias /usr/share/doc/;
        auth_basic "authorized users only";
        auth_basic_user_file /etc/nginx/passwd.conf;
        #autoindex on;
        allow 192.168.1.103;
        deny all;
    }
    location ~ \.php$ {
        #include /usr/local/etc/nginx/fastcgi.conf;
        include /etc/nginx/fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass 127.0.0.1:9000;
    }

}
[email protected]:/data/web# 

参考链接:

http://runningyongboy.blog.51cto.com/8234857/1722299

时间: 2024-10-22 00:51:36

Nginx-->进阶-->原理-->Nginx+php+fastcgi的原理与关系的相关文章

Nginx解析PHP的原理 | CGI、FastCGI及php-fpm的关系

Nginx解析PHP的原理,CGI/FastCGI以及PHP-Fpm的关系. 一.PHP+Nginx应运而生的场景.随着互联网的发展,用户对此接受面广,数据流的增大使得Web端的运行承载压力日益增大,野蛮生长在大数据时代里的WEB语言PHP也找到了比老搭档更优越的活力搭档Nginx,说到Nginx咱就一起唠一唠这其中的奥妙. 从以下几个维度来剖析一下Nginx的活力所在,当然是和解析PHP的老搭档APACHE相比而言. 性能1.1 资源占有率少,节省内存资源1.2 非阻塞式的请求处理机制给之增加

FastCGI特点原理、nginx与php-fpm两种通信方式对比

kankacan一.FastCGI特点: 1.HTTP服务器和动态脚本语言间通信的接口或工具 2.可把动态语言解析和HTTP服务器分离I 3.Nginx.Apache.Lighttpd,以及多数动态语言 都支持FastCGI 4.FastCGI接口方式采用 C/S结构,分为客户端(HTTP服务器)和服务器端(动态语言解析服务器) 5.PHP动态语言服务器可以启动多个FastCGI的守护进程(例如php-fpm(fcgi process mangement)) 6.HTTP服务器通过 FastCG

Nginx+php+fastcgi的原理与关系

一.用户对动态PHP网页访问过程 用户浏览器发起对网页的访问:http://192.168.1.103/index.php 用户和nginx服务器进行三次握手进行TCP连接(忽略包括nginx访问控制策略.nginx防火墙等访问控制策略) 第一步:用户将http请求发送给nginx服务器 第二步:nginx会根据用户访问的URI和后缀对请求进行判断 例如用户访问的index.php,nginx则会根据配置文件中的location进行匹配,例如: [email protected]:/data/w

Nginx为什么比Apache Httpd高效:原理篇

一.进程.线程? 进程是具有一定独立功能的,在计算机中已经运行的程序的实体.在早期系统中(如linux 2.4以前),进程是基本运作单位,在支持线程的系统中(如windows,linux2.6)中,线程才是基本的运作单位,而进程只是线程的容器.程序 本身只是指令.数据及其组织形式的描述,进程才是程序(那些指令和数据)的真正运行实例.若干进程有可能与同一个程序相关系,且每个进程皆可以同步(循 序)或异步(平行)的方式独立运行.现代计算机系统可在同一段时间内以进程的形式将多个程序加载到存储器中,并借

12.17 Nginx负载均衡;12.18 ssl原理;12.19 生产ssl密钥对;12.20 N

12.17 Nginx负载均衡:12.18 ssl原理:12.19 生产ssl密钥对:12.20 Nginx配置ssl 扩展: 针对请求的uri来代理 : http://ask.apelearn.com/question/1049 根据访问的目录来区分后端的web : http://ask.apelearn.com/question/920 nginx长连接 : http://www.apelearn.com/bbs/thread-6545-1-1.html nginx算法分析 : http:/

Nginx知多少系列之(四)工作原理

原文:Nginx知多少系列之(四)工作原理 目录 1.前言 2.安装 3.配置文件详解 4.工作原理 5.Linux下托管.NET Core项目 6.Linux下.NET Core项目负载均衡 7.Linux下.NET Core项目Nginx+Keepalived高可用(主从模式) 8.Linux下.NET Core项目Nginx+Keepalived高可用(双主模式) 9.Linux下.NET Core项目LVS+Keepalived+Nginx高可用集群 10.构建静态服务器 11.日志分析

高可用高性能分布式文件系统FastDFS进阶keepalived+nginx对多tracker进行高

在上一篇 分布式文件系统FastDFS如何做到高可用 中已经介绍了FastDFS的原理和怎么搭建一个简单的高可用的分布式文件系统及怎么访问. 高可用是实现了,但由于我们只设置了一个group,如果现在有5台服务器那将会出现5台只有一个group,每台服务器内的文件内容都相同(互备份)如下图,会造成资源浪费. 因此下面就5台服务器进行优化改造,进一步添加keepalived+nginx多tracker 架构,做到真正的高可用和高性能. FastDFS集群服务器分布 其中keepalived+ngi

架构设计:负载均衡层设计方案(3)——Nginx进阶

上篇文章<架构设计:负载均衡层设计方案(2)——Nginx安装>(http://blog.csdn.net/yinwenjie/article/details/46620711),我们介绍了Nginx的核心设计思想.基本安装和使用.本来准备继续介绍Nginx的几个使用特性,但是奈何博文篇幅太长,只有将一篇文章拆成两篇.本文我们将承接上文,继续讲解Nginx的实用特性,包括gzip功能.rewirte功能和一个第三方的节点监测模块.本文我们还将提到Taobao团队对Nginx的深度改造Tengi

Nginx 进阶 (ssl、fpm、rewrite、cache配置等)

一.配置https网站 1.自建CA (1)生成私钥文件 mkdir -p /etc/pki/CA/private #创建私钥保存的目录 (umask 077;openssl genrsa -out /etc/pki/CA/private/cakey.pem 4096) #创建私钥 ll /etc/pki/CA/private/ # 私钥只能自己保存,对保密性要求高 (2)生成自签证书 openssl req -new -x509 -key /etc/pki/CA/private/cakey.p