https TLS handshake ### bytedance

[diveDylan]

如何理解TLS加密握手 1、客户端发起TLS握手，发送TLS版本信息，支持的加密算法和一个生产的随机数（A，client key) 2、服务端确认加密算法，发送SSL证书信息内部包含public key，生成一个随机数(B, server key） 3、客户端验证服务端证书信息，进行授权，通过publick key 生成一个随机数（C，premaster secret），通过ABC三个随机数生成一个会话级别的随机数（客户端和服务端一样的session key) 4、服务端用private key解密随机数C，确认客户端信息。通过ABC三个随机数生成一个会话级别的随机数（客户端和服务端一样的session key) 5、客户端发送一条由session key加密的Client ready信息 6、服务端确认客户端信息，发送一条由session key 加密的Server ready信息

[diveDylan]

 ssl RSA: 目前主要采用
☐ client -> server Random NumberA 支持的证书版本
☐ server-> client Random Number B 选择的证书和公钥
☐ 客户端收到Random Number B 就能生成 premaster_secrect C, A+B+C => 生成master_secret
☐ client -> server 使用公钥证书将premaster_secrect加密发送给服务器
☐ server 通过私钥解密premaster_secrect，通过相同算法使用A+B+C得到master_secret

ssl DH和ecc:
  ☐ client选择自己的私钥A，通过私钥计算出公钥B，将公钥发送给服务端
  ☐ 服务端选择自己的私钥C，通过私钥得到公钥D，将公钥发送给客户端，并通过客户端公钥和服务端私钥算出共用会话密钥
  ☐ 客户端收到服务端返回的公钥，通过自己的私钥和服务端的公钥计算出共用会话密钥

[diveDylan]

http2: ☐ 报文中header 和data 通过换行回车换行符区分 ☐ 将http链接拆分成Data流和header流， 流内部数据通过帧保持原有顺序，每个流会有独特的流Id，保证流可以无序发送，通过建立时返回的setting帧的 max concurrent stream 得到最大的并发流数 HPACK压缩算法: ☐ 1、header中将常用的header处理成静态字典 ☐ 2、可以作为动态字典的键值对会使用动态字典 比如：userAgent、host动态键值为62，63，这两个基本不对只需要首次传输完整key-value后续之间传标志位62，63 ☐ 3、无法处理header最终会通过霍夫曼编码方式压缩 流量控制: http2一般建立一个tcp链接阻塞会阻塞整个通道 ☐ 避免触发tcp的对头阻塞，引起整个流管道的阻塞 ☐ 客户端和服务端都有自己的流量控制策略 ☐ 流量控制只针对data流，不针对header、push ☐ 通过window_update字段标志进行流量控制 Server Push: ☐ 主动向客户端推送资源的能力 ☐ 单页面应用中： client =》 ngnix server =》html =》 fetch css &js @push client =》 ngnix server =》 html =》css & js （from push）

[diveDylan]

 HTTP3 Quick协议:
 ☐ 简化 TLS 的握手流程，降低首次 0/1RTT， 采用迪夫霍夫曼算法握手，公钥长期即可0RTT
 ☐ 采用多流策略，某个流的队头阻塞不会引起另外一个流的数据阻塞
 ☐ 采用多流设计，单流丢失不影响其他流数据，针对到流的阻塞控制
 ☐ 拥塞控制需要对单个链接和流分别进行控制
 ☐ Quick协议允许客户端和服务端协商拥塞控制算法，默认为 TCP 协议的 Cubic 拥塞控制算法
 ☐ 支持动态连接迁移：手机wifi切换成蜂窝数据或者设备链接vpn的时候ip变更需要冲新建立TCP链接
  ☐ QUIC不通过伪首部（ip，端口，目标ip，目标端口）进行链接标识，通过算法得到64位UUID标记整个链接，即使IP变更也无需重新建立链接