http1 & http2 发展与特性

http://blog.csdn.net/qq_17371033/article/details/52690978

Http

http协议已经被广泛应用在web应用中,常用于一下几种场景:

  • 聊天 (全双工,客户端和服务器实时通信)

  • 推送 (服务器主动向客户端通信)

  • 应答 (传统模式,客户端发起请求,服务器响应)

长连接(TCP)

Http协议本身就是基于请求/应答模式的,只要服务器响应,本次http连接就结束了,但这不意味着TCP通道关闭。

所谓的长连接通常是指 TCP连接 ,TCP通道连接客户端和服务器端,可以保持一段时间不关闭。

http1.1引入了长连接,使用 Connection:keep-alive 首部字段来保证tcp通道长时间存在(需要服务端和客户端同时设置)。

长连接的TCP通道客户端一般不会主动关闭,服务端会自动关闭在一段时间内(可设置)未进行使用的tcp通道连接(超时处理)。

Http1.0

http1.0有两个很大的缺点:

  • 连接无法复用 (TCP通道立即关闭)

  • 队首请求阻塞 (http、tcp)

在TCP通道上,Http1.0不支持长连接,每次的请求/响应结束后,TCP通道立即关闭。

因此,一般PC端会向一个域名同时建立6~8个连接,手机端则是4~6个,会导致延迟和开销增大。

此外,队首阻塞有两个层面。

  1. http应用层队首阻塞:http1协议规定严格按照优先级进行请求发送,意味着低优先级请求的发送必须等待高优先级响应后进行。

  2. tcp传输层队首阻塞:tcp要求分组严格按照顺序交付,一个分组未收到,就会阻塞后续的所有高序号分组。直到重传那个丢失的分组。

http1.0请求阻塞

队首阻塞的情况常常会遇到,比如当某一个请求未抵达服务器,或响应因网络阻塞未返回时影响后面的请求发送,并且在js,css等外部文件下载方面造成很大的延时(同步下载)。

http1.1

http1.1已经被广泛使用。在http1.0的基础上,新增了以下功能:

  • TCP通道长连接(持久连接),在响应后不关闭TCP通道

  • 新增了首部字段 Host,客户端指明访问的主机(域名 || [ip + 端口号]),使得服务端可以在同一域名下的不同主机之间实现多个虚拟Web站点。

  • 新增了首部字段 Connection,实现持久连接,默认开启 Keep-Alive,关闭连接复用需要显示的设置成Close

  • 新增了http流水线机制(http pipelining),允许幂等的请求(GET,HEAD)同时发送,在响应方面仍然是以同步方式的顺序返回

  • ….

http1.1的新增特性解决了http1.0的两个大难题,实现了TCP通道连接复用,并支持多个请求同时发送,互不影响。

http1.1流水线机制

持久的TCP通道并不能解决所有问题,同一时间一条TCP通道只能有一个请求/应答。

客户端无法再通过TCP通道是否关闭来判断响应发送完成,因此响应中必须包含Content-Length首部来辅助浏览器判断一次响应的结束。

浏览器会根据Content-Length的值来判断响应是否发送完成,若该首部属性的值过大,则会一直处于pending状态,过小则会对响应体进行截取。

http层伪长连接

虽然http1.1实现了TCP通道在 一段时间内 的复用,这对于pc端很适用,但对于移动端则不然。

移动端的请求比较分散,时间跨度大,因此移动端往往在 应用层 做处理,常常使用一下几种方式:

  • http long-polling (长轮询)

  • http stream (http流)

  • web socket (H5)

长轮询

长轮询是实现http层面(应用)的 伪长连接 ,并没有在模式上进行改变,仍然是请求/应答模式,能够在很大的时间跨度上保持 长连接

长轮询

  1. 客户端向服务器发送一个请求

  2. 服务器端不是立刻响应处理,而是保持Http会话

  3. 服务器端需要推送消息时进行响应

  4. 客户端接受响应并再次发送一个请求

缺点:

  • 长连接的做法会导致服务端一直阻塞请求,造成内存上的闲置,在网站流量大,多并发的情况下会使用大量内存,浪费连接。

  • 在断网等极端情况下失去连接,需要重新发送请求,处理复杂

  • 后端服务器的响应可能被代理服务器缓存

短轮询

短轮询与长轮询不同处在于,客户端向服务器发送请求后,服务器会立刻返回响应,

http流

http流这种处理方式与长轮询类似,不同之处在于服务器推送响应后,不会停止这次http会话,而是继续保持阻塞状态,等待下一次推送或超时(超时后通知客户端重新发送请求)。

http流

http流的方式处理时,利用ajax的 readystate == 3 来判断服务器是否有推送数据,进行读取,但在IE中,readystate ==3时不能够读取数据,因此IE不支持http流的方式。

http流的实现方式很简单,是通过在响应头添加首部Transfer-Encoding: chunked,该首部的值chunked会使报文采用分块传输。

报文的分块传输不需要关闭tcp通道,也不用Content-Length首部来辅助浏览器判断响应的结果。

分块传输是针对响应体,服务端可以间断的发送响应体,每次响应都会包含具体字节长度。

这里有篇文章专门介绍了chunked分段传输。

web socket

web socket 是H5推出的新技术,基于TCP协议。

web socket通信只使用了一次http请求,创建TCP通道,利用HTTP响应的 101 状态码来触发协议切换,升级到web socket自身协议,后续的请求和响应都是遵循web socket协议。

Http Request

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: null
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Http Response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Origin: null
Sec-WebSocket-Location: ws://example.com/
 
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

http2.0

http1.0和http1.1仍然有很多的问题,http2.0目标便是解决http1.1版本中的两个问题:

  • 延迟性 (改动http应用层,而TCP传输层已经被广泛应用,改动代价太大)

  • 安全性

为了实现低延迟和高吞吐量,http2增加了了二进制分帧层和首部压缩技术。

二进制分帧

在http应用层,加入了一层二进制分帧层,在http层使用二进制对http请求进行编码。

传输层从应用层获取到的将是纯二进制,原先http1的一个请求文本会被分割成多个二进制帧传递给传输层。

二进制分帧层

二进制分帧层将一个请求切成碎片(帧,http2.0网络传输的最小单位)打乱发送,解决了队首阻塞的问题。

二进制分帧使用二进制格式来替换原有的文本格式,在解析和差错检测上更加的精准方便(不用考虑换行、空格等)。

首部压缩

由于http是无状态的,因此每次请求/响应都有首部来对所传输的资源进行描述。

在http1中,http层是以文本进行传输的,首部加上cookie可以达到上千字节。

http2采用了首部压缩,目的是减少每次请求的请求头大小,提升了性能,节约开销。

首部压缩

浏览器和服务器同时维护一张首部表,里面会记录一些常用键值对(用户代理、可接受的媒体类型等),拥有唯一序号来与之对应。

每次发送请求时,会从首部表中比较常用键值对,以唯一序号来代替,同时会将该请求首部(首部表以外的属性)与上一次的请求进行比较,只发送有差异性的首部属性。

最终确定出来需要发送的首部,会以哈夫曼编码进行再次压缩。

传输方式

二进制分帧层将请求和响应分为了一个又一个的帧,这些帧在一个tcp通道中是被打乱传输的。

为了能够完整准确的在客户端和服务端将其重新拼接,http2.0引入了流(Stream)的概念,变相的实现了多路复用

http2.0流

将一个tcp通道在逻辑上切割成了多个并行存在的流,一个流只服务于一个请求/应答,而在实际tcp传输中,其仍然是打乱发送的。

http2.0tcp通道

参考博文


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值