完整的TLS流

先经过3次TCP握手，然后发tls client hello报文，开始tls握手。

client hello 包：client主动向server打招呼：这个是handshake握手包，版本是1.0，这个包的长度是2019字节；

核心的handshake protocol，字段较多

前面3个：handshake type类型、length长度、version版本。

random：client随机生成一个32字节的数发给server。作用有几个：1）防止重放攻击  2）后续用于完整性校验   3）生成encrypt-key，开始加密应用层数据。

session ID：服务器生成session id，存放本次session协商好的对称密钥。下次通信时，客户端带上session id，server就知道用哪个对称密钥继续加密数据。不过session id有些缺陷，已被session ticket替代。

cipher suites：client列举自己支持的加密套件。前面是非对称加密算法，协商对称算法密钥的；后面都是加密应用数据的对称算法。后续server会根据自己的情况选择合适的加密套件。

extension：有好多分项，都有不同的含义，先看server name，这里访问的是webide。

supported groups：由于安全性和效率问题，tls1.3已经不再使用RSA，而是椭圆曲线。不同的椭圆曲线对应不同的曲线形状，会产生不同的公钥；不同的基点也会导致产生不同的公钥，所以这里有5种不同的椭圆曲线参数供client选择。

session ticket：作用和session id类似，这里还是client hello阶段，这个字段暂时没有值；保留字段，带上空值，也可以向服务器标明client支持session ticket功能。

application layer protocol negotiation：协商tls上层的应用层协议，这里采用的是http1.1协议

key share：client列举出了自己支持的加密套件，并把所有的非对称加密算法的公钥都一并带上，server收到后可以直接根据接受的ECDHE和client的公钥生成自己的公钥和对称密钥。

psk key exchange models：psk_dhe_ke=1，这里双方约定用非对称加密方法ECDHE协商一个对称密钥

supported version：支持的tls版本，tls1.2、tls1.3

pre-shared key：psk本质也是一串ID，这里有113字节，最早是server和client通过tls成功握手后把key和其他一些信息通过HMAC转换后发给client；client后续访问可以直接带上这个PSK，就不用再做密钥协商，节约时间。

其中4个extension是必须的：psk_key_exchange_modes、pre_shared_key、key_share、supported_versions。