Skip to content

Commit 24be694

Browse files
daachengdaacheng
committed
HTTPS原理
HTTPS原理
1 parent a23365a commit 24be694

File tree

9 files changed

+126
-1
lines changed

9 files changed

+126
-1
lines changed

‎network_protocol/HTTPS原理.md‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
# HTTPS原理
2+
## 1.HTTP通信存在的问题
3+
* HTTP通信数据传输使用的是明文，传输过程中数据可能被窃听
4+
* HTTP无法验证数据的完整性，数据可能在传输过程中被篡改（没有办法确认发送的请求/响应和接收到的请求/响应前后是否完全一致）
5+
* 无法验证通信方的身份，可能遭遇伪装，任何人都可以伪装成服务器欺骗客户端
6+
7+
## 2.HTTPS
8+
HTTPS是HTTP+SSL/TSL,在HTTP的基础上添加了一个安全层，SSL,Secure Socket Layer,对所有的数据进行加密后传输，是安全版本的HTTP。通常HTTP直接和TCP通信，当使用SSL时，则变成HTTP先和SSL层通信，再由SSL和TCP通信。
9+
10+
![](../pic/network_protocol/https_1.png)
11+
12+
## 3.HTTPS的主要作用
13+
* 对数据进行加密，并建立一个信息安全通道，来保证传输过程中数据安全
14+
* 对网站服务器进行身份认证
15+
16+
## 4.加密算法
17+
#### 4.1. 对称加密
18+
**加密和解密使用的是同一个秘钥。如AES，DES加密算法。**
19+
20+
通过对称加密算法加密时，必须要把秘钥告诉给对方，不然对方无法解密。但是在互联网上转发秘钥时，如果通信被窃听，秘钥也会被第三方获取，这时也就失去了加密的意义。
21+
22+
![](../pic/network_protocol/https_2.png)
23+
#### 4.2. 非对称加密
24+
非对称加密有两个秘钥：公钥与私钥，公钥是公开的，如果用公钥对数据进行加密，只有对应的私钥才可以解密；如果用私钥进行加密，只有对应的公钥才能解密。如RSA加密算法。
25+
26+
缺点：
27+
* 公钥是公开的，所以针对私钥加密的数据，第三方截获后，可以利用公钥解密，获取其中的内容
28+
* 非对称加密在数据加密解密过程中相对耗时，传输效率低
29+
30+
## 5.HTTPS使用对称加密+非对称加密相结合
31+
如果使用对称加密算法，对数据进行加密传输，但是对称加密的秘钥在互联网传输过程中会被窃取，这样就导致数据传输并不安全。
32+
33+
如果使用非对称加密算法 + 对称加密算法相结合，也就是在传输过程中利用非对称加密算法，将对称加密算法的秘钥进行加密，这样就算传输过程中秘钥被截获，别人也无法解密获取到秘钥，相对来说就很安全了。流程如下：
34+
35+
* 服务器将自己的公钥（非对称加密的公钥）告诉给客户端
36+
* 客户端随机生成一个秘钥（对称加密的秘钥），客户端利用非对称加密的公钥 对 对称加密算法的秘钥进行加密，发送给服务器
37+
* 服务器利用自己的私钥解密，得到对称加密算法的秘钥
38+
* 这样客户端与服务器都知道了对称加密算法的秘钥，并且就算该秘钥被第三方获取，也无法解密
39+
* 这样客户端与服务器就可以利用对称加密算法进行加密传输通信了
40+
41+
![](../pic/network_protocol/https_3.png)
42+
43+
#### 以上流程仍然不太安全
44+
非对称加密的公钥，如果直接通过互联网传输给客户端，容易被不法分子劫持，篡改为自己的公钥，如果这样的话，数据传输过程中又不安全了。
45+
46+
![](../pic/network_protocol/https_4.png)
47+
48+
## 6.客户端如何获取服务器的公钥？
49+
服务器的公钥不能在不安全的网络中直接发送给客户端，这时就引入了证书颁发机构（Certificate Authority，简称CA）
50+
#### 数字证书认证机构的业务流程
51+
1. 服务器的运营人员向第三方机构CA提供自己的公钥，组织信息，域名信息等申请认证
52+
2. CA审核通过后，会给服务器颁发签名证书，证书包含：申请者的公钥，申请者的组织信息，域名信息，签发机构的CA信息，有效时间等，同时还包含一个**数字签名**
53+
3. **数字签名**是通过对证书中的明文信息进行哈希计算，得到数字摘要，然后采用CA的私钥对数字摘要进行加密，进而得到数字签名
54+
![](../pic/network_protocol/https_5.png)
55+
4. 客户端向服务器发起https请求时，服务器返回给客户端的是CA颁发的证书
56+
5. 客户端读取证书中的明文，通过哈希计算得到数字摘要；同时利用CA的公钥(操作系统内置)对数字签名进行解密得到数字摘要，如果两个摘要相同，说明证书内容没有被篡改，证书中的秘钥是可以信赖的
57+
![](../pic/network_protocol/https_6.png)
58+
6. 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法
59+
60+
**以上可知，通过第三方证书传输公钥，可以防止公钥被第三方篡改的问题，这样这个通信流程就非常安全了。**
61+
62+
## 7.HTTPS工作流程
63+
1. 客户端发起HTTPS请求，连接服务器的443端口
64+
2. 服务器把配置好的证书发送给客户端
65+
3. 客户端对证书的合法性进行验证，比如是否在有效期内，证书的用途是不是匹配客户端请求的站点等，如果验证不通过会警告
66+
4. 如果证书验证通过，客户端从证书中获取服务器的非对称加密的公钥
67+
5. 客户端随机生成一个对称加密秘钥，利用公钥进行加密，发送给服务器
68+
6. 服务器使用自己的私钥解密，得到对称加密算法的秘钥
69+
7. 之后客户端与服务器就通过对称加密算法进行数据传输

‎network_protocol/main.md‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,4 +17,7 @@
1717
16. [TCP连接的建立与释放](TCP连接的建立与释放.md)
1818
17. [TCP/IP总结](TCPIP总结.md)
1919
18. [HTTP状态码、网关、代理、隧道](状态码网关代理隧道.md)
20-
19. [HTTP首部字段.md](http首部字段.md)
20+
19. [HTTP首部字段](http首部字段.md)
21+
20. [HTTPS原理](HTTPS原理.md)
22+
23+
* [总结](总结.md)

‎network_protocol/总结.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
### 1.UDP和TCP的特点和区别
2+
#### UDP：User Datagram Protocol,用户数据报协议
3+
* 面向无连接
4+
* 尽最大努力交付，不可靠传输，没有流量控制和拥塞控制
5+
* 支持一对一，一对多和多对一通信
6+
* 面向报文（对于应用层传下来的报文直接打包）
7+
* 首部开销小，只有8字节
8+
9+
#### TCP：Transmission Control Protocol，传输控制协议
10+
* 面向连接
11+
* 提供可靠传输，有流量控制和拥塞控制
12+
* 只能是一对一通信
13+
* 面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块）
14+
* 首部开销大，最小20字节，最大60字节
15+
16+
### 2.UDP和TCP的首部
17+
**UDP的首部只有8个字节，源端口号，目的端口号，长度，校验和**
18+
19+
**TCP的首部比较复杂，[TCP首部](TCP首部.md)**
20+
21+
### 3.TCP的三次握手与四次挥手过程，为什么是三报文建立连接，为什么是四报文释放连接
22+
[TCP连接的建立与释放](TCP连接的建立与释放.md)
23+
24+
### 4.TCP短连接和长连接的区别
25+
#### 短连接
26+
Client向Server发送消息，Server回应Client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是 Client先发起close操作。短连接一般只会在Client/Server间传递一次读写操作。
27+
28+
短连接管理起来比较简单，建立存在的连接都是有用的连接，不需要额外的控制手段。
29+
30+
#### 长连接
31+
Client与Server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
32+
33+
在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server端的压力会越来越大，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免客户端连累后端服务。
34+
35+
### 5.TCP的粘包，拆包
36+
#### UDP没有粘包问题
37+
TCP是基于字节流的传输，虽然应用层和传输层之间数据交互是大小不同的数据块，但是TCP并没有对这些数据块区分边界，仅仅是一连串没有结构的字节流；UDP是基于报文传输的，有区分边界，不会发生粘包情况
38+
#### 为什么会发生粘包拆包
39+
TCP是基于字节流传输的，在传输过程中，对于应用层的一个数据包，在传输层可能会拆分成多个字节数据块传输（拆包），也可能是多个数据包合并成一个字节数据块传输（粘包）
40+
* 要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包
41+
* 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包
42+
* 要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包
43+
* 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包
44+
45+
#### 解决办法
46+
在传输层无法保证数据包不被拆分和合并，只能通过应用层制定相关的协议，在应用层接收数据的时候根据协议解决粘包和拆包的问题，比如应用层协议规定消息头标识（边界），定义消息头与消息体，定义数据长度等。应用层在接收数据的时候根据头标识接收指定长度的消息头，然后解析获取消息长度，再接收指定长度的消息体，这样就能解决粘包和拆包的问题了
47+
48+
### 6.TCP的流量控制
49+
[TCP的流量控制](TCP的流量控制.md)
50+
### 7.TCP的拥塞控制
51+
[TCP的拥塞控制](TCP的拥塞控制.md)
52+
### 8.TCP的可靠传输实现
53+
[TCP可靠传输的实现](TCP可靠传输的实现.md)

‎pic/network_protocol/https_1.png‎

35.5 KB
Loading

‎pic/network_protocol/https_2.png‎

23.4 KB
Loading

‎pic/network_protocol/https_3.png‎

51.8 KB
Loading

‎pic/network_protocol/https_4.png‎

51.3 KB
Loading

‎pic/network_protocol/https_5.png‎

32.4 KB
Loading

‎pic/network_protocol/https_6.png‎

37.4 KB
Loading

0 commit comments

Comments
 (0)