HTTP是一个客户端（用户）和服务端（网站）之间请求和应答的标准，通常使用TCP协议。其本身位于TCP/IP协议族的应用层。
- 客户端&服务器
- 无连接
- 无状态
加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥，常见算法有：AES、DES、SM4。
需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用于加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文。公钥可以公开，可任意向外发布；私钥不可以公开。基于公开密钥加密的特性，它还能提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。常见非对称算法有：RSA、DSA、SM2。
是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值的指纹。常见算法有：MD5、SHA-256、SM3
百科给出的解释是：传输层安全性协议（Transport Layer Security）及其前身安全套接层（Secure Sockets Layer）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。网景公司在1994年推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化后即TLS。目前SSL/TLS已成为互联网上保密通信的工业标准。
HTTP over SSL/TLS，HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
一个网站如果要使用https，第一步就是找CA机构申请证书。简要流程如下
1. 申请人服务器server,生成一对非对称秘钥server_prikey、server_pubkey
1. 申请人把一些申请信息（使用者、有效期等）sever_info和server_pubkey递交给CA机构
1. CA机构验证申请人身份后，对server_info+server_pubkey+ca_info(ca机构添加的一些信息)进行散列运算，得到server_hash
1. CA机构使用自己的私钥ca_prikey 对server_hash进行签名，得到sign_server_hash
1. CA机构根据sign_server_hash+server_pubkey+server_info+ca_info构建成证书server_cert，并下发给申请人
1. 申请人配置证书到服务器server，一般情况下会开启443端口对外提供https的能力。
一些特殊的行业，处于多方面的顾虑，可能会搭建自己的CA服务，例如：各大银行、12306、硬件设备制造商等。目前国际上比较知名CA机构的根证书（CA的公钥）是预装在操作系统或浏览器的，如下图。
现实中，网站的证书验证多数是通过证书链的机制实现的，操作系统预装的证书也都是证书链最上层的根证书，而我们申请到的证书，也多是二级证书机构颁发的。
以访问百度为例，查看三次握手的抓包数据，其中110.242.68.3是百度服务器地址，10.100.172.90是我本机的局域网地址（客户端）。
1、客户端发送syn：
2、服务器响应syn+ack
3、客户端发送ack
流程如下（网络取图）：
仍旧以访问百度为例，查看https访问时，TLS的多次握手
2.1、客户端发送 client hello
- Content Type: Handshake (22)
- 0x16表示内容类型为握手协议
- Version: TLS 1.0 (0x0301)
- 使用TLS1.0
- Random: 777cd47f33acca3e39c74b2aac641fc1b5bc7c64ff5436d944281495d38899a7
- 随机数，4字节时间戳+28字节随机数，可以防重放
- Session ID: d14d21a0d37f4987c087d2fca80c2beca15dd93d3c90c69fe30b1fb4870fa84f
- sessionId，0-32字节随机数
- Cipher Suites (18 suites)
- 客户端支持的密码套件算法列表（优先级顺序）
- Extension
- 扩展信息
2.2、服务器响应 server hello
- Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
- 服务器根据客户端秘钥算法列表协商的秘钥
- TLS 通讯协议类型
- ECDHE 交换秘钥算法
- RSA 身份验证算法，一般为证书使用的算法
- AES 通信时的加密算法
- HSA256 哈希算法，计算签名使用
** 2.3服务器下发公钥证书**
- Certificates (3749 bytes)
- 下发给客户端的证书，一般情况下如上图有两个证书，一个是根认证机构颁发给二级机构的证书，一个是二级认证机构颁发给百度的证书
2.4服务器下发交换秘钥参数、协商秘钥的公钥（非必须，使用ECDHE交换秘钥算法时需下发参数）
- Named Curve: secp256r1 (0x0017)
- 指定非对称秘钥算法的椭圆曲线
- Pubkey:
- 公钥
- Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
- 签名算法
- Signature:
- 签名
2.5服务端响应结束，因为有一些不确定响应，需要最后回复一次客户端响应完毕。
在服务器响应结束前还有可能还有一次Certificate Request请求，用于请求客户端公钥证书，适用用高安全性场景下的双向认证。
3、客户端请求，这一部分协议差异比较大，在TLS1.3中规定该步骤为最后一步，无需TLS1.2后续确认响应，但是百度使用的TLS1.2，也没有后续的确认操作了。
- EC Diffie-Hellman Client Params
- 协商秘钥客户端参数
- Change Cipher Spec Message
- 告知后续使用密文传输
- Handshake Protocol: Encrypted Handshake Message
- 密文，如果服务器能顺利解密则协商成功
4.1、服务器创建session ticket
- Session Ticket:
- 服务的生成的session ticket,session ticket包含sessionId和协商的加密参数以便连接重用。
4.2 服务端告知密文传输
**
- Change Cipher Spec Message
- 告知客户端以后使用加密通讯
4.3 服务器发送密文数据
- Handshake Protocol: Encrypted Handshake Message
- 使用协商秘钥加密后的密文数据
至此，tls整个协商过程结束
http syn握手建立tcp连接
客户端开始tls握手
服务端开始tls握手，并下发证书供客户端认证服务器身份
客户端和服务端通过秘钥交换算法交换秘钥
通过协商秘钥安全协商出对称秘钥key
后续双方使用key加密传输的数据
服务端创建session ticket，用于保持和恢复连接
最后附上完整交互图，摘自网络，大致相同，待后续补充
