[[123090]]

CGI

CGI即通用網關接口(Common Gateway Interface)，是外部應用程序(CGI程序)與Web服務器之間的接口標準，是在CGI程序和Web服務器之間傳遞信息的規程。CGI規范允許Web服務器執行外部程序，并將它們的輸出發送給Web瀏覽器，CGI將Web的一組簡單的靜態超媒體文檔變成一個完整的新的交互式媒體。通俗的講CGI就像是一座橋，把網頁和WEB服務器中的執行程序連接起來，它把HTML接收的指令傳遞給服務器的執行程序，再把服務器執行程序的結果返還給HTML頁。CGI 的跨平臺性能***，幾乎可以在任何操作系統上實現。

CGI方式在遇到連接請求(用戶請求)先要創建cgi的子進程，激活一個CGI進程，然后處理請求，處理完后結束這個子進程。這就是fork-and-execute模式。所以用cgi方式的服務器有多少連接請求就會有多少cgi子進程，子進程反復加載是cgi性能低下的主要原因。當用戶請求數量非常多時，會大量擠占系統的資源如內存，CPU時間等，造成效能低下。

CGI腳本工作流程：

● 瀏覽器通過HTML表單或超鏈接請求指向一個CGI應用程序的URL。

● 服務器收發到請求。

● 服務器執行所指定的CGI應用程序。

● CGI應用程序執行所需要的操作，通常是基于瀏覽者輸入的內容。

● CGI應用程序把結果格式化為網絡服務器和瀏覽器能夠理解的文檔(通常是HTML網頁)。

● 網絡服務器把結果返回到瀏覽器中。

FastCGI

FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間通信的接口。多數流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等，同時，FastCGI也被許多腳本語言所支持，其中就有PHP。

FastCGI是從CGI發展改進而來的。傳統CGI接口方式的主要缺點是性能很差，因為每次HTTP服務器遇到動態程序時都需要重新啟動腳本解析器來執行解析，然后結果被返回給HTTP服務器。這在處理高并發訪問時，幾乎是不可用的。FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行著，只要激活后，不會每次都要花費時間去fork一次(這是CGI最為人詬病的fork-and-execute 模式)。CGI 就是所謂的短生存期應用程序，FastCGI 就是所謂的長生存期應用程序。由于 FastCGI 程序并不需要不斷的產生新進程，可以大大降低服務器的壓力并且產生較高的應用效率。它的速度效率最少要比CGI 技術提高 5 倍以上。它還支持分布式的運算, 即 FastCGI 程序可以在網站服務器以外的主機上執行并且接受來自其它網站服務器來的請求。

FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內存中并因此獲得較高的性能。眾所周知，CGI解釋器的反復加載是CGI性能低下的主要原因，如果CGI解釋器保持在內存中并接受FastCGI進程管理器調度，則可以提供良好的性能、伸縮性、Fail-Over特性等等。FastCGI接口方式采用C/S結構，可以將HTTP服務器和腳本解析服務器分開，同時在腳本解析服務器上啟動一個或者多個腳本解析守護進程。當HTTP服務器每次遇到動態程序時，可以將其直接交付給FastCGI進程來執行，然后將得到的結果返回給瀏覽器。這種方式可以讓HTTP服務器專一地處理靜態請求或者將動態腳本服務器的結果返回給客戶端，這在很大程度上提高了整個應用系統的性能。

FastCGI的工作流程:

● Web Server啟動時載入FastCGI進程管理器(PHP-CGI或者PHP-FPM或者spawn-cgi)

● FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程(可見多個php-cgi)并等待來自Web Server的連接。

● 當客戶端請求到達Web Server時，FastCGI進程管理器選擇并連接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。

● FastCGI子進程完成處理后將標準輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接著等待并處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 在CGI模式中，php-cgi在此便退出。

FastCGI 的特點

打破傳統頁面處理技術。傳統的頁面處理技術，程序必須與 Web 服務器或 Application 服務器處于同一臺服務器中。這種歷史已經早N年被FastCGI技術所打破，FastCGI技術的應用程序可以被安裝在服務器群中的任何一臺服務器，而通過 TCP/IP 協議與 Web 服務器通訊，這樣做既適合開發大型分布式 Web 群，也適合高效數據庫控制。

明確的請求模式。CGI 技術沒有一個明確的角色，在 FastCGI 程序中，程序被賦予明確的角色(響應器角色、認證器角色、過濾器角色)。

ISAPI

ISAPI(Internet Server Application Program Interface)是微軟提供的一套面向WEB服務的API接口，它能實現CGI提供的全部功能，并在此基礎上進行了擴展，如提供了過濾器應用程序接口。ISAPI應用大多數以DLL動態庫的形式使用，可以在被用戶請求后執行，在處理完一個用戶請求后不會馬上消失，而是繼續駐留在內存中等待處理別的用戶輸入。此外,ISAPI的DLL應用程序和WEB服務器處于同一個進程中，效率要顯著高于CGI。(由于微軟的排他性，只能運行于windows環境)

ISAPI服務器擴展為使用 Internet 服務器的通用網關接口(CGI) 應用程序提供了另一種選擇。與 CGI 應用程序不同，ISA 在 HTTP服務器所在的同一地址空間運行，并且可以訪問可由 HTTP 服務器使用的所有資源。ISA 的系統開銷比 CGI 應用程序低，因為它們不要求創建其他進程，也不執行需要越過進程邊界的通信，而這種通信非常耗時。如果內存被其他進程所需要，擴展和篩選器DLL 都可能被卸載。ISAPI 允許在一個 DLL 中有多個命令，這些命令作為 DLL 中CHttpServer對象的成員函數來實現。CGI 要求每個任務有一個單獨的名稱和一個到單獨的可執行文件的 URL 映射。每個新的 CGI 請求啟動一個新進程，而每個不同的請求包含在各自的可執行文件中，這些文件根據每個請求加載和卸載，因此系統開銷高于 ISA。

PHP-CGI

PHP-CGI是PHP自帶的FastCGI管理器。PHP-CGI的不足：

● php-cgi變更php.ini配置后需重啟php-cgi才能讓新的php-ini生效，不可以平滑重啟

● 直接殺死php-cgi進程php就不能運行了。(PHP-FPM和Spawn-FCGI就沒有這個問題,守護進程會平滑從新生成新的子進程。)

Spawn-FCGI

Spawn-FCGI是一個通用的FastCGI管理服務器，它是lighttpd中的一部份，很多人都用Lighttpd的Spawn-FCGI進行FastCGI模式下的管理工作，不過有不少缺點。而PHP-FPM的出現多少緩解了一些問題，但PHP-FPM有個缺點就是要重新編譯，這對于一些已經運行的環境可能有不小的風險)，在php 5.3.3中可以直接使用PHP-FPM了。Spawn-FCGI的代碼很少，全部才630行，用c語言編寫，最近一次提交是5年前。代碼主頁：https://github.com/lighttpd/spawn-fcgi

Spawn-FCGI代碼分析如下：

spawn-fcgi 首先create socket,bind,listen 3步創建服務器socket,(把這個socket叫做 fcgi_fd)

用dup2，把fcgi_fd 交換給 FCGI_LISTENSOCK_FILENO (FCGI_LISTENSOCK_FILENO數值上等于0，這是fastcgi協議當中指定用來listen的socket id)

● 執行execl ,replaces the current process image with a new process image. process image 進程在運行空間的代碼段

很顯然，Spawn-FCGI也是 pre-fork 模型，只是用了上古C語言編寫，充滿了N多 unix下暗黑編程技巧。

Spawn-FCGI功能很單一：

● 只管fork進程，子進程掛了，主進程僅僅log記錄一次，根本不會重新fork。在2009年一段時間內，我曾經用spawn-fcgi部署php-cgi，當跑一段時間就會全掛掉，只能用crontab定時重啟spawn-fcgi

● 不負責子進程中的網絡IO，把socket放到指定位置就完了，接下來的事情由被spawn的程序處理

Spawn-FCGI是一個很早期的程序，瞻仰一下即可。另外有：1996年的一段代碼:http://www.fastcgi.com/om_archive/kit/cgi-fcgi/cgi-fcgi.c，和spawn-fcgi一個風格#p#

PHP-FPM

PHP-FPM是一個PHP FastCGI管理器，是只用于PHP的,可以在 http://php-fpm.org/download下載得到。PHP-FPM其實是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP后才可以使用。FPM(FastCGI 進程管理器)用于替換 PHP-CGI 的大部分附加功能，對于高負載網站是非常有用的。它的功能包括：

● 支持平滑停止/啟動的高級進程管理功能;

● 可以工作于不同的 uid/gid/chroot 環境下，并監聽不同的端口和使用不同的 php.ini 配置文件(可取代 safe_mode 的設置);

● stdout 和 stderr 日志記錄;

● 在發生意外情況的時候能夠重新啟動并緩存被破壞的 opcode;

● 文件上傳優化支持;

● “慢日志” - 記錄腳本(不僅記錄文件名，還記錄 PHP backtrace 信息，可以使用 ptrace或者類似工具讀取和分析遠程進程的運行數據)運行所導致的異常緩慢;

● fastcgi_finish_request() - 特殊功能：用于在請求完成和刷新數據后，繼續在后臺執行耗時的工作(錄入視頻轉換、統計處理等);

● 動態/靜態子進程產生;

● 基本 SAPI 運行狀態信息(類似Apache的 mod_status);

● 基于 php.ini 的配置文件。

WSGI

Web服務器網關接口(Python Web Server Gateway Interface，縮寫為WSGI)是為Python語言定義的Web服務器和Web應用程序或框架之間的一種簡單而通用的接口。自從WSGI被開發出來以后，許多其它語言中也出現了類似接口。WSGI是作為Web服務器與Web應用程序或應用框架之間的一種低級別的接口，以提升可移植Web應用開發的共同點。WSGI是基于現存的CGI標準而設計的。

WSGI區分為兩個部份：一為“服務器”或“網關”，另一為“應用程序”或“應用框架”。在處理一個WSGI請求時，服務器會為應用程序提供環境資訊及一個回呼函數(Callback Function)。當應用程序完成處理請求后，透過前述的回呼函數，將結果回傳給服務器。所謂的 WSGI 中間件同時實現了API的兩方，因此可以在WSGI服務和WSGI應用之間起調解作用：從WSGI服務器的角度來說，中間件扮演應用程序，而從應用程序的角度來說，中間件扮演服務器。“中間件”組件可以執行以下功能：

● 重寫環境變量后，根據目標URL，將請求消息路由到不同的應用對象。

● 允許在一個進程中同時運行多個應用程序或應用框架。

● 負載均衡和遠程處理，通過在網絡上轉發請求和響應消息。

● 進行內容后處理，例如應用XSLT樣式表。

以前，如何選擇合適的Web應用程序框架成為困擾Python初學者的一個問題，這是因為，一般而言，Web應用框架的選擇將限制可用的Web服務器的選擇，反之亦然。那時的Python應用程序通常是為CGI，FastCGI，mod_python中的一個而設計，甚至是為特定Web服務器的自定義的API接口而設計的。WSGI沒有官方的實現, 因為WSGI更像一個協議。只要遵照這些協議,WSGI應用(Application)都可以在任何服務器(Server)上運行, 反之亦然。WSGI就是Python的CGI包裝，相對于Fastcgi是PHP的CGI包裝。

WSGI將 web 組件分為三類： web服務器，web中間件,web應用程序， wsgi基本處理模式為 ： WSGI Server -> (WSGI Middleware)* -> WSGI Application 。

 

 

1、WSGI Server/gateway

wsgi server可以理解為一個符合wsgi規范的web server，接收request請求，封裝一系列環境變量，按照wsgi規范調用注冊的wsgi app，***將response返回給客戶端。文字很難解釋清楚wsgi server到底是什么東西，以及做些什么事情，最直觀的方式還是看wsgi server的實現代碼。以python自帶的wsgiref為例，wsgiref是按照wsgi規范實現的一個簡單wsgi server。它的代碼也不復雜。

 

 

● 服務器創建socket，監聽端口，等待客戶端連接。

● 當有請求來時，服務器解析客戶端信息放到環境變量environ中，并調用綁定的handler來處理請求。

● handler解析這個http請求，將請求信息例如method，path等放到environ中。

● wsgi handler再將一些服務器端信息也放到environ中，***服務器信息，客戶端信息，本次請求信息全部都保存到了環境變量environ中。

● wsgi handler 調用注冊的wsgi app，并將environ和回調函數傳給wsgi app

● wsgi app 將reponse header/status/body 回傳給wsgi handler

● 最終handler還是通過socket將response信息塞回給客戶端。

2、WSGI Application

wsgi application就是一個普通的callable對象，當有請求到來時，wsgi server會調用這個wsgi app。這個對象接收兩個參數，通常為environ,start_response。environ就像前面介紹的，可以理解為環境變量，跟一次請求相關的所有信息都保存在了這個環境變量中，包括服務器信息，客戶端信息，請求信息。start_response是一個callback函數，wsgi application通過調用start_response，將response headers/status 返回給wsgi server。此外這個wsgi app會return 一個iterator對象 ，這個iterator就是response body。這么空講感覺很虛，對著下面這個簡單的例子看就明白很多了。

3、WSGI MiddleWare

有些功能可能介于服務器程序和應用程序之間，例如，服務器拿到了客戶端請求的URL, 不同的URL需要交由不同的函數處理，這個功能叫做 URL Routing，這個功能就可以放在二者中間實現，這個中間層就是 middleware。middleware對服務器程序和應用是透明的，也就是說，服務器程序以為它就是應用程序，而應用程序以為它就是服務器。這就告訴我們，middleware需要把自己偽裝成一個服務器，接受應用程序，調用它，同時middleware還需要把自己偽裝成一個應用程序，傳給服務器程序。

其實無論是服務器程序，middleware 還是應用程序，都在服務端，為客戶端提供服務，之所以把他們抽象成不同層，就是為了控制復雜度，使得每一次都不太復雜，各司其職。

uWCGI

uWSGI 項目旨在為部署分布式集群的網絡應用開發一套完整的解決方案。uWSGI主要面向web及其標準服務，已經成功的應用于多種不同的語言。由于uWSGI的可擴展架構，它能夠被無限制的擴展用來支持更多的平臺和語言。目前，你可以使用C，C++和Objective-C來編寫插件。項目名稱中的“WSGI”是為了向同名的Python Web標準表示感謝，因為WSGI為該項目開發了***個插件。uWSGI是一個Web服務器，它實現了WSGI協議、uwsgi、http等協議。uWSGI，既不用wsgi協議也不用FastCGI協議，而是自創了一個uwsgi的協議，uwsgi協議是一個uWSGI服務器自有的協議，它用于定義傳輸信息的類型(type of information)，每一個uwsgi packet前4byte為傳輸信息類型描述，它與WSGI相比是兩樣東西。據說該協議大約是fcgi協議的10倍那么快。

uWSGI的主要特點如下：

● 超快的性能。

● 低內存占用(實測為apache2的mod_wsgi的一半左右)。

● 多app管理。

● 詳盡的日志功能(可以用來分析app性能和瓶頸)。

● 高度可定制(內存大小限制，服務一定次數后重啟等)。