很早就看过，不过那时候没网站，也就没上心，自从开了JQ公会 ，头两月还好，第三个月搜狗的爬虫每天就占了几G的流量，不过那时候是虚拟主机，可配置性不大。现在转到VPS，也要开始注意了。
http://robbin.javaeye.com/
因为搜索引擎的流行，网络爬虫已经成了很普及网络技术，除了专门做搜索的Google，Yahoo，微软，百度以外，几乎每个大型门户网站都有自己的搜索引擎，大大小小叫得出来名字得就几十种，还有各种不知名的几千几万种，对于一个内容型驱动的网站来说，受到网络爬虫的光顾是不可避免的。
一些智能的搜索引擎爬虫的爬取频率比较合理，对网站资源消耗比较少，但是很多糟糕的网络爬虫，对网页爬取能力很差，经常并发几十上百个请求循环重复抓取，这种爬虫对中小型网站往往是毁灭性打击，特别是一些缺乏爬虫编写经验的程序员写出来的爬虫破坏力极强。曾经有一次我在JavaEye 的日志里面发现一个User-Agent是Java的爬虫一天之内爬取了将近100万次动态请求。这是一个用JDK标准类库编写的简单爬取网页程序，由于JavaEye网站内部链接构成了回环导致程序陷入了死循环。对于JavaEye这种百万PV级别的网站来说，这种爬虫造成的访问压力会非常大，会导致网站访问速度缓慢，甚至无法访问。
此外，相当数量的的网页爬虫目的是盗取目标网站的内容。比方说JavaEye网站就曾经被两个竞争对手网站爬取论坛帖子，然后在自己的论坛里面用机器人发帖，因此这种爬虫不仅仅影响网站访问速度，而且侵犯了网站的版权。
对于一个原创内容丰富，URL结构合理易于爬取的网站来说，简直就是各种爬虫的盘中大餐，很多网站的访问流量构成当中，爬虫带来的流量要远远超过真实用户访问流量，甚至爬虫流量要高出真实流量一个数量级。像JavaEye网站虽然设置了相当严格的反爬虫策略，但是网站处理的动态请求数量仍然是真实用户访问流量的2倍。可以肯定的说，当今互联网的网络流量至少有2/3的流量爬虫带来的。因此反爬虫是一个值得网站长期探索和解决的问题。
阅读全文…
之前看的很多was优化案例，包括自己实施过程中都只从WebSphere的角度来考虑问题，虽然WAS的优化中包括了操作系统层面的优化，比如对AIX、HPUX的系统参数做出调整，对于网络tcp的参数做出改动，但并没有更进一步，在进行LPAR分区前就做出完整的规划。
WebSphere管理员和硬件与操作系统管理员往往交流不多，且是串行的实施顺序。虽说也就那么做下来了，但是是否充分发挥了硬件的资源，是否达到了最好的性能，最稳定的运行，还是可以有改进的余地？都值得探讨。IBM网站上这三篇文章可谓打通了两种管理员之间的任督二脉，看懂了总有好处。
本书提供了整体系统观点，重点关注在 Power System 和 AIX 上运行 WebSphere Application Server 负载的环境的端到端系统部署、调优和管理方法。因而，本书为两类截然不同的技术读者架起了一座桥梁，也就是硬件和操作系统管理员与 WebSphere Application Server 应用软件工程师。我们都了解，在典型的企业环境中，这两类技术读者需要密切合作，但仍然有着不同的视角和职责。然而，对于企业来说，在度量 Power System 和 AIX 上运行的 WebSphere Application Server 投资的成败时，最终要取决于所有系统架构师能否很好地理解如何同心协力地利用每种产品的特有优势。因而，我们首先要做的是澄清各种观点。
在 Power System 上优化 WebSphere Application Server，第 1 部分: 入门以及优化策略
在 Power System 上优化 WebSphere Application Server，第 2 部分: 设置 Power System 硬件和分区（上）
在 Power System 上优化 WebSphere Application Server，第 3 部分: 设置 Power System 硬件和分区（下）
有空么可以再看看《WebSphere Application Server V6.1 Planning and Design WebSphere Handbook Series》
最近的几个项目里都用到Linux，于是不能像UNIX下有同事帮忙配置好一切那样轻松，要自力更生了。首先记录一下每次都会用到却还没深深记录在我的艾宾浩斯记忆曲线中的SSH相关知识。
SSH的全称为Secure Shell Protocol，是一种在互联网上提供安全远程登录（取代telnet)及其它安全网络服务（取代FTP）的协议，只要在客户端连接时选择SSH协议即可。对于服务器端的配置，Red Hat Enterprise Linux默认开启了SSH服务，对于配置文件的详细解释，可以参考下面两篇文章。
sshd_config配置 详解
sshd_config 中文手册
由于SSH的传输加密特性，还可以用来做安全隧道
SSH tunnel tips
IBM developworks上的这一篇 实战 SSH 端口转发 介绍的更为详细，而且有“X 协议转发实例分析”，在维护UNIX/LINUX时可以更方便。
安全隧道的实际用途之一么，当然是用来翻墙。
Firefox + Autoproxy + Tor 使用详解（转载）
MyEnTunnel+FireFox+FoxyProxy 通过SSH帐号翻墙教程
如何使用代理服务器
当然用PPTP建个VPN也是可以的
利用低端VPS开设VPN翻墙
科学松鼠会 的一篇公钥安全机制与宫爆鸡丁的故事 不错
扯远了，最后付一篇
Unix/Linux 系统自动化管理: 远程登录篇
爆竹声中一岁除，春风送暖入屠苏。
现在一年年过的是越来越快，还没做什么就又到了除夕，看看现在和一年前的自己，除了年岁增长，别的都停滞不前。
于是安慰自己，把时间放到十年的跨度，希望十年后，能面对一个更理性的社会，更自信的自己。
最后奉上《南方周末》的《十年》。
强文共赏，原文在这里 ，作者是推倒柏林墙。
男足这次3：0胜了韩国，举国上下全翻腾了，网上各种油菜花的评论妙语连珠，极尽调侃之能事。不过相比这篇文章，还是逊色不少。原来被国人臭骂了十来年的男足，才是俺们的骄傲。想想也是，国足不就是那日本热血动画片里一直失败却又不曾放弃的小强么？只是没有外挂罩着罢了。
借一句作者文中的话：每当看社会新闻气到吐血的时候，只有国家队的比赛，才能弭平我心灵的创伤。
安全是当今IT系统越来越重视的内容，特别在系统集成方面，需要我们尽可能构造一个安全可靠的环境。虽然按照传统的经验，一个系统对于不同的业务进行了网络拓扑上的划分，在关键位置部署了防火墙、入侵检测系统、审计系统等安全设备。但是“在你花费时间去加强系统中最坚固的部分的时候，你的对手则正在靠近这个系统中最薄弱的环节”，就要求我们“避免过度设计，优先改进最薄弱的环节 ”，而这点，往往用钱和设备是堆积不出来的，特别是一些安全设备对于管理人员来说比较陌生，操作上的疏忽反而会造成反作用。
本文版权所有 © 2010 Xin LI <delphij@FreeBSD.org> 保留所有权利
原文链接 《安全：该做什么和不该做什么 》
非商业转载请注明出处http://blog.delphij.net/ ， 谢绝商业转载。
安全不能建立在"别人不知道"的基础上
"别人不知道"是一种非常常见的安全假象 ，举例来说，一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等，都属于这一类。
将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像，这会直接导致与系统交互的人放松警惕；其次，这样的设计往往留有"后门"，甚至是设计者不知道的后门（因为往往他们并不对这类设计进行充分的、专业的审计），容易被攻击者利用；最后，这种做法存在第三方泄密问题，即，使用这种系统的人，需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。
延缓攻击的手段不能用来阻挡攻击
有许多延缓攻击的手段，例如改变服务的端口（比较常见的如将 ssh 改为 tcp/22 以外的端口），或禁止服务程序显示自己的版本等等，或仅仅简单地启用防火墙，这些手段起到的作用只是延缓攻击，而不应作为一种安全屏障。对于多层次式的安全设计来说，采取这些措施有助于提高检测到入侵的机会，但是它们本身并不会提高安全性。
与前一种情况类似，这种做法也只是让管理员放松警惕。例如以 ssh 为例，有人认为将端口改为一个非知名端口可以避免相关的攻击，但事实是，攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中，包括简单的 port knocking 一类的保护手法，都可以使用类似分组重放这样的方法来逐步攻破。
阅读全文…
最及时的声音