FastCGI

快速通用網關接口（Fast Common Gateway Interface／FastCGI）是一種讓交互程序與Web服務器通信的協議。FastCGI是早期通用網關接口（CGI）的增強版本。

FastCGI致力於減少網頁伺服器與CGI程式之間互動的開銷，從而使伺服器可以同時處理更多的網頁請求。

歷史

通用網關接口協議（CGI）是一種對接應用程序和網絡服務器的接口協議。CGI使外部程式與Web伺服器之間交互成為可能。CGI程式運行在獨立的進程中，並對每個Web請求建立一個進程，這種方法非常容易實現，但效率較差，難以擴展。

CGI程式運行在獨立的進程中，並對每個Web請求建立一個進程，在結束時銷毀。這種「每個請求一個新進程」的模型使得CGI程序非常容易實現，但效率較差，難以擴展。在高負載情況下，進程創建和銷毀進程的開銷變得很大。此外，由於地址空間無法共享，CGI進程模型限制了資源重用方法，如重用數據庫連接、內存緩存等。

為了解決CGI的可伸縮性缺點，Open Market開發了FastCGI，並在20世紀90年代中期首次在他們的網絡服務器產品中引入了它。Open Market最初開發FastCGI的部分原因是作為對網景公司開發網絡應用程序的專有、進程內API(網景服務器API)的競爭回應。

雖然FastCGI最初是由Open Market開發的，但後來被其他幾家網絡服務器製造商實施。然而，它的方法與其他加速和簡化服務器-子程序通信的方法相競爭。像mod_perl和mod_php這樣的Apache HTTP服務器模塊幾乎是同時出現的，並且很快流行起來。截至2019年，包括CGI在內的所有這些不同方法仍在普遍使用。

實現

與為每個請求創建一個新的進程不同，FastCGI使用持續的進程來處理一連串的請求。這些進程由FastCGI服務器管理，而不是web服務器。

當進來一個請求時，web服務器把環境變量和這個頁面請求通過一個socket比如FastCGI進程與web服務器（都位於本地）或者一個TCP 請求（FastCGI進程在遠端的server farm）傳遞給FastCGI進程。

服務傳入請求時，網絡服務器通過Unix域套接字、命名管道或TCP連接向FastCGI進程發送環境變量信息和頁面請求。響應通過相同的連接從進程返回到網絡服務器，然後網絡服務器將該響應傳遞給最終用戶。連接可能在響應結束時關閉，但是web服務器和FastCGI服務進程都將持續，不會被銷毀。

每個單獨的FastCGI進程在其生命周期內可以處理許多請求，從而避免了每個請求進程創建和終止的開銷。並發處理多個請求可以通過幾種方式來完成:通過內部多路復用使用一個連接(即一個連接上的多個請求)；通過使用多個連接；或者通過這些方法的混合。可以配置多個FastCGI服務器，提高穩定性和可擴展性。

優點

網站管理員和程序員可以發現，在FastCGI中將網絡應用程序與網絡服務器分離比嵌入式解釋器(mod_perl、mod_php等)有許多優點。這種分離允許服務器和應用程序進程獨立重啟——這是繁忙網站的一個重要考慮因素。它還能夠實現每個應用程序的託管服務安全策略，這是對ISPs和網絡託管公司的一個重要要求。不同類型的傳入請求可以分發到特定的FastCGI服務器，這些服務器已被配置為高效地處理這些類型的請求。

實作FastCGI的網頁伺服器

• Apache HTTP Server (部分)
  • 通過mod_fcgid模塊實現。這個模塊曾屬於第三方，但是在2009年被授予ASF，成為Apache的一個子項目。它只支持Unix域套接字，不支持TCP套接字。
  • 一個較早的第三方模塊 mod_fastcgi 。但是這個模塊從Apache 2.4.x 開始就不再被一同編譯了。 雖然這個模塊相關的bug早就被解決了。
  • Apache 1.x 在設計上禁止多路復用單個連接接收請求，因此Aapache 1.x是不支持的。
  • 在 Aapache 2.4 中，添加了新的mod_proxy_fcgi模塊，支持TCP FastCGI服務器。
• Caddy
• Cherokee HTTP Server
• Hiawatha Webserver
  • 支持FastCGI的負載平衡
  • 支持chrooted FastCGI 伺服器
• Lighttpd
• Nginx
• LiteSpeed Web Server
• Microsoft IIS
• Jetty
• Kerio WebSTAR
• OpenBSD 的 httpd(8)
• Open Market 網絡服務器

參見

• CGI
• IIS
• nginx