SSL和TLS-TLS 1.3
TLS 1.3（版本号3,4）变化很大，比如新的消息流和更强大的加密。
一个典型的SSL/TLS握手需要最少两个RTTs，如果要验证证书，需要更多次（下载和检查CRLs，或者调用OSCP）。2010年，Google介绍和发布了False Start技术，它的思想是客户端发送它的Finished消息之后，立刻开始发送应用数据（不等服务器发送Finished消息），这样节省了一个RTT。但是，该技术碰到了困难，没进入TLS标准。
开始设计TLS 1.3的时候，他们记得TLS False Start，想采用类似的技术减少握手需要的RTTs数。于是，设计了新的消息流。
TLS 1.3只要三次flights就可以建立一个TLS连接。跟TCP连接的建立类似，也需要交换三次消息。
如果和OCSP stapling相结合，可以很快地建立一个安全的连接。第一个flight，客户端发送ClientHello消息以后，立刻发送ClientKeyShare消息。ClientKeyShare消息（type 18）代替了ClientKeyExchange。TLS 1.3不再支持静态key交换，所以每个key交换必须是暂时的。ClientKeyShare消息包含一组参数，客户端支持的0个或者多个key交换方法。如果参数不被接受，或者服务器不支持，服务器就返回HelloRetryRequest消息，客户端就用另一个ClientKeyShare消息重新开始握手。
一旦客户端提供了合适的ClientKeyShare消息，服务器就响应一个ServerHello消息。该消息包含了服务器选择的协议版本、session ID、加密套件、随机数和服务器对客户端的扩展信息的响应。
TLS 1.3和以前的协议不同，服务器的扩展被分成两部分：ServerHello（里边的扩展没加密）和EncryptedExtensions（里边的扩展加密了）。
服务器然后生成它的key材料，发送它的ServerKeyShare消息（type 17）。服务器然后计算共享的secret，发送ChangeCipherSpec消息，
拷贝pending write状态到current write状态。服务器的其他消息，都是用这个key加密的。除了Finished，下来的消息都是可选的：
- 服务器可以发送EncryptedExtensions消息，包含客户端扩展（不是建立key所必须的）的响应。
- 如果需要被认证，在Certificate消息里发送证书。
- 如果服务器发送了CertificateRequest消息，客户端要返回证书
- 如果服务器没被认证，然后它发送CertificateVerify消息，包含所有握手消息的签名。除了显式服务器认证之外，这还提供了握手完整性。
为了完成flight，服务器发送Finished消息。
一旦客户端接收到ServerKeyShare消息，就可以计算premaster secret，派生出master secret和需要的全部key。客户端发送它的ChangeCipherSpec消息，拷贝pending write状态到current write状态。
如果服务器发送了CertificateRequest消息，客户端必须响应一个Certificate消息。该消息可能是空的，没有证书。
如果客户端发送了证书，一个数字签名的CertificateVerify消息也必须发送给服务器（证明私钥是这个证书的）。
最后，客户端发送一个Finished消息。一旦握手完成，客户端和服务器可以开始使用新建立的TLS连接交换应用数据。
Cipher Suites
TLS 1.3不再支持压缩，静态（RSA和DH）key交换，和non-AEAD加密。
- 对于压缩，TLS 1.3的ClientHello消息里的支持方法列表只能是null。如果客户端送了另一个值，服务器必须生成fatal alert：illegal_parameter。
- 对于key交换，TLS 1.3不再支持任何静态方法，例如RSA和DH，总是需要一个暂时的key交换。TLS 1.3只支持DHE和ECDHE。
- 对于加密，TLS 1.3不再支持non-AEAD加密。AEAD加密保护数据的机密性和真实性。AEAD需要key和IVs，可以忽略MAC keys。使用AEAD加密，加密的数据是TLSCompressed（或者TLSPlaintext）结构的fragment，认证的数据包含TLSPlaintext结构的顺序号、type和version属性。
Certificate Management
TLS 1.3继续支持RSA、DSA和ECDSA签名。
Alert Messages
TLS 1.3不支持压缩，不再需要decompression_failure了。