问题1：quic握手过程是怎样的？ 怎样节约握手时间？握手时间多少个RTT？握手过程成涉及到哪些概念以及变量（代码）
0~1 RTT握手过程
QUIC握手的过程是需要一次数据交互，0-RTT时延即可完成握手过程中的密钥协商，比TLS相比效率提高了3-5倍，且具有更高的安全性。
QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。
初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。
具体握手过程如下：
(1) 客户端判断本地是否已有服务器的全部配置参数，如果有则直接跳转到(5)，否则继续
(2) 客户端向服务器发送inchoate client hello(CHLO)消息，请求服务器传输配置参数
(3) 服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数
(4) 客户端收到REJ，提取并存储服务器配置参数，跳回到(1)
(5) 客户端向服务器发送full client hello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户
端根据获取的服务器配置参数和自己选择的公开数，可以计算出初始密钥。
(6) 服务器收到full client hello，如果不同意连接就回复REJ，同(3)；如果同意连接，根据客户端的公开数
计算出初始密钥，回复server hello(SHLO)消息，SHLO用初始密钥加密，并且其中包含服务器选择的一个临时公开数。
(7) 客户端收到服务器的回复，如果是REJ则情况同(4)；如果是SHLO，则尝试用初始密钥解密，提取出临时公开数
(8) 客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥
(9) 双方更换为使用会话密钥通信，初始密钥此时已无用，QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似，
只是数据包中的某些字段略有不同。
- QUIC has the following default flow control values (fromChromium’s quic_protocol.h ）：
// Minimum size of initial flow control window, for both stream and session.
const uint32 kMinimumFlowControlSendWindow = 16 * 1024; // 16 KB
// Maximum flow control receive window limits for connection and stream.
const QuicByteCount kStreamReceiveWindowLimit = 16 * 1024 * 1024 ; // 16MB
const QuicByteCount kSessionReceiveWindowLimit = 24 * 1024 * 1024 ; // 24MB
- 16 KB minimum value is necessary to allow 0-RTT requests with bodies. Current implementations will advertise much larger windows during the handshake, via the kSFCW (Stream Flow Control Window) and kCFCW (Connection Flow Control Window) tags in the CHLO and SHLO.