回答:
WSGIは、Webサーバーの開始時に、Webサーバープロセスの一部として（埋め込みモード）、または別個のプロセスとして（デーモンモード）、Pythonインタープリターを実行し、スクリプトをロードします。各リクエストにより、スクリプト内の特定の関数が呼び出され、リクエスト環境が引数として関数に渡されます。
CGIは、各要求を個別のプロセスとしてスクリプトを実行し、環境変数、stdin、およびstdoutを使用してスクリプトと「通信」します。
完全に後戻りする観点から、Blankmanは、Webサービスゲートウェイインターフェースの「紹介ページ」です。
パート1：Webサーバー
Webサーバーは応答を提供します。彼らは周りに座り、辛抱強く待っていて、突然、まったく警告なしに、突然：
Webサーバー（少なくとも、より優れたサーバー）は、この点で非常に優れています。需要に応じて処理を拡大および縮小し、非常に不安定なネットワークを介して最も不安定なクライアントと確実に会話を行うため、心配する必要はありません。彼らは奉仕し続けるだけです。
これが私のポイントです。Webサーバーはまさにそのサーバーです。彼らはコンテンツについて何も知りませんし、ユーザーについても何も知りません。実際、たくさん待って確実に返信する方法以外は何も知りません。
Webサーバーの選択は、ソフトウェアではなく、配信設定を反映する必要があります。Webサーバーは、処理や論理的なものではなく、配信を担当する必要があります。
パート2：（PYTHON）ソフトウェア
ソフトウェアは周りにありません。ソフトウェアは実行時にのみ存在します。ソフトウェアは、環境の予期しない変更（ファイルが予期した場所にない、パラメーターの名前が変更されているなど）に対応できません。最適化は設計の中心的な信条である必要がありますが（もちろん）、ソフトウェア自体は最適化しません。開発者は最適化します。ソフトウェアが実行されます。ソフトウェアは、上記の「意図的なつぶやき」セクションのすべてのことを行います。何でもかまいません。
ソフトウェアの選択または設計は、Webサーバーの選択ではなく、アプリケーション、機能の選択を反映する必要があります。
ここで、言語をWebサーバーに「コンパイル」する従来の方法が困難になります。物理サーバー環境に対処するためにアプリケーションにコードを配置するか、少なくとも、実行時に含める適切な「ラッパー」ライブラリーを選択せざるを得なくなり、Webサーバー間での統一感を与えます。
WSGIとは何ですか？
では、最後に、WSGIとは何でしょうか。WSGIは、 2つの部分に分けて記述された一連のルールです。それらは、統合を歓迎するあらゆる環境に統合できるように書かれています。
Webサーバー側向けに書かれた最初の部分は、「OK、WSGIアプリケーションを処理したい場合、ソフトウェアがロードされたときにソフトウェアがどのように考えているかを示します。アプリケーションで利用できるようにする必要があるものを次に示します。すべてのアプリケーションに期待できるインターフェース（レイアウト）です。さらに、何か問題が発生した場合のアプリの考え方と動作の予想方法を以下に示します。」
Pythonアプリケーションソフトウェア用に作成された2番目の部分は、「OK、WSGIサーバーを処理する場合、サーバーがユーザーに連絡したときにサーバーがどのように考えているかを示します。サーバーで使用できるようにする必要があるものを次に示します。ここにすべてのサーバーに期待できるインターフェース（レイアウト）があります。さらに、何か問題が発生した場合の動作とサーバーへの通知をここに示します。」
つまり、サーバーはサーバーになり、ソフトウェアはソフトウェアになり、一方が他方の仕様を考慮せずにうまく機能する方法です。これはWSGIです。
一方、mod_wsgiは、WSGI準拠のソフトウェアと通信できるようにするApacheのプラグインです。つまり、mod_wsgiは、Apacheでの上記のルールブックのパート1のルールの実装です。
CGIに関しては...他の人に聞いてください:-)
このスペースのすべての用語が不明確で、それに直面しようとすると、それは混乱を招く頭字語を含んだものです。また、CGI対FastCGI対WSGIなどについて説明している公式のpython HOWTOの形式の優れたバックグラウンドリーダーもあります。オン。最初に読んで欲しいです。