一、WSGI 協議

是一種協議規範，起到規範引數的做用，就像告訴公路同樣，規定超車靠右行，速度不低於90km/h，等。但這一切都是對雙方進行溝通，好比重慶到武漢這條高速路，這兒重慶和武漢就各為一端，他們之間的行車規範就按照WSGI規則便可。如今須要記住，WSGI溝通的雙方是wsgi server (好比uWSGI） 要和 wsgi application（好比django ）

wsgi server (好比uWSGI）實現wsgi協議規範的伺服器咱們叫作wsgi伺服器，也就是uWSGI伺服器，wsgi application（好比django ）實現wsgi協議的應用，咱們叫作wsgi應用，好比Django，Falsk

二、uWSGI

是一個web伺服器，或者wsgi server伺服器，他的任務就是接受使用者請求，因為使用者請求是經過網路發過來的，其中使用者到伺服器端之間用的是http協議，因此咱們uWSGI要想接受而且正確解出相關資訊，咱們就須要uWSGI實現http協議，沒錯，uWSGI裡面就實現了http協議。因此如今咱們uWSGI能準確接受到使用者請求，而且讀出資訊。

如今咱們的uWSGI伺服器須要把資訊發給Django，咱們就須要用到WSGI協議，恰好uWSGI實現了WSGI協議，因此。uWSGI把接收到的資訊做一次簡單封裝傳遞給Django，Django接收到資訊後，再通過一層層的中介軟體，因而，對資訊做進一步處理，最後匹配url，傳遞給相應的檢視函式，檢視函式作邏輯處理，而後將處理後的資料經過中介軟體一層層返回，到達Djagno最外層，而後，經過WSGI協議將返回資料返回給uWSGI伺服器，uWSGI伺服器經過http協議將資料傳遞給使用者，這就是整個流程

這個過程當中咱們彷佛沒有用到uwsgi協議，可是他也是uWSGI實現的一種協議，魯迅說過，存在即合理，因此說，他確定在某個地方用到了。咱們過一會再來討論nginx

咱們能夠用這條命令：python manage.py runserver，啟動Django自帶的伺服器。DJango自帶的伺服器（runserver 起來的 HTTPServer 就是 Python 自帶的 simple_server）。是預設是單程序單多執行緒的，對於同一個http請求，老是先執行一個，其餘等待，一個一個序列執行。沒法並行。並且django自帶的web伺服器效能也很差，只能在開發過程當中使用。因而咱們就用uWSGI代替了。可是uWSGI也不夠好

三、為何有了uWSGI為何還須要nginx

由於nginx具有優秀的靜態內容處理能力，而後將動態內容轉發給uWSGI伺服器，這樣能夠達到很好的客戶端響應。支援的併發量更高，方便管理多程序，發揮多核的優點，提高效能。這時候nginx和uWSGI之間的溝通就要用到uwsgi協議。

django 的併發能力真的是使人擔心，這裡就使用 nginx + uwsgi 提供高併發。

nginx 的併發能力超高，單臺併發能力過萬（這個也不是絕對），在純靜態的 web 服務中更是突出其優越的地方，因為其底層使用 epoll 非同步IO模型進行處理，使其深受歡迎伺服器。

Python須要使用nginx + uWSGI 提供靜態頁面訪問，和高併發多執行緒

php 須要使用 nginx + fastcgi 提供高併發，

java 須要使用 nginx + tomcat 提供 web 服務

Python由於GIL的存在，在一個程序中，只容許一個執行緒工做，致使單程序多執行緒沒法利用多核

多程序的執行緒之間不存在搶GIL的狀況，每一個程序有一個本身的執行緒鎖，多程序多GIL

四、可以用一個例子來進行說明

Nginx：Hey，WSGI，我剛收到了一個請求，我需要你作些準備，然後由Django來處理這個請求。

WSGI：OK，Nginx。我會設定好環境變數，然後將這個請求傳遞給django處理。

django：Thanks WSGI！給我一些時間，我將會把請求的響應返回給你。

WSGI：Alright，那我等你。

django：Okay，我完成了，這裡是請求的響應結果，請求把結果傳遞給Nginx。

WSGI：Good job！Nginx，這裡是響應結果，已經按照要求給你傳遞回來了。

Nginx：Cool，我收到了，我把響應結果返回給客戶端。大家合作愉快~