首先聲明這篇文章 是我從 豆瓣 上面看到的。 原文地址 http://www.douban.com/note/13508388/?start=0&post=ok#last 看我之后 豁然開朗，對Web的理解有加深了一層，在此再感謝一下文章的作者。寫這篇文章 ：一 寫下 自己的理解；二 讓更多初學Python Web開發和我有相同迷惑的人能到看到這篇文章
先把原文的內容貼出來
Apache/lighttpd: 相當於一個request proxy，根據配置，把不同的請求轉發給不同的server處理，例如靜態的文件請求自己處理，這個時候它就像一個web server，對於fastcgi/python這樣的請求轉發給flup這樣的Server/Gateway進行處理
flup: 一個用python寫的web server，也就是cgi中所謂的Server/Gateway，它負責接受apache/lighttpd轉發的請求，並調用你寫的程序 (application)，並將application處理的結果返回到apache/lighttpd
fastcgi: apache/lighttpd的一個模塊，雖然flup可以作為一個獨立的web server使用，但是對於瀏覽器請求處理一般都交給 apache/lighttpd處理，然后由apache/lighttpd轉發給flup處理，這樣就需要一個東西來把apache/lighttpd跟flup聯系起來，這個東西就是fastcgi，它通過環境變量以及socket將客戶端請求的信息傳送給flup並接收flup返回的結果
web.py: 應該說有了上面的東西你就可以開始編寫你的web程序了，但是問題是你就要自己處理瀏覽器的輸入輸出，還有cookie、session、模板等各種各樣的問題了，web.py的作用就是幫你把這些工作都做好了，它就是所謂的web framework，另外一個出名的是django，不過感覺太復雜了，web.py差不多就夠用了
WSGI : 除了flup Server/Gateway外還有很多其他人的寫的Server/Gateway, 這個時候就會出問題了，如果你在flup上寫了一個程序，現在由於各種原因你要使用xdly了，這個時候你的程序也許就要做很多痛苦的修改才能使用 xdly server了，WSGI就是一個規范，他規范了flup這個服務應該怎么寫，應該使用什么方式什么參數調用你寫的程序(application)等，當然同時也規范你的程序應該怎么寫了，這樣的話，只要flup跟xdly都遵守WSGI的話，你的程序在兩個上面都可以使用了，flup就是一個WSGI server
還有一條評論也很透徹
WSGI是python的接口規范，這個規范是針對WEB服務器和python應用（框架等）的交互的。FASTCGI則是兩者底層的通信協議的規范。
學過Java的人馬上會想到 Servlet 規范。沒錯Python的 WSGI規范 就類似於 Java 中的 Servlet規范。 事實上Python的設計者們制定 WSGI規范 就是想達到 像Java中Servletd的效果。
下面就來 說說 自己對 這些 名詞 的理解
HTTP Server 就是我們通常所說的 Web Server。我們知道 互聯網的 目地就是實現文件的共享，但我們該怎么實現文件共享呢？於是就出現了各種文件共享協議 FTP，SMB，NFS等當然這些協議都屬於TCP/IP協議族，架構在TCP/IP 之上 ，屬於TCP/IP 中的 運用層。那HTTP呢？
中文名稱：超文本傳送協議
英文名稱：hypertext transport protocol;
HTTP定義：一種詳細規定了瀏覽器和萬維網服務器之間互相通信的規則，通過因特網傳送萬維網文檔的數據傳送協議。
HTTP和FTP，SMB，NFS一樣都屬於TCP/IP 協議族中的 運用層，其實我們完全可以按照理解FTP 協議一樣 理解HTTP，它們本質是一樣的，歸根到底都是 機器A對機器B的文件的訪問的之間的一種的協議。
例如 我們在某視頻網站上 點擊播放 一個視頻，當我們點擊該視頻的時候，瀏覽器向 該視頻網站的服務器上發送HTTP協議內容，該視頻網站的Web服務器解析發送過來的HTTP請求，然后將請求交給該視頻網站的Web系統來處理， Web系統 在該服務器上 指定的位置 找到 這個視頻文件，在回應給Web服務器，Web服務器在把響應的內容轉換為HTTP協議反饋給我們，我們瀏覽器在解析反饋回來的HTTP內容，播放該視頻展示給我們看。
我這個過程概括起來就是 我們的機器 對 視頻網站服務器機器上面的 一個視頻文件的訪問。他們之間通過HTTP協議來訪問。
在來總結 WSGI、flup、fastcgi、web.py之間的關系，這其實是 Web服務器 與 Web系統 之間詳細的處理過程。
Apache/Lighttpd: HTTP Server(Web服務器),如同原文所說 HTTP Server其實相當於一個 request proxy(請求代理),它們負責解析 HTTP 協議，因為你不能在自己的程序中先 解析HTTP 協議，然后在進行響應的處理。這樣的話 第一增加了程序員的工作難度(HTTP解析還真有點負責) 第二：程序會變的復雜，不易修改。所以我們就把解析HTTP協議這個工作交給一種專門的軟件來做----HTTP Server。HTTP協議的解析的工作完成了，協議被解析成各種請求，那誰來處理這些請求來？當請求是一個靜態文件(HTML文件)的時候，HTTP Server則會自己處理這些請求，此時HTTP Server 就相當於一個Web Server。但當我們請求的是一個 cgi/fastcgi/python 腳本的時候呢？很明顯HTTP Server就處理不了啦，因為這些腳本無法直接轉換為HTML文本，要依賴於某種特定的容器(環境)下才可以，對於 cgi/fastcgi/python 這樣的請求轉發給flup這樣的Server/Gateway進行處理。就比如我們在Java Web中要請求一個Servlet時,普通的HTTP Server肯定處理不了，Servelt只能運行在實現了Servelt規范的服務器上才可以。
學過Java Web的看了 原文 后 是不是覺得 Tomcate服務器相當於Python中的(HTTP Server+flup+fastcgi+WSGI)
其他的名詞 原文說的 很詳細，我就不羅嗦啦。