写点什么

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:386161
用户头像

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

关注

评论 1 条评论

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

ios工具合集 4Easysoft iOS Toolkit 激活中文版最新

mac大玩家j

ios Mac软件

2023年度项目深入探索:AI与大模型在实际应用中的全景

数字扫地僧

盘点那些国际知名的黑客(下篇)

禅道项目管理

互联网 黑客 计算机网络

如何实现高效代码审查,赋能大规模开发

龙智—DevSecOps解决方案

代码审查

法律情境扮演、逆向推理文字游戏、AIGC创作……见证AI极致生产力!

飞桨PaddlePaddle

人工智能 AIGC

手把手带你离线部署Walrus,体验极简应用交付

SEAL安全

应用交付 应用交付平台 12 月 PK 榜 Walrus

KubeWharf:基于Kubernetes的分布式操作系统,助力云原生化部署和管理

bug菌

Kubernetes 社区征文

NFTScan | 11.27~12.03 NFT 市场热点汇总

NFT Research

NFT NFT\ NFTScan

亚马逊云科技宣布推出四项Zero-ETL集成特性

财见

关于Nuxt.js 服务端组件的使用

秃头小帅oi

给 Web 前端工程师看的用 Rust 开发 wasm 组件实战 | 京东云技术团队

京东科技开发者

rust 前端 webassembly 前端组件

Wireshark中的ICMP协议包分析

小魏写代码

KubeWharf:解析云原生未来的分布式操作系统

数字扫地僧

KubeWharf

MYSQL EXPLAIN 执行计划 | 京东物流技术团队

京东科技开发者

MySQL 数据库 EXPLAIN EXPLAIN执行计划

Dapp燃烧铸币模式系统开发丨智能合约技术开发

l8l259l3365

原来低代码开发部署起来这么简单

伤感汤姆布利柏

前端 低代码 低代码开发

DevSecOps研讨会年终专场来啦!邀您共探如何打好DevOps基础,赋能创新

龙智—DevSecOps解决方案

HarmonyOS振动效果开发指导

HarmonyOS开发者

HarmonyOS

京东商品详情接口在电商行业中的重要性及实时数据获取实现

Noah

数据“库”的增删改查

小齐写代码

一次讲清楚京东科技百亿级用户画像平台的探索和实践 | 京东云技术团队

京东科技开发者

数据库 Clickhouse 用户画像 用户画像平台

如何通过追踪用户旅程,找到流失用户

Footprint Analytics

区块链游戏 Web 3.0

深度探索E3PO:360° 视频传输平台的前沿技术与应用

数字扫地僧

E3PO

【高效视频处理】体验火山引擎多媒体处理框架 BMF

数字扫地僧

BMF

智能LED屏幕未来升级方向

Dylan

个性化 定制化 LED显示屏 全彩LED显示屏 led显示屏厂家

【FAQ】运动健康服务端侧数据常见问题及解答

HarmonyOS SDK

HMS Core

优化开发者体验,推动API测试行业发展,SmartBear收购API设计和文档领域领导者Stoplight

龙智—DevSecOps解决方案

API

紫龙游戏解锁Jira与Perforce的游戏开发行业实践

龙智—DevSecOps解决方案

紫龙游戏

淘宝商品详情接口在电商运营中的应用实例

Noah

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