最新 | 最热门 | 最高评价

+0  记一次LVS/Nginx环境下的访问控制

Tag: Technical | LVS | Nginx
老王 发于 2015年01月23日 16:56 | 点击: 1479 | 展开摘要
偶然间,我发现 Graphite 显示服务器网卡流量呈锯齿状,于是查了一下 Nginx 日志,发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。

简单分析一下访问日志,很容易就能拿到了可疑的 IP 段,直接用 iptables 封杀:

shell> iptables -A INPUT -s x.y.z.0/24 -j DROP

本以为世界会就此清净,可没想到一点儿用都没有。莫非小偷已经突破锁头的限制?不能够啊!直觉告诉我问题应该和 LVS 有关,可

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

+0  Request Header Or Cookie Too Large

Tag: Technical | AWK | Nginx
老王 发于 2014年12月31日 11:45 | 点击: 1376 | 展开摘要
运营反馈 Nginx 报 400 错误,具体点说:Request Header Or Cookie Too Large。其实随便搜搜就知道可以通过加大 client_header_buffer_size 和 large_client_header_buffers 来解决问题,不过这里面有一些细节值得讨论,正所谓:知其然,知其所以然。

首先,让我们想想为何 Nginx 不能用一个指令来搞定问题,而要用两个指令?为了搞清楚这个问题,我们不妨先看看官方文档的描述:

client

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

+0  PHP优化杂烩

Tag: Technical | PHP
老王 发于 2014年12月25日 19:06 | 点击: 1311 | 展开摘要
讲 PHP 优化的文章往往都是教大家如何编写高效的代码,本文打算从另一个角度来讨论问题,教大家如何配置高效的环境,如此同样能够达到优化的目的。

pool

一个让人沮丧的消息是绝大多数 PHP 程序员都忽视了池的价值。这里所说的池可不是指数据库连接池之类的东西,而是指进程池,PHP 允许同时启动多个池,每个池使用不同的配置,各个池之间尊重彼此的主权领土完整,互不干涉内政。

pool

有什么好处呢?默认情况下,PHP 只启用了一个池,所有请求均在这个池中执行。一旦某些请求

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

+0  Poor Man PHP Profiler

Tag: Technical | AWK | PHP | Shell
老王 发于 2014年11月14日 18:50 | 点击: 1282 | 展开摘要
说起 Profiler,老派的 PHP 程序员会选 XDebug,新派的 PHP 程序员会选 Xhprof,不过我们公司的服务器上都没装,于是我写了这个「Poor Man PHP Profiler」。

既然不用 XDebug 和 Xhprof,我们就要自己找 Profiler 的数据源才行。好在 PHP 本身支持慢日志,而且里面包含了调用栈信息,还包含了文件路径和具体的行号:

Slow

理论上不用写什么工具,把这个日志从前到后看一遍就能发现系统哪里慢,但我们人穷志不短,

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

+0  关于FIN_WAIT1

Tag: Technical | Linux | TCP
老王 发于 2014年11月06日 18:32 | 点击: 1796 | 展开摘要
前些天,一堆人在 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 | 点击: 1692 | 展开摘要
我不想攻击别人,但我更不想被别人攻击。于是乎安全扫描变得格外重要,如此才能防患于未然,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 | 点击: 764 | 展开摘要
前些天翻了翻「Wireshark数据包分析实战」,总结了一下汇聚成本文。

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

Where Slow

判断原则按上图所示:

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

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

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

实战抓包按下图所示:

Package

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

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

+0  一次优化引发的血案

Tag: Technical | Linux
老王 发于 2014年08月13日 19:45 | 点击: 1305 | 展开摘要
前些天一个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 | 点击: 1299 | 展开摘要
如果大家记忆力不太差的话,那么应该会记得前段时间发生的全国性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 | 点击: 3028 | 展开摘要
前些天帮别人优化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 | 点击: 1086 | 展开摘要
古语有云:工欲善其事,必先利其器。对于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 | 点击: 6829 | 展开摘要
我一直觉得自己的Nginx知识还算过得去,可是我错了,配置Nginx代理的遭遇让我苦不堪言,即便如此,我还是挣扎着记录一二,以便让后来者能够踩着我的足迹继续前进。

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

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

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

第一次尝试:

locatio

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