RTT握手、可靠传输与多路复用

接收端根据 offset 字段就可以对异步到达的数据包进行排序了。

HTTP/2 能实现多路复用的根本原因是采用了二进制帧格式的数据结构， QUIC 全称Quick UDP Internet Connections是一种基于 UDP 的传输层协议。

TLS 握手密钥协商1.3 版本 从图中可以看出TLS 握手需要 1 个 RTT也就是 1 次 RTT 就把通信密钥协商好了这是怎么做到的 1客户端生成随机数 a选择公开的大数 G 和 P计算 Aa*G%P将 A 和 G 发送给服务器也就是 Client Hello 消息 2服务器生成随机数 b计算 Bb*G%P将 B 发送给客户端也就是 Server Hello 消息 3客户端使用 ECDH 算法生成通信密钥 KEY aB ab*G%P 4服务器使用 ECDH 算法生成通信密钥 KEY bA ba*G%P 所以这里的关键就是 ECDH 算法a 和 b 是客户端和服务器的私钥是不公开的而其他参数是公开的， 2.5.5、常见算法 New Reno基于丢包检测 CUBIC基于丢包检测 BBR基于网络带宽 和 TCP 不同的是QUIC 是在用户空间实现的拥塞控制可以非常灵活的设置甚至可以为每一个请求都设置一种拥塞控制算法，那拥塞窗口的大小是如何计算的通过 4 个拥塞控制算法慢启动、拥塞避免、拥塞发生、快速恢复 2.5.1、慢启动 初始拥塞窗口大小 cwnd1也就是可以传输 1 个 MDSMax Datagram Size大小的数据包一般网卡允许传输的最大数据单元 MTU 的大小是 1500 字节，因为 TCP 的连接基于 4 元组源 IP、源端口、目的 IP、目的端口只要其中 1 个发生变化就需要重新建立连接，但是对于每个请求流而言也是存在队头阻塞问题的也就是说虽然 QUIC 解决了 TCP 层的队头阻塞但仍然存在单条流上的队头阻塞， 从协议栈可以看出QUIC HTTP/2 TLS UDP 2、QUIC 实现原理 2.1、数据格式 一个 QUIC 数据包的格式如下 由 header 和 data 两部分组成， HTTP/2 虽然通过多路复用解决了 HTTP 层的队头阻塞但仍然存在 TCP 层的队头阻塞，后面的流量控制和多路复用会涉及到 **Offset**偏移量表示该数据包在整个数据中的偏移量用于数据排序， 假设客户端先使用 IP1 发送了 1 和 2 数据包之后切换网络IP 变更为 IP2发送了 3 和 4 数据包服务器根据数据包头部的 Connection ID 字段可以判断这 4 个包是来自于同一个客户端， Frame Type  帧类型占用 1 个字节 1Bit7必须设置为 1表示 Stream 帧 2Bit6如果设置为 1表示发送端在这个 stream 上已经结束发送数据流将处于半关闭状态 3Bit5如果设置为 1表示 Stream 头中包含 Data length 字段 4Bit432表示 offset 的长度。

Data Length  数据长度占用 2 个字节表示实际应用数据的长度 Data  实际的应用数据 2.2、建立连接 先分析下 HTTPS 的握手过程包含 TCP 握手和 TLS 握手TCP 握手 从图中可以看出TCP 握手需要 2 个 RTT， Length表示 Payload 的长度 Type表示帧类型 Flags帧标识 Stream ID数据帧所属的流 Payload应用数据长度由 Length 字段指定 一个请求就对应一条流通过 Stream ID 就可以判断该数据帧属于哪个请求假设有 A 和 B 两个请求对应的 Stream ID 分别为 1 和 2那这个 TCP 连接上传输的数据大概如下 虽然在 HTTP 应用层可以同时发送多个请求但是在 TCP 传输层仍然只有 1 个滑动窗口来发送这些数据包考虑下面的情形