9

私の node.js アプリケーションは、http の場合はポート 80、https の場合は 443 でリッスンしています。これはかなり標準的な方法だと思います。

ただし、最近読んだ多くの例では、http/https をリッスンするために他のポート (8080 や 8081 など) を使用し、iptablesまたはufwルールなどの他の手段を使用して、パケットを他のポートとの間で再ルーティングすることにより、ポート 80/443 にサービスを提供しています。

こちらとこちらの 2 つの例を参照してください。

私の質問は、ポート 80 と 443 を直接リッスンしたくないのはなぜですか?

セキュリティ上の問題はありますか？これらの作成者が 1024 未満のポートでリッスンする権限を持っていないという単純なケースですか (これは驚くべきことだと思いますか?)。ほとんどの人はサイドノードで Apache を実行しますか? （私はしません）。

80 や 443 を直接リッスンしたくない正当な理由があると仮定すると、80/433 から選択した代替ポートにトラフィックを中継するには、どの方法を使用すればよいでしょうか?

上記で iptables と ufw について言及しましたが、これらのうちの 1 つが他のものよりも優れているのでしょうか、それとも他に使用すべき方法がありますか? 答えは、プロセス間で負荷を分散しているかどうかによって異なりますか?

前もって感謝します。

4

1 に答える 1

16

リンク先の最初の記事の最初の行に理由が記載されています。

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

80ノードをポートまたはにバインドするに443は、ルートとして実行する必要がありますが、これはお勧めできません。

より高いポートにトラフィックを再ルーティングするために使用する方法は、あなた次第です。iptablesは、リソースの消費が最も少なく、最も単純です。もう 1 つの方法は、NginX/Apache を使用して Node.js にプロキシすることです。その方法の主な利点は、そこから静的ファイルなどを提供できることであり、Node.js を介してそれらを提供する必要はありません。

Apache と NginX は両方とも、静的ファイルの提供に非常に優れているように明確に設計されているため、非常に優れていますが、Node はすべてのオーバーヘッドを伴う完全な JS 環境です。ノードは多数の同時接続を処理するのに優れており、通常のロードではファイルを完全に適切に処理できますが、NginX よりも多くのリソースを使用します。

Apache/NginX のような HTTP 対応のプロキシを使用すると、Node の複数のインスタンスを非常に簡単にセットアップして、異なるサブドメインを実行したり、同じドメインで異なるパスを実行したりすることもできます。

于 2013-02-18T15:05:38.130 に答える