Linux云计算 |【第二阶段】OPERATION-DAY3

news2024/11/15 5:46:57

主要内容:

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主机都需要)

[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)

[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)

[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)

[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测试访问:

[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:

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服务器(参考环境准备)

[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服务器,添加服务器池,实现反向代理功能

[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   //重新加载配置

验证:

[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
[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关系)

[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 设置失败超时时间,单位为秒
[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)

[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)

[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服务器

[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)

[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标记服务器已关机,不参与集群调度

[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的服务器不参与集群调度,但服务器并未正在关机,仅暂时不使用;

[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服务器

[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反向代理功能

[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端口;

测试:

[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登录的主机;再次登录时可能会有风险提示影响登录,报错信息如下:

[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 删除记录文件即可

常见报错:配置文件相关语法格式错误

[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)

[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:定义状态页面

[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
location /status {
    stub_status on;    
}
[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload

测试:

[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可访问状态页面,其它来访者拒绝访问

[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个请求:

$ 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格式错误,末尾需要带“/”

[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高并发测试

[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配置文件,增加并发量

[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内核参数(最大访问文件数量)

- 临时修改:

[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次;

- 永久修改:

[root@proxy ~]# vim /etc/security/limits.conf    //永久规则(重启服务器生效)
*               soft   nofile            100000
*               hard   nofile            100000

解释:用户或组   硬限制或软限制  需要限制的项目 限制的值

测试:

[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数据包头缓存

长地址栏:为了添加许多功能可传递参数,使地址栏变长。(?用来传递参数)

例如:https://www.baidu.com/s?ie=UTF-8&wd=https%3A//www.baidu.com/%23ie=UTF-8&wd=%25E5%259B%25BE%25E7%2589%2587asd

1)优化前,使用脚本测试长头部请求是否能获得响应

[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报错)

[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配置文件,增加数据包头部缓存大小

[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:(无提示头部信息过大报错即可)

[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配置文件,定义对静态页面的缓存时间

[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命令,功能一样,选项一样。

例如:启用服务并查看监听端口状态

[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优化。除此之外推荐参考相关学习网址:

  • 深度详解Nginx正向代理与反向代理(转) - 拓扑园

Tip:毕竟两个人的智慧大于一个人的智慧,如果你不理解本章节的内容或需要相关笔记、视频,可私信小安,请不要害羞和回避,可以向他人请教,花点时间直到你真正的理解

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2041877.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

在HMI项目中,传感器扮演的角色是啥?一文告诉你。

说到HMI项目&#xff0c;就绕不开物联网&#xff0c;说到物联网就不得不说传感器&#xff0c;本文大千UI工场带你详细了解传感器的价值。 一、传感器的价值 在HMI&#xff08;Human-Machine Interface&#xff09;项目中&#xff0c;传感器扮演着收集和监测实时数据的角色。传…

Tire树-存储与查找

#include <iostream>using namespace std;const int N 100010; // 定义常量 N 表示字典树节点的最大数量int son[N][26], cnt[N], idx; // son数组存储字典树&#xff0c;cnt数组记录某个字符串结束时的节点个数&#xff0c;idx表示当前字典树的节点总数 char str[N];…

数据结构之----堆

一、介绍 堆是一棵完全二叉树。堆又分为大堆&#xff0c;小堆两种结构。 大堆&#xff1a;所有的父节点都比它的子节点要大。 小堆&#xff1a;所有的父节点都比它的子节点要小。 二、堆的向上调整算法 比如要建一个小堆 思路&#xff1a;将父节点和子节点比较&#xff0c…

驰骋BPM RunSQL_Init SQL注入漏洞复现

0x01 产品简介 驰骋BPM系统由济南驰骋信息技术有限公司研发,具有悠久的历史和丰富的行业经验。其工作流引擎CCFlow自2003年开始研发,是国内知名的老牌工作流引擎,在BPM领域拥有广泛的研究群体与应用客户群。统提供.net与java两个版本,且两个版本的代码结构、数据库结构、设…

手写数字识别实战

全部代码&#xff1a; import matplotlib.pyplot import torch from torch import nn # nn是完成神经网络相关的一些工作 from torch.nn import functional as F # functional是常用的一些函数 from torch import optim # 优化的工具包import torchvision from matplotlib …

简单回归问题实战

数据表&#xff1a;链接: https://pan.baidu.com/s/1sSz7F_yf_JeumXcP4EjE5g?pwd753f 提取码: 753f 核心流程&#xff1a; import numpy as np # 计算误差函数 points是数据集中数据的位置 def compute_error_for_line_given_points(b,w,points):totalError0for i in range(0…

【FreeRTOS】队列的本质

目录 0 前言1. 数据传输的方法1.1 任务之间如何传输数据1.2 队列的本质1.3 操作队列的三个步骤 2 队列2.1 举例说明2.2 唤醒流程2.2.1 情况12.2.2 情况2 3 总结 0 前言 学习视频&#xff1a; 【FreeRTOS入门与工程实践 --由浅入深带你学习FreeRTOS&#xff08;FreeRTOS教程 基…

Haproxy基于cookie的会话保持

cookie value&#xff1a;为当前server指定cookie值&#xff0c;实现基于cookie的会话黏性&#xff0c;相对于基于 source 地址hash 调度算法对客户端的粒度更精准&#xff0c;但同时也加大了haproxy负载&#xff0c;目前此模式使用较少&#xff0c; 已经被session 共享服务器代…

亚信安慧AntDB-M聚合下推—加速你的数据分析查询

摘 要 在业务系统中&#xff0c;一般的事务型SQL语句涉及到的数据记录数不会很多&#xff0c;即便涉及到多个数据节点&#xff0c;基于AntDB-M的优化&#xff0c;访问也都很快。但是统计分析型SQL语句往往涉及到大量数据&#xff0c;甚至包括全表数据&#xff0c;基本都会覆盖…

3D 技术对我们的生活有哪些影响?

3D技术&#xff0c;也称为三维技术&#xff0c;是指利用计算机生成或处理三维数据的技术。它在多个领域对我们的生活产生了深远的影响&#xff1a; 1、制造业&#xff1a;3D技术使得个性化和定制化生产成为可能&#xff0c;大幅缩短了产品从设计到制造的时间&#xff0c;降低了…

【人工智能】Transformers之Pipeline(十):视频分类(video-classification)

目录 一、引言 二、视频分类&#xff08;video-classification&#xff09; 2.1 概述 2.2 技术原理 2.3 应用场景 2.4 pipeline参数 2.4.1 pipeline对象实例化参数 2.4.2 pipeline对象使用参数 2.4 pipeline实战 2.5 模型排名 三、总结 一、引言 pipeline&#x…

网络编程 8/15 基于UDP多人聊天室

//客户端代码 #include <myhead.h> struct msgType {char type; // 消息类型L:登录&#xff0c;Q:退出&#xff0c;C:聊天char usrName[20];char msgText[1024]; }; #define SER_PORT 6666 // 服务器端口 #define SER_IP "192.168.2.161" // 服务器IP…

SpringBoot解决创建项目无法选择JDK8和JDK11

文章目录 解决方案1解决方案2 在创建SpringBoot项目的时候&#xff0c;我们发现只能勾选JDK17以上的。并且官方没有提供2.X版本&#xff0c;但是目前大多数企业使用的还是 springboot 初始化的网址&#xff0c;我们一般使用的是官方的网址。 解决方案1 就选择jdk17和spring…

BIM+GIS在管廊机电监控与运维管控系统中的应用

研究背景 根据《GB50838-2015城市综合管廊工程技术规范》及《GBT51274-2017城镇综合管廊监控与报警系统工程技术标准》的相关条款要求&#xff0c;城市综合管廊监控报警系统用于对综合管廊内的设备运行状态及参数、实时环境信息、出入口状态等进行全方位在线监控&#xff0c;保…

java基础概念17-static

一、 static的作用 static修饰的变量、方法被类的所有实例共享。 示例&#xff1a; static用于声明属于类本身的变量、方法&#xff0c;而不是类的某个特定对象的。 二、static内存图 静态区中的成员变量&#xff0c;对象共享&#xff0c;内存中只有一份&#xff0c;谁要用&am…

u2net 和u2netp 的具体区别

U2Net和U2NetP是两种基于深度学习的图像分割模型&#xff0c;它们都使用了编码器-解码器架构和跳跃连接来提高分割的精度。然而&#xff0c;它们在网络结构和参数配置上存在一些差异。 初始化阶段的中间通道数 (mid_ch): U2Net: self.stage1 RSU7(in_ch, 32, 64)U2NetP: self.…

RHEL8 配置epel源

** RHEL8 配置epel源 ** 此次环境为最小化安装&#xff0c;版本信息如下&#xff1a;redhat8 一、安装epel源&#xff0c;执行如下命令&#xff1a; #yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm 之后执行#yum repolis 此时我们…

山海关古城测试--房产房屋

1.树状图搜索房产 1.1实现思路 因为树状图搜索要显示在界面中&#xff0c;所以需要在html文件中进行添加树状结构 而树状结构怎么来的&#xff0c;所以需要在controller中新写一个方法来传输一个树状结构&#xff0c;让html直接访问它即可树状结构在framework->web->Zt…

ES主分片和副本分片

在 Elasticsearch 中&#xff0c;主分片的数量在创建索引时设置&#xff0c;并且不能在索引创建后更改。主分片的数量因索引而异&#xff0c;对于每个索引&#xff0c;可以根据实际需要进行调整。 主分片数量的设置 默认值&#xff1a; 在 Elasticsearch 中&#xff0c;默认的主…

C++入门基础(太干了,别噎住)

1.C了解&#xff08;可跳过&#xff09; 1.1 C发展历史 C的起源可以追溯到1979年&#xff0c;当时Bjarne Stroustrup(本贾尼斯特劳斯特卢普&#xff0c;这个翻译的名字不同的地方可能有差异)在贝尔实验室从事计算机科学和软件工程的研究工作。面对项目中复杂的软件开发任务&am…