写点什么

Google 与微软想要改进 HTTP

  • 2012-07-03
  • 本文字数:1991 字

    阅读完需:约 7 分钟

Google 与微软想要通过 SPDY 与 Speed+Mobility 改进 HTTP。本文将会介绍这两个提案并指出他们对广为使用的 Internet 协议带来了哪些好处。

目前, Internet 工程任务组(IETF)与 W3C 正在网络路由、传输与安全等问题上紧密合作,包括 1999 年由 Roy Fielding 与 T. Berners-Lee 等人联合签名的关于 HTTP 1.1 的 RFC 2616 规范提案。自从上一个 HTTP 版本发布以来已经过去了 12 年多的时间,一些人已经开始注意到这个广为使用的 Internet 协议需要进行增强以面对时代的需要。目前,针对 HTTP 2.0 已经有多份提案被提交到了IETF,这其中包括 Google SPDY 与微软的 HTTP Speed+Mobility 。这两个提案都向后兼容于前一个版本的协议,旨在构建在现有的基础设施之上。

Google 想要重点解决现有 HTTP 1.1 的速度问题:

HTTP 实现的一个瓶颈在于 HTTP 需要通过多个连接来解决并发问题。这会导致一些问题,比如说为了建立连接所需的额外的往返过程、慢启动的延迟以及客户端的连接配额,这是由于客户端会防止对任何一个服务器打开过多的连接。

出于以上原因,SPDY 旨在:

在一个单独的 TCP 连接(或是任何可靠的传输流)之上增加一个 Framing Layer 以实现多个并发的流。Framing Layer 会针对类似于 HTTP 请求响应的流进行优化,比如说现在运行在 HTTP 之上的应用也可以运行在 SPDY 之上,对于 Web 应用来说只需做很少的修改或是无需修改。

实际上,SPDY 对 HTTP 1.1 进行了 4 个主要的改进,分别是多路请求、对请求划分优先级、压缩头以及服务器的流推送。虽然目前 SPDY 还仅仅是个提案,但它已经被实现出来并形成了产品。Google 在其很多服务与 Chrome 中都使用到了 SPDY。其他的实现还有 Apache SPDY 模块、用于 node.js 的 SPDY 服务器、Netty、Firefox 与 Amazon Silk,Ngnix 很快也会跟进。

微软针对 HTTP 2.0 提出的规范将重点放在了速度问题与移动上,该提案从 SPDY 开始到 WebSockets 结束。在之前与 InfoQ 的一封邮件交流中,来自于微软开放技术的高级程序经理及微软提案的签署者 Adalberto Foresti 提到“SPDY 做的非常漂亮,它让人们认识到了 Web 性能问题并采取了全新的方式改进 HTTP 以让 Web 变得更快”。微软的提案改进了 SPDY,这是通过简化”会话控制消息以删除对于 WebSockets 控制帧来说冗余的条目来实现的,但与现有的 HTTP 语义并不兼容,或是实现一些在传输层上的重要概念”。

微软的 HTTP Speed+Mobility 还增加了两节内容,旨在改进“物联网”上对于 HTTP 的使用,考虑到了 CPU 消耗、设备电池与资源、安全等问题。名为“Client is in control of content”的 1.1.4 节中提到:

考虑到 Internet 上各种各样的客户端以及连接数场景,客户端是定义下载什么内容的最佳场所。浏览器或是应用有关于用户当前正在做什么以及哪些数据在本地存在的第一手信息。比如说,目前使用的大多数浏览器都拥有强大的缓存,我们应该使用他们来存储不经常变化的 Web 元素。 HTTP 2.0 提案不应该强制浏览器或是应用下载没有请求的或是已经被缓存的内容。此外,客户端要有拒绝不想要或是不需要内容的权利。客户端要能通知服务端自己已经拥有了已经缓存,不需要下载的元素。在理想情况下,这种来自于客户端,发向服务端的反馈应该考虑到内容的增量审批,这样才会形成一个高效的“推送”扩展以通过适当的安全性与正确的格式递送正确的内容。

在名为“Network Cost and Power”的 1.1.5 节中,作者重点谈到了电源与带宽使用问题:

速度、消耗与电源之间的抉择并不是一个简单的问题。有时,速度可能是最需要考虑的事情。但有时,带宽消耗或是电池寿命可能是决定因素。HTTP 2.0 必须要能使开发者针对其具体的问题域约束进行优化(约束可能会随着时间的流逝而发生变化)而不是对通用问题给出一个统一的解决方案。 我们需要对更快的速度、更少的消耗、更低的电源使用量进行均衡处理。比如说,在网线上传递更少的数据会使页面的加载速度更快,更省电以及占用更少的带宽。但考虑到 HTTP 2.0 的使用场景千差万别,事实并不总是如此。比如说,对于一个电池即将耗尽或是缓存即将占满的设备来说,如果在保留 HTTP 2.0 中其他优化的同时能够禁用掉服务端推送更新将会提供更好的用户体验。因此,工作组需要同时考虑电源、消耗与速度问题。

为了解决方才提到的问题,微软提出通过 WebSocket 升级来实现会话握手、保持与 Framing,规范包含了用户希望看到的一些底层细节信息。

微软已经在今年 3 月举办的 IETF 83 大会上提交了其提案。他们还实现了一个开源的概念验证原型,可以让开发者评估HTTP Speed+Mobility 提案,项目代码位于GitHub 上。

至于业界会选择哪一个来实现还不明朗。根据 IETF 标准进程,“规范要经历一个开发期、经过 Internet 社区的几轮审查并根据体验进行修订、然后被恰当的组织采纳为标准、最后发布”。

相关资源: HTTPbis 工作组开始考虑 HTTP/2.0

查看英文原文: Google and Microsoft Want to Improve HTTP

2012-07-03 13:193401
用户头像

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

关注

评论

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

走在市场前沿:用Lazada商品列表数据接口追踪竞争对手

tbapi

lazada商品API接口 lazada商品列表数据接口 lazada lazada商品数据采集接口

综合性价比超越硅谷,PPIO派欧云发布下一代推理加速引擎

极客天地

ShareSDK第三方平台使用指南——新浪微博

MobTech袤博科技

Java 开发者 产品动态

第61期|GPTSecurity周报

云起无垠

利用 Python 和 IPIDEA:跨境电商与数据采集的完美解决方案

海拥(haiyong.site)

Python

日程管理多源归一,服务场景一键直达

HarmonyOS SDK

HarmonyOS

深入解析 Go 语言 GMP 模型:并发编程的核心机制

王中阳Go

Go 面试 GMP

8月浙江省公安厅即将举办省网络与信息安全管理员项目职业技能竞赛

行云管家

网络安全 信息安全

支持英文语言的堡垒机是什么?叫做什么名字?

行云管家

软件 堡垒机

向量检索服务应用场景

DashVector

数据库 向量检索 大模型

如何将文本转换为向量(DashScope)

DashVector

数据库 向量检索 大模型

GPT4o-mini是什么?有什么特点?

蓉蓉

GPT-4o mini

如何建立变更管控流水线

老张

软件测试 质量保障 交付质量 线上发布 变更管理

AlDente Pro :苹果电脑电池管理工具 延长电池寿命

Rose

苹果电脑 电池管理 AlDente Pro破解版 电池寿命

低代码平台在采购管理中的革新与应用

天津汇柏科技有限公司

低代码 采购管理 软件定制开发

复古传奇,经典归来,清渊传奇详细图文架设教程

echeverra

清渊传奇

巴赫:阿里AI技术将巴黎奥运转播带到新高度

阿里云CloudImagine

云计算 音视频 视频云 奥运会 AI增强技术

揭秘攻击者规避XDR检测的惯用手法及应对建议

我再BUG界嘎嘎乱杀

黑客 网络安全 安全 网安 XDR检测

滴滴开源 LogicFlow:专注流程可视化的前端框架

源字节1号

开源

RAG+AI工作流+Agent:LLM框架该如何选择,全面对比MaxKB、Dify、FastGPT、RagFlow、Anything-LLM,以及更多推荐

汀丶人工智能

agent rag FastGPT dify AI 智能体

两个爆点,引爆在线教育平台数智化

字节跳动数据平台

在线教育 可视化 云服务 数智化

ETL数据集成丨将DB2数据同步至Postgres数仓实践

RestCloud

数据库 postgresql 数据同步 ETL 数据集成工具

向量检索服务的基本概念

DashVector

向量检索 #数据库 #人工智能 #大模型

可观测性建设路线图

FunTester

Google与微软想要改进HTTP_微软_Abel Avram_InfoQ精选文章