网络知识
TCP
TCP 有三个特点，面向连接、可靠、基于字节流
基于字节流
- TCP 传输的数据是字节流，就是 01 串，没有边界，所以要有规则来划分边界，于是基于 TCP 就衍生了非常多的协议如 HTTP 和 RPC
- HTTP 主要用于 B/S 架构（浏览器），而 RPC 更多用于 C/S 架构（各种联网软件的客户端），现在他们在慢慢融合，很多软件都支持多端，所以对外一般用 HTTP 协议，内部集群用 RPC
- RPC 出现比 HTTP 早，比 HTTP/1.1 性能好，所以大部分公司内部都在用 RPC，HTTP/2.0 性能可能更好但才出来几年，目前替代不了 RPC
TLS 协议
- http 是明文传输，为了加密提升安全性，在 HTTP（应用层）和 TCP（传输层）之间加入 TLS 协议来加密数据，也就是 https（Hypertext Transfer Protocol Secure）
- 采用非对称加密（公钥私钥）生成秘钥，然后对称加密（同一个秘钥）加密解密
RSA 握手流程
- 第一次握手：首先客户端会发一个「Client Hello」消息，里面有客户端的 TLS 版本号，密码套件，生成的随机数等，服务端会保留这个随机数，之后用于生成对称加密秘钥
- 第二次握手：服务端接收消息后，确认 TLS 版本号，然后也生成随机数，然后从密码套件里面写一个，最后把公钥（TLS 证书，由 CA 签名）发送给客户端用于验证自己身份，服务端自身存有私钥
- 第三次握手：客户端解析这个证书，确认证书合法性后（CA 是私钥签名公钥验证，原理写在后面），生成一个新随机数（pre-master）用 RSA 公钥加密后给服务端，服务端会用 RSA 私钥解密，得到客户端发来的随机数，至此有三个随机数，客户端先后生成了两个，服务端一个，客户端根据这三个随机数生成相同的会话秘钥，生成后向客户端发信号告诉服务端可以开始加密了
- 第四次握手：服务端也是同样操作生成一个和客户端相同的会话秘钥，双方验证加密和解密都可行后，所有 http 请求/响应都会根据这个秘钥进行对称加密
CA 证书验证原理
只有私钥能生成合法签名，然后用公钥和消息验证，仅凭公钥和消息不能倒退签名
每个网站都会去第三方权威机构（CA）进行申请注册证书，提交自己的公钥和域名
浏览器收到证书后，会检查这个证书是不是被篡改过。
- 原理：CA 机构在颁发证书时，会用自己的私钥对证书内容进行签名，就是根据证书内容计算出哈希值，然后用私钥给哈希值签名
- 验证：浏览器需要验证这个签名。它会去系统或浏览器内置的**“受信任的根证书颁发机构”**列表里，寻找颁发该证书的 CA 机构
- 操作：找到后拿到 CA 机构的公钥（这个公钥是你的操作系统或浏览器出厂时就自带的，绝对可信），去验证证书上的数字签名，公钥解开解开签名拿到哈希值，浏览器自己再对证书计算出哈希值
- 结果：如果两个哈希值一致，就说明这个证书确实是该 CA 机构颁发的，没有被黑客中途修改。
RSA 的缺陷
不支持向前保密，如果服务端私钥泄露，之前的数据都可以被这个私钥解密，为了解决可以用 ECDHE 秘钥协商算法
公钥与私钥（非对称加密）
公钥加密的密文，只有私钥才能解密
公钥加密私钥解密，保密通讯，确保只有私钥持有者能解密
可以验证消息的来源是否是合法客户端，就比如 jwt 的验证
- 比喻：就像寄快递时的收件人专用信箱
- 过程：任何人都可以用你的公钥（公开的）给消息上锁，但只有你有私钥（唯一的钥匙）能打开
- 实际应用：HTTPS 网站加密验证等
只有私钥才能生成合法签名
私钥签名公钥验证，数字签名，验证消息来源真实性
只有持有私钥的人才能生成有效签名，可以验证身份，比如 CA 的证书
- 比喻：就像个人专用印章
- 过程：只有你能用自己的私钥盖章，别人用你的公钥验证这个章是不是真的属于你
- 实际应用：CA 颁发证书、软件签名、身份证认证等