本篇博客是对下面博客连接上的原文进行梳理+自己在其他方面资料做个整理
一个正常的TLS1.3 握手顺序是按照下面的顺序进行：
- 客户端发送Client Hello（CH）报文，包含有关密钥协商以及其他与TLS连接建立有关的扩展给服务端。
- 服务端发送Server Hello（SH）报文，包含有关密钥协商的扩展返还给客户端，双方根据CH和SH的协商结果可以得出密钥材料。
- 如果客户端发送的CH报文不满足服务端的需要（如：不包含服务端支持的DH组件），服务端会发送一个Hello Retry Request报文给客户端，要求客户端重新发送符合要求的CH报文。
- 利用密钥材料和前两个报文的哈希值，使用HKDF可以计算出一个handshake_key，此后握手阶段的信息受该密钥保护。
- 服务端发送Encypted Extension（EE）报文，包含其他与密钥协商无关的扩展数据给客户端。
- 如果使用公钥证书进行身份认证，服务端发送Certificate报文（传递自己的证书信息），和Certificate Verify(CV)报文（使用自己的证书私钥对之前的报文进行HMAC签名证明自己持有该证书）给客户端。
- 如果需要对客户端身份进行认证，服务端还需要发送Certificate Request（CR）报文给对方请求客户端发送证书。
- 服务端发送Finished报文。表明服务端到客户端信道的握手阶段结束，理论上不得再由该信道发送任何握手报文。
- 如果客户端收到了服务端的CR报文，返回自己的Certificate报文和CV报文。
- 客户端发送Finished报文，表明握手阶段结束，可以正式开始会话通讯。Finished报文使用会话密钥对上述所有握手信息进行HMAC签名，校验签名可以检验握手阶段的完整性，也可以验证双方是否协商出了一致的密钥。
TLS1.3最大的特点就是对不同的报文使用多种不同的秘钥，TLS1.2中只使用两种秘钥，一个事用于完整性校验，另一个是用于报文加密，同一个连接中不同方向的加密秘钥不一样，TLS1.3使用AEAD机制不再使用MAC_key来进行完整性校验，同时由于其他各种用途的加密需要，TLS1.3的实施过程使用一下几种key：
handshake_key early_traffic_key resumption_key exporter_key（导出秘钥，用户自定义的其他用途）
这些秘钥都是由之前协商的秘钥材料计算而出，区别在于HKDF的计算次数不同，HKDF计算使用的哈希值不同，以会话秘钥application_key为例子，以整个握手阶段的报文作为输入，计算四次HKDF导出最终使用的秘钥，同时，当加密的报文长度达到一定的长度的时候，双方发送的KU报文重新计算application_key
数据发送出去之后，recod层会在密报文头部加上一小段的明文信息来标识解密后明文的长度信息，对方的让recod 层收到消息之后，通过逆过程解密密文后转发给上层协议，
同时TLS1.3协议版本允许在末尾添加八字节整数倍的全为0的二进制数据，对方收到该消息之后，解密从末尾开始去掉0 ，当搜索到第一个不全为0的八字节的时候结束。
总的概括： TLS1.3协议版本 使用的更加 复杂额秘钥导出过程，增强了最终使用秘钥的安全性，同时简化了所使用的加密秘钥，删除了RC4 3DES SHA1 AES-CBC 等加密算法，删除了加密前压缩，重新协商等具有的漏洞，精简了协议 内容，
在TLS1.2中记录协议record，占据一个TLS连接的绝大数的数据流量，
分片，逆向是重组
生成序列号，为每个数据块生成唯一编号，防止被重放或被重排序
压缩，可选步骤，使用握手协议协商出的压缩算法做压缩
加密，使用握手协议协商出来的key做加密/解密
算HMAC，对数据计算HMAC，并且验证收到的数据包的HMAC正确性
发给tcp/ip，把数据发送给 TCP/IP 做传输(或其它ipc机制)。