Respostas:
O WSGI executa o interpretador Python no início do servidor da web, como parte do processo do servidor da web (modo incorporado) ou como um processo separado (modo daemon) e carrega o script nele. Cada solicitação resulta em uma função específica no script sendo chamada, com o ambiente de solicitação passado como argumentos para a função.
O CGI executa o script como um processo separado de cada solicitação e usa variáveis de ambiente, stdin e stdout para "se comunicar" com ele.
De um ponto de vista totalmente recuado, Blankman, aqui está minha "Página de Introdução" para a Interface de Gateway de Serviços da Web:
PARTE UM: SERVIDORES DA WEB
Servidores da Web fornecem respostas. Eles ficam sentados, esperando pacientemente, e então sem nenhum aviso, de repente:
Servidores Web (pelo menos, os melhores) são MUITO bons nisso. Eles aumentam e diminuem o processamento, dependendo da demanda, mantêm conversas confiáveis com os clientes mais desprezíveis em redes realmente cruas e nunca precisamos nos preocupar com isso. Eles continuam servindo.
Este é o meu ponto: servidores web são exatamente isso: servidores. Eles não sabem nada sobre conteúdo, nada sobre usuários, nada além de como esperar muito e responder de forma confiável.
Sua escolha de servidor da web deve refletir sua preferência de entrega, não seu software. Seu servidor da web deve ser responsável por servir, não processar ou coisas lógicas.
PARTE DOIS: SOFTWARE (PYTHON)
O software não fica parado. O software existe apenas no momento da execução. O software não é muito flexível quando se trata de mudanças inesperadas em seu ambiente (os arquivos não estão onde esperam, os parâmetros são renomeados etc.). Embora a otimização deva ser um princípio central do seu design (é claro), o próprio software não otimiza. Os desenvolvedores otimizam. O software é executado. O software faz todas as coisas na seção 'murmúrio deliberado' acima. Poderia ser qualquer coisa.
Sua escolha ou design de software deve refletir seu aplicativo, sua opção de funcionalidade e não sua escolha de servidor da web.
É aqui que o método tradicional de "compilar" linguagens para servidores da Web se torna doloroso. Você acaba inserindo código no aplicativo para lidar com o ambiente físico do servidor ou, pelo menos, sendo forçado a escolher uma biblioteca 'wrapper' apropriada para incluir no tempo de execução, para dar a ilusão de uniformidade nos servidores da web.
O QUE É WSGI?
Então, finalmente, o que é WSGI? WSGI é um conjunto de regras , escritas em duas metades. Eles são escritos de forma que possam ser integrados a qualquer ambiente que acolha bem a integração.
A primeira parte, escrita para o servidor da Web, diz "OK, se você deseja lidar com um aplicativo WSGI, veja como o software estará pensando quando carregar. Aqui estão as coisas que você deve disponibilizar para o aplicativo e aqui é a interface (layout) que você pode esperar que todo aplicativo tenha. Além disso, se algo der errado, veja como o aplicativo estará pensando e como você pode esperar que ele se comporte. "
A segunda parte, escrita para o software aplicativo Python, diz "OK, se você deseja lidar com um servidor WSGI, veja como o servidor estará pensando quando entrar em contato com você. Aqui estão as coisas que você deve disponibilizar para o servidor e aqui está a interface (layout) que você pode esperar que todo servidor tenha. Além disso, se algo der errado, veja como você deve se comportar e o que você deve informar ao servidor ".
Então, aí está - os servidores serão servidores e o software será software, e aqui está uma maneira de eles se darem bem sem que um tenha que fazer concessões quanto às especificidades do outro. Este é o WSGI.
O mod_wsgi, por outro lado, é um plug-in para o Apache que permite conversar com software compatível com WSGI; em outras palavras, o mod_wsgi é uma implementação - no Apache - das regras da parte um do livro de regras acima.
Quanto ao CGI .... pergunte a outra pessoa :-)
Se você não está claro sobre todos os termos deste espaço, e vamos ser sinceros, é um arquivo confuso, carregado de acrônimos, também há um bom leitor de plano de fundo na forma de um HOWTO oficial em python, que discute CGI vs. FastCGI vs. WSGI e assim por diante. em. Eu gostaria de ler primeiro.
Tanto o CGI quanto o WSGI definem interfaces padrão que os programas podem usar para manipular solicitações da web. A interface CGI está em um nível inferior ao WSGI e envolve o servidor configurando variáveis de ambiente que contêm os dados da solicitação HTTP, com o programa retornando algo formatado praticamente como uma resposta simples do servidor HTTP.
O WSGI, por outro lado, é uma interface específica de Python, de nível um pouco mais alto, que permite aos programadores escrever aplicativos independentes do servidor e que podem ser agrupados em outros aplicativos WSGI (middleware).