為什麼 Nginx 已經這麼成熟，Python 還有各種如 web.py 等 web 框架？

02-09

nginx是伺服器，web.py是web應用框架。

簡言之，前者封裝對網路io的處理，後者負責具體應用的邏輯，解決的問題是不一樣的。形象點呢，一個請求來了，nginx先把請求攔下來，發現要的是現成的東西(靜態文件)，它就直接把現成的靜態文件返回給客戶端，這樣速度非常快，如果是其他的請求，再交給web.py解決，web.py解決完了之後，只是生成要返回的內容，並不自己做網路io，而是由nginx處理的。

這樣多好，一個安心處理網路、並發，順便把遇到簡單的請求直接ko掉。另一個專心處理應用的邏輯。

當然nginx能做的不只是這些，而為了開發方便web.py等框架都是內置簡單的web伺服器的。

至於tornado，它裡面既有web應用框架，也有web伺服器，而且這個伺服器用的還是高性能單線程非阻塞非同步的模型，是個例外。

Nginx 是以靜態內容和前端代理為主的伺服器，Python 的各種框架用來實現動態的邏輯。

常見搭配是 Nginx 監聽客戶端連接，直接響應靜態請求（圖片、css、js 等），然後將動態請求通過 FastCGI (web.py) 或者 proxy (Tornado) 轉發給後端的伺服器進行處理。Nginx 本身是 C 寫的，代碼效率高，支持動態平衡，比直接用 Python 面對大規模請求要穩定高效一些。

Web.py 這些框架有時候會自帶一個伺服器用作開發，但是這個伺服器（與 Python 標準庫的 SimpleHTTPServer 一樣）無法很好應對高負載情況，不應用於生產環境。

真正與 Nginx 形成競爭關係的是 Tornado 和基於 Twisted 的一些伺服器。這些伺服器本身就是為直接連接客戶端設計的，並且支持 WebSocket 等一些 Nginx 反向代理不支持的協議。在一個足夠複雜的、模塊繁多的項目中，可能出現 Nginx 支持靜態文件，Tornado 支持 comet 服務，然後某一端代理更多的業務邏輯的組合形式。

nginx更多想做代理和均衡負載，而不大可能執行過於強大的邏輯。它就像一個家長，只有權力但是不具體做事情，然後它做好家長的角色。

而衆多邏輯實現的框架比如web.py就是具體在後面跑的兒子，處理各種業務邏輯。

爲什麼nginx不也把兒子的事情做了呢？估計做不好，因爲很難用一個程序來解決所有的業務，那時候就變成另外一個語言解釋器了……龐大而複雜，不大可行。而兒子也不大可能做了家長的事情，因爲處理業務邏輯重要的是擴展性和表達力。

所以他們就分開了。。。。

把自帶的開發用的伺服器當成生產用的了？

一般使用 flask 或者 django這種應用框架都會使用uswgi這種伺服器部署，但是uswgi本身並沒有對直連客戶端做優化，因此一般都會nginx+uswgi，使用nginx連接客戶端向uswgi分發請求提高效率，這樣對uswgi來說就不存在慢io問題，也可以做動靜分離等等各種。關於Tornado之類高排名答案也說清楚了。

正面回答問題：

webstack的前世今生就是一個重複造輪的過程，它的目標是將本地程序棧弄成分散式b/s web，其實這在語言端可以做(比如語言模塊的http unit，然後是一層層我們從桌面時代開發最基本的socketapp開始，http封裝之後也許是一個aysn網路io庫，最終到達語言庫級的webframework直到專門的獨立程序支持，也許這個時候人們發現那個網路io庫可以獨立出來作為一個server，再比如第三方容器在這種需求下很容易出現，流控安全等需要也會泛濫)，於是終於發展到用獨立的伺服器OS組件來實現這些強化，形成專門的產品來做，體現在開發上首先是webserver+CGI處理。web作為b/s在架構上假設有服務端程序存在，而cgi就是開發web程序的語言同webserver交互的擴展，動態語言將運行結果轉成web page app的手段。像mod_swgi，mod_php就直接將phpcgi做到了語言。如webstack.語言則屈居之下。—— 這完全是語言，獨立件，一方做大了包裹另一方的關係但二者始終是一體的。

更多看：

enginx:一個前後端統一,生態共享的webstack實現

伺服器的「伺服器」,enginx之於分散式部署的創新意義：使任何伺服器程序秒變集群

web 伺服器？ nginx 的作者要哭了！！！！！！人家是一個好性能的io的東西