企业高性能web服务器详细讲点

一、WEB 服务基础介绍

正常情况下的单次web服务访问流程：

相关服务：美国服务器租用

1.1 互联网发展历程回顾

1993年3月2日，中国科学院高能物理研究所租用AT&T公司的国际卫星信道建立的接入美国SLAC国家实
验室的64K专线正式开通，成为我国连入Internet的第一根专线。
1995年马云开始创业并推出了一个web网站 中国黄页
1999年创建阿里巴巴www.alibabagroup.com
2003年5月10日创立淘宝网
2004年12月，马云创立第三方网上支付平台支付宝（蚂蚁金服旗下，共有蚂蚁金服支付宝、余额宝、招
财宝、蚂蚁聚宝、网商银行、蚂蚁花呗、芝麻信用等子业务板块）
2009年开始举办双十一购物狂欢节，以下是历年交易成交额：
 

2009年双十一：5000万元
2010年双十一：9.36亿元
2011年双十一：33.6亿元
2012年双十一：191亿元
2013年双十一：350亿元
2014年双十一：571亿元
2015年双十一：912.17亿元
2016年双十一：1207亿元
2017年双十一：1682.69亿元
2018年双十一：2135亿元
2019年双十一：2684亿元
2020年双十一：4982亿元
2021年双十一：5403亿元
2022年双十一：5571亿元

2012年1月11日淘宝商城正式更名为“天猫”
2014年9月19日里巴巴集团于纽约证券交易所正式挂牌上市

1.2WEB服务介绍 

1.2.1 Apache 经典的 Web 服务端

Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发
目前经历了两大版本分别是1.X和2.X
其可以通过编译安装实现特定的功能

1.2.1.1 Apache prefork 模型

预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024
每个子进程有一个独立的线程响应用户请求
相对比较占用内存，但是比较稳定，可以设置最大和最小进程数
是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景
优点：稳定
缺点：每个用户请求需要对应开启一个进程,占用资源较多，并发性差,不适用于高并发场景

 1.2.1.2 Apache worker 模型

一种多进程和多线程混合的模型
有一个控制进程，启动多个子进程
每个子进程里面包含固定的线程
使用线程程来处理请求
当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求，
由于其使用了线程处理请求，因此可以承受更高的并发
优点：相比prefork 占用的内存较少，可以同时处理更多的请求
缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超
时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用（该问题在
prefork模式下，同样会发生）

1.2.1.3 Apache event模型

Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll)
每个进程响应多个请求，在现在版本里的已经是稳定可用的模式
它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题
（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）event MPM中，会有一个专门的线程来管理这些keepalive类型的线程
当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场
景下的请求处理能力
优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放
缺点：没有线程安全控制

二、Nginx 架构和安装

2.1 Nginx 概述

2.1.1 Nginx 介绍

Nginx：engine X ，2002年开发，分为社区版和商业版(nginx plus )
2019年3月11日 F5 Networks 6.7亿美元的价格收购
Nginx是免费的、开源的、高性能的HTTP和反向代理服务器、邮件代理服务器、以及TCP/UDP代理服务
器
解决C10K问题（10K Connections）
Nginx官网：http://nginx.org
nginx的其它的二次发行版：
Tengine：由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加
了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了
很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。从2011年12月开始，
Tengine成为一个开源项目官网: http://tengine.taobao.org/
OpenResty：基于 Nginx 与 Lua 语言的高性能 Web 平台， 章亦春团队开发，官网：http://openr
esty.org/cn/

2.1.2 Nginx 功能介绍

静态的web资源服务器html，图片，js，css，txt等静态资源
http/https协议的反向代理
结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
tcp/udp协议的请求转发（反向代理）
imap4/pop3协议的反向代理

2.2.3 基础特性

模块化设计，较好的扩展性
高可靠性
支持热部署：不停机更新配置文件，升级版本，更换日志文件
低内存消耗：10000个keep-alive连接模式下的非活动连接，仅需2.5M内存
event-driven,aio,mmap，sendfile

2.2.4 Web 服务相关的功能

虚拟主机（server）
支持 keep-alive 和管道连接(利用一个连接做多次请求)
访问日志（支持基于日志缓冲提高其性能）url rewirte
路径别名
基于IP及用户的访问控制
支持速率限制及并发数限制
重新配置和在线升级而无须中断客户的工作进程
 

2.2 Nginx 架构和进程

2.2.2 Nginx 进程结构

web请求处理机制
多进程方式：服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端，直
到用户关闭连接，这样的优势是处理速度快，子进程之间相互独立，但是如果访问过大会导致服务
器资源耗尽而无法提供请求
多线程方式：与多进程方式类似，但是每收到一个客户端请求会有服务进程派生出一个线程和此客
户端进行交互，一个线程的开销远远小于一个进程，因此多线程方式在很大程度减轻了web服务器
对系统资源的要求，但是多线程也有自己的缺点，即当多个线程位于同一个进程内工作的时候，可
以相互访问同样的内存地址空间，所以他们相互影响，一旦主进程挂掉则所有子线程都不能工作
了，IIS服务器使用了多线程的方式，需要间隔一段时间就重启一次才能稳定。
Nginx是多进程组织模型，而且是一个由Master主进程和Worker工作进程组成。

主进程(master process)的功能：
对外接口：接收外部的操作（信号）
对内转发：根据外部的操作的不同，通过信号管理 Worker
监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程
读取Nginx 配置文件并验证其有效性和正确性
建立、绑定和关闭socket连接
按照配置生成、管理和结束工作进程
接受外界指令，比如重启、升级及退出服务器等指令
不中断服务，实现平滑升级，重启服务并应用新的配置
开启日志文件，获取文件描述符
不中断服务，实现平滑升级，升级失败进行回滚处理
编译和处理perl脚本
工作进程（worker process）的功能：
所有 Worker 进程都是平等的
实际处理：网络请求，由 Worker 进程处理
Worker进程数量：一般设置为核心数，充分利用CPU资源，同时避免进程数量过多，导致进程竞争
CPU资源，
增加上下文切换的损耗
接受处理客户的请求
将请求依次送入各个功能模块进行处理
I/O调用，获取响应数据
与后端服务器通信，接收后端服务器的处理结果
缓存数据，访问缓存索引，查询和调用缓存数据
发送请求结果，响应客户的请求
接收主程序指令，比如重启、升级和退出等

2.2.3 Nginx 进程间通信

工作进程是由主进程生成的，主进程使用fork()函数，在Nginx服务器启动过程中主进程根据配置文件决 定启动工作进程的数量，然后建立一张全局的工作表用于存放当前未退出的所有的工作进程，主进程生 成工作进程后会将新生成的工作进程加入到工作进程表中，并建立一个单向的管道并将其传递给工作进 程，该管道与普通的管道不同，它是由主进程指向工作进程的单向通道，包含了主进程向工作进程发出 的指令、工作进程ID、工作进程在工作进程表中的索引和必要的文件描述符等信息。 主进程与外界通过信号机制进行通信，当接收到需要处理的信号时，它通过管道向相关的工作进程发送 正确的指令，每个工作进程都有能力捕获管道中的可读事件，当管道中有可读事件的时候，工作进程就 会从管道中读取并解析指令，然后采取相应的执行动作，这样就完成了主进程与工作进程的交互。

worker进程之间的通信原理基本上和主进程与worker进程之间的通信是一样的，只要worker进程之间能够 取得彼此的信息，建立管道即可通信，但是由于worker进程之间是完全隔离的，因此一个进程想要知道另外一 个进程的状态信息,就只能通过主进程来实现。 为了实现worker进程之间的交互，master进程在生成worker进程之后，在worker进程表中进行遍历，将该 新进程的PID以及针对该进程建立的管道句柄传递给worker进程中的其他进程，为worker进程之间的通信做 准备，当worker进程1向worker进程2发送指令的时候，首先在master进程给它的其他worker进程工作信息 中找到2的进程PID，然后将正确的指令写入指向进程2的管道，worker进程2捕获到管道中的事件后，解析指 令并进行相关操作，这样就完成了worker进程之间的通信。 另worker进程可以通过共享内存来通讯的，比如upstream中的zone，或者limit_req、limit_conn中的 zone等。操作系统提供了共享内存机制

 2.2.4 Nginx 启动和 HTTP 连接建立

Nginx 启动时，Master 进程，加载配置文件
Master 进程，初始化监听的 socket
Master 进程，fork 出多个 Worker 进程
Worker 进程，竞争新的连接，获胜方通过三次握手，建立 Socket 连接，并处理请求

2.2.5 HTTP 处理过程

 2.3 Nginx 模块介绍

nginx 有多种模块
核心模块：是 Nginx 服务器正常运行必不可少的模块，提供错误日志记录 、配置文件解析 、事件
驱动机制 、进程管理等核心功能
标准HTTP模块：提供 HTTP 协议解析相关的功能，比如： 端口配置 、 网页编码设置 、 HTTP响应
头设置 等等
可选HTTP模块：主要用于扩展标准的 HTTP 功能，让 Nginx 能处理一些特殊的服务，比如： Flash 
多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
邮件服务模块：主要用于支持 Nginx 的 邮件服务 ，包括对 POP3 协议、 IMAP 协议和 SMTP协议的
支持
Stream服务模块: 实现反向代理功能,包括TCP协议代理
第三方模块：是为了扩展 Nginx 服务器应用，完成开发者自定义功能，比如： Json 支持、 Lua 支
持等
nginx高度模块化，但其模块早期不支持DSO机制;1.9.11 版本支持动态装载和卸载

模块分类：

核心模块：core module
标准模块：
 HTTP 模块： ngx_http_*
 HTTP Core modules   #默认功能
 HTTP Optional modules #需编译时指定
 Mail 模块: ngx_mail_*
 Stream 模块 ngx_stream_*
第三方模块

 2.4 Nginx安装

2.4.1 Nginx版本和安装方式

Nginx版本
Mainline version 主要开发版本,一般为奇数版本号,比如1.19
Stable version 当前最新稳定版,一般为偶数版本,如:1.20
Legacy versions 旧的稳定版,一般为偶数版本,如:1.18
Nginx安装可以使用yum或源码安装，但是推荐使用源码编译安装
yum的版本比较旧
编译安装可以更方便自定义相关路径
使用源码编译可以自定义相关功能，更方便业务的上的使用

2.4.2.Nginx 编译安装

2.4.2.1 编译安装 Nginx

官方源码包下载地址： https://nginx.org/en/download.html

编译安装示例：

nginx完成安装以后，有四个主要的目录

2.4.2.2 验证版本及编译参数

2.5 平滑升级和回滚

2.5.2 平滑升级和回滚案例

#只要make无需要make install

#查看两个版本

#把之前的旧版的nginx命令备份

#把新版本的nginx命令复制过去

#检测一下有没有问题

#回收旧版本

#检测版本信息

#回滚

#如果升级的版本发现问题需要回滚,可以重新拉起旧版本的worker

三 、Nginx 核心配置详解

3.1 配置文件说明

nginx 官方帮助文档：http://nginx.org/en/docs/
Nginx的配置文件的组成部分：
主配置文件：nginx.conf
子配置文件: include conf.d/*.conf
fastcgi， uwsgi，scgi 等协议相关的配置文件
mime.types：支持的mime类型，MIME(Multipurpose Internet Mail Extensions)多用途互联网邮
件扩展类型，MIME消息能包含文本、图像、音频、视频以及其他应用程序专用的数据，是设定某
种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动
使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。

3.2 全局配置

Main 全局配置段常见的配置指令分类
正常运行必备的配置
优化性能相关的配置
用于调试及定位问题相关的配置
事件驱动相关的配置

示例: 实现 nginx 的高并发配置：

#修改配置：vim /etc/security/limits.conf

3.3 核心配置示例

3.3.1Nginx 账户认证功能

3.3.2自定义错误页面

示例：

3.3.3自定义错误日志

示例：

3.3.4检测文件是否存在

示例: 如果不存在页面, 就转到default.html页面

3.4.5 长连接配置

四 Nginx 高级配置

4.1 Nginx 状态页 

基于nginx 模块 ngx_http_stub_status_module 实现，
在编译安装nginx的时候需要添加编译参数 --with-http_stub_status_module
否则配置完成之后监测会是提示法错误
Note
注意: 状态页显示的是整个服务器的状态,而非虚拟主机的状态
 

#配置示例：
location /nginx_status {
  stub_status;
   auth_basic           "auth login";
   auth_basic_user_file /apps/nginx/conf/.htpasswd;
   allow 192.168.0.0/16;
   allow 127.0.0.1;
   deny all;
 }
#状态页用于输出nginx的基本状态信息：
#输出信息示例：
Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
 上面三个数字分别对应accepts,handled,requests三个值
Reading: 6 Writing: 179 Waiting: 106
Active connections: #当前处于活动状态的客户端连接数
 #包括连接等待空闲连接数=reading+writing+waiting
 
accepts： #统计总值，Nginx自启动后已经接受的客户端请求连接的总数。
handled: #统计总值，Nginx自启动后已经处理完成的客户端请求连接总数
 #通常等于accepts，除非有因worker_connections限制等被拒绝的
连接
 
requests: #统计总值，Nginx自启动后客户端发来的总的请求数 

Reading: #当前状态，正在读取客户端请求报文首部的连接的连接数
 #数值越大,说明排队现象严重,性能不足
 
Writing: #当前状态，正在向客户端发送响应报文过程中的连接数,数值越大,说明
访问量很大
Waiting: #当前状态，正在等待客户端发出请求的空闲连接数
 开启 keep-alive的情况下,这个值等于active – 
(reading+writing)

 4.2 Nginx 压缩功能

Nginx支持对指定类型的文件进行压缩然后再传输给客户端，而且压缩还可以设置压缩比例，压缩后的文
件大小将比源文件显著变小，样有助于降低出口带宽的利用率，降低企业的IT支出，不过会占用相
应的CPU资源。
Nginx对文件的压缩功能是依赖于模块 ngx_http_gzip_module,默认是内置模块
配置指令如下：

#启用或禁用gzip压缩，默认关闭
gzip on | off; 
#压缩比由低到高从1到9，默认为1，值越高压缩后文件越小，但是消耗cpu比较高。基本设定未4或者5
gzip_comp_level 4;
#禁用IE6 gzip功能，早期的IE6之前的版本不支持压缩
gzip_disable "MSIE [1-6]\."; 
#gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k; 
#启用压缩功能时，协议的最小版本，默认HTTP/1.1
gzip_http_version 1.0 | 1.1; 
#指定Nginx服务需要向服务器申请的缓存空间的个数和大小,平台不同,默认:32 4k或者16 8k;
gzip_buffers number size;  
#指明仅对哪些类型的资源执行压缩操作;默认为gzip_types text/html，不用显示指定，否则出错
gzip_types mime-type ...; 
#如果启用压缩，是否在响应报文首部插入“Vary: Accept-Encoding”,一般建议打开
gzip_vary on | off; 
#预压缩，即直接从磁盘找到对应文件的gz后缀的式的压缩文件返回给用户，无需消耗服务器CPU
#注意: 来自于ngx_http_gzip_static_module模块
gzip_static on | off

 示例：#重启nginx并进行访问测试压缩功能

小于1k的文件测试是否会压缩

五 Nginx Rewrite 相关功能

Nginx服务器利用 ngx_http_rewrite_module 模块解析和处理rewrite请求
此功能依靠 PCRE(perl compatible regular expression)，因此编译之前要安装PCRE库
rewrite是nginx服务器的重要功能之一，用于实现URL的重写，URL的重写是非常有用的功能
比如它可以在我们改变网站结构之后，不需要客户端修改原来的书签，也无需其他网站修改我们的
链接，就可以设置为访问
另外还可以在一定程度上提高网站的安全性。

rewrite案例: 域名永久与临时重定向

1 永久重定向301

域名永久型调整，即域名永远跳转至另外一个新的域名，之前的域名再也不使用，跳转记录可以缓存到 客户端浏览器 永久重定向会缓存DNS解析记录, 浏览器中有 from disk cache 信息,即使nginx服务器无法访问,浏览器也 会利用缓存进行重定向 比如: 京东早期的域名 www.360buy.com 由于与360公司类似，于是后期永久重定向到了 www.jd.com 示例：

六、Nginx 反向代理功能

1.udp 负载均衡实例: DNS

stream { 
 upstream dns_server{
   server 172.25.254.20:53 max_fails=3 fail_timeout=30s;
   server 172.25.254.30:53 max_fails=3 fail_timeout=30s;
 }
   server {
   listen 172.25.254.10:53 udp;
   proxy_pass dns_server;
   proxy_timeout 1s;
   proxy_responses 1; # 使用UDP协议时，设置代理服务器响应客户端期望的数据报文数
   # 该值作为会话的终止条件
   error_log logs/dns.log;
 }
  
}
测试：
[root@apache30 named]# dig www.timinglee.org @172.25.254.10
; <<>> DiG 9.16.23 <<>> www.timinglee.org @172.25.254.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33888
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 701447f1bdd8acea0100000066a27b465426b2b4bc7f1dc3 (good)
;; QUESTION SECTION:
;www.timinglee.org.             IN     A
;; ANSWER SECTION: 

www.timinglee.org.     86400   IN     A       172.25.254.20
;; Query time: 2 msec
;; SERVER: 172.25.254.10#53(172.25.254.10)
;; WHEN: Fri Jul 26 00:20:22 CST 2024
;; MSG SIZE rcvd: 90
[root@apache30 named]# dig www.timinglee.org @172.25.254.10
; <<>> DiG 9.16.23 <<>> www.timinglee.org @172.25.254.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8932
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8ecb61bbfe2716df0100000066a27b47a3bb0c3d8e537858 (good)
;; QUESTION SECTION:
;www.timinglee.org.             IN     A
;; ANSWER SECTION:
www.timinglee.org.     86400   IN     A       172.25.254.30
;; Query time: 1 msec
;; SERVER: 172.25.254.10#53(172.25.254.10)
;; WHEN: Fri Jul 26 00:20:23 CST 2024
;; MSG SIZE rcvd: 90

2.php高速缓存

[root@Nginx ~]# rm -fr /apps/nginx/测试结果：
 
[root@Nginx ~]# tar zxf srcache-nginx-module-0.33.tar.gz
[root@Nginx ~]# tar zxf memc-nginx-module-0.20.tar.gz
[root@Nginx ~]# cd nginx-1.26.1/
[root@Nginx nginx-1.26.1]# ./configure --prefix=/apps/nginx --user=nginx --
group=nginx --with-http_ssl_module --with-http_v2_module --withhttp_realip_module
 --with-http_stub_status_module --with-http_gzip_static_module 
--with-pcre --with-stream --with-stream_ssl_module --with-stream_realip_module --
add-module=/root/memc-nginx-module-0.20 --add-module=/root/srcache-nginx-module0.33

[root@Nginx nginx-1.26.1]# make && make install
[root@Nginx ~]# vim /apps/nginx/conf.d/php.conf
upstream memcache {
   server 127.0.0.1:11211;
   keepalive 512;
}
server {
 listen 80;
 server_name php.timinglee.org;
 root /data/php;
 location /memc {
   internal;
   memc_connect_timeout 100ms;
   memc_send_timeout 100ms;
   memc_read_timeout 100ms;
   set $memc_key $query_string; #使用内置变量$query_string来作为key
   set $memc_exptime 300; #缓存失效时间300秒
   memc_pass memcache;
 }
 location ~ \.php$ {
 set $key $uri$args; #设定key的值
   srcache_fetch GET /memc $key; #检测mem中是否有要访问的php
   srcache_store PUT /memc $key; #缓存为加载的php数据
   fastcgi_pass 127.0.0.1:9000;
   fastcgi_index index.php;
   include fastcgi.conf;
 }
}
[root@Nginx ~]# systemctl start nginx.service

测试结果

[root@apache20 ~]# ab -n500 -c10 http://php.timinglee.org/index.php
Concurrency Level:     10
Time taken for tests:   0.255 seconds
Complete requests:     500
Failed requests:       0