TA貢獻(xiàn)1810條經(jīng)驗(yàn) 獲得超4個(gè)贊
將另一個(gè)Web服務(wù)器置于Node.js前面有幾個(gè)充分的理由：
不必?fù)?dān)心Node.js進(jìn)程的特權(quán)/ setuid。通常只有root可以綁定到端口80。如果讓nginx / Apache擔(dān)心以root用戶身份啟動(dòng)，綁定到端口80，然后放棄其root特權(quán)，則意味著您的Node應(yīng)用程序不必?fù)?dān)心。
提供靜態(tài)文件，例如圖片，css，js和html。與使用適當(dāng)?shù)撵o態(tài)文件Web服務(wù)器相比，Node的效率可能較低（Node在某些情況下也可能更快，但這不太可能成為常態(tài)）。除了可以更高效地提供文件之外，您不必?fù)?dān)心像在Node之外提供服務(wù)時(shí)那樣處理eTag或緩存控件標(biāo)頭。某些框架可能會(huì)為您解決此問題，但您需要確定。無論如何，仍然可能會(huì)更慢。
正如Matt Sergeant在回答中提到的那樣，如果節(jié)點(diǎn)服務(wù)崩潰，您可以更輕松地顯示有意義的錯(cuò)誤頁面或退回到靜態(tài)站點(diǎn)。否則，用戶可能只會(huì)獲得超時(shí)連接。
在Node前面運(yùn)行另一臺(tái)Web服務(wù)器可能有助于減輕針對Node的安全漏洞和DoS攻擊。對于一個(gè)實(shí)際示例，通過在Node前面運(yùn)行Nginx之類的內(nèi)容來防止CVE-2013-4450。
我要說明第二點(diǎn)，說您可能應(yīng)該通過CDN或從類似Varnish的緩存服務(wù)器后面來提供靜態(tài)文件。如果執(zhí)行此操作，則起源不是Node還是Nginx或Apache都沒有關(guān)系。
請?zhí)貏e注意nginx：如果您使用的是websocket，請確保使用最新版本的nginx（> = 1.3.13），因?yàn)樗鼉H添加了對升級升級以使用websocket的支持。
TA貢獻(xiàn)1818條經(jīng)驗(yàn) 獲得超11個(gè)贊
只是為了給pauljz的答案增加一個(gè)原因，我使用了前端服務(wù)器，這樣當(dāng)我重新啟動(dòng)后端服務(wù)器或由于某種原因崩潰時(shí)，它可以提供502個(gè)錯(cuò)誤頁面。這使您的用戶永遠(yuǎn)不會(huì)收到有關(guān)無法建立連接的錯(cuò)誤。
TA貢獻(xiàn)1934條經(jīng)驗(yàn) 獲得超2個(gè)贊
我相信，只要您知道自己在做什么，就可以在所有情況下使用Node服務(wù)靜態(tài)文件。使用應(yīng)用服務(wù)器來服務(wù)于靜態(tài)文件無疑是一種新的范例，因?yàn)樵S多（每一個(gè)？）競爭技術(shù)（PHP，Ruby，Python等）都需要在應(yīng)用服務(wù)器之前使用HTTPD或Nginx之類的Web服務(wù)器。 。
我曾經(jīng)閱讀過的反對使用Node服務(wù)靜態(tài)文件的客觀原因都圍繞著使用您最了解的知識(shí)或使用經(jīng)過更好測試/更穩(wěn)定的知識(shí)的想法。從實(shí)踐上講，這是非常有效的原因，但幾乎沒有技術(shù)上的相關(guān)性。
除非您發(fā)現(xiàn)經(jīng)典Web服務(wù)器無法使用Node所具有的功能（我懷疑您會(huì)做到），否則請選擇您最了解的知識(shí)或希望使用的方法，因?yàn)檫@兩種方法都很好。
至于Nginx與Apache的關(guān)系，它們將與Node相同。您應(yīng)該比較它們而不考慮Node。
舉報(bào)