网络协议:HTTP的升级改进

目录

HTTP协议的不足(HTTP/1.1)

SPDY

 HTTP/2

HTTP/2的特性--二进制格式

 HTTP/2的一些概念

 HTTP/2的特性:多路复用(Multiplexing)

 HTTP/2的特性:优先级

 HTTP/2的特性:头部压缩

HTTP/2的特性:服务器推送(Server Push)

 HTTP/2的问题:队头阻塞(head of line blocking)

  HTTP/2的问题:握手延迟

 HTTP3

HTTP/3的疑问

HTTP/3的特性:连接迁移

HTTP/3的问题:操作系统内核、CPU负载


HTTP协议的不足(HTTP/1.1)

  • 同一时间,一个连接只能对应一个请求,针对同一个域名,大多数浏览器允许同时最多6个并发连接
  • 只允许客户端主动发起请求,一个请求只能对应一个响应
  • 同一个会话的多次请求中,头信息会被重复传输,通常会给每个传输增加500~800字节的开销,如果使用Cooike,增加的开销有时候会达到上千字节

SPDY

  • SPDY(speedy的缩写),是基于TCP的应用层协议,它强制要求使用SSL/TLS,2009年11月,Googole宣布将SPDY作为提高网络速度的内部项目
  • SPDY于HTTP的关系
    • SPDY并不用于取代HTTP,它知识修改了HTTP请求与响应的传输方式
    • 只需要一个SPDY层,现有的所有服务端应用均不用做任何修改
    • SPDY是HTTP/2的前身
    • 2015年9月,Google宣布移除对SPDY的支持,拥抱HTTP/2

 HTTP/2

  • HTTP/2于2015年5月以RFC 7540正式发布,根据W3Techs的数据,截至2019年6月,全球有36.5%的网站支持了HTTP/2
  • HTTP/1.1和HTTP/2速度对比
  • HTTP/2在底层传输做了很多的改进和优化,但在语义上完全与HTTP/1.1兼容,比如请求方法(如GET、POST)、Status Code、各种Headers等都没有改变
  • 因此,要想升级到HTTP/2
    • 开发者不需要修改任何代码
    • 只需要升级服务器配置,升级浏览器

HTTP/2的特性--二进制格式

  • HTTP/2采用二进制格式传输数据,而非HTTP/1.1的文本格式
  • 二进制格式在协议的解析和优化扩展上带来更多的优势和可能

 HTTP/2的一些概念

  • 数据流:已经建立的连接内的双向字节流,可以承载一条或多条消息。所有通信都在一个TCP连接上完成,此连接可以承载任意数量的双向数据流
  • 消息:与逻辑HTTP请求或响应消息对应,由一系列帧组成
  • 帧:HTTP/2通信的最小单位,每个帧都包含帧头(会标识出当前帧所属的数据流),来自不同数据流的帧可以交错发送,然后再根据每个帧头的数据流标识符重新组装

 HTTP/2的特性:多路复用(Multiplexing)

  • 客户端与服务器可以将HTTP消息分解为互不依赖的帧,然后交错发送,最后在另一端把它们重新组装起来
  • 并行交错地发送多个请求,请求之间互不影响
  • 并行交错地发送多个响应,响应之间互不干扰
  • 使用一个连接并行发送多个请求和响应
  • 不必再绕过HTTP/1.1限制而做很多工作。比如image sprites、合并CSS/JS、内嵌CSS/JS/Base65图片、域名分片等

 HTTP/2的特性:优先级

  • HTTP/2标准允许每个数据流都有一个关联的权重和依赖关系,可以向每一个数据流分配一个介于1至256之间的整数,每个数据流与其他数据流之间可以存在显示依赖关系
  • 客户端可以构建和传递“优先级树”,表明它倾向于如何接收响应
  • 服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级,再资源数据可用之后,确保将高优先级响应以最优方式传输至客户端

 HTTP/2的特性:头部压缩

  • HTTP/2使用HPACK压缩请求头和响应头,可以极大减少头部开销,进而提高性能
  • 早期版本的HTTP/2和SPDY使用zlib压缩,可以将所传输头数据的大小减少85%~88%,但在2012年夏天,被攻击导致会话劫持,后被更安全的HPACK取代

HTTP/2的特性:服务器推送(Server Push)

  • 服务器可以对一个客户端的请求发送多个响应,除了对最初请求响应外,服务器还可以向客户端推送额外资源,而无需客户端额外明确地请求

 HTTP/2的问题:队头阻塞(head of line blocking)

  HTTP/2的问题:握手延迟

RTT(Round Trip Time):往返时延,可以简单理解为通信一来一回的时间

 HTTP3

  • Google觉得HTTP/2仍然不够快,于是就有了HTTP/3
    • HTTP/3由Google开发,弃用TCP协议,改为使用基于UDP协议的QUIC协议实现
    • QUIC(Quick UDP Internet Connetcions) ,译为:快速UDP网络连接,由Google开发,再2013年实现
    • 于2018年从HTTP-over-QUIC改为HTTP/3

HTTP/3的疑问

  • HTTP/3基于UDP,如何保证可靠传输?答案:由QUIC来保证
  • 为何Google不开发一个新的不同于TCP、UDP的传输层协议
    • 目前世界上的网络设备基本只认TCP、UDP
    • 如果要修改传输层,意味着操作系统的内核也要修改
    • 另外,由IETF标准化的许多TCP新特性都因为缺乏广泛支持而没有得到广泛的部署或使用
    • 因此,想要开发并应用一个新的传输层协议是极其困难的一件事

HTTP/3的特性:连接迁移

  • TCP基于4要素:源IP,源端口,目标IP,目标端口
    • 切换网络时至少会有一个要素发生变化,导致连接发生变化
    • 当连接发生变化时,如果还使用原来的TCP连接,则会导致连接失败,就得等原来的连接超时后重新建立连接
    • 所以我们有时候发现切换到一个新网络的时候,即使新网络状况良好,但内容还是需要加载很久
    • 如果实现得好,当检测到网络变化时,立刻建立起新的TCP连接,即使这样,建立新的连接还是需要几百毫秒的时间
  • QUIC的连接不受4要素的影响,当4要素发生变化时,原连接依然维持
    • QUIC连接不以4要素作为标识,而是使用一组Connection ID(连接ID)来标识一个连接
    • 即使IP或者端口发生变化,只要Connection ID没有变化,那么连接依然可以维持
    • 比如:
      • 当设备连接到WIFI时,将进行中的下载从蜂窝网络连接到更快速的WIFI连接
      • 当WIFI连接不再可用时,将连接转移到蜂窝网络连接

HTTP/3的问题:操作系统内核、CPU负载

  • 据Google和Facebook称,与基于TLS的HTTP/2相比,它们大规模部署的QUIC需要近两倍的CPU使用量
    • Linux内核的UDP部分没有得到像TCP那样的优化,因为传统上没有使用UDP进行如此高速的信息传输
    • TCP和TLS有硬件加速,而者对于UDP很罕见,对于QUIC则基本不存在
  • 随着时间的推移,相信这个问题会逐步得到改善
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值