16 meneos
140 clics
HTTP está obsoleto. Es el momento de hacer una web distribuida y permanente [ENG]
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: barrapunto.com/articles/15/09/10/1141240.shtml ]
|
comentarios cerrados
Me parece muy interesante el IPSF ipfs.io.
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.
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.
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.
Veo mas factible montar la nueva red distribuida usando proyectos como Ethereum (que esta en pañales): manzanamecanica.org/2015/03/ethereum_agentes_autonomos_distribuidos_qu