Common Gateway Interface（CGI）是一項源自 1990 年代的網路技術，因速度過慢而被大幅棄用，如今卻在開發者中重新獲得關注。最新測試顯示，CGI 在現代硬體上能夠處理驚人的負載量，挑戰了長期以來對其限制的既定觀念。
Jake Gold 的實驗證明，基於 Go 語言的 CGI 程式在 16 執行緒的 AMD 3700X 處理器上運行，每秒可處理超過 2,400 次請求，相當於每日處理超過 2 億次請求。這樣的效能水準讓 CGI 重新回到嚴肅網路應用的競爭行列，這在幾年前似乎是不可能的事。
效能指標：
- 每秒請求數： 2,400+ 次
- 每日請求容量： 2 億+ 次
- 測試硬體： 16 執行緒 AMD 3700X 處理器
- 實作方式： Go + SQLite CGI 程式
原始問題及其持續存在的原因
CGI 的運作方式是為每個網路請求建立新的程序——啟動程式、執行程式，然後完全關閉程式。在 1990 年代後期，這種方法被證明極其緩慢，促使開發者創造了替代方案，如 PHP 的 mod_php 和 FastCGI，以便在請求之間將程式碼保持在記憶體中運行。
社群討論揭示了這個教訓如何深深植入開發者的思維中。許多程式設計師花費數十年時間避免使用每請求一程序的模式，深信這種方法存在根本性缺陷。然而，這種觀念是基於 1990 年代的運算限制，而非這種方法本身的固有問題。
歷史背景：
- 原始問題： 1990年代硬體上的程序建立開銷
- 傳統語言： Perl 、 Python 、 Java （啟動時間緩慢）
- 現代語言： Go 、 Rust （啟動時間快速）
- 安全性問題： Shellshock 漏洞（2014年）、輸入驗證疑慮
現代優勢浮現
當今的運算環境已發生劇烈變化。伺服器現在通常配備數百個 CPU 執行緒，即使是小型虛擬機器通常也有 16 個核心。更重要的是，像 Go 和 Rust 這樣的語言啟動速度遠快於早期網路開發中主導的 Perl、Python 和 Java 腳本。
每請求一程序的模式在現代環境中實際上提供了一些令人信服的優勢。每個請求都在完全隔離的環境中運行，消除了請求之間共享狀態所帶來的安全風險。這種隔離性也使 CGI 程式能夠出色地同時利用多個 CPU 核心。
「最重要的是，CGI 程式因為作為獨立程序運行，在利用多個 CPU 方面表現出色！」
安全性與效能辯論
對 CGI 的重新關注引發了關於其安全性影響的辯論。批評者指出 CGI 的安全漏洞歷史，包括其在 2014 年容易受到 Shellshock 漏洞攻擊。然而，支持者認為這些問題源於糟糕的輸入驗證實務，而非 CGI 協定本身的根本缺陷。
效能比較也引發討論。雖然使用傳統方法的 Go 程式可以輕鬆超過每秒 10,000 次請求，但並非每個應用程式都需要如此極端的效能。對許多使用案例而言，CGI 的簡潔性和隔離性優勢可能比原始速度更重要。
CGI 與現代替代方案比較：
- CGI 優勢： 完整的程序隔離，優秀的多核心利用率
- 傳統方法： 使用 Go 可達到每秒 10,000+ 次請求
- 權衡考量： 安全性與簡潔性 vs 原始效能
- 使用案例： 快速原型開發、多語言應用程式、客戶擴充功能
當今的實際應用
CGI 的復興不僅僅是學術好奇心。開發者正在找到實際應用，特別是用於快速原型開發和建立多語言網路應用程式，其中不同的程式語言處理不同的 URL 路徑。這種方法也很適合讓客戶使用自訂程式碼擴展軟體，而無需複雜的整合框架。
像 h2o 這樣的現代網路伺服器正在擁抱這一趨勢，提供簡潔的設定檔案，使 CGI 部署變得直接了當。一些開發者甚至認為 CGI 比專有的 lambda 函數更適合作為無伺服器運算的基礎，因為它基於開放標準而非供應商特定的實作。
CGI 的回歸代表了一個引人入勝的例子，說明不斷變化的技術如何能夠重新振興看似過時的方法。雖然它可能不會完全取代現代網路框架，但 CGI 的簡潔性和隔離性特質使其值得在特定應用中重新考慮。