La última introducción detallada de nginx versión 2023

abajo: https://nginx.org/en/download.html

introducir

Nginx es un servidor web que maneja principalmente la distribución de solicitudes de clientes y servidores, y es un servidor proxy inverso de alto rendimiento.

Proxy directo y proxy inverso

Un proxy es una capa hipotética de servidores entre el servidor y el cliente. El proxy recibirá la solicitud del cliente y la reenviará al servidor, y luego reenviará la respuesta del servidor al cliente.
Reenviar proxy significa que el cliente envía su solicitud al servidor proxy primero y luego reenvía la solicitud al servidor a través del servidor proxy. Nuestra VPN de uso común es un servidor proxy. Para conectarse a sitios web extranjeros, el cliente necesita usar un servidor que pueda conectarse a la red externa como proxy, y el cliente puede conectarse al servidor proxy.

El proxy inverso es diferente del proxy directo: el proxy directo representa al cliente, mientras que el proxy inverso representa al servidor. En el caso de varios servidores distribuidos, para permitir que las direcciones IP a las que accede el cliente sean el mismo sitio web, se requiere un proxy inverso.

Proxy inverso [proxy_pass]
El llamado proxy inverso es muy simple: de hecho, la raíz en la configuración de ubicación se puede reemplazar con proxy_pass . La descripción raíz es un recurso estático que Nginx puede devolver; la descripción proxy_pass es una solicitud dinámica que debe reenviarse, como el proxy a Tomcat. Equilibrio de carga [ascendente] En el proxy inverso anterior, especificamos la dirección de Tomcat a través de proxy_pass. Obviamente, solo podemos especificar una dirección de Tomcat, entonces, ¿qué sucede si queremos especificar varias para lograr el equilibrio de carga? Primero, defina un grupo de Tomcats a través del flujo ascendente y especifique políticas de carga (IPHASH, argumentos ponderados, conexiones mínimas), políticas de verificación de estado (Nginx puede monitorear el estado de este grupo de Tomcats), etc. En segundo lugar, reemplace proxy_pass con el valor especificado por upstream.

configuración básica de nginx.conf

main                                # 全局配置
worker_processes  2;  ## 默认1，一般建议设成CPU核数1-2倍
error_log  logs/error.log; ## 错误日志路径
pid  logs/nginx.pid; ## 进程id

  events {
    
    							# nginx工作模式配置
    # 使用epoll的I/O 模型处理轮询事件。
    # 可以不设置，nginx会根据操作系统选择合适的模型
    use epoll;
    
    # 工作进程的最大连接数量, 默认1024个
    worker_connections  2048;
    
    # http层面的keep-alive超时时间
    keepalive_timeout 60;
    
    # 客户端请求头部的缓冲区大小
    client_header_buffer_size 2k;
  }

http {
    
                                    # http设置
  #引入外部配置，提高可读性，避免单个配置文件过大
  include       mime.types;
  default_type  application/octet-stream;
  
  include mime.types;  # 导入文件扩展名与文件类型映射表
  default_type application/octet-stream;  # 默认文件类型
  
  # 日志格式及access日志路径
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
  '"$request" $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';
  access_log   logs/access.log  main;
  
  #使用高效文件传输，提升传输性能。启用后才能使用tcp_nopush，是指当数据表累积一定大小后才发送，提高了效率。
  sendfile        on;						
  #tcp_nopush     on;
  #设置客户端与服务端请求的超时时间，保证客户端多次请求的时候不会重复建立新的连接，节约资源损耗。
  keepalive_timeout  65;

# ===========================静态文件管理配置======================================
# 开启gzip压缩功能
     gzip on;
     
     # 设置允许压缩的页面最小字节数; 这里表示如果文件小于10k，压缩没有意义.
     gzip_min_length 10k; 
     
     # 设置压缩比率，最小为1，处理速度快，传输速度慢；
     # 9为最大压缩比，处理速度慢，传输速度快; 推荐6
     gzip_comp_level 6; 
     
     # 设置压缩缓冲区大小，此处设置为16个8K内存作为压缩结果缓冲
     gzip_buffers 16 8k; 
     
     # 设置哪些文件需要压缩,一般文本，css和js建议压缩。图片视需要要锁。
     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; 
# ===========================静态文件管理配置======================================

# 正常的正向静态代理
  server {
    
    
    listen       80;		# 监听端口
    server_name  localhost;	# ip、域名

  # 转发动态请求到web应用服务器
    location / {
    
    			# 请求路由映射，匹配拦截
      root   html;		# 请求位置
      index  index.html index.htm; # 首页位置
    }
    location /manage {
    
    
      root /ctp-manage-ui/dist;
      index index.html;
      try_files $uri $uri/ /manage/index.html;
    }

# 注意维护新增微服务，gateway 路由前缀
		location ~* ^/(code|auth|admin|gen|inst|order) {
    
    
		   proxy_pass http://127.0.0.1:9999;
		   #proxy_set_header Host $http_host;
		   proxy_connect_timeout 15s;
		   proxy_send_timeout 15s;
		   proxy_read_timeout 15s;
		   proxy_set_header X-Real-IP $remote_addr;
		   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		   proxy_set_header X-Forwarded-Proto http;
		}

# 使用expires选项开启静态文件缓存，10天有效
     location ~ ^/(images|javascript|js|css|flash|media|static)/  {
    
    
       root    /var/www/big.server.com/static_files;
       expires 10d;
     }
  }

# =============================简单反向代理=============================================

# 超时设置

# 该指令设置与upstream服务器的连接超时时间，这个超时建议不超过75秒。
 proxy_connect_timeout 60;
 
 # 该指令设置应用服务器的响应超时时间，默认60秒。
 proxy_read_timeout 60；
 
 # 设置了发送请求给upstream服务器的超时时间
 proxy_send_timeout 60;
 
 # max_fails设定Nginx与upstream服务器通信的尝试失败的次数。
 # 在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。
 
	server {
    
    
     listen       88;
     server_name  domain2.com www.domain2.com;
     access_log   logs/domain2.access.log  main;
    
     # 转发动态请求到web应用服务器
     location / {
    
    
       proxy_pass      http://127.0.0.1:8000;
       deny 192.24.40.8;  # 拒绝的ip
       allow 192.24.40.6; # 允许的ip   
     }
     
     # 错误页面
     error_page   500 502 503 504  /50x.html;
         location = /50x.html {
    
    
             root   html;
         }
   }

}

# =====================负载均衡 server=================================================
	server {
    
    
     listen          80;
     server_name     big.server.com;
     access_log      logs/big.server.access.log main;
     
     charset utf-8;
     client_max_body_size 10M; # 限制用户上传文件大小，默认1M
 
     location / {
    
    
       # 使用proxy_pass转发请求到通过upstream定义的一组应用服务器
       proxy_pass      http://backend_server;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header Host $http_host;
       proxy_redirect off;
       proxy_set_header X-Real-IP  $remote_addr;
     }
     
   }

# 负载均衡
   upstream backend_server {
    
    
     server 192.168.0.1:8000 weight=5; # weight越高，权重越大
     server 192.168.0.2:8000 weight=1;
     server 192.168.0.3:8000;
     server 192.168.0.4:8001 backup; # 热备
   }

	
}

ubicación

La presencia o ausencia de personajes en el lugar no tiene ningún efecto. Es decir, /homepage/ es lo mismo que /homepage

location = / {
    
    
  # 精确匹配/，主机名后面不能带任何字符串 /
  [ configuration A ]
}
location / {
    
    
  # 匹配所有以 / 开头的请求。
  # 但是如果有更长的同类型的表达式，则选择更长的表达式。
  # 如果有正则表达式可以匹配，则优先匹配正则表达式。
  [ configuration B ]
}
location /documents/ {
    
    
  # 匹配所有以 /documents/ 开头的请求，匹配符合以后，还要继续往下搜索。
  # 但是如果有更长的同类型的表达式，则选择更长的表达式。
  # 如果有正则表达式可以匹配，则优先匹配正则表达式。
  [ configuration C ]
}
location ^~ /images/ {
    
    
  # 匹配所有以 /images/ 开头的表达式，如果匹配成功，则停止匹配查找，停止搜索。
  # 所以，即便有符合的正则表达式location，也不会被使用
  [ configuration D ]
}

Método de coincidencia de URL y prioridad

La prioridad de hacer coincidir las reglas de coincidencia de personajes disminuye paso a paso

• = Coincidencia exacta 1
• ^~ comienza con una cadena 2
• ~ coincidencia regular 3 que distingue entre mayúsculas y minúsculas
• ~* coincidencia regular 4 que no distingue entre mayúsculas y minúsculas
• !~ Discordancia entre mayúsculas y minúsculas de expresiones regulares 5
• !~* No distingue entre mayúsculas y minúsculas expresiones regulares 6
• / Coincidencia universal, cualquier solicitud coincidirá con 7

La diferencia entre raíz y alias

raíz: concatenación (nombre personalizado de ubicación) alias: alias (nombre personalizado de ubicación)
raíz: /Users/admin/www**/h5**/index.html
Cuando no hay prefijo, raíz es lo mismo que alias y raíz es generalmente usado;
Cuando hay un prefijo, si el nombre del prefijo es consistente con la última parte de la ruta del directorio, se debe usar root y se debe usar alias si son inconsistentes.

El alias debe terminar en "/", de lo contrario se considerará como un archivo y no se podrá encontrar el directorio correspondiente; mientras que root es opcional para "/"

Modo historia

location /h5 {
    
    
  root /Users/admin/www/;
  index index.html;
  try_files $uri $uri/ /h5/index.html;
}

Esta sintaxis significa:

• Después de try_files, puede definir múltiples rutas de archivos y la última uri como un salto interno, donde la ruta del archivo se construye junto con el alias y las instrucciones raíz ;
• Se solicitan varios archivos con el primer archivo encontrado ;
• Y el archivo termina en "/", comprobará si el directorio existe;
• Cuando no se pueda encontrar ninguno de los archivos, utilizará la última uri para realizar una solicitud de salto interna .

• interpretación de variables

try_files sintaxis fija

$uri se refiere al archivo de inicio (la ruta detrás de la dirección IP, si es 127.0.0.1/index/a.png, entonces se refiere a index/a.png)
$uri/ se refiere a la carpeta de inicio
/index.html a Solicitud de inicio de dirección ip/index.html

Ejemplo por ejemplo:

• Definí try_files $uri $uri/ /h5/index.html, la raíz es /Users/admin/www;
• Se definen dos archivos, uri y uri, mi ruta de acceso es testhistory.com/h5/about, $uri es /h5/about, luego agrego root ya que no se puede encontrar el directorio raíz y $url/ no puede encontrar el directorio correspondiente;
• Si no se puede encontrar el archivo, saltará a /h5/index.html internamente, lo que equivale a solicitar testhistory.com/h5/index.ht internamente...

try_files $uri $uri/ /index.html;
Intente analizar los siguientes 2 archivos/carpetas (distinga automáticamente si la ruta detrás de la IP es un archivo o una carpeta), uri $uri/$ uri/,
si se resuelve, devuelve el primero,
si no se resuelve, inicia una solicitud y salta a 127.0.0.1/index.html (la ruta debe ser real, de lo contrario se informará un error)

Solicitar reenvío y redirección

# 转发动态请求
server {
    
      
  listen 80;                                                         
  server_name  localhost;                                               
  client_max_body_size 1024M;

  location / {
    
    
    proxy_pass http://localhost:8080;   
    proxy_set_header Host $host:$server_port;
    }
  }

# http请求重定向到https请求
server {
    
    
  listen 80;
  server_name Domain.com;
  return 301 https://$server_name$request_uri;
}

Ya sea para reenviar solicitudes o redirigir, hemos utilizado variables que comienzan con el símbolo $, que son variables globales proporcionadas por Nginx. Sus significados específicos son los siguientes:

$args, 请求中的参数;
 $content_length, HTTP请求信息里的"Content-Length";
 $content_type, 请求信息里的"Content-Type";
 $document_root, 针对当前请求的根路径设置值;
 $document_uri, 与$uri相同;
 $host, 请求信息中的"Host"，如果请求中没有Host行，则等于设置的服务器名;
 $limit_rate, 对连接速率的限制;
 $request_method, 请求的方法，比如"GET"、"POST"等;
 $remote_addr, 客户端地址;
 $remote_port, 客户端端口号;
 $remote_user, 客户端用户名，认证用;
 $request_filename, 当前请求的文件路径名
 $request_body_file,当前请求的文件
 $request_uri, 请求的URI，带查询字符串;
 $query_string, 与$args相同;
 $scheme, 所用的协议，比如http或者是https，比如rewrite ^(.+)$ $scheme://example.com$1 redirect;
 $server_protocol, 请求的协议版本，"HTTP/1.0"或"HTTP/1.1";
 $server_addr, 服务器地址;
 $server_name, 请求到达的服务器名;
 $server_port, 请求到达的服务器端口号;
 $uri, 请求的URI，可能和最初的值有不同，比如经过重定向之类的。

servidor de descarga de archivos

server {
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name  _;
 
 location /download {    
     # 下载文件所在目录
     root /usr/share/nginx/html;
     
     # 开启索引功能
     autoindex on;  
     
     # 关闭计算文件确切大小（单位bytes），只显示大概大小（单位kb、mb、gb）
     autoindex_exact_size off; 
     
     #显示本机时间而非 GMT 时间
     autoindex_localtime on;   
             
     # 对于txt和jpg文件，强制以附件形式下载，不要浏览器直接打开
     if ($request_filename ~* ^.*?\.(txt|jpg|png)$) {
         add_header Content-Disposition 'attachment';
     }
 }
}

Configuración de Nginx HTTPS

# 负载均衡，设置HTTPS
 upstream backend_server {
     server APP_SERVER_1_IP;
     server APP_SERVER_2_IP;
 }
 
 # 禁止未绑定域名访问，比如通过ip地址访问
 # 444:该网页无法正常运作，未发送任何数据
 server {
     listen 80 default_server;
     server_name _;
     return 444;
 }
 
 # HTTP请求重定向至HTTPS请求
 server {
     listen 80;
     listen [::]:80;
     server_name your_domain.com;
     
     location / {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header Host $http_host;
         proxy_redirect off;
         proxy_pass http://backend_server; 
      }
     
     return 301 https://$server_name$request_uri;
 }
 
 server {
     listen 443 ssl http2;
     listen [::]:443 ssl http2;
     server_name your_domain.com;
 
     # ssl证书及密钥路径
     ssl_certificate /path/to/your/fullchain.pem;
     ssl_certificate_key /path/to/your/privkey.pem;
 
     # SSL会话信息
     client_max_body_size 75MB;
     keepalive_timeout 10;
 
     location / {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header Host $http_host;
         proxy_redirect off;
         proxy_pass http://django; # Django+uwsgi不在本机上，使用代理转发
     }
 
 }

equilibrio de carga nginx

Upstream especifica la lista de direcciones del servidor backend, intercepta la solicitud de respuesta en el servidor y reenvía la solicitud a la lista de servidores configurada en Upstream.

// 默认情况下采用的是轮询策略，将所有客户端请求轮询分配给服务端
upstream balanceServer {
    
    
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

server {
    
    
    server_name  fe.server.com;
listen 80;
location /api {
    
    
    proxy_pass http://balanceServer;
        }
}

Sondeo (predeterminado) Cada solicitud se asigna a diferentes servidores backend uno por uno en el tiempo. El peso
del orden representa el peso. El valor predeterminado es 1. Cuanto mayor es el peso, más clientes se asignan. ip_hash Cada solicitud se asigna de acuerdo con el valor hash del IP de acceso, de modo que cada cliente de acceso accederá a un servidor backend fijo, lo que puede resolver el problema de la pérdida de sesión.

comandos comunes de nginx

# 启动nginx
start nginx
# 快速关闭Nginx，可能不保存相关信息，并迅速终止web服务
nginx -s stop
# 平稳关闭Nginx，保存相关信息，有安排的结束web服务
nginx -s quit
# 因改变了Nginx相关配置，需要重新加载配置而重载
nginx -s reload
# 重新打开日志文件
nginx -s reopen
# 为 Nginx 指定一个配置文件，来代替缺省的
nginx -c filename
# 不运行，而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性，并尝试打开配置文件中所引用到的文件
nginx -t
#  显示 nginx 的版本
nginx -v
# 显示 nginx 的版本，编译器版本和配置参数
nginx -V
# 格式换显示 nginx 配置参数
2>&1 nginx -V | xargs -n1
2>&1 nginx -V | xargs -n1 | grep lua

pregunta:

¿Cómo logra Nginx una implementación en caliente?

La implementación en caliente significa que después de modificar el archivo de configuración nginx.conf, el archivo de configuración puede entrar en vigor sin detener Nginx ni interrumpir la solicitud.

Modo maestro-trabajador de Nginx

Después de iniciar Nginx, el servicio Socket se inicia para su monitoreo en el puerto 80. Como se muestra en la figura, ¿

cuál es el papel de Nginx en relación con el proceso maestro y el proceso de trabajo?
Lea y verifique el archivo de configuración nginx.conf; administre el proceso de trabajo; ¿
cuál es la función del proceso de trabajo?
Cada proceso de trabajo mantiene un subproceso (para evitar el cambio de subprocesos) para manejar conexiones y solicitudes; tenga en cuenta que la cantidad de procesos de trabajo está determinada por el archivo de configuración, generalmente relacionado con la cantidad de CPU (favorable para el cambio de procesos), y hay varios Configuraciones Proceso de trabajo.
Solución 1:
después de modificar el archivo de configuración nginx.conf, el maestro del proceso principal es responsable de enviar la información de configuración actualizada al proceso de trabajo. Después de que el proceso de trabajo recibe la información, actualiza la información del hilo dentro del proceso. (Un poco valatile)
Opción 2: (nginx -s reload reload)
Después de modificar el archivo de configuración nginx.conf, regenere un nuevo proceso de trabajo, por supuesto, la solicitud se procesará con la nueva configuración y la nueva solicitud debe entregarse Para el nuevo proceso de trabajo, en cuanto al proceso de trabajo anterior, simplemente elimínelo después de que se procesen las solicitudes anteriores.
¡Nginx utiliza la segunda solución para lograr una implementación en caliente!

¿Qué debo hacer si Nginx no funciona?

Keepalived + Nginx para lograr alta disponibilidad
Keepalived es una solución de alta disponibilidad, que se utiliza principalmente para evitar un punto único de falla del servidor y puede lograr una alta disponibilidad de servicios web cooperando con Nginx
Keepalived + Nginx para lograr alta disponibilidad :
primero: solicitud No acceda a Nginx directamente, primero debe pasar Keepalived (esta es la llamada IP virtual, VIP)
Segundo: Keepalived debería poder monitorear el estado de vida de Nginx (proporcione un script definido por el usuario, verifique periódicamente el estado de Nginx procesar y cambiar el peso, habilitando la conmutación por error de Nginx)

Problema de uso compartido de sesiones distribuidas

solución:

IP_hash de nginx:

  - 这样同一个客户端每次的请求都会被同一个服务器处理，配置简单，不⼊侵应⽤，不需要额外修改代码

• defecto:
  • El servidor se reinicia y se pierde la sesión.
  • Existe riesgo de carga elevada en un solo punto
  • problema de punto único de falla

Uso compartido de sesiones, gestión centralizada de sesiones (redis)

Aviso:

alias: izquierda /: la diferencia entre con y sin

Referencias:

referencia de configuración de nginx

https://zhuanlan.zhihu.com/p/372610935
https://blog.csdn.net/qq_34817440/article/details/121501802

Modelo OSI de siete capas

Modelo de siete capas, también conocido como OSI (Open System Interconnection). El modelo de referencia es un sistema estándar desarrollado por la Organización Internacional de Normalización (ISO) para la interconexión entre computadoras o sistemas de comunicación, generalmente conocido como modelo de referencia OSI o modelo de siete capas.
Es un cuerpo modelo abstracto de siete capas, que incluye no solo una serie de términos o conceptos abstractos, sino también protocolos específicos.

Modelo TCP/IP de cuatro capas

El protocolo TCP/IP se refiere hasta cierto punto a la arquitectura OSI. Hay siete capas en el modelo OSI, pero son complejas, por lo que en el protocolo TCP/IP se simplifican a cuatro capas.