Nginx限流应用 & 漏桶/令牌桶算法原理

分类：Nginx作者：梦飞

文章目录

1. 前言

限流是一个后台服务的重要组成部分，尤其是在应对大量并发请求时，将流量限制到系统能够承受的范围内，才能保证系统安全高效运行。 本文从nginx配置入手，先列举限流的几种场景和nginx限流配置的用法，结合实验验证，再详细分析nginx中的漏桶算法原理。

2. 限流场景

2.1 简单限流

最简单的限流，严格按照固定速率限流，超出的请求直接拒绝。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    limit_req_status 429;
    server {
        location / {
            limit_req zone=one;
        }
}
  • limit_req_zone 定义了共享内存空间（用于存储请求数量等状态）和请求速率
  • $binary_remote_addr表示按照请求的ip地址限流
  • rate=12r/m表示限定速率为12r/m（12个请求每分钟），即每5s放行一个请求
  • zone=one:10m表示该空间容量为10M，名称为"one"
  • server下可以对每个服务路径指定 limit_req。如上面的配置zone=one指定了使用"one"这个空间做限流

实验验证：

10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.926] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.926] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.928] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.646] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.649] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.649] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.653] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

其中两个中括号的内容分别表示访问时间和处理耗时。 我们在5s内发送10个请求，只有一个请求成功了，其他请求都被拒绝（状态码为limit_req_status配置的429）。

2.2 削峰填谷

在实际的场景中，可能存在突发流量的情况，在短时间内请求速率高于限定速率，但从较大时间范围看，总速率在限定的范围之内。在这种情况下，直接拒绝超额的突发流量可能不是最好的策略，更好的策略是可以接受突发请求，并以限定的速率对请求进行处理（平滑流量），这样既不会超过限定速率，又可以尽可能地处理突发流量。在nginx中，这可以通过指定burst参数实现，如当burst=5，表示当请求超过限定速率时，允许超出的请求数量为5，这5个请求会阻塞等待，以限定速率依次通过。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    server {
        location / {
            limit_req zone=one burst=10;
        }
}

这个配置仅在上文配置基础上，增加burst=10，表示在速率为12r/m（每5s放行一个请求）的基础上，允许超过限定速率的请求数量为10。

实验验证：

10.99.16.41 - - [18/Feb/2022:18:39:13 +0800.1645180753.117] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:13 +0800.1645180753.789] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:18 +0800.1645180758.124] [5.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:23 +0800.1645180763.119] [9.977s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:28 +0800.1645180768.139] [14.356s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:33 +0800.1645180773.144] [19.360s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:38 +0800.1645180778.131] [24.347s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:43 +0800.1645180783.148] [29.363s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:48 +0800.1645180788.135] [34.349s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:53 +0800.1645180793.130] [39.344s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:58 +0800.1645180798.167] [44.381s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:40:03 +0800.1645180803.146] [49.358s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

我们在5s内发了12个请求（超出请求数为11）时，第1个请求直接通过，第2~11个请求阻塞并每5s通过一个（耗时递增5s），第12个请求直接被拒绝（第二行日志）。注：nginx的访问日志是在实际放行请求时打印，不是在请求到达时打印，所以可以看到第12个请求的日志早于第2～11个请求，因为第12个请求直接被拒绝，耗时为0，而第2～11个请求阻塞在等待队列中，耗时较长。

Note: 这种策略也常用于“流量整形(Traffic Shaping)”

2.3 峰值快速处理

在上一个示例中，我们将峰值进行了平滑处理，以处理一定程度的突发流量，但我们可以看到，当请求队列较大时，排在后面的阻塞请求会有较大的延时， 这无疑降低了用户体验。假如我们的服务本身就可以处理一定程度的突发流量（瞬间QPS高于平均水平），那我们就没必要将突发的流量阻塞，只要在burst允许范围内的流量就可以直接放行，这可以通过设置nodelay参数来实现。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    server {
        location / {
            limit_req zone=one burst=10 nodelay;
        }
}

实验验证：

10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.171] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.173] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.173] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.002] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.002] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.003] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.005] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.005] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.007] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

我们同样在5s内发送了12个请求，可以看到第2～11个请求并没有被阻塞，而是被立即处理了，第12个请求由于超出了burst，所以直接被拒绝了。

2.4 削峰填谷+峰值快速处理

在峰值快速处理的例子中，当接收到超出限定速率的请求时，可以一定程度上快速处理，但系统的承受能力毕竟是有限的，所以burst的大小会受限于系统的承受能力。假如系统能承受的最大瞬间并发量为2000，但外部短时间内请求峰值为3000，那么这多出的这1000个请求就必须丢弃吗？有没有可能快速处理2000个请求，剩下1000个堵塞等待后续处理呢？答案是肯定的，这可以通过Nginx的delay=?配置来实现。这个配置表示在超出限定速率的请求中，超过多少个请求之后需要被延时处理，没有超过delay值的请求，无需等待。nodelay其实是delay的一种特殊情况，表示所有请求都无需等待，相当于delay的值等于burst。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    server {
        location / {
            limit_req zone=one burst=10 delay=8;
        }
}

delay=8表示超出限定速率的8个请求可以被快速处理，再超过的（当然也必须小于burst）就必须阻塞等待。

图0. rate=5r/s burst=12 delay=8 时的限流说明 实验验证： 

10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.522] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.522] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.523] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.194] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.196] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.197] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:44 +0800.1645441964.535] [4.339s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:49 +0800.1645441969.539] [9.342s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

同样在5s内发送12个请求，可以看到，第2~9个请求立即被处理，第10～11个请求被阻塞并以限定速率依次处理（最后两行），第12个请求（倒数第三行）直接被拒绝。

3. 漏桶原理

3.1 算法介绍

Nginx的流量控制其实是通过漏桶原理实现的，在网络上有许多关于漏桶算法的描述，与此相关的另一个算法——令牌桶算法也常常被提及，并且这两者容易引起混淆。但通过下文的分析，我们将看到这两个算法其实本质上是等价的。

我们先通过一个图来理解漏桶算法：

图1. 使用漏桶做流量监管

  • 漏桶有固定容量（图中为T + τ），并以固定速率往外漏水
  • 如果漏桶为空，停止泄漏
  • 请求到达时，需要能够往桶中加入特定量的水。这个量可以每个请求都一样，也可以与请求报文的长度成比例
  • 如果加入的水会导致桶溢出，那么请求被认为超出了限制，并且桶的水量保持不变

图1中小人就是负责监控桶中水量，当请求需要往桶中加入的水量为T，而当前水量已经超过τ时（也就是如果加入T，桶会溢出），小人会采取行动：

  • 在流量监管（Traffic Policing）中（图1的情况），小人会打开陷阱的门，导致请求包被丢弃，并使水无法流入到桶中；
  • 在流量整形（Traffic Shaping）中（如图2），小人会推起挡板，使得阻塞了请求的通过，直到水位降到τ或以下才放行请求。

图2.使用漏桶做流量整形

不难看出，在上面的情况中，当流量整形的队列长度为0时，就相当于流量监管，所以流量监管是流量整形的一种特殊情况。另外，漏桶算法的核心在于判断请求是否以特定速率通过，至于超出的请求，并没有统一的处理方式，可以是直接拒绝，也可以是阻塞等待等等，这由实现方或使用方决定。

需要指出的是，在上面的描述中，流量并没有以水的形式流过漏桶，桶只是作为一个标尺，用于判断请求是否能够通过。也有另外一种描述漏桶算法的版本，在这个版本中，桶中的水直接模拟流量以固定的速率流过漏桶。但是通过分析我们会发现后者是前者的一种特殊情况，这里不做详述，有兴趣的可以参考wikipedia对这两个版本的比较，有问题也欢迎随时交流。

3.2 与Nginx参数对应关系

通过对Nginx- Github源码的分析，以及实验验证，我们可以把nginx配置的参数对应到图2中。直接给结论：

将图2中的队列长度记为Q，桶容量记为C：

  • rate 对应漏桶往外漏水的速率
  • burst = τ+Q
  • T = 1，即每个请求往漏桶加一个单元的水量，且C=τ+1
  • delay = τ；若配置了nodelay则表示Q=0，即burst= τ；若delay和nodelay都没有配置，则τ=0，即burst=Q 且 C=1

有了这个对应关系，再去理解nginx的参数，就更加明了了。

3.3 与令牌桶比较

令牌桶算法描述如下：

  • 每隔1/r秒一个令牌被加入到桶中（r为平均发送速率）
  • 桶最多可以容纳b个令牌。如果令牌到达时桶已经满了，那么丢弃该令牌
  • 当一个n个字节的报文到达时，就从令牌桶中删除n个令牌（如果有），并且将报文发送到网络
  • 如果令牌桶中少于n个令牌，那么令牌不会被删除，并且认为这个报文在流量限制之外

把这个描述和漏桶的做对比，我们会发现，其实这是同一个算法思想的两种不同描述：

  • 漏桶以固定速率往外漏水直到桶为空，并在报文到达时往内加水（要求不溢出）
  • 令牌桶以固定速率往内加令牌直到加满，并在报文到达时往外取令牌（要求有足够令牌）

所以只要给定等价的参数，这两个算法的对外表现是一致的，性质上的差别只会来自具体实现的不同，底层逻辑是完全一样的。

3.4 代码实现

虽然漏桶或令牌桶在描述中都存在一个定时时钟，但实际实现其实基本都不是使用时钟来实现的，而是使用懒惰计算的方式，即在请求到达时才根据当前时间和预设的速率计算出当前桶内应有的水/令牌量，这样可以避免时钟的使用，提升性能的同时也使得算法可以在不支持时钟的系统中使用。另外，算法中的队列也基本上不会显式体现在代码中，基本是以sleep延时的方式把请求阻塞在内存中，隐式表示队列，并且队列的大小往往也需要由使用方自己维护。

Golang官方实现了一个基于令牌桶的限流器，另一个使用较多的令牌桶第三方库是 juju/ratelimit，而漏桶算法的代表库是 uber 在 Github 上开源的 go 语言库 ratelimit。

代码的详解待后续有机会再补充，可以先参考这几篇文章：

参考：

原文地址：https://cloud.tencent.com/developer/article/2028460

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

Nginx编程算法

相关推荐

学习笔记：深入理解高性能代理服务器——Nginx
文章浏览阅读3.7k次，点赞2次，收藏5次。Nginx学习笔记一、Nginx 简介1. 什么是Nginx2. 反向代理3. 负载均衡4. 动静分离二、Nginx基本使用1. Nginx常用的操作命令2. Nginx的配置文件提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录一、Nginx 简介1. 什么是Nginx2. 反向代理3. 负载均衡4. 动静分离二、Nginx基本使用1. Nginx常用的操作命令2. Nginx的配置文件一、Nginx 简介1. 什么是Nginx  Nginx（“engine x”）是一个_nginx代理
Docker配置nginx
文章浏览阅读1.7w次，点赞14次，收藏61次。我们在使用容器的过程中需，有时候需要对容器中的文件进行修改管理，如果不做文件映射的化，我们使用docker exec -it 容器ID/容器名 /bin/bash 才能进入nginx中的文件里面如图。架设在客户机与目标主机之间，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器，并将原本要直接发送到web服务器上的http请求发送到代理服务器中。A想要组C的房子，但是A并不认识C所以租不到，但是B认识C，A找B帮忙租到了C的房子。客户端代理服务器服务器。_docker nginx 配置
Nginx如何实现404错误自动跳转到首页
文章浏览阅读1.4k次。当用户在访问网站的过程中遇到404错误时，通常情况下应该显示一个友好的错误页面，而不是仅仅显示一个简单的错误提示。在Nginx中，可以通过配置来实现404错误自动跳转到首页的功能。如果您的网站使用动态内容生成页面（如PHP或其他服务器端语言），则应相应地修改配置以适应您的网站架构。这样，当用户访问一个不存在的页面时，Nginx会自动将其重定向到首页。为了使配置生效，需要重新加载Nginx配置。首先，需要打开Nginx的配置文件。现在，当用户访问一个不存在的页面时，Nginx会自动将其重定向到首页。_nginx 404 重定向
docker/docker-compose 部署 nginx+mysql+wordpress 实战
文章浏览阅读2.7k次。docker 和 docker-compose 部署 nginx+mysql+wordpress 实战_docker wordpress mariadb
windows下nginx的安装使用及解决80端口被占用nginx不能启动的问题
文章浏览阅读1.3k次。5：再次启动nginx，可以正常启动，可以在任务管理器中查看到nginx的进程。重新启动下 直接访问8090端口 ok 访问成功。1 ：查看80端口占用情况，pid的值为3960。3：在运行中输入regedit打开注册表编辑器。2： 通过以下命令查看3960所对应的服务名称。4：找到Start，右键修改将其制改为4。_nginx80端口无法访问
【Nginx篇】Nginx轻松上手
文章浏览阅读3.1w次，点赞105次，收藏182次。高性能：Nginx 被设计为能够处理大量并发连接而不显著增加系统负担。它采用异步事件驱动的架构，可以有效地处理高流量的 Web 请求。负载均衡：Nginx 支持负载均衡，可以将请求分发到多个后端服务器，以提高网站性能和可用性。反向代理：Nginx 可以充当反向代理，将客户端请求转发到后端服务器，隐藏后端服务器的真实 IP 地址，增加安全性和可扩展性。静态文件服务：Nginx 可以高效地提供静态文件（如 HTML、CSS、JavaScript、图像等）的服务，减轻应用服务器的负担。
Nginx性能优化
文章浏览阅读976次。nginx作为常用的web代理服务器，某些场景下对于性能要求还是蛮高的，所以本片文章会基于操作系统调度以及网络通信两个角度来讨论一下Nginx性能的优化思路。我们的大学教程大部分讲述七层模型，实际上现代网络协议使用的都是四层模型，如下图，应用层报文经过四层的首部封装到对端。对端链路层拆开首部查看mac地址是自己在网上，拆开ip首部查看目的地址是不是自己，然后到达传输层应用层完成报文接收。文章是基于原有个人知识基础上，对旧知识进行巩固，以及新知识实践学习。
Nginx 轻松搞定跨域问题
文章浏览阅读5.4k次，点赞9次，收藏15次。最后再说一种情况，就是后端处理了跨域，就不需要自己在处理了（这里吐槽下，某些后端工程师自己改服务端代码解决跨域，但是又不理解其中原理，网上随便找段代码黏贴，导致响应信息可能处理不完全，如method没添加全，headers没加到点上，自己用的那个可能复制过来的并不包含实际项目所用到的，没有添加options请求返回状态码等，导致Nginx再用通用的配置就会可能报以下异常）里面的就好了，因为这里如果是预检请求直接就ruturn了，请求不会再转发到59200服务，如果也删除了，就会报和情况1一样的错误。_nginx 允许跨域
踩坑日记-nginx server_name配置多域名的坑
文章浏览阅读2.5k次。项目配置了多个域名，如下，php 代码中有获取的值。当访问a.demo.com时，其获取的值是符合预期的。但是当访问b.demo.com时，其获取的值还是a.demo.com，导致代码中的判断出现错误。_nginxservername多个域名
ingress-nginx控制器安装
文章浏览阅读1k次，点赞2次，收藏5次。采用YAML manifest的方式来安装ingress-nginx，用registry.lank8s.cn镜像库来替换 registry.k8s.io的库。_ingress-nginx安装
Windows环境下编译nginx
文章浏览阅读1.6k次，点赞2次，收藏2次。在windows平台编译nginx_windows 编译nginx
【Nginx】入门看这一篇就够啦，nginx 简介、安装、工作原理、工作方式、详解配置文件
文章浏览阅读5.8k次，点赞2次，收藏18次。nginx [engine x] 是 HTTP 和反向代理服务器、邮件代理服务器和通用 TCP/UDP 代理服务器。nginx 的特点是占有内存少，并发能力强，事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。在高连接并发的情况下，nginx是Apache服务器不错的替代品，能够支持高达50000个并发连接数的响应。使用epoll and kqueue作为开发模型。_nginx
Linux启动（systemctl start nginx）nginx服务时出现：Failed to start nginx.service: Unit not found.
文章浏览阅读2k次。Linux启动（systemctl start nginx）nginx服务时出现：Failed to start nginx.service: Unit not found._为什么nginx的systemctl start nginx.service不能使用
Nginx的反向代理
文章浏览阅读1.3k次。重启之后，打开浏览器，输入http://localhost:8900/myBaidu，这时候就会自动的跳转到百度的页面。按照我们不同的需求修改nginx文件夹中的nginx-1.16.1conf里面的nginx.conf文件。启动nginx：打开nginx的文件夹，然后双击nginx.exe文件，启动nginx。打开之后假设我们需要跳转到百度则在配置文件nginx.conf中的下面加上。1、打开任务管理器关闭nginx的进程。端口在配置文件的（下图）进行查看nginx端口。_nginx 代理百度
nginx重定向问题解决（rewrite or internal redirection cycle）
文章浏览阅读5.7k次，点赞5次，收藏3次。nginx重定向问题解决（rewrite or internal redirection cycle）_rewrite or internal redirection cycle while internally redirecting to "/inde
在 Windows 中关闭 Nginx 所有进程
文章浏览阅读1.3k次。请注意，上述命令假设 Nginx 已经在系统的 PATH 环境变量中配置。如果没有，请提供正确的 Nginx 安装路径，或者在命令中使用完整的路径来替换。将该命令与所有 Nginx 进程的 PID 一起使用，以终止所有正在运行的 Nginx 进程。此命令将启动一个新的 Nginx 进程来重新加载配置文件并重新启动服务器。使用以下命令来终止所有 Nginx 进程（使用上面的 PID 替换。的进程以及它们的 PID。打开命令提示符（CMD）。此命令将列出所有名为。选项来强制终止进程。_windows 怎么关闭nginx
如何在 Ubuntu 上安装和使用 Nginx？
文章浏览阅读2.7k次，点赞2次，收藏7次。包括 Netflix、GitHub 和 WordPress。Nginx 可以用作 Web 服务器、负载均衡器、反向代理和 HTTP 缓存等。_ubuntu安装nginx
轻松搭建短域名短链接服务系统，可选权限认证，并自动生成证书认证把nginx的http访问转换为https加密访问，完整步骤和代码
文章浏览阅读915次。轻松搭建短域名短链接服务系统，可选权限认证，并自动生成证书认证把nginx的http访问转换为https加密访问，完整步骤和代码。_nginx 短链代理
流媒体方案之Nginx——实现物联网视频监控项目
文章浏览阅读1.1k次，点赞35次，收藏24次。流媒体方案之Nginx——实现物联网视频监控项目Nginx是什么Nginx在流媒体方案中的位置软硬件准备移植编译Nginx运行Ngnix测试流媒体方案浏览器播放_nginx-rtmp-module
nginx 配置 wss 协议
文章浏览阅读1.9k次。nginx 配置 wss 协议转发 ws 服务器_nginx 配置wss
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot