QCon 演讲火热征集中,快来分享技术实践与洞见! 了解详情
写点什么

Google 正制订一项新协议,旨在替换掉 HTTP

  • 2009-11-17
  • 本文字数:1787 字

    阅读完需:约 6 分钟

近日 Google 提出了 SPDY ——运行在 SSL 上的一个应用层协议,该协议旨在替换掉 HTTP,而后者被认为会产生延迟。Google 已经使用 Web 服务器与增强的 Chrome 浏览器开发了一个原型,结果是页面加载速度比以前快了 2 倍。

前一阵 Google 发出的倡议“让Web 变得更快”旨在提高Internet 的速度。该倡议涵盖了几个领域,从构建更快的Web 服务器到更快的浏览器。例如, Page Speed 就是个用来提高网页下载速度的工具。 Google 在开源大量工具的同时又发布了相关的教程以帮助全世界的开发者加快其 Web 站点的速度。

然而 Google 并没有裹足不前,他们开发了一个名为 SPDY(发音为 SPeeDY)的新的应用协议,一旦成功并得到广泛应用的话,SPDY 就会替换掉 HTTP 并彻底颠覆整个 Internet。SPDY 白皮书说要向协议栈下面渗透并替换掉传输层协议(TCP),但 Google 也认识到这样的话部署起来会相当困难,因此他们打算对应用层协议 HTTP 进行改进。

SPDY 白皮书提到了 HTTP 协议中的很多限制,尤其是页面传输时的延迟:

  • 一个请求一个连接。由于 HTTP 一次只能获取一个资源(HTTP 管道很有用,但也只是强制形成一个 FIFO 队列),因此 500 毫秒的服务器端延迟导致无法重用 TCP 通道来处理其他请求,而浏览器则通过发送多个连接来解决这一问题。自从去年以来,浏览器已经将每个域的连接由 2 个调整为了 6 个。
  • 只有客户端才能发送请求。在 HTTP 中,只有客户端才可以发送请求。即便服务器端知道客户端需要某个资源,那它也没有办法通知客户端而只能等待其发出对该资源的请求。
  • 未压缩的请求与响应头。如今的请求头的大小差别很大,从 200 bytes 到 2KB 的都有。随着应用越来越多地使用 cookie 和 user agents 扩展特性,700-800 bytes 的头大小已经变得很常见了。对于 modem 或是 ADSL 连接来说,上行带宽都很低,这种延迟就变得很可观了。降低头中的数据可以改进发送请求的序列化延迟。
  • 冗余的头。此外,有几个头会跨越请求在同一个通道上重复发送。像 User-Agent、Host 和 Accept* 这样的头基本都是不变的,没必要重复发送。
  • 可选的数据压缩。HTTP 对数据进行可选的压缩编码。内容总是应该以压缩格式发送。

SPDY 的一个目标就让页面加载时间降低 50%,同时将浏览速度提升一倍。对一个用户来说,几百毫秒不算什么,但每一毫秒都会对未来高度互联的 Web 应用产生积极的影响。当前 Web 上的内容并不会受到该协议的影响,只有 Web 服务器和客户端需要增强以充分利用该协议。

Google 究竟想用 SPDY 做什么呢?

  • 在单个 TCP 会话上执行多个并发的 HTTP 请求。
  • 通过压缩头以及减少不必要的头来降低当前 HTTP 所占据的带宽。
  • 定义一个易于实现且提升服务器效率的协议。我们希望通过砍掉一些边缘情况来降低 HTTP 的复杂度并定义易于解析的消息格式。
  • 将 SSL 作为底层传输协议以达到更好的安全性且兼容于现有的网络基础设施。尽管 SSL 引入了延迟,但我们相信从长远来看,Web 还是要依赖于安全的网络连接的。此外,要想保证跨越现有代理的通信不被破坏,SSL 也是必须的。
  • 让服务器可以主动与客户端通信并向客户端发送数据。

为了达成这些目标,Google 在 SSL 之上增加了一个会话层来实现 SPDY,这考虑到了“单个 TCP 连接之上会有多个并发、交错的流”。HTTP GET 和 POST 消息格式保持不变,但 SPDY 提出了一个新的“帧格式用于在线路上编码和传输数据”。流是双向的,客户端与服务器端都能开启流。

到目前为止,Google 构建了一个既能处理 HTTP 协议,也能处理 SPDY 协议的内存服务器,代码将在不久后开源。还有一个修改的 Chrome 版本(内部的暂定名为 flip ,也是开源的)运行在 HTTP 和 SPDY 之上。他们还开发了一套测试工具集来保证使用 SPDY 后页面仍能正确下载。这些工具也将于不久之后发布。

原型表明目前的结果还是很不错的:

我们通过模拟的家庭网络连接下载了百强网站的 25 个,只有 1% 的包丢失。每个站点都被下载了 10 次并计算平均的页面加载时间,然后计算所有站点的平均时间。结果表明普通 TCP(没有 SSL)上的页面加载时间要比 HTTP 提升了 27% - 60%,而 SSL 要提升 39% - 55%。

纵然提出了最好的协议,但显然 Google 无法凭借一己之力取得成功,还需要依靠社区的推动与努力来创建一个全新的应用层协议。其他公司对此有何反应呢,让我们拭目以待。

参考资源: SPDY 协议草案规范可以使用SPDY 的Chrome

查看英文原文: Google Works on a Protocol Intended to Replace HTTP

2009-11-17 11:262804
用户头像

发布了 88 篇内容, 共 264.2 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

元气部落盲盒小程序开发芒趣盲盒app开发

风行无疆

ONES Talk | 我们为什么选择最难走的软件之路

万事ONES

SaaS ONES

react源码解析5.jsx&核心api

buchila11

React React Hooks

Linux一学就会之Vim编辑器的使用和Xmanager工具的使用。

学神来啦

vim Linux centos 运维 ext4

建立合格的跨职能团队,你需要知道这些!

禅道项目管理

团队 合作共赢

WICC 广州高峰对话:为开发者标注「航海地图」

融云 RongCloud

开发 游戏 社交 泛娱乐 出海

高维数据世界|基于高维稀疏矩阵的潜在变量模型研究

索信达控股

算法 变量模型 模型介绍 高维数据

你有一份「写作跨年」邀请函请查收 | 28天写作计划

TGO鲲鹏会

写作 技术创作 28天写作 内容创作 热门活动

英特尔宋继强:秉持三个坚持,穿越技术周期,构建未来技术生态

科技新消息

从双十一的物流大战,看全球通信网络的低延迟优化

融云 RongCloud

音视频 通信 低延迟 全球通信

APISIX-Datadog 插件发布,助力用户提高系统的可观测性

API7.ai 技术团队

云原生 可观测性 API网关 APISIX Datadog

Python代码阅读(第66篇):两个列表的包含关系

Felix

Python Code 列表 阅读代码 Python初学者

【最全攻略】玩转2021LIGHT开发者云大会

恒生LIGHT云社区

技术 开发 行业 行业大会

看完这5个核心功能,你会明白低代码平台到底能解决什么问题!

J2PaaS低代码平台

低代码 低代码开发 低代码平台

专家推荐五个免费的网络安全工具

喀拉峻

网络安全 安全 渗透测试 渗透

行业视野 | ONES CEO 王颖奇对话极客公园张鹏

万事ONES

SaaS SaaS平台

一页纸需求的应对方法 —— 五步法

CODING DevOps

业务价值 角色梳理 术语定义 主业务流程梳理 纲举目张

Rust 元宇宙 9 —— 库和序列化

Miracle

rust 元宇宙

创新模式驱动生产力提升,融云社交场景化 SDK 探索

融云 RongCloud

直播 sdk 语聊房 场景化

ONES Automation 流程自动化解决方案

万事ONES

自动化 SaaS

社交泛娱出海新引擎,融云「六化」能力助开发者轻装上阵

融云 RongCloud

游戏出海 出海社交 出海

react源码解析6.legacy模式和concurrent模式

buchila11

React React Hooks

混合云管理软件用哪个品牌好?咨询电话多少?

行云管家

新思科技BSIMM12报告显示开源、云、容器安全活动增长显著

InfoQ_434670063458

新思科技 软件安全 BSIMM

手把手带你写一个 Vue3 的自定义指令

CRMEB

”微博评论“的高性能高可用计算架构设计

Steven

架构实战营

读《区块链技术及应用第二版》华为区块链发展思路、双引擎战略及华为区块链特点和使用有感

孙叫兽

区块链 华为链 华为区块链服务

【IT运维小知识】虚拟化vCenter是什么意思?有啥优势?

行云管家

Java&Go三种HTTP客户端性能测试

FunTester

Java 性能测试 测试框架 Go 语言 FunTester

字节跳动亿级DAU客户端发布最佳实践

字节跳动终端技术

数据产品经理实战-指标体系搭建

第519区

数据产品经理 数据产品 指标体系 指标管理

Google正制订一项新协议,旨在替换掉HTTP_Google_Abel Avram_InfoQ精选文章