爬虫的概念：
其实呢，爬虫更官方点的名字叫数据采集，英文一般称作spider，就是通过编程来全自动的从互联网上采集数据。
比如说搜索引擎就是一种爬虫。
爬虫需要做的就是模拟正常的网络请求，比如你在网站上点击一个网址，就是一次网络请求。
爬虫的作用：
现如今大数据时代已经到来，网络爬虫技术成为这个时代不可或缺的一部分，企业需要数据来分析用户行为，来分析自己产品的不足之处，来分析竞争对手的信息等等，但是这些的首要条件就是数据的采集。
这其中使用爬虫较为有名的有今日头条等公司。
爬虫的本质
爬虫的本质就是自动化的去模拟正常人类发起的网络请求，然后获取网络请求所返回的数据。
跟我们人手动去点击一个连接，访问一个网页获取数据，并没有什么本质的区别。
爬虫的难点
爬虫的难点主要为两个方向：
数据的获取
一般来说我们想要抓取的网站是不希望我们去抓取他的数据的，那么这些网站就会做一些反爬虫的措施，来让我们无法去他的网站上抓取数据。所以我们也要做相应的措施去绕过这些反爬虫措施。
抓取数据的速度
我们抓取的目标的数据量，有时是非常庞大的，甚至几千万上亿的数据量，而有些甚至会要求实时的更新，所以抓取的速度也非常重要。我们一般会使用并发和分布式来解决速度的问题。
网络请求
网络请求其实就是在互联网上一次数据的传递。
而为了数据能够在庞杂的网络中能够正确，迅速的传递给目标主机。我们定义了许多的网络协议，也就是网络传输数据的规则，来实现网络的连接。
而这些协议中，我们使用的最多的，基本上就是HTTP/HTTPS协议。
HTTP协议最大的缺点就是明文传输，而在网络上数据传输的路径上有很大一部分都是暴露在公有环境下的，所以数据是很容易泄露。
深入浅出了解HTTP协议
HTTP（HyperText Transfer Protocol，超文本传输协议)是互联网上应用最为广泛的一种网络协议。目前使用最普遍的一个版本是HTTP 1.1。
HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP协议简介
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。
一次HTTP请求的基本流程一般是，在建立TCP连接后，由客户端向服务端发起一次请求（request），而服务器在接收到以后返回给客户端一个响应（response）。
所以我们看到的HTTP请求内容一般就分为请求和响应两部分。
HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。
默认HTTP的端口号为80。
HTTP是一个无状态的协议。
无状态协议
HTTP协议是无状态的，也就是说每一次HTTP请求之间都是相互独立的，没有联系的，服务端不知道客户端具体的状态。
比如客户端访问一次网页之后关闭浏览器，然后再一次启动浏览器，再访问该网站，服务器是不知道客户关闭了一次浏览器的。
这样设计的原因是因为Web服务器一般需要面对很多浏览器的并发访问，为了提高Web服务器对并发访问的处理能力，在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时，不保存发出请求的Web浏览器进程的任何状态信息。
HTTP请求
每一个HTTP请求都由三部分组成，分别是：请求行、请求报头、请求正文。
请求行
请求行一般由请求方法、url路径、协议版本组成，如下所示：
请求报头
请求行下方的是则是请求报头，HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。每个报头的形式如下：
名字 + : + 空格 + 值
-
Host
指定的请求资源的域名（主机和端口号）。HTTP请求必须包含HOST，否则系统会以400状态码返回。
-
User-Agant
简称UA，内容包含发出请求的用户信息，通常UA包含浏览者的信息，主要是浏览器的名称版本和所用的操作系统。这个UA头不仅仅是使用浏览器才存在，只要使用了基于HTTP协议的客户端软件都会发送，无论是手机端还是PDA等，这个UA头是辨别客户端所用设备的重要依据。
-
Accept
告诉服务器可以接受的文件格式。通常这个值在各种浏览器中都差不多，不过WAP浏览器所能接受的格式要少一些，这也是用来区分WAP和计算机浏览器的主要依据之一，随着WAP浏览器的升级，其已经和计算机浏览器越来越接近，因此这个判断所起的作用也越来越弱。
-
Cookie
Cookie信息。
-
Cache-Control
指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、man-age、max-stake、min-fresh、only-if-cached；响应消息中的指令包括 public、privete、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。
-
Referer
页面跳转处，表明产生请求的网页来自于哪个URL，用户是从该 Referer页面访问到当前请求的页面。这个属性可以用来跟踪Web请求来自哪个页面，是从什么网站来的。
-
Content-Length
内容长度。
-
Content-Range
响应的资源范围。可以在每次请求中标记请求的资源范围，在连接断开重连时，客户端只请求该资源未下载的部分，而不是重新请求整个资源，实现断点续传。迅雷就是基于这个原，使用多线程分段读取网络上的资源，最后再合并。
-
Accept-Encodingemphasized text
指定所能接收的编码方式，通常服务器会对页面进行GZIP压缩后再输出以减少流量，一般浏览器均支持对这种压缩后的数据进行处理，但对于我们来说，如果不想接收到这些看似乱码的数据，可以指定不接收任何服务器端压缩处理，要求其原样返回。
-
Accept-Language
指浏览器可以接受的语言种类 en、en-us指英语 zh、zh-cn指中文。
-
Connection
客户端与服务器链接类型，keep-alive:保持链接，close:关闭链接。
请求正文
请求正文通常是使用POST方法进行发送的数据，GET方法是没有请求正文的。
请求正文跟上面的消息报头一般由一个空行隔开。
HTTP响应
HTTP响应同样也是由状态行、响应报头、报文主体三部分组成。
状态行
状态行由HTTP协议版本号， 状态码， 状态消息三部分组成。如下所示：
响应报头
-
Allow
服务器支持哪些请求方法（如GET、POST等）。
-
Date
表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
-
Set-Cookie
非常重要的header, 用于把cookie发送到客户端浏览器，每一个写入cookie都会生成一个Set-Cookie。
-
Expires
指明应该在什么时候认为文档已经过期，从而不再缓存它，重新从服务器获取，会更新缓存。过期之前使用本地缓存。
-
Content-Type
WEB服务器告诉客户端自己响应的对象的类型和字符集。
-
Content-Encoding
文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。
-
Content-Length
指明实体正文的长度，以字节方式存储的十进制数字来表示。
-
Location
用于重定向一个新的位置，包含新的URL地址。表示客户应当到哪里去提取文档。
-
Refresh
表示浏览器应该在多少时间之后刷新文档，以秒计。
响应正文
服务器返回的数据。
URL
URL（Uniform Resource Locator），中文叫统一资源定位符。是用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
-
协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在"HTTP"后面的“//”为分隔符。
-
域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用。
-
端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口。
-
路径部分：从域名后的第一个“/”开始到最后一个“？”为止，是路径部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是路径部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是路径部分。
本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名。
-
参数部分：从“？”开始到“#”为止之间的部分为参数部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
-
锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分。
锚部分是用来定位到页面中某个元素的。
HTTP请求方法
HTTP协议中定义的请求方法有以下几种：
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
虽然HTTP请求中定义的方法有这么多种，但是我们平常使用的基本只有GET和POST两种方法，而且大部分网站都是禁用掉了除GET和POST外其他的方法。
因为其他几种方法通过GET或者POST都能实现，而且对于网站来说更加的安全和可控。
-
GET其实简单来说，
GET方法一般用来负责获取数据，或者将一些简短的数据放到URL参数中传递到服务器。比POST更加高效和方便。 -
POST由于
GET方法最多在url中携带1024字节数据，且将数据放到URL中传递太不安全，数据量大时URL也会变得冗长。所以传递数据量大或者安全性要求高的数据的时候，最好使用POST方法来传递数据。
状态码（status code）
当客户端向服务端发起一次请求后，服务端在返回的响应头中会包含一个HTTP状态码。下面是一些常见的状态码：
-
200 - 请求成功
-
301 - 资源（网页等）被永久转移到其它URL
-
404 - 请求的资源（网页等）不存在
-
500 - 内部服务器错误
HTTP的状态码是由三位数字来表示的，由第一位数字来表示状态码的类型，一般来说有五种类型：
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
以下是详细的状态码列表：
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 充当网关或代理的服务器，从远端服务器接收到了一个无效的请求 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
Cookie
Cookie有时也用其复数形式 Cookies，英文是饼干的意思。指某些网站为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。最新的规范是 RFC6265 。
Cookie其实就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。 服务器在接收到Cookie以后，会验证Cookie的信息，以此来辨别用户的身份。
Cookie可以理解为一个临时通行证。
作用
Cookie其实是HTTP请求头的扩展部分，由于HTTP协议是无状态的协议，所以为了在网页上实现登陆之类的需求，所以扩展了Cookie这样的功能。
每一次HTTP请求在数据交换完毕之后就会关闭连接，所以下一次HTTP请求就无法让服务端得知你和上一次请求的关系。而使用了Cookie之后，你在第一次登陆之类的请求成功之后，服务器会在Response的头信息中给你返回Cookie信息，你下一次访问的时候带上这个Cookie信息，则服务器就能识别你为上一次成功登陆的用户。
内容
Cookie一般保存的格式为json格式，由一些属性组成。
-
name：
Cookie的名称 -
value：
Cookie的值 -
domain：可以使用此
Cookie的域名 -
path：可以使用此
Cookie的页面路径 -
expires/Max-Age：此
Cookie的超时时间 -
secure：设置是否只能通过https来传递此条
Cookie
domain属性
域名一般来说分为顶级域名，二级域名，三级域名等等。
例如baidu.com是一个顶级域名，而www.baidu.com和map.baidu.com就是二级域名，依次类推。
而在我们的Cookie来说，都有一个domain属性，这个属性限制了访问哪些域名时可以使用这一条Cookie。因为每个网站基本上都会分发Cookie，所以domain属性就可以让我们在访问新浪时不会带上百度分发给我们的Cookie。
而在同一系的域名中，顶级域名是无法使用其二级域名的Cookie的，也就是说访问baidu.com的时候是不会带上map.baidu.com分发的Cookie的，二级域名之间的Cookie也不可以共享。但访问二级域名时是可以使用顶级域名的Cookie的。
path属性
path属性为可以访问此cookie的页面路径。 比如domain是abc.com，path是/test，那么只有/test路径下的页面可以读取此cookie。
expires/Max-Age属性
字段为此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。
Session
Session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。这个词在各个领域都有在使用。
而我们web领域，一般使用的是其本义，一个浏览器窗口从打开到关闭这个期间。
Session的目的则是，在一个客户从打开浏览器到关闭浏览器这个期间内，发起的所有请求都可以被识别为同一个用户。而实现的方式则是，在一个客户打开浏览器开始访问网站的时候，会生成一个SessionID，这个ID每次的访问都会带上，而服务器会识别这个SessionID并且将与这个SessionID有关的数据保存在服务器上。由此来实现客户端的状态识别。
Session与Cookie相反，Session是存储在服务器上的数据，只由客户端传上来的SessionId来进行判定，所以相对于Cookie，Session的安全性更高。
一般SessionID会在浏览器被关闭时丢弃，或者服务器会验证Session的活跃程度，例如30分钟某一个SessionID都没有活跃，那么也会被识别为失效。