比如主题界面。比如b站，你点击哪个分区最多，会多给你推送哪个分区的视频。
- 分析用户行为
分析一下用户喜欢上什么网站，喜欢浏览什么东西。（目的就是广告）
下面来讲两个关于Cookie的危险性
- XSS（Cross-site scripting）
跨站攻击。
假如这个网页的脚本是嗨客写的，那么用户在输入信息后，然后用户又是自动存Cookie，不会告诉服务器（因为不告诉，所以不安全），嗨客就能拿着这些Cookie去做坏事。
就比如用QQ号去注册了不明网站的信息，然后QQ被盗了，然后在QQ空间+全部人转发 羞耻信息 哈哈哈哈哈哈哈哈啊哈
解决方案是使用：HttpOnly，有兴趣的可以上网查
- XSRF（Cross-site request forgery）
跨站请求伪造，利用了Cookie的自动机制
例如用户登录了一个银行网站，然后又去访问了坏人的网站，然后嗨客就更改了Cookie信息，等到用户下次登录银行网站后，做转钱操作，这个时候Cookie就会更改请求信息，把转钱的url改一下，就转到嗨客手中了。
解决方案是使用：Referer
Authorization有两种类别，一种是Basic，一种是Bearer
Basic
用Http的Request来介绍：
【GET /user Http/1.1
Host：XBao.com
Authorization：Basic：<username:password(Base64)>】
↑其中的xxxx就是信息的Base64码
比如 （rikka：123）–》Base64编码 ，然后放在Basic中。
然后发送请求后，服务器通过验证Basic，来判断用户本人。
但是这个是不是也忒不安全了，毕竟Base64通过码表就能破解了，信息如果被捕获，那不就完了。
所以一般这种东西都是存在本地，在本地做验证…
Bearer
相当于一个授权凭证、令牌。
格式为：
Authorization：Basic：< bearer token>
这个token是api的token。这个token是授权方给的，所以相较于Basic，它更加安全。
OAuth2
OAuth2是基于Bearer的第三方授权，可以让开发更加安全。
比如我要登录CSDN，然后可以用QQ来授权登录，这个时候 我和QQ是第一方和第二方，CSDN是第三方。（这里也不用分的太清楚）
然后在登录的网页的URL就能看到 一个Client_Id:
这个client_id是CSDN传过去的，是CSDN给QQ的指定id。
Client-ID它的作用是传给QQ后，QQ识别后，你这个是CSDN登录，我给你整一个快速登录的界面，这个界面是专门的 用于CSDN的快速登录。
在了解完OAuthor2的概念后，我们来具体看一下OAuthor2的工作流程
首先，CSDN向QQ发送授权请求，并且发送client_id，这个client_id是CSDN和QQ在一开始就协商好的，csdn给到qq后，qq说OK，用户要在csdn申请QQ登录，了解。
然后呢QQ接收到了client_id，就会给CSDN返回一个授权码Authorization code
这个并不是token，因为token很重要，而且OAuthor2不要求使用HTTPS，所以这个中间的信息很有可能被盗用，所以不能传token。那么token如何获取呢？
这个时候CSDN会把Authorization code给其服务器，而这个过程是绝对安全的，不怕被窃取的。
然后CSDN的服务器会去向QQ的服务器发送请求，发送的时候带上了Authorization code 和 client_secret
client_secret是CSDN第三方登录时产生的，是绝对安全的，只有Server才有，而它传向QQ的传输过程绝对是HTTPS连接。
所以 QQ获取了 client_secret，它就有足够的信息知道，对方是CSDN用户在操作了，这个时候，它就把token传过去了。
这个时候Server拿到token后，OAuthor2的流程就已经结束了。
之后CSDN通过权限，比如去获取QQ的头像、用户名什么的，就会通过Bearer获取：
比如发送一个Request获取头像：
【GET /user/avator Http/1.1
Host：QQ.com
Authorization：Bearer< rikka token (base64)>】
微信登录
其实流程就是和上述差不多，也是个标准的OAuthor2流程。
access_token可能会失效，可以通过 https的Refresh Token向对方刷新token，这个时候怎么让对方知道你是原来之前那个人而不是新的人过来骗他盗取信息呢？那只能是通过 client_secert来让对方知道啦。
所以 client_secert真的很重要，必须要保密。
登录和授权就介绍到这里。
主要是介绍了 Cookie、Authorization，都是比较好理解的。
接下来来介绍下TCP/IP协议族
===========================================================================
一系列协议所组成的一个网络分层模型。
我们这里就不再讲解TCP的三次握手四次挥手了。因为那个比较简单，大家都懂。
这里主要讲一下为什么网络要分层？
首先看一下下面的数据在网络中的传输图：
从客户端到服务端的数据传输会经过许许多多的节点、路由器。
最理想的情况当然是直接从一个客户端，一条线连接到服务端。数据不走任何节点，但这个不可能发生的。
就是因为经过这么多的节点，所以会出现：总会有那么几个网络节点不稳定。整个网络是不可能一直保持的稳定的，数据的丢失和重传是一定会发生的。比如那种更大数据，就必须使用分段传输了。
而分段传输就必须要分层了。
所以网络的分层模型必须要抽出一层来做数据包分发，这一层就是传输层，TCP。
而TCP、UDP都有网络的需求，它们如果又要分包又要查包又要传包，那它们的工作也太多了。
所以这个时候又专门抽出一层来蒙头传，它不管包的顺序，也不管包到了没有，就是 通过给上层给自己的目标、路由表进行 寻址，然后传数据，这就是网络层、IP层，等传完之后，服务端的网络层把数据往上层 传输层传，让传输层来判断 有没有数据丢了，如果丢了，就告诉自己的TCP层，然后自己的TCP层又装好包让IP层去传数据。
数据链路层就是真实的传数据（每个包的数据），而且是二进制的，10101001的传。
都是些文字，没有图片。可以总结出：网络分层的根本原因是网络不稳定
TCP/IP就到这里，不用多讲，因为本blog并不是专门研究TCP/IP的。
TCP的连接就不讲啦，我们只需知道：
HTTP的连接指的就是TCP的连接，因为HTTP本来就是无连接的、无状态的，这是一个概念性的东西。
这里了解完就可以进入HTTPS的学习了。
==========================================================================
这里进入正题。
HTTPS就是在HTTP的基础上使用了SSL协议（又称TLS协议）
先说大致的步骤：
-
客户端请求建立TLS连接
-
服务器返回证书
-
客户端验证服务器证书
-
验证通过后，和服务器协商对称密钥（这个过程是非对称加密）
-
使用对称加密开始通信
看到了密钥，就说明了Https里确实是用到了对称加密，先用非对称加密协商对称加密的私钥，再用对称加密来进行交流。
这里先说一下为什么不全程用非对称加密，因为非对称加密太慢了，本来https就很慢，如果通信还是非对称加密的话那就更慢了。
然后我来文字+图解Https的连接，就是客户端向服务端完成一个Https连接的过程。
- 客户端向服务端发送一个 “连接请求”，比如发送一个字符串“I am Client，Hello”
除了这个字符串，还会附加一些信息，比如可用的TLS版本，Cipher Suite（可以接受的对称加密算法、非对称加密算法、Hash算法），和一个客户端随机数（后面会在加密的时候用到）
- 服务器收到后，向客户端发送一个“确认”，发送一个字符串比如：“I am Server，Hello”
然后从客户端所带的信息里，挑选自己想要使用的 TLS版本、自己喜欢的加密算法。
传过去以后，双方就已经确认好了 TLS版本、Cipher Suit，和各自的随机数。
- 服务器继续发送一个
证书，这个证书很重要
这个证书包含了服务器的公钥和三级证书。
我们来逐个分析这整个服务器发送给客户端的证书：
（1）一级证书：它包含了服务器的地址、服务器加密公钥和证书签名，要求客户端使用这个公钥，但由于传输不是安全的，所以有可能这个证书是伪造的！所以我们需要验证该证书的签发机构是否是可靠的。所以就这里就带了二级证书。
（2）二级证书：它首先包含了证书机构的自身信息，并且带上了一级证书的公钥，用这个公钥可以解开一级证书中的证书签名（所以这个地方使用到了是签名验证），但是坏人万一很厉害，可以自己搞一个证书机构，然后自己做一对密钥，然后以及证书也是这样伪造出来的，那怎么搞？所
以最权威的三级证书出现了
（3）三级证书：它又称根证书，它可以验证二级证书是安全的！并且它最权威，它的可靠是官方认证的。根证书保存于我们的操作系统（苹果官方、谷歌官方、微软官方..官方认证！），也就是说，它从操作系统创建的时候，就已经存在了。是最老大的签发机构，所以当验证完了根证书后，那么这整个证书的可靠性就能知道了。
当然，如果连根证书都是有问题的话，那我们是不可能有办法的（因为我们必须无条件信任根证书）
一般都有三级证书，大家（如果是Chrome浏览器）可以点击网站左边的 锁头，然后就可以查看三级证书信息了（根证书很忙的，所以一般不会直签三级证书）
- 然后服务器还没有发完！它在这个时候正式的使用了并且是唯一一次非对称加密（上面那个验证签名的不算）
服务器用其发送的 证书公钥非对称加密了一个 Pre-master Secret，它也是一个随机数。
- 双方根据
Pre-master Secret和客户端随机数+服务器随机数算出Master Secret，这个一听名字就很隐私。
（我也不知道，虽然客户端随机数和服务器随机数都是明文传输的，但是数学上和实际上，这样更加的安全 = =！）
- 双方根据
Master Secret计算出密钥，而且是6个（其中有2个不重要）
6Ly9ibG9nLmNzZG4ubmV0L3Jpa2thdGhld29ybGQ=,size_16,color_FFFFFF,t_70)
- 双方根据
Pre-master Secret和客户端随机数+服务器随机数算出Master Secret，这个一听名字就很隐私。
（我也不知道，虽然客户端随机数和服务器随机数都是明文传输的，但是数学上和实际上，这样更加的安全 = =！）
- 双方根据
Master Secret计算出密钥，而且是6个（其中有2个不重要）