在 2025 收官前,看清 Data + AI 的真实走向,点击查看 BUILD 大会精华版 了解详情
写点什么

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

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

关注

评论

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

Flink Next:Beyond Stream Processing

Apache Flink

大数据 flink 编程 流计算 实时计算

CPP进阶:迭代器失效

正向成长

迭代器失效

直播预告|FeatureStore Meetup V2

星策开源社区

人工智能 大数据 开源 特征平台 MLOps

[Day2]-[回溯] N皇后问题

方勇(gopher)

LeetCode 动态规划 数据结构算法

澳鹏数据标注平台MatrixGo加速人工智能落地

澳鹏Appen

人工智能 数据标注 训练数据

车载运行小程序,快速打造智慧汽车应用生态

Speedoooo

车联网 物联网 智慧终端 智慧汽车 车载小程序

在线常用crontab表达式大全验证解析

入门小站

工具

性能测试中的LongAdder

FunTester

性能测试 FunTester

架构实战营6&微信业务架构&学生管理系统方案

唐诗宋词

在线HTML压缩工具

入门小站

工具

代码评审的最佳解决方案

阿里云云效

云计算 阿里云 敏捷开发 代码管理 代码评审

智能家居开放平台技术建设新思路

Speedoooo

物联网 智慧社区 智慧家居 智能终端 应用平台

JavaScript 引擎是如何实现 async/await 的

CRMEB

车联网数据安全新挑战的技术应对方案

Speedoooo

车联网 物联网 数据安全 容器安全

赋能创新,深开鸿重磅发布面向金融行业KaihongOS发行版

科技汇

阿里巴巴代码规约检测&Java 代码规约扫描

阿里云云效

阿里巴巴 阿里云 代码扫描 #java 代码规约检测

面试题笔记

Clarke

java高级用法之:在JNA中使用类型映射

程序那些事

Java 程序那些事 3月月更 JNA

【ELT.ZIP】OpenHarmony啃论文俱乐部——轻翻那些永垂不朽的诗篇

ELT.ZIP

OpenHarmony 数据压缩 ELT.ZIP

企业如何实现在线客服功能?

小炮

在线客服

TDesign 更新周报(2022年3月第4周)

TDesign

一文读懂并发与并行

潘大壮

并发编程 多线程 并行 并发’ #java

什么是404页面?

源字节1号

404

如何建立高效的质量保障机制

老张

软件测试 质量保障 交付能力

个全中文注释的迷你Spring!

程序员阿杜

Java spring springboot

恒源云(GpuShare)_无监督的QG方法

恒源云

自然语言处理 深度学习

Hoo虎符研究院|区块链简报 20220328期

区块链前沿News

虎符 Hoo 虎符交易所

Petal Maps的美学钥匙,解锁AITO问界M5的硬核浪漫

脑极体

架构实战营-第6期 模块一课后作业

乐邦

「架构实战营」

Linux之time命令

入门小站

Linux

微信业务架构图&学生管理系统架构设计

高山觅流水

架构实战营 「架构实战营」

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