男女老少都爱看的nginx详解及常见实验详解

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

一、用户发起请求

当你在浏览器中输入一个网址（URL）并按下回车键时，浏览器会封装你的请求信息。这个请求信息包含了请求方法（如 GET、POST 等）、请求的目标 URL、可能的请求头（如 Accept 表示可接受的内容类型、User-Agent 标识浏览器类型等）以及请求体（如果有数据要提交，比如 POST 请求中提交表单数据）。

二、DNS 解析

浏览器首先需要确定要访问的服务器的 IP 地址。如果 URL 中是域名而不是 IP 地址，浏览器会向 DNS（Domain Name System）服务器发送查询请求。DNS 服务器根据域名查找对应的 IP 地址，并将结果返回给浏览器。

三、建立连接

TCP 三次握手
浏览器获得服务器 IP 地址后，与服务器建立 TCP 连接。首先，浏览器向服务器发送一个 SYN（Synchronize）包，表示请求建立连接。
服务器接收到 SYN 包后，回复一个 SYN/ACK（Synchronize Acknowledge）包，表示同意建立连接并确认收到了浏览器的请求。
浏览器收到 SYN/ACK 包后，再回复一个 ACK（Acknowledge）包，确认服务器的回复。至此，TCP 三次握手完成，连接建立成功。

四、发送请求

连接建立后，浏览器将请求信息通过已建立的 TCP 连接发送给服务器。请求信息以数据包的形式在网络中传输，经过多个网络设备（如路由器、交换机等）的转发，最终到达服务器。

五、服务器处理请求

服务器接收到请求后，根据请求的 URL 和请求方法，确定要调用的 Web 应用程序中的特定资源或处理逻辑。
Web 服务器软件（如 Apache、Nginx 等）将请求转发给相应的 Web 应用程序（如用 Java、Python、PHP 等语言开发的 Web 应用）。
Web 应用程序对请求进行处理，可能包括查询数据库、执行业务逻辑、生成动态内容等。

六、服务器返回响应

处理完成后，Web 应用程序将响应结果返回给 Web 服务器软件。
Web 服务器软件构建 HTTP 响应消息，包含响应状态码（如 200 OK 表示成功、404 Not Found 表示资源未找到等）、响应头（如 Content-Type 表示响应内容的类型、Content-Length 表示响应内容的长度等）和响应体（即请求的资源内容，如 HTML 页面、图片、JSON 数据等）。
服务器将响应消息通过 TCP 连接发送回浏览器。

七、浏览器处理响应

浏览器接收响应消息，并根据响应状态码判断请求是否成功。
如果响应状态码为 200 OK 等成功状态码，浏览器会解析响应头，确定响应内容的类型。
根据响应内容的类型，浏览器进行相应的处理。例如，如果是 HTML 页面，浏览器会解析 HTML 代码，构建页面结构，并下载页面中引用的 CSS、JavaScript、图片等资源。如果是 JSON 数据，浏览器可能会将其交给 JavaScript 代码进行进一步处理。

八、断开连接

TCP 四次挥手
当浏览器完成对响应内容的处理后，如果不需要继续与服务器保持连接，浏览器会向服务器发送一个 FIN（Finish）包，表示请求关闭连接。
服务器接收到 FIN 包后，回复一个 ACK 包，表示确认收到关闭请求。
服务器完成自己的任务后，也向浏览器发送一个 FIN 包，表示服务器也请求关闭连接。
浏览器收到服务器的 FIN 包后，回复一个 ACK 包，确认服务器的关闭请求。至此，TCP 四次挥手完成，连接关闭。

1.1 Web 服务介绍

通常由两种Web服务器，它们分别是Apache和Nginx：

1.1.1 Apache

Apache 是世界使用排名第一的 Web 服务器软件。下面是关于 Apache Web 服务的介绍：

一、历史与地位

Apache 诞生于 1995 年，由一群开发爱好者共同创建。它在 Web 服务器领域具有极其重要的地位，被广泛应用于互联网上的众多网站和企业内部网络。其开源的特性使得开发者可以免费使用、修改和分发，吸引了大量的开发者参与到其发展和改进中。

二、特点与优势

高度可靠：经过多年的发展和实践检验，Apache 具有出色的稳定性和可靠性，能够长时间不间断地运行，为用户提供稳定的 Web 服务。
强大的配置能力：提供了丰富的配置选项，可以根据不同的需求进行灵活的配置。你可以调整服务器的性能参数、设置虚拟主机、配置访问控制等。
支持多种平台：可以在多种操作系统上运行，包括 Windows、Linux、Unix 等，具有广泛的适用性。
安全性能高：提供了多种安全机制，如访问控制、用户认证、加密传输等，保障了网站的安全性。
丰富的模块支持：拥有大量的模块，可以根据需要进行扩展。例如，支持 PHP、Python、Perl 等脚本语言的模块，以及实现缓存、压缩、重定向等功能的模块。

三、工作原理

当客户端（如浏览器）向 Apache 服务器发送请求时，Apache 服务器首先会根据配置文件中的设置，确定请求的目标资源。如果是静态资源（如 HTML 文件、图片、CSS 文件等），Apache 会直接从文件系统中读取并返回给客户端。如果是动态资源（如 PHP 脚本、Python 脚本等），Apache 会将请求转发给相应的脚本解释器进行处理，然后将处理结果返回给客户端。

四、应用场景

企业网站：许多企业选择 Apache 作为其官方网站的 Web 服务器，以提供稳定、安全的服务。
开源项目：大量的开源项目使用 Apache 作为其 Web 服务平台，方便用户访问和使用。
电子商务网站：对于高流量的电子商务网站，Apache 的性能和可靠性能够满足其业务需求。
教育机构和政府部门：这些机构通常需要稳定、安全的 Web 服务，Apache 是一个不错的选择。

总之，Apache Web 服务以其可靠性、灵活性、安全性和广泛的适用性，成为了 Web 服务器领域的重要选择之一。

1.1.2 Nginx

Nginx 是一款高性能的 Web 服务器和反向代理服务器。下面是对 Nginx Web 服务器的详细介绍：

一、历史与发展

Nginx 由俄罗斯的程序员 Igor Sysoev 开发，于 2004 年首次公开发布。它以其高效的性能、低资源消耗和强大的功能迅速在全球范围内获得了广泛的应用。如今，Nginx 已经成为互联网上最流行的 Web 服务器之一。

二、特点与优势

高性能：Nginx 采用异步非阻塞的事件驱动模型，能够处理大量并发连接，具有极高的吞吐量和响应速度。在高并发场景下，Nginx 表现出卓越的性能，远远超过传统的 Web 服务器。
低资源消耗：相比其他 Web 服务器，Nginx 对系统资源的占用非常少。它可以在较低配置的服务器上运行，节省硬件成本。
反向代理和负载均衡：Nginx 可以作为反向代理服务器，将客户端的请求转发到后端的多个服务器上，实现负载均衡。这样可以提高系统的可用性和可靠性，同时也方便了服务器的扩展。
静态文件服务：对于静态文件（如图片、CSS、JavaScript 文件等），Nginx 能够高效地提供服务。它可以直接从磁盘读取文件并返回给客户端，无需经过复杂的应用程序处理。
热部署：Nginx 支持热部署，即可以在不中断服务的情况下更新配置文件或升级服务器。这对于需要保持高可用性的系统来说非常重要。
丰富的功能模块：Nginx 拥有众多的功能模块，可以根据不同的需求进行扩展。例如，支持 SSL/TLS 加密、HTTP/2 协议、gzip 压缩等。

三、工作原理

事件驱动模型：Nginx 采用异步非阻塞的事件驱动模型，当一个连接到达时，Nginx 不会为每个连接创建一个新的进程或线程，而是通过事件机制来处理连接。这种方式可以大大减少系统资源的消耗，提高服务器的并发处理能力。
反向代理：当 Nginx 作为反向代理服务器时，它接收客户端的请求，然后将请求转发到后端的服务器上。后端服务器处理请求并将结果返回给 Nginx，Nginx 再将结果返回给客户端。在这个过程中，Nginx 可以对请求进行负载均衡、缓存、过滤等操作。
负载均衡：Nginx 可以通过多种方式实现负载均衡，如轮询、加权轮询、IP 哈希等。负载均衡可以将请求均匀地分配到后端的多个服务器上，提高系统的可用性和性能。

四、应用场景

高并发网站：对于高并发的网站，如电商平台、社交媒体等，Nginx 可以提供高性能的 Web 服务和负载均衡，确保系统的稳定运行。
反向代理：作为反向代理服务器，Nginx 可以隐藏后端服务器的真实 IP 地址，提高系统的安全性。同时，它还可以对请求进行过滤和缓存，提高系统的性能。
静态文件服务：对于静态文件的服务，Nginx 可以高效地提供服务，减少对后端应用服务器的压力。
微服务架构：在微服务架构中，Nginx 可以作为 API 网关，对微服务进行路由、负载均衡、安全控制等操作。

总之，Nginx Web 服务器以其高性能、低资源消耗、强大的功能和广泛的应用场景，成为了现代互联网架构中不可或缺的一部分。

1.1.3 两者比较

比较项目	Apache	Nginx
开发语言	C	C
诞生时间	1995 年	2004 年
性能	处理高并发能力相对较弱，性能中等	高性能，采用异步非阻塞的事件驱动模型，能处理大量并发连接
资源消耗	相对较高	低资源消耗
稳定性	经过多年发展稳定性高	稳定性也非常高
配置难度	配置相对复杂	配置较为简洁
反向代理和负载均衡	支持，但功能相对 Nginx 稍弱	强大的反向代理和负载均衡功能
静态文件服务	能处理静态文件，但效率相对 Nginx 低	高效处理静态文件
热部署	支持热部署，但相对 Nginx 灵活性稍弱	支持热部署，操作方便
应用场景	适合企业网站、开源项目等	高并发网站、反向代理、静态文件服务、微服务架构等

1.2 互联网发展历程回顾

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日里巴巴集团于纽约证券交易所正式挂牌上市

二. 什么是Nginx

2.1 定义

Nginx 是一款高性能的开源 Web 服务器和反向代理服务器，同时也可作为邮件代理服务器和通用的 TCP/UDP 代理服务器。

它以其高效的事件驱动模型、低资源消耗和强大的功能而备受青睐。Nginx 能够处理大量并发连接，在高并发场景下表现出色，可快速响应客户端请求并将其转发到后端服务器进行处理。它支持负载均衡、缓存、SSL/TLS 加密、HTTP/2 协议等众多功能，广泛应用于互联网上的高流量网站、微服务架构、反向代理等场景，为用户提供稳定、高效、安全的网络服务。

2.2 Nginx的发展史

一、诞生背景

2002 年，一位名叫 Igor Sysoev 的俄罗斯工程师为了解决当时高并发 Web 服务的需求，开始着手开发 Nginx。当时的 Web 服务器市场主要由 Apache 等占据，但在处理高并发请求方面存在一些性能瓶颈。

二、早期发展（2004 - 2007）

2004 年，Nginx 首次公开发布。它以其高效的性能和低资源消耗迅速引起了开发者的关注。其独特的事件驱动模型和异步非阻塞的设计使其能够在处理大量并发连接时表现出色。
在这一时期，Nginx 主要被一些技术爱好者和小型项目所采用。随着其稳定性和功能的不断提升，逐渐在一些中型网站中得到应用。

三、快速成长（2008 - 2012）

2008 年，Nginx 开始获得更多的认可和广泛的应用。许多大型网站开始尝试使用 Nginx 来处理高并发的流量。其反向代理和负载均衡功能成为吸引企业用户的重要特性。
2009 年，Nginx 0.8 版本发布，标志着其功能更加成熟稳定。这一版本增加了对更多操作系统的支持，并改进了性能和稳定性。
2011 年，Nginx 1.0 正式版发布，这是一个重要的里程碑。它具备了完整的功能集，包括强大的反向代理、负载均衡、缓存、SSL 加密等功能，被越来越多的企业和组织采用。

四、广泛应用（2013 - 2018）

随着云计算和微服务架构的兴起，Nginx 在这些领域中发挥了重要作用。作为 API 网关和反向代理服务器，它能够帮助企业构建高可用、可扩展的分布式系统。
2016 年，Nginx Plus 发布，这是 Nginx 的商业版，提供了更多的高级功能和技术支持。它被广泛应用于企业级环境中，满足对性能和可靠性要求更高的场景。
在这一时期，Nginx 的社区不断壮大，有大量的开发者为其贡献代码和插件，进一步丰富了其功能和应用场景。

五、持续创新（2019 - 至今）

Nginx 继续在性能优化、功能扩展和安全性方面进行创新。例如，支持 HTTP/2 和 QUIC 协议，提高了网络传输效率；加强了安全防护功能，抵御各种网络攻击。
随着容器化和 Kubernetes 的普及，Nginx 在容器编排和云原生应用中扮演着重要角色。它可以与 Kubernetes 集成，实现自动扩缩容、流量管理等功能。
Nginx 不断适应新的技术趋势和用户需求，为全球的网站和应用提供高效、可靠的网络服务。

2.3 Nginx 的负载均衡算法

一、轮询（round-robin）

默认的负载均衡算法。Nginx 将请求依次分配到各个后端服务器，每个服务器被选中的机会相等。例如，有三个后端服务器 A、B、C，第一个请求分配给 A，第二个请求分配给 B，第三个请求分配给 C，第四个请求又分配给 A，如此循环。

优点：实现简单，能平均分配请求到各个服务器。
缺点：不考虑服务器的实际负载情况，可能导致某些负载较高的服务器性能下降。

二、加权轮询（weighted round-robin）

在轮询的基础上，为每个后端服务器设置一个权重值。权重值越高，被分配到的请求就越多。例如，服务器 A 的权重为 3，服务器 B 的权重为 2，服务器 C 的权重为 1，那么在一段时间内，分配给 A 的请求数大约是 B 的 1.5 倍，是 C 的 3 倍。

优点：可以根据服务器的性能差异分配不同数量的请求。
缺点：同样不考虑服务器的实时负载情况。

三、IP 哈希（ip_hash）

根据客户端的 IP 地址计算哈希值，然后将请求分配到特定的后端服务器。同一个 IP 地址的请求总是被分配到同一台服务器。

优点：可以保证来自同一客户端的请求始终被分配到同一台服务器，有利于实现会话保持。
缺点：当后端服务器数量发生变化时，可能会导致部分客户端的请求分配到新的服务器，从而影响会话的连续性。

四、最少连接（least_conn）

将请求分配到连接数最少的后端服务器。Nginx 会实时监测每个后端服务器的连接数，新的请求总是被分配到连接数最少的服务器上。

优点：能够根据服务器的实际负载情况分配请求，使负载更加均衡。
缺点：算法相对复杂，需要实时监测连接数，可能会带来一定的性能开销。

五、一致性哈希（consistent_hash）

通过一致性哈希算法将请求分配到后端服务器。一致性哈希可以在服务器数量发生变化时，尽量减少对已有的请求分配的影响。

优点：在服务器数量变化时，对现有请求的影响较小。
缺点：实现相对复杂，可能会带来一定的性能开销。

2.4Nginx 负载均衡算法的实现原理

一、轮询（round-robin）

实现原理：
Nginx 维护一个后端服务器列表，按照顺序依次将请求分配给列表中的每一台服务器。当一个请求到来时，Nginx 从列表的头部开始选择一台服务器处理请求，处理完一个请求后，将选择的指针移动到下一台服务器，如此循环。

例如，有服务器 A、B、C，第一个请求分配给 A，第二个请求分配给 B，第三个请求分配给 C，第四个请求又回到 A，依此类推。

二、加权轮询（weighted round-robin）

实现原理：
在轮询算法的基础上，为每台后端服务器分配一个权重值。Nginx 首先计算所有服务器权重值的总和。当有请求到来时，Nginx 从 0 开始依次累加每台服务器的权重值，直到找到第一个累加值大于等于当前请求序号的服务器。这个请求就分配给这台服务器。

例如，服务器 A 的权重为 3，服务器 B 的权重为 2，服务器 C 的权重为 1。总权重为 6。第一个请求分配给 A（因为 0<3），第二个请求也分配给 A（因为 3<6），第三个请求分配给 B（因为 3+2>5），第四个请求分配给 A（因为 5<6），第五个请求分配给 B（因为 3+2+2>7），第六个请求分配给 C（因为 3+2+2+1>8），然后循环。

三、IP 哈希（ip_hash）

实现原理：
根据客户端的 IP 地址计算哈希值，然后对后端服务器的数量取模，得到的结果决定将请求分配到哪台服务器。这样，同一个 IP 地址的客户端请求总是会被分配到同一台服务器。

例如，有三台服务器 A、B、C，客户端 IP 地址经过哈希计算后得到的值为 12345，对 3 取模后结果为 0，那么这个请求就分配给服务器 A。如果另一个客户端 IP 地址哈希后取模结果为 1，请求就分配给服务器 B。

四、最少连接（least_conn）

实现原理：
Nginx 实时监测每台后端服务器的当前连接数。当有新的请求到来时，选择连接数最少的那台服务器处理请求。

例如，服务器 A 当前连接数为 10，服务器 B 为 8，服务器 C 为 12。新的请求会被分配给服务器 B，因为它的连接数最少。

五、一致性哈希（consistent_hash）

实现原理：
将请求的某个特征值（如用户 ID、请求 URL 等）进行哈希运算，得到一个哈希值。然后将这个哈希值映射到一个虚拟的哈希环上。后端服务器也通过相同的哈希算法映射到这个哈希环上。从请求的哈希值在哈希环上的位置开始，顺时针查找，找到的第一个服务器就是处理该请求的服务器。

这样，当后端服务器数量发生变化时，只有部分请求会受到影响，而不是所有请求都需要重新分配到不同的服务器，从而减少了因服务器变动带来的缓存失效等问题。

2.5 Nginx 与其他负载均衡软件相比的优缺点

与 LVS 对比：
- 优点：
  - 工作在网络 7 层：Nginx 可以针对 http 应用做更多分流策略，如基于域名、目录结构等，而 LVS 工作在网络 4 层，在这方面灵活性欠佳。Nginx 的正则规则比 LVS 更强大灵活，适用场合更多。
  - 对网络依赖小：理论上能 ping 通就能进行负载功能，且 Nginx 安装配置简单，测试方便，还能打印错误日志，而 LVS 对网络依赖较大，安装配置和测试相对复杂，出问题时排查难度也较高。
  - 能承担高负载压力且稳定：Nginx 可应对较高负载，是为解决 c10k 问题而诞生，在硬件条件允许的情况下，一般能支撑几万次的并发量；LVS 抗负载能力也强，但配置性较低，可配置的东西少。
  - 可作为 Web 服务器即 Cache 功能：Nginx 可作为静态网页和图片服务器，LVS 则无此功能。
- 缺点：
  - 性能和效率略低：LVS 工作在网络 4 层，抗负载能力强，性能高，能达到 F5 的 60%，对内存和 CPU 资源消耗比较低，且没有流量产生，而 Nginx 在处理大量请求时性能和效率相对 LVS 稍逊一筹。
  - 应用范围相对较窄：LVS 可以对几乎所有应用做负载均衡，包括 http、数据库、在线聊天室等，而 Nginx 仅能支持 http、https 和 Email 协议，适用范围较小。
  - 不支持某些功能：Nginx 不支持正则处理，不能做动静分离；对后端服务器的健康检查，只支持通过端口来检测，不支持通过 url 来检测。而 LVS 在这些方面相对更具优势。

与 HAProxy 对比：
- 优点：
  - 配置简单：Nginx 的安装和配置相对 HAProxy 更简单易懂，测试也较方便，易于管理和维护。
  - 支持的协议相对较多：Nginx 支持 http、https 和 Email 协议，HAProxy 主要支持 TCP（四层）和 HTTP（七层）协议。
  - 可作为 Web 服务器和 Cache：Nginx 不仅能做负载均衡，还可作为功能强大的 Web 应用服务器以及 Cache，HAProxy 则不能做 Web 服务器，即不支持 HTTP cache 功能。
  - 社区活跃：Nginx 社区非常活跃，第三方模块众多，相关资料丰富，遇到问题时更容易找到解决方案。
- 缺点：
  - 负载均衡速度和并发处理能力稍逊：在单纯的负载均衡效率和并发处理上，HAProxy 比 Nginx 更出色，尤其是在处理大量并发请求时表现更优。
  - 功能相对较少：HAProxy 支持更多的负载均衡策略，如动态加权轮循、加权源地址哈希、加权 URL 哈希和加权参数哈希等，并且能够补充 Nginx 的一些缺点，比如支持 Session 的保持、Cookie 的引导以及通过获取指定的 url 来检测后端服务器的状态等，而 Nginx 在这些功能上相对较弱。

三.什么是正向代理

3.1. 定义与概念

正向代理位于客户端和目标服务器之间。当客户端向目标服务器发送请求时，请求首先被发送到正向代理服务器。代理服务器再代表客户端向目标服务器发起请求，并将目标服务器的响应返回给客户端。

比如：

假设你在一个学校里，学校的网络管理比较严格，不允许学生直接访问一些娱乐网站。但是你特别想访问某个特定的国外音乐网站来听音乐。

这时候，你可以使用一个位于校外的代理服务器。你在自己的电脑上进行设置，让所有的网络请求先经过这个校外的代理服务器。

当你想要访问那个国外音乐网站时，你的请求会先发送到这个代理服务器。代理服务器接收到你的请求后，就像它自己是一个普通的客户端一样，去访问那个音乐网站。音乐网站并不知道这个请求实际上是来自于你，它只看到代理服务器的 IP 地址。代理服务器获取到音乐网站的响应后，再把这个响应转发给你。

在这个例子中，这个校外的代理服务器就是正向代理。它帮助你突破了学校网络的限制，实现了你访问特定网站的目的，同时也保护了你的隐私，因为音乐网站只知道代理服务器的 IP，而不知道你的真实 IP 地址。

3.2 工作原理

客户端配置：客户端需要配置代理服务器的地址和端口，以便将请求发送到代理服务器。例如，在浏览器的网络设置中，可以指定代理服务器的 IP 地址和端口号。
请求转发：当客户端发起请求时，请求被发送到正向代理服务器。代理服务器根据请求的目标地址，向目标服务器发起请求。在这个过程中，目标服务器只看到代理服务器的 IP 地址，而不知道真正的客户端地址。
响应返回：目标服务器将响应返回给代理服务器，代理服务器再将响应转发给客户端。

3.3 主要用途

访问限制突破：当客户端无法直接访问某些目标服务器时，例如由于网络限制、防火墙阻挡等原因，可以通过正向代理服务器来访问。代理服务器可能位于可以访问目标服务器的网络中，从而帮助客户端突破访问限制。
隐私保护：客户端的真实 IP 地址不会直接暴露给目标服务器，而是由代理服务器的 IP 地址代替。这样可以在一定程度上保护客户端的隐私。
缓存加速：代理服务器可以缓存目标服务器的响应内容。当客户端再次请求相同的资源时，代理服务器可以直接返回缓存的内容，而无需再次向目标服务器发起请求，从而提高访问速度。

四.什么是反向代理

4.1 定义与概念

反向代理是一种服务器代理技术，主要作用是代表后端的服务器接收来自客户端的请求，并将请求转发给合适的后端服务器进行处理，然后将后端服务器的响应返回给客户端。

比如：

假设你是一个网购爱好者，经常在一家大型电商平台购物。

这家电商平台在幕后可能有很多台服务器来处理各种业务，比如有专门处理用户登录的服务器、处理商品搜索的服务器、处理订单的服务器等等。但是作为用户的你并不知道这些具体的服务器在哪里，也不知道有多少台。

当你在浏览器中输入电商平台的网址并访问时，你的请求实际上是先发送到了一个反向代理服务器。这个反向代理服务器就像是一个 “前台经理”，它根据你的请求内容（比如你是在进行商品搜索还是在提交订单），将请求转发到相应的后端服务器上。

如果此时有很多用户同时在进行商品搜索，反向代理服务器可能会将这些请求均衡地分配到多台专门处理商品搜索的服务器上，以确保系统的快速响应和稳定运行。同时，反向代理服务器还可以对用户的请求进行一些安全检查和过滤，防止恶意攻击。

对于你来说，你只需要与这个电商平台的网址进行交互，而不需要关心具体是哪台服务器在为你服务。这个反向代理服务器就为你提供了一个统一的入口，同时也实现了负载均衡和安全防护等功能。

4.2 工作原理

客户端请求：客户端向反向代理服务器发送请求，就像请求直接发送到目标服务器一样。客户端通常不知道它正在与反向代理服务器通信，而认为是在与目标服务器直接交互。
代理服务器处理：反向代理服务器接收到客户端的请求后，根据请求的内容（如 URL、请求头信息等）和预先配置的规则，决定将请求转发给哪个后端服务器。例如，可以根据请求的域名将不同的请求转发到不同的后端服务器集群。
后端服务器响应：后端服务器处理请求并将响应返回给反向代理服务器。
响应返回客户端：反向代理服务器将后端服务器的响应返回给客户端。

4.3 主要用途

负载均衡：通过将请求分发到多个后端服务器，可以平衡服务器的负载，提高系统的整体性能和可靠性。反向代理服务器可以根据不同的负载均衡算法（如轮询、加权轮询、最少连接等）来分配请求。
安全防护：反向代理服务器可以作为一道屏障，隐藏后端服务器的真实 IP 地址和架构，减少直接针对后端服务器的攻击。它还可以进行一些安全检查和过滤，如过滤恶意请求、防止 SQL 注入等。
缓存加速：反向代理服务器可以缓存经常访问的内容，当客户端再次请求相同的内容时，可以直接从缓存中返回响应，而无需再次向后端服务器请求，从而提高响应速度，减轻后端服务器的负载。
统一入口：为客户端提供一个统一的入口点，无论后端有多少个服务器或服务，客户端只需要与反向代理服务器交互。这样可以简化客户端的配置和管理。

五. 正向代理与反向代理的区别

比较项目	正向代理	反向代理
位置	位于客户端一侧	位于服务器一侧
代表对象	代表客户端	代表后端服务器
目的	帮助客户端突破访问限制、保护隐私或加速访问	负载均衡、提高服务器安全性和可扩展性、提供统一入口
客户端知晓度	客户端明确知道自己在使用代理，并需进行配置	客户端通常不知道与反向代理通信，认为在与目标服务器直接交互
对服务器隐藏性	隐藏客户端信息	隐藏后端服务器信息
负载均衡能力	一般不具备负载均衡功能	主要用于负载均衡

六. 常见实验详解

`6.1 Nginx`的源码编译

6.1.1实验环境

1.红帽九主机一台

2.172.25.254.100/24

6.1.2实验步骤

1.下载官网

https://nginx.org/https://nginx.org/

2.解压进入解压目录

3.添加选项

查看：

添加的：

4.检查是否支持添加的选项

再次检查：

上面写错了，是search，就这样操作一直检查直到没有依赖性报错，如果有按上面的方法继续安装需要的依赖包（都是-devel）。

5.完全通过后，会生成`Makefile`文件

6.关闭debug功能

7.把`nginx`软件的命令执行路径添加到环境变量中

8.启动`nginx`并查看

启动ngin：

`6.2 Nginx`的平滑升级及版本回滚

6.2.1实验环境

相同。

6.2.2实验步骤

平滑升级：

1.官网下载1.26版本

2.添加模块，解压

3.检测

4.直接make

5.备份

6.生成新的进程

7.回收主进程的worker进程

8.验证

回滚：

1.唤醒老的进程

2.回收新的进程

3.测试

4.还原，杀死新的进程

`6.3nginx`命令参数

6.3.1实验环境

相同。

6.3.2实验步骤

-V：显示版本和编译参数
-v：显示版本

-s  reload 重新开启一个worker进程，并回收原来的

`6.4nginx`启动文件编写

6.4.1实验环境

相同。

6.4.2实验步骤

1.编写启动文件

2.重启

`6.5 root` 与 alias

6.5.1实验环境

相同。

6.5.2实验步骤

1.主配置文件添加子配置文件目录

2.创建子配置文件

检查语法，访问：

3.测试`root` 与 alias（别名）

`6.6location`用法

6.6.1实验环境

相同。

6.6.2实验步骤

1.编写子配置文件

2.测试

3.同样操作

等号：

以 t 开头：

以html为结尾：

不区分大小写：加*

以多个结尾：

`6.7 nginx`的用户认证

6.7.1 实验环境

相同。

6.7.2实验步骤

1.创建认证文件

如果要创建第二个要将c去掉：

2.使用认证文件

6.8. 自定义错误页面

6.8.1 实验环境

相同。

6.8.2 实验步骤

当我们访问的页面不存在的时候就去找我们定义的错误页面

6.9 自定义日志

6.9.1 实验环境

相同。

6.9.2 实验步骤

1.修改子配置文件

2.测试

`6.10 nginx`文件检测

6.10.1实验环境

相同。

6.10.2实验步骤

1.修改子配置文件

2.测试

如果前面检测的文件不存在就去访问我们定义的defaults.html文件

`6.11 nginx`长链接控制

6.11.1实验环境

相同。

6.11.2实验步骤

1.编写主配置文件

keepalive_timeout  65; #保持连接的时间，超时断开连接
keepalive_requests 2; #请求两次断开连接

2.测试

[root@nginx ~]# telnet www.haha.com 80
Trying 172.25.254.100...
Connected to www.haha.com.
Escape character is '^]'.
GET / HTTP/1.1
HOST: www.haha.com

HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Fri, 16 Aug 2024 15:50:18 GMT
Content-Type: text/html
Content-Length: 13
Last-Modified: Fri, 16 Aug 2024 15:40:17 GMT
Connection: keep-alive
ETag: "66bf72e1-d"
Accept-Ranges: bytes

www.haha.com

GET / HTTP/1.1             #第二次请求直接断开
HOST: www.haha.com

HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Fri, 16 Aug 2024 15:50:37 GMT
Content-Type: text/html
Content-Length: 13
Last-Modified: Fri, 16 Aug 2024 15:40:17 GMT
Connection: close
ETag: "66bf72e1-d"
Accept-Ranges: bytes

www.haha.com
Connection closed by foreign host.
[root@nginx ~]#

`6.12 nginx`下载服务器

6.12.1实验环境

相同。

6.12.2实验步骤

1.创建下载目录

2.编写子配置文件

autoindex on | off; #自动文件索引功能，默为off
autoindex_exact_size on | off; #计算文件确切大小（单位bytes），off 显示大概大小（单位K、
M)，默认on
autoindex_localtime on | off ; #显示本机时间而非GMT(格林威治)时间，默认off
autoindex_format html | xml | json | jsonp; #显示索引的页面文件风格，默认html
limit_rate rate; #限制响应客户端传输速率(除GET和HEAD以外的所有方法)，单位
B/s,bytes/second， #默认值0,表示无限制,此指令由
ngx_http_core_module提供
set $limit_rate 4k; #也可以通变量限速,单位B/s,同时设置,此项优级高.

3.测试

点击文件后就开始下载了

测试限速：

`6.13 nginx`的压缩功能

6.13.1实验环境

相同。

6.13.2实验步骤

1.主配置文件开启`gzip`压缩，默认是关闭

2.添加参数

#启用或禁用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;

3.测试

创建一个大于1k和小于1k的文件

6.14 内置变量

6.14.1实验环境

相同。

6.14.2实验步骤

1.添加一个模块，和前面1.26平滑升级一样

这个模块是自己传到虚拟机的，网上可以找到，wget下载下来即可

make && make install

2.写子配置文件

[root@nginx ~]# curl -b "key1=lee,key2=lee1" -u lee:lee var.timinglee.org/var?name=lee&&id=6666
172.25.254.100
name=lee
?
/data/web/html
/var
var.timinglee.org
36818
lee
GET
/data/web/html/var
/var?name=lee
http
HTTP/1.1
172.25.254.100
var.timinglee.org
80
curl/7.76.1
key1=lee,key2=lee1
lee1

6.15 全站加密

6.15.1实验环境

相同。

6.15.2实验步骤

1.创建证书

2.编写子配置文件

3.浏览器访问测试

当访问路径不存在时，重定向到主页面：

`6.16 nginx`的反向代理及动静分离

6.16.1实验环境

相同。

6.16.2实验步骤

1.实现反向代理

web1和web2主机下载httpd，配置apache服务，和前面的实验相同，在默认页面路径写页面。可以参考我下面的文章连接，里面有详细步骤：

http://t.csdnimg.cn/RrEHehttp://t.csdnimg.cn/RrEHe

2.测试反向代理

3.实现动静分离

web2主机端口改为8080：

web1安装php（动态页面）

nginx主机写子配置文件

4.测试动静分离

本地主机添加本地域名解析，目录为：
C:\Windows\System32\drivers\etc\hosts

注意：记得保存

`6.17 nginx`的反向代理的负载均衡

6.17.1实验环境

相同。

6.17.2实验步骤

1.编写子配置文件

2.测试

3.后续操作一样

添加hash算法，同一个IP访问同一个地址

hash $request_uri consistent：这个算法同一个uri的访问同一个地址

hash $cookie_lee：这个算法对lee的值进行哈希

`6.18 PHP`源码安装

6.18.1实验环境

相同。

6.18.2实验步骤

1.源码安装

官网下载php，解压，编译，make && make install；与nginx源码安装相同

编译，有依赖包就下载依赖包，与之前源码安装Nginx一样

2.`php`相关配置优化6.19

[root@nginx ~]# cd /usr/local/php/etc
[root@nginx etc]# cp php-fpm.conf.default php-fpm.conf
[root@nginx etc]# vim php-fpm.conf

pid = run/php-fpm.pid #去掉这行注释

[root@nginx etc]# cd php-fpm.d/
[root@nginx php-fpm.d]# cp www.conf.default www.conf

#生成主配置文件
[root@nginx php-fpm.d]# cd /root/php-8.3.9/
[root@nginx php-8.3.9]# cp php.ini-production /usr/local/php/etc/php.ini
[root@nginx ~]# vim /usr/local/php/etc/php.ini

[Date]
; Defines the default timezone used by the date functions
; https://php.net/date.timezone
date.timezone = Asia/Shanghai #修改时区

#生成启动文件
[root@nginx ~]# cd /root/php-8.3.9/
[root@nginx php-8.3.9]# cp sapi/fpm/php-fpm.service /lib/systemd/system/
[root@nginx php-8.3.9]# vim /lib/systemd/system/php-fpm.service 

# Mounts the /usr, /boot, and /etc directories read-only for processes invoked by
this unit.
#ProtectSystem=full #注释该内容

[root@Nginx php-8.3.9]# systemctl start php-fpm.service
[root@nginx php-8.3.9]# netstat -lnupt | grep php
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      153071/php-fpm: mas

`6.19 php`的动态扩展模块

6.19.1实验环境

相同。

6.19.2实验步骤

1.安装memcache模块

[root@nginx ~]# tar zxf memcache-8.2.tgz
[root@nginx ~]# cd memcache-8.2/
[root@nginx memcache-8.2]# yum install autoconf
[root@nginx memcache-8.2]# phpize
[root@nginx memcache-8.2]# ./configure && make && make install
Installing shared extensions:     /usr/local/php/lib/php/extensions/no-debug-nonzts-20230831/
[root@nginx memcache-8.2]# ls /usr/local/php/lib/php/extensions/no-debug-non-zts20230831/ memcache.so
opcache.so

2.复制测试文件到nginx发布目录中

[root@nginx ~]# cd memcache-8.2/
[root@nginx memcache-8.2]# ls
autom4te.cache config.log     configure.ac example.php Makefile.fragments 
README
build           config.m4     config.w32   include     Makefile.objects runtests.php
config9.m4
    config.nice   CREDITS       libtool     memcache.la         src
config.h       config.status docker       LICENSE     memcache.php       
tests
config.h.in     configure     Dockerfile   Makefile     modules
[root@nginx memcache-8.2]# cp example.php memcache.php /data/php/
[root@nginx ~]# vim /data/php/memcache.php
define('ADMIN_USERNAME','admin');   // Admin Username
define('ADMIN_PASSWORD','lee');   // Admin Password
define('DATE_FORMAT','Y/m/d H:i:s');
define('GRAPH_SIZE',200);
define('MAX_ITEM_DUMP',50);
$MEMCACHE_SERVERS[] = 'localhost:11211'; // add more as an array
#$MEMCACHE_SERVERS[] = 'mymemcache-server2:11211'; // add more as an array

3.配置php加载memcache模块

[root@nginx ~]# vim /usr/local/php/etc/php.ini
;extension=zip
extension=memcache
;zend_extension=opcache
[root@nginx ~]# systemctl reload php-fpm
[root@nginx no-debug-non-zts-20230831]# php -m | grep mem
memcache

4.部署memcached

[root@nginx ~]# yum install memcached -y
[root@nginx ~]# systemctl enable --now memcached.service
[root@nginx ~]# netstat -antlupe | grep memcache
tcp       0     0 127.0.0.1:11211         0.0.0.0:*               LISTEN     
976       1037243   186762/memcached
[root@nginx ~]# cat /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1,::1"

5.测试：

访问 http://php.haha.com/example.php 不断刷新

访问 http://php.haha.com/memcache.php 查看命中效果

性能对比：

没有memcache介入时，500个访问丢失了41个

有memcache介入时，500个访问丢失了0个

七.总结

以下是对Nginx的总结：

一、Nginx 的强大性能

高并发处理：Nginx 能够轻松应对大量并发连接，其异步非阻塞的事件驱动模型可高效利用系统资源，确保快速响应客户端请求。
低内存占用：与传统 Web 服务器相比，Nginx 在处理相同数量请求时消耗更少内存，特别适合资源有限的环境。
快速响应时间：优化的算法和高效的网络 I/O 处理，使得 Nginx 能够在极短时间内响应，极大提升用户体验。

二、丰富的功能特性

反向代理：可将客户端请求转发至后端多个服务器，实现负载均衡和高可用性，同时隐藏后端服务器真实 IP，增强安全性。
静态文件服务：高效处理静态文件，如图片、CSS、JavaScript 等，直接返回给客户端，减轻后端服务器负担。
缓存功能：支持动态和静态内容缓存，提高响应速度，减少服务器负载和网络带宽使用。
负载均衡：多种算法（轮询、加权轮询、IP 哈希等）可将请求分发到多个后端服务器，确保系统可靠性和可扩展性。
安全防护：可作为防火墙过滤恶意攻击，还支持 SSL/TLS 加密，保障数据传输安全。

三、灵活的配置选项

简洁的配置文件：Nginx 的配置文件语法简单易懂，方便用户根据自身需求进行灵活配置，实现各种复杂功能。
模块扩展：丰富的第三方模块可供选择，进一步扩展 Nginx 的功能，满足不同场景的需求。

总之，Nginx 以其卓越的性能、强大的功能和灵活的配置，成为众多网站和应用的首选服务器。无论是高并发场景、负载均衡需求还是安全防护要求，Nginx 都能提供可靠的解决方案。

qiao不出代码来

关注

16
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
男女老少都爱看的nginx详解及常见实验详解

正常情况下的单次web服务访问流程：一、用户发起请求当你在浏览器中输入一个网址（URL）并按下回车键时，浏览器会封装你的请求信息。这个请求信息包含了请求方法（如 GET、POST 等）、请求的目标 URL、可能的请求头（如 Accept 表示可接受的内容类型、User-Agent 标识浏览器类型等）以及请求体（如果有数据要提交，比如 POST 请求中提交表单数据）。二、DNS 解析浏览器首先需要确定要访问的服务器的 IP 地址。
复制链接

扫一扫