Osea, que si una pestañatiene problemas no todo el navegador se cierra….

Con la reciente salida de Internet Explorer 8 hemos asistido al nacimiento del segundo gran navegador multiproceso después de Chrome. ¿Qué significa esto? ¿Este tipo de navegadores son el futuro? ¿Qué ventajas e inconvenientes tienen respecto a los navegadores con un único proceso? Y lo más importante: ¿nos beneficia o nos perjudica a los usuarios este cambio de paradigma? Estas preguntas y algunas más las intentaré contestar en esta entrada.

¿Qué son los navegadores multiproceso?

Normalmente, cada aplicación ejecuta un único proceso, desde el cuál controlará todas las acciones que tenga que realizar. Si necesita hacer varias cosas a la vez, creará varios hilos, que no son más que subprocesos ligeros que comparten casi todos los datos o casi todas las instrucciones. De esta manera los recursos se utilizan de manera más eficiente, sobre todo la memoria, ya que al compartirla se evita tener que guardar varias veces lo mismo.

Comenzando una analogía que no sé si me va a gustar, un navegador monoproceso sería una empresa convencional, y los hilos serían sus trabajadores, que efectivamente pueden trabajar en paralelo y tienen aproximadamente la misma información, la que les provee la empresa. Este modelo es el que tradicionalmente han seguido las empresas pequeñas, y no les ha ido mal.

En contraposición, los navegadores multiproceso, como su propio nombre indica, crean varios procesos para realizar esas mismas tareas. En este caso suelen crear un proceso por cada página o pestaña que abramos (luego lo matizaré). En principio esto no tendría demasiado sentido, ya que un montón de memoria se repetirá, como por ejemplo las instrucciones que procesan el HTML o el motor de Javascript. Sin embargo, se obtienen mejores resultados al tratarse de un programa que tiene que estar preparado para ejecutarse durante horas o días seguidos.

Siguiendo y terminando con la analogía anterior, un navegador multiproceso es una gran empresa que trabaja en diferentes regiones. Aunque se dedica a hacer lo mismo en una región que en otra, una rama ciertamente no necesita saber nada sobre los clientes de otra rama. De esta manera necesitamos dirigentes o ingenieros “repetidos” para llevar cada una de las ramas, coste que nos ahorraríamos si solo tuviéramos una gran fábrica. A pesar de todo este modelo funciona bastante bien, y entre otros aspectos resalta uno interesante: si una rama tiene problemas no afecta a las demás.

¿Qué ventajas/desventajas tienen?

Lo más obvio es que se necesitan más recursos para ejecutar lo mismo que en navegadores monoproceso, ya que como he comentado antes muchos datos se guardan varias veces en memoria. Esto es algo malo de por sí, pero no creo que sea algo excesivamente notable con la cantidad de memoria que tenemos hoy en día.

De hecho, tras un tiempo usando el navegador abriendo y cerrando pestañas, el uso de memoria será incluso más eficiente que un navegador convencional. Esto es debido a que, cuando cerramos una pestaña, automáticamente se destruirá el proceso y los huecos que se liberan se administrarán desde rutinas específicas de nuestro Sistema Operativo. En un navegador monoproceso será el propio navegador el que tenga que ver qué hace con esa memoria, y no el SO. Por muy bueno que sea un navegador, el SO siempre será más eficiente, simplemente porque dispone de más herramientas. Esta es una de la razones por la que por ejemplo Firefox al cabo de un tiempo use más memoria que al principio aunque cerremos todas las pestañas, lo que lo hace bastante degradable.

Dejando de lado la eficiencia, la mayor ventaja de estos navegadores es la seguridad que ofrecen. Al aislar cada web en su propio proceso, es casi imposible que pueda afectar a las demás webs que están visualizando. En realidad incluso están aisladas respecto al navegador. Esto supone una funcionalidad interesantísima: si una de estas webs causa un fallo crítico que obliga a cerrarla, el navegador y las demás pestañas seguirán intactos. Es decir, si una web se cuelga, el navegador puede seguir adelante. Tradicionalmente, si una de las pestañas causa un fallo, todo el navegador se cierra inesperadamente.

Pero evitar que el navegador se rompa solo es un pequeño avance comparado con la seguridad que esta arquitectura puede ofrecer. Que dos webs estén completamente aisladas respecto a sí mismas y respecto al SO significa que es mucho más difícil infectarse con software malicioso. Y no solo en teoría, también se está probando en la práctica: Chrome ha sido el único navegador sobre el que no se ha encontrado ningún exploit en PWN2OWN, un concurso con expertos en seguridad celebrado esta semana. De acuerdo, IE8 ha sucumbido, pero eso es otro tema.

¿Cuántos procesos se crean?

Aunque las arquitecturas de Chrome e IE8 tienen algunas diferencias, las dos crean un proceso inicial que será el que se ocupe de la interfaz (las ventanas, las barras, etc), de todas las comunicaciones con el sistema (entrada/salida de ficheros, de internet, etc) y con el usuario (teclado, ratón, pantalla). Este es el proceso padre, y si se cierra se cerrarán todos los demás.

A partir de entonces se crean procesos adicionales por una o más webs que abramos. Cada proceso contendrá los motores de renderizado de HTML, CSS, Javascript, imágenes, etc necesarios para leer una página web. Esta es la información que se repetirá tantas veces como procesos tengamos abiertos. Estos procesos están aislados del resto del sistema, y solo se comunican con el proceso padre: si quieren acceso a disco lo tienen que hacer a través del padre, si quieren acceso a la red o a la pantalla también.

Aquí está la diferencia entre IE8 y Chrome, ya que los dos crean procesos de manera distinta. IE8 calculará cuántos procesos debe abrir dependiendo del número de sitios web que abras: si tienes cinco sitios abre 3 procesos, si tienes 15 abre 6, los que sean. Cada proceso se ocupará de varios sitios webs por defecto, y si uno de esos sitios web causa un fallo, los demás sitios que maneje ese proceso se cerrarán también. En cierto modo es como si balanceara la carga de varios sitios web entre varios procesos, tal y como se hace en un servidor web. Una manera rápida de ver los sitios que comparten un mismo proceso es ver qué pestañas comparten el mismo color (aunque si tienen distinto color también pueden compartir proceso).

Chrome sigue una arquitectura que me parece que tiene algo más sentido. En principio crea un proceso por cada sitio web que abras. Si abres otra pestaña con el mismo sitio web (por ejemplo, dos artículos de Genbeta) será lo suficientemente inteligente para reutilizar ese proceso. Este algoritmo seguirá repitiéndose hasta llegar a un tope que actualmente se acerca a los 20 procesos, a partir de este punto varias webs compartirán procesos de manera similar a IE8.

Otro punto fundamental de Chrome es que también aísla en su propio proceso a los plugins, cosa que IE8 no parece hacer. Estos componentes externos a los navegadores son probablemente la parte más inestable y la parte menos segura, así que es una buena idea aislarla también.

¿Es este el futuro?

Sí. Los navegadores tradicionales tienen sentido en la web tradicional, con sitios simples y recursos muy limitados. Hoy en día tenemos varios factores que nos llevan a preferir una arquitectura multiproceso: las aplicaciones web son tan complejas como las de escritorio (piensa en Gmail, Google Docs, etc), los navegadores se utilizan durante mucho tiempo, gracias a las pestañas cada vez abrimos más webs a la vez y la cantidad de memoria RAM es bastante grande. Y ni siquiera he hablado de los procesadores multinúcleo: un navegador multiproceso puede aprovecharlos más que los actuales multihilo, y si cada vez tenemos más núcleos habrá que explotarlos más.

Por estos motivos creo, espero y quiero que Firefox, Opera y Safari implementen esta arquitectura cuanto antes. Cualquiera que haya probado Chrome (en menor medida IE8) habrá comprobado que la experiencia de usuario es mucho mejor a lo que estamos acostumbrados, y que la estabilidad general del navegador es muy alta aunque visitemos sitios pesados. En general, todo se reduce a que los navegadores multiproceso no se degradan con la misma facilidad que los tradicionales.