HTTP3协议
1.解决对头阻塞问题
2.Hands-on with quic in wireshark
2.1 客户端发送Initial给服务器
可以看到有两个 quic的payload，通常第二个数据包只是填充(Padding)，将这个数据包填充到1399的长度
接着打开第一个quic的payload，可以看到这是一个长头包，定义了quic的版本是draft-29。
接着就是连接目的端口长度和连接目的ID，连接源端口和连接源ID，这个是客户端最初将如何识别这个唯一的QUIC连接，在某种意义上，这几乎就像使用TCP的端口号一样
在这个package中，我们同样可以看到TLS1.3的client，在TCP中，我们首先是建立三次握手，其次才会发送TLS 1.3的client hello报文，但是在quic中，我们能够立即使用第一个数据包发送它
quic_transport_parameters和tcp中的syn报文类似，我们如何向服务器提供选项，然后服务器回复它的选项
initial_max_stream_data_uni和initial_max_stream_data_bidi_local表示单向还是双向流，我们可以在quic对话中支持多大16个流（通过initial_max_stream_uni和initial_max_streams_bidi确定）。
2.2 服务器发送Initial给客户端
和客户端发给服务器类似的部分就不多介绍，可见服务器回复给客户端的有ACK帧，并且largest acknowledged: 0,表示客户端发送的第一个包的pkn: 0已经确认收到
3.Analyzing Quic with Wireshark
3.1 quic如何开始
首先端侧不知道服务器侧是否支持quic协议，还是按照正常的TCP三次握手，TLS握手，在服务器回复响应头的header中，如下图的302 FOUND，在alt-svc中，会告诉客户端，我支持quic协议，这样下次通信过程中，端侧才会开始发送quic报文
3.2 quic Handshake
类似TCP讲解：
- 首先客户端发送Initial包给服务器，包含如何和服务器建立连接的相关信息。
- 服务器根据客户端发来的连接信息，做出响应
- 握手结束，客户端开始发送请求给服务器
详细讲解：
- 客户端首次发送initial包，内嵌了TLS的client hello包，并且携带了一些transport parameters，并使用长头包来确认连接，此外还携带了应用层参数ALPN告诉服务器将使用HTTP3
- 服务器回复Initial包，内嵌TLS的Server hello包
- 服务器回复Handshake包，此数据包已经被加密了，并且内嵌了TLS的setup instruction，ALPN信息，以及ACK帧等信息
- 客户端回复Handshake finsh信息
关注点：当前所有支持TLS 1.3的端侧，在client hello中，Version版本都是TLS 1.2，而在扩展字段中supported_versions中标明了明确的版本，这么做的原因是：这个是为了通过尚未支持TLS 1.3的防火墙设备和中间设备。
在wireshark中的4,5包中，Handshake都是发送 Certificate包（被fragment了），然后在6包中进行证书校验，服务器结束handshake。接着客户端在8包中结束handshake。
4.Quic connections and Streams
1.每个quic连接有一个独一无二的ID，在发送initial包的时候，除非之前有过连接记录，否则发送一个连接ID给服务器，其为由八个字节构成的不可预测的值。
2.quic流：下图是一个UDP对应的一个QUIC连接，quic连接下面有四个stream
正在上传…重新上传取消
5.Quic Packets VS Frames
5.1 packet
传统意义上的packet如下图所示：frames代表的是以太网帧和有效荷载，所以这将是从以太网帧的边缘一直到帧检查序列末尾
in QUIC：QUIC包被封装在UDP报文里面，然后帧被定义封装在quic包里面，所以帧在quic连接中具有不同的功能。举例：包含加密的crypto帧，ACK帧等。现在quic还允许将多个数据包封装在一个UDP数据包中，这可以充分利用可用空间，并提高效率
6. Demo：Analyzing Quic connection/stream/packet
6.1 quic connection
客户端发送的initial包是一个long header，这样做的原因是因为它将完全识别目标ID和源连接ID。客户端发送一个八字节的Destination Connection ID，任何被动监听器都无法根据此信息确定应用程序（FTP,TCP,SSH...）
连接建立好，数据开始传输的包是number 9，可以看到这次是一个short header，仅仅包括了一个Destination CID。所以现在即使IP和端口发生了变化，quic连接可能仍然存在于这两个端点之间。 
6.2 Quic Stream
从package Number 7可以看到，流ID是3（流ID为奇数是，代表的是服务器发送的数据），并且是一个uni=1，代表是一个单向流，然后服务器可以将内容放入 该流中，在这个数据包中，很明显只有一条流，
从Package Number9中可以看到，quic连接上有三条流，并且都是单向流，流ID分别是2,6,10（因为是客户端发送的，所以流ID都是偶数），如果流数据丢失了，那么一方或者另一方可以主动传输丢失的数据流，因此只要丢了一个QUIC数据包，不需要重传所有流，只需要重传数据包丢失的所在流。
7.quic问题公关
7.1 通用问题
1.客户端和服务器支持版本不一致，这样就会退化为tcp
2.如果客户端支持服务器版本中的任何一个，连接将继续，这个时候quic可能遇到另外一个问题，网络路径上的基础设备和安全监测系统，如下图所示，中间的任何一个设备，都可能会存在问题，因为之前主要公关的就是适配TCP，使用UDP可能存在意想不到的问题。
7.2 测试quic工具
1.在线工具(https://http3check.net)
可以监测服务器是否支持quic，以及支持的版本信息等
2.进入开发者模式，更多工具->开发者模式
3.通过命令行工具，curl -http3 host
7.3 确认丢包场景
从图中可以看到，单方向上传输的包都是递增的，快速确认丢包场景可以从包的递增来查看，更方便的是，我们可以通过file->Export Package Dissections->as CSV，然后在excel表中通过差值来判断。