nginx ngx_http_module(10) 指令详解

钜形不锈钢水箱  金牌会员 | 2025-2-20 21:32:23 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 884|帖子 884|积分 2652

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企服之家，中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

钜形不锈钢水箱

金牌会员
这个人很懒什么都没写!

楼主热帖

标签云

挺好的 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表