一般来说nginx 配置文件中对优化比较有作用的为以下几项： worker_processes 8; nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数。 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一 个进程分配到多个cpu。 worker_rlimit_nofile 102400; 这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文 件数（ulimit -n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 use epoll; 使用epoll 的I/O 模型 worker_connections 102400; 每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。 keepalive_timeout 60; keepalive 超时时间。 client_header_buffer_size 4k; 客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求 头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE 取得。 open_file_cache max=102400 inactive=20s; 这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。 open_file_cache_valid 30s; 这个是指多长时间检查一次缓存的有效信息。 open_file_cache_min_uses 1; open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。 关于内核参数的优化： net.ipv4.tcp_max_tw_buckets = 6000 timewait 的数量，默认是180000。 net.ipv4.ip_local_port_range = 1024 65000 允许系统打开的端口范围。 net.ipv4.tcp_tw_recycle = 1 启用timewait 快速回收。 net.ipv4.tcp_tw_reuse = 1 开启重用。允许将TIME-WAIT sockets 重新用于新的TCP 连接。 […]
View Details一、Nginx优点： 1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。 3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。 4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS小。 5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。 6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构，在高流量环境中稳定性也很好。 7、可作为中层反向代理使用。 8、可作为静态网页和图片服务器。 9、Nginx社区活跃，第三方模块非常多，相关的资料在网上比比皆是。 Nginx常规的和HTTP请求和相应流程图： Nginx缺点： 1、适应范围较小，仅能支持http、https、Email协议。 2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 二、LVS优点： 1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。 2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。 3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。 4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。 5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。 LVS DR(Direct Routing)模式的网络流程图： LVS的缺点： 1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。 2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。 三、HAProxy优点： 1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段) 2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。 3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。 4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。 5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种 ① roundrobin 表示简单的轮询，每个服务器根据权重轮流使用，在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。最大支持4095个后端主机； ② leastconn 连接数最少的服务器优先接收连接。leastconn建议用于长会话服务，例如LDAP、SQL、TSE等，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。 ③ static-rr 每个服务器根据权重轮流使用，类似roundrobin，但它是静态的，意味着运行时修改权限是无效的。另外，它对服务器的数量没有限制。该算法一般不用； ④ source 对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器；该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑤ uri 表示根据请求的URI左端（问号之前）进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端；该算法一般用于后端是缓存服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑥ url_param 在HTTP GET请求的查询串中查找<param>中指定的URL参数，基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求；该算法一般用于将同一个用户的信息发送到同一个后端服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑦ hdr(name) 在每个HTTP请求中查找HTTP头<name>，HTTP头<name>将被看作在每个HTTP请求，并针对特定的节点；如果缺少头或者头没有任何值，则用roundrobin代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑧ rdp-cookie（name） 为每个进来的TCP请求查询并哈希RDP cookie<name>；该机制用于退化的持久模式，可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie，则使用roundrobin算法代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 haproxy的工作模型图： HAPorxy缺点： 1. 不支持POP/SMTP协议 2. 不支持SPDY协议 3. 不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。 4. 重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。 5. 多进程模式支持不够好 ——————— 作者：qi_li_juan 来源：CSDN 原文：https://blog.csdn.net/qlj324513/article/details/81541282 版权声明：本文为博主原创文章，转载请附上博文链接！
View Details前言 使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。通过负载均衡调度服务器，将来自浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。 摘自《大型网站技术架构_核心原理与案例分析》 另外，大家可以看我的这两篇博客：LVS + keepalived + nginx + tomcat 实现主从热备 + 负载均衡 和 主从热备+负载均衡（LVS + keepalived），对比下这三篇博客，其中区别及各自的优缺点需要大家好好体会。 环境准备 192.168.0.221：nginx + keepalived master 192.168.0.222：nginx + keepalived backup 192.168.0.223：tomcat 192.168.0.224：tomcat 虚拟ip(VIP):192.168.0.200，对外提供服务的ip，也可称作浮动ip 各个组件之间的关系图如下： tomcat做应用服务器 tomcat的安装不在本博客范围之内，具体可参考virtualBox安装centos，并搭建tomcat，tomcat的webapps下记得放自己的应用，我的是myWeb，如果大家也用我的myWeb，那么index.jsp中的ip需要换成自己的 将192.168.0.223、192.168.0.224上的tomcat启动起来，tomcat的路径可能和我的不一致，需要写成自己的 # cd /usr/local/tomcat7/bin # ./startup.sh 访问myWeb如下 nginx做负载均衡 nginx的安装，本文就不讲述了，具体可参考LVS + keepalived + nginx + tomcat 实现主从热备 + 负载均衡 nginx.conf内容如下
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 |
user root; #运行用户 worker_processes 1; #启动进程,通常设置成和cpu的数量相等 #全局错误日志及PID文件 error_log /usr/local/nginx/logs/error.log; error_log /usr/local/nginx/logs/error.log notice; error_log /usr/local/nginx/logs/error.log info; pid /usr/local/nginx/logs/nginx.pid; # 工作模式及连接数上线 events { use epoll; #epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能 worker_connections 1024; #单个后台worker process进程的最大并发链接数 } #设定http服务器,利用它的反向代理功能提供负载均衡支持 http { include mime.types; default_type application/octet-stream; #设定请求缓冲 server_names_hash_bucket_size 128; client_header_buffer_size 32K; large_client_header_buffers 4 32k; # client_max_body_size 8m; #sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用， #必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的uptime. sendfile on; tcp_nopush on; tcp_nodelay on; #连接超时时间 keepalive_timeout 65; #开启gzip压缩，降低传输流量 gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.1; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml; gzip_vary on; #添加tomcat列表，真实应用服务器都放在这 upstream tomcat_pool { #server tomcat地址:端口号 weight表示权值，权值越大，被分配的几率越大; server 192.168.0.223:8080 weight=4 max_fails=2 fail_timeout=30s; server 192.168.0.224:8080 weight=4 max_fails=2 fail_timeout=30s; } server { listen 80; #监听端口 server_name localhost; #默认请求设置 location / { proxy_pass http://tomcat_pool; #转向tomcat处理 } #所有的jsp页面均由tomcat处理 location ~ \.(jsp|jspx|dp)?$ { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://tomcat_pool; #转向tomcat处理 } #所有的静态文件直接读取不经过tomcat,nginx自己处理 location ~ .*\.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|pdf|xls|mp3|wma)$ { expires 30d; } location ~ .*\.(js|css)?$ { expires 1h; } #定义错误提示页面 error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } } |
主从nginx的配置文件完全一样，nginx.conf配置可复杂可简单，大家根据自己的情况自行配置，照搬上述配置也是可以的。 配置好后，启动nginx，路径要写自己的 # cd /usr/local/nginx/sbin # ./nginx 访问nginx，效果如下： 两台nginx服务器服务正常，此时是没有主从之分的，两者级别一样高，当配置keepalived之后就有了主从之分了。 keepalived实现nginx高可用(HA) keepalived的安装本文就不讲述了，具体可参考主从热备+负载均衡（LVS + keepalived） keepalived作用其实在第一张图中已经有所体现，主要起到两个作用：实现VIP到本地ip的映射； 以及检测nginx状态。 master上的keepalived.conf内容如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
global_defs { notification_email { 997914490@qq.com } notification_email_from sns-lvs@gmail.com smtp_server smtp.hysec.com smtp_connection_timeout 30 router_id nginx_master # 设置nginx master的id，在一个网络应该是唯一的 } vrrp_script chk_http_port { script "/usr/local/src/check_nginx_pid.sh" #最后手动执行下此脚本，以确保此脚本能够正常执行 interval 2 #（检测脚本执行的间隔，单位是秒） weight 2 } vrrp_instance VI_1 { state MASTER # 指定keepalived的角色，MASTER为主，BACKUP为备 interface eth0 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) virtual_router_id 66 # 虚拟路由编号，主从要一直 priority 100 # 优先级，数值越大，获取处理请求的优先级越高 advert_int 1 # 检查间隔，默认为1s(vrrp组播周期秒数) authentication { auth_type PASS auth_pass 1111 } track_script { chk_http_port #（调用检测脚本） } virtual_ipaddress { 192.168.0.200 # 定义虚拟ip(VIP)，可多设，每行一个 } } |
backup上的keepalived.conf内容如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
global_defs { notification_email { 997914490@qq.com } notification_email_from sns-lvs@gmail.com smtp_server smtp.hysec.com smtp_connection_timeout 30 router_id nginx_backup # 设置nginx backup的id，在一个网络应该是唯一的 } vrrp_script chk_http_port { script "/usr/local/src/check_nginx_pid.sh" interval 2 #（检测脚本执行的间隔） weight 2 } vrrp_instance VI_1 { state BACKUP # 指定keepalived的角色，MASTER为主，BACKUP为备 interface eth0 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) virtual_router_id 66 # 虚拟路由编号，主从要一直 priority 99 # 优先级，数值越大，获取处理请求的优先级越高 advert_int 1 # 检查间隔，默认为1s(vrrp组播周期秒数) authentication { auth_type PASS auth_pass 1111 } track_script { chk_http_port #（调用检测脚本） } virtual_ipaddress { 192.168.0.200 # 定义虚拟ip(VIP)，可多设，每行一个 } } |
nginx检测脚本check_nginx_pid.sh内容如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#!/bin/bash A=`ps -C nginx --no-header |wc -l` if [ $A -eq 0 ];then /usr/local/nginx/sbin/nginx #重启nginx if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then #nginx重启失败 exit 1 else exit 0 fi else exit 0 fi |
启动keepalived # service keepalived start 访问VIP，效果如下： 我们来看下keepalived的日志信息 master（192.168.0.221）： backup（192.168.0.222）： 当我们把master上的keepalived停掉（模拟宕机），再来看下keepalived日志 原master（192.168.0.221）： 原backup（192.168.0.222）： 通过VIP可以正常访问服务，前端请求感受不到后端nginx的切换；重新唤醒原master（192.168.0.221）的测试这里就不进行了，大家自行测试 注意点 1、执行脚本时报错：/bin/sh^M: bad […]
View Detailskeepalived的作用是检测后端TCP服务的状态，如果有一台提供TCP服务的后端节点死机，或者工作出现故障，keepalived会及时检测到，并将有故障的节点从系统中剔除，当提供TCP服务的节点恢复并且正常提供服务后keepalived会自动将TCP服务的节点加入到集群中。这些工作都是keepalived自动完成，不需要人工干涉，需要人工做的只是修复发生故障的服务器，以下通过示例来演示。 前提：为了测试能顺利进行，需先关闭selinux和firewalld。 测试环境如下： 1 2 3 4 5 keepalived主机： 10.0.0.20 keepalived备机： 10.0.0.21 http服务器1： 10.0.0.22 http服务器2： 10.0.0.23 VIP : 10.0.0.100 一、两台http服务器的安装 1、 两台机均安装httpd 1 $ sudo yum install -y httpd 2、 添加首页 1 2 3 4 5 6 7 $ sudo -i #http服务器1设置 # echo “10.0.0.22” >/var/www/html/index.html #http服务器2设置 # echo “10.0.0.23” >/var/www/html/index.html 3、 启动并设置开机启动httpd 1 2 $ sudo systemctl start httpd $ sudo systemctl enable httpd 二、两台keepalived主机的设置 1、 两台机均安装keepalived 1 2 3 #安装依赖文件与keepalive $ sudo yum install -y openssl openssl-devel keepalived 2、 keepalived主机配置 1 2 3 4 […]
View Details原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://lanlian.blog.51cto.com/6790106/1303195 一、keepalived简介： keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。 工作原理 Layer3,4&5工作在IP/TCP协议栈的IP层，TCP层，及应用层,原理分别如下： Layer3：Keepalived使用Layer3的方式工作式时，Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包（既我们平时用的Ping程序）,如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除，这种情况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效作为服务器工作正常与否的标准。 Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的状态来决定服务器工作正常与否。如web server的服务端口一般是80，如果Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。 Layer5：Layer5就是工作在具体的应用层了，比Layer3,Layer4要复杂一点，在网络上占用的带宽也要大一些。Keepalived将根据用户的设定检查服务器程序的运行是否正常，如果与用户的设定不相符，则Keepalived将把服务器从服务器群中剔除。 二、实验步骤： 1.创建管理节点在node1上，建立双机互信node1和node2，然后同步时间，安装keepalived 1 2 3 4 [root@node1~]# ansible all -m yum -a 'name=keepalived state=present' [root@node1keepalived]# rpm -qc keepalived /etc/keepalived/keepalived.conf//生成的主配置文件 /etc/sysconfig/keepalived 2.在node1上配置文件需要做一下修改 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 global_defs{ notification_email { root@localhost //收邮件人，可以定义多个 } notification_email_from kaadmin@localhost //发邮件人可以伪装 smtp_server 127.0.0.1 //发送邮件的服务器地址 smtp_connect_timeout 30 //连接超时时间 router_id LVS_DEVEL } vrrp_instanceVI_1 { //每一个vrrp_instance就是定义一个虚拟路由器的 state MASTER //由初始状态状态转换为master状态 interface eth0 virtual_router_id 51 //虚拟路由的id号，一般不能大于255的 priority 100 //初始化优先级 advert_int 1 //初始化通告 authentication { //认证机制 auth_type […]
View Details使用NGINX+Openresty实现WAF功能 一、了解WAF 1.1 什么是WAF Web应用防护系统（也称：网站应用级入侵防御系统 。英文：Web Application Firewall，简称： WAF）。利用国际上公认的一种说法：Web应用 防火墙 是通过执行一系列针对HTTP/HTTPS的 安全策略 来专门为Web应用提供保护的一款产品。 1.2 WAF的功能 支持IP白名单和黑名单功能，直接将黑名单的IP访问拒绝。 支持URL白名单，将不需要过滤的URL进行定义。 支持User-Agent的过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持CC攻击防护，单个URL指定时间的访问次数，超过设定值，直接返回403。 支持Cookie过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持URL过滤，匹配自定义规则中的条目，如果用户请求的URL包含这些，返回403。 支持URL参数过滤，原理同上。 支持日志记录，将所有拒绝的操作，记录到日志中去 1.3 WAF的特点 异常检测协议 Web应用防火墙会对HTTP的请求进行异常检测，拒绝不符合HTTP标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。 增强的输入验证 增强输入验证，可以有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为。从而减小Web服务器被攻击的可能性。 及时补丁 修补Web安全漏洞，是Web应用开发者最头痛的问题，没人会知道下一秒有什么样的漏洞出现，会为Web应用带来什么样的危害。WAF可以为我们做这项工作了——只要有全面的漏洞信息WAF能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常完美的，并且没有安装对应的补丁本身就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。 基于规则的保护和基于异常的保护 基于规则的保护可以提供各种Web应用的安全规则，WAF生产商会维护这个规则库，并时时为其更新。用户可以按照这些规则对应用进行全方面检测。还有的产品可以基于合法应用数据建立模型，并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到，可现实中这是十分困难的一件事情。 状态管理 WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件（比如登陆失败），并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。 其他防护技术 WAF还有一些安全增强的功能，可以用来解决WEB程序员过分信任输入数据带来的问题。比如：隐藏表单域保护、抗入侵规避技术、响应监视和信息泄露保护。 1.3WAF与网络防火墙的区别 网络防火墙作为访问控制设备，主要工作在OSI模型三、四层，基于IP报文进行检测。只是对端口做限制，对TCP协议做封堵。其产品设计无需理解HTTP会话，也就决定了无法理解Web应用程序语言如HTML、SQL语言。因此，它不可能对HTTP通讯进行输入验证或攻击规则分析。针对Web网站的恶意攻击绝大部分都将封装为HTTP请求，从80或443端口顺利通过防火墙检测。 一些定位比较综合、提供丰富功能的防火墙，也具备一定程度的应用层防御能力，如能根据TCP会话异常性及攻击特征阻止网络层的攻击，通过IP分拆和组合也能判断是否有攻击隐藏在多个数据包中，但从根本上说他仍然无法理解HTTP会话，难以应对如SQL注入、跨站脚本、cookie窃取、网页篡改等应用层攻击。 web应用防火墙能在应用层理解分析HTTP会话，因此能有效的防止各类应用层攻击，同时他向下兼容，具备网络防火墙的功能。 二、使用nginx配置简单实现403和404 2.1 小试身手之rerurn 403 修改nginx配置文件在server中加入以下内容 set $block_user_agent 0; if ($http_user_agent ~ "Wget|AgentBench"){ # 注意if 和(之间要有空格，否则会报错 set $block_user_agent 1; } if ($block_user_agent = 1){ return 403; } 通过其他机器去wget，结果如下 [root@mini1 ~]# wget http://192.168.3.140 --2017-05-05 14:14:53-- http://192.168.3.140/ Connecting to 192.168.3.140:80… connected. HTTP request sent, awaiting response… 403 Forbidden 2017-05-05 14:14:53 […]
View Details前言： 我们在访问淘宝的时候，会看到代码中的js和css文件是通过一次请求或得的，我们知道浏览器一次请求只能并发访问数个资源，这样的处理错输在网络传输层面可以大大节省时间，这里使用的技术就是把css、js等静态资源合并为一个资源。淘宝使用的tengine是基于nginx的web服务器，从11年底开源。所使用的是mod_concat模块，合并多个文件在一个响应报文中。 http1.1下浏览器的并发访问资源数 IE6 2 IE7 2 IE8 6 Firefox2 2 Firefox3 6 Safari 3,4 […]
View Details修改siteName为需要的重启的网站名字，将代码拷入bat文件 @echo off cd c:\Windows\System32\inetsrv appcmd stop site "siteName" appcmd start site "siteName" from:https://blog.csdn.net/a980433875/article/details/52088252
View DetailsCentos7下nginx配置https 在互联网信息安全日益重要的今天，https协议几乎成了标配，部分浏览器如果遇到非https的服务器会拒绝访问，有的平台也要求app的服务器要用https协议（如苹果、微信小程序）。 下面是个人配置https的笔记，先完整记录下来，不然到时遇到问题又各种百度。 一、步骤1 配置nginx 假如你已经申请到了https证书，而且有nginx下的版本，通常是两个文件，一个是 .key 后缀的文件，为证书的私钥，另一个是 .crt 后缀的文件，为证书的公钥。 nginx.conf 配置如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
server { listen 443 ssl; server_name www.server.com default_server; #1 ssl_certificate ssl/bundle.crt; #2 ssl_certificate_key ssl/cert.key; #3 ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; } |
把#1所在行的 www.sever.com 改成你的域名（注意：这个域名是你申请证书时用的域名）。 把#2所在行的 ssl/bundle.crt* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 把#3所在行的 ssl/cert.key* 改成你实际文件的路径，如果是相对路径，那么是相对于nginx的conf目录的路径。 如果要让用户用http协议访问时自动跳转https，则还需加上如下配置：
|
1 2 3 4 5 |
server { listen 80; server_name www.server.com; rewrite ^(.*)$ https://www.server.com; } |
就是一个url重写而已。 注意要把 www.server.com 改成你实际的主机名。 配置完后，用如下命令
|
1 |
nginx -t |
测试下配置文件有没有错误。 如果没有错误，用如下命令
|
1 |
nginx -s reload |
重启nginx，然后用浏览器测试下用https协议能否正常访问服务器。 如果不能访问，请确认下证书路径有没有问题，如果没有，请看下面的 步骤2。 二、步骤2 开启服务器的防火墙 需要该步骤是因为服务器的防火墙没有开通443端口。 centos7 下用的防火墙是firewalld，配置防火墙用命令firewall-cmd。 开通443端口
|
1 |
firewall-cmd --zone=public --add-port=443/tcp --permanent |
确认是否开通
|
1 |
firewall-cmd --list-ports |
如果可以看到443/tcp字样就说明开通了 重新加载下防火墙配置
|
1 |
firewall-cmd --reload |
执行完该步骤，大多数服务器应该可以正常用https协议访问。 如果不能，如果你用的是阿里云服务器，请看步骤3。如果是其它服务器，请自行百度。 步骤3 在安全组规则开通443端口 需要该步骤的原因是因为云服务器的安全组规则上没有开通相关的端口。 做完步骤3，应该可以用https了。如果还不能，提交工单问技术人员吧。或者再检查下步骤1与步骤2有没有做到位。 from:https://blog.csdn.net/chunyuan314/article/details/77369110
View Details