Nginx

LNMP

LNMP 概述

L：Linux
N：Nginx
M：MySQL
P：<PHP、python、Perl>

FastCGI

CGI 概述

common gateway interface 通用网关接口
FastCGI解决了语言解释器和 Web Server 之间通讯的问题，主要是帮助 Web Server 处理动态请求处理完毕后再将数据返回给 Web Server
CGI 和 FastCGI的区别：
- CGI：Web Server 每收到一个请求都会创建一个 CGI 进程，处理请求结束时会关闭进程
- FastCGI：处理完请求后不会关闭CGI进程，而是保留这个进程，使这个进程可以处理多个请求

php-fpm 概述

FastCGI Process Manager：FastCGI 进程管理器
是一个实现了 FastCGI 的程序，并且提供进程管理功能
进程包括 master 进程和 worker 进程
- master 进程：只有一个，负责监听端口，接受来自 Web Server 的请求
- worker 进程：一般会有多个，每个进程中会嵌入一个 PHP 解释器来进行php代码的处理

FastCGI 核心指令

由 ngx_http_fastcgi_module 模块提供此功能
实现通过 fastcgi协议将客户端的动态请求转发至 php-fmp 处理
官方文档：https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

fastcgi_pass

定义转发的后端 fastcgi server 地址
Syntax：fastcgi_pass address;
Default：—
Context：location, if in location

fastcgi_index

定义 fastcgi server 默认主页位置，如：fastcgi_index、index.php
Syntax：fastcgi_index name;
Default：—
Context：http, server, location

fastcgi_param

定义传递给fastcgi服务器的参数值，可以是文本，变量或组合

变量

Nginx 变量前言

在 Nginx 中，变量是用来存储和传递数据的容器。可以将它们看作是一些可变的值，可以在 Nginx 配置中使用，以便在运行时生成不同的内容或进行特定的操作，例如：作为功能判断或日志等场景

Nginx 变量可以分为两类：内置变量和自定义变量。

Nginx 内置变量

Nginx 内置变量是由 Nginx 提供的一组预定义变量；
通过内置变量可以获取到众多的与客户端访问相关的值，可以在配置文件中直接使用。
参考文档：https://nginx.org/en/docs/varindex.html
常用的内置变量包括：

$remote_addr

客户端 IP 地址，例如：
- 112.39.61.13

$server_addr

服务器的IP地址，注意：显示的是服务器网卡的真实IP 包括局域网IP，例如：
- 172.27.185.115

$server_name

当前请求的虚拟主机名，例如：
- xiangzheng.vip

$server_port

服务器的端口号，例如：
- 80
- 443

$upstream_response_time

后端应用服务器处理时间

$upstream_addr

后端服务器地址

$proxy_add_x_forwarded_for

此变量表示将客户端的IP追加请求报文中 X-Forwarded-For 首部字段，多个IP之间用逗号分隔，如果请求中没有 X-Forwarded-For，就使用 $remote_addr
X-Forwarded-For头信息可以有多个，中间用逗号分隔，第一项为真实的客户端ip，剩下的就是曾经经过的代理或负载均衡的ip地址，经过几个就会出现几个。

$document_root

当前请求资源的系统根目录位置，例如：
- /data/web/pc/html

$document_uri

不包含参数的URI
假设访问的网站为 www.azheng.com/echo/index-1000002662.html?from=pc ，那么此变量的返回结果将是：
- /echo/index-1000002662.html

$uri

请求 URI，不包括主机名和参数部分。

$args

RUL的参数，请求的参数部分。
假设访问的网站为 www.azheng.com/echo/index-1000002662.html?from=pc ，那么此变量的返回结果将是：
- from=pc

$request_uri

完整uri，相当于 $document_uri+$args
假设访问的网站为 www.azheng.com/echo/index-1000002662.html?from=pc ，那么此变量的返回结果将是：
- /echo/index-1000002662.html?from=pc

$scheme

请求的协议，例如：
- http、https、ftp 等

$host

请求行中的主机名，或“主机”请求头字段中的主机名，或与请求匹配的服务器名
假设访问的网站为 www.azheng.com/echo/index-1000002662.html?from=pc ，那么此变量的返回结果将是：
- www.azheng.com

$request_filename

当前请求的文件路径，基于根或别名指令以及请求URI
假设访问的网站为 www.azheng.com/echo/index-1000002662.html?from=pc ，root中定义的路径为/data/web/pc/html，那么此变量的返回结果将是：
- /data/web/pc/html/echo/index-1000002662.html

$request_method

请求方法，例如：
- GET、POST、HEAD、DELETE 等

$server_protocol

客户端请求协议的版本，例如：
- HTTP/1.0、HTTP/1.1、HTTP/2.0 等

$http_user_agent

客户端浏览器的 User-Agent 信息

$http_referer

表示请求来源的 URL。

$http_<name>

name为任意请求报文首部字段，例如：
- $http_user_agent 客户端浏览器的详细信息，如：curl/7.68.0
- $http_cookie 客户端的cookie信息

$cookie_<name>

name为任意请求报文首部字段cookie

$request_time

总的处理时间

其他常用内置变量

$args	# 存放了请求url中的请求指令。比如http://www.myweb.name/server/source?arg1=value1&arg2=value2 中的 arg1=value1&arg2=value2

$content_length	# 存放请求头中的Content-length字段。

$content_type	# 存放请求头中的Content-Type字段。

$document_root	# 存放当前请求在root指令中指定的值。(即当前请求的根路径)

$host	# 存放了请求url中的主机字段，比如比如http://www.myweb.name/server/source?arg1=value1&arg2=value2 中的 www.myweb.name。如果请求中的主机部分字段不可用或者为空，则存放nginx配置中该server块中server_name指令的配置值

$http_user_agent # 存放客户端agent信息

$http_cookie # 存放客户端cookie信息

$limit_rate	# 这个变量可以限制连接速率。

$request_method	# 客户端请求的动作，通常为GET或POST。

$remote_addr # 客户端的IP地址。

$remote_port # 客户端的端口。

$remote_user # 已经经过Auth Basic Module验证的用户名。

$request_filename # 当前请求的文件路径，由root或alias指令与URI请求生成。

$scheme # HTTP方法（如http，https）。

$server_protocol # 请求使用的协议，通常是HTTP/1.0或HTTP/1.1。

$server_addr # 服务器地址，在完成一次系统调用后可以确定这个值。

$server_name # 服务器名称。

$server_port # 请求到达服务器的端口号。

$request_uri # 包含请求参数的原始URI，不包含主机名，如”/foo/bar.php?arg=baz”。

$uri # 不带请求参数的当前URI，$uri不包含主机名，如”/foo/bar.html”。

$document_uri # 与$uri相同。

Nginx 自定义变量

自定义变量是用户在 Nginx 配置中定义的变量。它们可以通过 set 指令创建，并且可以在配置文件中的任何地方使用。自定义变量的语法为：

第三方模块

前言

Nginx的第三方模块是由Nginx社区或其他独立开发者创建的扩展，可以用来扩展或增强Nginx的功能。这些第三方模块可以添加新的功能、提高性能、增强安全性、实现特定用途等等。

常用第三方模块

ngx_http_geoip_module：用于将IP地址转换为地理位置信息，可以根据客户端的位置提供不同的服务。
ngx_http_lua_module：通过Lua脚本语言扩展Nginx的功能，可以实现高度灵活的配置和动态处理请求。
ngx_http_image_filter_module：可以缩放、裁剪、旋转和转换图像格式等等，可以用于图片处理或优化。
ngx_http_auth_pam_module：使用PAM（Pluggable Authentication Modules）来验证用户身份，可以与系统用户数据库集成。

要使用这些第三方模块，您需要在编译Nginx时将其包含在内，并在Nginx配置文件中相应地配置。虽然第三方模块可以为Nginx增加很多有用的功能，但是需要注意的是，不同的第三方模块可能与不同版本的Nginx兼容性不同，因此需要仔细查看相应的文档并确认兼容性。

加载第三方模块

要在Nginx中加载第三方模块，您需要按照以下步骤进行操作：

首先，您需要获取所需的第三方模块的源代码或二进制文件。通常，第三方模块的开发者会提供相应的源代码或二进制文件。
接下来，您需要重新编译Nginx，并在编译时包含第三方模块。您可以使用以下命令来重新编译Nginx并包含第三方模块：

./configure --add-module=/path/to/third-party/module
make
sudo make install

这里的/path/to/third-party/module是您要包含的第三方模块的路径。您可以在configure命令中使用多个--add-module选项来同时包含多个第三方模块。

编译完成后，您需要在Nginx配置文件中启用第三方模块。通常情况下，第三方模块的开发者会提供相应的配置说明，您只需要按照说明进行配置即可。

注意：在加载第三方模块之前，请确保您的Nginx版本与第三方模块兼容。某些第三方模块可能不支持最新版本的Nginx，因此您需要仔细查看相应的文档并确认兼容性。

echo

nginx 第三方模块 echo 可以用于在 nginx 配置中输出 HTTP 响应的内容，通常用于调试和测试目的。
https://github.com/openresty/echo-nginx-module

安装 echo 模块

clone完源码包后，重新编译

# echo 模块源码
# ls -l /usr/local/src/echo-nginx-module/
total 76
-rw-r--r-- 1 root root  3184 Apr  6 18:21 config
-rw-r--r-- 1 root root  1345 Apr  6 18:21 LICENSE
-rw-r--r-- 1 root root 54504 Apr  6 18:21 README.markdown
drwxr-xr-x 2 root root  4096 Apr  6 18:21 src
drwxr-xr-x 2 root root  4096 Apr  6 18:21 t
drwxr-xr-x 2 root root    55 Apr  6 18:21 util
-rw-r--r-- 1 root root   986 Apr  6 18:21 valgrind.suppress


# 编译前
# ls -l /apps/nginx/sbin/
total 7420
-rwxr-xr-x 1 nginx nginx 7596456 Apr  2 14:00 nginx


# 获取编译时的选项
# nginx -V
...


# 编译，主要添加 --add-module=PATH 选项来指定第三方模块的路径
# cd /usr/local/src/nginx-1.18.0/
# ./configure --prefix=/apps/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module --add-module=/usr/local/src/echo-nginx-module
...
# make && make install


# 编译后
# ls -l /apps/nginx/sbin/
total 15364
-rwxr-xr-x 1 root  root  8131576 Apr  6 23:19 nginx # 新的！
-rwxr-xr-x 1 nginx nginx 7596456 Apr  2 14:00 nginx.old

echo 模块的使用

范例一

location /echo {
    echo "Hello, world!";
}


# curl www.azheng.com/echo
Hello, world!

范例二

下面是一个使用 echo 模块和一些自定义和内置变量的示例配置：

基础

I/O 模型

I/O 概述

I/O 就是把数据从内核空间中的内存数据 复制到 用户空间进程的内存当中

I/O 分类

Linux 中的 I/O

磁盘 I/O
- 磁盘 I/O 是进程向内核发起的系统调用；
- 假设请求磁盘上的某个资源，比如说 html 文件或者图片：
  - 内核会通过相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存
网络 I/O
- 一切皆文件，本质就是对 socket 文件的读写
总结：
- 无论是磁盘I/O还是网络I/O，每次I/O都要经由两个阶段：
  1. 先将数据加载至内核内存空间（缓冲区），时间较长
  2. 然后将数据从内核缓冲区复制到用户空间进程的内存，时间较短

同步与异步

同步与异步 关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状态的通知

同步 synchronous；被调用者并不提供事件的处理结果相关的通知信息，需要被调用者主动询问事件是否处理完成

异步 asynchronous；被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

阻塞与非阻塞

阻塞与非阻塞 关注调用者在等待结果返回之前所处的状态

阻塞 blocking；指IO操作需要彻底完成后才返回结果到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情

非阻塞 nonblocking；指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情

小结

**假设用水壶烧水这件事举例：**启动水壶后；

需要定期关注水是否烧开(同步)，期间不能做其他事情(阻塞)，这就是同步/阻塞。
需要定期关注水是否烧开(同步)，期间可以去做别的事情(非阻塞)，这就是同步/非阻塞。
水烧开后水壶会发出水烧开的信号来提醒我(异步)，期间不能做其他事情(阻塞)，这就是异步/阻塞。
水烧开后水壶会发出水烧开的信号来提醒我(异步)，期间可以去做别的事情(非阻塞)，这就是异步/非阻塞。

Nginx 概述

nginx是一个性能优异的web服务器应用，并且还能提供强大的反向代理功能

为什么这么快

epoll 模型
支持sendfile零复制技术
- 即将数据从磁盘中读出后进入内核空间后直接发送给soket缓存区，从而省略了user缓存这一步

特性

模块化设计、较好的扩展性
高可靠性
支持热部署：不停机更新配置文件、升级版本、更换日志文件等
低内存消耗：10000个kepp-alive连接模式下的非活动连接，消耗内存仅2.5M
event-driven、aio、mmap、sendfile

处理机制

一个master进程带领多个worker进程进行数据处理
master进程只负责将客户端请求调度到worker
真正进行数据处理的是worker进程

Apache VS Nginx

Nginx：

其他配置

基础配置

main

全局配置
主配置段，即全局配置段，对http,mail都有效

user nginx nginx; # 启动Nginx工作进程的用户和组，（指定的是workr进程的身份，master进程始终是以root身份运行的，因为80端口只有特权用户才可以监听）

worker_processes  < number | auto >; # 启动nginx worker进程的数量，一般和cpu核心数相同。也可以定义为auto，表示根据CPU核心数量自动匹配

worker_cpu_affinity 0001 0010 0100 1000; # 将worker进程绑定在某一颗cpu上，这样可以减少进程与不同cpu的反复切换，从而提升性能，0001 0010 0100 1000表示 四颗cpu;0号-3号cpu

error_log  logs/error.log; # 错误日志记录级别和路径

pid        run/nginx.pid; # pid文件路径

worker_priority 0; # worker进程优先级，-20~20(19)，数值越小优先级越高

worker_rlimit_nofile 65536; # 所有worker进程能打开的文件数量上线，还包括nginx的所有连接，实际的并发连接数不能超过系统级别的最大打开文件数的限制，最好与ulimit -n的值保持一致，否则在文件描述符不足时会报 Too many open files

daemon off; # 前台运行nginx服务，用于测试、docker等环境

worker_cpu_affinity

前期准备，假设系统中有8颗 CPU，但是 nginx 只开启了4个 worker 进程

# lscpu | grep -E "^CPU\(s\)"
CPU(s):              8


# grep worker_processes /apps/nginx/conf/nginx.conf
worker_processes  4;


# ps aux | grep nginx
root        1853  0.0  0.0  42456   844 ?        Ss   12:21   0:00 nginx: master process nginx
nginx       1854  0.0  0.2  77112  5024 ?        S    12:21   0:00 nginx: worker process
nginx       1855  0.0  0.2  77112  5024 ?        S    12:21   0:00 nginx: worker process
nginx       1856  0.0  0.2  77112  5024 ?        S    12:21   0:00 nginx: worker process
nginx       1857  0.0  0.2  77112  5024 ?        S    12:21   0:00 nginx: worker process

未绑定前 worker 会在不同的 CPU核心工作

# watch -n.5 'ps axo pid,cmd,psr | grep nginx'
   1853 nginx: master process nginx   2
   1854 nginx: worker process         3
   1855 nginx: worker process         4
   1856 nginx: worker process         5
   1857 nginx: worker process         6


# while true ; do ab -c 1000 -n 2000 http://localhost/ ; done


# watch -n.5 'ps axo pid,cmd,psr | grep nginx'
   1853 nginx: master process nginx   2
   1854 nginx: worker process         0
   1855 nginx: worker process         5
   1856 nginx: worker process         3
   1857 nginx: worker process         5



# watch -n.5 'ps axo pid,cmd,psr | grep nginx' 这个命令可以实现每0.5秒自动刷新一次，查看当前系统中所有包含“nginx”的进程的pid、cmd和psr（处理器标识符）信息。
具体解释如下：
  watch -n.5：这个命令用于设置一个定时器，每0.5秒刷新一次命令的输出。
  ps axo pid,cmd,psr：这个命令用于列出包含所有进程的pid，进程的命令名和进程所绑定的处理器标识符。
  grep nginx：这个命令管道符号用于过滤所有包含“nginx”的进程。注意，在某些情况下您可能需要修改grep命令来滤除不需要的进程。
综上所述，该命令对于监控和调试在Linux中运行的nginx进程非常有用。

将 CPU 核心分别与 2、4、6、8 号CPU做亲缘性绑定

# grep worker_cpu_affinity /apps/nginx/conf/nginx.conf
worker_cpu_affinity  00000010 00001000 00100000 10000000;


# while true ; do ab -c 1000 -n 2000 http://localhost/ ; done


# 显示1、3、5、7是正确的，因为CPU是从0开始标号 
# watch -n.5 'ps axo pid,cmd,psr | grep nginx'
   8826 nginx: worker process         1
   8827 nginx: worker process         3
   8828 nginx: worker process         5
   8829 nginx: worker process         7

worker_rlimit_nofile

当 Nginx 处理客户端请求时，Nginx 使用文件描述符来打开与该请求相关联的文件，而这个文件可能是一个静态 HTML 文件、一个动态的 PHP 脚本或任何其他类型的文件。每个这样的文件都被分配一个文件描述符来表示与该文件的连接，当文件已经被打开时，该文件的描述符就会被放入一张描述符表中。

优化

基础优化

以普通用户身份运行 Nginx

启动Nginx工作进程的用户和组，（指定的是workr进程的身份，master进程始终是以root身份运行的，因为80端口只有特权用户才可以监听）

user nginx nginx;

worker 进程相关优化

开启和 CPU 核心数相同的 worker 进程

启动nginx worker进程的数量，一般和cpu核心数相同，也可以定义为auto，表示根据CPU核心数量自动匹配

worker_processes  < number | auto >;

CPU 核心与 worker 进程进行亲缘性绑定

将worker进程绑定在某一颗cpu上，这样可以减少进程与不同cpu的反复切换，从而提升性能，0001 0010 0100 1000表示四颗cpu;0号-3号cpu

worker_cpu_affinity 0001 0010 0100 1000;

worker 的优先级

可选
-20优先级最高，19优先级最低，默认为0

所有 worker 进程能打开的文件数量

worker_rlimit_nofile 65536;

每个 worker 进程的最大连接数

events {
    worker_connections  10240;
}

每个 worker 可以同时接受多个新的网络连接

events {
    multi_accept on; # on时Nginx服务器的每个工作进程可以同时接受多个新的网络连接，此指令默认值为off，即默认为一个工作进程只能接受一个网络连接，建议优化，建议此值设为on

}

事件驱动模型优化

使用 epoll 的事件驱动模型（默认值）

events {
    use epoll;
}

http 响应首部优化

隐藏 nginx 版本号

作为web服务器

前言

Nginx 作为 Web 服务器时主要负责处理 html、图片、js、css、txt 等静态资源
动态资源的请求可以通过反向代理实现

mime

MIME（Multipurpose Internet Mail Extensions）是多用途互联网邮件扩展标准。它是一个用于描述文件内容类型的标准。MIME 用于在互联网上交换各种类型的数据，如文本、图像、音频、视频、应用程序等。
在Web中，MIME类型通常指定在 HTTP 请求头部的 Content-Type 属性中，用于表明发送的数据类型，以帮助客户端或浏览器正确地处理响应数据。
- 例如，如果客户端请求一个资源，服务器在响应头中指定了 MIME 类型为 text/html，则客户端浏览器会将这个资源当做 HTML 文档来处理。
MIME类型使用单个字符串来表示，例如：
- text/html、application/json、image/jpeg、audio/mp3 等
Nginx服务器可以通过配置文件添加、修改或者删除 MIME 类型，以满足不同文件类型的需求。例如：
- 可以使用 Nginx 的“types”模块来映射某个文件扩展名对应的 MIME 类型；
- 或者使用“default_type”指令设置默认的 MIME 类型。
  - default_type 默认值为 application/octet-stream，他的字面意思是 “八进制流二进制应用程序”，它是一种通用的二进制数据流类型，通常用于指示文件的媒体类型未知或不确定的情况下。
  - 在互联网通信中，当服务器无法确定某个文件的正确 MIME 类型时，会自动将其指定为 “application/octet-stream” 类型，这表示它是一个二进制文件类型，通常需要本地程序来识别和打开该类型的文件。
  - 例如，当您在下载某些未知格式的文件时，当服务器无法确定文件的正确 MIME 类型时，将自动将这些文件指定为 “application/octet-stream” 类型，这意味着文件将被视为二进制文件类型，并且您需要使用相应的本地程序来打开它们。
  - 需要注意的是，由于 “application/octet-stream” 类型不会告诉客户端文件的具体内容和类型，因此它在安全上存在一定的风险，例如，攻击者可以将其利用为上传病毒、恶意代码等攻击手段的载体。因此，在实际开发中，建议尽可能地明确文件的 MIME 类型，以便更好地保护系统的安全性和可靠性。
总的来说，MIME类型是一种用于指示数据的媒体类型或格式的标准，它在互联网通信和 Web 应用中扮演着重要的角色。

参考文档：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_Types

http {
...
    include       mime.types; # 导入支持的文件类型，在编译安装中是相对于/apps/nginx/conf的目录
    default_type  text/html; # 除mime.types中文件类型外，设置其他文件默认的MIME类型，访问其它类型时会提示下载不匹配的文件类型，建议修改为txt格式查看
    types { # 指定多个MIME类型
        text/html html;
        image/gif gif;
        image/jpeg jpg;
    }
...
}

范例

准备测试页面

# vim /apps/nginx/html/index.php
<?php
  echo "Hello, World!"; 
?>

访问测试，这种情况如果使用浏览器访问将自动下载文件

# curl http://localhost/index.php -sI | grep Content-Type
Content-Type: application/octet-stream

将无法识别后缀的文件解析为文本格式

http {
...
    default_type  text/html;
...
}

好啦

# curl http://localhost/index.php -sI | grep Content-Type
Content-Type: text/html

定义 http 响应首部

自定义 http 响应首部

添加头部报文信息，实现对后端服务器响应给客户端的报文中添加指定的响应首部字段
由 ngx_http_headers_module 模块提供此功能

Syntax：add_header name value [always];
Default： —
Context：http, server, location, if in location

add_header 配置范例

# 生产中通常开启，可以间接性的告诉攻击者攻击的是CDN等信息
add_header X-Cache $upstream_cache_status; # 是否缓存命令，常用
add_header X-Accel $server_name # 客户访问的FQDN，常用
add_header X-Via $server_addr; # 当前nginx主机的IP，不常用

add_header 测试范例

[root@centos8 ~]# vim /apps/nginx/conf/conf.d/pc.conf
...
    location / {
        proxy_pass http://10.0.0.18;
        proxy_cache nginx_proxy_cache;
        proxy_cache_key $request_uri;
        proxy_cache_valid 200 302 301 10m;
        proxy_cache_valid any 5m;
        add_header X-Cache $upstream_cache_status; #显示是否缓存命令
    }
...


#测试
[root@localhost ~]#curl -I http://www.azheng.com/
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Thu, 11 Nov 2021 12:21:06 GMT
Content-Type: text/html
Content-Length: 2331099
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Thu, 11 Nov 2021 11:42:16 GMT
ETag: "618d0198-2391db"
X-Cache: MISS #第一次未命中
Accept-Ranges: bytes

[root@localhost ~]#curl -I http://www.azheng.com/
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Thu, 11 Nov 2021 12:21:08 GMT
Content-Type: text/html
Content-Length: 2331099
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Thu, 11 Nov 2021 11:42:16 GMT
ETag: "618d0198-2391db"
X-Cache: HIT #第二次命中
Accept-Ranges: bytes

需要注意的是，添加自定义首部时应该遵循一些规范和最佳实践，例如不应该使用已经被标准化的首部名称，避免潜在的安全风险以及性能影响。

作为代理服务器

前言

Nginx可以通过多种方式实现反向代理，包括但不限于以下方式：

HTTP/HTTPS反向代理：Nginx可以将客户端请求转发到后端HTTP/HTTPS服务器，实现反向代理功能。在HTTP/HTTPS反向代理中，Nginx可以代理各种HTTP请求类型，如GET、POST等。
TCP/UDP反向代理：Nginx还可以代理TCP/UDP连接，例如代理SMTP、DNS等服务。
IMAP4/POP3反向代理：Nginx还支持代理IMAP4和POP3邮件服务。
FastCGI/UWSGI/SCGI等协议反向代理动态请求：Nginx可以通过FastCGI、UWSGI、SCGI等协议代理动态请求，例如PHP、Python等脚本语言的动态请求。这种方式比较常用于Web应用程序的反向代理。

总之，Nginx作为一款高性能的Web服务器和反向代理服务器，支持多种协议和应用场景，可灵活应对各种需求。

反向代理和负载均衡

反向代理和负载均衡是两个不同的概念，虽然它们有时候在实践中会结合使用。

反向代理是一种代理服务器，它接收客户端请求并将请求转发给后端服务器，同时将后端服务器的响应返回给客户端，从而实现隐藏后端服务器的IP地址和提供更好的安全性等功能。
负载均衡是一种分布式系统中的策略，它通过将负载分散到多个计算机节点上，以提高系统的性能、可扩展性和可用性。负载均衡可以实现在多台服务器之间分发请求，以达到平衡服务器负载的目的。

在实践中，我们通常会将反向代理和负载均衡结合使用，将客户端请求转发到多个后端服务器上，从而实现高性能和高可用性的Web应用程序。

反向代理和负载均衡的区别

反向代理和负载均衡是两个不同的概念，虽然它们在实践中有时候会结合使用。它们的主要区别如下：

功能不同：反向代理是一种代理服务器，它接收客户端请求并将请求转发给后端服务器，同时将后端服务器的响应返回给客户端，从而实现隐藏后端服务器的IP地址和提供更好的安全性等功能。而负载均衡是一种分布式系统中的策略，它通过将负载分散到多个计算机节点上，以提高系统的性能、可扩展性和可用性。
目的不同：反向代理的主要目的是提高Web应用程序的安全性和性能，通过隐藏后端服务器的IP地址和实现静态资源的缓存等功能，减轻后端服务器的负载，从而提高应用程序的可用性和可靠性。而负载均衡的主要目的是实现服务器集群的负载平衡，将客户端请求分配到多个后端服务器上，从而平衡服务器的负载，提高整个系统的性能和可用性。
实现方式不同：反向代理是通过在代理服务器和后端服务器之间建立连接，并在代理服务器上配置反向代理规则，来实现客户端请求的转发和响应的返回。而负载均衡是通过在负载均衡器上配置负载均衡策略，并在负载均衡器和后端服务器之间建立连接，来实现客户端请求的分发和后端服务器的负载平衡。

虽然反向代理和负载均衡是两个不同的概念，但在实践中通常会结合使用，以实现高性能和高可用性的Web应用程序。

同构代理和异构代理

同构代理指的是代理服务器和后端服务器使用相同的协议通信

比如Nginx作为代理服务器，反向代理到Apache或Tomcat服务器，它们都使用HTTP协议进行通信。

异构代理则指代理服务器和后端服务器使用不同的协议通信

比如Nginx作为代理服务器，反向代理到MySQL或Redis服务器，MySQL或Redis使用TCP协议进行通信，而Nginx使用HTTP协议进行通信。
需要注意的是，虽然代理服务器和后端服务器的协议不同，但代理服务器可以使用一些转换协议的技术来进行通信，比如使用FastCGI、uWSGI、SCGI等协议将请求转发到后端服务器。这样可以在代理服务器和后端服务器之间进行协议转换，从而实现异构代理的功能。

Nginx 代理相关模块说明

ngx_http_upstream_module

用于定义为proxy_pass、fastcgi_pass、uwsgi_pass等指令引用的后端服务器分组
这个模块允许 Nginx 与上游服务器进行通信，以便在 Nginx 与客户端之间进行负载均衡和高可用性方案。该模块可以配置多种负载均衡算法，如轮询、IP哈希、最少连接数等。
https://nginx.org/en/docs/http/ngx_http_upstream_module.html

ngx_http_proxy_module

将客户端的请求以http协议转发至指定服务器进行处理，缓存实现
该模块提供了将请求代理转发到另一个服务器的功能，通常用于反向代理和缓存。可以配置请求头、响应头和缓存设置等。
https://nginx.org/en/docs/http/ngx_http_proxy_module.html

ngx_stream_proxy_module

将客户端的请求以tcp协议转发至指定服务器处理
该模块提供了将TCP或UDP数据流代理转发到另一个服务器的功能，常用于代理转发数据库、消息队列等应用。
https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html

ngx_http_fastcgi_module

将客户端对php的请求以fastcgi协议转发至指定服务器处理
这个模块允许 Nginx 与 FastCGI 应用程序进行通信，通常用于运行 PHP 等脚本语言。可以配置请求参数、响应参数等。
https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

ngx_http_uwsgi_module

将客户端对python的请求以uwsgi协议转发至指定服务器处理
该模块允许 Nginx 与 uWSGI 应用程序进行通信，通常用于 Python 等脚本语言。可以配置请求参数、响应参数等。
https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html

ngx_http_headers_module

添加头部报文信息，实现对后端服务器响应给客户端的报文中添加指定的响应首部字段
该模块提供了添加、修改、删除请求和响应头的功能。可以用于设置缓存控制、安全标头等。
https://nginx.org/en/docs/http/ngx_http_headers_module.html

http_proxy 模块常用参数说明

https://nginx.org/en/docs/http/ngx_http_proxy_module.html
nginx默认会隐藏后端服务器的server、Date、X-Pad、X-Accel-… 等字段传递给客户端

proxy_pass

设置将客户端请求转发给的后端服务器主机

Syntax:	proxy_pass URL;
Default:	—
Context:	location, if in location, limit_except

URL 可以是：
主机名(将转发至后端服务器作为主机头首部)
IP地址:端口
预先设置的转发主机群组，需要 ngx_stream_proxy_module 模块支持

范例

有 / 符号和无 / 符号的区别

无 / ，类似root

server {
    ...
    server_name HOSTNAME;
    location /web {
        proxy_pass http://10.0.0.18:8080; #8080后无 /
    # 表示location后面的url附加到8080后
    # 最终访问的是后端服务器的：http://10.0.0.18:8080/web/index.html
    # 后端服务器需要有web目录才能访问，否则将将报404未找到
    }
    ...    
} 

#访问结果简述：
# http://HOSTNAME/web/ --> http://10.0.0.18:8080/web/index.html

有 / ，类似alias

server {
    ...
    server_name HOSTNAME;
    ...
    location /web {
        proxy_pass http://10.0.0.18:8080/; #8080后有 /
    # 表示访问代理服务器的 /web 相当于直接访问： http://10.0.0.18:8080/index.html    
    }
    ...    
} 

# 访问结果简述：
# http://HOSTNAME/web/ --> http://10.0.0.18:8080

其他注意事项

如果 location 定义其 uri 时使用了正则表达式模式（包括~、*，但不包括^），则 proxy_pass 之后必须不能使用 uri，用户请求时传递的 uri 将直接附加至后端服务器之后

server {
    ...
    server_name HOSTNAME;    
    ...
    location ~|~* /uri {
        index index.html;
        proxy_pass http://host:port; # proxy_pass后面的url不能加/，否则会报语法错误
    ...    
}
    
# 访问结果简述：
# http://HOSTNAME/uri/  -->  http://host:port/uri

是的，如果在 location 块中使用正则表达式模式（包括 ~、~*），那么在使用 proxy_pass 指令时，应该避免在 URI 中指定具体的值，否则 Nginx 将会把请求传递到一个错误的后端服务器或者返回 404 错误。