说说Http原理

注：1.请直接看六。2.一切从Http设计角度考虑。

 

一.Http请求过程：

1.用户浏览器发送域名向DNS服务发送一个域名，请求其ip地址。

2.DNS找到ip并返回给用户浏览器。

3.用户浏览器向服务端浏览器发送请求。（地址、端口号、请求、参数等等）

4.服务端向用户浏览器返回响应。

二.Http特点

http不面向链接，无状态（但我们可以用session+cookie来实现状态）。

三.缺点

Http 协议无法加密数据。

四.体系

IP+TCP+SSL/TLS+HTTP。SSL会对内容加密，防止用户篡改。

五.先说加密算法

对称加密算法：一把key即加密又解密。

非对称加密算法：一对配套的公钥私钥。用公钥对数据进行加密，只有用对应的私钥才能解密；用私钥对数据进行加密，那么只有用对应的公钥才能解密。

六.原理

（从设计角度出发，每一个小段并不是最终状态！）

1.对消息加密，则接收方需要解密得到信息。

既然接收方要解密，就需要得到一把公钥（如果用对称算法则....凉了么这不是....）

但我们发送请求有时需要通过“中间人”（用来协商密钥）。遇到一个“不靠谱”的中间人就可能会生这种事：

①client向中间人：请求获取公钥(s.public) 

②中间人向server：请求获取公钥(s.public)

③server向中间人：返回公钥(s.public)

④如果此时中间人进行篡改，中间人向client：返回自己的公钥(m.public，假公钥)

⑤此时，client发送消息，用假公钥(m.public)进行加密，并返回给中间人。

⑥中间人可以用私钥(m.private)进行解密，篡改信息，再用真公钥(s.public)向client发出篡改后的信息。

所以，我们需要让中间人安分下来！

2.我们需要一个可信的中间人——第三方机构(CA)

第三方机构，它有一个（t.pub）(t.pri)。那么故事就会是这样：

①client向中间人：请求获取公钥(s.pub) 

②中间人向server：请求获取公钥(s.pub)

③server向第三方机构：发出公钥(s.pub)

④在第三方判明申请者的身份后，便为server分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给server。（证书包括了s.pub，颁发机构，等等的信息。SHA-256算法就是在这）

⑤server向中间人：返回数据证书

⑥中间人向client：返回数据证书 （他对证书无能为力。即便也能通过正规渠道从CA获得一个公钥，但是由于CA进行了身份绑定，client可以判断出来！）

⑦client向中间人发送消息...这时中间人已经没有威胁了！

3.那么，client如何验证数字证书？

可以去找第三方问。对于每一个clinet，受信任的CA都被浏览器内置证书，向用户提供其公钥c.pub。

4.现在，让我们忽略中间人再看看整个过程

①当客户端向服务端发送请求三次握手-random

②三次握手之后会得到服务器端发送CA证书[]-random

③客户端对证书进行验证（比如：证书编号、对证书所有路径层级校验、对请求域名做校验、有效期校验....）

④客户端生成随机对称密钥，通过s.pub加密-random

⑤客户端发送给服务端由s.pub加密的对称密钥

⑥服务器端客户端基于会话密钥（生成三个随机数[三个random由s.pub加密]进行验证，这就是对称加密）进行通信 。

5.小小总结

用非对称加密生成数字证书，然后用对称加密进行传输。

过程中生成随机数，知道开始会话才最终确定密钥。