标签：协议 p1 重传 TCP 发送 Http3.0 QUIC Http2.0
1. http2.0，或许是一个过渡协议
a. 它兼容1.1版本，2015年左右发布，目前部分知名网站已经开始使用，它依然基于TCP协议，主要focus on performance。
b. 很多请求都是头部很多内容，实际传输的内容很少，所以http2.0做了头部压缩。不过 HTTP/2 并没有使用传统的压缩算法，而是开发了专门的“HPACK”算法，“HPACK”算法是专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，也可以说是“字典”（这有点类似 brotli），压缩和解压缩就是查表和更新表的操作
- 这里注意http2中没有请求/响应行的概念了，都抽象为虚拟头，与其他头部一起放到索引表中管理。常见的头放到静态表中，新增的头，放到动态表中。
- 比如说，第一次发送请求时的“user-agent”字段长是一百多个字节，用哈夫曼（第一次这个内容还是全量的，所以需要说有哈夫曼编码压缩）压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好。
c. 二进制方式传输，（注意这里并没有加密），它把 TCP 协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。
d. 虚拟流的概念
- HTTP/2 为此定义了一个“流”（Stream）的概念，它是二进制帧乱序的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID。多个请求对应多个流ID，从而实现多路复用的目的，所以不需要保持多个TCP链接，server端响应能力更好，以前需要为每一个客户端维持6个TCP的状态信息，现在只需要一个即可。
- 流还可以设置优先级，比如有些关键资源（js，css）可以优先发送
- HTTP/2 还在一定程度上改变了传统的“请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息，一定程度的双工。
- 多个请求对应多个流ID，不在是以前的串行发送了，可以一起发送，某个流的数据包全部收到了之后，就可以组装给上层应用使用了。某个流的数据被卡住或者丢包重串，不影响其他流，这就在应用层解决了对头阻塞的问题（注意这里TCP的阻塞依然存在）
e. 2015年发布http2的时候，TLS1.3还没有发布，所以只要求使用使用TLS1.2以上的协议，默认比1.1要求的更高，默认需要使用https加密传输。
注意：
http1.1里面的一些优化手段，对于2.0来说，可能起到反作用。比如合并js，css，雪碧图等。因为过大的文件，容易导致缓存失效，其他一个单元修改了，整个缓存就得重新获取。
更多的TCP连接，也对server端不友好，更小的资料，往往会很快会被使用，给好的UI体现。
2. Http3.0，真正的下一代可靠的高速应用层通信技术
a. http2中始终在使用TCP协议，所以无论如何都还是会有tcp传输层的对头阻塞问题，而http3彻底解决对头阻塞的问题，正式版本还没有发布。
- 让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个“请求 - 响应”分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是“段”）。在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能“干着急”。比如这个流有3个包，现在收到了2个包，还有一个包没有收到，就会一直等，超时后还会要求重传。
- 在比如，这里有2个请求，就会有2个stream，我们假定他们编号是stream1，stream2，然后stream1被TCP拆分为p1-1，p1-2，p1-3，共3个包，stream2被TCP拆分出p2-1，p2-2 两个包。流拆包时可能时乱顺（可能会有优先级）给TCP传输的，比如p1-1，p1-2，p2-1，p1-3，p2-2的顺序。这样假如网络不好在传p1-3时候，一直没有收到确认收到的ACK消息，就会一直等，可能等到超时重传p1-3，这样p2-2就一直不能传输，而p2-1就只能呆在缓存区静静的等待，就导致了阻塞。
b. 所以google又（google在web协议发展中，总是领先推出一些协议，成为既定事实，在由标准化组织给他正名，写入RFC）重新推了QUIC协议，彻底放弃使用TCP协议，而使用基于UDP的QUIC协议。
c. UDP协议不需要3次握手和4次挥手，所以天然比TCP协议快。
d. 同时2018年TLS1.3版本发布，可以获取更好的加密性能。QUIC 内含了 TLS1.3，只能加密通信，支持 0-RTT 快速建连；
e. QUIC协议自定义了连接机制，在IP地址发送变化，只要双方的通信Id没变，就会保持连接，特别适合移动互联网的应用场景， 不会像tcp那样不能变ip和port，如果变了就要重新建立耗时的TCP连接。
f. QUIC自定义重传机制，由于TCP重传机制算法不够优秀，往往不准确超时时间，所以QUIC使用自增ID计算，更好的计算出了重传时间。
g. 离开了TCP的底层重传，流之间没有依赖，包之间没有依赖，真正实现了多路复用，告诉传输数据。
h. 自定义流量控制，采用滑动窗口协议与http2相同。
标签：协议,p1,重传,TCP,发送,Http3.0,QUIC,Http2.0 来源： https://www.cnblogs.com/roy1/p/13721842.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。