作者：xlzd
链接：https://zhuanlan.zhihu.com/p/20471442
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
到上一篇博客为止，我们已经可以不费吹灰之力编写代码抓取常规互联网网站的公开数据，不过，大多数情况下你可能会发现一个问题：程序刚刚开始运行不久，就再也得不到服务器的正常返回。换言之，你被封了。这篇博客我们将探讨常规的反爬虫机制。
最简单的反爬手段
有一部分网站（甚至包括部分商业网站）其实并没有真正认真做过反爬虫这件事情，你不需要做任何伪装，即可分分钟抓光它的网站。面对这样的网站，你只需要开大马力抓抓抓就好了，如果处于情怀考虑，你可以抓的慢一点，让它的服务器别太累。
除去这样的情况，最简单的反爬虫机制，应该算是U-A校验了。浏览器在发送请求的时候，会附带一部分浏览器及当前系统环境的参数给服务器，这部分数据放在HTTP请求的header部分(如下图是一个请求头示意)。
header的表现形式为key-value对，其中User-Agent标示了一个浏览器的型号，如上图即为在OS X系统中Chrome的User-Agent。作为最简单的反爬虫机制，服务器会通过判断U-A的值来区分不同浏览器（或客户端）。一般情况下，使用编程语言提供的第三方网络库来发送HTTP请求会有一个默认的U-A，比如requests库的默认U-A为"python-requests/2.8.1"(后面的版本号可能不同)。如果服务器仅仅通过判断请求的U-A来区分不同浏览器，我们则可以通过模拟U-A来达到鱼目混珠的目的。所谓模拟U-A，即是我们手动指定我们发出去的请求的User-Agent的值。
通过访问频度反爬
这种反爬虫机制的原理是，真人通过浏览器访问网站的速度（相对程序来讲）是很慢的，所以如果你一秒访问了200个页面——这里不代表实际数值，只是表达在较短时间内发送了较多请求，具体阈值需要具体考虑——服务器则认为你是一个爬虫。一个简单的示例，打开58同城，然后用你20多年单身练就的手速狂按刷新，不久之后你就可以发现58给了你一个验证码页面，你需要正确输入验证码才可以继续。面对这样的情况（没有账号登录），一般来讲我们有两种情况解决：
换IP
识别验证码
简单来讲，服务器认为我们当前的出口IP访问频率过快，那么我们换一个全新的IP不就好了吗，当新的IP再此被认为访问过快，我们就再重新换一个新的IP，如此往复。如何实现更换IP呢？其实我们不需要真正更换IP，而是通过一个代理IP转发我们的请求。不少网站提供或罗列了一大批代理IP，我们可以抓取下来之后存储起来，以备不时之需。不过，很多代理IP的寿命都比较短，所以最好有一套完整的机制来校验已有代理IP的有效性。使用requests库来更换代理IP的示例代码如下：
request=requests.Session()request.proxies={"http":"http://10.10.1.10:3128",}
除去更换代理IP，识别验证码也是一种可行的解决方案。不过，识别验证码的技术难度要比更换代理IP高个三四层楼。就像你刚才刷出58的验证码时，当你正确输入验证码之后，就可以继续正常访问了。同样地，当你的OCR程序识别出验证码中的文本之后，按照浏览器的请求方式向服务器发送识别结果之后，一般就可以继续正常访问了。
面对这样的网站，一种较好的的方式是用一台机器从慢到快测试被封的阀值，然后将程序按照比阀值低一点的速度抓取。如果量比较大，还可以通过上一篇博客所讲将爬虫并行化。
通过验证码限制
这样的方式与上面的方式相比更加难处理的是，不管你的访问频次怎么样，你都需要输入验证码才行。比如12306，不管你是登录还是购票，也不论你是第一次还是第一万次购买，你都需要输入一个验证码之后才能继续。这时候，在绝大部分情况下，你必须要想办法识别验证码了。之所以说是大多数情况下，是因为在极少数极少数情况下（尤其是政府网站），棒槌程序员通过客户端的JavaScript来校验验证码，这时候对你的爬虫来讲，其实是没有验证码的（比如中国商标网）。除开你遇到这种几乎可以忽略不计的棒槌开发的网站，其他时候你只有通过识别验证码来继续后面的操作了。
通过经常变换网页结构
常见于一些社交网站，他们会经常更换网页的结构，如果你是通过依赖网页结构来解析需要的数据（不幸的是大部分情况下我们都需要通过网页结构来解析需要的数据），则在原本的网页位置找不到原本需要的内容。这时候，要分不同情况具体处理了。如果你只打算一次性抓取特定数据，那么赶快行动，它以后结构变了无所谓，反正你也不打算在抓它一次。如果是需要持续性抓取的网站，就要仔细思考下应对方案了。一个简单粗暴但是比较费力的办法是，写一个校验脚本，定期校验网页结构，如果与预期不符，那么赶快通知自己（或者特定开发者）修改解析部分，以应对网页结构变化。
除此之外，可以考虑解析数据时通过数据的特点来解析而不是通过网页结构，这样只要网页上我们需要的数据不变，基本可以不关心网页结构如何。当然，这样的方法也有弊端，那就是可能不能覆盖百分之百的情况，在少数情况下，可能无法解析出我们需要的东西。比如我曾经写过程序根据文本密度解析新闻正文，在绝大部分情况下可以正常抽取新闻正文，不过少数情况下，会出现解析失败的情况。
通过账号限制
其实这样的情况下，账号的作用更多是网站处于功能考虑的，反爬虫只不过是顺便完成的功能。具体的处理机制，我们下一篇博客细聊关于模拟登录。
小结
这篇博客中，我们简单总结了几种简单的反爬虫机制及相应的处理措施，后面会有针对性的介绍详细的处理方案以及总结更加复杂的反爬机制。
