学习笔记 -- Nginx(持续更新中)
一、基础
1.1、概念
1.1.1、概念
Nginx 是一个高效率的 HTTP 和逆向代理 web 服务器,并支持 IMAP、POP3 和 SMTP 服务。它是由俄罗斯市场中流量排名第二的 Rambler.ru 网站的开发者伊戈尔·赛索耶夫负责开发,并在遵循基于 BSD 许可证开放获取的方式下开源了其源代码。该服务器以其稳定运行、全面功能集合以及易于配置的特点而著称
1.1.2、用途
- 发布静态网站:Nginx能够发送由服务器存储的静态文件(如HTML文档、图片)至浏览器端设备。
- 做前后端分离:通过将前端项目的代码打包至html文件夹中进行部署即可实现。
- 反向代理:当一个网络请求抵达反向代理服务器实例(例如运行Nginx的应用),该服务会自动转发请求至后端服务器,并返回结果。
- 负载均衡:当单台服务器无法应对高并发访问时,则可配置Nginx执行负载均衡功能。
- 虚拟主机功能:对于需要分发请求至多台后端服务器的应用场景,在配置Nginx时需选择合适的虚拟主机方案。
- Nginx还支持HTTPS协议下的安全连接以及WebSocket等实时通信协议的应用场景。
1.2、Nginx常用版本
1.3、目录结构
1.usr/local/nginx/conf
该目录将其Nginx主配置文件设置为nginx.conf$, 并在其中调用其他相关子配置文件。
2.usr/local/nginx/html
存放一些静态页面
3.usr/local/nginx/logs
记录访问日志。
nginx.pid:记录了nginx的进程的ID号
1.4、nginx原理

二、配置文件
2.0、配置文件作用域
在Nginx配置文件中定义的作用域是指那些在特定上下文中执行配置指令的有效范围。Nginx提供了多种作用域类型可供选择,并且每个Scope都指定了适用一组Config指令的操作范围。建议通过http、server 和location 配置块来实现不同层级的设置目标,并且这些配置块分别对应不同的Scope类型,在此框架下您可以实现对全局配置、虚拟主机设置以及特定URL路径管理等功能的灵活操作与控制
-
Global Scope:
-
Definition: Global Scope refers to the operational range of configuration directives applied across the entire Nginx server.
-
Function: Configuration directives within the Global Scope take effect across the entire server, encompassing default parameters, logging settings, event handlers, and other related configurations.
-
Location: Specified at the outermost level of the configuration file, excluding any
http,server, orlocationblocks. -
Use Cases: This scope is utilized for establishing global default values, defining log recordation rules, configuring event handlers, setting security policies, and managing extension modules.
-
Http 作用域:
-
说明:Http 作用域是指适用于 Http 协议层面的配置指令范围。
-
其影响:在其下的 location 块生效。
-
位置说明:配置位于顶层。
-
具体应用:用于全局设置诸如 keepalive 参数、日志格式和缓存策略等。
-
** server domain ** :
-
定义: server domain 即为针对单一虚拟主机(server)配置指令的有效范围。
-
作用: server domain 内部设置涵盖设置包括但不限于:端口监听、域名绑定以及SSL证书配置。
-
配置位置:该设置特别适用于位于http块中的相关参数调整。
-
示例用途:通过该领域设置可实现对独立虚拟主机的个性化配置管理。
-
作用域定位:
-
定义:location 作用域是指根据请求路径的不同匹配特定配置规则的区域。
-
功能:位于该作用域内的配置指令仅影响特定 URL 路径,并支持代理设置、缓存管理及权限控制等功能。
-
配置位置:此定位机制位于 server 块内部。
-
举例说明:该机制可依据不同 URI 路径分别设定相应的规则,在具体应用中可据此实现针对不同 URL 路径实施代理策略、缓存管理以及权限控制等功能。
2.1、基本配置
worker processes 1; # 工作的进程个数,默认为1,表示开启一个业务进程。
events ( # 事件驱动模块
worker_connections 1024; # 每一个worker进程能创多少个连接。
http {
include mime.types;# 引用另外的配置文件,引入http mime类型。
default_type appllcation/octet-stream;# 默认此格式
sendfile on;# 数据0拷贝 使用linux的`sendfile(socket, file, len)`高效网络传输,也就是数据拷贝
keepalive timeout 65;# 保持连接超时
server { # 一个虚拟主机
listen 80:# 监听端口号
server_name localhost;#主机名(域名或者主机名)
location / { # uri(域名后面的字符串)
root html; # 相对路径,usr/local/nginx
index index.html index.htm:
}
error_page 500 502 503 504 /50x.html;
}
conf

2.2、一些配置的匹配规则
2.2.1、server_name
在Nginx环境中,server配置块被用来设置虚拟服务器,并依据不同的匹配标准来设置相应的服务器配置。
精确匹配(=)
使用完全匹配的字符串来匹配请求。
server {
listen 80;
server_name = example.com;
...
}
bash
只会匹配域名为 example.com 的请求
普通字符串匹配
使用普通的字符串来匹配请求,不支持正则表达式。
server {
listen 80;
server_name example.com;
...
}
bash
会匹配域名为 example.com 或 www.example.com 的请求
正则表达式匹配( ~ 和 ~ *)
采用正则表达式来进行请求的匹配操作。其中在进行模式匹配时使用``~符号以区分大小写字母,在模式不敏感的场景下则使用``~*符号。
server {
listen 80;
server_name ~ ^www\.example\.com$;
...
}
bash
将对来自域名 www.example.com 的请求做出处理。通过指定参数 ~* 来忽略大小写差异,举个例子:server_name ~* ^www\.example\.com$; 将对来自域名 WWW.EXAMPLE.COM 的请求做出处理。
最长前缀匹配(^~)
使用最长前缀匹配规则,如果找到匹配项,则停止搜索其他匹配项。
server {
listen 80;
server_name ^~ www.example.com;
...
}
bash
该系统能够处理以 example.com 和 www.example.com 为域名的请求,并不包含来自 images.example.com 的访问。
默认匹配(*)
使用通配符来匹配所有请求,通常用于处理未匹配到的请求。
server {
listen 80 default_server;
server_name *;
}
bash
会匹配所有域名的请求
优先级
从高到低为:= 、^、或~、普通字符串匹配、 。
2.1.2、Location匹配规则
静态文件匹配规则:
location等于/ path至file { ... }:对应指定文件路径并赋予最高优先权。
location位于/ path至directory { ... }:对应指定目录路径。
location经过~* \.(jpg|png|gif) $ { ... }:识别以jpg png gif结尾的文件。
动态文件匹配规则:
location ~* ^/api/ { ... }:匹配以/api/开头的路径。
location ~* \.php$ { ... }:匹配以.php结尾的路径。
通用匹配规则:
location / { ... }:匹配所有路径,优先级最低。
否定匹配规则:
The regex does not match paths starting with /admin/.
字符串匹配规则:
location = /exact/match { ... }:被精确地用于完全匹配指定的字符串。
location ~* ^/prefix/ { ... }:被精确地用于被以/prefix/开头进行匹配。
location ~* \.suffix$ { ... }:被精确地用于被以.suffix结尾进行匹配。
三、虚拟主机与域名解析
3.1、域名、dns、ip地址的关系
- 一个IP地址可能对应多个网站或组织的域名。
- 每个IP地址都是由一系列数字组成的标识符。
因此有了网站名称(即域名),人们可以通过它快速定位到对应的服务器。 - 在互联网中, 域名与IP地址之间是一一对应 (有时也可能是多对一)的关系, 域名系统负责将网站名称转换为对应的网络通信端口, 这种转换过程称为DNS解析, 网络设备如路由器会根据需求自动完成这一工作流程, DNS系统就是专门用于完成这种解析任务的服务设施。
- 每个IP地址都是由一系列数字组成的标识符。
3.2、浏览器、Nginx 与http协议

3.3、虚拟主机原理
Nginx采用特殊的软硬件划分网络资源的技术体系,在线划分每一台物理计算机为独立运行的多台虚拟主机系统,在线实现各自对外提供WWW服务功能组合模式下完成一台物理机多端口多服务功能扩展目标体系架构方案设计目标达成过程。
Nginx提供三种基本类型的虚拟主机配置方案设计思路:基于IP地址的空间分布型、基于DNS域名称的空间分布型以及基于端口号的空间分布型;其中基于域名的空间分布型配置特点在于通过IP地址与服务器资源绑定关系建立DNS域名称到服务器资源映射关系机制。
基于域名的空间分布型要求实现多个DNS域名称映射到同一台Nginx服务器系统中,在线构建DNS域名称到应用服务响应对象映射关系机制;当客户端发送特定DNSServer请求时系统自动识别对应应用服务响应对象并返回相应结果;这样就能实现不同DNSServer请求返回不同网页内容的工作原理支撑体系设计思路。
3.4、域名解析与泛域名解析
3.4.1、本地配置域名解析
C盘 > Windows > System32 > drivers > etc下的hosts文件
添加格式

3.4.2、公网服务器配置域名解析(华为云为例)
1.解析域名
其他几家也差不多





只需要填这两个,其他默认就行
2.域名类型

3.4.3、泛解析
主机记录填写一个*,表示泛解析,就是解析所有*.mofeng759.top

3.4.4、域名解析相关企业项目技术架构
多用户2级域名

短网址
- 长端口技术的本质是实现不同设备之间跨越物理距离的数据传输
- 长端口技术的应用场景主要集中在以下领域
1 在此方案中
2 我们采用了基于协议栈的安全通信机制
3 所有通信过程均需遵循严格的认证流程
4 每个设备都需要具备相应的身份认证信息
5 整个通信过程采用双向认证机制以提高安全性
用户点击一个简短的链接。
该服务接收到用户发送来的请求。
系统通过数据库查找对应于该短链接的完整URL。
随后系统会将用户自动重定向到完整的URL地址。
这样做的好处是可以让用户方便地分享和记忆这个长URL。
通过短链接服务可以实现将长URL转换为易于传播和记忆的一个简短地址。
这种服务不仅能够节省字符空间还能提高信息传播效率并带来更好的用户体验。
3.5、Nginx中的虚拟主机域名配置
3.5.1、多虚拟主机配置
设置虚拟主机时需要确保不同域名的端口号不重复使用。每个域名只能分配一组特定的端口,并且各域名的端口号必须唯一。
http {
include mime.types;# 引用另外的配置文件,引入http mime类型。
default_type appllcation/octet-stream;# 默认此格式
sendfile on;# 数据0拷贝 使用linux的`sendfile(socket, file, len)`高效网络传输,也就是数据拷贝
keepalive timeout 65;# 保持连接超时
server { # 配置第一个虚拟主机
listen 80:# 监听端口号
server_name 域名1;#主机名(域名或者主机名)
location / { # uri(域名后面的字符串)
root html; # 相对路径,usr/local/nginx
index index.html index.htm:
}
error_page 500 502 503 504 /50x.html;
server { # 配置第二个虚拟主机
listen 80:# 监听端口号
server_name 域名2;#主机名(域名或者主机名)
location / { # uri(域名后面的字符串)
root html; # 相对路径,usr/local/nginx
index index.html index.htm:
}
}
conf

四、反向代理案例
4.1、概念
4.1.1、反向代理
反向代理机制,则它处于目标服务器和客户端之间,并隐藏了真实的服务器IP地址;看起来像直接与代理服务器通信。在这种情况下;代理服务器会接收并转发来自客户端的请求;并将请求转发到目标服务器获取数据;并将其数据返回给客户。客户对这一过程是完全无感知的;因为它无需任何配置即可访问相关服务或资源。

4.1.2、正向代理
正向代理又称为代理服务。一般设置在客户端与目标服务器之间。其主要功能是协助客户端接入外部网络资源。配置好之后,在使用时可以通过代理服务器完成对互联网资源的访问。

4.1.3、网关
- 网关是一种计算机系统或设备,在上层网络之间建立连接并实现互连功能。它承担着转换角色,在需要时将不同通信协议、数据格式或语言的信息重组以适应目标系统的具体需求。
- 网关作为一种服务角色与反向代理具有相同功能,并共同承担着将外部请求发送至目标服务器的任务;然而它们的应用场景存在明显区别。
- 反向代理的作用是将客户端请求转发给相应服务器进行处理。
- 正向代理则相反。
4.2、应用中的使用
4.2.1、流程图
1.传统应用



2.传统应用



4.3、负载均衡
4.3.1、概念
- 负载均衡建立于现有网络架构之上,并采用了高效透明的技术手段来增强网络设备与服务器的带宽能力、提升系统吞吐量以及优化数据处理性能。这种技术方案显著提升了网络架构的灵活性与可靠性。
- 负载均衡的核心概念在于将任务分散到多个执行单元中进行处理。具体而言,在Web服务领域主要应用于Web服务器,在文件传输方面则涉及FTP服务器,在企业关键业务中则包括企业级应用服务器和其他重要任务型服务器等多场景应用领域中发挥重要作用。
4.3.2、负载均衡配置
upstream httpds{
server 191.xxx.xx.xxx:80;
server 192.xxx.xx.xxx:80;
server 193.xxx.xx.xxx:80;
}
server { # 配置第一个虚拟主机
listen 80:# 监听端口号
server_name ~^[0-9]+\.xxxx\.com$;#主机名(域名或者主机名)
location / { # uri(域名后面的字符串)
proxy_pass http://httpds
#proxy_pass http://www.xxx.com;#
#proxy_pass http://xxx.com;#重定向到此网址,地址栏会变
#root html; # 相对路径,usr/local/nginx
#index index.html index.htm:
}

4.3.3、负载均衡策略
1.权重/上下线/备用机
该方案是对轮询机制的一种优化升级策略,在实现资源分配公平性方面具有显著提升效果。
upstream httpds{
server 191.xxx.xx.xxx:80 weight=6;
server 192.xxx.xx.xxx:80 weight=4 down;#down 表示不参与负载均衡
server 193.xxx.xx.xxx:80 weight=2;
server 193.xxx.xx.xxx:80 weight=1 backup;# backup代表备用服务机器
}
bash
2.轮询
- 每个请求依次按照时间序列分配给不同的后端服务器,并形成一种环形队列结构。
- 前端调度器通过'心跳机制'来实现与各后端服务器之间的状态监控。
- 一旦发现某台后端服务器出现故障,则将其从队列中移除。
- 这种安排特别适用于那些无需维持会话的状态。
- 其主要缺陷在于无法持久保存会话信息。
3.ip hash
负载均衡器采用了基于客户端IP地址的负载分配策略,在确保来自同一客户端的所有请求始终定向到同一服务器的同时,在网络层面上实现了会话连接的一致性与稳定性。
4.least Connections
把请求转发给连接数最少的后端服务器。
5.url hash(第三方)
- 将所有URL路由至同一个后端服务器,并需配合缓存机制以提升访问效率。
- 特别适合用于访问固定资源时。
4.4、动静分离
4.4.1、使用场景
在Web开发领域中,动静分离是一种普遍采用的设计模式,在优化服务器性能和提升用户体验方面发挥了重要作用。这种设计模式的主要理念是将动态请求与静态请求区分开来处理:动态请求由后端服务器负责处理,并通过部署专门的静态服务器来管理静态资源的需求。这种方法不仅有助于减轻后端服务器的工作负担、提高静态资源的加载速度以及增强前后端系统的独立性与可维护性等关键方面;还能够有效支持高并发场景下的业务需求,并通过解耦前端与后端的方式显著简化系统架构设计;此外,在某些特殊场景下还可以实现无状态服务的目标
4.4.2、配置动静分离
server {
listen 80;
server.name localhost
location / {
proxy_ pass http://192.161.44.104:8080;
}
location /css {
root html;
}
location /js {
root html;
}
location /img {
root html;
}
}
java

4.5、URLRewrite
4.5.1、URLRewrite的使用场景
URLRewrite是一种服务器端重写URL的技术,它的使用场景非常广泛。
- 将旧域名重定向至新域名。
如果公司更换了域名可以通过URLRewrite规则将旧的域名重定向至新的域名同时保持参数不变 这样输入旧域名会自动跳转到新的域名。 - 根据客户端IP地址进行访问跳转。
在某些情况下 可能需要根据客户端的IP地址进行访问跳转 例如 当某个版本上线时 可能希望所有的IP访问任何内容都显示一个固定的维护页面 只有公司IP访问正常 这种情况下可以通过URLRewrite来实现。 - 优化URL结构。
偶尔 URL 结构可能会显得复杂 需要将其简化 例如 将动态生成的 URL 中的参数部分进行重写 使其看起来更加整洁明了。 - 实施静态资源映射。
可以将经常被访问的静态资源映射到单个文件上 从而提高服务器性能 例如 将所有的图片请求映射到index.php文件中 由该文件来处理图片请求并返回相应的图片。 - 安全处理敏感信息。
对于包含敏感信息的 URL 可以通过URLRewrite规则对其进行处理和替换 这样可以帮助保护用户隐私和数据安全。 - 提升搜索引擎优化效果(SEO)。
URLRewrite可以帮助改善网站的搜索引擎优化效果 通过重新设计 URL 结构 可以让搜索引擎更好地理解和索引网站内容 进而提高网站的排名和收录情况。
4.5.2、配置格式
rewrite <regex> <replacement> [f1ag];
关键字 正则 替代内容 flag标记
bash
- flag标记说明:
last:执行完后继续执行后续的location URI规则。break:执行后立即停止不再执行后续规则。redirect: redirect导致浏览器跳转至目标URL并显示该URL。permanent: permanent导致浏览器永久性地将当前页面重定向至目标URL。
4.5.3、配置示例
在Nginx中,URLRewrite可以通过使用正则表达式和特定指令来实现。
使用rewrite指令进行URL重写。
将所有的请求重定向到index.html文件。
location / {
rewrite ^(.*)$ /index.html?$1;
}
bash
使用try_files指令来尝试访问文件
如果文件不存在则重定向到其他URL。
location / {
try_files $uri $uri/ /404;
}
bash
首先尝试访问请求的文件,如果文件不存在,则重定向到404页面。
location / {
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
bash
通过error_page命令来路由错误页面的请求。例如,在下面的配置项中将所有返回状态码为500的错误请求路由至500.html页面.
4.5、防盗链
4.5.1、概念
- 这是一种技术手段,即某些网站为了避免被广告拦截器拦截,无需直接提供内容,而是通过技术手段绕过广告放置页面,并在自己的商业利益页面上展示所需内容。
- 更具体地说,防盗链问题的根本原因在于一些小型网站非法复制并放置大型网站的关键字链接(例如音乐、图片、软件下载等)。这种行为使得这些小网站能够获取大量流量和资源。
- 例如,如果一个网站缺少某个页面所需的信息(如图片信息),那么该页面完全可以将该图片链接转接到其他网站上展示给浏览者。这样不仅减少了资源的浪费,还能提高自身流量等级。
- 显然这种做法对于被利用资源的网页来说是不公的。
4.5.2、配置
valid_referers none | blocked | server_names | strings .....
bash
- 空字符串用于检测Referer头域不存在的情况。
- 当Referer被防火墙或代理服务器删除或伪装时。
- 此时该字段不以
"http://"或"https://"开头。
- 此时该字段不以
- 创建一个包含多个URL的列表用于检测Referer头域是否属于这些URL之一。
打开Nginx的配置文件(通常是nginx.conf)。
为保护服务器指定防盗链配置,请在[服务器块]中应用location指令以确定需受保护的资源位置。例如,在防护图像资源时,请配置如下:
bash
server {
…
location /images/ {
valid_referers none blocked example.com;
if ($invalid_referer) {
return 403;
}
}
…
}
需要在location中配置
server {
...
location /images/ {
valid_referers none blocked example.com;
if ($invalid_referer) {
return 403; #状态码
#rewrite ^/ /img/x.png #返回图片
#return 401; #跳转界面
}
}
# 401跳转的界面
error_page 401 /401.html;
location = /401.html {
root html;
}
}
bash

在配置文件中定义了valid_referers指令用于指定可被访问的有效来源(referer)。在此示例中,默认仅当请求来源于example.com时才允许访问/images/目录下的资源。若来源不在预先列出的列表中,则将变量invalid_referer置为true值。于location块内采用if指令判断invalid_referer变量的状态。若结果为真,则将返回适当的错误响应(包含相应错误页面或报错图片),例如返回403 Forbidden状态码以阻止未授权访问的操作。
4.6、高可用配置
4.6.1、原理图

4.6.2、安装(yum)
1.命令
yum install keepalived
bash
2.配置文件位置
/etc/keepalived/keepalived.conf
bash
3.修改配置文件
注意:配置文件很多内容,其他的没啥用,不用管,可以删除,也可以留着,下面的才是重点配置文件。
主设备配置
! Configuration File for keepalived
global_defs {
router_id lb111
}
vrrp instance 主设备实例名 {
state MASTER 当前机器名
interface ens33 网卡名
virtual_router_id 51
priority 100 优先级
advert int 1 间隔检测时间
authentication { 认证(同一组的认证配置)
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { 虚拟地址
168.44.200
}
}
bash

备用机设置
! Configuration File for keepalived
global_defs {
router_id lb111
}
vrrp instance 备用机实例名 {
state BACKUP 当前机器名
interface ens33 网卡名
virtual_router_id 51
priority 50 优先级
advert int 1 间隔检测时间
authentication { 认证(同一组的认证配置)
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { 虚拟地址
168.44.200
}
}
bash

注意:主机备用机的virtual_router_id
4.启动
systemctl start keepalived
bash
4.7、https配置
4.7.1、非对称加密
1、概念
- 非对称加密,也称为公钥加密,是一种加密算法,使用了一对密钥:公钥和私钥。公钥是公开的,可以与任何人共享,而私钥则是保密的,只有密钥的持有者可以访问。
- 在非对称加密中,使用公钥加密数据,而私钥用于解密数据。加密的数据只能用对应的私钥进行解密。这种加密方式提供了更高的安全性,因为攻击者即使获得了公钥,也无法通过公钥逆推出私钥,从而无法解密数据。
- 非对称加密常用于安全通信和数字签名。在安全通信中,发送方使用接收方的公钥加密消息,只有接收方可以使用其对应的私钥解密消息。这样可以确保消息在传输过程中不被窃取或篡改。在数字签名中,发送方使用自己的私钥加密消息摘要,接收方可以使用发送方的公钥验证数字签名的真实性。
- 常见的非对称加密算法包括
RSA(Rivest-Shamir-Adleman)和椭圆曲线密码学(Elliptic Curve Cryptography, ECC)。这些算法在保护敏感数据和确保通信安全方面发挥了重要作用。
2、流程
非对称加密的信息处理流程如下:
- 钥匙生成步骤:首先需要先制作一组钥匙组合包涵公钥与私钥这对钥匙集合必须严格保密仅限授权持有者使用
- 数据加密过程:发送端利用接收端提供的公开钥匙完成待保护信息的编码工作这一过程通常采用基于RSA或其他公匙算法的技术将原始明文转化为难以破译的密码文字
- 密码传递环节:编码完成后将此难以解读的信息通过安全通信渠道传递给受信任的对象这一阶段确保了所有参与者的通信活动均处于监管之下防止潜在的安全威胁
- 解码接受阶段:受体端通过个人拥有的专用钥匙进行信息还原工作这一步骤依赖于与前述使用的公匙算法相对应的私匙机制能够精准地恢复出原始的信息内容
- 对于数据机密性的保护是使用非对称加密系统的主要目标。
为了进一步确认数据的真实性和完整性, 可以采用数字签名的方式进行额外认证。
数字签名的具体流程如下:
- 生成密钥对: 发送方需生成一对私钥与公钥, 其中私钥用于创建数字签名, 公钥则用于验证该签名。
- 制作数字签名: 发送方通过选用私钥签名算法(如RSA)将待 signing的数据摘要转换为具体的数字签名。
- 传递文件及数字文件: 在传递文件的同时, 也应一并传递该文件所对应的数字签名, 接收端则需分开接收这两部分信息进行处理。
- 验证过程: 接收端利用发送方的公钥来解码接收到的数字并验证其有效性, 通过解码得到的数据摘要应与原始文件内容完全一致, 才能确认文件未被篡改且其完整性得到保障。
*采用非对称加密与数字签名相结合的方式进行应用,在确保数据的安全性(机密性、完整性和真实性)的基础上实现双方通信的安全性和可靠性。
4.7.2、CA机构
- CA机构主要职能包括:负责颁发与管理数字证书的事务性工作。数字证书是用于网络环境内身份验证与通信加密的关键工具。该机构通过数字签名机制对电子证书进行认证与验证,从而保障其真实性与可靠性。
- 在颁发数字证书之前,CA机构将对申请者身份实施识别流程。具体而言,在颁发特定类型电子证书时需核验身份证件有效性、单位注册证明材料及授权拥有相关域名等必要条件。
- 当发现电子证书存在密钥泄露或失效情况时,CA机构将采取措施处理过期或无效的电子证书,并将其信息记录于电子吊销清单中(Certificate Revocation List,CRL)。该操作有助于防止持有无效电子证书人员的安全漏洞暴露。
- CA机构负责电子证书的全生命周期管理,包括但不限于电子证书的生成、更新、撤销等相关操作,同时该机构还承担着密钥对生成与存储的责任,确保私钥的安全性与可用性。
- CA机构还会发布基础认证电子证书(Root Certificate),它是整个电子签名体系的基础架构元素。该基础认证电子书由CA自签名生成,并广泛应用于验证下级CA机构所发行的相关电子书证
基于与CA机构的合作关系,个人及组织能够获取经过认证并签名的电子数字证书,在线身份与通信的安全性得到保障;CA机构的持续运行则确保了电子数字证书的有效性和全球通用性。
4.7.3、Https证书配置
五、扩容
5.1、扩容方式
单机垂直方向上的扩容旨在提升硬件资源规模。
在系统架构设计中,采用集群化的扩展模式能够有效提升性能。
其中包含以下三个关键模块:
-
数据划分模块,该模块将基于Service-Oriented Architecture(SOA)优化原则,实现对数据的高效管理与处理。
-
上游服务进行SOA化改造,以支持原有的水平和垂直方向上的容量扩充需求。
-
实现入口切分优化,从而进一步提升系统的可扩展性与性能表现。
针对移动设备生态,我们聚焦于以下应用场景:
移动设备原生应用(物联网场景)
基于H5技术的嵌入式应用方案设计 -
数据异构化
1. 多级缓存
客户端缓存
CDN缓存
异地多活
Nginx缓存 -
服务异步化
4. 拆分请求
5. 消息中间件
- 扩容原则
- 无状态原则
- 弹性原则
5.2、单机垂直扩容
- 云服务资源得到扩展。
-
整机设备包括IBM、浪潮、DELL和HP等主流品牌。
-
CPU和主板均采用主流配置。
-
网络接口采用10G/40G百兆网络技术。
-
磁盘存储方案包含以下类型:
- 机械硬盘(SAS/SCSI)、混合硬盘(HHD)、固态硬盘(SSD)包括 SATA型态、PCI-e型态以及 MVMe型态。
- 固态硬盘具有快速访问速度的特点但可能存在较高的故障发生率。
- 系统盘或热点数据存储通常会采用多副本机制以确保数据安全性和可靠性。
- 多副本机制可提升数据冗余度
- 系统盘或热点数据存储通常会采用多副本机制以确保数据安全性和可靠性
- 数据冗余度的提升有助于保障关键业务系统的稳定性运行
- 值得注意的是虽然固态硬盘在性能上有显著优势但仍需警惕其可能出现的故障风险
- HDD(速度低,但故障率低,存储内容更多)
- 冷数据存储
- 机械硬盘(SAS/SCSI)、混合硬盘(HHD)、固态硬盘(SSD)包括 SATA型态、PCI-e型态以及 MVMe型态。
-
5.3、水平扩展
5.3.1、会话管理
Nginx高级负载均衡
ip_hash; :响应用户提交的请求获取其IP地址,并随后将其转换为哈希值后分配至指定的服务节点。

适用于中小型项目的快速扩展,并可能导致上下文信息丢失
其他Hash 1. hash $cookie_ jsessionid; : cookie中的jsessionid(由tomcat生成)进行Hash。

2. `hash $request_uri;`
- 使用lua逻辑定向分发
- Redis + SpringSession
5.3.2、sticky模块应用完成对Nginx的负载均衡
1、安装sticky模块
- 使用参考
tengine中有session.sticky模块我们通过第三方的方式安装在开源版本中 - sticky是第三方模块,需要重新编译Nginx.他可以对Nginx这种静态文件服务器使用基于cookie的负载均衡
1.
下载模块
该项目的官方网站:项目官网、其他版本:另外一个版本、获取:下载

2.
上传解压
3.
基于openssl-devel进行安装,请前往源码目录并按照指示进行安装
./configure --prefix=/usr/local/nginx --add-moudle=/root/nginx-goodies-nginx-sticky-module-ng-c78b7dd79d0d
bash
通过调用--add-moudle参数可以实现第三方模块的加载。
指定插件安装路径为 /root/nginx-goodies-nginx-sticky-module-ng-c78b7dd79d0d 。
4. 运行Make指令以生成相应组件。
在遇到构建错误时可参考相关文档进行排查。

定位Nginx的根目录,并启动 ngx_http_sticky_misc.h文件,在引用时添加下面内容
#include <openssl/sha.h>
#include <openssl/mds.h>
bash

6. 重新configure
./configure --prefix=/usr/local/nginx --add-moudle=/root/nginx-goodies-nginx-sticky-module-ng-c78b7dd79d0d
bash
- 然后重新
make - 升级检测
记得备份好原程序(不然升级会将修改恢复)
mv /usr/local/sbin/nginx /usr/local/sbin/nginx.old
bash
升级检测
make upgrade
bash
把编译好的Nginx程序替换到原来目录里
cp objs/nginx /usr/local/nginx/sbin/
bash
- 检查程序中是否包含新模块
nginx -v
bash
2、使用sticky模块
- 默认会下发一个
route的cookie

- 配置方法
upstream httpget {
sticky name=route expires=6h;
server 192.168.44.102;
server 192.168.44.103;
}
bash
固定名称:Cookie名称,请确保不要与Tomcat下发的JESSIONID冲突。
expires:Cookie的有效期限
固定名称:Cookie名称,请确保不要与Tomcat下发的JESSIONID冲突。
expires:Cookie的有效期限
5.4、Keepalive
5.4.1、浏览器演示

5.4.2、使用场景
- 显然用户的预期是会有后续的操作需求。
- 重用连接能够有效减少通信中的握手次数,并且特别地,在https协议下建立一次连接所需的开销会显著增加。
- 不使用
- 通过缓存机制实现内联资源访问,并无需依赖keepalve机制。
- 长驻 TCP 连接可能导致系统资源的无效耗损。
5.4.3、配置
5.4.3.1、 图解




5.4.3.2、配置详解
- 该指令 实现功能模块以阻止特定浏览器使用KeepAlive *
作用
语法
默认
参数说明
配置位置
keepalive_timeout指令
作用 :用于指定keepalive连接的超时时间。若无新请求抵达该时间点前,则会关闭连接;根据应用需求优化此参数可实现对保持连接时间和资源消耗的平衡控制;设为零则关闭该功能。
语法格式 :keepalive_timeout 75;
**默认设置为75秒。
位置:在http、server和location配置块中使用。
作用:指定每个keepalive连接允许的最大请求数。请求数量超出该数值后会导致连接关闭以防止潜在的问题。
语法:keepalive_requests 100;
默认值为100。
位置:该指令位于http、server和location配置块内使用。
- 指定命令
作用:该命令的作用是定义两次向客户端发送响应之间的间隔超时时间,并且一旦发生超时就会关闭连接(因为耗时的同步操作可能会丢弃用户的连接),需要注意的是该超时时间必须不低于keepalive_timeout的时间设置。
语法:send_timeout 60;
默认值:60秒。
位置:该命令可以在http配置块、server配置块以及location配置块中找到使用场景。
keeplive_time指令
功能:设置保持连接的最大时长限制。
语法:表示时长的方式包括秒数/小时格式;例如:3600s/1h;
默认值:默认设置为一小时保持连接状态。
位置:该指令配置项主要设置在HTTP服务器端以及位于location配置块中的相关位置。
5.4.3.3、对上游服务器做配置
建议先设置好HTTP/1.1协议以实现传输效率的提升,在HTTP/1.0协议的基础上进行进一步优化和功能扩展。为了确保Upstream中的上游服务器能够默认设置为短连接,请在应用层进行相应的参数配置;此外,在服务器端详细说明如何进行相应的设置以确保每个请求完成后都会立即断开。
proxy_http_version 1.1; # 配置http版本号,默认使用http1.0协议,需要在request中增加“Connection: keep-alive” header才能够支持,而HTTP1.1默认支持。
proxy_set_header Connection "";# 默认是close,需要设置为空,开启长连接。
配置
keeplive 功能:用于保留上游服务器的连接数。
书写规范:keeplive <保留连接数>;
配置项位于 upstream 设置块内。
-
$\texttt{keeplive\_timeout}$
功能:用于连接保留时间。
语法:\texttt{keeplive\_timeout} = 100;
位置:位于 upstream 配置块内部. -
keeplive_requests
功能 :在一个TCP复用中可以并发接收的请求数量上限被指定为100。
语法 :keeplive_requests 100;
设置位置 :该变量位于上游配置块内。
5.4.4、Charles(抓包工具)
CharlesProxy公司提供官方访问下载链接以及官方网站获取最新版本的 CharlesProxy软件
5.5、Apache Benchmark压力测试
5.5.1、安装
1、命令
yum install httpd-tools
bash
5.5.2、使用
1、命令
- 简单压测示例
ab -n 10000 -c 30 http://ip/
bash



2、结果说明
完成了1000次请求。
完成了1万次请求。
服务器软件。
服务器主机名。
服务器端口。
文档路径。
文档长度。
并发度。
测试所需时间。
成功请求次数。
失败请求次数。
写入错误次数。
总数据传输量:其中包含HTML内容的数据传输量。
每秒请求数(QPS),即每秒并发量。
每个请求数值响应延迟(响应延迟):指从发送到收到确认的时间总长(单位:秒);
数据传输吞吐量:指系统在单位时间内处理的数据总量(单位:kb/s或mb/s);
3、参数说明
-n: 即requests,用于指定压力测试总共的执行次数。-c:即concurrency,用于指定的并发数。-t:即timelimit,等待响应的最大时间(单位:秒)。-b:即windowsize,TCP发送/接收的缓冲大小(单位: 字节)。-p:即postfile,发送POST请求时需要上传的文件,此外还必须设置-T参数。- ``-u: 即
putfile,发送PUT请求时需要上传的文件,此外还必须设置-T参数。 -T:即content-type,用于设置Content-Type请求头信息, 例如:applcaton/-www-form-urlencoded,默认值为text/plain。-v:即verbosity,指定打印帮助信息的冗余级别。-w:以HTML表格形式打印结果。-i:使用HEAD请求代替GET请求。-x:插入字符串作为table标签的属性。-y:插入字符串作为tr标签的属性。-z: 插入字符串作为td标签的属性。-C: 添加cookie信息,例如:"Apache= 1234"(可以重复该参数选项以添加多个。-H:添加任意的请求头,例如:"Accept-Encoding: gzip"请求头将会添加在现有的多个请求头之后可以重复该参数选项以添加多个)。-A:添加一个基本的网络认证信息,用户名和密码之间用英文置号隔开。-P:添加一个基本的代理认证信息,用户名和密码之间用英文置号隔开。-X:指定使用的和端口号,例如:" 126.10.10.3:88"。-V:打印版本号并退出。-k:使用HTTP的KeepAlve特性。-d:不显示百分比。-S:不显示预估和警告信息。-g:输出结果信息到gnuplot格式的文件中。-e:输出结果信息到CSV格式的文件中。-r:中指定接收到错误信息时不退出程序。-h:显示用法信息,其实就是ab -help。
5.5.3、测试对比
1、直连Tomcat

2、Nginx反向代理Tomcat

3、Nginx反向代理Tomcat+keeplived

六、反向代理相关理论知识
6.1、反向代理核心流程
6.1.1、http请求报文组成

6.1.2、Upstream工作流程
1、流程
proxy_pass向上游服务器请求数据共有6个阶段
- 启动初始化流程
- 通过网络通信协议与远程服务提供方建立连接
- 向远程服务提供方发送通信请求以获取服务信息
- 解析HTTP头信息并提取关键参数如状态码、返回码等
- 解析JSON或XML格式的响应数据并提取所需字段
- 完成整个流程



2、指令含义
-
set_header:设置Header -
proxy_connect_timeout:连接超时后立即中断 -
proxy_send_timeout:规定请求发送间隔时间为60秒(非持续耗时)。若超出该时间则关闭连接。 -
proxy_read_timeout:规定时间内未收到响应则关闭连接并返回504错误码。 -
proxy_request_buffering:是否在发送请求前完全读取请求体到上游服务器。 -
proxy_buffering:是否缓存上游服务器的数据。 -
proxy_buffers 32 64K:使用32个大小为64K字节的内存缓冲块。 -
proxy_buffer_size:header缓冲区的大小。 -
proxy_max_temp_file_size 1024m:临时文件的最大大小由1024MB设置。 -
proxy_temp_file_write_size 8k:当启用代理服务器到临时文件响应缓冲时,限制一次写入数据大小,默认受proxy_buffer_size和proxy_buffers指令设置的两个缓冲区限制;而临时文件的最大容量则由proxy_max_temp_file_size指令设定。 -
proxy_temp_path /spool/nginx/proxy_temp 1 2:临时文件写入位置位于子目录结构/和/中。 -
proxy_busy_buffers_size 8k:用于客户端传输响应时的内存缓冲区大小设为8KB。
6.1.3、对客户端的限制
1、配置位置
- http
- server
- location
2、指令含义
client_body_buffer_size:定义客户端缓存空间大小client_header_buffer_size:指定客户端请求头缓存空间的大小client_max_body_size 1000M:默认设置为1M(64位平台为16K),当客户端请求体超出此设定时将触发HTTP 413(Request Entity Too Large)错误并返回给客户端;若将此参数设为0则可禁用对客户端请求正文大小的检查client_body_timeout:指定从客户端发起连接后等待发送完整request body的时间超时间隔;若在指定时间内未收到任何响应内容则Nginx将返回HTTP 408(Request Time Out)错误client_header_timeout:定义从客户端发起连接后等待完整发送一个request header的时间超时间隔;若在指定时间内未完成发送完整request header则Nginx将返回HTTP 408(Request Timed Out)错误client_body_temp_path path [level1[level2 [level3]]]:指定了客户端临时缓存body文件的位置路径及分层组织方式client_body_in_file_only on:标志设置为on表示将body数据完整写入磁盘文件并维持该文件不被删除(建议谨慎使用)client_body_in_single_buffer:启用策略以确保body数据在内存中使用连续单一缓冲区以提升二次开发环境下的读取性能client_body_buffer_size:默认值为32位平台8K(64位平台16K),当单个请求体数据量超过配置值时会将其拆分为多个临时文件进行处理client_header_buffer_size:指定了从客户端接收请求头信息的数据缓冲区容量;当单个字段或行无法全部加载至缓冲区内系统将自动切换至下一个缓冲区继续读取相关数据- large_client_header_buffers :系统预设初始状态下的大客户模式头缓冲区容量设置为8K
6.1.4、有用的Header设置
1、获取客户端IP
配置header
proxy_set_header X-Forwarded-For $remote_addr;
2、其他的一些默认有用的指令
- 主机名:
- 允许缓存控制:禁止缓存指令
- 缓存控制策略:禁止缓存指令
- 提供安全请求头信息:默认存在,并指示所使用的HTTP协议类型
- 浏览器信息:提供关于浏览器的相关信息
- 接受请求类型:指示系统能够接收的请求类型
- 接受压缩编码(gzip 和 deflate):
- 接受语言(中文(简体)及普通话(权重 0.9)):
6.2、Gzip压缩

6.2.1、相关的请求头信息
`content-encoding`:内容的压缩格式。
2. `transfer-encoding`:传输的格式。
- chunked:以一个一个单独的包发送(单独解),当包的长度为0字节则结束。
3. `content-length`:内容的长度,只读此长度的数据(和**transfer-encoding**对应)。
6.2.2、动态压缩(适合反向代理)
1、原理
gzip 采用 DEFLATE 压缩算法进行实时数据压缩。DEFLATE 压缩算法是一种无损失数据压缩技术,并整合了 LZ77 编码策略与霍夫曼编码原理以实现高效的数据存储与传输。
* LZ77 算法: LZ77 算法是一种基于滑动窗口的压缩算法,用于查找和利用数据中的重复模式。它通过在滑动窗口内搜索已经出现过的数据片段,并尝试用指向这些重复片段的指针来表示数据,从而实现数据的压缩。具体来说,如果当前的数据片段在窗口中已经出现过,就用指向窗口中对应位置的指针来替代当前数据片段,从而减小数据的大小。
* 哈夫曼编码: 哈夫曼编码是一种变长编码方式,它根据字符出现的频率来构建一棵前缀编码树,使得频率较高的字符用较短的编码表示,而频率较低的字符用较长的编码表示。在 DEFLATE 中,使用哈夫曼编码来对 LZ77 算法生成的指针和字面值进行编码,以进一步减小数据的大小。
在 gzip 压缩过程中 会实时生成哈夫曼树 以适应不同数据片段的频率分布 这种情况下可以通过分析具体数据特性来选择合适的编码策略 从而进一步提升压缩效果
在压缩过程中,原始数据往往会划分为若干个独立的数据块,在每个独立的数据块中都嵌入了一个经过压缩的数据流以及相应的哈夫曼编码表。这种划分方式的主要目的则是为了加速解压阶段对被压缩信息的快速定位与解码,并显著提升了整个解压流程的效率
2、命令
作用域http,server, location
-
gzip on:开关设置为启用状态,默认情况下关闭。 -
gzip buffers 32 4k|16 8k:缓冲区容量设定为32块×4KB或16块×8KB。 -
gzip_comp_level 1:压缩级别设为1至9级(级别越高压缩效果越佳)。 -
gzip_http_version 1.1:仅支持Gzip协议版本1.1及以上。 -
gzip_min_length 256:指定响应内容需至少256个字节才能被Gzip编码处理。 -
gzip_proxied:-
如果header头中包含**“Expires”**头信息,则启用压缩功能。
-
当Header字段包含Expire信息时
-
如果Header字段包含Cache-Control:no-cache信息,则启用压缩功能。
-
当Header字段包含Cache-Control:no-cache指令时
-
如果Header字段包含Cache-Control:no-store信息,则启用压缩功能。
-
当Header字段包含Cache-Control:no-store指令时
-
如果Header字段包含Authorization信息,则启用压缩功能。
-
当Header字段包含Authorization指令时
-
不论Header字段是否包含Last-Modified信息,则始终启用压缩功能。
-
假设在没有Last-Modified信息的情况下始终进行Gzip编码
-
如果Header字段不包含"ETag"头信息,则始终启用压缩功能。
-
假设在没有ETag标识的情况下始终进行Gzip编码
-
如果Header字段包含"Authorization"头信息,则始终启用压缩功能。
-
当Header字段中有Authorization指令时则进行Gzip编码
-
不论如何都对响应内容进行Gzip编码处理
-
gzip_types:哪些mime要型的文件进行压缩。- text/xml application/xml application/atom+ xml application/rss + xml application/xhtml+ xml image/svg+xml
- text/javascript application/javascript application/x-javascript
- text/x-json application/json application/x-web-app-manifest+json
- text/css text/plain text/x-component
- font/opentype applic ation/x-font-tf appic ation/vnd.ms-fontobject
- image/x-icon;
-
-
设置Vary头字段为on:新增一个Header字段以适配旧版本浏览器的Vary: Accept-Encoding字段。
- 禁用某些浏览器的Gzip压缩:(支持使用正则表达式进行配置)建议不要配置(因为会每次请求解析正则表达式)。
3、动态压缩缺点
开启动态的Gzip就无法使用
- CPU 资源消耗: 动态压缩操作确实会消耗 CPU 资源来执行编码与解码过程。
- 在面对大量数据或运行于低性能设备时,
压缩效果可能会影响到系统的负载水平,
从而降低整体性能表现。 - 压缩比不高: 尽管 Gzip 在大多数应用场景下能有效地实现数据压缩,
但对于特定类型的文件,
如已过二次压缩的数据或是具有较多噪声的数据,
其实际效果可能并不理想,
并且有时甚至会导致最终文件体积增大。 - 无法实时压缩: Gzip 是一种基于实时数据流的技术,
因此在对数据流进行编码与解码的过程中会产生延迟。
这种特性会影响在网络传输中
对于响应时间的要求。 - 不适用于所有数据类型: 尽管 Gzip 在大多数情况下能有效减少文件大小,
然而它并不适合作为通用的数据压缩工具。
例如,
已经被过一次或多次压缩的数据文件、加密存储的数据或是包含大量随机噪声的内容都无法很好地应用 Gzip 进行进一步优化。
6.2.2、静态压缩(适合资源服务器)
1、原理
采用 DEFLATE 压缩算法进行数据压缩,在静态压缩模式下,压缩器预设了与数据类型匹配的哈夫曼编码表而非实时生成的编码表。这些哈夫曼编码表是根据数据类型设计而成的,在实际压缩过程中无需实时生成编码表。
对于静态压缩场景中的信息处理而言,在预定义的数据特征基础上建立相应的哈夫曼编码表是必要的。
该单元主要依赖于预先生成的哈夫曼编码表来进行数据转换与存储。
解码模块能够继承编译程序所使用的代码映射关系。
2、命令
静态压缩默认关闭,需要自己开一下--with-http_gzip_static_module模块
cd nginx-1.21.6 #进目录
./configure --prefix=/usr/local/nginx/ --with-http_gzip_static_module
make
bash
gzip_static on I off I always:用于控制静态文件gzip压缩状态。on:是否开启或关闭该功能。off:关闭该功能。always:总是按照gzip压缩进行处理。(可能存在客户端无法解压的风险)。搭配ngx_http_gunzip_module使用。
3、ngx_http_gunzip_module 命令
gunzip on | off:开启gunzip bufters 32 4k|16 8k:缓存大小
