09年，有一款脚本相当流行，通过创建随机的tag以及分类，或者给搜索参数添加随机数字/字符串来达到拖挂MySQL的目的。

其实不单单对于对搜索没有防备的WordPress有效，对于任何资源有限，而执行时间比较长，没有缓存的操作，都有一定的杀伤力，如果IP数量比较多，且持久的进行测试/攻击，那么便可以造成拒绝服务的效果。

昨天发帖之后，有个童鞋倒是提醒了我，于是更新了一下内存缓存的策略。

  • 首先最重要的一点是限制请求的频率，iptables和fail2ban是对好基友，交给他们妥妥的。
  • 附带着用nginx把连接数也限制掉，最后降低redis中对于搜索结果页面的缓存时间。
  • 其实使用了object-cache后，击穿redis中的mysql快照的可能性本身就小了很多
  • 顺带还做了一些其他的事情，不过不重要了，来聊聊站内搜索好了。

搜索无意是计算机乃至互联网中的一项重要功能，有个段子，linux中重要的工具都变成了网络服务，其中grep变成了Google。

但是对于个人博客来说，就不尽然了。

首先个人站点内内容数量少，不算BSP上写过的内容，光是这个WP站，也有7~8年的历史了，但是文章不过千余，而根据最近30天的统计数据来看，只有32%的人会是直接访问网站，而多数人都是因为特定的文章或者推荐，直接到达想要获取的内容的页面，一般来说，访客在看到内容，或者下载完毕附件之后就会离开，除非你的内容激起了共鸣或者聚合了一堆他感兴趣的事情，观察数据，后者只有24.99%，并且后者多数是通过翻看类目下的文章来进行内容的获取。

继续观察数据，某些页面成为入口页面的比重就大于首页10%以上是常见状态，而平均停留时长为4~5分钟，恰好足够阅读一篇热点文章，而没有给额外的交互操作留下时间，加之直接来访的跳出率有64%，所以，搜索功能弱化掉，只放在首页，个人觉得比较合适。

并且，对于搜索内容，因为在页面元标签内限定了机器人none，所以，会重复进行接口访问的，一般来说只有正常人和来捣乱但是我不会给糖的孩子了，而正常人不会有太多的搜索交互，除非他输入法过愚人节嗨的停不下来，或者文章内有太多的暗示去搜索，以及给出了搜索链接，而这些我都不会去做（忘记了，还有我自己，或许我是使用搜索功能的最大用户了吧，下次做个统计）。

最后补一下开头说的Search flood exploit问题，在wordpress trac中ticket的地址：