【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

Google 性能工程师 Ilya Grigorik 谈 HTTP/2

  • 2014-11-12
  • 本文字数:1701 字

    阅读完需:约 6 分钟

HTTP/2,也就是超文本传输协议第 2 版,是下一代 HTTP 协议。该版本是自 1999 年 HTML 1.1 发布后的首个更新,目前它正由互联网工程任务组(IETF)的 Hypertext Transfer Protocol Bis (httpbis) 工作小组进行开发。

对于 HTTP/2,来自于 Google 的性能工程师 Ilya Grigorik最近发布了一个 PPT 对此进行了详细的说明。在该呈现中,Ilya Grigorik 首先提到了一组数据:目前平均每个 Web 页面大约会访问 12 个不同的主机,包含 78 个不同的请求,传输 1232KB 的数据,导致一个页面的渲染时间通常会在 2.6s 至 5.6s 之间。而在渲染占用的整个时间里面,网络大约占 69.5%,JavaScript 占 6.6%,布局占 5.1%,绘制占 4.5%,因此网络传输的效率对整体性能有明显的影响。

Ilya Grigorik 认为 HTTP/1.1 在性能方面有明显的缺陷,主要体现在以下几个方面:

a) 并行能力有限

  • 每一个源最大只支持 6 个请求
  • 管道在实际使用时不起作用
  • 竞争性的 TCP 流,强制快速重传(Spurious retransmissions)
  • 额外的握手、内存缓冲等

b) 客户端请求队列

  • 队首阻塞
  • 延迟的请求分发

c) 较高的协议负载

  • 头信息和 Cookies 大约要 800 字节
  • HTTP 元数据没有压缩

另外,HTTP/1.1 只允许由客户端主动发起请求,服务端只能等待客户端发送请求,这对于满足预加载的现状是一种桎梏。

针对这些问题,虽然我们可以通过一些变通的方法进行处理,但是这不可避免的会引发另外的问题。例如,针对请求数的限制我们可以把多个小文件打包到一个大文件中,但是由于并不是每一个页面都需要所有的小文件,所以这样做会造成带宽的浪费。那么 HTTP/2 是否能够帮助我们解决这些问题呢?它都包含哪些内容呢?

实际上 HTTP/2 是为了在万维网上进行低延迟的数据传输而设计的一个协议,它提供了 HTTP 语义的传输优化,支持 HTTP/1.1 的所有核心特征,并且在其他方面做的更高效。在 HTTP/2 中,基本的协议单位是帧,每个帧都有不同的类型和用途。例如,报头 (HEADERS) 和数据 (DATA) 帧组成了基本的 HTTP 请求和响应;其他帧,例如设置 (SETTINGS) 和推送承诺 (PUSH_PROMISE) 则用来实现 HTTP/2 的其他功能。

HTTP/2 基于 SPDY 协议,充分解决了 TCP 连接的限制。它允许多个并发 HTTP 请求共用一个 TCP 会话,而不是为每个请求单独开放连接,这样只需建立一个 TCP 连接就可以传送网页上所有资源,不仅可以减少消息交互往返的时间还可以避免创建新连接造成的延迟,使得 TCP 的效率更高。

针对只能由客户端发起请求的问题,HTTP/2 添加了一种新的交互模式,即服务器能够通过复用一个以 PUSH_PROMISE 帧发送的请求来实现推送。而对于数据冗余问题,在 HTTP/2 中帧包含的 HTTP 报头字段是压缩的,同时它还舍弃掉了不必要的头信息,因此能显著地减少请求和响应的大小。

如果你想了解与 HTTP/2 相关的更多信息,可以查看百度阅读提供的HTTP/2 中文版

对于Ilya Grigorik 所分享的内容 Hacker News 社区上也有一些人发表了自己的看法, byuu 认为:

首先 Firefox 以及一些其他的浏览器只能在 TLS 上使用 HTTP/2 ,这对很多人而言是一种阻碍。虽然加密非常好,但是 SSL 证书可能需要一定的成本以及额外的 CPU 资源。其次,使用一种新的、自定义的压缩算法对头信息进行处理并不一定合适,因为如果头信息只有 300 字节的数据,那么压缩数据所带来的带宽收益并不一定会比它所消耗的 CPU 成本高,况且这样还增加了程序的复杂性。最后,byuu 认为新协议可能会改变我们既有 Web 网站的工作方式,如果优化做的不好,那么性能可能会比 HTTP/1.1 更糟,同时兼容性也会阻碍大家对 HTTP/2 的采纳。

kator 则从另一个角度发表了自己的看法:

“我并不怀疑这里有大量可提升的空间,很明显 HTTP/2 有很多内容来自于 SPDY 以及其他的一些项目。我担心的是我们现在正在做的事情对那些可以将所有内容塞到一个流中的大公司而言有巨大好处,而对于小公司而言则更多的是劣势。另外,作为一个老家伙,我担心人们会丢失与这些服务对话,或者以文本的方式查看对话的能力。”


感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-11-12 00:385974
用户头像

发布了 321 篇内容, 共 115.9 次阅读, 收获喜欢 18 次。

关注

评论 1 条评论

发布
用户头像
Ilya Grigorik
2023-12-24 01:25 · 上海
回复
没有更多了
发现更多内容

NUCLEO-L432KC实现UART1、UART2双串口数据通信(STM32L432KC)

不脱发的程序猿

嵌入式 stm32 单片机 NUCLEO-L432KC 串口通信

阿里开源:历年亿级活动高并发系统设计场景总结

Java架构师迁哥

网格策略交易软件,量化马丁倍投交易机器人

实测Tengine开源的Dubbo功能

捉虫大师

dubbo 网关 tengine

Flume自定义拦截器

大数据技术指南

大数据 5月日更

MySQL 数据库救火:磁盘爆满了,怎么办?

华为云开发者联盟

数据库 磁盘 MySQL 数据库 日志文件 磁盘爆满

电子产品PCB电路板散热的方法

不脱发的程序猿

嵌入式 PCB 电路板散热 电子电路 电路板

《复仇者联盟》AI换脸平台

不脱发的程序猿

人工智能 开源 AI 复仇者联盟

☕️【Java 技术之旅】带你看透Lambda表达式的底层

洛神灬殇

Java Lambda 底层原理 5月日更 行为参数化

【大咖直播】Elastic 可观测性实战工作坊

腾讯云大数据

elastic

视频门禁的优点及应用场景

anyRTC开发者

音视频 WebRTC RTC sdk

请警惕 ES 的三大坑

悟空聊架构

elasticsearch 架构 分布式 微服务 ES

突击 22 天面进腾讯,给到 32K*14 薪!全靠这份阿里面试参考指南了

Java 程序员 架构 面试 计算机

合作伙伴眼中的HarmonyOS 专访方太智能厨电专家俞贵涛

科技汇

最佳入门系列 | 何为服务网关?

架构精进之路

微服务 5月日更

网络攻防学习笔记 Day27

穿过生命散发芬芳

5月日更 网络攻防

Logo设计软件 Tech Support

凌天一击

【多线程与高并发】从一则招聘信息进入多线程的世界

牧小农

Java 多线程与高并发

可视化突破海绵城市发展困境,智慧城市从“一张图”开始

一只数据鲸鱼

数据可视化 智慧城市 智慧水务 三维可视化 海绵城市

终于看到阿里大牛能把springboot讲的如此出神入化

Java 程序员 架构 计算机

聊聊微服务治理的落地问题 | Geek大咖说第二期

百度Geek说

微服务 自动化

BI系统里的数据赋能与业务决策

薄荷点点

数据产品经理 决策 BI 数据驱动 风险识别

索信达控股:金融机构如何打造最适合自己的个性化推荐系统?

索信达控股

大数据 金融科技 金融 个性化推荐 营销数字化

哈工大与华为终端有限公司签署首个HarmonyOS高校协同育人合作协议

科技汇

Flink的批数据SQL

五分钟学大数据

flink 5月日更

VSCode 无鼠标操作快捷键对比Atom

追风的少年

GitHub开源14.5万行阿波罗11号源代码

不脱发的程序猿

GitHub 开源 阿波罗11号

集成学习中的随机森林

华为云开发者联盟

机器学习 决策树 随机森林 集成学习 Bagging

为什么你的Docker容器刚启动就停了?

运维研习社

Docker Linux 5月日更

阿里云联合中国信通院发布《云计算开放应用架构》标准,加速云原生应用规模化落地进程

阿里巴巴云原生

容器 开发者 运维 云原生 k8s

OCR性能优化:从神经网络到橡皮泥

华为云开发者联盟

神经网络 机器学习 OCR 橡皮泥 CNN网络

Google性能工程师Ilya Grigorik谈HTTP/2_语言 & 开发_孙镜涛_InfoQ精选文章