HTTP长链接这个说法好久以前就据说过,并且打开F12进行调试的时候也频繁看到keep-alive的http请求。虽然常常遇到,不过对于长链接仍是处于一种懵懂状态。正好今天上班比较闲,静下心来仔细研究了一番。html
现在所使用的HTTP协议基本上都是1.1的,默认为长链接。也就是说一个HTTP请求的响应头里面,默认会有这么一行代码:Connection:keep-alive
。HTTP长链接容许了HTTP设备在请求结束以后将TCP链接保持在打开的状态,以便为以后的HTTP请求重用现存的链接。从本质上来说,HTTP仅仅是应用层的协议,TCP才是真正的传输层协议,所以TCP才有真正的长链接短链接的说法。json
短链接的步骤为:创建链接——数据传输——关闭链接...创建链接——数据传输——关闭链接浏览器
长链接的步骤为:创建链接——数据传输...(保存链接)...数据传输——关闭链接服务器
长链接的带来的好处是显而易见的,它复用了TCP通道。通俗的来讲,使用短链接发起多个HTTP请求时,每次都会去从新创建TCP链接,这样会形成严重的资源浪费。若采用长链接,什么三次握手四次挥手可能只须要进行一次,这无疑减小了不少消耗。框架
固然,长链接也并非永久无限制的链接。服务器可以对长链接进行限制。koa
Connection:Keep-Alive Keep-Alive:max=5,timeout=120
像上面这样的HTTP响应头,说明服务器最多还会为另外5个事务保存链接打开的状态或者保持链接打开状态至空闲120秒后。async
本着治学严谨的态度,我对此进行了测试,比较HTTP请求长链接与短链接之间的耗时。测试
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>Document</title> </head> <body> <button id="button">点击发起请求</button> </body> <script> document.getElementById('button').onclick = () =>{ let arr = []; let i = 1000 while(i){ arr.push(fetch('/json')); i--; } let start = new Date().getTime(); Promise.all(arr).then(()=>{ let stop = new Date().getTime(); console.log(stop-start); }) } </script> </html>
点击按钮,向后台发起1000次请求,计算出1000次请求的耗时。fetch
后台使用了koa框架,代码以下网站
//...以上省略一万行代码 //短链接 router.get('/json', async (ctx, next) => { ctx.set('Connection','close'); ctx.body = { title: 'hello world' } }) //不设置response.header,默认长链接 router.get('/json', async (ctx, next) => { ctx.body = { title: 'hello world' } })
经过测试,短链接响应1000次请求的时间平均为1900ms,长链接的平均响应时间为1500ms。因而可知,长链接对于效率的提高是很是显著的。(这个测试还意外的测试出了火狐浏览器对于多请求同时进行方面存在不足)。
若存在理解上的错误,欢迎指出,欢迎访问个人我的网站