主要内容:
Nginx调度器(7层代理服务器Http、Nginx,4层代理服务器SSH)、配置upstream服务器集群池属性,HTTP错误代码,Nginx优化(自定义404错误代码、状态页面显示、ab压力测试、客户端开启缓存、414错误长地址码代理)
提前准备需要的环境:
① 创建虚拟机,最小化方式安装,按要求配置IP且同网段之间互通,配置YUM,修改主机名
proxy 192.168.2.5(vmnet2) 192.168.4.5(vmnet4) //必须
web1 192.168.2.100(vmnet2) //必须
web2 192.168.2.200(vmnet2) //必须
client 192.168.4.10(vmnet4) //可选,主要作为测试
② 由于最小化安装缺少许多工具包(web1和web2主机都需要)
bash
[root@web1 ~]# yum -y install vim net-tools bash-completion psmisc httpd
[root@web2 ~]# yum -y install vim net-tools bash-completion psmisc httpd
③ 建议关闭防火墙(# systemctl stop firewalld)
④ proxy环境准备(还原Nginx)
bash
[root@proxy ~]# cd ~/lnmp_soft/nginx-1.17.6/
[root@proxy nginx-1.17.6]# killall nginx
[root@proxy nginx-1.17.6]# rm -rf /usr/local/nginx/
[root@proxy nginx-1.17.6]# make install
[root@proxy nginx-1.17.6]# cd /usr/local/nginx/
[root@proxy nginx]# ls
conf html logs sbin
⑤ web1环境准备(使用httpd)
bash
[root@web1 ~]# echo "I am web1" > /var/www/html/index.html
[root@web1 ~]# systemctl restart httpd
[root@web1 ~]# netstat -nuptl | grep :80
tcp6 0 0 :::80 :::* LISTEN 1499/httpd
⑥ web2环境准备(使用httpd)
bash
[root@web2 ~]# echo "I am web2" > /var/www/html/index.html
[root@web2 ~]# systemctl restart httpd
[root@web2 ~]# netstat -nuptl | grep :80
tcp6 0 0 :::80 :::* LISTEN 1497/httpd
⑦ 使用proxy客户机curl测试访问:
bash
[root@proxy ~]# curl 192.168.2.100
I am web1
[root@proxy ~]# curl 192.168.2.200
I am web2
一、HTTP代理和调度
HTTP代理是一种中间服务器,它充当客户端和服务器之间的中介。客户端首先将请求发送到代理服务器,然后代理服务器再将请求转发到目标服务器。目标服务器的响应也会先经过代理服务器,然后再返回给客户端。通常情况下,代理又分为正向代理和反向代理。
1、正反向代理(Proxy)
正向代理(Forward Proxy)
正向代理通常用于客户端,帮助客户端访问互联网上的资源。它可以隐藏客户端的真实IP地址,提供访问控制、内容过滤、缓存加速等功能。例如,企业网络中的代理服务器可以限制员工访问某些网站,或者加速访问常用资源。
反向代理(Reverse Proxy)
反向代理通常用于服务器端,帮助服务器处理客户端请求。它可以隐藏服务器的真实IP地址,提供负载均衡、安全防护、缓存加速等功能。例如,大型网站通常使用反向代理服务器来分发请求到多个后端服务器,提高系统的可用性和性能。
反向代理服务器架设在服务器端,通过缓冲经常被请求的页面来缓解服务器的工作量,将客户机请求转发给内部网络上的目标服务器;并将从服务器上得到的结果返回给Internet上请求连接的客户端,此时代理服务器与目标主机一起对外表现为一个服务器;目前web网站使用反向代理,除了可以防止外网对内网服务器的恶性攻击、缓存以减少服务器的压力和访问安全控制之外,还可以进行负载均衡,将用户请求分配给多个服务器。
Nginx反向代理语法格式:
在http{}内加upstream{},location{}内添加proxy_pass
2、HTTP调度算法(Scheduling)
HTTP调度通常指的是在多个HTTP服务器之间分配和调度请求的过程。这种调度可以基于多种策略,例如负载均衡、故障转移、会话保持等。HTTP调度的主要目的是提高系统的可用性、性能和可靠性。
负载均衡
HTTP调度中最常见的一种形式。它通过将客户端的请求分发到多个服务器上,以确保每个服务器的负载相对均衡,从而提高整体系统的处理能力和响应速度。常见的负载均衡算法包括轮询(Round Robin)、最少连接(Least Connections)、IP哈希(IP Hash)等。
故障转移
指在某个服务器发生故障时,自动将请求转移到其他正常工作的服务器上,以确保服务的连续性。这通常通过健康检查和故障检测机制来实现。
会话保持(Session Persistence)
指确保同一个客户端的请求始终被分发到同一个服务器上,以保持会话状态的一致性。这在需要会话状态的应用中尤为重要,例如在线购物车、登录状态等。
3、服务器组主机状态类型
在服务器组(如Nginx、HAProxy等负载均衡器)中,主机状态类型如 down、max_fails 和 fail_timeout 是用于管理和监控后端服务器状态的重要参数。这些参数帮助负载均衡器决定如何处理对特定服务器的请求,以及在服务器出现故障时如何进行故障转移。
① down:
down 状态表示该服务器当前被标记为不可用。负载均衡器不会将任何请求分发到处于
down
状态的服务器。这通常用于维护或临时禁用某个服务器时。示例(Nginx):
server 192.168.1.1:80 down;
② max_fails:
max_fails 参数定义了在某个时间段内,负载均衡器允许对某个服务器请求失败的次数。当达到这个次数时,负载均衡器会认为该服务器不可用,并在
fail_timeout
时间段内不再向其分发请求。示例(Nginx):
server 192.168.1.2:80 max_fails=3;
③ fail_timeout:
fail_timeout 参数定义了在达到
max_fails
次数后,负载均衡器将服务器标记为不可用的时间段。在这个时间段内,负载均衡器不会向该服务器分发请求。过了这个时间段后,负载均衡器会再次尝试向该服务器发送请求,以检查其是否恢复正常。示例(Nginx):
server 192.168.1.3:80 max_fails=3 fail_timeout=30s;
示例:假设我们有一个Nginx配置,其中有三台后端服务器,其中一台被标记为 down,另外两台设置了 max_fails 和 fail_timeout:
bash
upstream backend {
server 192.168.1.1:80 down;
server 192.168.1.2:80 max_fails=3 fail_timeout=30s;
server 192.168.1.3:80 max_fails=2 fail_timeout=10s;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
解释说明:
192.168.1.1:80 被标记为 down,不会接收任何请求。
192.168.1.2:80 允许最多失败3次,失败后在30秒内不会接收请求。
192.168.1.3:80 允许最多失败2次,失败后在10秒内不会接收请求。
案例:Nginx反向代理
使用Nginx实现Web反向代理功能,实现如下功能:
- ① 后端Web服务器两台,可以使用httpd实现
- ② Nginx采用轮询的方式调用后端Web服务器(集群)
- ③ 配置upstream服务器集群池属性
**环境要求:**使用3台RHEL7虚拟机,其中一台作为Nginx代理服务器,该服务器需要配置两块网卡,IP地址分别为192.168.4.5和192.168.2.5,两台Web服务器IP地址分别为192.168.2.100和192.168.2.200。
步骤1:web1和web2,部署实施后端Web服务器(参考环境准备)
bash
[root@web1 ~]# yum -y install httpd
[root@web1 ~]# echo "I am web1" > /var/www/html/index.html
[root@web1 ~]# systemctl restart httpd
[root@web2 ~]# yum -y install httpd
[root@web2 ~]# echo "I am web2" > /var/www/html/index.html
[root@web2 ~]# systemctl restart httpd
[root@proxy ~]# curl 192.168.2.100
I am web1
[root@proxy ~]# curl 192.168.2.200
I am web2
步骤2:Proxy主机,配置Nginx服务器,添加服务器池,实现反向代理功能
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
upstream webserver { //使用upstream定义后端服务器集群,集群名称任意(如webserver)
server 192.168.2.100:80; //使用server定义集群中的具体服务器IP和端口
server 192.168.2.200:80;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://webserver; //调用集群,优先级最高(通过proxy_pass将用户的请求转发给webserver集群)
root html;
index index.html index.htm;
}
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx //启动Nginx
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
验证:
bash
[root@proxy ~]# curl 192.168.2.5 //使用该命令多次访问查看效果
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web2
通过Firefox浏览器访问192.168.2.5,反复刷新访问页面,如图所示:
Nginx采用轮询的方式调用后端Web服务器,集群的服务器越多,网页承载能力越强。
步骤3:配置upstream服务器集群池属性(weight权重)
- weight设置服务器权重值,默认值为1
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
upstream webserver{
server 192.168.2.100:80;
server 192.168.2.200:80 weight=2; //添加权重weight
}
...
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
测试:发现服务器访问测试多次,都是以权重值为2的web2访问结果最多;(1:2关系)
bash
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web2
[root@proxy ~]# curl 192.168.2.5
I am web2
步骤4:配置upstream服务器集群池属性(max_fails、fail_timeout健康检查)
- max_fails 设置最大失败次数,测试服务器几次才确认服务器失败
- fail_timeout 设置失败超时时间,单位为秒
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
upstream webserver{
server 192.168.2.100:80;
server 192.168.2.200:80 max_fails=2 fail_timeout=30; //添加服务器健康检查
}
...
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
测试1:关闭一台后端服务器(如web2)
bash
[root@web2 ~]# systemctl stop httpd
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web1
发现 web2 服务器访问测试失败2次后,等待30秒后再测试访问,若30秒依旧访问失败则继续 timeout30秒 并停止对web2访问,所以轮询结果都是web1访问;
测试2:再次启动后端服务器的httpd(如web2)
bash
[root@web2 ~]# systemctl restart httpd
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web2
当发现web2服务器访问正常,待30秒的失败超时结束后再进行web2访问;
步骤5:配置upstream服务器集群池属性(ip_hash)
应用场景:客户端访问一个需登录的服务器,服务器给客户返回例如VIP登录信息,客户反馈信息再找服务器时,可能会轮询到其它服务器,为了避免同个服务器反复的验证登录情况,添加ip_hash 得以解决;
ip_hash 调度规则为:设置相同客户端访问相同Web服务器
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
upstream webserver{
ip_hash; //添加ip_hash
server 192.168.2.100:80;
server 192.168.2.200:80 max_fails=2 fail_timeout=30;
}
...
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
测试:ip_hash会通过计算,自动分配固定的后端服务器(例如web2)
bash
[root@proxy ~]# curl 192.168.2.5
I am web2
[root@proxy ~]# curl 192.168.2.5
I am web2
[root@proxy ~]# curl 192.168.2.5
I am web2
步骤6:配置upstream服务器集群池属性(down)
down标记服务器已关机,不参与集群调度
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
upstream webserver{
server 192.168.2.100:80;
server 192.168.2.200:80 down;
}
...
测试:标记为down的服务器不参与集群调度,但服务器并未正在关机,仅暂时不使用;
bash
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web1
[root@proxy ~]# curl 192.168.2.5
I am web1
二、TCP/UDP调度
1)Ngx_stream_core_module模块
使用 --with-stream 开启该模块(可直接开启,不用配置core_module)
- 注意:nginx从1.9版本才开始支持该功能;
Stream语法格式:
在http{}外添加stream{},在server{}内添加proxy_pass
**补充:**Nginx不仅仅只有提供7层功能,还能提供4层功能,如SSH功能等;
案例:Nginx的TCP/UDP调度器
使用Nginx实现TCP/UDP调度器功能,实现如下功能:
- ① 后端SSH服务器两台
- ② Nginx编译安装时需要使用--with-stream,开启ngx_stream_core_module模块
- ③ Nginx采用轮询的方式调用后端SSH服务器
**环境要求:**使用4台RHEL7虚拟机,其中一台作为Nginx代理服务器,该服务器需要配置两块网卡,IP地址分别为192.168.4.5和192.168.2.5,两台SSH服务器IP地址分别为192.168.2.100和192.168.2.200。
步骤1:还原,并部署支持4层TCP/UDP代理的Nginx服务器
bash
[root@proxy ~]# cd ~/lnmp_soft/nginx-1.17.6/
[root@proxy nginx-1.17.6]# killall nginx
[root@proxy nginx-1.17.6]# rm -rf /usr/local/nginx/
[root@proxy nginx-1.17.6]# ./configure --with-stream --with-http_stub_status_module
[root@proxy nginx-1.17.6]# make && make install
[root@proxy nginx-1.17.6]# cd /usr/local/nginx/
[root@proxy nginx]# ls
conf html logs sbin
选项说明:
- --with-stream //--with-stream参数开启4层代理模块功能(4层:TCP/UDP)
- --with-http_stub_status_module //开启状态页面模块
步骤2:配置Nginx服务器,添加服务器池,实现TCP/UDP反向代理功能
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
stream { //创建stream新业务,需开启--with-stream
upstream backend{ //创建backend后端集群
server 192.168.2.100:22; //后端SSH服务器的IP和端口
server 192.168.2.200:22;
}
server { //新增Server
listen 12345; //Nginx监听的端口(如12345)
proxy_pass backend; //调用集群(后端)
}
}
http {
.. ..
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload //重新加载配置
- 注意:Nginx监听的端口不能写22,因代理Proxy也开启22端口,访问时会与本身22端口发生冲突;配置端口12345可以映射到集群22端口,访问时直接访问集群22端口;
测试:
bash
[root@proxy ~]# ssh 192.168.2.5 -p 12345 //使用该命令多次访问查看效果
[root@web1 ~]#
[root@proxy ~]# ssh 192.168.2.5 -p 12345
[root@web1 ~]#
补充:由于轮询方式调用后端SSH服务器,两台SSH的密码需要一样;
常见报错:~/.ssh/known_hosts记录SSH登录的主机;再次登录时可能会有风险提示影响登录,报错信息如下:
bash
[root@proxy ~]# ssh 192.168.2.5 -p 12345
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:raxUTShAWIOjwl9RKP9t63Zjs7bqKc1Lp/YNy0y1dY4.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:1
ECDSA host key for [192.168.2.5]:12345 has changed and you have requested strict checking.
Host key verification failed.
- 解决方案:rm -rf ~/.ssh/known_hosts 删除记录文件即可
**常见报错:**配置文件相关语法格式错误
bash
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
nginx: [emerg] "server" directive is not allowed here in /usr/local/nginx/conf/nginx.conf:21
分析1:server单词拼写是否有误;
分析2:配置中的【{}】是否对应;
分析3:配置文件顶部是否有不明字符;
分析4:server{}中不能嵌套其它server{}
分析5:steam{}语法格式:
三、Nginx优化
对Nginx服务器进行适当优化,解决如下问题以提升服务器的处理性能:
- ① 自定义返回给客户端的404错误页面;
- ② 查看服务器状态信息;
- ③ 客户端访问服务器提示"Too many open files"如何解决;
- ④ 解决客户端访问头部信息过长的问题;
- ⑤ 让客户端浏览器缓存数据;
HTTP常见错误代码列表:
案例1:自定义404的报错页面
优化前,客户端使用浏览器访问不存在的页面,会提示404文件未找到
修改Nginx配置文件,自定义报错页面(准备报错页面的test.jpg)
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
error_page 404 /test.jpg; //自定义404错误页面
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
- 注意:/test.jpg需要存放在/usr/local/nginx/html/目录下,不是/根目录下
测试:使用浏览器访问不存在的页面
四、Nginx状态页面
1)http_stub_status_module模块
--with-http_stub_status_module 开启模块功能;(可以查看 Nginx连接数等信息)
说明:--with-http_stub_status_module //开启status状态页面
2)Status语法格式
浏览器访问状态页面,如图所示:
3)状态信息
- Active connections:当前活动的连接数量
- Accepts:已经接受客户端的连接总数量
- Handled:已经处理客户端的连接总数量(一般与accepts一致,除非服务器限制连接数量)
- Requests:客户端发送的请求数量
- Reading:当前服务器正在读取客户端请求头的数量
- Writing:当前服务器正在写响应信息的数量
- Waiting:当前多少客户端在等待服务器的响应
案例2:定义状态页面
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
location /status {
stub_status on;
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
测试:
bash
[root@proxy ~]# curl 192.168.2.5/status //实时动态变化
Active connections: 2 //当前用户登录访问数量(当前活动的连接数量)
server accepts handled requests
15 15 11
Reading: 0 Writing: 1 Waiting: 1
补充:curl命令浏览器没有缓存,所以每次刷新访问请求会重新连接;
例如:限制仅允许192.168.2.5可访问状态页面,其它来访者拒绝访问
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
location /status {
stub_status on;
allow 192.168.2.5;
deny all;
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
测试:
五、配置优化
1)全局配置优化
- 调整进程数量
2)EVENT模块优化
- max_clients=worker_processes*worker_connections //最大客户端并发连接数
- 注意修改Linux系统ulimit限制:/etc/security/limits.conf(永久规则)
3)HTTP模块优化
- 客户端浏览器缓存数据
- 解决客户端访问头部信息过长的问题
常用压力测试工具(ab)
主要用于测试HTTP服务器(如Apache、Nginx等)的性能。它可以帮助开发人员和系统管理员评估服务器在高负载情况下的表现,包括响应时间、吞吐量和资源使用情况等。
ab
通常随Apache HTTP服务器一起安装,因此如果你已经安装了Apache,很可能已经包含了ab
工具。如果没有安装,可以通过以下方式安装:
在Ubuntu/Debian上
sudo apt-get update
sudo apt-get install apache2-utils在CentOS/RHEL上
sudo yum install httpd-tools
命令格式: ab [options] [http[s]://]hostname[:port]/path
常用选项
-n
:指定请求的总数。-c
:指定并发请求的数量。-t
:指定测试运行的最大时间(秒)。-k
:启用HTTP KeepAlive功能,即在一次连接中执行多个请求。
例如:假设我们要对http://example.com/进行压力测试,发送1000个请求,每次并发10个请求:
bash
$ ab -n 1000 -c 10 http://example.com/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking example.com (be patient).....done
Server Software: Apache/2.4.29
Server Hostname: example.com
Server Port: 80
Document Path: /
Document Length: 1234 bytes
Concurrency Level: 10
Time taken for tests: 5.000 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 1234000 bytes
HTML transferred: 1234000 bytes
Requests per second: 200.00 [#/sec] (mean)
Time per request: 50.000 [ms] (mean)
Time per request: 5.000 [ms] (mean, across all concurrent requests)
Transfer rate: 246.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 1.1 2 5
Processing: 5 45 10.0 45 60
Waiting: 5 45 10.0 45 60
Total: 6 47 10.0 47 65
解释说明:
- Server Software:服务器软件信息。
- Server Hostname:服务器主机名。
- Server Port:服务器端口。
- Document Path:请求的文档路径。
- Document Length:文档长度(字节)。
- Concurrency Level:并发级别(并发请求数)。
- Time taken for tests:测试所花费的总时间(秒)。
- Complete requests:完成的请求总数。
- Failed requests:失败的请求总数。
- Total transferred:总传输字节数。
- HTML transferred:传输的HTML字节数。
- Requests per second:每秒请求数(吞吐量)。
- Time per request:每个请求的平均时间(毫秒)。
- Transfer rate:传输速率(千字节/秒)。
**常见报错:**URL格式错误,末尾需要带"/"
bash
[root@web1 ~]# ab -c 2000 -n 2000 http://192.168.2.5
ab: invalid URL
Usage: ab [options] [http[s]://]hostname[:port]/path
案例3:优化Nginx并发量
1)优化前使用ab高并发测试
bash
[root@proxy ~]# ab -n 2000 -c 2000 http://192.168.2.5/
Benchmarking 192.168.2.5 (be patient)
socket: Too many open files (24) //提示打开文件数量过多
2)修改Nginx配置文件,增加并发量
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
worker_processes 2; //与CPU核心数量一致
events {
worker_connections 65535; //每个worker最大并发连接数(默认1024)
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
虽然nginx.conf配置文件设置了最大并发连接数,但Linux系统在文件的访问下也做了相应的次数限制,需要针对Linux内核参数进行修改;
3)优化Linux内核参数(最大访问文件数量)
- 临时修改:
bash
[root@proxy nginx]# ulimit -n //当前并发访问文件限制次数
1024
[root@proxy ~]# ulimit -a //可查看所有属性值
[root@proxy ~]# ulimit -Hn 100000 //设置硬件限制(临时规则)
[root@proxy ~]# ulimit -Sn 100000 //设置软件限制(临时规则)
[root@proxy ~]# ulimit -n
100000
**补充:**从硬件和软件层面角度,最大访问一个文件次数为100000次;
- 永久修改:
bash
[root@proxy ~]# vim /etc/security/limits.conf //永久规则(重启服务器生效)
* soft nofile 100000
* hard nofile 100000
**解释:**用户或组 硬限制或软限制 需要限制的项目 限制的值
测试:
bash
[root@proxy ~]# ab -c 2000 -n 2000 http://192.168.2.5/
Percentage of the requests served within a certain time (ms)
50% 94
66% 102
75% 106
80% 240
90% 247
95% 248
98% 249
99% 249
100% 249 (longest request)
案例4:优化Nginx数据包头缓存
长地址栏:为了添加许多功能可传递参数,使地址栏变长。(?用来传递参数)
1)优化前,使用脚本测试长头部请求是否能获得响应
bash
[root@proxy ~]# cd ~/lnmp_soft/
[root@proxy lnmp_soft]# cat buffer.sh //查看测试脚本
#!/bin/bash
URL=http://192.168.2.5/index.html? //?传递参数,例如http://192.168.2.5?ha
for i in {1..5000}
do
URL=${URL}v$i=$i
done
curl $URL //经过5000次循环后,生成一个长的URL地址栏
解释:循环5000次后http://192.168.2.5/index.htmlv1=1以此类推,生成长地址栏
测试1:http://192.168.2.5/index.html(414报错)
bash
[root@proxy lnmp_soft]# ./buffer.sh //运行脚本测试生成的长地址栏
<html>
<head><title>414 Request-URI Too Large</title></head> //提示头部信息过大
<body>
<center><h1>414 Request-URI Too Large</h1></center>
<hr><center>nginx/1.17.6</center>
</body>
</html>
2)优化后,修改Nginx配置文件,增加数据包头部缓存大小
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
http {
client_header_buffer_size 200k; //默认请求包头信息的缓存支持长度200K
large_client_header_buffers 4 200k; //大请求包头部信息的缓存个数与容量4x200K
.. ..
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
测试2:(无提示头部信息过大报错即可)
bash
[root@proxy nginx]# cd ~/lnmp_soft/
[root@proxy lnmp_soft]# ./buffer.sh //再次运行脚本测试生成的长地址栏
<title>Welcome to nginx!</title>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
例如5:浏览器本地缓存静态数据
**应用场景:**配置nginx的数据缓存,一台服务器的相同数据可能会被同一个客户反复访问,为了不重复让服务器给客户传递相同数据,达到节约资源、节省时间的目的,可以定义客户端缓存时间实现优化配置;
1)以Firefox浏览器为例,在Firefox地址栏内输入about:cache将显示Firefox浏览器的缓存信息,
点击List Cache Entries可以查看详细信息;
2)清空firefox本地缓存数据
3)修改Nginx配置文件,定义对静态页面的缓存时间
bash
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location ~* \.(jpg|html|txt|png)$ { //当用户访问的为该类型文件
expries 30d; //定义客户端缓存时间为30天
}
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload
测试:使用Firefox浏览器访问图片,再次查看缓存信息
**补充:**SS命令
可以查看系统中启动的端口信息,该命令常用选项如下:
- [-a] 显示所有端口的信息
- [-n] 以数字格式显示端口号
- [-t] 显示TCP连接的端口
- [-u] 显示UDP连接的端口
- [-l] 显示服务正在监听的端口信息,如httpd启动后,会一直监听80端口
- [-p] 显示监听端口的服务名称是什么(也就是程序名称)
注意:在RHEL7系统中可以使用 ss命令 替代 netstat命令,功能一样,选项一样。
例如:启用服务并查看监听端口状态
bash
[root@proxy nginx]# netstat -nuptl | grep httpd
tcp6 0 0 :::80 :::* LISTEN 6417/httpd
[root@proxy nginx]# ss -nuptl | grep httpd
tcp LISTEN 0 128 :::80 :::* users:(("httpd",pid=6423,fd=4),("httpd",pid=6422,fd=4),("httpd",pid=6421,fd=4),("httpd",pid=6420,fd=4),("httpd",pid=6419,fd=4),("httpd",pid=6417,fd=4))
思维导图:
小结:
本篇章节为**【第二阶段】OPERATION-DAY3**的学习笔记,这篇笔记可以初步了解到 Nginx调度器、配置upstream服务器集群池属性,HTTP错误代码、Nginx优化。除此之外推荐参考相关学习网址:
Tip:毕竟两个人的智慧大于一个人的智慧,如果你不理解本章节的内容或需要相关笔记、视频,可私信小安,请不要害羞和回避,可以向他人请教,花点时间直到你真正的理解