爬虫基础篇

1 爬虫的基本流程

爬虫的核心过程是模拟浏览器与服务器交互的过程，首先向服务器发送请求（如HTTP请求、HTTPS请求等），获取到服务器响应结果后将其转化为程序语言可提取对象，然后从对象中解析出的想要的内容以及下一步访问的网址，将内容格式化存储在本地文件或者数据库中，继续向下一个网址发送请求重复上述操作，直至无下一网址可访问或满足既定的条件后爬取完毕。

2 一个完整的HTTP请求过程

输入网址->浏览器会自动解析出网址中的域名->解析出域名对应的IP（DNS寻址）->根据IP和端口浏览器会与服务器建立TCP连接->浏览器向服务器发起HTTP请求->服务器向浏览器响应HTML代码->浏览器解析出HTML并请求HTML中的资源（如JS、CSS、图片等）->浏览器对页面进行渲染呈现给访问者

2.1 DNS寻址

浏览器解析出网址的域名时，首先会查询自身的DNS缓存中是否有该域名对应的IP，如果没有就会继续查询浏览器所在操作系统的DNS缓存中是否存在该域名对应的IP，如果没有就会查询操作系统hosts文件中是否有该域名对应的IP，如果仍然没有则会进行DNS递归查询或者DNS迭代查询。

2.1.1 DNS递归查询

DNS递归查询模式下DNS客户端向本地名称服务器（即客户机配置的首选DNS服务器如Google运营商的114.114.114.114）发送域名解析请求后（如发送www.baidu.com的域名解析请求）会一直处于等待状态：

1. 本地名称服务器收到解析请求后，会根据其本地配置的根域服务器IP地址向根名称服务器发送www.baidu.com域名解析请求，根名称服务器接收到请求后，会告诉本地名称服务器com名称服务器的IP地址；
2. 本地域名服务器收到com名称服务器的IP地址后，又向com名称服务器发送www.baidu.com域名解析请求，com名称服务器接收到请求后，会告诉本地名称服务器baidu.com名称服务器的IP地址；
3. 本地域名服务器收到baidu.com名称服务器的IP地址后，又向baidu.com名称服务器发送www.baidu.com域名解析请求，baidu.com名称服务器接收到请求后，会告诉本地名称服务器www.baidu.com名称服务器的IP地址；
4. 本地域名服务器收到www.baidu.com名称服务器的IP地址后，又向www.baidu.com名称服务器发送www.baidu.com域名解析请求，www.baidu.com名称服务器接收到请求后，会告诉本地名称服务器www.baidu.com域名映射的IP地址。

2.1.2 DNS迭代查询

DNS迭代查询模式下DNS客户端向本地名称服务器（即客户机配置的首选DNS服务器如Google运营商的114.114.114.114）发送域名解析请求后（如发送www.baidu.com的域名解析请求）会收到本地名称服务器返回的根名称服务器的IP地址：

1. DNS客户端收到本地名称服务器返回的IP地址后，会向根名称服务器发送www.baidu.com域名解析请求，根名称服务器接收到请求后，会告诉DNS客户端com名称服务器的IP地址；
2. DNS客户端收到com名称服务器的IP地址后，又向com名称服务器发送www.baidu.com域名解析请求，com名称服务器接收到请求后，会告诉DNS客户端baidu.com名称服务器的IP地址；
3. DNS客户端收到baidu.com名称服务器的IP地址后，又向baidu.com名称服务器发送www.baidu.com域名解析请求，baidu.com名称服务器接收到请求后，会告诉DNS客户端www.baidu.com名称服务器的IP地址；
4. DNS客户端收到www.baidu.com名称服务器的IP地址后，又向www.baidu.com名称服务器发送www.baidu.com域名解析请求，www.baidu.com名称服务器接收到请求后，会告诉DNS客户端www.baidu.com域名映射的IP地址。

2.2 建立TCP连接

2.2.1 TCP报文格式简介

其中比较重要的字段有：

（1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：

• URG：紧急指针（urgent pointer）有效。
• ACK：确认序号有效。
• PSH：接收方应该尽快将这个报文交给应用层。
• RST：重置连接。
• SYN：发起一个新连接。
• FIN：释放一个连接。

需要注意的是：

• 不要将确认序号Ack与标志位中的ACK搞混了。
• 确认方Ack=发起方Seq+1，两端配对。

2.2.2 TCP连接之三次握手

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）【告诉服务器端，客户端想要与你建立连接】客户端向服务器端发送一段TCP报文（SYN=1，seq=x），客户端进入SYN-SENT阶段；

（2）【告诉客户端，服务器端已经知道你想建立连接】服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段，并返回一段TCP报文（SYN=1，ACK=1，seq=y，ack=x+1）；

（3）【告诉服务器端，客户端已经知道你同意建立连接】客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段，并返回最后一段TCP报文（ACK=1，seq=x+1，ack=y+1），随后客户端进入ESTABLISHED阶段；服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

2.2.3 TCP连接之四次挥手

（1）【让服务器端知道了客户端想要释放连接】客户端想要释放连接，向服务器端发送一段TCP报文（FIN=1，seq=u），客户端进入FIN-WAIT-1阶段（半关闭阶段），并且停止在客户端到服务器端方向上发送数据（不是一切数据，仍可发报文），但是客户端仍然能接收从服务器端传输过来的数据。

（2）【让客户端知道了服务器端了解了自己想要释放连接的请求】服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态），并返回一段TCP报文（ACK=1，seq=v，ack=u+1），随后服务器端开始准备释放服务器端到客户端方向上的连接。

（3）【让客户端知道了服务器端准备好释放连接了】服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文（FIN=1，ACK=1，seq=w，ack=u+1），随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）【让服务器端知道了客户端了解了自己准备好释放连接了】客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文（ACK=1，seq=u+1，ack=w+1），服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段，由此正式确认关闭服务器端到客户端方向上的连接，客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

Q1:为什么握手是三次，挥手确是四次？

TCP建立连接时之所以需要“三次握手”，是因为第二次握手时SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"挥手"传输的。

Q2:为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

Q3:为什么客户端在TIME-WAIT阶段要等2MSL?

为的是确认服务器端是否收到客户端发出的ACK确认报文，当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器（MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期）。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

如果服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文，客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因。

3 发起HTTP请求

3.1 HTTP协议

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。它定义了Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。它的请求是建立在一些底层协议的基础上完成的，先后经过IP协议、TCP协议以及HTTP协议。

HTTP协议特性
HTTP协议采用了请求/响应模型，客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据，服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP是一种无状态(stateless)协议，HTTP协议自身不对请求和响应之间的通信状态进行保存。