HackMD
Backend
References
- 🔗 MyApollo - 理解 Python 後端技術：從 CGI 談到 WSGI, uWSGI 與 uwsgi
- 🔗 MyApollo - 理解 Python 後端技術： ASGI - WSGI 的繼承者
Nouns
Gateway Interface
Web App 與 Web Server 溝通的協議
-
CGI (Common Gateway Interface)
- Web 伺服器在收到 request 時，如果要將 request 交由其他程式（CGI program）處理，就需要建立 1 個新的 process 執行該程式
- 該程式處理完 request 之後，就必須將 response 輸出到 STDOUT，Web 伺服器就會把這個 STDOUT 回應給使用者。
- 如果這個外部程式需要接收資料，則可以透過讀取 STDIN 得到資料，如果是需要讀取 request 相關資料，則是透過讀取環境變數取得，這些環境變數會在 Web 伺服器建立新的 process 時一併建立好。
- 這種做法天生就無法處理大量 requests，這也是為什麼我們現在少使用 CGI 的緣故。
-
FastCGI (Fast Common Gateway Interface)
… -
WSGI (Web Server Gateway Interface)
- Python 在 PEP333 提出。
- 協議分為兩端：Framework Side (Application Side) 和 Gateway Side (Server Side)
- 比如：Flask、Django 等 Web App 框架實作 Framework Side
- 比如：Gunicorn、uWSGI 等 Web Server 實作 Gateway Side
- 即便有了 uWSGI、Gunicorn 等 Web Server，還是會搭上 Nginx。
- 因為 Nginx 有反向代理的現成功能可以白嫖
- uwsgi 協定
- 用來傳送各種類型的 binary 資料的協定
-
ASGI (Asynchronous Server Gateway Interface)
- 協議分為兩端：Application 和 Protocol Server
- 比如：FastAPI 等 Web App 框架實作 Application
- 比如：Uvicorn、Hypercorn 等 Web Server 實作 Protocol Server
- 向下相容 (ASGI 相容 WSGI)
- 支援異步
- 支援 WebSockets、SSE 等 persistent connection (而非像 HTTP request 那樣短期的)
- 協議分為兩端：Application 和 Protocol Server
Web Server
Web Server 會實作 Gateway Interface 來橋接 Web App 和 HTTP requests 之間的溝通。
| Type | Example |
|---|---|
| all | Nginx, Apache2, Lighttpd |
| Python | uWSGI, Gunicorn, Uvicorn, Hypercorn |
| Java | Tomcat |
| PHP | PHP-FPM |
Forward Proxy (正向代理)
-
說明
正向代理是【client 端】的代理
正向代理位於【client 端】前方，並確保沒有 origin server 能直接與該特定 client 端通訊
- 一般 client-server 通訊
- 正向代理
-
Why?
- 替【client 端】避開國家或機構的瀏覽限制
某些政府、學校和其他組織使用防火牆，僅允許使用者存取有限版本的網際網路。正向代理可用於繞過這些限制，因為它們允許使用者連接到代理，而不是直接連接到他們正在造訪的網站。 - 封鎖【client 端】對某些內容的存取
反過來，也可以設定代理以封鎖一組使用者存取某些網站。例如，可以設定學校網路，透過啟用內容篩選規則的代理連接到 Web，拒絕轉寄來自 Facebook 和其他社交媒體網站的回應。 - 保護【client 端】的線上身分
在某些情況下，普通網際網路使用者只是希望增加線上匿名性，但在其他情況下，網際網路使用者可能生活在政府對持不同政見者施加嚴重後果的地方。在網路論壇或社交媒體上批評政府可能會導致這些使用者被罰款或監禁。如果這些持不同政見者使用正向代理連接到他們發佈政治敏感評論的網站，則更難以使用發佈評論的 IP 位址來追溯持不同政見者。因為只能看到代理伺服器的 IP 位址。
- 替【client 端】避開國家或機構的瀏覽限制
Reverse Proxy (反向代理)
-
說明
反向代理是【origin server】的代理
反向代理位於【origin server】前方，並確保沒有 client 端能直接與該 origin server 通訊
- 一般 client-server 通訊
- 反向代理
-
Why?
- 【origin server】的負載平衡
每天獲得數百萬使用者的熱門網站可能無法使用單個來源伺服器處理其所有傳入網站流量。相反，網站可以分散在不同伺服器集區中，所有伺服器都處理同一網站的請求。在這種情況下，反向代理可以提供負載平衡解決方案，該解決方案將在不同的伺服器之間均勻分配傳入流量，以防止任何單個伺服器過載。如果伺服器完全出現故障，其他伺服器可以代為處理流量。 - 防止【origin server】被攻擊
使用反向代理後，網站或服務永遠不需要顯示其來源伺服器的 IP 位址。這使得攻擊者更難利用針對性攻擊，例如 DDoS攻擊。相反，攻擊者只能針對反向代理（如 Cloudflare 的 CDN），後者將具有更嚴格的安全性和更多的資源來抵禦網路攻擊。
全球伺服器負載平衡 (GSLB)：在這種負載平衡形式中，網站可以分散在全球的多台伺服器上，反向代理會將用戶端請求傳送到地理位置上離它們最近的伺服器。這減少了請求和回應需要傳輸的距離，從而最大限度地減少載入時間。 - 快取內容 (即 CDN)
反向代理還可以快取內容，從而提高效能。例如，如果巴黎的使用者造訪網頁伺服器位於洛杉磯的反向代理網站，則該使用者實際上可能連接到巴黎的本地反向代理伺服器，然後該伺服器需要與洛杉磯的來源伺服器通訊。然後，代理伺服器可以快取（或臨時儲存）回應資料。後面瀏覽該網站的巴黎使用者將從位於巴黎的反向代理伺服器獲取本地快取版本，從而提高效能。 - SSL 加密
為每個用戶端加密和解密 SSL（或 TLS）通訊對於來源伺服器來說計算量很大。可以將反向代理設定為解密所有傳入請求並加密所有傳出回應，從而釋放來源伺服器上的寶貴資源。
- 【origin server】的負載平衡
