作者回复: great。
作者回复:
1.省去了TLS封装步骤,也就没有了TLS帧头等相关信息,字节数等成本就减少了。
2.HPACK的字典需要双方传输同步,如果有的字典没有传过来就会阻塞,而HTTP/3解决了这个问题。
作者回复: good。
作者回复:
1.队头阻塞在tcp和http层都存在,原因不同。http/2解决了http的队头阻塞,在http层是没有问题了,但在tcp层还有队头阻塞,所以会影响传输效率。
2.一个流就是一个请求响应,它阻塞不会影响其他流,所以不会发生队头阻塞。
3.QUIC有很多优于tcp的新特性,例如连接迁移、多路复用,加密。
4.队头阻塞确实不太好理解,可以再看看之前的课程,结合示意图来加深体会。
作者回复: 和http/2一样,http/3是完全兼容的,因为语义还是保持不变。
作者回复: http/2和http/3确实比较难,不是之前那么简单就能够理解的,多看看,等正式发布之后再实际抓包可能就会好懂了。
作者回复: quic里的流由多个帧组成,这些帧会组合在一个包里,也就是说一个包里会有多个流的帧,但不是一个包就包含了完整的流,而是会有多个包(里面多个帧)然后才能是一个完整的流。
丢包只会丢失部分帧,quic也只会重传这些丢失的帧。
作者回复: 在udp协议之上也可以实现有连接的协议,比如有的公司的自定义协议。
quic底层的udp提供了无连接的基础,但它是有连接的,连接迁移的功能还是quic自己实现的。
作者回复: 是的,quic和tls的关系比较复杂,不是直接的上下级关系,但画图为了“美观”给画成了这样,所以示意图只是“示意”,还是要结合文字来全面理解。
作者回复: 基本正确,udp的各个包之间没有依赖关系,所以就不会出现队头阻塞。
quic里的另一个关键是流概念,它和http/2的一样,把多个请求响应解耦,互不干扰。
这样在上层应用层和下层的传输层就都没有了队头阻塞,但因为丢包而重传该等还是会等,只是不会影响其他的流。
作者回复: Accept-Encoding是请求头,不是响应头。
这些Nginx都会自动处理,不需要我们再做操作。
作者回复: chrome可以用开发者工具看,在27讲里有截图。
作者回复: 传输层就是只负责传输数据,不关心数据的具体内容。
应用层通常不关心数据传输的细节,关心的是如何处理数据,解析数据格式。
作者回复: 公网ip就应该走公网吧,内网ip应该是特殊的内网网段,比如192/10/172什么的。