Nginx开发入门与深度解析：模块开发与性能理解

167 浏览量更新于2024-06-15 收藏 3.47MB DOCX 举报

《Nginx开发从入门到精通》是一本深入讲解Nginx开发技术的实用指南，由taobaoserverplatform于2013年1月25日发布。该书分为上篇和下篇，旨在帮助读者全面理解和掌握Nginx。上篇主要聚焦于Nginx模块的开发，包括： 1. **背景与历史**：介绍Nginx的发展历程以及其在Web服务器领域的应用和特点，强调其高效、稳定和模块化的特性。 2. **平台初探**：详细阐述Nginx的架构，包括其基础概念，如基本数据结构，以及配置系统、请求处理流程和模块化体系结构，让读者了解其工作原理。 3. **Handler模块**：深入剖析handler模块，讲解其结构、挂载方法，提供一个Hello World模块示例，并对部分模块进行分析。 4. **过滤模块**：介绍过滤模块的功能，以及如何分析其工作原理，这部分重点讲解了90%的内容。 5. **Upstream模块**：讲解负载均衡模块，以及core和event等其他模块的使用，还涉及lua模块的高级应用。 6. **模块开发高级篇**：深入讨论变量的应用、upstream模块的高级技巧，以及利用lua扩展Nginx功能。下篇则着重于Nginx的原理解析： 1. **高性能服务器设计**：涉及著名的c10k问题，以及编写高性能服务器的关键原则，强调事件驱动和时间管理的重要性。 2. **Nginx架构详解**：深入解析Nginx的源码结构，包括配置原理、事件机制、进程管理和基础设施，如内存池、共享内存、缓冲管理、异步I/O（AIO）和锁实现。 3. **基础设施**：详细介绍了Nginx内部的基本数据结构，如时间缓存，这些内容对于理解Nginx的工作底层至关重要。《Nginx开发从入门到精通.pdf.docx》是一本涵盖了Nginx的基础、模块开发和核心原理的教程，适合对Nginx有初步了解或希望提升技能的开发者深入学习和实践。通过阅读这本书，读者能够全面掌握Nginx的开发环境搭建、模块编写、性能优化和架构理解，提升自己的Nginx开发能力。

Nginx 开发从入门到精通

后，然后再 fork 出多个 worker 进程，这样每个 worker 进程都可以去 accept 这个 socket(当然不是同一

个 socket，只是每个进程的这个 socket 会监控在同一个 ip 地址与端口，这个在网络协议里面是允许的)。一

般来说，当一个连接进来后，所有在 accept 在这个 socket 上面的进程，都会收到通知，而只有一个进程可以

accept 这个连接，其它的则 accept 失败，这是所谓的惊群现象。当然，nginx 也不会视而不见，所以 nginx

提供了一个 accept_mutex 这个东西，从名字上，我们可以看这是一个加在 accept 上的一把共享锁。有了这

把锁之后，同一时刻，就只会有一个进程在 accpet 连接，这样就不会有惊群问题了。accept_mutex 是一个

可控选项，我们可以显示地关掉，默认是打开的。当一个 worker 进程在 accept 这个连接之后，就开始读取请

求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的

了。我们可以看到，一个请求，完全由 worker 进程来处理，而且只在一个 worker 进程中处理。

那么，nginx 采用这种进程模型有什么好处呢？当然，好处肯定会很多了。首先，对于每个 worker 进程来说，

独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多。其次，采用

独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master 进程则

很快重新启动新的 worker 进程。当然，worker 进程的异常退出，肯定是程序有 bug 了，异常退出，会导致

当前 worker 上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以

慢慢体会。

上面讲了很多关于 nginx 的进程模型，接下来，我们来看看 nginx 的是如何处理事件的。

有人可能要问了，nginx 采用多 worker 的方式来处理请求，每个 worker 里面只有一个主线程，那能够处

理的并发数很有限啊，多少个 worker 就能处理多少个并发，何来高并发呢？非也，这就是 nginx 的高明之

处，nginx 采用了异步非阻塞的方式来处理请求，也就是说，nginx 是可以同时处理成千上万个请求的。想想

apache 的常用工作方式（apache 也有异步非阻塞版本，但因其与自带某些模块冲突，所以不常用），每个请

求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不

小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的 cpu 开销很大，自然性能就上不去了，而这

些开销完全是没有意义的。

为什么 nginx 可以采用异步非阻塞的方式来处理呢，或者异步非阻塞到底是怎么回事呢？我们先回到原点，看

看一个请求的完整过程。首先，请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系

统底层，就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得

阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，你再继续吧。阻塞调用会进入内核等待，cpu

就会让出去给别人用了，对单线程的 worker 来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu

空闲下来没人用，cpu 利用率自然上不去了，更别谈高并发了。好吧，你说加进程数，这跟 apache 的线程模

型有什么区别，注意，别增加无谓的上下文切换？所以，在 nginx 里面，最忌讳阻塞的系统调用了。不要阻塞，

那就非阻塞喽。非阻塞就是，事件没有准备好，马上返回 EAGAIN，告诉你，事件还没准备好呢，你慌什么，

过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它

事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事

情了，但带来的开销也是不小的。所以，才会有了异步非阻塞的事件处理机制，具体到系统调用就是像 select/

poll/epoll/kqueue 这样的系统调用。它们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，

但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制正好解决了我们上面的两个问

题，拿 epoll 为例 (在后面的例子中，我们多以 epoll 为例子，以代表这一类函数)，当事件没准备好时，放到

epoll 里面，事件准备好了，我们就去读写，当读写返回 EAGAIN 时，我们将它再次加入到 epoll 里面。这样，

只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在 epoll 里面等着。这样，我们就可

以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请

3.1 上篇：nginx 模块开发篇

www.linuxidc.com

Nginx 开发从入门到精通

求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里

的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。与多线程相比，这种事

件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常

的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。

我之前有对连接数进行过测试，在 24G 内存的机器上，处理的并发请求数达到过 200 万。现在的网络服务器基

本都采用这种方式，这也是 nginx 性能高效的主要原因。

我们之前说过，推荐设置 worker 的个数为 cpu 的核数，在这里就很容易理解了，更多的 worker 数，只会

导致进程来竞争 cpu 资源了，从而带来不必要的上下文切换。而且，nginx 为了更好的利用多核特性，提供了

cpu 亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来 cache 的

失效。像这种小的优化在 nginx 中非常常见，同时也说明了 nginx 作者的苦心孤诣。比如，nginx 在做 4 个字

节的字符串比较时，会将 4 个字符转换成一个 int 型，再作比较，以减少 cpu 的指令数等等。

现在，知道了 nginx 什么会选择这样的进程模型与事件模型了。对于一个基本的 web 服务器来说，事件通常有

三种类型，网络事件、信号、定时器。从上面的讲解中知道，网络事件通过异步非阻塞可以很好的解决掉。如何

处理信号与定时器？

首先，信号的处理。对 nginx 来说，有一些特定的信号，代表着特定的意义。信号会中断掉程序当前的运行，

在改变状态后，继续执行。如果是系统调用，则可能会导致系统调用的失败，需要重入。关于信号的处理，大家

可以学习一些专业书籍，这里不多说。对于 nginx 来说，如果 nginx 正在等待事件（epoll_wait 时），如果程

序收到信号，在信号处理函数处理完后，epoll_wait 会返回错误，然后程序可再次进入 epoll_wait 调用。

另外，再来看看定时器。由于 epoll_wait 等函数在调用的时候是可以设置一个超时时间的，所以 nginx 借助这

个超时时间来实现定时器。nginx 里面的定时器事件是放在一个最小堆里面，每次在进入 epoll_wait 前，先从

最小堆里面拿到所有定时器事件的最小时间，在计算出 epoll_wait 的超时时间后进入 epoll_wait。所以，当没

有事件产生，也没有中断信号时，epoll_wait 会超时，也就是说，定时器事件到了。这时，nginx 会检查所有

的超时事件，将他们的状态设置为超时，然后再去处理网络事件。由此可以看出，当我们写 nginx 代码时，在

处理网络事件的回调函数时，通常做的第一个事情就是判断超时，然后再去处理网络事件。

我们可以用一段伪代码来总结一下 nginx 的事件处理模型：

好，本节我们讲了进程模型，事件模型，包括网络事件，信号，定时器事件。

nginx 基础概念 (100%)

connection

在 nginx 中 connection 就是对 tcp 连接的封装，其中包括连接的 socket，读事件，写事件。利用 nginx 封

装的 connection，我们可以很方便的使用 nginx 来处理与连接相关的事情，比如，建立连接，发送与接受数

据等。而 nginx 中的 http 请求的处理就是建立在 connection 之上的，所以 nginx 不仅可以作为一个 web

服务器，也可以作为邮件服务器。当然，利用 nginx 提供的 connection，我们可以与任何后端服务打交道。

结合一个 tcp 连接的生命周期，我们看看 nginx 是如何处理一个连接的。首先，nginx 在启动时，会解析配置

文件，得到需要监听的端口与 ip 地址，然后在 nginx 的 master 进程里面，先初始化好这个监控的 socket(创

建 socket，设置 addrreuse 等选项，绑定到指定的 ip 地址端口，再 listen)，然后再 fork 出多个子进程出来，

然后子进程会竞争 accept 新的连接。此时，客户端就可以向 nginx 发起连接了。当客户端与 nginx 进行三次

第 3 章

www.linuxidc.com

Nginx 开发从入门到精通

握手，与 nginx 建立好一个连接后，此时，某一个子进程会 accept 成功，得到这个建立好的连接的 socket，

然后创建 nginx 对连接的封装，即 ngx_connection_t 结构体。接着，设置读写事件处理函数并添加读写事件

来与客户端进行数据的交换。最后，nginx 或客户端来主动关掉连接，到此，一个连接就寿终正寝了。

当然，nginx 也是可以作为客户端来请求其它 server 的数据的（如 upstream 模块），此时，与其它 server

创建的连接，也封装在 ngx_connection_t 中。作为客户端，nginx 先获取一个 ngx_connection_t 结构体，

然后创建 socket，并设置 socket 的属性（比如非阻塞）。然后再通过添加读写事件，调用 connect/read/

write 来调用连接，最后关掉连接，并释放 ngx_connection_t。

在 nginx 中，每个进程会有一个连接数的最大上限，这个上限与系统对 fd 的限制不一样。在操作系统中，通过

ulimit -n，我们可以得到一个进程所能够打开的 fd 的最大数，即 noﬁle，因为每个 socket 连接会占用掉一个

fd，所以这也会限制我们进程的最大连接数，当然也会直接影响到我们程序所能支持的最大并发数，当 fd 用完

后，再创建 socket 时，就会失败。不过，这里我要说的 nginx 对连接数的限制，与 noﬁle 没有直接关系，可

以大于 noﬁle，也可以小于 noﬁle。nginx 通过设置 worker_connectons 来设置每个进程可使用的连接最大

值。nginx 在实现时，是通过一个连接池来管理的，每个 worker 进程都有一个独立的连接池，连接池的大小

是 worker_connections。这里的连接池里面保存的其实不是真实的连接，它只是一个 worker_connections

大小的一个 ngx_connection_t 结构的数组。并且，nginx 会通过一个链表 free_connections 来保存所有的

空闲 ngx_connection_t，每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表

里面。

在这里，很多人会误解 worker_connections 这个参数的意思，认为这个值就是 nginx 所能建立连接的最大

值。其实不然，这个值是表示每个 worker 进程所能建立连接的最大值，所以，一个 nginx 能建立的最大连接

数，应该是 worker_connections * worker_processes。当然，这里说的是最大连接数，对于 HTTP 请求本

地资源来说，能够支持的最大并发数量是 worker_connections * worker_processes，而如果是 HTTP 作为

反向代理来说，最大并发数量应该是 worker_connections * worker_processes/2。因为作为反向代理服务

器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

那么，我们前面有说过一个客户端连接过来后，多个空闲的进程，会竞争这个连接，很容易看到，这种竞争会

导致不公平，如果某个进程得到 accept 的机会比较多，它的空闲连接很快就用完了，如果不提前做一些控

制，当 accept 到一个新的 tcp 连接后，因为无法得到空闲连接，而且无法将此连接转交给其它进程，最终

会导致此 tcp 连接得不到处理，就中止掉了。很显然，这是不公平的，有的进程有空余连接，却没有处理机

会，有的进程因为没有空余连接，却人为地丢弃连接。那么，如何解决这个问题呢？首先，nginx 的处理得先

打开 accept_mutex 选项，此时，只有获得了 accept_mutex 的进程才会去添加 accept 事件，也就是说，

nginx 会控制进程是否添加 accept 事件。nginx 使用一个叫 ngx_accept_disabled 的变量来控制是否去竞

争 accept_mutex 锁。在第一段代码中，计算 ngx_accept_disabled 的值，这个值是 nginx 单进程的所有

连接总数的八分之一，减去剩下的空闲连接数量，得到的这个 ngx_accept_disabled 有一个规律，当剩余连

接数小于总连接数的八分之一时，其值才大于 0，而且剩余的连接数越小，这个值越大。再看第二段代码，当

ngx_accept_disabled 大于 0 时，不会去尝试获取 accept_mutex 锁，并且将 ngx_accept_disabled 减 1，

于是，每次执行到此处时，都会去减 1，直到小于 0。不去获取 accept_mutex 锁，就是等于让出获取连接的

机会，很显然可以看出，当空余连接越少时，ngx_accept_disable 越大，于是让出的机会就越多，这样其它进

程获取锁的机会也就越大。不去 accept，自己的连接就控制下来了，其它进程的连接池就会得到利用，这样，

nginx 就控制了多进程间连接的平衡了。

好了，连接就先介绍到这，本章的目的是介绍基本概念，知道在 nginx 中连接是个什么东西就行了，而且连接

是属于比较高级的用法，在后面的模块开发高级篇会有专门的章节来讲解连接与事件的实现及使用。

3.1 上篇：nginx 模块开发篇

www.linuxidc.com

Nginx 开发从入门到精通

request

这节我们讲 request，在 nginx 中我们指的是 http 请求，具体到 nginx 中的数据结构是

ngx_http_request_t。ngx_http_request_t 是对一个 http 请求的封装。我们知道，一个 http 请求，包

含请求行、请求头、请求体、响应行、响应头、响应体。

http 请求是典型的请求 -响应类型的的网络协议，而 http 是文件协议，所以我们在分析请求行与请求头，以及

输出响应行与响应头，往往是一行一行的进行处理。如果我们自己来写一个 http 服务器，通常在一个连接建立

好后，客户端会发送请求过来。然后我们读取一行数据，分析出请求行中包含的 method、uri、http_version

信息。然后再一行一行处理请求头，并根据请求 method 与请求头的信息来决定是否有请求体以及请求体的长

度，然后再去读取请求体。得到请求后，我们处理请求产生需要输出的数据，然后再生成响应行，响应头以及响

应体。在将响应发送给客户端之后，一个完整的请求就处理完了。当然这是最简单的 webserver 的处理方式，

其实 nginx 也是这样做的，只是有一些小小的区别，比如，当请求头读取完成后，就开始进行请求的处理了。

nginx 通过 ngx_http_request_t 来保存解析请求与输出响应相关的数据。

那接下来，简要讲讲 nginx 是如何处理一个完整的请求的。对于 nginx 来说，一个请求是从

ngx_http_init_request 开始的，在这个函数中，会设置读事件为 ngx_http_process_request_line，

也就是说，接下来的网络事件，会由 ngx_http_process_request_line 来执行。从

ngx_http_process_request_line 的函数名，我们可以看到，这就是来处理请求行的，正好与之前讲

的，处理请求的第一件事就是处理请求行是一致的。通过 ngx_http_read_request_header 来读取请求数据。

然后调用 ngx_http_parse_request_line 函数来解析请求行。nginx 为提高效率，采用状态机来解析请求行，

而且在进行 method 的比较时，没有直接使用字符串比较，而是将四个字符转换成一个整型，然后一次比较以

减少 cpu 的指令数，这个前面有说过。很多人可能很清楚一个请求行包含请求的方法，uri，版本，却不知道其

实在请求行中，也是可以包含有 host 的。比如一个请求 GET http://www.taobao.com/uri HTTP/1.0 这样

一个请求行也是合法的，而且 host 是 www.taobao.com，这个时候，nginx 会忽略请求头中的 host 域，而

以请求行中的这个为准来查找虚拟主机。另外，对于对于 http0.9 版来说，是不支持请求头的，所以这里也是

要特别的处理。所以，在后面解析请求头时，协议版本都是 1.0 或 1.1。整个请求行解析到的参数，会保存到

ngx_http_request_t 结构当中。

在解析完请求行后，nginx 会设置读事件的 handler 为 ngx_http_process_request_headers，然后后续的

请求就在 ngx_http_process_request_headers 中进行读取与解析。ngx_http_process_request_headers

函数用来读取请求头，跟请求行一样，还是调用 ngx_http_read_request_header 来读取请求头，调用

ngx_http_parse_header_line 来解析一行请求头，解析到的请求头会保存到 ngx_http_request_t 的域

headers_in 中，headers_in 是一个链表结构，保存所有的请求头。而 HTTP 中有些请求是需要特别处理

的，这些请求头与请求处理函数存放在一个映射表里面，即 ngx_http_headers_in，在初始化时，会生成一个

hash 表，当每解析到一个请求头后，就会先在这个 hash 表中查找，如果有找到，则调用相应的处理函数来处

理这个请求头。比如:Host 头的处理函数是 ngx_http_process_host。

当 nginx 解析到两个回车换行符时，就表示请求头的结束，此时就会调用 ngx_http_process_request

来处理请求了。 ngx_http_process_request 会设置当前的连接的读写事件处理函数为

ngx_http_request_handler，然后再调用 ngx_http_handler 来真正开始处理一个完整的 http 请求。这里可

能比较奇怪，读写事件处理函数都是 ngx_http_request_handler，其实在这个函数中，会根据当前事件是读

事件还是写事件，分别调用 ngx_http_request_t 中的 read_event_handler 或者是 write_event_handler。

由于此时，我们的请求头已经读取完成了，之前有说过， nginx 的做法是先不读取请求 body，所以

第 3 章

www.linuxidc.com

Nginx 开发从入门到精通

这里面我们设置 read_event_handler 为 ngx_http_block_reading，即不读取数据了。刚才说到，真

正开始处理数据，是在 ngx_http_handler 这个函数里面，这个函数会设置 write_event_handler 为

ngx_http_core_run_phases，并执行 ngx_http_core_run_phases 函数。ngx_http_core_run_phases 这

个函数将执行多阶段请求处理，nginx 将一个 http 请求的处理分为多个阶段，那么这个函数就是执行这些阶段

来产生数据。因为 ngx_http_core_run_phases 最后会产生数据，所以我们就很容易理解，为什么设置写事件

的处理函数为 ngx_http_core_run_phases 了。在这里，我简要说明了一下函数的调用逻辑，我们需要明白

最终是调用 ngx_http_core_run_phases 来处理请求，产生的响应头会放在 ngx_http_request_t 的 head-

ers_out 中，这一部分内容，我会放在请求处理流程里面去讲。nginx 的各种阶段会对请求进行处理，最后会调

用 ﬁlter 来过滤数据，对数据进行加工，如 truncked 传输、gzip 压缩等。这里的 ﬁlter 包括 header ﬁlter

与 body ﬁlter，即对响应头或响应体进行处理。ﬁlter 是一个链表结构，分别有 header ﬁlter 与 body ﬁlter，

先执行 header ﬁlter 中的所有 ﬁlter，然后再执行 body ﬁlter 中的所有 ﬁlter。在 header ﬁlter 中的最后一

个 ﬁlter，即 ngx_http_header_ﬁlter，这个 ﬁlter 将会遍历所的有响应头，最后需要输出的响应头在一个连

续的内存，然后调用 ngx_http_write_ﬁlter 进行输出。ngx_http_write_ﬁlter 是 body ﬁlter 中的最后一个，

所以 nginx 首先的 body 信息，在经过一系列的 body ﬁlter 之后，最后也会调用 ngx_http_write_ﬁlter 来

进行输出 (有图来说明)。

这里要注意的是，nginx 会将整个请求头都放在一个 buﬀer 里面，这个 buﬀer 的大小通过配置项

client_header_buﬀer_size 来设置，如果用户的请求头太大，这个 buﬀer 装不下，那 nginx 就会重新分

配一个新的更大的 buﬀer 来装请求头，这个大 buﬀer 可以通过 large_client_header_buﬀers 来设置，这个

large_buﬀer 这一组 buﬀer，比如配置 4 8k，就是表示有四个 8k 大小的 buﬀer 可以用。注意，为了保存请

求行或请求头的完整性，一个完整的请求行或请求头，需要放在一个连续的内存里面，所以，一个完整的请求行

或请求头，只会保存在一个 buﬀer 里面。这样，如果请求行大于一个 buﬀer 的大小，就会返回 414 错误，如

果一个请求头大小大于一个 buﬀer 大小，就会返回 400 错误。在了解了这些参数的值，以及 nginx 实际的做

法之后，在应用场景，我们就需要根据实际的需求来调整这些参数，来优化我们的程序了。

处理流程图：

以上这些，就是 nginx 中一个 http 请求的生命周期了。我们再看看与请求相关的一些概念吧。

keepalive 当然，在 nginx 中，对于 http1.0 与 http1.1 也是支持长连接的。什么是长连接呢？我们知道，

http 请求是某于 TCP 协议之上的，那么，当客户端在发起请求前，需要先与服务端建立 TCP 连接，而每一次

的 TCP 连接是需要三次握手来确定的，如果客户端与服务端之间网络差一点，这三次交互消费的时间会比较多，

而且三次交互也会带来网络流量。当然，当连接断开后，也会有四次的交互，当然对用户体验来说就不重要了。

而 http 请求是请求应答式的，如果我们能知道每个请求头与响应体的长度，那么我们是可以在一个连接上面执

行多个请求的，这就是所谓的长连接，但前提条件是我们先得确定请求头与响应体的长度。对于请求来说，如

果当前请求需要有 body，如 POST 请求，那么 nginx 就需要客户端在请求头中指定 content-length 来表明

body 的大小，否则返回 400 错误。也就是说，请求体的长度是确定的，那么响应体的长度呢？先来看看 http

协议中关于响应 body 长度的确定：

1. 对于 http1.0 协议来说，如果响应头中有 content-length 头，则以 content-length 的长度就可以知道

body 的长度了，客户端在接收 body 时，就可以依照这个长度来接收数据，接收完后，就表示这个请求

完成了。而如果没有 content-length 头，则客户端会一直接收数据，直到服务端主动断开连接，才表示

body 接收完了。

3.1 上篇：nginx 模块开发篇

www.linuxidc.com

剩余92页未读，继续阅读

Java干码人

粉丝: 2
资源: 43

Nginx开发入门与深度解析：模块开发与性能理解

Nginx开发从入门到精通完整学习指南

Nginx开发从入门到精通：模块开发与原理解析

Nginx入门到精通指南：配置与优化

Nginx开发从入门到精通.pdf

Nginx教程从入门到精通.pdf

Nginx从入门到精通.pdf

nginx从入门到精通.pdf

Nginx教程从入门到精通.zip

Nginx开发从入门到精通 Nginx开发从入门到精通 Nginx开发从入门到精通中文

Nginx开发从入门到精通【pdf】版

最新资源