透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
6077 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (2讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
结束语 (1讲)
结束语 | 做兴趣使然的Hero
透视HTTP协议
登录|注册

32 | 未来之路:HTTP/3展望

Chrono 2019-08-09
在前面的两讲里,我们一起学习了 HTTP/2,你也应该看到了 HTTP/2 做出的许多努力,比如头部压缩、二进制分帧、虚拟的“流”与多路复用,性能方面比 HTTP/1 有了很大的提升,“基本上”解决了“队头阻塞”这个“老大难”问题。

HTTP/2 的“队头阻塞”

等等,你可能要发出疑问了:为什么说是“基本上”,而不是“完全”解决了呢?
这是因为 HTTP/2 虽然使用“帧”“流”“多路复用”,没有了“队头阻塞”,但这些手段都是在应用层里,而在下层,也就是 TCP 协议里,还是会发生“队头阻塞”。
这是怎么回事呢?
让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个“请求 - 响应”分解成流,交给 TCP 后,TCP 会再拆成更小的包依次发送(其实在 TCP 里应该叫 segment,也就是“段”)。
在网络良好的情况下,包可以很快送达目的地。但如果网络质量比较差,像手机上网的时候,就有可能会丢包。而 TCP 为了保证可靠传输,有个特别的“丢包重传”机制,丢失的包必须要等待重新传输确认,其他的包即使已经收到了,也只能放在缓冲区里,上层的应用拿不出来,只能“干着急”。
我举个简单的例子:
客户端用 TCP 发送了三个包,但服务器所在的操作系统只收到了后两个包,第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来,“停下”等着客户端重传那个丢失的包,这样就又出现了“队头阻塞”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

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

    作者回复: great。

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

    作者回复: good。

    2019-08-09
    2
  • 阿锋
    (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.队头阻塞确实不太好理解,可以再看看之前的课程,结合示意图来加深体会。

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

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

    2019-08-09
    1
  • YK_861
    跟不上节奏了呀。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    2019-08-09
收起评论
13
返回
顶部