Hace unos meses, la gente de archive.org llamaba a hacer una web distribuida. Los peligros de la web ‘pseudo-centralizada’ de hoy día son evidentes y lo sufrimos a diario con los errores 404. Dependemos de nodos centrales que deben ser mantenidos y cuidados, y aquellas que están en manos de particulares o pequeños grupos están condenadas a desaparecer. Por eso Neocities ha recogido el guante y se ha lanzado a hacer su Geocities del siglo XXI disponible en IPFS. [Vía: http://barrapunto.com/articles/15/09/10/1141240.shtml ]
#7 Es algo más complejo y seguro, no es tan fácil por lo poco que he leido, a ver, el concepto no está mal, pero da yuyu tener tus datos o los de un banco en un server que se hace mirror tuyo por la cara... a saber en qué manos está el servidor... entiendo que quizás se podrían hacer listas blancas de mirrors pero entonces ya no es un sistema distribuido 100%
Probablemente IPFS tenga una forma de indicar si permites que tu contenido se distribuya o no, o como dicen #3 y #8 exista la posibilidad de autorizar mirrors concretos o hacer listas blancas.
Esto rompería un poco la filosofía de IPFS, pero no impide que se implemente.
Otra pega son las estadísticas de visitas, accesos, clicks, etc. ¿Cómo se pueden contabilizar en este sistema?
Esto podría ser un problema para muchos sitios, no solo a nivel de publicidad (¿cómo mides entonces?), también para los propios administradores/desarrolladores de las webs que usan los datos de los usuarios (localización, navegador, resolución de pantalla, SO, etc.) para mejorar/optimizar las webs y los contenidos.
#10 Entonces no solo se replica el contenido, se replican los propios datos de los "nodos" hacia un punto central (o hacia todos los nodos).
Es factible, pero no lo termino de ver.
Es posible que en un tiempo evolucionemos hacia IPFS o algo similar, pero tengo que la sensación que será más bien un IPFS descafeinado, algo parecido a una evolución de los servicios distribuidos actuales mezclados con esta filosofía.
En realidad lo que hacen ahora mismo Google, Facebook, Amazon y demás es muy similar a lo que aquí se plantea, con la diferencia de que no se implementa de forma automática y de que se mantiene el estricto control al ser servidores propios en vez de nodos independientes.
1. En ese caso el volumen de tráfico resultante no sería muy alto, pero sería constante. Reduces tráfico en la descarga del contenido pero multiplicas el de replicación de "metadatos".
2. Mantener la coherencia de eso sería infernal...
Cada nodo conoce los nodos de los que cogió la información y a quienes se la ha pasado, y les manda sus estadísticas. Estos a su vez tienen que replicar esa información y también mandar sus estadísticas propias, y los siguientes nodos lo mismo, ...
La replicación a todos los nodos sería masiva, con envío masivo de datos distintos (e incoherentes entre sí) desde múltiples nodos a múltiples nodos... El equivalente a tener hubs planos en vez de switches e inundar la red de paquetes.
2- Así funcionan ahora mismo muchos sistenas ahora mismo (Soy administrador de Websphere Aplication server y si quieres mantener la persistencia de sesión tienes que activar algo parecido a otra instancia que tiene los datos de todas las demás o puedes hacerlo a nivel de BBDD), es cierto, aumentas la carga y las necesidades de hardware a costa de mantener los datos de sesión y también es cierto que NO es muy fiable, al menos en Websphere
#5 Ahí está el problema que yo le veo, a no ser que sólo almacenes parte de la información y además encriptada de tal manera que al no tener toda aunque la desencriptases no podrías hacer nada con ella.
#6 Pero para que otros puedan acceder a tu mirror y obtener la web o servicio o lo que sea, necesitan poder desencriptar eso. Y para tal hazaña, necesitan una clave de desencriptado, que estará almacenada en tu servidor (que ha clonado la información del original). Y creo que eso de ir dando por ahí las claves privadas a los servidores que "mirroreen" al tuyo no es buena política de seguridad...
El javascript también está obsoleto y mira hasta donde lo estamos sufriendo... Veo compleja la infraestructura distribuida tal y como la plantea el artículo.
#0 Es interesante pero sigo viendo problemas, al final resume en que es algo parecido entre el bitcoin y el torrent, entras en una web y si haces un bookmark te hace una copia local conviertiendote en un mirror pero ¿van a dejar los bancos que hagas un mirror local de toda su web en tu equipo? por poner un ejemplo hay muchos aplicables.
A ver está claro que en el caso de los bancos quizás optarían por tener unos cuantos mirrors autorizados pero no lo tengo claro, hay veces, al menos en la actualidad, que tienes que acceder a las máquinas físicamente para determinadas operaciones y eso sólo se consigue teniendo acceso físico al CPD, yo mismo en persona tuve que instalar con un USB un CA de un ministerio y eso sólo era posible haciéndolo físicamente tal y como se gestionó, aunque reconozco que podría haberse hecho de otra manera.
Después está lo que dice #1 que aplica también al HTTP, será una mierda ahora mismo pero nos lo comeremos años
#2 accediendo desde otro equipo en el exteriror y marcandolo como bookmark se replicaría en el nuevo
#3 Sisi, pero yo no quiero que otra persona tenga mis datos. Si yo accedo desde el ordenador de un amigo, no quiero que su máquina haga de "mirror", quiero que mis datos sigan en mi servidor y sólo sean accesibles por mi. Que si, que los navegadores cachean, pero no es exactamente lo mismo una replicación completa que un "mantener la información descargada que no cambie para acelerar la próxima petición al mismo sitio"...
Yo sólo le veo una pega: Si quiero un servidor personal, con mi propio ordenador, mis propios datos y mi propio acceso desde internet. ¿Cómo preservar eso en un sistema distribuído?
Me estoy leyendo y le veo varias pegas, y que algunos de los problemas de http que cuenta ya no lo son.
Pegas a IPFS:
- IPFS se basa en copiar/distribuir los contenidos en muchas ubicaciones: esto solo es válido para contenido estático, pero ahora mismo la mayoría de las webs son de contenido dinámico.
- IPFS se basa en hashes: esto garantiza que si el contenido se ha cambiado, ya no coincide con el hash y por lo tanto es una forma de validar el contenido. El problema de los hashes está en las colisiones, un único hash puede representar distintos contenidos, al ser el conjunto de hashes (finito) menor que el de contenidos posibles (prácticamente infinito).
Esto hace que te pueda mandar parte de contenido perteneciente a otro "documento", y por lo tanto terminas con un "documento" corrupto (ya sé que las colisiones en hashes son muuuuuuuuuuuuuuy poco probables, pero son posibles, y con el crecimiento exponencial de los contenidos se van a dar sí o sí).
- Webs de aplicaciones comerciales/empresariales: no veo IPFS para algo así, donde el control del contenido es primordial. De todas formas estas aplicaciones suelen de contenido dinámico, por lo que engancha con la primera pega.
No pretendo decir que he entendido a fondo IPFS, por lo que es posible que existan soluciones a estas pegas.
Tampoco sé si hay más pegas, pero supongo que probablemente sí.
Supuestos problemas de http que ya no lo son:
- Las caídas o apagados de los servidores web. Esto ya no es un problema, se pueden hacer ahora mismo webs distribuidas, que te sirven el contenido de distintas ubicaciones, en función de tu localización y de la disponibilidad de los servidores.
También se puede solucionar de una forma más tradicional con clusters y balanceadores, sistemas de ficheros distribuidos (gfs/gpfs/dfs ...), etc.
- La centralización, en realidad no es un problema de http, el problema es que nos hemos hecho dependientes de servicios concretos (google/gmail, Facebook, etc), pero eso no es por culpa de http.
- El ejemplo del consumo de ancho de banda (ejemplo de Gangnam Style) se soluciona con servicios de proxy-cache, que además también solucionan (en parte) los problemas de caídas.
Con todo esto, es cierto que http tiene fallos (de ineficiencia, seguridad, etc.), pero se pueden solventar.
Comentarios
#7 Es algo más complejo y seguro, no es tan fácil por lo poco que he leido, a ver, el concepto no está mal, pero da yuyu tener tus datos o los de un banco en un server que se hace mirror tuyo por la cara... a saber en qué manos está el servidor... entiendo que quizás se podrían hacer listas blancas de mirrors pero entonces ya no es un sistema distribuido 100%
Probablemente IPFS tenga una forma de indicar si permites que tu contenido se distribuya o no, o como dicen #3 y #8 exista la posibilidad de autorizar mirrors concretos o hacer listas blancas.
Esto rompería un poco la filosofía de IPFS, pero no impide que se implemente.
Otra pega son las estadísticas de visitas, accesos, clicks, etc. ¿Cómo se pueden contabilizar en este sistema?
Esto podría ser un problema para muchos sitios, no solo a nivel de publicidad (¿cómo mides entonces?), también para los propios administradores/desarrolladores de las webs que usan los datos de los usuarios (localización, navegador, resolución de pantalla, SO, etc.) para mejorar/optimizar las webs y los contenidos.
#9 Las estadísticas y visitas se replicarían de un entorno a otro, sumandose todas al final seguramente, no lo veo difícil de implementar
#10 Entonces no solo se replica el contenido, se replican los propios datos de los "nodos" hacia un punto central (o hacia todos los nodos).
Es factible, pero no lo termino de ver.
Es posible que en un tiempo evolucionemos hacia IPFS o algo similar, pero tengo que la sensación que será más bien un IPFS descafeinado, algo parecido a una evolución de los servicios distribuidos actuales mezclados con esta filosofía.
En realidad lo que hacen ahora mismo Google, Facebook, Amazon y demás es muy similar a lo que aquí se plantea, con la diferencia de que no se implementa de forma automática y de que se mantiene el estricto control al ser servidores propios en vez de nodos independientes.
#11 Se replicaría todo, contenido y datos dinámicos como estadísticas, a todos los nodos
#12 A todos los nodos le veo 2 grandes problemas.
1. En ese caso el volumen de tráfico resultante no sería muy alto, pero sería constante. Reduces tráfico en la descarga del contenido pero multiplicas el de replicación de "metadatos".
2. Mantener la coherencia de eso sería infernal...
Cada nodo conoce los nodos de los que cogió la información y a quienes se la ha pasado, y les manda sus estadísticas. Estos a su vez tienen que replicar esa información y también mandar sus estadísticas propias, y los siguientes nodos lo mismo, ...
La replicación a todos los nodos sería masiva, con envío masivo de datos distintos (e incoherentes entre sí) desde múltiples nodos a múltiples nodos... El equivalente a tener hubs planos en vez de switches e inundar la red de paquetes.
#13 1- las estadísticas no es que ocupen mucho
2- Así funcionan ahora mismo muchos sistenas ahora mismo (Soy administrador de Websphere Aplication server y si quieres mantener la persistencia de sesión tienes que activar algo parecido a otra instancia que tiene los datos de todas las demás o puedes hacerlo a nivel de BBDD), es cierto, aumentas la carga y las necesidades de hardware a costa de mantener los datos de sesión y también es cierto que NO es muy fiable, al menos en Websphere
#14 Sí, conozco WAS pero en esos casos estamos hablando de entornos limitados y controlados, no de "Internet".
#5 Ahí está el problema que yo le veo, a no ser que sólo almacenes parte de la información y además encriptada de tal manera que al no tener toda aunque la desencriptases no podrías hacer nada con ella.
#6 Pero para que otros puedan acceder a tu mirror y obtener la web o servicio o lo que sea, necesitan poder desencriptar eso. Y para tal hazaña, necesitan una clave de desencriptado, que estará almacenada en tu servidor (que ha clonado la información del original). Y creo que eso de ir dando por ahí las claves privadas a los servidores que "mirroreen" al tuyo no es buena política de seguridad...
El javascript también está obsoleto y mira hasta donde lo estamos sufriendo... Veo compleja la infraestructura distribuida tal y como la plantea el artículo.
Me parece muy interesante el IPSF https://ipfs.io.
#0 Es interesante pero sigo viendo problemas, al final resume en que es algo parecido entre el bitcoin y el torrent, entras en una web y si haces un bookmark te hace una copia local conviertiendote en un mirror pero ¿van a dejar los bancos que hagas un mirror local de toda su web en tu equipo? por poner un ejemplo hay muchos aplicables.
A ver está claro que en el caso de los bancos quizás optarían por tener unos cuantos mirrors autorizados pero no lo tengo claro, hay veces, al menos en la actualidad, que tienes que acceder a las máquinas físicamente para determinadas operaciones y eso sólo se consigue teniendo acceso físico al CPD, yo mismo en persona tuve que instalar con un USB un CA de un ministerio y eso sólo era posible haciéndolo físicamente tal y como se gestionó, aunque reconozco que podría haberse hecho de otra manera.
Después está lo que dice #1 que aplica también al HTTP, será una mierda ahora mismo pero nos lo comeremos años
#2 accediendo desde otro equipo en el exteriror y marcandolo como bookmark se replicaría en el nuevo
#3 Sisi, pero yo no quiero que otra persona tenga mis datos. Si yo accedo desde el ordenador de un amigo, no quiero que su máquina haga de "mirror", quiero que mis datos sigan en mi servidor y sólo sean accesibles por mi. Que si, que los navegadores cachean, pero no es exactamente lo mismo una replicación completa que un "mantener la información descargada que no cambie para acelerar la próxima petición al mismo sitio"...
Yo sólo le veo una pega: Si quiero un servidor personal, con mi propio ordenador, mis propios datos y mi propio acceso desde internet. ¿Cómo preservar eso en un sistema distribuído?
Me estoy leyendo y le veo varias pegas, y que algunos de los problemas de http que cuenta ya no lo son.
Pegas a IPFS:
- IPFS se basa en copiar/distribuir los contenidos en muchas ubicaciones: esto solo es válido para contenido estático, pero ahora mismo la mayoría de las webs son de contenido dinámico.
- IPFS se basa en hashes: esto garantiza que si el contenido se ha cambiado, ya no coincide con el hash y por lo tanto es una forma de validar el contenido. El problema de los hashes está en las colisiones, un único hash puede representar distintos contenidos, al ser el conjunto de hashes (finito) menor que el de contenidos posibles (prácticamente infinito).
Esto hace que te pueda mandar parte de contenido perteneciente a otro "documento", y por lo tanto terminas con un "documento" corrupto (ya sé que las colisiones en hashes son muuuuuuuuuuuuuuy poco probables, pero son posibles, y con el crecimiento exponencial de los contenidos se van a dar sí o sí).
- Webs de aplicaciones comerciales/empresariales: no veo IPFS para algo así, donde el control del contenido es primordial. De todas formas estas aplicaciones suelen de contenido dinámico, por lo que engancha con la primera pega.
No pretendo decir que he entendido a fondo IPFS, por lo que es posible que existan soluciones a estas pegas.
Tampoco sé si hay más pegas, pero supongo que probablemente sí.
Supuestos problemas de http que ya no lo son:
- Las caídas o apagados de los servidores web. Esto ya no es un problema, se pueden hacer ahora mismo webs distribuidas, que te sirven el contenido de distintas ubicaciones, en función de tu localización y de la disponibilidad de los servidores.
También se puede solucionar de una forma más tradicional con clusters y balanceadores, sistemas de ficheros distribuidos (gfs/gpfs/dfs ...), etc.
- La centralización, en realidad no es un problema de http, el problema es que nos hemos hecho dependientes de servicios concretos (google/gmail, Facebook, etc), pero eso no es por culpa de http.
- El ejemplo del consumo de ancho de banda (ejemplo de Gangnam Style) se soluciona con servicios de proxy-cache, que además también solucionan (en parte) los problemas de caídas.
Con todo esto, es cierto que http tiene fallos (de ineficiencia, seguridad, etc.), pero se pueden solventar.
#4
Exacto.
Veo mas factible montar la nueva red distribuida usando proyectos como Ethereum (que esta en pañales): http://manzanamecanica.org/2015/03/ethereum_agentes_autonomos_distribuidos_que_viven_de_criptomonedas.html