前些天，一堆人在TCPCopy社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况：TCP Close看图可知，主动关闭的一方发出 FIN，同时进入 FIN_WAIT1 状态，被动关闭的一方响应 ACK，从而使主动关闭的一方迁移至 FIN_WAIT2 状态，接着被动关闭的一方同样会发出 FIN，主动关闭的一方响应 ACK，同时迁移至 TIME_WAIT 状态。回到开头的问题：FIN_WAIT1 能持续多久？一般情况下，服务器间的 ACK 确认是非常快的，以至于我们凭肉眼往往观察不到 FIN_WAIT1 的存在，不过网上也有很多案例表明在某些情况下 FIN_WAIT1 会持续很长时间，从而诱发问题。最常见的误解是认为 tcp_fin_timeout 控制 FIN_WAIT1 的过期，从名字上看也很像，但实际上它控制的是 FIN_WAIT2 的过期时间，官方文档是这样说的：The length of time an orphaned (no longer referenced by any application) connection will remain in the FIN_WAIT_2 state before it is aborted at ...继续阅读 (31)

我不想攻击别人，但我更不想被别人攻击。于是乎安全扫描变得格外重要，如此才能防患于未然，xsscrapy就是这样一个漏洞检测工具。既然这个工具是用 Python 写的，那么理论上安装应该是一件非常简单的事情：shell> git clone https://github.com/DanMcInerney/xsscrapy shell> cd xsscrapy shell> pip install -r requirements.txt不过我的服务器运行的操作系统是 CentOS 5.4 ，搭配的环境是 Python 2.4 ，于是整个过程变得异常坎坷，实际上我花了一天的时间才摸索成功，本文记录一下过程：因为 Python 版本比较旧，所以在动手之前先安装新版 Python ，这没有什么可说的，不过需要提醒的一点是，要确保包含如下开发包，否则 Python 不可用：shell> yum install openssl-devel bzip2-devel zlib-devel环境准备好了之后，在安装 xsscrapy 依赖的lxml时，出现错误：UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position …: ordinal not in range(128)看上 ...继续阅读 (39)

前些天翻了翻「Wireshark数据包分析实战」，总结了一下汇聚成本文。所谓慢，通常只是整体的主观感受，我们真正应该关心的是哪个环节最耗时？Where Slow判断原则按上图所示：如果 TCP 握手或 ACK 耗时长，那么说明网络慢。如果请求耗时长，那么说明客户端慢。如果响应耗时长，那么说明服务端慢。实战抓包按下图所示：Package对应结果依次是：正常、网络慢、客户端慢、服务端慢，如果使用 Wireshark，那么可能会发现时间显示格式有差异，改成相对时间就好了。此外赞一下CloudShark。 ...继续阅读 (44)

前些天一个Nginx+PHP项目上线后遭遇了性能问题，于是打算练练手，因为代码并不是我亲自写的，所以决定从系统层面入手看看能否做一些粗线条的优化。首先，我发现服务的Backlog设置过小，可以通过ss命令查询Send-Q来确认：shell> ss -ln Recv-Q Send-Q Local Address:Port Peer Address:Port 0 511 *:80 *:* 0 128 127.0.0.1:9000 *:*明显看出，Nginx的Backlog是511；PHP的Backlog是128，在高并发时易成为瓶颈。关于TCP队列的详细介绍，推荐阅读「TCP queue 的一些问题」，此外，大家有兴趣的可以关注一下在Linux中全连接和半连接队列长度是如何计算的。其次，我发现服务的进程数设置过少，Nginx的进程数好说，通过worker_processes指令控制，按照CPU个数设置就行了，如果版本够的话，可以直接设置成auto。PHP的进程数设置多少合适，并没有一个固定的答案，如果内存充足的话，我一般选择静态模式，并设置进程数为1024个，当然不能片面的以为进程数越多越好，不然调度会成问题。关于PHP进程数的 ...继续阅读 (36)

如果大家记忆力不太差的话，那么应该会记得前段时间发生的全国性DNS解析故障：很多顶级域名被解析到了IP地址 「65.49.2.178」，导致中国互联网瘫痪了几个小时。不过在那起事件里一些移动客户端应用得以幸免，其原因在于它们使用了云端Hosts。所谓云端Hosts，就是把原本放在本地的Hosts放到了云端，如果用JSON的话类似：{ "foo.com": "1.2.3.4", "bar.com": "2.4.6.8" }客户端跳过DNS查询过程，直接通过IP与服务端交互。用Shell模拟的话好比：shell> curl -H "Host: foo.com" http://1.2.3.4/path shell> wget -e "http_proxy=2.4.6.8" http://bar.com/path鉴于国内网络情况的复杂性，很多服务往往会同时部署在网通，电信等机房，此时应该给每个机房配置独立的云端Hosts文件，以便用户能够选择合适线路的服务器。有时候问题可能会更复杂。举个例子：若干HTTP接口，部署在北京网通和上海电信两个机房，全国各地的客户端在请求接口时，不管地理位置在哪，只要是网通线路就走北京网通；只要是电信线路就走上海电信。这些没有什么问题，但如果再加一个需求就可能有麻烦了：客户端通过HTTP接口能够拿到CDN下载地址，与HTTP接口只有北京上海两个机 ...继续阅读 (21)

前些天帮别人优化PHP程序，搞得灰头土脸，最后黔驴技穷开启了FastCGI Cache，算是勉强应付过去了吧。不过FastCGI Cache不支持分布式缓存，当服务器很多的时候，冗余的浪费将非常严重，此外还有数据一致性问题，所以它只是一个粗线条的解决方案。对此类问题而言，SRCache是一个细粒度的解决方案。其工作原理大致如下：SRCache工作原理当问题比较简单的时候，通常SRCache和Memc模块一起搭配使用。网上能搜索到一些相关的例子，大家可以参考，这里就不赘述了。当问题比较复杂的时候，比如说缓存键的动态计算等，就不得不写一点代码了，此时Lua模块是最佳选择。闲言碎语不多讲，表一表Nginx配置文件长啥样：lua_shared_dict phoenix_status 100m; lua_package_path '/path/to/phoenix/include/?.lua;/path/to/phoenix/vendor/?.lua;;'; init_by_lua_file /path/to/phoenix/config.lua; server { listen 80; server_name foo.com; root /path/to/root; index index.html index.htm index.php; ...继续阅读 (38)

古语有云：工欲善其事，必先利其器。对于Web开发亦是如此，不过现在的Web框架实在是太多了！以PHP为例，有CakePHP、CodeIgniter、Symfony，Zend，Yii等等，到底谁是最合适的？事实上过多的选择往往会让人陷入「乱花渐欲迷人眼」的窘境，这些年我一直游走在各种PHP框架之间，却始终没有觅得属于自己的屠龙刀，于是我决定自己动手，就像歌里唱的那样：不是你亲手点燃的那就不能叫做火焰。既然要自己动手，那么就需要明确一下设计目标，我个人主要关注以下几个方面：微内核、模块化、扩展性。套用陈道明说过的一句广告语：简约而不简单。在说明设计方案之前，不妨放松一下心情，聊聊看似风马牛不相及的太阳系：Solar System在我小时候，课本上教的是太阳系有九大行星，分别是：水星、金星、地球、火星、木星、土星、天王星、海王星和冥王星。其中，冥王星较小，后来，人们发现还有一些和冥王星类似的天体也在围绕太阳运转，如果冥王星被划为行星的话，那么这些天体无疑也属于行星，此时太阳系到底有几大行星的问题彻底让天文学家蒙圈了，最后他们耍了一个小聪明，剥夺冥王星的行星资格就行了，从此太阳系就只剩八大行星了。当然，我并不是让你关注这些天文学上的八卦往事，实际上我希望你关注的是太阳系的结构模式：有的行星是丁克家庭，没有卫星，比如水星和金星；有的行星是计划生育标兵，比如地球只有一个卫星（月亮）；有的行星是 ...继续阅读 (34)

通过netstat命令，我们能获取TCP数据，监控它们有助于了解系统。如果netstat版本比较老的话，那么运行时可能会遇到下面的错误信息：error parsing /proc/net/netstat: Success假设操作系统是CentOS，让我们看看如何确认netstat隶属于哪个软件包：shell> rpm -qf $(which netstat) net-tools-如上所示，得知netstat属于net-tools软件包，通常升级它就可以修复错误了：shell> yum update net-tools在「netstat -s」中，TCP数据分为Tcp和TcpExt两部分，本文监控的是前者：Tcp: 10549129725 active connections openings 10556220620 passive connection openings 28458277 failed connection attempts 3248285 connection resets received 234 connections established 289641890208 segments received 229159129140 segments send out 805264756 segmen ...继续阅读 (31)

在数据为王的时代，日志管理是一个绕不开的话题，相应的开源软件有不少，比如热门的三件套：Logstash、ElasticSearch、Kibana，可惜我对这些高大上的东西往往心存敬畏，不敢轻易触碰，相比较而言，我更喜欢能够快速上手的东西。对于日志管理，老版本的Linux缺省使用Syslog，其配置大致如下所示：shell> cat /etc/syslog.conf # Log all kernel messages to the console. # Logging much else clutters up the screen. # kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cr ...继续阅读 (28)

一台Redis服务器在很短的时间里消耗了几十个G的内存，最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂，所以一时无法判断犯罪嫌疑人到底是谁。最开始的直觉是认为肯定有人保存了大体积的数据，于是问题就变成了找出哪些键占用的空间比较大，DBA同事用了redis-rdb-tools等工具来分析数据文件。可惜的是虽然找到了一些大体积的键，但最终都排除了嫌疑，问题似乎陷入了僵局。在被直觉带入死胡同之后，我们开始调整调查的角度：即便一个键本身占用的空间并不大，但是如果相同模式的键数量很多的话，那么合计起来一样会占用大量空间，于是问题就变成了找出哪些相同模式的键占用的空间比较大。这次我不想用什么工具，而是打算在测试服务器上一边删除可疑键一边查看内存变化情况：shell> /path/to/redis-cli keys foo:* | xargs /path/to/redis-cli del悲催的是一运行这个命令服务器就挂了！因为数据太多了，所以KEYS受不了。此时应该使用SCAN，它有游标的概念，每次迭代只涉及很少的数据。直接在命令行使用SCAN有些麻烦，于是我用了PHP：php $redis = new Redis(); $redis-setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY); $match = 'foo:*'; $count = ...继续阅读 (33)