GNUers 博客

设置TIME_WAIT的目的

设置TIME_WAIT的两个原因是：1.实现了全双工的TCP连接关闭。TIME_WAIT会出现在主动关闭这端的原因是：该端发出最后一个ACK后，如果这个ACK丢失或最后一个FIN丢失，另外一段将会超时重传最后的FIN。主动关闭这端由于TIME_WAIT的存在可以在需要的时候重传最后的确认报文，否则它收到最后的FIN后可能无法重传最后的ACK，而只能发出RST。另外TIME_WAIT总是从收到最后一个FIN开始算起，当它收到对端重传的FIN后会重新计时。2.过时的重复报文段失效每个IP数据包的有效时间由TTL（长度定义为8bit，所以最多经过的路由次数是255）限制。MSL定义为报文的最大生存时间，Linux下是30s。每个连接的新的替身只能在2MSL后才能再次发起，主要是为了保证前一个连接的过时重复报文段不会在新的连接出现，保证不会被误认为是第二次连接的报文段。

用python解压web服务器返回的gzip数据

之前用tcpdump抓包的时候，只要是gzip压缩过的数据就没有办法直接还原原始的数据。这段时间学了一下python正好看里面有gzip模块。今天先尝试了一下解压web server返回的压缩过的数据。测试了一下OK #!/usr/bin/env python import urllib2 import gzip import binascii from StringIO import StringIO def gunziptxt(data): buf = StringIO(data) of =gzip.GzipFile(fileobj=buf,mode="rb") outdata=of.read() return outdata url="http://127.0.0.1/index.html" request=urllib2.Request(url,headers={'User-agent':"python urllib browser","Accept-Encoding":'gzip'}) try: response=urllib2.urlopen(request,timeout=5) data=response.read() except: print “get %s response failed” %url print “headers:\n”,response.info() if response.info()[“content-encoding”] == ‘gzip’: print “http resonse is gzip” outdata=gunziptxt(data) lbuf=StringIO() with gzip.GzipFile(mode=‘wb’,fileobj=lbuf) as inf: inf.write(data) gziplen=len(lbuf.getvalue()) print “gzip %d and gunzip %d”%(gziplen,len(outdata)) else: print “http resonse is not gzip” outdata=data print “http response:\n”,outdata ...

awk实时统计PV

今天有人问我怎么实时统计一下访问量的大小。其实在公司是有专门的监控系统做这些基本的访问量，服务调用，业务数据的完整分析。不过就简单根据apache或者nginx的日志来看看PV的话，可以直接tail日志给awk处理。 #pv.f #假设第4列的格式是：[31/May/2013:13:46:31 +0800] #第6列是GET 或者POST 表示访问的方式 function pt(a) { for (i in a) { printf("%s -- %d\n",i,a[i]); } } { t=substr($4,9,13); #per second if ( per == 1) { t=substr($4,9,10); #per minute } if( k != t ) { if( length(k)>2) { pt(af); } delete af; k=t; } else if( k == t) { FLAG=t; if ($6 ~ "GET" || $6 ~ "POST" ) { af[FLAG]++; } } } ![pv530](/picture/a7cf7ca7.png)

nginx+uwsgi+django配置

这几天有点时间开始学习了一下django。昨天是直接用自带的manage.py启动的。今天简单查了几下几种模式，后来选了uwsgi模式开跑django，主要是nginx自带了这个模块，比较方便。1.nginx的配置nginx的配置比较简单的，写个upstream然后写一下uwsgi_pass就OK。 server { ........... location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. # try_files $uri $uri/ /index.html; # Uncomment to enable naxsi on this location # include /etc/nginx/naxsi.rules include uwsgi_params; uwsgi_pass django; uwsgi_buffer_size 8k; uwsgi_intercept_errors on; } } upstream django { server 127.0.0.1:9000; keepalive 1; } 配置uwsgi #/etc/uwsgi/apps-available/django.ini [uwsgi] socket = 127.0.0.1:9000 chdir = /home/pm/study/django/pystudy daemonize=/home/pm/study/django/pystudy/pystudy.log pidfile= /tmp/uwsgi.pid module=pystudy.wsgi:application master=True uid=pm gid=pm plugin = python processes = 2 threads = 4 stats = 127.0.0.1:9001 在apps-enabled建立链接到apps-available/django.ini 的软链接。启动直接sudo /etc/init.d/uwsgi start即可不过这个uwsgi的启动脚本貌似有问题，明明启动好了显示失败，而且uwsgi stop也没有把进程给停掉。 ...

nginx设置根据参数进行跳转

线上有个老系统要下线，发现有个老的接口还有人在用。其实之前这个接口也只是根据URL中的target参数进行一个跳转。这个直接在nginx里面做也是比较简单的，直接从$arg_target里把匹配的目标地址（包括参数）都提取出来，然后放到rewrite里面就OK。因为对应的参数实际已经被匹配下来了（只有GET请求，没有POST的），所以rewrite语句里面加了一个‘？“避免自动把之前的$args加到后面。 location =/redir.do { root /home/nginx/webpages/; set $to_url 'www.xxx.net'; if ( $arg_target ~* 'https?://(.*)' ) { set $to_url $1; } if ( $arg_target ~* 'https?%2F(.*)' ) { set $to_url $1; } rewrite ^ http://$to_url? break; }

BitTorrent Sync试用

今天想着把去年海淘的T530拿出来打理一下，就直接sftp把工作笔记本的文件拖到了新电脑。其实一直想试试网盘的，现在多个电脑切来切去的经常发现某个文件在另外的一个电脑上，非常不方便。考虑到数据安全就同步到内部网盘上了。下午正好无聊发现有个BitTorrent Sync是专门做局域网内部的文件同步的，Linux下也可以很方便地使用。就简单试了下。使用还是比较简单的，看一下http://labs.bittorrent.com/experiments/sync/get-started.html#getting-started的介绍一目了然。本是准备在测试环境搞台服务器和我自己电脑上的进行同步。不过可能是因为我电脑是挂在自己的一个路由器下亦或是测试环境访问不了办公网络的原因，所以同步没有成功。为了测试一下功能就直接搞了2个测试服务器上玩，试了下是可以同步的。下载http://btsync.s3-website-us-east-1.amazonaws.com/btsync_x64.tar.gz解压后直接运行btsync后会看到有一个后台进程，默认的管理端口是8888,可以登陆操作。1. 如果是主动要分享文件的话就之间点一下获取安全码，再选择一下要分享的目录即可。可以设置为只读同步，或者允许对方更新后本地也进行更新。2. 如果是要同步其他机器分享的文件，就输入其他机器对应目录的安全码，再选择后同步的目标目录。 2个机器直接的同步后，可以在另外的机器上修改删除文件，这样原来的源服务器上的文件也会进行更新。不过这样就会有点问题，万一某个机器的数据被误删除了，所有机器的文件都没有了。不过好在可以设置“Delete files to Sync Trash”把删除的文件放在回收站。

nginx同时listen ipv4和ipv6端口

其实根据nginx的wiki的表述,在linux下一般默认的监听ipv6的一个端口会同时把ipv4的端口相应地监听起来。除非自己手动设置了/proc/sys/net/ipv6/bindv6only为1。今天重新编译了nginx后发现在ipv4环境下blog不能访问了，但是ipv6环境下是可以正常访问的。就单独搞了一下原来的配置是listen [::]:443 ssl so_keepalive=on;listen [::]:80 so_keepalive=on; listen [::]:443 ssl so_keepalive=on ipv6only=on spdy; listen 443 ssl so_keepalive=on spdy; listen [::]:80 so_keepalive=on ipv6only=on; listen 80 so_keepalive=on; 表述

nginx开启pagespeed和sdpy

nginx 1.4.0已经增加了sdpy协议的支持。所以只需要简单的编译即可。另外这段时间炒的很热的google pagespeed模块也出了一个beta版本。pagespeed编译后实在是比之前大了太多，表示有点难以接受。1.编译安装新版的openssl,因为debian stable带的openssl版本太老不支持NPNwget http://www.openssl.org/source/openssl-1.0.1e.tar.gz && tar zxvf openssl-1.0.1e.tar.gzcd openssl-1.0.1e && ./Configure –prefix=/opt/openssl再修改一下Makefile：INSTALL_PREFIX=/opt/opensslmake && make install1.下载好nginx```bash wget http://nginx.org/download/nginx-1.4.0.tar.gz && tar zxvf nginx-1.4.0.tar.gz wget https://github.com/pagespeed/ngx_pagespeed/archive/release-1.5.27.2-beta.zip && unzip release-1.5.27.2-beta.zipcd ngx_pagespeed-release-1.5.27.2-beta/wget https://dl.google.com/dl/page-speed/psol/1.5.27.2.tar.gz && tar -xzvf 1.5.27.2.tar.gz ./configure –prefix=/usr/share/nginx1.4 –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-client-body-temp-path=/var/lib/nginx/body –http-fastcgi-temp-path=/var/lib/nginx/fastcgi –http-log-path=/var/log/nginx/access.log –http-proxy-temp-path=/var/lib/nginx/proxy –http-scgi-temp-path=/var/lib/nginx/scgi –http-uwsgi-temp-path=/var/lib/nginx/uwsgi –lock-path=/var/lock/nginx.lock –pid-path=/var/run/nginx.pid –with-pcre-jit –with-debug –with-file-aio –with-http_addition_module –with-http_dav_module –with-http_gzip_static_module –with-http_secure_link_module –with-http_stub_status_module –with-http_ssl_module –with-http_sub_module –with-http_xslt_module –with-ipv6 –with-openssl=/opt/openssl/usr/local/ssl/ –add-module=/root/soft/ngx_pagespeed-release-1.5.27.2-beta –with-http_spdy_module需要注意得修改一下objs/Makefile里的东西，把.openssl都删除掉 ====编译了pagespeed模块的nginx会接近100M，表示不可接受我就把这个模块去掉了。。只单独编译了一个支持sdpy模块的nginx。

nginx下使用$upstream_cache_status来标记缓存命中状态

之前把blog改成前端nginx直接缓存一下页面时，没有注意有$upstream_cache_status这个变量可以直接获取到命中的状态。所有就用了另外的一点小方法来判断是否命中缓存。map $upstream_addr $hitstatus {default ‘cache’ ;~unix ‘nocache’;} add_header Cache-status $upstream_cache_status;

tomcat的keepalive时间设置问题

前几天进行线上的压测，发现应用的性能比之前还降低了就进行了一些分析。应用的结构是基础的apache+mod_jk+jboss的模式。主要的原因是之前的很多默认参数设置不合理，比如jk的配置worker.list=localworker.local.type=ajp13worker.local.host=localhostworker.local.port=8001worker.local.lbfactor=50worker.local.cachesize=100 #当前配置大于每个进程的最多线程数50，需要减小worker.local.cache_timeout=600 #闲置连接的清理时间worker.local.socket_keepalive=1worker.local.recycle_timeout=300 # #作用和cachesize类似但是在non-cache 的时候也能用 11:17:02.983554 IP (tos 0x0, ttl 64, id 26914, off set 0, flags [DF], proto 6, length: 60) 127.0.0.1.47060 > 127.0.0.1.7001: S [tcp sum ok] 3713142601:3713142601(0) win 3276711:17:02.983570 IP (tos 0x0, ttl 64, id 0, off set 0, flags [DF], proto 6, length: 60) 127.0.0.1.7001 > 127.0.0.1.47060: S [tcp sum ok] 3721181851:3721181851(0) ack 3713142602 win 32767 13:05:37.104641 IP (tos 0x0, ttl 64, id 0, off set 0, flags [DF], proto 6, length: 60) 127.0.0.1.7001 > 127.0.0.1.47265: S [tcp sum ok] 2010311520:2010311520(0) ack 2018476636 win 3276713:05:45.476963 IP (tos 0x0, ttl 64, id 17630, off set 0, flags [DF], proto 6, length: 60) 127.0.0.1.47280 > 127.0.0.1.7001: S [tcp sum ok] 2021138150:2021138150(0) win 3276713:05:45.476981 IP (tos 0x0, ttl 64, id 0, off set 0, flags [DF], proto 6, length: 60) 127.0.0.1.7001 > 127.0.0.1.47280: S [tcp sum ok] 2016571274:2016571274(0) ack 2021138151 win 3276713:06:11.061661 IP (tos 0x0, ttl 64, id 48536, off set 0, flags [DF], proto 6, length: 52) 127.0.0.1.7001 > 127.0.0.1.47265: F [tcp sum ok] 1642:1642(0) ack 467 win 819213:06:17.641781 IP (tos 0x0, ttl 64, id 13753, off set 0, flags [DF], proto 6, length: 52) 127.0.0.1.7001 > 127.0.0.1.47280: F [tcp sum ok] 1642:1642(0) ack 467 win 8192