爬虫基础——客户端识别

本文讨论一些服务器可以用来识别其交谈对象的技巧。
HTTP最初是匿名、无状态的请求和响应的协议。Web服务器几乎没有信息可以用来判定哪个是用户发送的请求。现代的Web站点希望能够提供个性化的接触，具有如下识别的机制：

承载用户身份信息的HTTP首部。
客户端IP地址跟踪，通过用户的IP地址对其进行识别。
用户登录，用认证方式来识别用户。
胖URL，一种在URL嵌入识别信息的技术。
cookie，一种功能强大且搞笑的持久身份识别技术。

HTTP首部

Request格式如下：

GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq= HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a href="http://www.google.cn">www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r

一个http请求报文由

请求行（request line)
消息头部（header)
空行
请求正文

请求行
请求行由请求方法字段、URL字段和HTTP协议版本字段，组成，它们用空格分隔，例如：GET /index.html HTTP/1.1

请求头部
请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

注意到Connection: Keep-Alive。除了keep alive还有close的情况，静态网页居多的情况下一般是使用close。为什么呢？因为KeepAlive =On时，每次用户访问，打开一个TCP连接，Apache 都会保持该连接一段时间，以便该连接能连续为同一client服务。简单来说就是打开KeepAlive 属性可以有效地降低TCP握手的次数。

空行
最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器请求头结束。
对于一个完整的http请求来说空行是必须的，否则服务器会任务本次请求的数据尚未完全发送到server，处于等待状态

请求正文
请求数据不在GET方法中使用，而是在POST中使用。POST方法适用于需要client填写表单的场合，与请求数据相关的最常用的请求头是Content-Type（MIME）和Content-Length。

客户端IP地址

早期的Web曾将客户端IP地址作为一种标识形式来使用。如果每个用户都有不同的IP地址，且IP地址变化很少，这种方案是可行的。但是使用客户端IP地址来识别用户，存在很多缺点，限制了将其作为用户识别技术的效能：

客户端IP描述的是机器而不是用户。
很多因特网服务提供商会为用户动态分配IP。所以不能假设IP地址能标识用户。
很多用户是通过NAT（网络地址转换）防火墙来浏览网络的，NAT为了解决IP地址短缺的问题，将实际的IP地址转换成了公有的IP。
如果使用代理，Web服务器看到的是代理服务器的IP。

综上所属IP地址不能个性化的识别用户。但是内网中可以这么做。

用户登录

Web服务器无需被动的根据用户的IP地址来猜测它的身份，它可以要求用户通过用户名和密码进行认证。只要用户输入了用户名和密码（对身份进行完整性检查），浏览器就会重复原来的请求，这次它会添加一个Authorization首部，说明用户名和密码。但是任何有这种想法的人，不用费多大事就可以将HTTP基本的认证用户名和密码破解出来，所以这种加首部的方式不常使用，而是时候另外的更安全的技术。
更何况如果登录多个Web站点都需要重新输入用户名和密码，这是很繁琐的。

接下来，讨论由于安全原因和重复输入的麻烦的解决方案。

胖URL

有些Web站点会为每个用户生成特定版本的URL来追踪用户的身份。通常会对真正的URL进行扩展，在URL路径开始或结束的地方添加一些状态信息。用户浏览站点时，Web服务器会动态的生成一些超链接，继续维护URL的状态信息。

比如上面有一段内容就是生成的一个胖URL，它附加了用户生成的一个ID。用胖URL存在几个问题：

丑陋的URL。
无法共享URL。如果把URL给他人，可能会将你积累的个人信息共享出去。
破坏缓存。
额外的服务器符合。服务器需要重写HTML页面使URL变胖。
逃逸口。如果用户请求一个特定的URL，会无意中逃离胖URL会话。
非持久的。用户退出登录的时候，所有信息会丢失。

cookie

cookie是当前识别用户，实现持久会话的最好方式。
cookie分为会话和持久两种类型。用户退出时，会话cookie就会被删除。而持久cookie则存储在硬盘上。他们之间的唯一区别就是过期时间。

cookie包含了一个由（name=value）这样的信息构成的任意列表：

cookie是由浏览器存储在高速缓存目录下的独立的文本文件中的，可以通过浏览这个目录来查看cookie。这叫做cookie罐。

浏览器内部的cookie罐可以有成百上千个，但是浏览器不会将每个cookie都发送给站点，通常它们只向每个站点发送2-3个cookie，原因如下：

隐私问题。将所有cookie发送给所有站点，会发生潜在的隐私问题，你并不信任的站点也会获取到。
识别问题。cookie包含的是特有的键值对，只有当前站点可以识别，大多数cookie都是无法识别的无用数据。
性能问题。浏览器实际传送cookie字节数不能比实际的内容字节数多，否则会严重降低性能。

cookie的域属性
domain可以用来控制哪些站点可以看到那个cookie。
cookie的路径属性
cookie规范允许用户将cookie与部分Web站点关联起来，可以通过Path属性来实现这一个功能，在这个属性列出的URL路径前缀下所有的cookie都是有效的。
例如，某个Web服务器可能是两个组织共享的，每个组织都有独立的cookie，通过设置path=/xx/从而同一站点下的不同请求访问的cookie不同。

HTTP认证机制

尽管可以通过cookie进行认证，但是很多情况下，HTTP的原生认证功能就可以很好的满足要求。
但是基本认证的缺点在上面已经说过了。
所以这里介绍一下摘要认证：

摘要认证是另一种 HTTP 认证协议，它与基本认证兼容，但却更为安全。摘要认证试图修复基本认证协议的严重缺陷。具体来说，摘要认证进行了如下改下：

永远不会以明文方式在网络上发送密码。
可以防止恶意用户捕获并重放认证的握手过程。
可以有选择地防止对报文内容的篡改。
防范其他几种常见的攻击方式。

摘要认证并不是最安全的协议。摘要认证并不能满足安全 HTTP 事务的很多需求。对这些需求来说，使用 TLS 和 HTTPS 协议更为合适一些。但摘要认证比它要取代的基本认证强大很多，具体了解摘要认证可以看看下面这篇文章：https://www.cnblogs.com/huey/p/5490759.html。

我们着重介绍一下HTTPS协议：

先来观察这两张图，第一张访问域名http://www.12306.cn，谷歌浏览器提示不安全链接，第二张是https://kyfw.12306.cn/otn/regist/init，浏览器显示安全。

什么是HTTP?
超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

什么是HTTPS？
HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

HTTP协议传输数据以明文形式显示。HTTPS基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护。而且HTTPS有如下特点：

内容加密：采用混合加密技术，中间者无法直接查看明文内容
验证身份：通过证书认证客户端访问的是自己的服务器
保护数据完整性：防止传输的内容被中间人冒充或者篡改

混合加密：结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。

数字摘要：通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。

数字签名技术：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。

收方能够证实发送方的真实身份；

发送方事后不能否认所发送过的报文；

收方或非法者不能伪造、篡改报文。

client向server发送请求https://baidu.com，然后连接到server的443端口。
服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。
传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名（保证公钥不是第三方伪造的），服务端的域名信息等内容。
客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（秘钥）。然后用证书对该随机值进行加密。
传送加密信息
这部分传送的是用证书加密后的秘钥，目的就是让服务端得到这个秘钥，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
服务段加密信息
服务端用私钥解密秘密秘钥，得到了客户端传过来的私钥，然后把内容通过该值进行对称加密。
传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。

具体了解认证机制，可以看看下面的文章：
https://blog.csdn.net/ctwy291314/article/details/83275456