最新 | 最热门 | 最高评价

+0  关于FIN_WAIT1

Tag: Technical | Linux | TCP
老王 发于 2014年11月06日 18:32 | 点击: 1734 | 展开摘要
前些天,一堆人在 TCPCopy 社区里闲扯蛋,有人提了一个问题:FIN_WAIT1 能持续多久?引发了一场讨论,期间我得到斌哥和多位朋友的点化,受益良多。

让我们热热身,通过一张旧图来回忆一下 TCP 关闭连接时的情况:

TCP Close

看图可知,主动关闭的一方发出 FIN,同时进入 FIN_WAIT1 状态,被动关闭的一方响应 ACK,从而使主动关闭的一方迁移至 FIN_WAIT2 状态,接着被动关闭的一方同样会发出 FIN,主动关闭的一方响应 ACK,同时迁移

查看全文: http://www.udpwork.com/item/13483.html

+0  如何安装xsscrapy

Tag: Technical | Python
老王 发于 2014年10月30日 17:03 | 点击: 1640 | 展开摘要
我不想攻击别人,但我更不想被别人攻击。于是乎安全扫描变得格外重要,如此才能防患于未然,xsscrapy 就是这样一个漏洞检测工具。

既然这个工具是用 Python 写的,那么理论上安装应该是一件非常简单的事情:

shell> git clone https://github.com/DanMcInerney/xsscrapy
shell> cd xsscrapy
shell> pip install -r requirements.txt

不过我的服务

查看全文: http://www.udpwork.com/item/13449.html

+0  Where SLOW

Tag: Technical
老王 发于 2014年09月30日 15:12 | 点击: 725 | 展开摘要
前些天翻了翻「Wireshark数据包分析实战」,总结了一下汇聚成本文。

所谓慢,通常只是整体的主观感受,我们真正应该关心的是哪个环节最耗时?

Where Slow

判断原则按上图所示:

如果 TCP 握手或 ACK 耗时长,那么说明网络慢。

如果请求耗时长,那么说明客户端慢。

如果响应耗时长,那么说明服务端慢。

实战抓包按下图所示:

Package

对应结果依次是:正常、网络慢、客户端慢、服务端慢,如果使用 Wireshark,那么可能会发现时间显示格式有

查看全文: http://www.udpwork.com/item/13325.html

+0  一次优化引发的血案

Tag: Technical | Linux
老王 发于 2014年08月13日 19:45 | 点击: 1263 | 展开摘要
前些天一个Nginx+PHP项目上线后遭遇了性能问题,于是打算练练手,因为代码并不是我亲自写的,所以决定从系统层面入手看看能否做一些粗线条的优化。

首先,我发现服务的Backlog设置过小,可以通过ss命令查询Send-Q来确认:

shell> ss -ln
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 511 *:80

查看全文: http://www.udpwork.com/item/13118.html

+0  简易云端Hosts的构建

Tag: Technical | DNS
老王 发于 2014年07月16日 09:33 | 点击: 1262 | 展开摘要
如果大家记忆力不太差的话,那么应该会记得前段时间发生的全国性DNS解析故障:很多顶级域名被解析到了IP地址 「65.49.2.178」,导致中国互联网瘫痪了几个小时。不过在那起事件里一些移动客户端应用得以幸免,其原因在于它们使用了云端Hosts。

所谓云端Hosts,就是把原本放在本地的Hosts放到了云端,如果用JSON的话类似:

{
"foo.com": "1.2.3.4",
"bar.com": "2.4.6.8"
}

客户端跳过DNS查询过程,直

查看全文: http://www.udpwork.com/item/12746.html

+0  Nginx缓存解决方案:SRCache

Tag: Technical | Lua | Nginx
老王 发于 2014年06月20日 15:10 | 点击: 2914 | 展开摘要
前些天帮别人优化PHP程序,搞得灰头土脸,最后黔驴技穷开启了FastCGI Cache,算是勉强应付过去了吧。不过FastCGI Cache不支持分布式缓存,当服务器很多的时候,冗余的浪费将非常严重,此外还有数据一致性问题,所以它只是一个粗线条的解决方案。

对此类问题而言,SRCache是一个细粒度的解决方案。其工作原理大致如下:

SRCache工作原理

当问题比较简单的时候,通常SRCache和Memc模块一起搭配使用。网上能搜索到一些相关的例子,大家可以参考,这里就

查看全文: http://www.udpwork.com/item/12651.html

+0  Web框架与太阳系

Tag: Technical | Framework
老王 发于 2014年06月04日 11:44 | 点击: 1048 | 展开摘要
古语有云:工欲善其事,必先利其器。对于Web开发亦是如此,不过现在的Web框架实在是太多了!以PHP为例,有CakePHP、CodeIgniter、Symfony,Zend,Yii等等,到底谁是最合适的?事实上过多的选择往往会让人陷入「乱花渐欲迷人眼」的窘境,这些年我一直游走在各种PHP框架之间,却始终没有觅得属于自己的屠龙刀,于是我决定自己动手,就像歌里唱的那样:不是你亲手点燃的那就不能叫做火焰。

既然要自己动手,那么就需要明确一下设计目标,我个人主要关注以下几个方面:微

查看全文: http://www.udpwork.com/item/12586.html

+0  记我配置Nginx代理的遭遇

Tag: Technical | Nginx
老王 发于 2014年05月27日 17:14 | 点击: 5855 | 展开摘要
我一直觉得自己的Nginx知识还算过得去,可是我错了,配置Nginx代理的遭遇让我苦不堪言,即便如此,我还是挣扎着记录一二,以便让后来者能够踩着我的足迹继续前进。

说起来非常简单:某项目的搜索功能升级了,需要把请求从旧的服务代理到新的服务上面去,其中有点儿不一样的地方是参数的传递形式发生的变化,例子如下:

旧:http://www.old.com/query/lamp

新:http://www.new.com/search?q=lamp

第一次尝试:

locatio

查看全文: http://www.udpwork.com/item/12552.html

+0  监控Netstat中的TCP数据

Tag: Technical | AWK
老王 发于 2014年05月11日 21:53 | 点击: 1431 | 展开摘要
通过netstat命令,我们能获取TCP数据,监控它们有助于了解系统。

如果netstat版本比较老的话,那么运行时可能会遇到下面的错误信息:

error parsing /proc/net/netstat: Success

假设操作系统是CentOS,让我们看看如何确认netstat隶属于哪个软件包:

shell> rpm -qf $(which netstat)
net-tools-<VERSION>

如上所示,得知netstat属于net-t

查看全文: http://www.udpwork.com/item/12234.html

+0  跟我学Rsyslog

Tag: Technical | Rsyslog
老王 发于 2014年05月09日 11:34 | 点击: 5578 | 展开摘要
在数据为王的时代,日志管理是一个绕不开的话题,相应的开源软件有不少,比如热门的三件套:Logstash、ElasticSearch、Kibana,可惜我对这些高大上的东西往往心存敬畏,不敢轻易触碰,相比较而言,我更喜欢能够快速上手的东西。

对于日志管理,老版本的Linux缺省使用Syslog,其配置大致如下所示:

shell> cat /etc/syslog.conf

# Log all kernel messages to the console.
# Logg

查看全文: http://www.udpwork.com/item/12231.html

+0  如何在Redis里按模式删除数据

Tag: Technical | Redis
老王 发于 2014年04月11日 16:40 | 点击: 1399 | 展开摘要
一台Redis服务器在很短的时间里消耗了几十个G的内存,最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂,所以一时无法判断犯罪嫌疑人到底是谁。

最开始的直觉是认为肯定有人保存了大体积的数据,于是问题就变成了找出哪些键占用的空间比较大,DBA同事用了redis-rdb-tools等工具来分析数据文件。可惜的是虽然找到了一些大体积的键,但最终都排除了嫌疑,问题似乎陷入了僵局。

在被直觉带入死胡同之后,我们开始调整调查的角度:即便一个键本身占用的空间并不大,但是如果相同

查看全文: http://www.udpwork.com/item/12113.html

+0  一个Shell工具:jsondiff.sh

Tag: Technical | Shell
老王 发于 2014年03月19日 19:14 | 点击: 2020 | 展开摘要
我最近忙着重构一个历史项目,不过由于客观条件所限,没有测试用例可用,以至于我不得不通过人肉对比新旧服务器的结果集是否一致来判断对错。既然说懒惰是程序员的美德,所以我想还是写一个工具吧,加之结果集为JSON,于是便有了jsondiff.sh。

逻辑很简单,无非就是通过curl在不同的服务器上取得结果集,然后diff即可,不过这里有几点需要注意的地方:首先,JSON就一行,直接diff会失去意义;其次,JSON中汉字会被编码,不利于查看;另外,JSON中字段顺序是无所谓的,所以

查看全文: http://www.udpwork.com/item/11976.html
|<<<3456789>>>| 一共12页, 139条记录