上一篇我们介绍了爬虫中 HTTP 的基础内容, 相信看过的朋友们应该对 HTTP 已经有个初步的认识了. 本篇博主将分享一些 HTTP 的高级内容, 以及在爬虫中的应用, 让大家更深入理解. 这些内容包括:
Cookie 解读
Session 解读
HTTPs 解读
Cookie 解读
1. 什么是 Cookie?
Cookie 原意是 "小甜点" 的意思, 但是在互联网上被用作储存在用户本地终端上的数据.
百度百科是这么解释的:
Cookie, 有时也用其复数形式 Cookies, 指某些网站为了辨别用户身份, 进行 session
跟踪而储存在用户本地终端上的数据 (通常经过加密). 定义于 RFC2109 和 2965 中的都已废弃, 最新取代的规范是
RFC6265.(可以叫做浏览器缓存)
2. 为什么要使用 Cookie?
首先, 需要明确一个很重要的概念:
HTTP 是一个无状态的协议.
什么意思呢? 举一个简单的例子来理解一下.
< 应用一 >
比如, 我们网上购物的时候, 浏览了几个网页, 选了几样商品放入了购物车. 但是由于 HTTP 的无状态特点, 当我们结账的时候服务器并不知道操作的用户是谁, 即无法记录上下文的信息, 这严重的妨碍了 web 应用程序交互式的操作.
为了解决 HTTP 的无状态的问题, Cookie 就应运而生了. Cookie 绕开了 HTTP 的无状态性, 提供了一种 "额外手段" 维护了用户跟服务器会话中的状态. 说白了,
Cookie 就是一小段数据储存在本地, 记录并标识了用户身份, 以便服务器辨认.
这其实相当于让一个失忆的人从此有了记忆. 因此, 无论当我们购买几次商品, 退货, 结账等, 服务器都能通过这个标识来判断出你是谁.
还有一个常见的例子, 就是登录.
< 应用二 >
当我们登录某个网站输入用户名和密码后, 一般浏览器会提示是 "是否保存密码". 我们通常会勾选保存, 那么这样带来的好处就是在以后的一段时间我们访问该网站都会自动登录而不必每次都去敲用户名和密码了.
也正是这个原因, 简化了爬虫中模拟登录的问题, 每次登录只要 post 一个 Cookie 信息就可以了, 而避免了每次都 post 登录信息. 当然, 这只针对一部分网站而言, 一些复杂的网站会定期的变换一些算法, 使得 Cookie 频繁的失效, 这时候就需要 post 登录信息了或者模拟找到算法的规律.
关于爬虫模拟登录的详细内容后续后专门开一篇和大家分享.
3.Cookie 的分类
Cookie 有两种类型: 持久化 Cookie, 非持久化 Cookie.
持久化 Cookie: 表示 Cookie 会保存到本地磁盘上, 关闭浏览器再次打开, Cookie 依然有效直到设置的 expire 时间.
非持久化 Cookie: 表示 Cookie 会在本地内存中, 生命周期会受浏览器开关状态影响, 只要浏览器关闭, Cookie 则失效.
4.HTTP+Cookie 的交互过程
下面是 HTTP 请求中使用
Cookie 所实现的整个 web 交互过程
.
博主以一个访问豆瓣的实际例子作为上述过程的具体说明和描述.
<1> 步骤 1 的请求头
看到请求头里面没有 Cookie, 只是常规的头域字段信息.
<2> 步骤 2/3 的响应头
服务器根据
POST 请求 (用户名密码等)
生成一个 Cookie, 并通过响应头的 set-Cookie 字段返回此 Cookie 信息.
<3> 步骤 5 的请求头
再一次刷新页面的请求头中就有了获取 Cookie 信息.
<4> 步骤 7 的响应头
第二次的响应头无 set-Cookie 字段信息, 因为服务器已经辨别了这个用户刚刚提交的 Cookie 信息.
5.Cookie 的格式和属性
格式:
客户端发送 Cookie(键值对):Cookie:key1=value1; key2=value2; key3=value3
服务器响应 Cookie:Set-Cookie: name=value;expires=date;path=path;domain=domain_name;secure
属性:
name: 为一个 Cookie 的名称.
domain: 为可以访问此 Cookie 的域名, 该域名可以使多个 web 服务器共享 Cookie.
path: 表示 Cookie 所在目录,"/" 表示根目录.
expires/max-age: 为 Cookie 的生命周期. 若设置该值, 则到此时间 Cookie 会失效. 若没有设置该值, 默认与 session 一起失效. 浏览器关闭, Cookie 失效.
secure: 布尔值, 指定 Cookie 的传输方式, 默认是不安全的 HTTP 连接.
http:Cookie 的 httponly 属性, 若此属性为 true, 则只能在 http 的请求头中携带 Cookie 信息.
Session 解读
1. 什么是 Session?
百度百科是这么解释的:
Session: 在计算机中, 尤其是在网络应用中, 称为 "会话控制".Session 对象存储特定用户会话所需的属性及配置信息. 这样, 当用户在应用程序的 Web 页之间跳转时, 存储在 Session 对象中的变量将不会丢失, 而是在整个用户会话中一直存在下去. 当用户请求来自应用程序的 Web 页时, 如果该用户还没有会话, 则 Web 服务器将自动创建一个 Session 对象. 当会话过期或被放弃后, 服务器将终止该会话.
2. 为什么要使用 Session?
同样是因为
HTTP 是一个无状态协议
.Session 和 Cookie 的存在都是为了解决这个问题的.
由于服务器本身并不会维持用户的上下文, 因此为了实现会话的跟踪, 不得不想出一种办法.
Session 正是一种保存上下文的机制
, 对于每一个用户来讲, 用户所产生的变量值都保存在了服务器端, 这样就使得整个会话都衔接的上, 而每个用户有自己独一无二的 ID, 我们叫做 SessionID.
3.Session 和 Cookie 有什么联系?
这个要从 SessionID 说起. 我们上面提到服务器会每个用户创建一个 SessionID, 那么我们该如何使用它呢
SessionID 有如下几种使用方式:
<1>Cookie
这是我们最常用的方式, Cookie 相当于一个
SessionID 的高级应用
, 是 SessionID 的载体或者容器. 我们说 Cookie 可以用来识别用户身份, 也是因为 SessionID 的缘故.
因此, 可以说 Session 是服务端的解决方案, 实现了 web 的会话跟踪, 而 Cookie 是客户端的解决方案, 实现了跟踪过程的用户识别.
Session 是真正解决 HTTP 无状态的方案, 而 Cookie 只是实现了 Session 过程中的 SessionID 方式.
<2>URL 重写
Cookie 的使用给用户带来了极大的方便, 以及很好的用户体验. 但是 Cookie 存在着一些安全问题, Cookie 储存在本地会很大程度暴露用户信息. 因此, 用户可以选择禁用 Cookie.
那么另一种实现 SessionID 的方式就是 URL 重写. URL 重写就是把 SessionID 附加在 URL 里, 可以作为 URL 路径附加信息或者查询字符串附加在 URL 后面.
就是说用户所有的请求的 URL 中都要有 sesssionID 这个东西, 否则无法保持会话的持久状态.
<3> 表单隐藏字段
服务器会修改表单, 设置一个 SessionID 的隐藏字段, 用户需要将 SessionID 填写到隐藏字段中提交表单, 以让服务器知道用户身份.
隐藏字段也是爬虫中的反爬策略之一, 如果我们爬虫提交的表单没有填写隐藏字段, 那么服务器会认为这是一种爬虫行为而禁掉, 或者提交的内容不正确也可能造成同样的后果. 因此, 每次爬取前有必要查看一下是否存在隐藏字段. 当然, 关于隐藏字段还有更复杂的玩法这里就不详细介绍了.
4.Session 的关闭
< 关闭浏览器 >
有时候我们可能会误以为关闭了浏览器, Session 就消失了. 其实, Session 并没有消失, 如果消失, 消失的也是 Cookie(如果储存在内存的话).
Session 是储存在服务端的, 注意是服务端. 而服务端是不会知道浏览器什么时候关闭了的, 但是服务端又不能一直开着 Session, 那样会损耗服务器资源. 因此, 为了解决这个问题, 服务端一般会设置 Session 超时, 通过检测用户活动状态来判断是否超时. 如果超时, 那么整个会话 Session 才真正消失, 不然还是会开着直到超时.
如果 Cookie 是本地储存在磁盘上的, 在我们关闭浏览器的很短一段时间内再次打开浏览器, 还是会回到刚才那个 Session 会话. 但是如果 Cookie 储存在内存中, 再次打开时浏览器已经忘记了 Cookie, 那么就无法和刚才的会话连接上了.
结论是:
关闭浏览器并不会使服务端 Session 对象消失.
< 注销 >
注销和关闭浏览器有着本质的区别, 注销实际上会使 Session 对象消失. 就比如我们在网页上点击注销一样, 用户信息就都被清空了. 如果需要连接 Session, 需要重新创建 Session.
结论是:
注销会使服务端 Session 对象消失.
HTTPs 解读
1. 什么是 HTTPs?
依旧百度百科一下:
HTTPS(全称: Hyper Text Transfer Protocol over Secure SocketLayer), 是以安全为目标的 HTTP 通道, 简单讲是 HTTP 的安全版. 即 HTTP 下加入 SSL 层, HTTPS 的安全基础是 SSL, 因此加密的详细内容就需要 SSL.
它是一个 URIscheme(抽象标识符体系), 句法类同 http: 体系 . 用于安全的 HTTP 数据传输. https:URL 表明它使用了 HTTP , 但 HTTPS 存在不同于 HTTP 的默认端口及一个加密 / 身份验证层 (在 HTTP 与 TCP 之间). 这个系统的最初研发由网景公司 (Netscape) 进行, 并内置于其浏览器 NetscapeNavigator 中, 提供了身份验证与加密通讯方法. 现在它被广泛用于万维网上安全敏感的通讯, 例如交易支付方面.
2.HTTPs 与 HTTP 的区别
超文本传输协议 HTTP 协议被用于在 Web 浏览器和网站服务器之间传递信息. HTTP 协议以明文方式发送内容, 不提供任何方式的数据加密, 如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文, 就可以直接读懂其中的信息, 因此 HTTP 协议不适合传输一些敏感信息, 比如
信用卡号, 密码
等.
为了解决 HTTP 协议的这一缺陷, 需要使用另一种协议:
安全套接字层超文本传输协议 HTTPS.
为了数据传输的安全, HTTPS 在 HTTP 的基础上加入了 SSL 协议,
SSL 依靠证书来验证服务器的身份, 并为浏览器和服务器之间的通信加密.
HTTPS 和 HTTP 的区别主要为以下四点:
一, https 协议需要到 ca 申请证书, 一般免费证书很少, 需要交费.
二, http 是超文本传输协议, 信息是明文传输, https 则是具有安全性的
ssl 加密传输协议
.
三, http 和 https 使用的是完全不同的连接方式, 用的端口也不一样, 前者是
80
, 后者是
443
.
四, http 的连接很简单, 是无状态的; HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输, 身份认证的网络协议, 比 http 协议安全.
3.HTTPs 对爬虫的影响
乍一看感觉 HTTPs 有点像反爬的手段, 通过上面的了解, 我们发现 HTTPs 是对服务器端的验证, 通过 CA 证书保证了我们访问的网站是有身份的, 而非其他假网站. 相反, 我们爬虫模拟的是客户端, 并不受 HTTPs 的限制.
因此,
HTTPs 不影响我们爬虫.
但是, 我们在爬虫的过程仍然也会遇到过类似 SSL 不通过之类的错误. 比如, 博主以前用 requests 访问 HTTPs 的时候遇到过这样的坑, 但最后究其原因是同时打开了 fiddler 造成的.
请参考知乎: https://www.zhihu.com/questio... 有相应的解决办法.
总结
本篇向大家介绍了爬虫中 HTTP 的高级使用内容, 主要围绕 Cookie,Session 和 HTTPs 进行展开. 后续会针对本篇内容进行详细的
爬虫模拟登录分享
来源: https://segmentfault.com/a/1190000013074959