你好，我是DS Hunter。从这一讲开始，我会给你讲一讲不同研发职能做反爬的方向和技巧。
一般来说，公司会将Web站点分为前端、后端两部分，也就是前后端分离。必要的时候，可能还会做BFF。后端做反爬，是一件自然而然的事情，很多公司的反爬虫都是后端开始做的。当后端力不从心之后，才开始给前端做。前端力不从心了呢？就开始由BFF做了。
所以在课程中，我们也同样按照这个逻辑，先从后端开始说起。我会给你介绍下后端进行规则过滤的基本方法，并带你进入正式的key生成与验证斗争中，希望你能在这个过程中，真正理解后端反爬虫的作用以及成本分析逻辑。另外在这节课的最后，我还针对爬虫的计算力进攻进行了拓展，如果你有精力，也可以随着文字一起思考。
现在，我们就从后端出手的原因开始说起吧。
我在上面提到了，后端做反爬是一件自然而然的事情。所谓的“自然”，其实是由于服务器（也就是后端）顶不住爬虫的压力才做的。后来慢慢有经验了，才开始做一些类似“提供假信息”、“没有反爬措施的反爬虫系统”这种奇奇怪怪的封杀操作。这个时候，后端出手的原因也慢慢不再仅限于减轻服务器压力，而是开始加入商业上的博弈了。
首先你要知道，线上爬虫其实很多，不仅仅有竞对，还有一些练手的爬虫。这些爬虫特别可怕，它们往往极不专业，很容易把服务器打挂。这些爬虫，你可以尽情封杀。
而另一些竞对爬虫则完全不同，如果真的封杀了，即使胜利了，也会导致更多的问题。说是“皮洛士式的胜利”也不为过。因此两者要使用不同的策略“区别对待”，分开处理。这一讲，我们就主要针对竞对爬虫的骚扰给出具体的解决方案。
这里我为你提供了四种具体做法，分别是特征检测模块、key生成模块、验证模块和随机模块。它们像处于一个有输出又有辅助的团队一样，相互独立，又彼此协作，共同成为了反爬虫路上的有力助手。在实际应用中，我更推荐你综合使用。
在05讲中，我提到了多种的特征检测，帮助你定位具体检测的内容。精准定位，才会事半功倍。这一讲，我们就来看看一些在后端进行的特征检测（例如HTTP级别检测中的HTTP Header），它们的具体实现方式是什么样的。这里的具体实现方式分为三种：在线检测，离线检测，混合检测。我们一个一个来看。
在线检测，顾名思义，用户请求进来的时候，直接就检测特征，当场判定结果。就像现在的健康码一样，当场出码，当场判定，过期不看。
这里在线检测的做法，其实就是写个算法，针对近期的流量做样本，合并做一个集合。在集合中取特征平均值，最后拿当前流量做比较就可以了。如果后续单个流量过来后，特征不符合统计分布，那么这个流量就是有问题的。
不过这里会存在两个问题：样本本身会是爬虫吗？取平均值的复杂度会不会过高？
针对第一个问题，我们之前提到过，样本要从爬虫少的地方提取，例如订单页，进来就付钱。取付钱接口的流量，相对就纯净很多。如果对方想攻击这个样本，那代价可是太高了。
针对第二个问题，取平均值本身是一个O(n)复杂度的事情。因此，当流量高的时候，自然会变慢。不过，变慢的前提是，你使用的“近期的流量”，是最近一段时间的流量，例如最近一分钟。
如果反过来，你的流量池是一个先入先出的队列，那么其实复杂度就没那么麻烦了，因为流量数将是一个定值。而线上系统变慢的情况还是不可避免的。但是，系统性能问题对于很多职能部门来说是不可容忍的：要知道，其他团队费尽心思才节约出一点时间，被你一下子全耗光了，别人一定会和你有争议的。
针对性能问题，我们会有离线检测来解决。
离线检测，顾名思义，就是把流量放到线下，抽时间慢慢算，算好了给线上用就可以了。通常，我们对流量规则的实时性要求并没有特别高的时候，就会采取这种方法。
这里我们提到了一个新的词，规则。这个词我们后续也会经常使用，也会和其它的词进行搭配，比如规则引擎。什么是规则？这里我们试着下个定义。
规则（rule）：
使用任何技术手段，对线上请求特征按照指定的条件（condition）或方法（callback）进行检测验证，并执行指定操作的过程。在部分系统里，这个也被称为过滤器（filter）。
回到离线检测的部分。其实，离线检测和在线检测的方法是一样的，但是操作上会有些区别。操作时，你可以把固定时间间隔（例如一分钟）的流量放到一个池里面，然后定期跑计算规则，例如上面提到的平均值，或者IP频次，都可以。接着再把规则推到规则引擎去，线上系统直接使用规则引擎产生的规则即可。
这里你应该可以看到，效率大大提升了，但是实时性会大幅下降。
回到我们这门课常用的一句话：小孩子才做选择，大人全都要。是的，我们还可以做混合检测。
混合检测其实是针对不同的规则，使用不同的检测模式，并统一部署。
有的规则对实时性要求很高。例如，IP频次，阈值到达100，你就封杀。结果因为使用了离线规则，一分钟后才起作用，那一分钟内人家直接干上个一万次请求，这时候你封杀人家，人家直接走就可以了呀，一万次够用了呀。
有的规则对实时性要求不高，但是计算量非常大，那么就妥妥地走离线检测。例如HTTP Header，同一个爬虫上一分钟犯的错误下一分钟还会犯。这样的情况下，抓慢点也没关系，亡羊补牢嘛。而只要抓到了，对方又没办法立刻变更策略，他要改代码，反应更慢。因此可以走离线。
此外，离线策略不一定非得是一分钟，也可能是跑个一天，这种大规模策略甚至可以放在业务低谷期来操作，我们可以做一个在线离线混合部署，最大规模降低成本。
也就是说，白天，业务高峰，跑在线策略。晚上，业务低谷，跑离线Job，机器闲着也是闲着，低谷期利用起来反而提高了利用率，跑完第二天还是可以接着用。成本越低，从另一个角度来看也就是收益越大，后续和财务谈ROI也更有底气。
从这里开始，我们讨论的就是key的相关检测了。key生成可以认为是反爬虫的基本操作了，市面上几乎所有的反爬虫系统都逃不开这一套：下发加密key，客户端执行解密，然后上传解密后的key，服务端验证是否合法。虽然做法千差万别，但是原理都没什么创新。
这个做法和我们日常生活里面验证身份的流程非常相似，这相当于给每个人发一个员工卡，上班时要用员工卡验证身份。而我们主要的工作，就是验证员工刷的是不是发的那张卡。
你可能会疑惑，为什么验证模块不和key生成模块放在一起呢？其实，出于服务器压力的分配问题，生成key和验证key不一定在同一个集群实现。这样可以实现解耦，避免强依赖的产生，导致出问题的时候无法关闭系统，不得已进行熔断操作。因此，我们很可能需要一个独立的验证模块来进行key的验证操作。
那在key生成的这个版块，我们只讨论一个问题：如何生成一个key？
首先，生成一个随机数就可以了吗？如果生成随机数，那么必然要面对存储问题。不然在验证key的时候，你如何判断这个是自己生成的那个，而不是客户端乱编了一个呢？
因此，我们需要使用的，是一个伪随机的逻辑。也就是说，要有随机性，但是也要有规律。随机性是对爬虫来说的，有规律是对验证来说的。基于这样的操作方向，我们需要进行的就是 SKU与时间混合的操作了。
SKU（Stock Keeping Unit，最小存货单位），也就是我们常说的商品ID。我们前面论证过，反爬虫方会在指定时间内进行价格的变化，那么如何在不断变化的价格中添加一个伪随机的key生成逻辑呢？我一步步来说。
首先，一个比较简单的key生成办法是：
md5(sku+current_hour)
这样，我们就实现了当前商品当前小时内key不变，那么验证模块也就可以做到针对指定的key。
你可能会觉得，一个商品key一直一样，是很容易被抓的。但实际上，这不一定会被抓，因为前端解密key会很复杂。其次，指定商品一小时又不变价，他没有重复抓的必要。
这里可能会出现的漏洞，反而是很容易被抓“规律”。对方多试几次，很可能猜出你的后端加密规则！怎么办呢？我们都知道，MD5是公开算法，那么其实防止被抓规律的做法就很简单了：加盐。
具体加什么呢？一个比较阴险的做法，是加检测规则。例如，加http头。这样，每个人就会变得不一样。这个时候我们的伪代码就变成了：
// fingerprint：通过用户特征，计算出一个无重复的指纹。
// 用于给md5函数加盐
md5(sku+current_hour+fingerprint(http-header))
这样，每个用户的header不一样，那么每个人的key就不同。
你可能会问：但是，爬虫一般懒得改header，他实际上很可能还是每次拿到一样的key啊？
没问题，这个时候，我们上面提到的真随机就可以派上用场了。真随机虽然不好检测，但是他可以用来加盐。具体做法大概是：
var left = md5(sku+current_hour+fingerprint(http-header))// 32位
var right = md5(random())// 取一个随机值，并md5掉，用于混淆key
var result = xor(left, right)+right// 两个key异或作为新key的left，right不变。
这里的XOR是一个全字段异或的循环。为什么要这样操作呢？因为32位的key就这样变成了64位，并且规律性极差。你验证key的时候呢，取前32位和后32位，再异或回来，就能拿到原来的left和right了。right是随机值，丢弃掉。left是key，验证即可。这样就实现了，对爬虫随机，对自己有规律。
验证模块是反爬虫的核心，下发的key，就是为了传回来做验证。在验证模块，我们的核心就是：如何快速准确地验证key？
key验证其实就是key再次生成的过程。我们知道，下发key和验证key发生在同一session内，那么它们的上下文就是一致的，我们可以直接再生成一次key，与请求带来的key比对即可。
这时候你就会发现了，这种伪随机key的最大好处就是：无需存储，所以没有存储压力！因此效率极高！到这里，我们就解决了“快速又准确地验证”这个难题。
这里，我可以给你拓展一下。其实，有些拦截操作还可以放在生成key那里，而不是验证key这里。具体怎么做呢？举个封杀某个header的例子吧。如果某个HTTP Header有问题，那么你在生成key的时候，可以有意修改掉一位。也就是说，你可以假装不知道这个请求是来自爬虫的，然后直接生成一个错误的key给客户端。那么，回头这里在不受任何影响直接生成key的时候，之前生成的那个key是一定验证不过的。这样，对方还以为自己的key破解有问题。
那么，拦截操作放在生成key那里，和放在验证key这里，有什么区别吗？
区别很明显，生成key和验证key因为算法一致，所以可以放在两个集群。而放在生成key那里，是可以缓解验证key集群的压力的。要知道，虽然你生成key，也验证key，但是实际上很多低级爬虫是不带key直接打验证服务器的。因此，验证模块的压力天生比生成的地方大一些，所以，我们要减少操作，避免崩溃。而生成key的崩溃了，我们可以简单地关闭验证模块来实现熔断。而验证模块崩了……你确定你一定关得掉验证模块吗？它可崩了啊！
随机模块，也就是随机筛选。它是验证模块的一部分，不过，“做随机筛选”这件事是一个可选项。所以这里给你单独讲解。
在随机模块，可能会出现两种做法。首先，随机跳过，其实就是在校验的时候，我们可能随机跳过一部分请求，不校验。第二种做法，随机封杀，也就是说我们也可能随机封杀一部分请求。至于冤枉真用户？冤枉就冤枉了。两种做法看起来都有些不可思议，但是它们还是有着实际意义的。我们一个个来看。
首先，随机跳过。随机跳过本身并不能拦截爬虫，但是它有一个战略意义，就是让爬虫方困惑，增加破解成本。
对于爬虫方来说，反爬虫方给出100%的假数据，和给出20%的假数据，其实是没什么区别的。哪怕只有5%的假数据，这一整批数据他都不敢用的，毕竟不知道哪些是假的。
这里我给你拓展一个情境，那就是降低假数据概率，会导致一个情况：爬虫方有可能在拿到真数据的那一瞬间，就觉得自己胜利了，然后代码直接上生产。这样生产上实际拿到的数据还是不准的。
这时候你会疑惑一件事情：那，我要是给太少假数据了，岂不是没什么意义？那我给多少假数据合适呢？
我个人的习惯是真数据占比数字通常设置为79.4%，其余的就是假数据了。
这么奇怪的数字是怎么定下来的？
通常来说，爬虫方会对自己的代码再三确认，也就是说，比较谨慎的爬虫工程师，试个三次发现没问题，也就被deadline给逼上线了，不会无休止地测下去的。而79.4%这个数字好就好在，连续三次真数据的概率，如果刚好是0.5，那就是79.4%的三次方，那么对方其实测试三次，有一半的概率是拿到真数据，就会容易误以为自己胜利了。而假数据的概率超过20%，也不低了。
所以这个数字非常合适。当然，这是在大规模勾心斗角的爬虫中使用的数据，实际上检测到是小爬虫的话，你可以不考虑随机跳过的事情，100%封杀也没问题。
随机封杀，依然是一个大型爬虫专用的技术，它的关键词只有一个，就是“低”，也就是随机封杀的概率设置会尽可能低一些。为什么呢？
首先，用户是会被误伤的。其次，你可能会说，整体概率设置低了之后，爬虫方被随机被检测到的概率也很低。
但是你要赌的是什么呢？是对方不小心抽检到了这个数据，并开始质疑爬取的数据有问题。而厉害的对手很可能实际爬的没啥问题，他又找不出证据来说明为什么这个数据不对，这很容易引发对方的产品经理和研发之间的争执，最终摩擦起火都有可能。
当然了，如果摩擦起火之类的事情没有发生，那……好像你也没损失什么对不对？所以，概率设置得低，也是可以的。
完成了一系列的反爬虫措施之后，当然要复盘一下效果了。而反爬虫效果检测，一直以来都是个难题。因为你不可能直接去问爬虫：嘿兄弟，你抓到了多少假数据？就算你去问了，爬虫也得问：嘿，兄弟，真数据给我，我验证一下？
所以，我们只能通过一些办法，侧面估算出误伤率以及爬虫占比。
从技术角度来说，通常有两种方式，打点法和转化率不变法。前者用来检测误伤率，后者用来检测爬虫量。
所谓打点法，就是在有前后顺序的请求上，一个做反爬，一个不做反爬。举个例子，商品价格页面做反爬，商品付款页面不做反爬，毕竟你也不怕爬虫来给你付款。
这样，在价格页面检测到爬虫后，就写入一个Cookie，相当于给所有爬虫打一个标签。理论上说，普通用户是不可能有这个Cookie的。那么，我们在付款页面检测这个Cookie，能拿到它吗？显然是不应该拿到的，因为用户是无Cookie的。那么这里检测到多少Cookie，就证明有多少用户被误伤了。
而转化率不变法，则是另一个操作，我们首先定义一下转化率：订单量除以UV，就是UV的转化率。当然订单量可以先做用户去重，这个就看业务的要求了。这里我先假设，转化率只与网站的质量有关，与其他因素无关，或者至少关系很小。大多数情况下，商品在全天24小时内，转化率不变。
在这个假设下，就可以拉一个流量曲线，再拉一个订单曲线，加权一下试着让两者重合。但是这两者由于爬虫的存在一定是很难重合上的。你可以先想一下，你们的低谷期，也就是订单为0的时间，这个时候不管转化率是多少，UV都应该接近0对吧？那么，我们就可以判定，这部分的流量就是全爬虫。
但是扣除掉等量的流量后，订单曲线和流量曲线如果还是很难重合，那么这个不重合的原因，就是不稳定爬虫导致的。这个时候，你就可以一点一点扣流量了：慢慢估算出真实的转化率，进而估算出每个时间段的爬虫。当然，这种做法永远是估算，你不要指望精确计算出爬虫量。
根据上面的打点法和转化率不变法的做法指导，我们可以做离线检测和在线检测了。
实时在线检测主要用于监控、熔断。而打点法是用于进行误伤检测的，也就是说，它能迅速地识别到用户被误伤、可以做自动熔断反爬虫的功能。因此，这里更推荐用打点法。
需要注意的是，由于是实时检测，对读取的实时性要求很高，就不能走离线库了，需要用在线库，比如常规的MySQL。不过，那服务器顶得住吗？
顶得住的。你可以回忆下打点法，实际上拦截打点，是在订单处拦截的，所以数据量是订单量乘以误伤率。这样一来，实际上没有多少数据。而如果真的出现了顶不住的情况，那就证明误伤太多了，可以直接先熔断掉反爬虫再说。
如果说做爬虫最重要的是低调，那做反爬最重要的就是：安全。不惜一切保证安全。
说得更直白一点就是：怂。
其实，打点法和转化率不变法都是可以做离线检测的。但是这里主要推荐转化率不变法。
转化率不变，本质上是一个计算，这个计算需要全天的数据，因此全天数据都拿到之后再跑是没问题的。因此，计算不需要实时，也无需关注查询性能，最终走一次Hive查询即可。每天一次，按公司最低配置要求就行。此外，即使存储丢失了也不是什么大事，一切给成本让路。
至于计算时间，和上面特征检测部分的离线检测一样，是可以放在晚上的。同时，整个的效果检测也是可以使用在线离线混部的方式的。也就是说，你可以把统计功能和线上机器部署到一起，晚上用线上机器的剩余计算力进行离线检测。
最后，我来给你做个总结。这节课，我们针对后端的反爬虫动作进行了详细的探讨。首先，后端因为天生忍受爬虫压力，主动进行了反爬虫的研发任务。那么针对爬虫进攻的目的与做法的不同，我们的应对策略也是不同的。
在中间的部分，我们一共提到了四种后端反爬虫的具体做法，它们彼此独立，但又相互配合。除了常规的特征检测我们一定要在后端做掉以外，还可以通过后端生成key并验证key来实现请求的身份校验。当然，一些勾心斗角的价格操作（即02讲中那些奇奇怪怪的价格迷惑方式）也可以在这里处理掉。而第四种反爬虫做法，“随机模块”，也是你的一个反爬备选项。
当然，别忘了在进行了那么多的反爬虫动作之后，后续的反爬虫效果检测也是后端义不容辞的责任之一。
这里，我也给你提供了一张这一讲的脑图来进行复习。针对四种动作的“独立又配合”的性质，我给每个动作增加了一个小的标签，希望能够帮助你理解它们之间微妙的关联。
下一讲，我们可以看下，前端这个反爬虫的主战场，是如何与爬虫正面刚的。
好了，又到了愉快的思考题时间！还是三选一的老规矩，你可以任选一个问题在留言区和我一起讨论。
期待你在评论区的分享，我会及时回复你。今天诗句的下方，也有关于计算力进攻的探讨，如果你有精力，也可以和我一起在评论区讨论。反爬无定式，我们一起探索。
爬虫方的计算力攻击是个很尴尬的事情，目前来讲，并且没有真正完美的防范措施。
我们都知道，反爬是需要消耗计算力的。虽然和爬虫相比，我们可以做到少消耗资源，但是还是不能做到不消耗资源。
举个例子，生成key的服务，虽然我们上面介绍的MD5伪随机，已经是优化过的方案了，最早是走存储key的，可以做到真随机。
但是，如果爬虫知道了这个逻辑，他拼命地访问生成key的接口生成key，访问之后也不验证，单纯地拼命去消耗。这样的进攻会导致大量的key被生成、存储，但是没有人消费，最终积压在存储系统里，压爆反爬虫系统。
也许你会继续问： 这样对爬虫又什么好处吗？
当然有，反爬虫系统挂了，结果就是会自动熔断，系统以无反爬的状态运行。就像每天调戏保安，保安累得全睡着了，小偷不就可以随便进去偷东西了吗？
所以，这也是我们采取MD5的伪随机key的主要原因。
除此之外，你可以压测一下自己的反爬系统，看一下哪里是系统瓶颈，任何一环被打挂了，爬虫都能肆意妄为，这是一个很可怕的事情。
也许你会说：我们是不是可以对这一切做一些防范？比如，拉取key的接口做些什么措施，让爬虫无法来乱搞事情？
嗯？有没有感觉这是个递归的死结？你说的是不是给反爬虫系统做一个反爬虫系统？那么这个给反爬虫系统做保护的反爬虫系统，又由谁来保护呢？
所以，我们可以做一些基本的防护，比如规则封锁。但是指望完全防护住，注定是一个不现实的想法，需要早早放弃。
评论