我要评论一、nginx请求默认页面资源
1、配置文件详解
修改端口号为8080并重启服务：
二、nginx进程模型
1、nginx常用命令解析
master进程：主进程（只有一个）
worker进程：工作进程（可以有多个，默认只有一个进程）
生命周期的原理：
信号: (操作人在执行以下指令操作的时候，master会转递给worker相关的信息让worker去进行相关的操作)
./nginx #开启nginx服务。 ./nginx -s stop #暴力的关闭，如果后端有用户在连接如果用此命令会导致连接全部中断，如果发现有恶意攻击和黑客入侵的情况下可以用此命令。 ./nginx -s stop #重新加载配置文件信息。 ./nginx -s quit #优雅的关闭，如果后端有用户在连接会等待连接完成之后再去关闭，同时不会让新的请求访问进来（只针对http请求如果不是http请求时不行的）。 ./nginx -t #检测配置文件的语法是否正确。 ./nginx -v #查看当前的配置信息。 ./nginx -v #显示详细信息，包括了nginx的版本、gcc版本、configure编译路径等。 ./nginx -c #代表手动切换nginx的配置文件。 ./nginx -h & ./nginx -h #显示nginx的帮助命令。
每个worker之间相对独立，如果某个worker收到黑客的攻击，那么运维人员只需要关闭相关的worker进程，如果某个worker进程不存在只需要master重新fork以下即可。
2、修改worker的进程数
三、worker抢占机制
当client发起了请求之后client和worker之间会有一个护事锁（accept_mutex）服务端的众多worker会去抢这个锁，哪个worker抢到就由哪个worker来进行处理。
四、传统服务事件处理
假设一个client在进行请求的时候由worker1来进行处理，在处理的过程中用时比较长而且卡住了，客户端的请求就会被阻塞，假设在阻塞的过程中又有新的请求进来（假设client2、client3也同时连接到worker）要去处理。只有阻塞的请求处理完毕才回去处理client2、client3，所以master会去fork一个新worker进程。（在告并发情况下，这样的消耗会很大而且占用的资源会比较多）。
五、nginx时间处理
假设一个client在进行请求的时候由worker1来进行处理，在处理的过程中用时比较长而且卡住了。对于nginx而言是异步非阻塞的，如果发生阻塞同时又有新的请求进来那么worker会去处理下一个请求。用到的模型为epoll，（如果用到epoll那么一个worker进程可以处理6~8w的请求量，并且不会产生很多的开销），那么需要越高的并发量只需要增加服务器的配置就可以了（有钱解决）。
（一）nginx的events模块支持的多种事件模型支持的模型
nginx 的 events 模块主要用于配置 nginx 如何处理连接，它提供了多种事件模型，以适应不同的操作系统和应用场景。下面为你详细介绍 nginx 支持的主要事件模型：
1. select 模型
- 原理：
select是一种较为传统的事件驱动模型，它通过对文件描述符集合进行轮询，检查是否有文件描述符处于可读、可写或异常状态。当有事件发生时，select函数会返回发生事件的文件描述符数量，然后程序需要遍历文件描述符集合来确定具体是哪些文件描述符发生了事件。 - 适用场景：适用于连接数较少的场景，因为
select模型在处理大量连接时，轮询操作会带来较高的 cpu 开销，性能会显著下降。同时，select模型对文件描述符数量有限制，通常最大为 1024。 - 配置示例：
nginx
events {
use select;
worker_connections 1024;
}2. poll 模型
- 原理：
poll是对select模型的改进，它同样采用轮询的方式检查文件描述符的状态，但poll没有文件描述符数量的限制。poll使用一个结构体数组来存储文件描述符和对应的事件，避免了select对文件描述符数量的硬限制。 - 适用场景：适用于连接数相对较多，但仍然不是非常大的场景。相比于
select，poll在处理大量连接时性能有所提升，但在处理超大量连接时，轮询操作仍然会带来较高的 cpu 开销。 - 配置示例：
nginx
events {
use poll;
worker_connections 2048;
}3. epoll 模型
- 原理：
epoll是 linux 内核为处理大批量文件描述符而作了改进的poll，是 linux 下多路复用 io 接口select/poll的增强版本。它采用事件驱动的方式，只关注那些有事件发生的文件描述符，避免了对所有文件描述符的轮询，从而提高了效率。epoll使用内核和用户空间共享内存的方式，减少了数据的拷贝次数。 - 适用场景：适用于 linux 系统下处理大量并发连接的场景，是 nginx 在 linux 系统上的首选事件模型。
- 配置示例：
nginx
events {
use epoll;
worker_connections 65535;
}4. kqueue 模型
- 原理：
kqueue是 freebsd 系统上的一种高效事件通知机制，类似于 linux 下的epoll。它采用事件队列的方式，当有事件发生时，会将事件添加到队列中，程序可以从队列中获取发生事件的文件描述符。 - 适用场景：适用于 freebsd 系统，在处理大量并发连接时性能较好。
- 配置示例：
nginx
events {
use kqueue;
worker_connections 65535;
}5. rtsig 模型
- 原理：
rtsig是基于实时信号实现的事件模型，它通过发送实时信号来通知程序有事件发生。 - 适用场景：该模型在实际应用中使用较少，因为实时信号的处理有一些限制，并且性能不如
epoll和kqueue等模型。 - 配置示例：
nginx
events {
use rtsig;
worker_connections 1024;
}6. /dev/poll 模型
- 原理：
/dev/poll是 solaris 系统上的一种事件通知机制，它通过读取/dev/poll设备文件来获取事件信息。 - 适用场景：适用于 solaris 系统，在该系统上可以提供较好的性能。
- 配置示例：
nginx
events {
use /dev/poll;
worker_connections 65535;
}自动选择模型
如果不指定 use 指令，nginx 会根据操作系统自动选择最合适的事件模型。例如，在 linux 系统上会优先选择 epoll 模型，在 freebsd 系统上会优先选择 kqueue 模型。示例如下：
nginx
events {
worker_connections 65535;
}在实际应用中，建议根据服务器的操作系统和具体的业务场景选择合适的事件模型，以提高 nginx 的性能和稳定性。
（二）nginx默认的模型是epoll
epoll 是 linux 内核为处理大批量文件描述符而作了改进的 poll，是 linux 下多路复用 io 接口 select/poll 的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统 cpu 利用率。下面从几个方面详细介绍 epoll 模型：
基本概念
在网络编程中，服务器需要处理多个客户端的连接请求，传统的方法（如 select 和 poll）在处理大量连接时性能会下降。epoll 则通过事件驱动的方式，只关注那些有事件发生的文件描述符，避免了对所有文件描述符的轮询，从而提高了效率。
工作原理
epoll 的工作流程主要分为三个步骤：
- 创建 epoll 实例：使用 epoll_create 或 epoll_create1 函数创建一个 epoll 实例，它会返回一个文件描述符，后续的操作都基于这个描述符进行。
- 注册事件：使用 epoll_ctl 函数向 epoll 实例中添加、修改或删除需要监控的文件描述符以及对应的事件。例如，可以监控文件描述符的可读、可写等事件。
- 等待事件发生：使用 epoll_wait 函数等待事件的发生。当有事件发生时，该函数会返回有事件发生的文件描述符列表，程序可以对这些文件描述符进行相应的处理。
代码示例
以下是一个简单的使用 epoll 实现的 tcp 服务器示例代码：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <sys/epoll.h>
#include <unistd.h>
#define max_events 10
#define buf_size 1024
int main() {
int listen_fd, epoll_fd;
struct sockaddr_in server_addr;
struct epoll_event ev, events[max_events];
// 创建监听套接字
listen_fd = socket(af_inet, sock_stream, 0);
if (listen_fd == -1) {
perror("socket");
return 1;
}
// 初始化服务器地址
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_family = af_inet;
server_addr.sin_addr.s_addr = inaddr_any;
server_addr.sin_port = htons(8080);
// 绑定地址
if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) {
perror("bind");
close(listen_fd);
return 1;
}
// 监听连接
if (listen(listen_fd, somaxconn) == -1) {
perror("listen");
close(listen_fd);
return 1;
}
// 创建 epoll 实例
epoll_fd = epoll_create1(0);
if (epoll_fd == -1) {
perror("epoll_create1");
close(listen_fd);
return 1;
}
// 将监听套接字添加到 epoll 实例中
ev.events = epollin;
ev.data.fd = listen_fd;
if (epoll_ctl(epoll_fd, epoll_ctl_add, listen_fd, &ev) == -1) {
perror("epoll_ctl: listen_fd");
close(listen_fd);
close(epoll_fd);
return 1;
}
while (1) {
int nfds = epoll_wait(epoll_fd, events, max_events, -1);
if (nfds == -1) {
perror("epoll_wait");
continue;
}
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == listen_fd) {
// 处理新的连接
struct sockaddr_in client_addr;
socklen_t client_addr_len = sizeof(client_addr);
int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_addr_len);
if (conn_fd == -1) {
perror("accept");
continue;
}
// 将新的连接添加到 epoll 实例中
ev.events = epollin;
ev.data.fd = conn_fd;
if (epoll_ctl(epoll_fd, epoll_ctl_add, conn_fd, &ev) == -1) {
perror("epoll_ctl: conn_fd");
close(conn_fd);
}
} else {
// 处理客户端数据
char buf[buf_size];
ssize_t n = read(events[i].data.fd, buf, buf_size);
if (n <= 0) {
// 客户端关闭连接
close(events[i].data.fd);
epoll_ctl(epoll_fd, epoll_ctl_del, events[i].data.fd, null);
} else {
// 回显数据给客户端
write(events[i].data.fd, buf, n);
}
}
}
}
// 关闭监听套接字和 epoll 实例
close(listen_fd);
close(epoll_fd);
return 0;
}优点
- 高效处理大量连接：
epoll使用事件驱动机制，只关注有事件发生的文件描述符，避免了select和poll对所有文件描述符的轮询，因此在处理大量并发连接时性能更优。 - 内存拷贝优化：
epoll使用内核和用户空间共享内存的方式，减少了数据的拷贝次数，提高了效率。 - 水平触发和边缘触发模式：
epoll支持水平触发（lt）和边缘触发（et）两种模式，开发者可以根据具体需求选择合适的模式。
缺点
- 平台依赖性：
epoll是 linux 特有的，在其他操作系统（如 windows、macos）上无法使用。 - 实现复杂度较高：相比于
select和poll，epoll的使用和实现相对复杂，需要开发者对其原理有深入的理解。
注：worker的进程要根据cpu实际情况来定不是越高越高，如果太高会造成请求访问卡顿。影响业务的正常运行。
epoll的配置
events {
#默认使用epoll
use epoll;
#每个worker允许的客端最大连接数
worker_connections 1024;
}
以上就是nginx处理web请求机制的方法详解的详细内容，更多关于nginx处理web请求机制的资料请关注代码网其它相关文章！
发表评论