nginx 是乙個高效能的http和反向**伺服器（關於正向**和方向**，可參考部落格：也是乙個imap/pop3/smtp伺服器。在高連線併發的情況下，nginx是apache伺服器不錯的替代品。
nginx 一般監聽伺服器的80或者443埠（listen 80 就代表監聽80埠），因為一般直接訪問**都是通過這兩個埠，一台伺服器可以繫結多個網域名稱，根據不同的網域名稱，nginx會去找不同的地方去訪問。
nginx和apache一般都作為web伺服器。至於tomcat，是乙個web應用容器，一般用於執行後台**。一般來說，使用nginx或者apache處理客戶端到伺服器的請求，然後將請求交給tomcat處理，tomcat處理後返回資料給nginx，最後nginx將客戶端請求的資料發給客戶端。
django是乙個開放源**的web應用框架，由python寫成。django不是乙個伺服器，只是乙個web的應用框架。採用了mtv的框架模式，即模型m，模板t和檢視v。
wsgi是乙個web伺服器，它實現了wsgi協議、uwsgi、http等協議。用於連線web伺服器和web應用框架。
wsgi：一種實現python解析的通用介面標準/協議，是一種通用的介面標準或者介面協議，實現了python web程式與伺服器之間互動的通用性。 利用它，web.py或bottle或者django等等的python web開發框架，就可以輕鬆地部署在不同的web server上了；那麼問題來了，這三者在一起的工作原理是什麼？uwsgi:同wsgi一樣是一種通訊協議。uwsgi協議是乙個uwsgi伺服器自有的協議，它用於定義傳輸資訊的型別，它與wsgi相比是兩樣東西。
uwsgi :一種python web server或稱為server/gateway。uwsgi類似tornadoweb或者flup，是一種python web server，uwsgi是實現了uwsgi和wsgi兩種協議的web伺服器，負責響應python 的web請求。
1. 一般來說，客戶端發起的http/https請求首先到達了我們的web伺服器（在這裡我們使用nginx作為我們的伺服器）。
2. web伺服器收到請求後，對請求進行解析處理（一般來說如果是靜態請求，直接返回靜態頁面（純html頁面）），然後將請求傳送給uwsgi。
3. uwsgi對來自nginx的請求進行處理，將處理後的結果傳送給web應用框架（在這裡我們使用django）。
4. web應用框架收到請求之後，web應用對請求進行處理（例如，django通過某個函式進行處理），將結果返回給uwsgi。
5. uwsgi收到web應用框架的處理結果後，對該結果進行處理打包，傳送給web伺服器。
6. web伺服器將收到的結果返回給客戶端。
這三者之間資訊的傳遞涉及到資料格式以及協議的轉換。
那麼為什麼我們之前在使用django開發專案的過程中， 直接使用python manage.py runserver來執行伺服器，也沒有用到其他兩個，就可以直接通過瀏覽器來訪問？那是因為django自帶了wsgiref模組，可以作為wsgi伺服器，可以對我們的http請求進行處理，但是效能不好，只能測試的時候用。到了真正部署的時候就要用到uwsgi伺服器（nginx也不是必須的，只是為了效能和安全方面的考慮，也是為了更好地處理靜態資源）。
參考資料：
Django，Nginx和uWSGI關係簡介
一 簡介 1.nginx簡介 nginx 是乙個高效能的http和反向 伺服器 關於正向 和方向 可參考部落格 也是乙個imap pop3 smtp伺服器。在高連線併發的情況下，nginx是apache伺服器不錯的替代品。nginx 一般監聽伺服器的80或者443埠 listen 80 就代表監聽8...
Django，Nginx和uWSGI關係簡介
nginx 是乙個高效能的http和反向 伺服器 關於正向 和方向 可參考部落格 也是乙個imap pop3 smtp伺服器。在高連線併發的情況下，nginx是apache伺服器不錯的替代品。nginx 一般監聽伺服器的80或者443埠 listen 80 就代表監聽80埠 因為一般直接訪問 都是通...
windows系統 python安裝uwsgi教程
直接在cmd中使用pip install uwsgi報錯 attributeerror module os has no attribute uname 報錯說明 是因為uwsgiconfig.py檔案中，os.uname 是不支援windows系統的，platform模組是支援任何系統 uwsgi...