今天就跟大家聊聊有关节点。js中使用反向代理的原因是什么,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
<强>反向代理是什么?
一个反向代理(反向代理)基本上就是一种用于接受请求并将它们转发到某处的另一个HTTP服务器上的特殊网络,服务器,也会接受响应并转发回给原始的请求者。
反向代理通常不会精确地发送原始请求,典型的做法是会在某些方面对请求作出修改。例如,如果反向代理位于www.example.org: 80并转发请求到,ex.example.org: 8080年的话,大概就是它重写了原始的主机头,以匹配目标地址。反向代理也可能通过其他方式修改请求,比如清理一个有缺陷的请求或是在协议之间作出转换。
一旦反向代理收到一个响应,可能也会对其进行某方面的转换。常用的途径同样是修改主机头以匹配原始请求。
请求的身体也能被修改。一种通常的修改是在响应时执行gzip压缩。另一种常见改变是当基础服务只是HTTP时启用HTTPS支持。
反向代理也可以将到来的请求分发给多个后端实例。如果一个服务暴露于api.example.org,那么一个反向代理可以转发请求到,api1.internal.example.org, api2.internal.example.org等处。
有很多种不同的反向代理。两种更流行的分别是Nginx和HAProxy。这两种工具都能够执行gzip压缩和增加HTTPS,支持,它们也能很好地适用于其它领域.Nginx,更流行一些,并且也有诸如从文件系统运行静态文件服务器等一些其它有益的能力,所以我们将在本文中使用它作为例子。
现在我们知道何为反向代理了,下面来看看为何我们要将其用于node . js。
<强>为何应该使用一个反向代理吗?
<强> SSL终端
SSL终端是使用反向代理的最主要原因之一。将一个应用的协议从http变为https可不止添加一个年代字母那么简单.Node。js本身能够,对https执行必要的加密和解密,也能被配置为读取必要的证书文件。
但是,配置一个用于和我们的应用通信的协议,并管理一个永不过期的SSL,凭证,并非真的是我们的应用需要关注的事情。检查一个代码库中的证书不只是麻烦,同时也是一种安全风险。在应用启动时从特定位置获取证书也有其风险。
有鉴于此,最好在应用之外执行SSL终端,通常就由一个反向代理来承担。受惠于像certbot这样的技术,通过Nginx,维护证书也像设置一个定时任务一样简单。这样的一个任务可以自动安装新证书并动态重配置Nginx进程。与重启每个节点。js,应用实例相比,这是一个破坏性小得多的过程。
同时,通过允许一个反向代理来执行SSL终端,这也意味着只有被反向代理的作者编写的代码可以访问你的私有SSL证书。反之,如果由你的,节点。js应用处理SSL,那么你的应用用到的每一个单独的第三方模块,即便是潜在的恶意模块,都能访问你的私有SSL证书了。
<强> gzip压缩
gzip是另一个你应该由应用让渡到反向代理的特性.gzip压缩策略最好在管理级别设置,而不是不得不为每个应用指定和配置。
最好使用某些逻辑来决定对什么采用gzip。例如,很小的文件,或许比1 kb还小的,或许就不值得压缩,因为其gzip,压缩版本没准会变得更大,亦或客户端对其解压的CPU开销也更不划算。同时,当处理二进制数据时,取决于其格式可能也无法从压缩中获益。有时gzip,也无法被简单地启用或禁用,为了兼容压缩算法需要检查接收到的接受编码头。
<强>集群化
JavaScript是一种单线程语言,相应的,节点。js天然也是一种单线程的服务器平台(尽管节点。js v10中开始出现的实验性,工人线程支持致力于改变这一点)。这意味着要从一个节点。js应用中获取尽可能更大的吞吐量需要运行和CPU核数差不多相同的实例数量。
节点。js自带的集群模块可以实现集群化。收到的HTTP请求将会被交给一个主进程而后再被分发给集群,工人。
但是,动态伸缩集群工人会有点费劲。通常也会通过运行一个额外的节点。js,进程作为分发主进程来增加吞吐量。但是,跨机器伸缩进程对于集群来说还是有点强人所难了。
基于这些原因,有时使用一个反向代理来分发正在运行的节点。js,进程会更好。反向代理能被动态配置以指向新出现的应用进程。说实在的,一个应用就应该只关注其自身的工作,而不是管理多个拷贝并分发请求。
<>强企业路由
