Nginx中fastcgi_pass配置概述

Posted 2023-05-14

参考技术A Socket通信是大家耳熟能详的一种进程间通信方式(IPC Inter-Process Communication)，它是一种全双工的通信方式.
Socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。

用于主机间(不同主机或同一主机)的通信
只需对方的ip地址和端口就可以通信
通信是基于网络协议栈的。
类似打电话一样只要知道对方手机号就可以通话。

用于一台主机的进程间通信
但它不使用网络底层协议来通信
基于文件（相同的文件路径）来进行通信
此文件是操作系统的实体文件

Unix Domain Socket是Unix系统下重要的本地进程间通信（IPC）机制之一，
在 DDE、GNOME、KDE 等 Linux 桌面环境中常见的进程间通信方式。

进程通信的方法有管道、命名管道、信号、消息队列、共享内存、信号量，这些方法都要求通信的两个进程位于同一个主机。但是如果通信双方不在同一个主机又该如何进行通信呢？通过使用tcp/ip协议族来进行相应的通信，如下图（图片来源于《tcp/ip协议详解卷一》第一章1.3）

直接和各个不同协议进行通信时就要使用不同的接口，还需处理不同协议的各种细节，开发难度大大增加，不易扩展。于是UNIX BSD就发明了socket这种东西，socket屏蔽了各个协议的通信细节，无需关注协议本身，直接使用socket提供的接口来进行互联的不同主机间的进程的通信。

Socket就实现了这种功能，提供了Tcp/Ip协议的抽象，对外提供了一套接口，同过这个接口就可以统一的使用Tcp/Ip协议的功能了。

文件描述符（file descriptor）通常是一个小的非负整数，内核用以标识一个特定进程正在访问的文件。当打开一个现有文件或创建一个新文件时，内核向进程返回一个文件描述符。当读、写一个文件时，使用 open 或 create 返回的文件描述符标识该文件，将其作为参数传送给 read 或 write。

每个进程在PCB（Process Control Block）中保存着一份文件描述符表，文件描述符就是这个表的索引，每个表项都有一个指向已打开文件的指针。

传递文件描述符还是有它的必要性的。

unix的哲学: 一切皆文件。socket被理所当然的设计成了文件，通过描述符我们可以定位到具体的file结构体，file结构体中有个f_type属性，标识了文件的类型，如图，DTYPE_VNODE表示普通的文件DTYPE_SOCKET表示socket，当然还有其他的类型，比如管道、设备等，这里我们只关心socket类型。如果是socket类型，那么f_ops域指向的就是相应的socket类型的驱动，而f_data域指向了具体的socket结构体，socket结构体关键域有so_type,so_pcb。

Socket工作模式, so_type常见的值有：

so_pcb表示socket控制块，其又指向一个结构体，该结构体包含了当前主机的ip地址(inp_laddr)，当前主机进程的端口号(inp_lport)，发送端主机的ip地址(inp_faddr)，发送端主体进程的端口号(inp_fport)。

so_pcb是socket类型的关键结构，不亚于进程控制块之于进程，在进程中，一个pcb可以表示一个进程，描述了进程的所有信息，每个进程有唯一的进程编号，该编号就对应pcb；socket也同时是这样，每个socket有一个so_pcb，描述了该socket的所有信息，而每个socket有一个编号，这个编号就是socket描述符。

nginx中fastcgi_pass的2种配置方式: unix domain socket和TCP Socket

Unix domain socket和Tcp socket，在性能上没有显著差距。
当访问压力较小时，可以使用UnixSocket，因为不会占用额外的端口、且理论上效率较高。

当高并发的时候，Tcp Socket能表现出更高的稳定性，且性能并不差于Unix Socket，缺点是会占用大量的临时端口，需要用内核参数优化。

1、 unix domain socket
2、 unix domain sockets vs. internet sockets
3、 socket Linux Programmer's Manual
4、 unix domain sockets vs. internet sockets
5、 nginx、php-fpm默认配置与性能–TCP socket还是unix domain socket

Nginx 高级配置

nginx官方网站：http://nginx.org/

1.  Nginx连接后端的方式：反向代理(proxy_pass)、直连fastcgi(fastcgi_pass)

        例子：

                fastcgi_pass backend1;

                proxy_pass http://backend2;

        location块中配置此项，表示用反向代理或直连fastcgi的方式连接后端服务，其中backend1、backend2为upstream配置，其中配置下游的ip&port列表和调度参数，见下文。

        注意：fastcgi_pass与proxy_pass是互斥配置，不能同时生效。

2. Nginx调度与负载均衡配置(upstream配置)

1) 轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器。 weight指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况，weight默认值为1。
        例如：
        upstream bakend {
                server 192.168.0.14 weight=10;
                server 192.168.0.15 weight=10;

        }

2) ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

        例如：
        upstream bakend {
                ip_hash;
                server 192.168.0.14:88;
                server 192.168.0.15:80;

        }

3) hash 每个请求按访问$hash_seed的hash结果分配。

        例如：

        upstream bakend {

                hash $hash_seed;

                server 192.168.0.14:88;
                server 192.168.0.15:80;

        }

4) fair（第三方）按后端服务器的响应时间来分配请求，响应时间短的优先分配，需要第三方插件。

        upstream backend {
                server 192.168.0.14:88;
                server 192.168.0.15:80;
                fair;

        }

5) url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。 例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

        upstream backend {

                server squid1:3128;
                server squid2:3128;
                hash $request_uri;
                hash_method crc32;
        }

3. upstream配置参数

例子：

        upstream bakend{
                ip_hash;
                server 127.0.0.1:9090 down;
                server 127.0.0.1:8080 weight=2;
                server 127.0.0.1:6060 max_fails=1 fail_timeout=10s;
                server 127.0.0.1:7070 backup;
        }

proxy_pass http://bakend/;或fastcgi_pass backend; 为每个设备的状态设置为:

        1) down 表示单前的server暂时不参与负载，一般用于标记故障机。

        2) weight 默认为1.weight越大，负载的权重就越大。
        3) max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
        4) fail_timeout:max_fails次失败后，暂停改服务的时间，超过时间后继续向该服务发送流量，默认为10s。
        5) backup：备用服务器，其它所有的非backup机器down或者忙的时候，启用backup机器。

4.容错机制

        1) Nginx 默认判断失败节点状态以connect refuse和time out状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态；

        2) 除非添加了fastcgi_next_upstream或proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理；

        3) 在next_upstream过程中，会对fails进行累加，如果备用机处理还是错误则直接返回错误信息（但404不进行记录到错误数，如果不配置错误状态也不对其进行错误状态记录）

综述，nginx记录错误数量timeout和connect refuse是永远被记录错误状态，而502、500、503、504只有在配置proxy_next_upstream或fastcgi_next_upstream后nginx才会记录这4种HTTP错误到fails中，当fails大于等于max_fails时，则该节点失效；

注意：

        fastcgi_next_upstream与proxy_next_upstream支持的错误并不一致：

                fastcgi_next_upstream：error | timeout | invalid_header | http_500 | http_503 | http_403 | http_404 | off

                proxy_next_upstream：error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_403 | http_404 | off ...

当fastcgi的服务异常时，因为fastcgi_next_upstream不支持http_502错误，无法对fastcgi异常进行判断，

所以fastcgi_pass与proxy_pass处理的规则也不相同：

	fastcgi_pass	proxy_pass
轮询	默认会将请求发送到下一个服务节点上	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
weight	默认会将请求发送到下一个服务节点上	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上
hash	默认不会将请求发送到下一个服务节点上，直接拒绝请求	默认不会将请求发送到下一个服务节点上，直接拒绝请求 在proxy_next_upstream中配置http_502错误，则会将请求发送到下一个服务节点上