1. 授权

定义

由身份或持有的令牌确认享有的权限，登录过程实质上的目的也是为了确认权限。

Http中确认授权的方式一：Cookie（目前不常用于授权）

Cookie是客户端给服务器用的，setCookie是服务器给客户端用的。cookie由服务器处理，客户端负责存储

工作机制:

• 服务器需要客户端保存的内容，放在set-Cookie headers里返回，客户端会自动保存。
• 客户端保存的Cookies，会在之后的所有请求里都携带进Cookie header里发回给服务器。
• 客户端保存Cookie是按照服务器域名来分类的，例如baidu.com发回的Cookie保存下来后，之后请求google.com并不会带上cookie。
• 客户端保存的Cookie在超时后会被删除，没有设置超时时间的Cookie（称为Session Cookie）在浏览器关闭后就会自动删除。

Cookie登录：

客户端发送cookie：账户和密码
服务端收到后确认登录setCookie：sessionID=1，记下sessionID
客户端收到sessionID后记录，以后请求服务端带上对比记录下sessionID，说明已经登录

Cookie作用：

会话管理：登录状态，购物车
个性化：用户偏好，主题
Tracking：分析用户行为

Cookie攻击

XXS：跨脚本攻击，及使用JavaScript拿到浏览器的cookie之后，发送到自己的网站，以这种方式来盗用用户Cookie。Server在发送Cookie时，敏感的Cookie加上HttpOnly，这样Cookie只能用于http请求，不能被JavaScript调用
XSRF:跨站请求伪造。Referer 从哪个网站跳转过来

Http中确认授权的方式二：Authorization

两种方式：Basic和Bearer

Basic

• 格式：Authorization:Basic<username:password(Base64ed)>

Bearer

• 格式：Authorization:Bearer<bearer token>
• bearer token获取方式：通过OAuth2的授权流程

首先第三方网站向授权网站申请第三方授权合作，拿到授权方颁发的client_id和client_secret（一般都是appid+appkey的方式）。

1. 用户在使用第三方网站时，点击授权按钮，跳转到授权方网站，并传入client_id作为自己的身份识别。
2. 用户同意授权后，授权网站将页面跳回第三方网站，并传给第三方网站Authorization code作为用户认可的凭证
3. 第三方网站将Authorization code发给自己的服务器
4. 服务器将Authorization code和client_secret一并发送给授权方的服务器，
5. 通过验证后，返回access_token。整个OAuth流程结束。

在这就过程中申请的client_secret是服务器持有的，安全起见不能给客户端，用服务端去和授权方获取用户信息，再传给客户端，包括④，⑤的请求过程也是需要加密的。这才是标准的授权过程。
有了access_token之后，就可以向授权方发送请求来获取用户信息

OAuth授权.png

实例分析，微博授权

实例.png

步骤分析就是上面的内容，这里把第4,6,8请求的参数分析一下
第④步参数：
response_type：指授权类型，必选，这里填固定值‘code’
client_id：指客户端id，必选，这里填在平台报备时获取的appid
redirect_uri：指重定向URI，可选
scope：指申请的权限范围，可选
state：指客户端当前状态，可选，若填了，则认证服务器会原样返回该值

第⑥步参数：
grant_type：指使用哪种授权模式，必选，这里填固定值‘authorization_code’
code：指从第⑤步获取的code，必选
redirect_uri：指重定向URI，必选，这个值需要和第④步中的redirect_uri保持一致
client_id：指客户端id，必选，这里填在平台报备时获取的appid
client_secret：指客户端密钥，必选，这里填在平台报备时获取的appkey

第⑧步参数：
access_token：指访问令牌，必选，这里填第⑦步获取的access_token
token_type：指令牌类型，必选，大小写不敏感，bearer类型 / mac类型
expires_in：指过期时间，单位秒，当其他地方已设置过期时间，此处可省略该参数
refresh_token：指更新令牌，可选，用即将过期token换取新token
scope：指权限范围，可选，第④步中若已申请过某权限，此处可省略该参数

Refresh token

我们在上面的第八步中会有refresh_token的参数，这个在实际操作中也比较常见

• 用法：access_token过了有效时间后，调用refresh token接口，传来新的token

自己项目借鉴，简化OAuth2的过程

有时候我们在自己的项目中，将登陆和授权设计成类似OAuth2的过程，不过去掉Authorization code。登陆成功返回access_token，然后客户端再请求时，带上access_token。

2. TCP/IP

我们常常会说到TCP/IP，那到底是什么呢。这就需要讲到网络分层模型。TCP在传输层，IP在网络层。那为什么需要分层？因为网络不稳定，导致需要重传的问题。为了提高传输效率我们就需要分块，在传输层中就会进行分块。TCP还有两个重要的内容就是三次握手，四次分手。

三次握手

1. 客户端：我要给你发消息了（SYN =1 , seq = x）
2. 服务端：我知道了(ACK =1 , ack = x+1) ，我也要给你发消息了(SYN = 1 , seq = y)

3. 客户端：我知道了(ACK = 1 , ack = y+1)

   
   
   TCP三次握手.png

• 两次握手是否可以？
  不可以，三次握手防止因网络重传问题导致无效的连接。比如当A的第一次请求因网络慢B端迟迟收不到的问题，A发送第二次请求，如果是两次握手就会建立连接，当网络变好第一次请求再次到达B端就会再次建立一个连接。

四次挥手

1. 客户端：我要给结束连接了（FIN =1 , seq = u）
2. 服务端：我知道了(ACK =1 , ack = u+1 , seq = v)
3. 服务端：我也要结束连接了（FIN =1 , seq = w , ACK =1 , ack = u+1）

4. 客户端：我知道了(ACK = 1 , ack = w+1 , ack = w+1)

   
   
   四次挥手.png

• 为什么连接的时候是三次握手，关闭的时候却是四次握手？
  因为B端要在收到A端发送Fin消息后，可能还有需要传输的数据，所以多了一次握手。
• 为什么A在TIME-WAIT状态必须等待2MSL的时间？
  当B端收不到A最后发过来的ACK信息，这时B就会重传Fin+ACK的消息，若果马上关闭就会导致A收不到，而且不会再发送ACK信息给B。
  TCP三次握手和四次挥手过程

3. HTTPS建立过程

HTTPS 协议是由 HTTP 加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护

http和https对比.png

下图是HTTPS建立的过程，但是主要步骤都在图中有显示

简述https建立过程（图一）.png

1.客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法及密钥长度），客户端随机数，hash算法。

2.服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件，服务端随机数。服务器的加密组件内容是从接收到客户端加密组件内筛选出来的。

3.之后服务器发送Certificate报文。报文中包含公开密钥证书。一般实际有三层证书嵌套，其实像下面图二直接用根证书机构签名也是可以的，但是一般根证书机构比较忙，需要类似中介的证书机构来帮助。

4.最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

5.SSL第一次握手结束后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。

6.接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

7.客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密报文作为判定标准。

8.服务器同样发送Change Cipher Spec报文。

9.服务器同样发送Finished报文。

10.服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP响应。

11.应用层协议通信，即发送HTTP响应。

12.最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。

图二内容解释Certificate报文中证书内容。

证书机构认证（图二）.png

图三内容解释对称加密的密钥创建

利用客户端随机数，服务端随机数，per-master secret随机数生成master secret，再生成客户端加密密钥，服务端加密密钥，客户端MAC secert，服务端MAC secert。MAC secert用于做报文摘要，这样能够查知报文是否遭到篡改，从而保护报文的完整性。

Https创建之后的密钥（图三）.png

Https建立流程.png

Android网络请求知识（一）HTTP基础概念
Android网络请求知识（二）对称和非对称加密、数字签名，Hash，Base64编码
Android网络请求知识（三）授权，TCP/IP，HTTPS建立过程