¿Por qué los servicios web centralizados son tan populares?

Sus otras opciones son “descentralizadas” y “federadas”. Hay problemas con ambos.


Un servicio web descentralizado es esencialmente imposible. No puede apuntar un navegador a una red punto a punto. Incluso si utilizó algo como WebRTC, hay problemas muy difíciles que deben abordarse:

  • Mantener la latencia aceptablemente baja. Las redes P2P son notoriamente lentas, y para la mayoría de los casos de uso, esto hace que la red sea inutilizable. ¿Recuerdas los días de KaZaA y LimeWire? Imagínese si usar Google llevara tanto tiempo realizar una búsqueda como lo hizo una de esas piezas de software.
  • Ser resistente a los ataques. En una red descentralizada, los pares maliciosos son un gran problema. Puede intentar detectarlos y excluirlos de la red, pero no hay forma de bloquearlos por completo (imagínese si todos los dispositivos IoT pirateados funcionaran para interrumpir una red P2P). Un nodo malicioso podría soltar mensajes, filtrar mensajes, enviar datos incorrectos, intentar causar una partición de red, o algo peor.
  • Mantener una red. Si no hay suficientes pares, la red se vuelve inestable. Las particiones de red harán que el servicio se desconecte.
  • No hay fuente de verdad. La tecnología Blockchain soluciona esto un poco, pero requiere una cantidad muy grande de nodos para funcionar de manera confiable (de lo contrario, terminará con un 51% de problemas de ataque). En una red P2P, nadie está “a cargo” y, en consecuencia, cualquier persona puede hacer esencialmente cualquier cosa que cualquier otra persona pueda hacer.
  • Es exagerado. Hay muy pocas aplicaciones que recibirían algún beneficio sustancial de ser puramente de igual a igual.
  • Señalización. Algo tiene que conectar a los compañeros entre sí. No hay forma de establecer una red P2P a través de WebRTC sin algún tipo de servicio centralizado o federado para conectar pares inicialmente.
  • Amigabilidad móvil. Mantener una conexión a una red de igual a igual requiere muchos recursos. La red está en uso casi constante, lo que puede afectar negativamente a los usuarios móviles. Los usuarios de dispositivos alimentados por batería notarán una caída sustancial en la duración de la batería.

Mirando cosas fuera del navegador, tiene DNS, que tiene una gran cantidad de problemas. Esta red se basa en la confianza y es relativamente fácil de explotar. Skype solía estar descentralizado, pero Microsoft lo retiró, citando las limitaciones de la descentralización cuando una gran cantidad de nodos son móviles o tienen conexiones de red de baja calidad.

Especialmente en la web, donde las técnicas P2P son muy limitadas, esto es casi una no opción por completo.


Un servicio web federado crea múltiples instancias de una autoridad centralizada. Un gran ejemplo de esto fue el servicio Persona (anteriormente BrowserId) de Mozilla. Tiene varias autoridades de confianza y los clientes pueden elegir una de muchas.

El mayor problema con los servicios federados es que tienden a no funcionar de manera sorprendente. Cada instancia federada (las llamaré “instancias”) debe comunicarse con otras instancias si desea compartir el estado. Imagínese si Twitter estuviera federado: para que sus amigos puedan ver su tweet, ellos tendrían que usar la misma instancia o su instancia necesitaría hablar con su instancia. En el caso de Persona, un sitio web generalmente confiaba en los servidores Persona de Mozilla. Si configuro mi propia instancia de Persona, necesitaría obtener sitios web para reconocer mi instancia e implementarla.

Otro problema es el control. Considere XMPP o Jabber. Google creó su propio cliente XMPP (Google Talk), pero finalmente quiso agregarle funciones. Ampliar XMPP es difícil y aporta poco valor a los usuarios, por lo que Google cortó lentamente los lazos con el servicio original y creó lo que ahora es Hangouts. A menos que haga que todas las instancias acuerden y se muevan al unísono, el servicio se vuelve disjunto y, en algunos casos, incompatible entre instancias.

Incluso si no hubo lucha por el control entre las instancias de un servicio federado, es casi imposible lograr que operen de forma sincronizada. Imagínese tratando de implementar una solución de seguridad en cada servidor XMPP del mundo. Considere CRIME, una vulnerabilidad que afecta a SPDY y TLS. SPDY se corrigió y finalmente se eliminó el soporte de los navegadores, y la compresión HPACK mitigó el problema en HTTP / 2. Si dicha vulnerabilidad se presentara en un servicio federado, sería excepcionalmente difícil actualizar rápidamente todas las instancias.