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