一篇了解爬虫技术方方面面

开发 前端
传统爬虫从一个或若干初始网页的URL开始,获得初始网页上的URL,在抓取网页的过程中,不断从当前页面上抽取新的URL放入队列,直到满足系统的一定停止条件。聚焦爬虫的工作流程较为复杂,需要根据一定的网页分析算法过滤与主题无关的链接,保留有用的链接并将其放入等待抓取的URL队列。

 

[[210603]]

原理

传统爬虫从一个或若干初始网页的URL开始,获得初始网页上的URL,在抓取网页的过程中,不断从当前页面上抽取新的URL放入队列,直到满足系统的一定停止条件。聚焦爬虫的工作流程较为复杂,需要根据一定的网页分析算法过滤与主题无关的链接,保留有用的链接并将其放入等待抓取的URL队列。

然后,它将根据一定的搜索策略从队列中选择下一步要抓取的网页URL,并重复上述过程,直到达到系统的某一条件时停止。另外,所有被爬虫抓取的网页将会被系统存贮,进行一定的分析、过滤,并建立索引,以便之后的查询和检索;

所以一个完整的爬虫一般会包含如下三个模块:

  • 网络请求模块
  • 爬取流程控制模块
  • 内容分析提取模块

网络请求

我们常说爬虫其实就是一堆的http(s)请求,找到待爬取的链接,然后发送一个请求包,得到一个返回包,当然,也有HTTP长连接(keep-alive)或h5中基于stream的websocket协议,这里暂不考虑;

所以核心的几个要素就是:

  1. url
  2. 请求header、body
  3. 响应herder、内容

URL

爬虫开始运行时需要一个初始url,然后会根据爬取到的html文章,解析里面的链接,然后继续爬取,这就像一棵多叉树,从根节点开始,每走一步,就会产生新的节点。为了使爬虫能够结束,一般都会指定一个爬取深度(Depth)。

Http请求

http请求信息由请求方法(method)、请求头(headers)、请求正文(body)三部分组成。由于method一般是header中的第一行,也可以说请求头中包含请求方法,下面是chrome访问请求头的一部分:

对于爬虫需要注意的是请求方法是post时,需要将请求的参数先进行urlencode后再发送,后台收到请求信息后可能会做一些校验,这可能会影响到爬取,相关的header字段如下:

  • Basic Auth

这是一种古老的、不安全的用户验证方式,一般会有用户授权的限制,会在headers的Autheration字段里要求加入用户名密码(明文),如果验证失败则请求就会失败,现在这种认证方式正在被淘汰。

  • Referer

链接的来源,通常在访问链接时,都要带上Referer字段,服务器会进行来源验证,后台通常会用此字段作为防盗链的依据。

  • User-Agent

后台通常会通过此字段判断用户设备类型、系统以及浏览器的型号版本。有些编程语言包里网络请求会自定义User-Agent,可以被辨别出来,爬虫中可以设置为浏览器的ua.

  • Cookie

一般在用户登录或者某些操作后,服务端会在返回包中包含Cookie信息要求浏览器设置Cookie,没有Cookie会很容易被辨别出来是伪造请求;

也有本地通过JS,根据服务端返回的某个信息进行处理生成的加密信息,设置在Cookie里面;

  • JavaScript加密操作

在进行敏感数据传输时,一般都会通过javascript进行加密,例如qq空间就会对用户登陆密码进行RSA加密后再发送给服务器,因此,爬虫在模拟登陆时需要自己去请求公钥,然后加密。

  • 自定义字段

因为http的headers可以自定义地段,所以第三方可能会加入了一些自定义的字段名称或者字段值,这也是需要注意的。

流程控制

所谓爬取流程,就是按照什么样的规则顺序去爬。在爬取任务不大的情况下,爬取的流程控制不会太麻烦,很多爬取框架都已经帮你做了如scrapy,只需要自己实现解析的代码。

但在爬取一些大型网站时,例如全网抓取京东的评论,微博所有人的信息,关注关系等等,这种上十亿到百亿次设置千亿次的请求必须考虑效率,否则一天只有86400秒,那么一秒钟要抓100次,一天也才8640w次请求,也需要100多天才能到达十亿级别的请求量。

涉及到大规模的抓取,一定要有良好的爬虫设计,一般很多开源的爬虫框架也都是有限制的,因为中间涉及到很多其他的问题,例如数据结构,重复抓取过滤的问题,当然最重要的是要把带宽利用满。

所以分布式抓取很重要,这时流程控制就会很重要,分布式最重要的就是多台机器不同线程的调度和配合,通常会共享一个url队列,然后各个线程通过消息通信,如果想要抓的越多越快,那么对中间的消息系统的吞吐量要求也越高。

现在也有一些开源的分布式爬取框架如scrapy-redis就是一个重写了scrapy的调度模块、队列、管道的包,redis数据库是用来在分布式中做请求队列共享,scrapyd是用来部署scrapy的,scrapyd-api用来启动获取数据。

内容分析提取

请求headers的Accept-Encoding字段表示浏览器告诉服务器自己支持的压缩算法(目前最多的是gzip),如果服务器开启了压缩,返回时会对响应体进行压缩,爬虫需要自己解压;

过去我们常需要获取的内容主要来源于网页html文档本身,也就是说,我们决定进行抓取的时候,都是html中包含的内容,但是随着这几年web技术飞速的发展,动态网页越来越多,尤其是移动端,大量的SPA应用,这些网站中大量的使用了ajax技术。

我们在浏览器中看到的网页已不全是html文档说包含的,很多都是通过javascript动态生成的,一般来说,我们最终眼里看到的网页包括以下三种:

  • Html文档本身包含内容

这种情况是最容易解决的,一般来讲基本上是静态网页已经写死的内容,或者动态网页,采用模板渲染,浏览器获取到HTML的时候已经是包含所有的关键信息,所以直接在网页上看到的内容都可以通过特定的HTML标签得到。

这种情况解析也是很简单的,一般的方法有一下几种:

  1. CSS选择器
  2. XPATH(这个值得学习一下)
  3. 正则表达式或普通字符串查找
  4. JavaScript代码加载内容

一般来说有两种情况:一种情况是在请求到html文档时,网页的数据在js代码中,而并非在html标签中,之所以我们看到的网页是正常的,那是因为,其实是由于执行js代码动态添加到标签里面的。

所以这个时候内容在js代码里面的,而js的执行是在浏览器端的操作,所以用程序去请求网页地址的时候,得到的response是网页代码和js的代码,所以自己在浏览器端能看到内容,解析时由于js未执行,肯定找到指定HTML标签下内容肯定为空,如百度的主页就是这种,这个时候的处理办法,一般来讲主要是要找到包含内容的js代码串,然后通过正则表达式获得相应的内容,而不是解析HTML标签。

另一种情况是在和用户交互时,JavaScript可能会动态生成一些dom,如点击某个按钮弹了一个对话框等;对于这种情况,一般这些内容都是一些用户提示相关的内容,没什么价值,如果确实需要,可以分析一下js执行逻辑,但这样的情况很少。

  • Ajax/Fetch异步请求

这种情况是现在很常见的,尤其是在内容以分页形式显示在网页上,并且页面无刷新,或者是对网页进行某个交互操作后,得到内容。对于这种页面,分析的时候我们要跟踪所有的请求,观察数据到底是在哪一步加载进来的。然后当我们找到核心的异步请求的时候,就只需抓取这个异步请求就可以了,如果原始网页没有任何有用信息,也没必要去抓取原始网页了。

爬虫技术的现状

语言

理论上来说,任何支持网络通信的语言都是可以写爬虫的,爬虫本身虽然语言关系不大,但是,总有相对顺手、简单的。目前来说,大多数爬虫是用后台脚本类语言写的,其中python无疑是用的最多最广的,并且页诞生了很多优秀的库和框架,如scrapy、BeautifulSoup 、pyquery、Mechanize等。

但是一般来说,搜索引擎的爬虫对爬虫的效率要求更高,会选用c++、java、go(适合高并发),我在大学时代就用c++实现了一个多线程的框架,但是发现和python实现的爬虫效率提升并不明显,原因是,对于简单爬虫,瓶颈在于数据分析及提取,而网络效率和语言关系并不大。

值得一提的是,在近几年node发展非常快, 使得javascript遍地开花,有些人也开始尝试用node做爬虫,但是,这其实和其它后台脚本语言没什么区别,也不如 python简单, 因为你依旧不能在node 里发起ajax请求,不能执行原网页的dom。

因为node的javascript 执行环境和浏览器的执行环境并不相同。那么,难道就真的不能像在浏览器中一样用js写爬虫,用jquery提取内容吗?

运行环境

爬虫本身不区分到底是运行在windows还是Linux,又或是OSX,但从业务角度讲,我们把运行在服务端(后台)的,称之为后台爬虫。而现在,几乎所有的爬虫都是后台爬虫。

后台爬虫的三大问题

后台爬虫在大行其道的时候,也有着些许棘手的、到目前也没有什么好的解决方案问题,而归根结底,这些问题的根本原因是由于后台爬虫的先天不足导致,在正式讨论之前,我们先思考一个问题,“爬虫和浏览器有什么异同?”。

相同点

本质上都是通过http/https协议请求互联网数据

不同点

  1. 爬虫一般为自动化程序,无需用用户交互,而浏览器不是
  2. 运行场景不同;浏览器运行在客户端,而爬虫一般都跑在服务端
  3. 能力不同;浏览器包含渲染引擎、javascript虚拟机,而爬虫一般都不具备这两者。

了解了这些,我们再来看看后台面临的问题

问题一:交互问题

有些网页往往需要和用户进行一些交互,进而才能走到下一步,比如输入一个验证码,拖动一个滑块,选几个汉字。网站之所以这么做,很多时候都是为了验证访问者到底是人还是机器。

而爬虫程序遇到这种情况很难处理,传统的简单图片验证码可以通过图形处理算法读出内容,但是随着各种各样,花样百出,人神共愤的、变态的验证码越来越多(尤其是买火车票时,分分钟都想爆粗口),这个问题就越来越严重。

问题二:Javascript 解析问题

如前文所述,javascript可以动态生成dom。目前大多数网页属于动态网页(内容由javascript动态填充),尤其是在移动端,SPA/PWA应用越来越流行,网页中大多数有用的数据都是通过ajax/fetch动态获取后然后再由js填充到网页dom树中,单纯的html静态页面中有用的数据很少。

目前主要应对的方案就是对于js ajax/fetch请求直接请求ajax/fetch的url ,但是还有一些ajax的请求参数会依赖一段javascript动态生成,比如一个请求签名,再比如用户登陆时对密码的加密等等。

如果一昧的去用后台脚本去干javascript本来做的事,这就要清楚的理解原网页代码逻辑,而这不仅非常麻烦,而且会使你的爬取代码异常庞大臃肿,但是,更致命的是,有些javascript可以做的事爬虫程序是很难甚至是不能模仿的,比如有些网站使用拖动滑块到某个位置的验证码机制,这就很难再爬虫中去模仿。

其实,总结一些,这些弊端归根结底,是因为爬虫程序并非是浏览器,没有javascript解析引擎所致。针对这个问题,目前主要的应对策略就是在爬虫中引入Javascript 引擎,如PhantomJS,但是又有着明显的弊端,如服务器同时有多个爬取任务时,资源占用太大。

还有就是,这些 无窗口的javascript引擎很多时候使用起来并不能像在浏览器环境中一样,页面内部发生跳转时,会导致流程很难控制。

问题三:IP限制

这是目前对后台爬虫中最致命的。网站的防火墙会对某个固定ip在某段时间内请求的次数做限制,如果没有超过上线则正常返回数据,超过了,则拒绝请求,如qq 邮箱。

 

值得说明的是,ip限制有时并非是专门为了针对爬虫的,而大多数时候是出于网站安全原因针对DOS攻击的防御措施。后台爬取时机器和ip有限,很容易达到上线而导致请求被拒绝。目前主要的应对方案是使用代理,这样一来ip的数量就会多一些,但代理ip依然有限,对于这个问题,根本不可能彻底解决。 

责任编辑:庞桂玉 来源: 马哥Linux运维
相关推荐

2010-05-05 19:08:37

cluster负载均衡

2015-07-01 15:10:30

2010-08-23 13:05:52

2018-05-23 14:02:27

2020-11-10 10:01:22

VimLinux命令

2023-01-17 09:37:23

读写分离数据库

2020-12-01 12:25:28

VimLinux分屏

2017-03-22 09:11:45

bugbug赏金计划众包项目

2017-10-25 20:26:19

大数据生活金融

2024-01-24 14:21:53

2022-10-26 07:39:36

MVCC数据库RR

2022-12-19 08:14:30

注解开发配置

2021-05-20 06:57:16

RabbitMQ开源消息

2018-03-12 22:13:46

GO语言编程软件

2021-07-10 09:02:42

编程语言 TypeScript

2021-07-14 10:08:30

责任链模式加工链

2021-10-28 19:15:02

IPUARM

2020-10-09 08:15:11

JsBridge

2021-06-30 00:20:12

Hangfire.NET平台

2021-07-28 10:02:54

建造者模式代码
点赞
收藏

51CTO技术栈公众号