uWSGI 伺服器的 uwsgi 協議究竟用在何處？

01-22

uWSGI 與 python web framework（eg: django）通信現在基本基於 wsgi 那麼uWSGI 的自有協議 uwsgi 是用在 uWSGI 與 nginx 這種反代（或者前端伺服器）之間的通信嘛？如果是的話可不可以理解 uwsgi 的作用類似於 fastcgi 呢？如果不是那麼 uwsgi 協議到底用在哪裡呢？

單純協議層面個人感覺用處不大，相比 gunicorn 而言 uwsgi 用自定義協議替代 http 協議做反向代理，理論上 uwsgi 的二進位協議比 http 文本協議的 payload 開銷小，但是增加了一層複雜性，間接的一個影響是 uwsgi 的文檔會比 gunicorn 差很多，但性能沒有顯著差異。

反向代理相對於內嵌 fastcgi 的好處在於容易擴展後端實例，用 fastcgi 到需要擴展的時候，依然需要在前頭再過一層反向代理。

你理解的沒錯，WSGI是一種編程介面，而uwsgi是一種傳輸協議，從作用上來講，的確跟fastcgi是最接近的。跟fastcgi的區別在於它是面向多並發的。我們知道fastcgi是CGI的替代品，它的工作方式仍然跟CGI是類似的，當一個請求進入的時候，通過socket發送請求的環境變數，然後發送POST數據（相當於CGI的stdin），然後等待程序輸出（相當於CGI的stdout），等輸出結束後，再發送下一個請求。這就導致fastcgi最大的並發量被限制為fastcgi後端的數量，顯然這樣的伺服器模式對於並發量很大、單個請求耗時比較長的服務是不合適的，因此很多時候我們不願意使用fastcgi部屬而是使用反向代理的方式配置。

但是跟反向代理比起來，fastcgi顯然也是有好處的，最重要的好處在於解析HTTP協議的部分被offload到了前端伺服器一級，後端伺服器不再解析HTTP協議，這樣就減輕了後端的壓力，由於前端是nginx這樣用C/C++高性能實現的伺服器，比起在後端的Python當中使用腳本語言解析HTTP協議，效率要高不少。

uwsgi想要繼承fastcgi的這種好處，它通過將消息分片的方式，可以在一個socket上並發傳輸多個請求，這樣就解決了一個連接上一次只能傳輸一個請求的問題。熟悉HTTP2.0的話會發現這個分片機制跟HTTP2.0很像。

uwsgi協議是一個uWSGI伺服器自有的協議，它用於定義傳輸信息的類型（type of information），每一個uwsgi packet前4byte為傳輸信息類型描述，它與WSGI相比是兩樣東西。

參考自：uWSGI詳解 - BOKE - CSDN博客