ToB企服应用市场:ToB评测及商务社交产业平台

标题: nginx ngx_http_module(10) 指令详解 [打印本页]

---

作者: 钜形不锈钢水箱    时间: 2025-2-20 21:32
标题: nginx ngx_http_module(10) 指令详解
nginx ngx_http_module(10) 指令详解

nginx 模块目次
nginx 全指令目次
一、目次

1.1 模块简介

• ngx_http_v2_module：HTTP/2支持模块，允许Nginx通过HTTP/2协议与客户端举行通信。HTTP/2带来了许多性能优化，如多路复用、头部压缩和服务器推送等功能，可以明显进步网页加载速率和用户体验。启用此模块通常必要在设置中使用 http2 参数，比方在 listen 指令中指定 ssl http2。
  
• ngx_http_v3_module：HTTP/3支持模块，允许Nginx通过HTTP/3协议（基于QUIC传输协议）与客户端举行通信。HTTP/3旨在解决HTTP/2的一些局限性，特别是在高延迟或不稳定的网络情况下提供更好的性能和可靠性。由于HTTP/3依赖于QUIC协议，因此必要相应的QUIC实现（如Google’s QUIC library）。请注意，该模块大概不是全部Nginx版本的标准部门，且必要特定的编译选项。
  
• ngx_http_xslt_module：XSLT转换模块，允许Nginx在返回XML内容之前对其举行XSLT（可扩展样式语言转换）处理。这对于动态天生HTML页面或以其他格式出现XML数据非常有效。通过这个模块，你可以界说如何将XML文档转换为其他格式（如HTML），并在响应中返回转换后的内容。常用的指令包罗 xslt_stylesheet 用于指定XSLT样式表的位置，以及 xslt_types 用于界说哪些MIME类型应被转换。
  

1.2 指令目次

1.2.1 ngx_http_v2_module

• http2
  
• http2_body_preread_size
  
• http2_chunk_size
  
• http2_idle_timeout
  
• http2_max_concurrent_pushes
  
• http2_max_concurrent_streams
  
• http2_max_field_size
  
• http2_max_header_size
  
• http2_max_requests
  
• http2_push
  
• http2_push_preload
  
• http2_recv_buffer_size
  
• http2_recv_timeout
  

1.2.2 ngx_http_v3_module

• http3
  
• http3_hq
  
• http3_max_concurrent_streams
  
• http3_stream_buffer_size
  
• quic_active_connection_id_limit
  
• quic_bpf
  
• quic_gso
  
• quic_host_key
  
• quic_retry
  

1.2.3 ngx_http_xslt_module

• xml_entities
  
• xslt_last_modified
  
• xslt_param
  
• xslt_string_param
  
• xslt_stylesheet
  
• xslt_types
  

二、解释

2.1 ngx_http_v2_module

ngx_http_v2_module 是 Nginx 的一个模块，用于支持 HTTP/2 协议。HTTP/2 旨在解决 HTTP/1.1 中的一些性能瓶颈，并提供更高效的网络通信。通过 ngx_http_v2_module，Nginx 可以利用 HTTP/2 的特性，如多路复用、头部压缩和服务器推送等，从而提拔网页加载速率和用户体验。
主要功能

• 多路复用：允许在同一个 TCP 连接上同时处理多个哀求和响应，减少连接创建的开销。
  
• 头部压缩：使用 HPACK 算法对 HTTP 头部举行压缩，减少传输数据量。
  
• 服务器推送：允许服务器自动推送资源到客户端，减少额外的哀求往返时间。
  
• 流优先级：允许客户端为不同的哀求设置优先级，优化资源加载次序。
  

常用指令
以下是与 ngx_http_v2_module 模块相关的常用设置指令及其简要阐明：

• http2：在 listen 指令中启用 HTTP/2 支持。
  
• ssl_protocols：指定支持的 SSL/TLS 协议版本，确保兼容性和安全性。
  
• ssl_prefer_server_ciphers：优先使用服务器端的加密套件，增强安全性。
  
• http2_push：用于服务器推送资源。
  
• http2_max_concurrent_streams：设置每个连接的最大并发流数，默认是无穷制。
  

使用示例
以下是一些详细的设置示例，展示如何利用 ngx_http_v2_module 来实现 HTTP/2 支持。
   基本设置
  假设你想在你的网站上启用 HTTP/2 支持：

1. server {
2.     listen 443 ssl http2;  # 启用 HTTP/2 和 SSL
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.com.key;
8.     ssl_protocols TLSv1.2 TLSv1.3;  # 仅启用安全的 TLS 版本
9.     ssl_prefer_server_ciphers on;
11.     location / {
12.         root /var/www/html;
13.         index index.html;
14.     }
15. }

复制代码

在这个例子中：

• listen 443 ssl http2; 启用了 HTTPS 和 HTTP/2 支持。
  
• ssl_certificate 和 ssl_certificate_key 指定了 SSL 证书和私钥文件的路径。
  
• ssl_protocols 设置了支持的 TLS 协议版本，推荐仅启用较新的、更安全的版本。
  
• ssl_prefer_server_ciphers on; 优先使用服务器端的加密套件，进步安全性。
  

   服务器推送
  你可以使用 http2_push 指令来推送资源到客户端，减少额外的哀求往返时间：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.com.key;
8.     ssl_protocols TLSv1.2 TLSv1.3;
9.     ssl_prefer_server_ciphers on;
11.     location / {
12.         root /var/www/html;
13.         index index.html;
15.         # 推送 CSS 文件
16.         http2_push /styles.css;
17.         # 推送 JavaScript 文件
18.         http2_push /script.js;
19.     }
20. }

复制代码

在这个例子中：

• http2_push /styles.css; 和 http2_push /script.js; 指令会在客户端哀求根路径 / 时，自动推送这些资源到客户端，减少额外的哀求。
  

   流优先级
  固然 ngx_http_v2_module 不直接提供流优先级的设置选项，但你可以在前端代码中通过 HTTP/2 的 Priority 头部来设置优先级。比方，在 HTML 中可以这样指定：

1. <link rel="stylesheet" href="/styles.css" importance="high">
2. <script src="/script.js" importance="low"></script>

复制代码

欣赏器会根据这些提示调解资源加载的优先级。
   调解并发流数
  你可以通过设置 http2_max_concurrent_streams 来控制每个连接的最大并发流数：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.com.key;
8.     ssl_protocols TLSv1.2 TLSv1.3;
9.     ssl_prefer_server_ciphers on;
11.     http2_max_concurrent_streams 100;  # 设置最大并发流数为 100
13.     location / {
14.         root /var/www/html;
15.         index index.html;
16.     }
17. }

复制代码

在这个例子中：

• http2_max_concurrent_streams 100; 设置了每个连接的最大并发流数为 100。默认情况下，这个值是无穷制的。
  

注意事项

• 性能考虑：
  
  
  
  • HTTP/2 提供了许多性能改进，但在某些场景下大概会引入额外的复杂性。确保合理设置超时时间和重试机制，避免不须要的延迟和资源浪费。
    
  
  
• 安全性：
  
  
  
  • 确保 SSL 证书的有效性和安全性，定期更新证书。
    
  • 对敏感数据举行加密传输，防止中心人攻击。
    
  
  
• 日记记载：
  
  
  
  • 合理设置日记级别和格式，便于监控和故障排查。特别是注意记载 HTTP/2 相关的错误信息和性能指标。
    
  
  
• 兼容性：
  
  
  
  • 确保客户端欣赏器支持 HTTP/2。大多数当代欣赏器都支持 HTTP/2，但旧版本大概不支持。
    
  • 如果必要支持 HTTP/1.1 客户端，确保 Nginx 设置能够同时处理 HTTP/1.1 和 HTTP/2 哀求。
    
  
  

通过合理设置 ngx_http_v2_module，你可以充实利用 HTTP/2 的优势，明显提拔网页加载速率和用户体验。这对于构建高可用性和高性能的应用系统非常有效。
2.1.1 指令列表

http2

http2 指令用于控制是否启用 HTTP/2 协议。HTTP/2 提供了多项性能优化，如多路复用、头部压缩和服务器推送等。

1. Syntax:        http2 on | off;
2. Default: http2 off;
3. Context: http, server
4. This directive appeared in version 1.25.1.

复制代码

• on：启用 HTTP/2 协议。
  
• off：禁用 HTTP/2 协议，默认行为。
  

案例
   基本用法
  最简单的 http2 用法是启用或禁用 HTTP/2 协议：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location / {
9.         # 启用 HTTP/2 协议
10.         http2 on;
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当用户访问 example.com 时，Nginx 将通过 HTTPS 使用 HTTP/2 协议与客户端通信。
  

注意事项

• SSL/TLS 要求：HTTP/2 必要在 SSL/TLS 上运行，因此必须同时设置 listen 443 ssl http2。
  
• 欣赏器支持：确保目标用户的欣赏器支持 HTTP/2，以充实利用其性能优势。
  

http2_body_preread_size

http2_body_preread_size 指令用于设置在处理哀求体之前预先读取的数据量。这有助于优化大哀求体的处理。

1. Syntax:        http2_body_preread_size size;
2. Default: http2_body_preread_size 64k;
3. Context: http, server
4. This directive appeared in version 1.11.0.

复制代码

• size：在处理哀求体之前预先读取的数据量，默认为 64 KB。
  

案例
   基本用法
  最简单的 http2_body_preread_size 用法是指定预读取数据量：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /upload {
9.         # 设置预读取数据量为 128 KB
10.         http2_body_preread_size 128k;
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当用户上传文件到 /upload 路径时，Nginx 将预先读取 128 KB 的哀求体数据。
  

注意事项

• 性能优化：合理设置预读取数据量可以减少 I/O 操作次数，进步处理服从，特别是在处理大数据量哀求时。
  
• 内存使用：注意不要设置过大的预读取数据量，以免占用过多内存。
  

http2_chunk_size

http2_chunk_size 指令用于设置 HTTP/2 响应分块的巨细。这有助于优化响应传输的服从。

1. Syntax:        http2_chunk_size size;
2. Default: http2_chunk_size 8k;
3. Context: http, server, location

复制代码

• size：HTTP/2 响应分块的巨细，默认为 8 KB。
  

案例
   基本用法
  最简单的 http2_chunk_size 用法是指定响应分块巨细：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /stream {
9.         # 设置响应分块大小为 16 KB
10.         http2_chunk_size 16k;
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当 Nginx 从后端服务器获取响应并传输给客户端时，将使用 16 KB 的分块巨细举行传输。
  

注意事项

• 传输服从：合理的分块巨细可以进步传输服从，特别是在高带宽情况下。
  
• 延迟问题：较小的分块巨细大概会增长传输延迟，尤其是在低带宽情况下。
  

http2_idle_timeout

http2_idle_timeout 指令用于设置 HTTP/2 连接在空闲状态下的超时时间。这有助于管理连接资源，避免长时间占用连接。

1. Syntax:        http2_idle_timeout time;
2. Default: http2_idle_timeout 3m;
3. Context: http, server

复制代码

• time：HTTP/2 连接在空闲状态下的超时时间，默认为 3 分钟。
  

案例
   基本用法
  最简单的 http2_idle_timeout 用法是指定空闲超时时间：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location / {
9.         # 设置空闲超时时间为 5 分钟
10.         http2_idle_timeout 5m;
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当 HTTP/2 连接处于空闲状态超过 5 分钟时，Nginx 将关闭该连接。
  

注意事项

• 资源管理：合理设置空闲超时时间可以有效管理连接资源，避免长时间占用连接。
  
• 用户体验：过短的超时时间大概导致频繁断开连接，影响用户体验，特别是在长轮询或 WebSocket 应用中。
  

http2_max_concurrent_pushes

http2_max_concurrent_pushes 用于设置 HTTP/2 连接中允许的最大并发推送哀求数。这有助于控制服务器在单个连接上可以自动推送的资源数量，避免过多的推送哀求影响性能。

1. Syntax: http2_max_concurrent_pushes number;
2. Default: http2_max_concurrent_pushes 10;
3. Context: http, server
4. This directive appeared in version 1.13.9.

复制代码

• number：指定最大并发推送哀求数，默认值为 10。
  

案例
   基本用法
  最简单的 http2_max_concurrent_pushes 用法是指定最大并发推送哀求数：

1. http {
2.     http2_max_concurrent_pushes 5;  # 设置最大并发推送请求数为 5
4.     server {
5.         listen 443 ssl http2;
6.         server_name example.com;
8.         ssl_certificate /etc/nginx/ssl/example.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example.key;
11.         location / {
12.             root /var/www/html;
13.         }
14.     }
15. }

复制代码

在这个例子中，设置了 http2_max_concurrent_pushes 5，这意味着每个 HTTP/2 连接最多允许 5 个并发推送哀求。
   调解并发推送哀求数
  根据实际需求调解并发推送哀求数：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /low_push/ {
9.         root /var/www/html;
10.         http2_max_concurrent_pushes 3;  # 较少的并发推送请求数
11.     }
13.     location /high_push/ {
14.         root /var/www/html;
15.         http2_max_concurrent_pushes 20;  # 较多的并发推送请求数
16.     }
17. }

复制代码

在这个例子中：

• 对于 /low_push/ 路径下的哀求，设置了较少的并发推送哀求数（3）。
  
• 对于 /high_push/ 路径下的哀求，设置了较多的并发推送哀求数（20）。
  

注意事项

• 性能优化：合理设置并发推送哀求数，确保既能进步页面加载速率，又不会对服务器造成过大压力。
  
• 用户体验：根据页面的实际资源需求和用户的网络状况，调解合适的并发推送哀求数。
  

http2_max_concurrent_streams

http2_max_concurrent_streams 用于设置 HTTP/2 连接中允许的最大并发流数。这有助于控制单个连接上的并发哀求数量，提拔性能并避免资源争用。

1. Syntax: http2_max_concurrent_streams number;
2. Default: http2_max_concurrent_streams 128;
3. Context: http, server

复制代码

• number：指定最大并发流数，默认值为 128。
  

案例
   基本用法
  最简单的 http2_max_concurrent_streams 用法是指定最大并发流数：

1. http {
2.     http2_max_concurrent_streams 64;  # 设置最大并发流数为 64
4.     server {
5.         listen 443 ssl http2;
6.         server_name example.com;
8.         ssl_certificate /etc/nginx/ssl/example.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example.key;
11.         location / {
12.             root /var/www/html;
13.         }
14.     }
15. }

复制代码

在这个例子中，设置了 http2_max_concurrent_streams 64，这意味着每个 HTTP/2 连接最多允许 64 个并发流。
   调解并发流数
  根据实际需求调解并发流数：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /low_streams/ {
9.         root /var/www/html;
10.         http2_max_concurrent_streams 32;  # 较少的并发流数
11.     }
13.     location /high_streams/ {
14.         root /var/www/html;
15.         http2_max_concurrent_streams 256;  # 较多的并发流数
16.     }
17. }

复制代码

在这个例子中：

• 对于 /low_streams/ 路径下的哀求，设置了较少的并发流数（32）。
  
• 对于 /high_streams/ 路径下的哀求，设置了较多的并发流数（256）。
  

注意事项

• 性能优化：合理设置并发流数，确保既能满足应用需求，又不会对服务器造成过大压力。
  
• 负载平衡：根据服务器的实际负载情况，调解合适的并发流数以优化性能。
  

http2_max_field_size

http2_max_field_size 用于设置 HTTP/2 哀求或响应头字段的最大巨细。这有助于防止过大的头字段导致内存溢出或其他问题。

1. Syntax: http2_max_field_size size;
2. Default: http2_max_field_size 4k;
3. Context: http, server

复制代码

• size：指定头字段的最大巨细，默认值为 4KB。
  

案例
   基本用法
  最简单的 http2_max_field_size 用法是指定头字段的最大巨细：

1. http {
2.     http2_max_field_size 8k;  # 设置头字段的最大大小为 8KB
4.     server {
5.         listen 443 ssl http2;
6.         server_name example.com;
8.         ssl_certificate /etc/nginx/ssl/example.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example.key;
11.         location / {
12.             root /var/www/html;
13.         }
14.     }
15. }

复制代码

在这个例子中，设置了 http2_max_field_size 8k，这意味着每个头字段的最大巨细为 8KB。
   调解头字段巨细
  根据实际需求调解头字段巨细：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /small_fields/ {
9.         root /var/www/html;
10.         http2_max_field_size 2k;  # 较小的头字段大小
11.     }
13.     location /large_fields/ {
14.         root /var/www/html;
15.         http2_max_field_size 16k;  # 较大的头字段大小
16.     }
17. }

复制代码

在这个例子中：

• 对于 /small_fields/ 路径下的哀求，设置了较小的头字段巨细（2KB）。
  
• 对于 /large_fields/ 路径下的哀求，设置了较大的头字段巨细（16KB）。
  

注意事项

• 安全性：合理设置头字段巨细，防止恶意客户端发送过大的头字段，导致服务器资源耗尽。
  
• 功能完整性：确保头字段巨细限制不影响正常的功能和业务逻辑。
  

http2_max_header_size

http2_max_header_size 用于设置 HTTP/2 哀求或响应头部的总巨细。这有助于防止过大的头部数据导致内存溢出或其他问题。

1. Syntax: http2_max_header_size size;
2. Default: http2_max_header_size 16k;
3. Context: http, server

复制代码

• size：指定头部的总巨细，默认值为 16KB。
  

案例
   基本用法
  最简单的 http2_max_header_size 用法是指定头部的总巨细：

1. http {
2.     http2_max_header_size 32k;  # 设置头部的总大小为 32KB
4.     server {
5.         listen 443 ssl http2;
6.         server_name example.com;
8.         ssl_certificate /etc/nginx/ssl/example.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example.key;
11.         location / {
12.             root /var/www/html;
13.         }
14.     }
15. }

复制代码

在这个例子中，设置了 http2_max_header_size 32k，这意味着每个哀求或响应头部的总巨细为 32KB。
   调解头部巨细
  根据实际需求调解头部巨细：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     location /small_headers/ {
9.         root /var/www/html;
10.         http2_max_header_size 8k;  # 较小的头部大小
11.     }
13.     location /large_headers/ {
14.         root /var/www/html;
15.         http2_max_header_size 64k;  # 较大的头部大小
16.     }
17. }

复制代码

在这个例子中：

• 对于 /small_headers/ 路径下的哀求，设置了较小的头部巨细（8KB）。
  
• 对于 /large_headers/ 路径下的哀求，设置了较大的头部巨细（64KB）。
  

注意事项

• 安全性：合理设置头部巨细，防止恶意客户端发送过大的头部数据，导致服务器资源耗尽。
  
• 性能优化：确保头部巨细限制不影响正常的哀求处理，并优化服务器性能。
  

http2_max_requests

http2_max_requests 指令用于设置在关闭HTTP/2连接之前可以处理的最大哀求数。这个指令帮助控制HTTP/2连接的复用和资源管理。

1. Syntax:        http2_max_requests number;
2. Default:        http2_max_requests 1000;
3. Context:        http, server
4. This directive appeared in version 1.11.6.

复制代码

• number：指定在关闭HTTP/2连接之前可以处理的最大哀求数，默认值为 1000。
  

案例
   基本用法
  最简单的 http2_max_requests 用法是指定一个详细的哀求数量：

1. http {
2.     server {
3.         listen 443 ssl http2;
4.         server_name example.com;
6.         ssl_certificate /etc/nginx/ssl/example.com.crt;
7.         ssl_certificate_key /etc/nginx/ssl/example.com.key;
9.         location / {
10.             proxy_pass http://backend;
11.             http2_max_requests 500;
12.         }
13.     }
14. }

复制代码

在这个例子中：

• 设置了 http2_max_requests 500，这意味着Nginx将在关闭HTTP/2连接之前处理最多500个哀求。
  

   动态设置不同设置
  你可以根据不同的域名或服务器块动态设置不同的最大哀求数：

1. server {
2.     listen 443 ssl http2;
3.     server_name example1.com;
5.     ssl_certificate /etc/nginx/ssl/example1.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example1.com.key;
8.     location / {
9.         proxy_pass http://backend_example1;
10.         http2_max_requests 500;
11.     }
12. }
14. server {
15.     listen 443 ssl http2;
16.     server_name example2.com;
18.     ssl_certificate /etc/nginx/ssl/example2.com.crt;
19.     ssl_certificate_key /etc/nginx/ssl/example2.com.key;
21.     location / {
22.         proxy_pass http://backend_example2;
23.         http2_max_requests 2000;
24.     }
25. }

复制代码

在这个例子中：

• 对于 example1.com，设置了 http2_max_requests 500。
  
• 对于 example2.com，设置了 http2_max_requests 2000。
  

注意事项

• 资源管理：合理设置最大哀求数，避免过高的数值导致资源耗尽或过低影响性能。
  
• 实用场景：实用于必要准确控制HTTP/2连接复用的应用场景。比方，在高并发网站、API网关等情况中使用。
  
• 调试和监控：如果你遇到连接复用问题，可以检查以下几点：
  
  
  
  • 确保最大哀求数设置合理，并符合你的需求。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  • 使用工具模拟不同负载条件下的哀求举行测试，确保在各种情况下都能正常工作。
    
  
  

http2_push

http2_push 指令用于启用HTTP/2服务器推送功能。这个指令帮助提前推送资源到客户端，减少页面加载时间。

1. Syntax:        http2_push uri | off;
2. Default:        http2_push off;
3. Context:        http, server, location
4. This directive appeared in version 1.13.9.

复制代码

• uri：指定要推送的资源URI。
  
• off：禁用HTTP/2服务器推送（默认值）。
  

案例
   基本用法
  最简单的 http2_push 用法是指定一个详细的资源URI：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.com.key;
8.     location / {
9.         root /var/www/html;
10.         http2_push /css/style.css;
11.     }
12. }

复制代码

在这个例子中：

• 设置了 http2_push /css/style.css，这意味着Nginx将提前推送 /css/style.css 资源给客户端。
  

   动态设置不同设置
  你可以根据不同的域名或服务器块动态设置不同的推送资源：

1. server {
2.     listen 443 ssl http2;
3.     server_name example1.com;
5.     ssl_certificate /etc/nginx/ssl/example1.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example1.com.key;
8.     location / {
9.         root /var/www/html_example1;
10.         http2_push /css/style1.css;
11.     }
12. }
14. server {
15.     listen 443 ssl http2;
16.     server_name example2.com;
18.     ssl_certificate /etc/nginx/ssl/example2.com.crt;
19.     ssl_certificate_key /etc/nginx/ssl/example2.com.key;
21.     location / {
22.         root /var/www/html_example2;
23.         http2_push /css/style2.css;
24.     }
25. }

复制代码

在这个例子中：

• 对于 example1.com，设置了 http2_push /css/style1.css。
  
• 对于 example2.com，设置了 http2_push /css/style2.css。
  

注意事项

• 资源选择：合理选择必要推送的资源，避免不须要的资源推送增长网络负担。
  
• 实用场景：实用于必要优化页面加载速率的应用场景。比方，在提拔用户体验、减少初次渲染时间等方面使用。
  
• 调试和监控：如果你遇到推送资源问题，可以检查以下几点：
  
  
  
  • 确保推送资源设置合理，并符合你的需求。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  • 使用工具模拟不同负载条件下的哀求举行测试，确保在各种情况下都能正常工作。
    
  
  

http2_push_preload

http2_push_preload 指令用于启用对 <link rel="preload"> 标签的支持，并将其转换为HTTP/2服务器推送。这个指令帮助自动推送预加载的资源。

1. Syntax:        http2_push_preload on | off;
2. Default:        http2_push_preload off;
3. Context:        http, server, location
4. This directive appeared in version 1.13.9.

复制代码

• on：启用对 <link rel="preload"> 标签的支持并自动推送资源。
  
• off：禁用此功能（默认值）。
  

案例
   基本用法
  最简单的 http2_push_preload 用法是指定是否启用预加载支持：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.com.key;
8.     location / {
9.         root /var/www/html;
10.         http2_push_preload on;
11.     }
12. }

复制代码

在这个例子中：

• 设置了 http2_push_preload on，这意味着Nginx将自动推送带有 <link rel="preload"> 标签的资源。
  

   动态设置不同设置
  你可以根据不同的域名或服务器块动态设置是否启用预加载支持：

1. server {
2.     listen 443 ssl http2;
3.     server_name example1.com;
5.     ssl_certificate /etc/nginx/ssl/example1.com.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example1.com.key;
8.     location / {
9.         root /var/www/html_example1;
10.         http2_push_preload on;
11.     }
12. }
14. server {
15.     listen 443 ssl http2;
16.     server_name example2.com;
18.     ssl_certificate /etc/nginx/ssl/example2.com.crt;
19.     ssl_certificate_key /etc/nginx/ssl/example2.com.key;
21.     location / {
22.         root /var/www/html_example2;
23.         http2_push_preload off;
24.     }
25. }

复制代码

在这个例子中：

• 对于 example1.com，设置了 http2_push_preload on。
  
• 对于 example2.com，设置了 http2_push_preload off。
  

注意事项

• 自动推送：合理利用 <link rel="preload"> 标签，避免不须要的资源推送增长网络负担。
  
• 实用场景：实用于必要自动推送预加载资源以优化页面加载速率的应用场景。比方，在提拔用户体验、减少初次渲染时间等方面使用。
  
• 调试和监控：如果你遇到预加载资源问题，可以检查以下几点：
  
  
  
  • 确保预加载支持设置合理，并符合你的需求。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  • 使用工具模拟不同负载条件下的哀求举行测试，确保在各种情况下都能正常工作。
    
  
  

http2_recv_buffer_size

http2_recv_buffer_size 指令用于设置接收HTTP/2帧时的缓冲区巨细。这个指令帮助优化HTTP/2协议的数据传输服从。

1. Syntax:        http2_recv_buffer_size size;
2. Default:        http2_recv_buffer_size 256k;
3. Context:        http

复制代码

• size：指定接收缓冲区的巨细，默认值为 256k。
  

案例
   基本用法
  最简单的 http2_recv_buffer_size 用法是指定一个详细的缓冲区巨细：

1. http {
2.     http2_recv_buffer_size 512k;
4.     server {
5.         listen 443 ssl http2;
6.         server_name example.com;
8.         ssl_certificate /etc/nginx/ssl/example.com.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example.com.key;
11.         location / {
12.             root /var/www/html;
13.         }
14.     }
15. }

复制代码

在这个例子中：

• 设置了 http2_recv_buffer_size 512k，这意味着Nginx将使用512KB的接收缓冲区来处理HTTP/2帧。
  

   动态设置不同设置
  由于 http2_recv_buffer_size 只能在 http 上下文中设置，因此不能针对不同的服务器块单独设置。你可以在主设置文件中统一设置：

1. http {
2.     http2_recv_buffer_size 1m;
4.     server {
5.         listen 443 ssl http2;
6.         server_name example1.com;
8.         ssl_certificate /etc/nginx/ssl/example1.com.crt;
9.         ssl_certificate_key /etc/nginx/ssl/example1.com.key;
11.         location / {
12.             root /var/www/html_example1;
13.         }
14.     }
16.     server {
17.         listen 443 ssl http2;
18.         server_name example2.com;
20.         ssl_certificate /etc/nginx/ssl/example2.com.crt;
21.         ssl_certificate_key /etc/nginx/ssl/example2.com.key;
23.         location / {
24.             root /var/www/html_example2;
25.         }
26.     }
27. }

复制代码

在这个例子中：

• 全部服务器块都将使用 http2_recv_buffer_size 1m 的设置。
  

注意事项

• 性能与资源平衡：合理设置接收缓冲区巨细，避免过大导致内存占用过高或过小影响数据传输服从。
  
• 实用场景：实用于必要优化HTTP/2协议数据传输服从的应用场景。比方，在高并发网站、实时应用等情况中使用。
  
• 调试和监控：如果你遇到接收缓冲区问题，可以检查以下几点：
  
  
  
  • 确保接收缓冲区巨细设置合理，并符合你的需求。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  • 使用工具模拟不同负载条件下的哀求举行测试，确保在各种情况下都能正常工作。
    
  
  

http2_recv_timeout

http2_recv_timeout 指令用于设置 HTTP/2 连接中接收数据的超时时间。

1. Syntax:        http2_recv_timeout time;
2. Default:        http2_recv_timeout 30s;
3. Context:        http, server

复制代码

• time：指定超时时间，默认值为 30 秒。
  

案例
   基本用法
  最简单的 http2_recv_timeout 用法是指定超时时间：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     # 设置 HTTP/2 接收数据的超时时间为 60 秒
9.     http2_recv_timeout 60s;
11.     location / {
12.         proxy_pass http://backend.example.com;
13.     }
14. }

复制代码

在这个例子中：

• 设置了 HTTP/2 接收数据的超时时间为 60 秒。
  

   使用默认值
  你可以选择使用默认值（30 秒）：

1. server {
2.     listen 443 ssl http2;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     # 使用默认的超时时间（30 秒）
9.     http2_recv_timeout 30s;
11.     location / {
12.         proxy_pass http://backend.example.com;
13.     }
14. }

复制代码

在这个例子中：

• 使用默认的超时时间（30 秒）。
  

注意事项

• 性能优化：合理设置超时时间可以避免长时间未响应的连接占用资源，但过短的超时时间大概导致正常哀求被中断。
  
• 实用场景：实用于必要控制 HTTP/2 连接中接收数据超时的应用场景。比方，在高流量网站或必要处理大量并发哀求的情况中，得当调解超时时间可以进步系统的稳定性和性能。
  
• 调试和监控：如果你遇到超时问题，可以检查以下几点：
  
  
  
  • 确保数值设置合理，不会导致过多的超时或过早中断。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  
  

2.2 ngx_http_v3_module

ngx_http_v3_module 是 Nginx 的一个模块，用于支持 HTTP/3 协议。HTTP/3 是基于 QUIC（Quick UDP Internet Connections）传输协议的新一代 HTTP 协议，旨在进步网络连接的性能和可靠性，特别是在高延迟和不稳定的网络情况中。
主要功能

• QUIC 支持：通过 QUIC 协议实现更快的连接创建和更高效的传输。
  
• 0-RTT 连接规复：允许客户端在重新连接时跳过握手过程，从而减少延迟。
  
• 多路复用：多个哀求可以共享同一个连接，避免了队头阻塞问题。
  
• 增强的安全性：默认使用 TLS 1.3 加密，确保数据传输的安全性。
  

设置要求
为了启用 ngx_http_v3_module 模块，你必要满足以下条件：

• Nginx 版本：确保你使用的是支持 HTTP/3 的 Nginx 版本（比方 Nginx 1.19.7 及以上版本）。
  
• OpenSSL 版本：必要 OpenSSL 1.1.1 或更高版本来支持 QUIC 和 TLS 1.3。
  
• BoringSSL：Nginx 对 HTTP/3 的支持依赖于 BoringSSL 库，因此你大概必要下载并编译 BoringSSL。
  

常用指令

• listen
  
• 用途：指定服务器监听的端口和协议类型。
  
• 示例：
  
  1. listen 443 quic reuseport;

  复制代码
• http3
  
• 用途：启用 HTTP/3 支持。
  
• 示例：
  
  1. http3 on;

  复制代码
• quic
  
• 用途：设置 QUIC 相关参数。
  
• 示例：
  
  1. quic {
  2.     max_idle_timeout 60s;
  3.     initial_max_data 1048576;
  4. }

  复制代码

使用示例
以下是一些简化的设置示例，展示了如何使用 ngx_http_v3_module 来启用 HTTP/3 支持。
   基本 HTTP/3 设置
  假设你盼望为你的网站启用 HTTP/3 支持：

1. server {
2.     listen 443 quic reuseport ssl http2;
3.     listen [::]:443 quic reuseport ssl http2;
5.     server_name example.com;
7.     ssl_certificate /etc/nginx/ssl/example_com.crt;
8.     ssl_certificate_key /etc/nginx/ssl/example_com.key;
10.     ssl_protocols TLSv1.2 TLSv1.3;
11.     ssl_ciphers HIGH:!aNULL:!MD5;
13.     location / {
14.         root /var/www/html;
15.         index index.html index.htm;
16.     }
17. }

复制代码

在这个例子中：

• listen 443 quic reuseport ssl http2; 启用了 HTTP/3、HTTP/2 和 SSL/TLS 支持。
  
• ssl_certificate 和 ssl_certificate_key 分别指定了服务器证书和私钥文件的路径。
  
• ssl_protocols 和 ssl_ciphers 设置了支持的协议和加密套件。
  

   详细设置 QUIC 参数
  你可以进一步设置 QUIC 相关参数以优化性能：

1. server {
2.     listen 443 quic reuseport ssl http2;
3.     listen [::]:443 quic reuseport ssl http2;
5.     server_name example.com;
7.     ssl_certificate /etc/nginx/ssl/example_com.crt;
8.     ssl_certificate_key /etc/nginx/ssl/example_com.key;
10.     ssl_protocols TLSv1.2 TLSv1.3;
11.     ssl_ciphers HIGH:!aNULL:!MD5;
13.     quic {
14.         max_idle_timeout 60s;
15.         initial_max_data 1048576;
16.         initial_max_stream_data_bidi_local 262144;
17.         initial_max_stream_data_bidi_remote 262144;
18.         initial_max_stream_data_uni 262144;
19.         initial_max_streams_bidi 100;
20.         initial_max_streams_uni 100;
21.         ack_delay_exponent 3;
22.         max_ack_delay 25ms;
23.     }
25.     location / {
26.         root /var/www/html;
27.         index index.html index.htm;
28.     }
29. }

复制代码

在这个例子中：

• quic 块界说了多个 QUIC 参数，包罗最大空闲超时时间、初始最大数据量等。
  

   逼迫重定向 HTTP 到 HTTPS
  为了确保全部哀求都通过 HTTPS 处理，可以设置 HTTP 哀求自动重定向到 HTTPS：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     # 强制重定向到 HTTPS
6.     return 301 https://$host$request_uri;
7. }
9. server {
10.     listen 443 quic reuseport ssl http2;
11.     listen [::]:443 quic reuseport ssl http2;
13.     server_name example.com;
15.     ssl_certificate /etc/nginx/ssl/example_com.crt;
16.     ssl_certificate_key /etc/nginx/ssl/example_com.key;
18.     ssl_protocols TLSv1.2 TLSv1.3;
19.     ssl_ciphers HIGH:!aNULL:!MD5;
21.     quic {
22.         max_idle_timeout 60s;
23.         initial_max_data 1048576;
24.     }
26.     location / {
27.         root /var/www/html;
28.         index index.html index.htm;
29.     }
30. }

复制代码

在这个例子中：

• 第一个 server 块监听 HTTP 端口 80，并将全部哀求重定向到 HTTPS。
  
• 第二个 server 块监听 HTTPS 端口 443，并设置了 HTTP/3 和 QUIC 参数。
  

注意事项

• BoringSSL 库：Nginx 对 HTTP/3 的支持依赖于 BoringSSL 库，而不是标准的 OpenSSL。你必要从 BoringSSL GitHub 堆栈 下载并编译 BoringSSL。
  编译步骤如下：
  
  
  
  • 克隆 BoringSSL 堆栈：
    
    1. git clone https://github.com/google/boringssl.git
    2. cd boringssl

    复制代码
  • 编译 BoringSSL：
    
    1. mkdir build
    2. cd build
    3. cmake ..
    4. make

    复制代码
  • 下载并编译 Nginx，使用 BoringSSL 而不是 OpenSSL：
    
    1. wget http://nginx.org/download/nginx-1.21.4.tar.gz
    2. tar -zxvf nginx-1.21.4.tar.gz
    3. cd nginx-1.21.4
    5. ./configure --with-http_v3_module --with-cc-opt="-I/path/to/boringssl/include" --with-ld-opt="-L/path/to/boringssl/build/ssl -L/path/to/boringssl/build/crypto"
    6. make
    7. sudo make install

    复制代码
  
  
• 防火墙设置：确保防火墙允许 UDP 流量，由于 QUIC 协议基于 UDP。
  
  1. sudo ufw allow 443/udp

  复制代码
• 日记记载：为了方便调试和监控，发起启用详细的日记记载，特别是在设置 HTTP/3 时。
  
  1. error_log /var/log/nginx/error.log warn;
  2. access_log /var/log/nginx/access.log main;

  复制代码
• 测试设置：在生产情况中摆设前，务必举行充实的测试，确保 HTTP/3 设置正确无误。可以使用工具如 Qualys SSL Labs 来评估你的 SSL/TLS 设置是否支持 HTTP/3。
  

通过合理设置 ngx_http_v3_module，你可以为你的网站提供更快、更可靠的连接体验。
2.2.1 指令列表

http3

http3 指令用于启用或禁用 HTTP/3 支持。

1. Syntax:        http3 on | off;Default:        http3 on;
2. Context:        http, server

复制代码

• on：启用 HTTP/3 支持。
  
• off：禁用 HTTP/3 支持。
  

案例
   启用 HTTP/3
  最简单的 http3 用法是启用 HTTP/3 支持：

1. server {    listen 443 ssl http3;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.crt;    ssl_certificate_key /etc/nginx/ssl/example.key;    # 启用 HTTP/3 支持    http3 on;
2.     location / {        proxy_pass http://backend.example.com;    }}

复制代码

在这个例子中：

• 启用了 HTTP/3 支持。
  

   禁用 HTTP/3
  你可以选择禁用 HTTP/3 支持：

1. server {
2.     listen 443 ssl;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     # 禁用 HTTP/3 支持
9.     http3 off;
11.     location / {
12.         proxy_pass http://backend.example.com;
13.     }
14. }

复制代码

在这个例子中：

• 禁用了 HTTP/3 支持。
  

注意事项

• 兼容性：确保客户端支持 HTTP/3 协议，否则大概会导致连接失败。
  
• 实用场景：实用于必要利用 HTTP/3 提供的性能优势的应用场景。比方，在高延迟或不稳定网络情况中，HTTP/3 可以明显进步页面加载速率和用户体验。
  
• 调试和监控：如果你遇到 HTTP/3 支持问题，可以检查以下几点：
  
  
  
  • 确保 Nginx 设置正确，而且服务器支持 QUIC 协议。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  
  

http3_hq

http3_hq 指令用于启用或禁用 HTTP/3 的 HQ（Header Compression）功能。

1. Syntax:        http3_hq on | off;
2. Default:        http3_hq off;
3. Context:        http, server

复制代码

• on：启用 HTTP/3 的 HQ 功能。
  
• off：禁用 HTTP/3 的 HQ 功能。
  

案例
   启用 HQ 功能
  最简单的 http3_hq 用法是启用 HQ 功能：

1. server {    listen 443 ssl http3;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.crt;    ssl_certificate_key /etc/nginx/ssl/example.key;    # 启用 HTTP/3 支持    http3 on;
2.     # 启用 HTTP/3 的 HQ 功能    http3_hq on;    location / {        proxy_pass http://backend.example.com;    }}

复制代码

在这个例子中：

• 启用了 HTTP/3 的 HQ 功能。
  

   禁用 HQ 功能
  你可以选择禁用 HQ 功能：

1. server {    listen 443 ssl http3;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.crt;    ssl_certificate_key /etc/nginx/ssl/example.key;    # 启用 HTTP/3 支持    http3 on;
2.     # 禁用 HTTP/3 的 HQ 功能    http3_hq off;    location / {        proxy_pass http://backend.example.com;    }}

复制代码

在这个例子中：

• 禁用了 HTTP/3 的 HQ 功能（默认值）。
  

注意事项

• 性能优化：启用 HQ 功能可以减少传输的数据量，但在某些情况下大概会增长 CPU 负载。根据实际需求举行权衡。
  
• 实用场景：实用于必要减少传输数据量的应用场景。比方，在移动设备或低带宽网络情况中，启用 HQ 功能可以明显进步传输服从。
  
• 调试和监控：如果你遇到 HQ 功能问题，可以检查以下几点：
  
  
  
  • 确保 Nginx 设置正确，而且服务器支持 HQ 功能。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  
  

http3_max_concurrent_streams

http3_max_concurrent_streams 指令用于设置 HTTP/3 连接中最大并发流的数量。

1. Syntax:        http3_max_concurrent_streams number;
2. Default:        http3_max_concurrent_streams 128;
3. Context:        http, server

复制代码

• number：指定最大并发流的数量，默认值为 128。
  

案例
   基本用法
  最简单的 http3_max_concurrent_streams 用法是指定最大并发流的数量：

1. server {    listen 443 ssl http3;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.crt;    ssl_certificate_key /etc/nginx/ssl/example.key;    # 启用 HTTP/3 支持    http3 on;
2.     # 设置最大并发流数量为 256    http3_max_concurrent_streams 256;    location / {        proxy_pass http://backend.example.com;    }}

复制代码

在这个例子中：

• 设置了最大并发流数量为 256。
  

   使用默认值
  你可以选择使用默认值（128）：

1. server {    listen 443 ssl http3;    server_name example.com;    ssl_certificate /etc/nginx/ssl/example.crt;    ssl_certificate_key /etc/nginx/ssl/example.key;    # 启用 HTTP/3 支持    http3 on;
2.     # 使用默认的最大并发流数量（128）    http3_max_concurrent_streams 128;    location / {        proxy_pass http://backend.example.com;    }}

复制代码

在这个例子中：

• 使用默认的最大并发流数量（128）。
  

注意事项

• 性能优化：合理设置最大并发流数量可以平衡资源使用和性能。过高的并发流数量大概导致资源耗尽，而过低则大概限制性能。
  
• 实用场景：实用于必要控制 HTTP/3 连接中并发流数量的应用场景。比方，在高并发情况下，得当调解并发流数量可以进步系统性能和稳定性。
  
• 调试和监控：如果你遇到并发流数量问题，可以检查以下几点：
  
  
  
  • 确保数值设置合理，不会导致过多的并发流或资源耗尽。
    
  • 查看Nginx的日记文件，确认是否有与此相关的警告或错误信息。
    
  
  

http3_stream_buffer_size

http3_stream_buffer_size 指令用于设置 HTTP/3 流的缓冲区巨细。这影响着数据在传输过程中的缓冲服从和性能，特别是在高并发场景下。

1. Syntax:        http3_stream_buffer_size size;
2. Default:        http3_stream_buffer_size 64k;
3. Context:        http, server

复制代码

• size：指定缓冲区巨细，默认值为 64k（即64KB）。
  

案例
   设置较大的缓冲区
  假设我们盼望增长 HTTP/3 流的缓冲区巨细以进步处理大文件时的性能：

1. http {
2.     server {
3.         listen 80 http3;
4.         server_name example.com;
6.         # 增加 HTTP/3 流的缓冲区大小到 128KB
7.         http3_stream_buffer_size 128k;
8.     }
9. }

复制代码

  使用默认的缓冲区巨细
  如果我们盼望使用默认的64KB缓冲区巨细：

1. http {
2.     server {
3.         listen 80 http3;
4.         server_name example.com;
6.         # 使用默认的 64KB 缓冲区大小
7.         http3_stream_buffer_size 64k;
8.     }
9. }

复制代码

注意事项

• 性能优化：得当增长缓冲区巨细可以进步大文件传输的性能，但过大的缓冲区大概会导致内存占用过高。
  
• 资源管理：根据实际应用场景调解缓冲区巨细，确保系统资源的有效利用。
  

quic_active_connection_id_limit

quic_active_connection_id_limit 指令用于设置 QUIC 协议中允许的活动连接 ID 的最大数量。这有助于控制服务器端的资源消耗，并防止滥用。

1. Syntax:        quic_active_connection_id_limit number;
2. Default:        quic_active_connection_id_limit 2;
3. Context:        http, server

复制代码

• number：指定允许的最大活动连接 ID 数量，默认值为 2。
  

案例
   设置较大的连接 ID 限制
  假设我们盼望增长允许的活动连接 ID 数量以支持更多的并发连接：

1. http {
2.     server {
3.         listen 80 quic;
4.         server_name example.com;
6.         # 增加允许的活动连接 ID 数量到 5
7.         quic_active_connection_id_limit 5;
8.     }
9. }

复制代码

  使用默认的连接 ID 限制
  如果我们盼望使用默认的2个活动连接 ID：

1. http {
2.     server {
3.         listen 80 quic;
4.         server_name example.com;
6.         # 使用默认的 2 个活动连接 ID
7.         quic_active_connection_id_limit 2;
8.     }
9. }

复制代码

注意事项

• 资源管理：增长活动连接 ID 数量可以支持更多并发连接，但也必要相应增长服务器资源。
  
• 安全性：合理设置连接 ID 限制，避免被滥用导致资源耗尽。
  

quic_bpf

quic_bpf 指令用于启用或禁用 BPF（Berkeley Packet Filter）支持，主要用于高级网络调试和监控。BPF 可以帮助捕获和分析网络流量，但在大多数情况下不必要启用。

1. Syntax:        quic_bpf on | off;
2. Default:        quic_bpf off;
3. Context:        main

复制代码

• on：启用 BPF 支持。
  
• off（默认）：禁用 BPF 支持。
  

案例
   启用 BPF 支持
  假设我们必要启用 BPF 支持举行高级网络调试：

1. main {
2.     # 启用 BPF 支持
3.     quic_bpf on;
4. }

复制代码

  禁用 BPF 支持
  如果我们不必要 BPF 支持：

1. main {
2.     # 禁用 BPF 支持（默认行为）
3.     quic_bpf off;
4. }

复制代码

注意事项

• 调试工具：BPF 主要用于高级调试和监控，平常应用通常不必要启用。
  
• 性能影响：启用 BPF 大概会对性能产生一定影响，需审慎使用。
  

quic_gso

quic_gso 指令用于启用或禁用 GSO（Generic Segmentation Offload）支持。GSO 是一种网络优化技能，通过减少内核中断次数来进步网络性能。

1. Syntax:        quic_gso on | off;
2. Default:        quic_gso off;
3. Context:        http, server

复制代码

• on：启用 GSO 支持。
  
• off（默认）：禁用 GSO 支持。
  

案例
   启用 GSO 支持
  假设我们盼望启用 GSO 支持以进步网络性能：

1. http {
2.     server {
3.         listen 80 quic;
4.         server_name example.com;
6.         # 启用 GSO 支持
7.         quic_gso on;
8.     }
9. }

复制代码

  禁用 GSO 支持
  如果我们不盼望启用 GSO 支持：

1. http {
2.     server {
3.         listen 80 quic;
4.         server_name example.com;
6.         # 禁用 GSO 支持（默认行为）
7.         quic_gso off;
8.     }
9. }

复制代码

注意事项

• 性能优化：GSO 可以明显进步网络性能，尤其是在高吞吐量场景下。
  
• 硬件兼容性：确保服务器硬件支持 GSO，否则大概无法得到预期的性能提拔。
  

quic_host_key

quic_host_key 指令用于指定 QUIC 协议使用的主秘密钥文件。QUIC 是一种基于 UDP 的传输协议，旨在进步网络连接的安全性和性能。

1. Syntax:        quic_host_key file;
2. Default: —
3. Context: http, server

复制代码

• file：QUIC 协议使用的主秘密钥文件路径。
  

案例
   基本用法
  最简单的 quic_host_key 用法是指定主秘密钥文件路径：

1. server {
2.     listen 443 quic ssl;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     # 指定 QUIC 主机密钥文件路径
9.     quic_host_key /etc/nginx/ssl/quic_host_key.pem;
11.     location / {
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当 Nginx 使用 QUIC 协议与客户端通信时，将使用 /etc/nginx/ssl/quic_host_key.pem 文件中的密钥举行加密和身份验证。
  

注意事项

• 安全性：确保主秘密钥文件的安全性，防止未经授权的访问。
  
• 设置要求：确保正确天生并设置了主秘密钥文件，以支持 QUIC 协议的安全通信。
  

quic_retry

quic_retry 指令用于控制是否启用 QUIC 协议的重试机制。重试机制有助于防止中心人攻击（MITM）和其他潜伏的安全威胁。

1. Syntax:        quic_retry on | off;
2. Default: quic_retry off;
3. Context: http, server

复制代码

• on：启用 QUIC 协议的重试机制。
  
• off：禁用 QUIC 协议的重试机制，默认行为。
  

案例
   基本用法
  最简单的 quic_retry 用法是启用或禁用重试机制：

1. server {
2.     listen 443 quic ssl;
3.     server_name example.com;
5.     ssl_certificate /etc/nginx/ssl/example.crt;
6.     ssl_certificate_key /etc/nginx/ssl/example.key;
8.     # 启用 QUIC 重试机制
9.     quic_retry on;
11.     location / {
12.         proxy_pass http://backend;
13.     }
14. }

复制代码

在这个例子中：

• 当客户端实验通过 QUIC 协议与 Nginx 举行通信时，Nginx 将启用重试机制来增强安全性。
  

注意事项

• 安全性：启用重试机制可以防止某些类型的攻击，但大概会增长初始连接的时间。
  
• 性能考虑：在高并发情况下，频繁的重试大概会增长服务器负载。
  

2.3 ngx_http_xslt_module

ngx_http_xslt_module 是 Nginx 的一个模块，用于在将 XML 数据发送给客户端之前，使用 XSLT（Extensible Stylesheet Language Transformations）样式表对 XML 举行转换。这个模块使得 Nginx 能够作为一个轻量级的中心层，在处理 XML 数据时举行格式化和转换，从而天生更易读或更适合特定应用需求的输出。
主要功能

• XML 转换：通过 XSLT 样式表对 XML 数据举行转换。
  
• 动态加载 XSLT 样式表：可以根据哀求的不同动态选择不同的 XSLT 样式表。
  
• 支持参数通报：可以将哀求参数通报给 XSLT 样式表，以便在转换过程中使用这些参数。
  

常用指令
以下是 ngx_http_xslt_module 中一些常用的指令及其阐明：

• xslt_stylesheet: 界说用于转换 XML 数据的 XSLT 样式表文件路径。
  
• xslt_string: 直接在设置文件中界说 XSLT 样式表内容（通常不推荐，由于样式表大概较长且难以维护）。
  
• xslt_types: 指定哪些 MIME 类型的响应必要举行 XSLT 转换，默认是 text/xml。
  
• xslt_parameters: 将哀求参数通报给 XSLT 样式表。可以在样式表中使用这些参数来控制转换逻辑。
  

使用示例
以下是一些详细的设置示例，展示了如何使用 ngx_http_xslt_module 对 XML 数据举行转换。
   基本设置
  假设你有一个 XML 文件，并盼望使用 XSLT 样式表对其举行转换：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /xml {
6.         # 设置根目录
7.         root /var/www/data;
9.         # 启用 XSLT 转换
10.         xslt_stylesheet /etc/nginx/stylesheet.xsl;
12.         # 设置需要进行 XSLT 转换的 MIME 类型
13.         xslt_types application/xml;
14.     }
15. }

复制代码

在这个例子中：

• xslt_stylesheet /etc/nginx/stylesheet.xsl; 指定了用于转换 XML 数据的 XSLT 样式表文件路径。
  
• xslt_types application/xml; 指定了必要举行 XSLT 转换的 MIME 类型为 application/xml。
  

   动态加载 XSLT 样式表
  你可以根据哀求的不同动态选择不同的 XSLT 样式表：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /xml {
6.         # 设置根目录
7.         root /var/www/data;
9.         # 根据请求参数选择不同的 XSLT 样式表
10.         if ($arg_style = "mobile") {
11.             xslt_stylesheet /etc/nginx/mobile.xsl;
12.         }
13.         if ($arg_style = "desktop") {
14.             xslt_stylesheet /etc/nginx/desktop.xsl;
15.         }
17.         # 设置需要进行 XSLT 转换的 MIME 类型
18.         xslt_types application/xml;
19.     }
20. }

复制代码

在这个例子中：

• if ($arg_style = "mobile") { ... } 和 if ($arg_style = "desktop") { ... } 根据哀求参数 style 的值动态选择不同的 XSLT 样式表。
  

   通报参数到 XSLT 样式表
  你可以将哀求参数通报给 XSLT 样式表，以便在转换过程中使用这些参数：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /xml {
6.         # 设置根目录
7.         root /var/www/data;
9.         # 启用 XSLT 转换并传递参数
10.         xslt_stylesheet /etc/nginx/stylesheet.xsl;
11.         xslt_parameters $lang $theme;
13.         # 设置需要进行 XSLT 转换的 MIME 类型
14.         xslt_types application/xml;
15.     }
16. }

复制代码

在这个例子中：

• xslt_parameters $lang $theme; 将哀求参数 lang 和 theme 通报给 XSLT 样式表。在 XSLT 样式表中，可以通过 $lang 和 $theme 变量访问这些参数。
  

注意事项

• 性能考虑：XSLT 转换大概会消耗一定的计算资源，特别是在高并发情况下。发起对 XSLT 样式表举行优化，避免复杂的转换逻辑。
  
• 缓存机制：为了进步性能，可以结合使用缓存机制（如 proxy_cache 或 fastcgi_cache），以减少重复的 XSLT 转换操作。
  
• 安全性：确保 XSLT 样式表的内容是安全的，防止恶意代码注入。可以使用静态样式表文件而不是动态天生的样式表，以降低风险。
  
• 测试验证：在摆设之前举行全面测试，确保全部设置按预期工作，并检查是否有任何潜伏的问题（如转换错误、样式表未正确加载等）。
  

2.3.1 指令列表

xml_entities

xml_entities 指令用于指定 XML 实体文件的路径。XML 实体文件界说了自界说实体，这些实体可以在处理 XML 文档时被引用。

1. Syntax:        xml_entities path;
2. Default: —
3. Context: http, server, location

复制代码

• path：XML 实体文件的路径。
  

案例
   基本用法
  最简单的 xml_entities 用法是指定 XML 实体文件路径：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /xml {
6.         # 指定 XML 实体文件路径
7.         xml_entities /etc/nginx/xml/entities.dtd;
9.         # 处理 XML 请求
10.         proxy_pass http://backend;
11.     }
12. }

复制代码

在这个例子中：

• 当 Nginx 处理 /xml 路径下的哀求时，将使用 /etc/nginx/xml/entities.dtd 文件中的界说来分析和处理 XML 实体。
  

注意事项

• 文件路径：确保指定的 XML 实体文件路径存在而且 Nginx 对其具有读权限。
  
• 安全性：避免加载不受信托的 XML 实体文件，以防止潜伏的安全风险。
  

xslt_last_modified

xslt_last_modified 指令用于控制是否启用 XSLT 输出的末了修改时间头信息。这有助于优化缓存计谋和进步性能。

1. Syntax:        xslt_last_modified on | off;
2. Default: xslt_last_modified off;
3. Context: http, server, location
4. This directive appeared in version 1.5.1.

复制代码

• on：启用 XSLT 输出的末了修改时间头信息。
  
• off：禁用 XSLT 输出的末了修改时间头信息，默认行为。
  

案例
   基本用法
  最简单的 xslt_last_modified 用法是启用或禁用末了修改时间头信息：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /xml-transform {
6.         # 启用 XSLT 输出的最后修改时间头信息
7.         xslt_last_modified on;
9.         # 指定 XSLT 样式表
10.         xslt_stylesheet /etc/nginx/xslt/style.xsl;
12.         # 处理 XML 请求并应用 XSLT 转换
13.         proxy_pass http://backend;
14.     }
15. }

复制代码

在这个例子中：

• 当 Nginx 处理 /xml-transform 路径下的哀求并应用 XSLT 转换时，会包罗 Last-Modified 响应头，指示输出内容的末了修改时间。
  

注意事项

• 缓存优化：启用 xslt_last_modified 可以帮助客户端和代理服务器更好地管理缓存，减少不须要的哀求。
  
• 响应头正确性：确保 Last-Modified 响应头的值正确反映实际的末了修改时间，以免误导客户端缓存计谋。
  

xslt_param

xslt_param 用于在 XSLT 转换过程中通报参数给 XSLT 样式表。这允许你在转换 XML 数据时动态地向样式表通报值，从而实现更灵活的转换逻辑。

1. Syntax: xslt_param parameter value;
2. Default: —
3. Context: http, server, location
4. This directive appeared in version 1.1.18.

复制代码

• parameter：指定要通报给 XSLT 样式表的参数名称。
  
• value：指定参数的值。
  

案例
   基本用法
  最简单的 xslt_param 用法是指定参数及其值：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_param title "Example Title";  # 传递参数 'title' 及其值 'Example Title'
9.     }
10. }

复制代码

在这个例子中，设置了 xslt_param title "Example Title"，这意味着在实行 XSLT 转换时，将通报一个名为 title 的参数，并将其值设置为 "Example Title"。
   多个参数
  根据实际需求通报多个参数：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_param title "Example Title";  # 传递第一个参数
9.         xslt_param author "John Doe";      # 传递第二个参数
10.     }
11. }

复制代码

在这个例子中，通报了两个参数：title 和 author。
注意事项

• 灵活性：通过通报参数，可以使 XSLT 样式表更加通用和灵活。
  
• 数据安全：确保通报的参数值是安全的，避免注入攻击等安全问题。
  

xslt_string_param

xslt_string_param 与 xslt_param 类似，但专门用于通报字符串类型的参数。它允许你明确指定通报的参数类型为字符串。

1. Syntax: xslt_string_param parameter value;
2. Default: —
3. Context: http, server, location
4. This directive appeared in version 1.1.18.

复制代码

• parameter：指定要通报给 XSLT 样式表的参数名称。
  
• value：指定参数的值（字符串类型）。
  

案例
   基本用法
  最简单的 xslt_string_param 用法是指定参数及其字符串值：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_string_param title "Example Title";  # 传递字符串参数 'title'
9.     }
10. }

复制代码

在这个例子中，设置了 xslt_string_param title "Example Title"，这意味着在实行 XSLT 转换时，将通报一个名为 title 的字符串参数，并将其值设置为 "Example Title"。
   多个字符串参数
  根据实际需求通报多个字符串参数：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_string_param title "Example Title";  # 传递第一个字符串参数
9.         xslt_string_param author "John Doe";      # 传递第二个字符串参数
10.     }
11. }

复制代码

在这个例子中，通报了两个字符串参数：title 和 author。
注意事项

• 明确性：使用 xslt_string_param 明确指定了通报的参数类型为字符串，有助于进步代码的可读性和维护性。
  
• 实用场景：实用于必要明确通报字符串参数的场景。
  

xslt_stylesheet

xslt_stylesheet 用于指定用于 XML 转换的 XSLT 样式表文件路径，并可以通报参数给样式表。这使得你可以将 XML 数据转换为其他格式（如 HTML、文本等）。

1. Syntax: xslt_stylesheet stylesheet [parameter=value ...];
2. Default: —
3. Context: location

复制代码

• stylesheet：指定 XSLT 样式表文件的路径。
  
• [parameter=value ...]：可选参数，指定通报给 XSLT 样式表的参数及其值。
  

案例
   基本用法
  最简单的 xslt_stylesheet 用法是指定样式表文件路径：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;  # 指定样式表文件路径
8.     }
9. }

复制代码

在这个例子中，指定了 XSLT 样式表文件路径 /etc/nginx/xslt/transform.xsl。
   通报参数
  根据实际需求通报参数给样式表：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl title="Example Title" author="John Doe";  # 传递参数给样式表
8.     }
9. }

复制代码

在这个例子中，通报了两个参数：title 和 author 给样式表。
   完整设置示例
  结合多个指令举行完整设置：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl title="Example Title" author="John Doe";  # 指定样式表并传递参数
8.         xslt_param subtitle "Subtitle Text";  # 额外传递参数
9.     }
11.     location /another_transform {
12.         root /var/www/xml;
13.         xslt_stylesheet /etc/nginx/xslt/another_transform.xsl;  # 不同的样式表
14.     }
15. }

复制代码

在这个例子中：

• 对于 /transform 路径下的哀求，使用了样式表 /etc/nginx/xslt/transform.xsl 并通报了多个参数。
  
• 对于 /another_transform 路径下的哀求，使用了不同的样式表 /etc/nginx/xslt/another_transform.xsl。
  

注意事项

• 路径正确性：确保指定的样式表文件路径正确，而且 Nginx 历程具有访问该文件的权限。
  
• 参数通报：合理使用参数通报功能，使样式表更具灵活性和通用性。
  

xslt_types

xslt_types 用于指定哪些 MIME 类型的响应应被转换为 XSLT 样式表处理。默认情况下，只有 text/xml 类型的响应会被处理。

1. Syntax: xslt_types mime-type ...;
2. Default: xslt_types text/xml;
3. Context: http, server, location

复制代码

• mime-type：指定要处理的 MIME 类型，默认为 text/xml。
  

案例
   基本用法
  最简单的 xslt_types 用法是指定处理的 MIME 类型：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_types application/xml text/xml;  # 处理多种 MIME 类型
9.     }
10. }

复制代码

在这个例子中，设置了 xslt_types application/xml text/xml，这意味着除了默认的 text/xml 类型外，还将处理 application/xml 类型的响应。
   扩展处理类型
  根据实际需求扩展处理的 MIME 类型：

1. server {
2.     listen 80;
3.     server_name example.com;
5.     location /transform {
6.         root /var/www/xml;
7.         xslt_stylesheet /etc/nginx/xslt/transform.xsl;
8.         xslt_types text/xml application/xml text/plain;  # 处理更多的 MIME 类型
9.     }
10. }

复制代码

在这个例子中，处理了三种 MIME 类型：text/xml、application/xml 和 text/plain。
注意事项

• 兼容性：确保指定的 MIME 类型确实适合 XSLT 转换，以避免不须要的错误或性能问题。
  
• 灵活性：通过扩展处理的 MIME 类型，可以使 XSLT 转换功能更加灵活和强盛。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4