test1111

• 了解客户端和服务端的请求原理
• HTTP协议及其组成
• HTTPS交互原理分析

访问支付宝，微信的开放接口 都是基于HTTP

对外提供的开放服务 API都是基于HTTP协议的，

微服务中的服务之间的调用大部分都是基于HTTP协议的。

Web层提供http协议的对外接口

http协议是基于TCP可靠通讯协议之上的

fiddler：这是一个抓包工具，抓取网络上一个请求。所有的请求都经过了fiddle。

下载地址：https://www.telerik.com/download/fiddler/fiddler4

post http://csdn.net htt/1.1

方法 URL/URI 协议的版本

Request 请求头

Response

头部

• Host：目标地址
• Connextion：链接地址
• Referrer：做防盗链
• Cookie：携带参数

​

内容

[“headers”…]

Response

• http/1.1 200 OK
• 协议/版本号
• 响应状态码
• 状态码对应的原因

头部信息

• Server:openresty 基于nigix和lua实现的高性能的web平台
• Date
• Connertion
• ......

URL/URI

URL

网络上的资源位置

http://www.gutapedu.com:80/java/index.html?name=mic#head

指定协议类型（ftp/https）

Host	域名，然后解析成IP地址
Port	端口号（一般不写）
Path	资源路径（虚拟主机对应的路径名称）
Query-string	查询字符串
#head 片段标识符	页面某个地方有个一锚点，到最上边，到最下边

URI

统一资源的标识符

• URI定位到互联网上的某一个资源
• URL标识这个互联网上的一个地点

​

方法

Post	资源给你
Get	查询
Delete	删除
Put	做更新
Option	服务端告诉我这个URI支持的是什么类型 post get
Head	查询请求，拿到head信息，不要返回主体

HTTP协议的特点

http协议是无状态的。

两次http请求之间是没有关系的。

http在服务端不需要记录请求的状态，省了很多开销，

比较灵活，应用面更广。

登录，在登录，在登录，哈哈哈

无状态解决方法

http协议引入了cookie机制，解决了http无状态的问题

cookie由服务端生成，保存在客户端，下一次请求携带cookie信息发送过来。

Tomicat中有session session有sessioinID （set-cookie ）

客户端保存 cookie.JSESSIONID

下次发送时携带cookie发送到服务端。

不用session的原因

需要通过session统一保存，

分布式架构中需要同步session，统一session的问题。所以我们很多时候自己扮演tomcat生成这样的一个角色，客户端的session信息，我是可以自己保存的，我可以开一个授权服务，专门生成Token，然后把Token返回给客户端的浏览器去保存。

通信是明文的

可以通过抓包工具，拿到http协议的数据

通信被第三方不法分子去抓取，可以拿到你的信息，可以监听，篡改。解决不安全问题。

由https协议

一种加密的超文本传输，发送过程中完全加密

基于TCP协议层之上去扩展的一个协议层。

https和http协议分层一模一样。

https的通信原理

怎么去实现安全传输的。

SSL(Secure Sockets Layer 安全套接层),

http 不加密

https的通信原理

怎么去实现安全传输的？？

需要加密：

所以要分配不同的密钥

服务端怎么告诉客户端使用的哪一种加密算法

客户端无法全部都预置密钥，所以就需要在通信过程中把密钥发给客户端。如果在通信过程中拿到密钥的话，又是不安全传输。

涉及网络传输的就是一个不安全的。所以怎么去协商密钥的过程。

密钥的分发也很复杂，是每一次请求都分发，还是第一次分发，

非对称性加密

公钥怎么去拿？

密钥的泄露问题怎么解决

问题在于中间人身份的不确定性

需要一个中间人去证明这个请求是服务端的。

服务端把需要传递给客户端的公钥再做一次加密。

第三方也使用非对称加密

第三方机构

不法分子有可能先获得一个公钥，然后拦截请求之后，替换掉证书。

客户端的数字证书内部内置解密算法。

对称加密 密钥a 密钥a

密钥是统一的。

拿到密钥后，一个更改其他的请求了

每个客户端分配不同的密钥。

服务端怎么告诉客户端要使用哪种加密算法

客户端不能预置密钥，

密钥是网络传输的。

密钥的分发处理起来很麻烦。什么时候分发，怎么分发

每个客户端都可以拿到一个公钥，不同的公钥，每一个客户端拿到不同的公钥。

服务端存储私钥

公钥怎么去传输？？？

服务端利用网络去分发是一定可以截取的，

中间人可以截取。

引入第三方。

第三方，通过自己的私钥去加密公钥

第三方机构 （CA）

第三方机构（CA）对使用私钥服务端的公钥进行加密

数字证书

证书编号（MD5）。

域名

所有者

有效期

加密（server短的公钥）

数字签名的生成算法：MD5

客户端对证书进行加密

服务端下载数字证书以后，利用内置的公钥进行解密，根据证书的签名算法，对证书的内容进行加密，然后跟服务端发给客户端的消息进行比较。

浏览器或操作系统都会内置一些证书

阿里或微信在你支付的时候会进行提示你进行下载证书。

1.客户端发起请求(Client Hello 包)

三次握手，建立 TCP 连接

支持的协议版本(TLS/SSL)

客户端生成的随机数 client.random，后续用于生成“对话密钥”

客户端支持的加密算法

sessionid，用于保持同一个会话（如果客户端与服务器费尽周折建立了一个 HTTPS 链接，刚建完就断了，也太可惜）

2.服务端收到请求，然后响应（Server Hello）

确认加密通道协议版本

服务端生成的随机数 server.random，后续用于生成“对话密钥”

确认使用的加密算法（用于后续的握手消息进行签名防止篡改）

服务器证书（CA 机构颁发给服务端的证书）

3.客户端收到证书进行验证

验证证书是否是上级 CA 签发的，在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级地进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信

服务端返回的证书中会包含证书的有效期，可以通过失效日期来验证 证书是否过期

验证证书是否被吊销了

前面我们知道 CA 机构在签发证书的时候，都会使用自己的私钥对证书进行签名 证书里的签名算法字段 sha256RSA 表示 CA 机构使用 sha256 对证书进行摘要，然后使用 RSA 算法对摘要进行私钥签名，而我们也知道 RSA 算法中，使用私钥签名之后，只有公钥才能进行验签。

浏览器使用内置在操作系统上的CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的机构颁发。验签之后得知 CA 机构使用 sha256 进行证书摘要，然后客户端再使用 sha256 对证书内容进行一次摘要，如果得到的值和服务端返回的证书验签之后的摘要相同，表示证书没有被修改过。

验证通过后，就会显示绿色的安全字样

客户端生成随机数，验证通过之后，客户端会生成一个随机数 pre-master secret，客户端根据之前的：Client.random + sever.random + pre-master 生成对称密钥然后使用证书中的公钥进行加密，同时利用前面协商好的加密算法，将握手消息取 HASH 值，然后用“随机数加密握手消息+握手消息 HASH 值（签名）”然后传递给服务器端；(在这里之所以要取握手消息的HASH 值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。)

4.服务端接收随机数

服务端收到客户端的加密数据以后，用自己的私钥对密文进行解密。然后得到client.random/server.random/pre-master secret，再用随机数密码 解密 握手消息与 HASH 值，并与传过来的。

HASH 值做对比确认是否一致。

然后用随机密码加密一段握手消息(握手消息+握手消息的 HASH 值)给客户端

5.客户端接收消息

客户端用随机数解密并计算握手消息的 HASH，如果与服务端发来的 HASH 一致，此时握手过程结束，之后所有的通信数据将由之前交互过程中生成的 pre master

secret / client.random/server.random 通过算法得出 session

Key，作为后续交互过程中的对称密钥

WEB攻击手段

主动攻击

我是一个主动的行为，去做SQL注入。

被动攻击

跨站脚本攻击、请求伪造

csrf(Cross-Site Request Forgeries )跨站请求伪造攻击

看了一篇文章的介绍，csrf ，引用下其中评论的一段总结：

CSRF(Cross Site Request Forgery)即跨站请求伪造。就是利用后台有规律的接口，例如 localhost/deleteAriticle.php?id=3&username=xiaoxiao，攻击者在被攻击的网站页面嵌入这样的代码，当用户xiaoxiao访问该网站的时候，会发起这个请求。服务器会删除id为3的数据。

客户端防范：对于数据库的修改请求，全部使用POST提交，禁止使用GET请求。

服务器端防范：一般的做法是在表单里面添加一段隐藏的唯一的token(请求令牌)。

来源于: https://javaguide.net

微信公众号：不止极客