最近写专利时看到了一种基于浏览记录的反爬虫方法，该方法基于 "在前端页面中以埋点或者提取页面日志的方式，获取用户的前端浏览记录，计算用户行为指标并进行人机验证" 。
用户行为指标
用户行为指标的计算基于前端浏览记录中的浏览地址与浏览时间。
- 根据所述浏览时间和所述地址数量计算预设单位时长内访问次数；
- 根据所述地址数量与所述总浏览时长计算每个浏览地址的平均浏览时长；
- 利用预设的指标函数对所述地址数量、总浏览时长、平均浏览时长和预设单位时长访问次数进行计算，得到用户行为指标。
其中，f 为用户行为指标，A为所述地址数量，B为所述总浏览时长，C为所述平均浏览时长，D为所述预设单位时长访问次数，α、β、γ和θ为预设权重系数。
例如，用户小明的在6点至7点的浏览地址为的www.xiaoshuo.com，在7点至9点浏览地址为www.gouwu.com，则确定用户小明的地址数量为2，浏览总时长为3小时，用户小明对每个浏览地址的平均浏览时长为1.5小时，当预设单位时长为3小时，预设单位时长内访问次数为2。
由于非爬虫用户的作息方式较为固定，因此非爬虫用户的浏览习惯较为固定 。该方法利用计算得到的用户行为指标表示用户为非爬虫用户的概率，并将用户行为指标与预设阈值进行对比，当所述用户行为指标大于预设阈值，确定该用户为爬虫，对所述用户进行访问限制。
然后根据所述反爬虫验证参数，构建所述用户对所述目标网页的访问代价函数，并迭代所述访问代价函数，得到访问代价值。
所述访问代价是指用户通过用户IP地址对数据进行访问时，用户IP地址对应的服务器的负载消耗。
所述访问代价函数为：
例如，用户通过用户IP地址对目标网页进行访问时，该用户IP地址对应的服务器需要承担每秒8000次的数据请求产生的负载消耗，则每秒8000次的数据请求产生的负载消耗即为用户对所述目标网页进行访问的访问代价。
所述对所述访问代价函数进行迭代，是指利用所述访问代价函数计算多个预设单位时长内，用户通过用户IP地址对数据进行访问的单位访问代价，并将该多个预设单位时长内单位访问代价的均值作为所述访问代价值。
判断所述访问代价值是否小于所述反爬虫验证参数，当所述访问代价值小于所述反爬虫验证参数时，对所述用户进行访问限制。
反爬流程图
经验分析
目前基于应用层的反爬已经数见不鲜，各大厂商都将反爬核心转移到用户行为和设备指纹上。
像本文的反爬虫方法，适用于具有个人账号或者稳定cookie的访问来源。
比如在抖音和脉脉的风控上，该方法与其有着异曲同工之妙。
通过定时或者用户操作时触发行为记录的POST请求，将行为记录以日志形式发送给服务端进行校验。
如果你单纯的用请求库去访问接口，并没有做相应的POST请求，当爬虫请求达到一定阈值后会被服务端限制访问。
反反爬策略
打造一个用于服务端检测的环境，比如说启动一个服务来发送行为记录，维持和服务端的通信。或者开启一个真实的应用。
就像在抖音的wss协议中，需要维持心跳，在正常的长连接时，去构造app_log一样。
当然也不是说只要构建了环境就不会被限制，各大厂都有一套专用的爬虫识别算法，需要不断测试才能找到最好的解决方法。
比如在晚上11点后的检测比白天严格，比如每周固定时间会对一周访问记录进行大型检测，所以有时需要根据风控算法去打造一套专用的采集算法。
以上文的用户行为指标公式为例，想要爬虫增加访问频率和访问量，则需要在行为记录中去增加参数值。
因其他事 未完待续