autoDevops,CI,CD
首先我们先了解Apache Gzip的相关资料。一、gzip介绍Gzip是一种流行的文件压缩算法,现在的应用十分广泛,尤其是在Linux平台。当应用Gzip压缩到一个纯文本文件时,效果是非常明显的,大约可以减少70%以上的文件大小。这取决于文件中的内容。 利用Apache中的Gzip模块,我们可以使用Gzip压缩算法来对Apache服务器发布的网页内容进行压缩后再传输到客户端浏览器。这样经过压缩后实际上降低了网络传输的字节数,最明显的好处就是可以加快网页加载的速度。网页加载速度加快的好处不言而喻,除了节省流量,改善用户的浏览体验外,另一个潜在的好处是Gzip与搜索引擎的抓取工具有着更好的关系。二、Web服务器处理HTTP压缩的过程如下:Web服务器接收到浏览器的HTTP请求后,检查浏览器是否支持HTTP压缩(Accept-Encoding 信息);如果浏览器支持HTTP压缩,Web服务器检查请求文件的后缀名;如果请求文件是HTML、CSS等静态文件,Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件;如果请求文件的压缩文件不存在,Web服务器向浏览器返回未压缩的请求文件,并在压缩缓冲目录中存放请求文件的压缩文件;如果请求文件的最新压缩文件已经存在,则直接返回请求文件的压缩文件...
 
0

apache使用gzip压缩

发表者:admin分类:Devops2015-07-15 15:15:05 阅读[2121]
apache使用gzip压缩打开http.conf文件,首先开启gzip模块:1LoadModule deflate_module modules/mod_deflate.so 然后,配置何时使用gzip压缩12345678<IfModule mod_deflate.c># 压缩等级 9DeflateCompressionLevel 9# 压缩类型 html、xml、php、css、jsSetOutputFilter DEFLATEAddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-javascript application/x-httpd-phpAddOutputFilter DEFLATE js css</IfModule> 重启apache进行测试测试代码如下: 1 <html> 2 <body> 3 </body> 4 <div id="div1">1234</div> 5 <input type="button" value="ajax请求php页面" onclick="display()" /> 6 <script src="./js/zepto.min.js" type="text/javascript" charset="utf-8"></script> 7 <script type="text/javascript" charset="utf-8"> 8 function display() 9 { 10 $.ajax( 11 { 12 type:"post", 13 url:"ne...
Web项目到IIS7上的时候,发生了如下错误,特此记录下解决方案,以备遇到同样问题的同学参考,如有问题,欢迎指正!错误如下:我的解决方案如下:在cmd中以管理员身份运行->%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i 即可,如果安装成功,则会出现如下截图如果这样还不行,就检察IIS运行池模式是不是集成模式,.Net Framework版本是不是4.0,如下:
抓哪个进程干坏事前要先停掉syslog /etc/init.d/rsyslog stop echo 1 > /proc/sys/vm/block_dump dmesg | egrep “READ|WRITE|dirtied” | egrep -o ‘([a-zA-Z]*)’ | sort | uniq -c | sort -rn | head 1423 kjournald 1075 pdflush 209 indexer 3 cronolog 1 rnald 1 mysqld 不要忘记在抓完之后关掉block_dump和启动syslog echo 0 > /proc/sys/vm/block_dump /etc/init.d/rsyslog start
关于ip_conntrack调整的一个好文   Tuning Linux firewall connection tracker ip_conntrackOverviewIf your Linux server should handle lots of connections, you can get into the problem with ip_conntrack iptables module. It limits number of simultaneous connections your system can have. Default value (in CentOS and most other distros) is 65536. To check how many entries in the conntrack table are occupied at the moment: cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count Or you can dump whole table : cat /proc/net/ip_conntrack Conntrack table is hash table (hash map) of fixed size (8192 entries by default), which is used for primary lookup. When the slot in the table is found it points to list of conntrack structures, so secondary lookup is done using list traversal. 65536/8192 gives 8 – the average list length. You may want to experiment with this value on heavily loaded systems. Modifying conntrack capacity To see the current conntrack capacity...
报错ip_conntrack version 2.4 (8192 buckets, 65536 max) - 304 bytes per conntrack     大家都知道linux的iptables防火墙使用了ip_conntrack 内核模块实现连接跟踪功能,所有的进出数据包都会记录在连接跟踪表中,包括tcp,udp,icmp等,一旦连接跟踪表被填满以后,就会发生丢包,导致网络不稳定。 在大多数系统中,缺省的连接跟踪表大小是65536,可以通过下面2条命令查看缺省大小,sysctl  net.ipv4.netfilter.ip_conntrack_maxcat  /proc/sys/net/ipv4/netfilter/ip_conntrack_max 当需要扩大连接跟踪表时,首先需要先加载ip_conntrack 模块,再通过以下接口进行调整,例如:modprobe  ip_conntracksysctl  -w net.ipv4.netfilter.ip_conntrack_max = 655360(放大10倍)。 其实,ip_conntrack 模块支持一个隐含的模块参数hashsize(隐含参数意味着通过modinfo ip_conntrack查看时没有给出的模块参数),连接跟踪表其实是一张hash表,每个hash bucket(桶)有8条记录,因此65536条记录对应8192个has...
 
0

centos7.0搭建VPN

发表者:admin分类:Devops2015-07-01 22:16:10 阅读[2054]
在百度找了很多centos7.0搭建VPN的教程,结果大量的教程都不对。文武双全用自己家里的微型电脑,安装了centos7.0并且尝试搭建一个VPN服务器。下面把修订版的教程分享给大家,此贴参考了大量百度搜索到的教程,感谢所有为本人贡献知识的人们。1,先看看你的主机是否支持pptp,返回结果为yes就表示通过。modprobe ppp-compress-18 && echo yes2,是否开启了TUN,有的虚拟机主机需要开启,返回结果为cat: /dev/net/tun: File descriptor in bad state。就表示通过。cat /dev/net/tun3,先更新下操作系统,系统自动会更新一堆的东西。yum update4,安装pppyum -y install ppp5,安装pptpd,百度到大量教程这里有错误。centos7.0下使用yum安装pptpd失败了,后来文武双全直接下载pptpd服务,手动安装的。这里说下详细的安装pptpd的教程。首先到 http://rpmfind.net/linux/rpm2html/search.php?query=pptpd 找到你操作系统所对应的pptpd的版本号。文武双全用的是centos7.0,那么对应的pptpd的版本号就是 pptpd-1.4.0-2.fc20.x86_64.rpm 。(pptpd-1.4.0-6.fc21.x86_64.rpm无法安装到centos7.0中,一定要注意。)使用wget 命令将ppt...
之前使用wdcp,被wdcp论坛中的各种一键升级脚本坑得死去活来。因为都是默认编译,所以这些脚本基本都没有附带任何功能。前不久在对抗CC攻击的过程中,文武双全把nginx和php都升级到目前的最高版本,顺便也解决了困扰我许久的wdcp下web服务拿不到真实ip的问题。特此奉上,根据wdcp官方论坛网友提供的nginx升级到任意版本的脚本,并且添加了新的编译语句。该脚本提供了附带识别真实ip的功能,用了各种cdn和阿里云的云盾的wdcp用户推荐使用哦。wdcp下nginx升级脚本的下载和安装nginx升级脚本的下载地址:http://www.yuandekai.com/down/2015/2/nginx_up.sh把脚本丢到服务器的/root目录,或者登陆服务器后,使用wget  http://www.yuandekai.com/down/2015/2/nginx_up.sh  命令下载;然后执行命令 sh nginx_up.sh 1.7.9 ;   这里1.7.9你可以填写你想升级到的任意版本nginx的版本号,我反正是直接升级到目前最高的nginx1.7.9版本了。个人建议:把服务器的nginx停掉再升级。我在nginx跑的时候升级,出现了两次升级完成后nginx.conf配置文件丢失的问题。。。我从老版本的nginx里复制了一份到升级后的nginx目录里,解决了这个问题。脚本增加了http_realip_module...
2015年2月10日下午,文武双全个人网站又被人攻击了,这次是使用webbench1.5压力测试工具发动的攻击。前后持续了一个多小时吧,看上去不像是故意帮我测试服务器的。倒像是用工具,持续不断的靠压测占满带宽,导致网站无法访问的攻击。来自美国单一ip的不间断webbench压力测试攻击此次攻击的ip,是来自于美国的单一ip:198.2.218.18。此ip在nginx里留下了,23716次攻击记录,每秒钟的并发链接在58次。如图所示:攻击的地址跟之前的也不一样,这一次主要攻击的是:http://www.yuandekai.com/category/emarkting  这个页面实际上是不存在的,应该返回404状态码的,但是文武双全的日志里竟然显示200;http://www.yuandekai.com/?s=a 这实际上是个查询页面,利用站内搜索查询所有包含“a”的页面,短期内大量的并发查询实际上对mysql是一个严峻的考验;文武双全个人网站被webbench压测攻击的日志服务器被webbench压测下的状态1,CPU没有被占满,nginx+php—fpm抗住压力;个人网站被webbench攻击下的内存占用并不高2,内存占用低于50%,此次使用阿里云的VNC,可以登录服务器,没有发生内存溢出的行为;3,带宽被占满,我3M的带宽,阿里云监控显示平均带宽占用为3.2M;文武双全解...
2014年底,文武双全个人网站刚刚遭受了一次CC攻击,详见文武双全个人网站遭遇严重CC攻击之总结 。2015年新年刚过,个人博客这又被攻击了。此次攻击是从2015年1月18日凌晨3点开始的,大约在2015年1月22日凌晨0点网站可以正常访问了。下面是此次应对CC攻击的总结,希望能够对大家以后防黑防CC有帮助。文武双全个人网站是在WDCP环境下和阿里云主机上,此文可能对以上用户有帮助。阿里云的云盾和云监控在CC面前很无力网站被CC攻击后的CPU走势图此次被CC攻击后,服务器一度无法VNC。无奈之下,我只能再次将网站加入云盾,寻求短暂保护。将云盾的罚值调整到最低的时候,云盾依然会不工作。云监控里,一点服务器的相关数据都获取不到。发生这种情况很有可能是CC攻击导致服务器内存溢出,linux将云盾和云监控的进程给杀掉了,这是我猜测的哈。而且那个蛋疼的wdcp后台,无法在云盾下获取真实ip的问题,我依然没解决。很有可能是wdcp的后台用的是单独的apache进程,需要修改wdcp的apache进程的配置文件,以后有时间再研究吧。此次CC攻击类型和上次几乎一样还是针对www.yuandekai.com这个网站的域名发动的DDOS攻击,手法跟上次几乎可以说一模一样。利用大量ip伪装成百度蜘蛛,不停的...
    总共66页,当前第23页 | 页数:
  1. 13
  2. 14
  3. 15
  4. 16
  5. 17
  6. 18
  7. 19
  8. 20
  9. 21
  10. 22
  11. 23
  12. 24
  13. 25
  14. 26
  15. 27
  16. 28
  17. 29
  18. 30
  19. 31
  20. 32
  21. 33