node.js - node.js 应该监听哪些端口？如何以及为什么？

Question

我的 node.js 应用程序在端口 80 上监听 http 和 443 端口，我认为这是相当标准的做法。

然而，我最近阅读的许多示例使用其他端口(例如 8080 和 8081)来监听 http/https，然后使用其他方式(例如 iptables)或 ufw通过将数据包重新路由到其他端口/从其他端口来服务端口 80/443 的规则。

看两个例子here和 here .

所以我的问题是为什么我不想直接监听端口 80 和 443？

手头有安全问题吗？这仅仅是这些作者没有权限监听低于 1024 的端口的情况吗(我觉得这很奇怪？)？大多数人都在辅助 Node 上运行 Apache 吗？ (我没有)。

假设我不想直接监听 80 和/或 443 有充分的理由，我应该使用哪种方法将流量从 80/433 中继到我选择的替代端口？

我在上面提到了 iptables 和 ufw，其中一个比其他的更好，还是我应该使用其他方法？答案是否取决于我是否在进程之间平衡负载？

提前致谢。

Answer 1

您链接到的第一篇文章的第一行提到了原因。

Standard practices say no non-root process gets to talk to
the Internet on a port less than 1024.

要将 Node 绑定(bind)到端口 80 或 443，您需要以 root 身份运行它，这不是一个好主意。

用于将流量重新路由到更高端口的方法由您决定。 iptables 是资源密集度最低且最简单的。另一种方法是使用 NginX/Apache 代理到 Node。我想说该方法的主要好处是您还可以从那里提供诸如静态文件之类的东西，而不必通过 Node 提供它们。

Apache 和 NginX 都被明确设计为非常擅长提供静态文件，因此它们非常擅长，而 Node 是一个完整的 JS 环境，涉及所有开销。 Node 非常擅长处理大量并发连接，它当然可以完美地处理正常负载的文件，但它会使用比 NginX 更多的资源来完成它。

使用 Apache/NginX 等支持 HTTP 的代理还意味着您可以非常轻松地设置多个 Node 实例以运行不同的子域，甚至是同一域中的不同路径。