• 许童童
    2019-08-09
    IP 协议要比 UDP 协议省去 8 个字节的成本,也更通用,QUIC 为什么不构建在 IP 协议之上呢?
    直接利用UDP,兼容性好。
    说一说你理解的 QUIC、HTTP/3 的好处。
    彻底解决队头阻塞,用户态定义流量控制、拥塞避免等算法,优化慢启动、弱网、重建连接等问题。
    对比一下 HTTP/3 和 HTTP/2 各自的流、帧,有什么相同点和不同点。
    HTTP/3在QUIC层定义流、帧,真正解决队头阻塞,HTTP/2流、帧是在TCP层上抽象出的逻辑概念。
    相同点是在逻辑理解上是基本一致的,流由帧组成,多个流可以并发传输互不影响。
    展开

    作者回复: great。

    
     5
  • Flourishing
    2019-12-25
    老师,以下问题,麻烦回答一下,谢谢:

    1.它使用自己的帧“接管”了 TLS 里的“记录”,握手消息、警报消息都不使用 TLS 记录,直接封装成 QUIC 的帧发送,省掉了一次开销。省掉的一次开销是什么?

    2.解决了 HPACK 的“队头阻塞”问题。 没明白这句话。

    作者回复:
    1.省去了TLS封装步骤,也就没有了TLS帧头等相关信息,字节数等成本就减少了。

    2.HPACK的字典需要双方传输同步,如果有的字典没有传过来就会阻塞,而HTTP/3解决了这个问题。

    
     2
  • -W.LI-
    2019-08-09
    1.传输层TCP和UDP就够了,在多加会提高复杂度,基于UDP向前兼容会好一些。
    2.在传输层解决了队首阻塞,基于UDP协议,在网络拥堵的情况下,提高传输效率
    3.http3在传输层基于UDP真正解决了队头阻塞。http2只是部分解决。

    作者回复: good。

    
     2
  • 阿锋
    2019-08-09
    (1)http的队头阻塞,和tcp的队头阻塞,怎么理解 ?是由于tcp队头阻塞导致http对头阻塞,还是http本身的实现就会造成队头阻塞,还是都有。感觉有点模糊?
    (2)看完了QUIC,其流内部还是会产生队头阻塞,感觉没啥区别,QUIC内部还不是要实现tcp的重传那一套东西。QUIC没看出来比tcp好在哪里。
    (3)队头阻塞在http,tcp,流等这几个概念中是怎么理解和区分的,很迷惑。

    作者回复:
    1.队头阻塞在tcp和http层都存在,原因不同。http/2解决了http的队头阻塞,在http层是没有问题了,但在tcp层还有队头阻塞,所以会影响传输效率。

    2.一个流就是一个请求响应,它阻塞不会影响其他流,所以不会发生队头阻塞。

    3.QUIC有很多优于tcp的新特性,例如连接迁移、多路复用,加密。

    4.队头阻塞确实不太好理解,可以再看看之前的课程,结合示意图来加深体会。

    
     1
  • QQ怪
    2019-08-09
    老师能否分享下要更新换代http3,其上层的服务协议是否也要更新还是都能够兼容?

    作者回复: 和http/2一样,http/3是完全兼容的,因为语义还是保持不变。

    
     1
  • YK_861
    2019-10-31
    跟不上节奏了呀。

    作者回复: http/2和http/3确实比较难,不是之前那么简单就能够理解的,多看看,等正式发布之后再实际抓包可能就会好懂了。

    
    
  • 酸奶啊火龙果
    2019-10-22
    老师,文中有一张包的结构图,Quic Package Payload 里面说『实际传输的数据是多个帧构成的流』,这里怎么理解呢?
    是这样吗,Quic里面有帧、流、包的概念,流上传输的是帧,Quic是把多个流结合为包然后传递给UDP吗,因为每个流是一个消息,丢包的时候会一次丢多个消息吗

    作者回复: quic里的流由多个帧组成,这些帧会组合在一个包里,也就是说一个包里会有多个流的帧,但不是一个包就包含了完整的流,而是会有多个包(里面多个帧)然后才能是一个完整的流。

    丢包只会丢失部分帧,quic也只会重传这些丢失的帧。

    
    
  • moooofly
    2019-08-31
    “下班回家,手机会自动由 4G 切换到 WiFi。这时 IP 地址会发生变化,TCP 就必须重新建立连接。而 QUIC 连接里的两端连接 ID 不会变,所以连接在“逻辑上”没有中断,它就可以在新的 IP 地址上继续使用之前的连接,消除重连的成本,实现连接的无缝迁移”,我觉得这里是不是应该强调一下,QUIC 是基于无连接概念的 UDP 协议,因此也就没有所谓的“中断”和“重连”概念,进而才能实现在新的 ip 地址上的无缝迁移;

    作者回复: 在udp协议之上也可以实现有连接的协议,比如有的公司的自定义协议。

    quic底层的udp提供了无连接的基础,但它是有连接的,连接迁移的功能还是quic自己实现的。

    
    
  • moooofly
    2019-08-31
    一个小建议:既然 TLS1.3 是被“包含”在 QUIC 协议中的,那么文章中给出的 HTTP/3 协议栈图,就有点容易让人产生误会,图示给人的感觉是 QUIC 和 TLS1.3 是一个级别的对等存在,让人感觉 QPack 是基于 QUIC 的,而 Stream 是基于 TLS1.3 实现的

    作者回复: 是的,quic和tls的关系比较复杂,不是直接的上下级关系,但画图为了“美观”给画成了这样,所以示意图只是“示意”,还是要结合文字来全面理解。

    
    
  • moooofly
    2019-08-31
    我是不是可以这样理解,QUIC 之所以解决了队头阻塞,是基于UDP的乱序,无连接,以包为单位进行传出的特性,即当发生丢包时,当前流中对应的请求或应答就彻底“丢失”了,之后只需要通过在UDP基础实现的“可靠传输”功能,重传就好了,这样就避免了接收端死等尚未接收到的数据的“干着急”状态;

    作者回复: 基本正确,udp的各个包之间没有依赖关系,所以就不会出现队头阻塞。

    quic里的另一个关键是流概念,它和http/2的一样,把多个请求响应解耦,互不干扰。

    这样在上层应用层和下层的传输层就都没有了队头阻塞,但因为丢包而重传该等还是会等,只是不会影响其他的流。

    
    
  • -W.LI-
    2019-08-09
    老师好!能问个关于nginx的问题么?
    nginx配置gzip on;
    后还需要在http头里加
    accept encoding :gzip么?
    然后还需要再header头里添加,Accept-Encoding :gzip么?

    作者回复: Accept-Encoding是请求头,不是响应头。

    这些Nginx都会自动处理,不需要我们再做操作。

    
    
  • sunözil
    2019-08-09
    老师,针对HTTPS章节,如何查看非实验环境的密码套件呢?

    作者回复: chrome可以用开发者工具看,在27讲里有截图。

    
    
  • -W.LI-
    2019-08-09
    老师好!
    协议处在哪一次有什么划分标准么?
    mac层和ip成感觉一般不怎么会变
    传输层和应用层搞不太清楚

    作者回复: 传输层就是只负责传输数据,不关心数据的具体内容。

    应用层通常不关心数据传输的细节,关心的是如何处理数据,解析数据格式。

    
    
  • -W.LI-
    2019-08-09
    老师好!我问个问题
    我们有两个内网服务服务A要调用服务B
    A调用B的时候是用的B的外网域名。这两个服务对外的公网IP是一个。
    DNS解析的时候A发现B和自己是同一个公网IP,然后是不是会直接走内网调用啊?感觉去外网绕一圈,也绕不出啊。

    作者回复: 公网ip就应该走公网吧,内网ip应该是特殊的内网网段,比如192/10/172什么的。

    
    
我们在线,来聊聊吧