详解基于Node.js的HTTP/2 Server实践

虽然HTTP/2目前已经逐渐的在各大网站上开始了使用,但是在目前最新的Node.js上仍然处于实验性API,还没有能有效解决生产环境各种问题的应用示例。因此在应用HTTP/2的道路上我自己也遇到了许多坑,下面介绍了项目的主要架构与开发中遇到的问题及解决方式,也许会对你有一点点启示。

配置

虽然W3C的规范中没有规定HTTP/2协议一定要使用ssl加密,但是支持非加密的HTTP/2协议的浏览器实在少的可怜,因此我们有必要申请一个自己的域名和一个ssl证书。

本项目的测试域名是 you.keyin.me ,首先我们去域名提供商那把测试服务器的地址绑定到这个域名上。然后使用Let's Encrypt生成一个免费的SSL证书:

sudo certbot certonly --standalone -d you.keyin.me

输入必要信息并通过验证之后就可以在 /etc/letsencrypt/live/you.keyin.me/ 下面找到生成的证书了。

改造Koa

Koa是一个非常简洁高效的Node.js服务器框架,我们可以简单改造一下来让它支持HTTP/2协议:

class KoaOnHttps extends Koa {
 constructor() {
  super();
 }
 get options() {
  return {
   key: fs.readFileSync(require.resolve('/etc/letsencrypt/live/you.keyin.me/privkey.pem')),
   cert: fs.readFileSync(require.resolve('/etc/letsencrypt/live/you.keyin.me/fullchain.pem'))
  };
 }
 listen(...args) {
  const server = http2.createSecureServer(this.options, this.callback());
  return server.listen(...args);
 }
 redirect(...args) {
  const server = http.createServer(this.callback());
  return server.listen(...args);
 }
}

const app = new KoaOnHttps();
app.use(sslify());
//...
app.listen(443, () => {
logger.ok('app start at:', `https://you.keyin.cn`);
});

// receive all the http request, redirect them to https
app.redirect(80, () => {
logger.ok('http redirect server start at', `http://you.keyin.me`);
});

上述代码简单基于Koa生成了一个HTTP/2服务器,并同时监听80端口,通过sslify中间件的帮助自动将http协议的连接重定向到https协议。

静态文件中间件

静态文件中间件主要用来返回url所指向的本地静态资源。在http/2服务器中我们可以在访问html资源的时候通过服务器推送(Server push)将该页面所依赖的js\css\font等资源一起推送回去。具体代码如下:

const send = require('koa-send');
const logger = require('../util/logger');
const { push, acceptsHtml } = require('../util/helper');
const depTree = require('../util/depTree');
module.exports = (root = '') => {
 return async function serve(ctx, next) {
  let done = false;
  if (ctx.method === 'HEAD' || ctx.method === 'GET') {
   try {
    // 当希望收到html时,推送额外资源。
    if (/(\.html|\/[\w-]*)$/.test(ctx.path)) {
     depTree.currentKey = ctx.path;
     const encoding = ctx.acceptsEncodings('gzip', 'deflate', 'identity');
     // server push
     for (const file of depTree.getDep()) {
      // server push must before response!
      // https://huangxuan.me/2017/07/12/upgrading-eleme-to-pwa/#fast-skeleton-painting-with-settimeout-hack
      push(ctx.res.stream, file, encoding);
     }
    }
    done = await send(ctx, ctx.path, { root });
   } catch (err) {
    if (err.status !== 404) {
     logger.error(err);
     throw err;
    }
   }
  }
  if (!done) {
   await next();
  }
 };
};

需要注意的是,推送的发生永远要先于当前页面的返回。否则服务器推送与客户端请求可能就会出现竞争的情况,降低传输效率。

依赖记录

从静态文件中间件代码中我们可以看到,服务器推送资源取自depTree这个对象,它是一个依赖记录工具,记录当前页面 depTree.currentKey 所有依赖的静态资源(js,css,img...)路径。具体的实现是:

const logger = require('./logger');

const db = new Map();
let currentKey = '/';

module.exports = {
  get currentKey() {
    return currentKey;
  },
  set currentKey(key = '') {
    currentKey = this.stripDot(key);
  },
  stripDot(str) {
    if (!str) return '';
    return str.replace(/index\.html$/, '').replace(/\./g, '-');
  },
  addDep(filePath, url, key = this.currentKey) {
    if (!key) return;
    key = this.stripDot(key);
    if(!db.has(key)){
      db.set(key,new Map());
    }
    const keyDb = db.get(key);

    if (keyDb.size >= 10) {
      logger.warning('Push resource limit exceeded');
      return;
    }
    keyDb.set(filePath, url);
  },
  getDep(key = this.currentKey) {
    key = this.stripDot(key);
    const keyDb = db.get(key);
    if(keyDb == undefined) return [];
    const ret = [];
    for(const [filePath,url] of keyDb.entries()){
      ret.push({filePath,url});
    }
    return ret;
  }
};

当设置好特定的当前页 currentKey 后,调用 addDep 将方法能够为当前页面添加依赖,调用 getDep 方法能够取出当前页面的所有依赖。 addDep 方法需要写在路由中间件中,监控所有需要推送的静态文件请求得出依赖路径并记录下来:

router.get(/\.(js|css)$/, async (ctx, next) => {
 let filePath = ctx.path;
 if (/\/sw-register\.js/.test(filePath)) return await next();
 filePath = path.resolve('../dist', filePath.substr(1));
 await next();
 if (ctx.status === 200 || ctx.status === 304) {
  depTree.addDep(filePath, ctx.url);
 }
});

服务器推送

Node.js最新的API文档中已经简单描述了服务器推送的写法,实现很简单:

exports.push = function(stream, file) {
 if (!file || !file.filePath || !file.url) return;
 file.fd = file.fd || fs.openSync(file.filePath, 'r');
 file.headers = file.headers || getFileHeaders(file.filePath, file.fd);

 const pushHeaders = {[HTTP2_HEADER_PATH]: file.url};

 stream.pushStream(pushHeaders, (err, pushStream) => {
  if (err) {
   logger.error('server push error');
   throw err;
  }
  pushStream.respondWithFD(file.fd, file.headers);
 });
};

stream 代表的是当前HTTP请求的响应流, file 是一个对象,包含文件路径 filePath 与文件资源链接 url 。先使用 stream.pushStream 方法推送一个 PUSH_PROMISE 帧,然后在回调函数中调用 responseWidthFD 方法推送具体的文件内容。

以上写法简单易懂,也能立即见效。网上很多文章介绍到这里就没有了。但是如果你真的拿这样的HTTP/2服务器与普通的HTTP/1.x服务器做比较的话,你会发现现实并没有你想象的那么美好,尽管HTTP/2理论上能够加快传输效率,但是HTTP/1.x总共传输的数据明显比HTTP/2要小得多。最终两者相比较起来其实还是HTTP/1.x更快。

Why?

答案就在于资源压缩(gzip/deflate)上,基于Koa的服务器能够很轻松的用上 koa-compress 这个中间件来对文本等静态资源进行压缩,然而尽管Koa的洋葱模型能够保证所有的HTTP返回的文件数据流经这个中间件,却对于服务器推送的资源来说鞭长莫及。这样造成的后果是,客户端主动请求的资源都经过了必要的压缩处理,然而服务器主动推送的资源却都是一些未压缩过的数据。也就是说,你的服务器推送资源越大,不必要的流量浪费也就越大。新的服务器推送的特性反而变成了负优化。

因此,为了尽可能的加快服务器数据传输的速度,我们只有在上方 push 函数中手动对文件进行压缩。改造后的代码如下,以gzip为例。

exports.push = function(stream, file) {
 if (!file || !file.filePath || !file.url) return;
 file.fd = file.fd || fs.openSync(file.filePath, 'r');
 file.headers = file.headers || getFileHeaders(file.filePath, file.fd);

 const pushHeaders = {[HTTP2_HEADER_PATH]: file.url};

 stream.pushStream(pushHeaders, (err, pushStream) => {
  if (err) {
   logger.error('server push error');
   throw err;
  }
  if (shouldCompress()) {
   const header = Object.assign({}, file.headers);
   header['content-encoding'] = "gzip";
   delete header['content-length'];

   pushStream.respond(header);
   const fileStream = fs.createReadStream(null, {fd: file.fd});
   const compressTransformer = zlib.createGzip(compressOptions);
   fileStream.pipe(compressTransformer).pipe(pushStream);
  } else {
   pushStream.respondWithFD(file.fd, file.headers);
  }
 });
};

我们通过 shouldCompress 函数判断当前资源是否需要进行压缩,然后调用 pushStream.response(header) 先返回当前资源的 header 帧,再基于流的方式来高效返回文件内容:

  1. 获取当前文件的读取流 fileStream
  2. 基于 zlib 创建一个可以动态gzip压缩的变换流 compressTransformer
  3. 将这些流依次通过管道( pipe )传到最终的服务器推送流 pushStream 中

Bug

经过上述改造,同样的请求HTTP/2服务器与HTTP/1.x服务器的返回总体资源大小基本保持了一致。在Chrome中能够顺畅打开。然而进一步使用Safari测试时却返回HTTP 401错误,另外打开服务端日志也能发现存在一些红色的异常报错。

经过一段时间的琢磨,我最终发现了问题所在:因为服务器推送的推送流是一个特殊的可中断流,当客户端发现当前推送的资源目前不需要或者本地已有缓存的版本,就会给服务器发送 RST 帧,用来要求服务器中断掉当前资源的推送。服务器收到该帧之后就会立即把当前的推送流( pushStream )设置为关闭状态,然而普通的可读流都是不可中断的,包括上述代码中通过管道连接到它的文件读取流( fileStream ),因此服务器日志里的报错就来源于此。另一方面对于浏览器具体实现而言,W3C标准里并没有严格规定客户端这种情况应该如何处理,因此才出现了继续默默接收后续资源的Chrome派与直接激进报错的Safari派。

解决办法很简单,在上述代码中插入一段手动中断可读流的逻辑即可。

//...
fileStream.pipe(compressTransformer).pipe(pushStream);
pushStream.on('close', () => fileStream.destroy());
//...

即监听推送流的关闭事件,手动撤销文件读取流。

最后

本项目代码开源在Github上,如果觉得对你有帮助希望能给我点个Star。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Node.js学习教程之HTTP/2服务器推送【译】

    前言 最近Node.js v8.4+版本发布带来了体验版的HTTP/2,你可以自己通过设置参数--expose-http2启动. 这篇文章,我将介绍HTTP/2最重要的一方面服务器推送并且创建一个小的Node.js程序案例来使用它.下面话不多说了,来一起看看详细的介绍吧. 关于HTTP/2 HTTP/2 的目的是通过支持完整的请求与响应复用来减少延迟,通过有效压缩 HTTP 标头字段将协议开销降至最低,同时增加对请求优先级和服务器推送的支持. 更多关于HTTP/2内容,请查看文章HTTP/2.

  • 详解基于Node.js的HTTP/2 Server实践

    虽然HTTP/2目前已经逐渐的在各大网站上开始了使用,但是在目前最新的Node.js上仍然处于实验性API,还没有能有效解决生产环境各种问题的应用示例.因此在应用HTTP/2的道路上我自己也遇到了许多坑,下面介绍了项目的主要架构与开发中遇到的问题及解决方式,也许会对你有一点点启示. 配置 虽然W3C的规范中没有规定HTTP/2协议一定要使用ssl加密,但是支持非加密的HTTP/2协议的浏览器实在少的可怜,因此我们有必要申请一个自己的域名和一个ssl证书. 本项目的测试域名是 you.keyin.

  • 详解基于node.js的脚手架工具开发经历

    前言 我们团队的前端项目是基于一套内部的后台框架进行开发的,这套框架是基于vue和ElementUI进行了一些定制化包装,并加入了一些自己团队设计的模块,可以进一步简化后台页面的开发工作. 这套框架拆分为基础组件模块,用户权限模块,数据图表模块三个模块,后台业务层的开发至少要基于基础组件模块,可以根据具体需要加入用户权限模块或者数据图表模块.尽管vue提供了一些脚手架工具vue-cli,但由于我们的项目是基于多页面的配置进行开发和打包,与vue-cli生成的项目结构和配置有些不一样,所以创建项目

  • 详解基于Node.js的微信JS-SDK后端接口实现代码

    做了一个网站,放到线上,用微信打开,点击分享,可是分享后发给朋友的链接卡片是微信默认自带的,如下: 这标题,描述以及图片是默认自带的,丑不说,分享给别人还以为是盗号网站呢,而接入微信的JSSDK后,分享可以自定义内容,如下: 我承认,虽然这分享的标题和内容也并不正经,但这不妨碍我表达我们可以通过微信JSSDK定义分享内容,接下来我们将一步一步从零实现JSSDK从后端Node.js的接入. 成为测试公众号开发者 登录测试公众号后台 首先我们需要在微信公众平台申请测试接口,地址:https://mp

  • 详解基于 Node.js 的轻量级云函数功能实现

    导语 在万物皆可云的时代,你的应用甚至不需要服务器.云函数功能在各大云服务中均有提供,那么,如何用"无所不能"的 node.js 实现呢? 一.什么是云函数? 云函数是诞生于云服务的一个新名词,顾名思义,云函数就是在云端(即服务端)执行的函数.各个云函数相互独立,简单且目的单一,执行环境相互隔离.使用云函数时,开发者只需要关注业务代码本身,其它的诸如环境变量.计算资源等,均由云服务提供. 二.为什么需要云函数? 程序员说不想买服务器,于是便有了云服务: 程序员又说连 server 都不

  • 详解阿里Node.js技术文档之process模块学习指南

    模块概览 process是node的全局模块,作用比较直观.可以通过它来获得node进程相关的信息,比如运行node程序时的命令行参数.或者设置进程相关信息,比如设置环境变量. 环境变量:process.env 使用频率很高,node服务运行时,时常会判断当前服务运行的环境,如下所示 if(process.env.NODE_ENV === 'production'){ console.log('生产环境'); }else{ console.log('非生产环境'); } 运行命令 NODE_EN

  • 详解在node.js中require方法的加载规则

    require 方法的加载规则 优先从缓存中加载 核心模块 路径形式的模块 第三方模块 一.优先从缓存中加载 main.js:执行加载a.js模块 require('./a') a.js:执行加载b.js模块,并输出a被加载了 require('./b') console.log('a.js 被加载了') b.js:输出b被加载了 console.log('b.js 被加载了') 结果: 可以看出:main去加载a.js,然后a在去加载b.js过程中,并没有打印两次 a.js被加载,Node会直

  • 基于node.js express mvc轻量级框架实践

    本文记录的是笔者最近抽私下时间给朋友做的一个时时彩自动下注系统,比较简单,主要也是为了学习一下node.js. 其实逻辑没什么可以深谈的,主要是想说说这套代码结构.结构如下图: js的代码比较难以维护,不清楚大家对于这点是否认同,但这里笔者只说自己的感受,笔者的朋友一开始找到笔者,说玩时时彩,一直盯着玩,会因为贪心会乱来,想做个自动下注系统, 让程序自己玩.一开始,笔者也只想敷衍了事,直接拿node.js+express整了下面这套结构. 基本和express 示例代码没啥两样.但是随着需求的变

  • 详解基于React.js和Node.js的SSR实现方案

    基础概念 SSR:即服务端渲染(Server Side Render) 传统的服务端渲染可以使用Java,php 等开发语言来实现,随着 Node.js 和相关前端领域技术的不断进步,前端同学也可以基于此完成独立的服务端渲染. 过程:浏览器发送请求 -> 服务器运行 react代码生成页面 -> 服务器返回页面 -> 浏览器下载HTML文档 -> 页面准备就绪 即:当前页面的内容是服务器生成好给到浏览器的. 对应CSR:即客户端渲染(Client Side Render) 过程:浏

  • 详解用Node.js写一个简单的命令行工具

    本文介绍了用Node.js写一个简单的命令行工具,分享给大家,具体如下: 操作系统需要为Linux 1. 目标 在命令行输入自己写的命令,完成目标任务 命令行要求全局有效 命令行要求可以删除 命令行作用,生成一个文件,显示当前的日期 2. 代码部分 新建一个文件,命名为sherryFile 文件sherryFile的内容 介绍: 生成一个文件,文件内容为当前日期和创建者 #! /usr/bin/env node console.log('command start'); const fs = r

  • 详解基于node的前端项目编译时内存溢出问题

    前段时间公司有个基于vue的项目在运行npm run build的时候会报内存溢出,今天在某个技术流交群也有位小伙伴基于angular的项目也出现了这个问题,所以查了一些相关的资料总结了一下,下面会详细说明前端三大框架编译时遇到这个问题具体怎么解决.首先看我模拟出的报错内容 具体截图如下 里面有句关键的话,CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory JavaScript堆内存不足,这里说的 JavaS

随机推荐