Server web in modalità kernel: un'ottimizzazione intelligente o un incubo per la sicurezza?

Http.sys non è tanto un server web come un proxy-forwarder. È progettato per consentire a molti server Web di coesistere su una casella di Windows, quindi è possibile avere IIS in esecuzione un sito Web, ma anche diversi servizi WCF in esecuzione con interfacce http / REST o SOAP, tutti su porta standard 80. (questo è il motivo per cui non è possibile eseguire Apache su Windows senza un po 'di jiggling, Apache non è stato modificato per funzionare con questo sistema di registrazione, peccato che non fosse reso più trasparente per le applicazioni e richiedesse alcune modifiche abbastanza complesse da agganciare ad esso).

Il modo in cui funziona è che si registra un URL con esso e l'applicazione corrispondente, quando una richiesta http viene effettuata sulla porta 80, http.sys lo accetta ma poi passa la richiesta a qualsiasi applicazione registrata per gestirlo URL target.

Dubito che un webserver in modalità kernel abbia senso - anche se le prestazioni del socket possono essere migliorate in questo modo, per eseguire qualsiasi lavoro utile, la logica dell'applicazione verrà comunque eseguita nello spazio utente, quindi c'è sempre una transizione - l'hai appena spostato un po 'lungo il callstack.

Http.sys non è l'unico server web in modalità kernel disponibile: sotto Linux c'è anche tux . Come hai correttamente identificato, la sicurezza è un problema con questi tipi di server, il che ha portato a non includere il tux nel kernel linux principale (e credo non aggiornato per versioni del kernel più recenti).

Una soluzione migliore sarebbe l'uso di un sistema operativo che non si basa sulla protezione hardware per rafforzare la sicurezza del processo, ad es. Singolarità di Microsoft: un tale sistema consentirebbe l'aumento dell'efficienza di un server in modalità kernel senza i rischi per la sicurezza. Sfortunatamente, nessun sistema operativo pronto per la produzione basato su questo principio è disponibile dal 2015, e nessuno AFAIK sta lavorando seriamente su uno di essi (il progetto Singularity è stato cancellato).

Http.sys è a basso rischio, in quanto non può eseguire alcuna operazione fornita da una terza parte.

Http.sys svolge alcune attività.

• Funziona come un server di inoltro proxy, consentendo così a più processi di rispondere alla richiesta a parti diverse dello spazio dei nomi HTTP. risposta gbjbaanb copre bene.

• Serve file statici, direttamente dalla cache dei file di Windows. Ciò fornisce una grande accelerazione per i file statici di file di piccole dimensioni, in quanto non ci sono opzioni di contesto.

• Memorizzerà in cache l'output da qualsiasi applicazione inoltrata a una richiesta HTTP e restituirà il risultato incassato. L'applicazione ha il controllo completo su quanto dura (se esiste) la memorizzazione nella cache.

Http.sys è progettato per eseguire le semplici attività MOLTO velocemente, passando tutto il resto a un processo nello spazio utente.

In risposta al commento

"low risk, as it can’t run any code provided by a 3rd party" - That's what they always say, and it's almost never true.

Il problema è che devi fidarti di Microsoft per scrivere codice complesso del kernel per fare questa domanda, altrimenti decidi di non usare affatto windows per il web hosting . Http.sys aggiunge molto poco al rischio di bug del kernel, dato quanto è complesso il kernel.

Se qualcosa di simile a Http.sys riduce il rischio, poiché esiste una separazione così netta sotto il servizio web di basso livello e il codice dell'applicazione.

In una configurazione ben progettata, la macchina (o il server virtuale) che esegue il server Web ha un accesso molto limitato al resto della rete, poiché si tratta di un obiettivo ad alto rischio. Rende molto poco diverso se il kernel o un server Web in modalità utente viene violato, poiché il server non dovrebbe avere più "diritti" sulla rete, quindi il processo in modalità utente del server Web deve fare il suo lavoro.