Php : Modulo o CGI?

L'interprete Php, se installato sotto Apache, può girare grosso modo in due modalità: come modulo del webserver o come CGI.
Se non siete a conoscenza della configurazione del vostro servizio di hosting, potete scoprire subito se Php gira come Cgi o modulo semplicemente caricando un file .php con la solita istruzione:

<?php phpinfo();?>

Lanciando questo file sul webserver, potete vedere tutte le variabili di configurazione di php e scoprire alla voce "SERVER API" se si tratta di un Cgi o di un Apache Handler. Ecco le differenze tra le due modalità.

Quando Php viene installato come modulo di Apache, diventa parte del webserver condividendone quindi la memoria, i processi e le problematiche, prima tra tutti la sicurezza. In teoria un errore php può bloccare l'intero webserver in esecuzione, immaginate poi se questo è responsabile di più siti ospitati su un unico hosting -evidentemente di fascia economica. L'utente sotto il quale gira il processo è quindi quello di Apache ("apache", "httpd",  "nobody"  o  "www-data" che sia) e questo può generare conflitti quando ad esempio installiamo qualcosa attraverso il software, come un'estensione di Joomla, e poi cerchiamo di sovrascrivere il file via Ftp.
A favore di questa soluzione, chiamata anche Dynamic Shared Object, va detto che è la più facile da configurare anche perché è quella installata di default con Apache.

La versione CGI è divenuta via via più utilizzata, grazie anche al superamento della prima versione dei CGI, sostituiti oggi da protocolli più efficienti come FastCgi sfociato poi nel progetto fcgiD.
Quando Php è installato come CGI, ogni chiamata genera un nuovo processo ma questo rappresenta solo in parte un problema. Infatti i nuovi protocolli come FastCgi costituiscono una sorta di layer intermedio con il quale un processo rimane sempre in esecuzione per gestire le chiamate con il webserver, ottimizzando le prestazioni.  A fronte di ciò, i vantaggi sono innegabili:

• essendo una versione separata dal webserver, è possibile aggiungere moduli non previsti in maniera nativa in fase di prima installazione;
• se il provider lo consente,  è possibile addirittura usare una propria versione del file php.cgi -opportunamente compilato- e sopratutto gestire il tutto mediante semplici direttive htaccess; volendo è possibile cambiare anche la versione di php;
• l'utente che esegue il processo è lo stesso di Php e non più quello di Apache, con quello che ne consegue in termini di sicurezza: Php diventa l'unico responsabile autorizzato alla gestione dei propri files, compresi quelli di configurazione con le varie password di database...
• i moderni protocolli Cgi consentono di gestire le chiamate attraverso socket, quindi in teoria potremmo disporre i processi su un secondo webserver diverso da quello su cui gira Apache, con ovvi vantaggi in termini di prestazioni
• l'interprete viene chiamato solo quando serve; in un sito basato su molti parti statiche (come quello che state leggendo) non ha senso portare in memoria l'interprete php anche quando c'è da gestire una chiamata ad un file html o css

A partire dalla versione 5.3 di Php è possibile usare, al posto di fcgiD, PHP-FPM che è molto più di uno strato intermedio tra Apache e Php. Oltre al fatto di gestire altri server come Nginx, dispone di funzionalità avanzate come la memoria cache, la possibilità di riavviare la macchina in situazioni di emergenza e di attribuire permessi diversi agli utenti, funzione essenziale in termini di sicurezza.