Http 链接复用

0、html

在真正试图解决你的疑问的以前,咱们来看一下,从发出request以前到接收respon以后,都发生了什么。算法

0.你向浏览器的地址栏输入一个域名.如 http://www.zhihu.com
1.浏览器向你的本地DNS服务器请求解析该域名,即将你的http://www.zhihu.com 解析为真实的IP地址.详细协议请查询RFC文档,其中对DNS协议的格式内容,指令意义,压缩算法,等都做出了规定。
2.拿到ip地址以后,发起TCP 握手(3次),详情请看计算机网络TCP协议部分
3.握手成功,构造request,即 HTTP 中request请求.并发送到目的地。有关HTTP协议的内容请查阅RFC文档能够购买HTTP权威指南做为参考和释疑.
4.服务器接受到一个完整的request(该边界的指定通常是conten-length,chunked也有),根据用户的request内容运算出相应的response。
5.服务器将response 沿着request创建的链接,向浏览器(客户端)发送数据。
5.5 keepalive的时候不关闭该链接,没有keepalive的时候发起tcp close,4次握手
6.浏览器根据接收到的response开始渲染页面。






浏览器

至此,一个网页的打开过程完毕,咱们从中提取出耗时的部分。
1.DNS查询时间(一来一回,走UDP协议) 网络IO
2.tcp 创建链接握手 网络IO
3.request构造时间(cpu运算)
4.request发送完毕时间(网络IO)
5.服务器接收request运算构造response(CPU运算,特指构造response过程当中没有任何IO操做)
6.服务器发送response到客户端的时间(网络IO)
6.5 服务器关闭链接时间(IO)
7.客户端接收数据渲染页面时间(cpu运算)。







服务器

至此,一个流程就这样简单地构造完毕了网络

一、http 1.0:每个http请求都会打开一个tcp socket链接,当交互完毕后会关闭这个链接。以后, 从1996年开始,不少HTTP/1.0浏览器与服务器都对协议进行了扩展,那就是“keep-alive”扩展协议。使用HTTP/1.0的客户端在首部中加上"Connection:Keep-Alive",请求服务端将一条链接保持在打开状态。服务端若是愿意将这条链接保持在打开状态,就会在响应中包含一样的首部。若是响应中没有包含"Connection:Keep-Alive"首部,则客户端会认为服务端不支持keep-alive,会在发送完响应报文以后关闭掉当前链接。并发

对于http 1.0,具备一些性能上的缺陷。socket

例如,一个包含有许多图像的网页文件中并无包含真正的图像数据内容,而只是指明了这些图像的URL地址,当WEB浏览器访问这个网页文件时,浏览器首先要发出针对该网页文件的请求,当浏览器解析WEB服务器返回的该网页文档中的HTML内容时,发现其中的图像标签后,浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。显 然,访问一个包含有许多图像的网页文件的整个过程包含了屡次请求和响应,每次请求和响应都须要创建一个单独的链接,每次链接只是传输一个文档和图像,上一次和下一次请求彻底分离。即便图像文件都很小,可是客户端和服务器端每次创建和关闭链接倒是一个相对比较费时的过程,而且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件,CSS文件等内容时,也会出现相似上述的状况。tcp

同时,带宽和延迟也是影响一个网络请求的重要因素。在网络基础建设已经使得带宽获得极大的提高的当下,大部分时候都是延迟在于响应速度。基于此会发现,http1.0被抱怨最多的就是链接没法复用,和head of line blocking这两个问题。理解这两个问题有一个十分重要的前提:客户端是依据域名来向服务器创建链接,通常PC端浏览器会针对单个域名的server同时创建6~8个链接,手机端的链接数则通常控制在4~6个。显然链接数并非越多越好,资源开销和总体延迟都会随之增大。链接没法复用会致使每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。head of line blocking会致使带宽没法被充分利用,以及后续健康请求被阻塞。post

二、http 1.1:HTTP/1.1采起持久链接的方式替代了Keep-Alive。HTTP/1.1的链接默认状况下都是持久链接。若是要显式关闭,须要在报文中加上Connection:Close首部。即在HTTP/1.1中,全部的链接都进行了复用。然而如同Keep-Alive同样,空闲的持久链接也能够随时被客户端与服务端关闭。不发送Connection:Close不意味着服务器承诺链接永远保持打开。HttpClient经过链接池来管理持久链接。性能

HTTP/1.1的KeepAlive就是串行的会话模式,一去一回,省掉的是TCP层面重复建立的成本。

在一个TCP链接上能够传送多个HTTP请求和响应,减小了创建和关闭链接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答能够在一个链接中传输,但每一个单独的网页文件的请求和应答仍然须要使用各自的链接。HTTP 1.1还容许客户端不用等待上一次请求结果返回,就能够发出下一次请求,但服务器端必须按照接收到客户端请求的前后顺序依次回送响应结果,以保证客户端可以区分出每次请求的响应内容,这样也显著地减小了整个下载过程所须要的时间。
三、 多路复用代替原来的 序列和阻塞机制,全部就是请求的都是经过 一个 TCP 链接并发完成。

在 HTTP/2 中,有了二进制分帧以后,HTTP/2 再也不依赖 TCP 连接去实现多流并行了,在 HTTP/2 中:

  • 同域名下全部通讯都在单个链接上完成,同个域名只须要占用一个 TCP 链接,使用一个链接并行发送多个请求和响应
  • 单个链接能够承载任意数量的双向数据流,单个链接上能够并行交错的请求和响应,之间互不干扰
  • 数据流以消息的形式发送,而消息又由一个或多个帧组成,多个帧之间能够乱序发送,由于根据帧首部的流标识能够从新组装。每一个请求均可以带一个 31bit 的优先值,0 表示最高优先级, 数值越大优先级越低
四、区别的缘由:
缘由是由于HTTP1.1 及更低版本的协议,并无一个字段用来区分一个response是归属于哪个request的。但HTTP 2 就有这个字段了。所以在HTTP1.1 及更低版本,你只能在发送一个request以后,等待response的到来。HTTP1.1 request和response 的无标识符问题(即response没法指明是哪个request的),就造就了如今这种状况。HTTP 2 协议解除了这个问题。
 
参考:
相关文章
相关标签/搜索