27 de marzo de 2009



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.

LCIE en IE8

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.

Chrome se ha rompido

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.

IE8 se ha rompido

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.

Se ha rompido un plugin

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?

. 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.

Via | Genbeta

Enlace | Arquitectura de Chrome
Enlace | Chrome en Pwn2Own
Enlace | LCIE en IE8
Enlace | Arquitectura de IE8
Enlace | Procesos en IE8 y Chrome

Deja tu Comentario.


Quieres leer más post como éste???...suscribete aquí!!!

3 comentarios:

Energy dijo...

engo entendido que Firefox 4 también será multiproceso. Lo cierto es que yo también estoy de acuerdo en que este tipo de navegadores serán el futuro, a pesar del mayor consumo de recursos que pueda suponer.

Con FF3 muy pocas veces fallan las páginas hasta el punto de que tengas que cerrar el navegador, pero recuerdo que con FF2 esto era algo relativamente frecuente. Lo peor es que al intentar abrir de nuevo el navegador, cargaba de nuevo las mismas pestañas y evidentemente volvía a petar, creándose así un bucle del que era difícil salir.

Unknown dijo...

Supongo que en Mozilla y Opera estarán pensando a ver cómo lo hacen, porque las mejoras son muy interesantes... Apple con Safari supongo que también, porque ya tienen el camino prácticamente hecho al estar basado en el mismo motor de Chrome.

Por cierto, también espero que alguien cambie su motor por Webkit, realmente es increíble la velocidad y eficiencia que han conseguido con ese motor, por no hablar de los estándares. Si al menos IE utilizara Webkit los desarrolladores web podríamos respirar tranquilos de una vez por todas :)

silver dijo...

Es una muy buena explicación y comparación.

Y me quedo con esto: "Si al menos IE utilizara Webkit los desarrolladores web podríamos respirar tranquilos de una vez por todas :)"