Portada
mis comunidades
otras secciones
#3:
Viaja por el aire, porque internet no tiene cables... http://youtu.be/wCa1jfo93jQ
#9:
En realidad, y visto lo visto, por donde al final SIEMPRE acaba pasando es por aquí:
#1:
Por dónde no sé, pero sé que lo hace a través de megas y megas pesadísimos.
http://www.muycomputer.com/2012/05/11/anton-reixa-la-banda-ancha-solo-sirve-para-descargar-megas-pesados
http://www.muycomputer.com/2012/05/11/anton-reixa-la-banda-ancha-solo-sirve-para-descargar-megas-pesados
Comentarios
Pasa toda por aquí:
#2 o aquí:
#3 http://24.media.tumblr.com/a57a397ea38a02ce14396961a881de97/tumblr_mkdp717ggz1rfeu45o1_400.gif
#2
#4
Viaja por el aire, porque internet no tiene cables...
En realidad, y visto lo visto, por donde al final SIEMPRE acaba pasando es por aquí:
La de cable que hemos colocado, impresionante. ¿Y todavía queda cobre en el globo terráqueo?
#9 Si fueran tan listos habrían hecho un aparcamiento subterráneo
#20 Antes eran los rumanos los más entendidos, aunque últimamente les estamos igualando.
#20 Cobre... en fin lo de la fibra y eso creo que es mejor.
#25 Pequeño detalle que he pasado por alto
Por dónde no sé, pero sé que lo hace a través de megas y megas pesadísimos.
http://www.muycomputer.com/2012/05/11/anton-reixa-la-banda-ancha-solo-sirve-para-descargar-megas-pesados
Joder, la NSA tiene que saber mas de mi que yo mismo...
#8 #11 La mitad de las que he probado van a dar a la NSA (O_O)
Por el Pentágono.
#5 de hecho, la página en cuestión te informa de los posibles servicios de inteligencia que puedan estar accediendo a tus comunicaciones.
Por ejemplo, Si visualizas la ruta desde Francia hasta Dropbox, te dice: "Probably accessed by these security services: DGSE (FR) - NSA (US)".
Habéis descubierto America (nunca mejor dicho) http://es.wikipedia.org/wiki/Traceroute
#13 Eso, y también el agua tibia. Y hay infinidad de utilidades mas visuales que el traceroute (tracert en máquina Microsoft)
https://www.google.es/search?safe=off&q=visual%20trace%20route&hl=es-ES&qsubts=1376937061337
#13 pero el traceroute no tiene el conveniente aviso: "Probably accessed by these security services ..." que encuentro muy apropiado
#13 Y en realidad, viendo el código fuente de la página, lo que se muestra es información estática...
Más información e infografia en http://apps.opendatacity.de/prism/en
¿No os parece curioso que uno de los que menos "vigilancia" tenga es YouPorn?
#30 ¿Después de semejante verborrea conspirativa? Va a ser que no. Si no sabe, que pregunte (o se informe). Pero no se puede ir por la vida pensando que un * es una conspiración gubernamental, lo siento.
¿En serio esto ha llegado a portada?
Vamos a ver, empresas grandes como Google tienen registradas sus IPs en sus sedes por simple comodidad, que una base de datos de IPs te diga que una en concreto está en Mountain View no implica que el datacenter donde vayas a parar esté allí, de hecho por costes y rendimiento a las empresas les interesa que vayas al datacenter que tienes más cercano.
Que alguien se crea que todas las peticiones a Google o Youtube se sirvan desde un único datacenter en Mountain View y encima publique un artículo en Internet si que es digno de estudio.
#24 ¿En serio tu comentario pretende enseñar algo a alguien?
La idea del trazado de rutas no consiste en saber dónde termina el paquete, sino por dónde pasa. Conociendo los nodos intermedios se tiene todo el camino hasta la IP de destino. Y conociendo el camino, tu comentario se va por el váter.
De hecho es más divertido que eso, porque esta rebatiendo algo que nadie ha dicho salvo tú.
Es más, de tu comentario de deduce que TODOS los datos DINÁMICOS de Google, Youtube, etc. están replicados por todo el mundo, algo más que discutible. De hecho prácticamente te puedo asegurar que los datos dinámicos que permiten trazar usuarios según sus peticiones, accesos a servicios, ubicación, hábitos, etc. sí van todos a servidores centralizados.
#32 Un trace te da las IPs, no te dice donde están localizadas esas IPs, para eso vas a un servicio de geolocalización de IPs que no es más que una base de datos de donde están registradas esas IPs, esto en la gran mayoría de los casos coincide con una IP de un ISP asociada a un determinado lugar pero no es así en las grandes corporaciones de Internet porque registran las IPs en sus sedes, que lógicamente no es donde están todos los data centers. Por eso aunque tengas los saltos para poner el puntito en el mapa necesitas el servicio de geolocalización y si el punto final está "mal" pues lo vas a pintar ahí, si te fijas en los de Google son todos dentro del mismo país hasta que salta a una IP de Google que es cuando va a Mountain View porque como he dicho es donde las tienen registradas.
Y sobre tus deducciones dedícate a otra cosa, yo no he dicho que todos los datos estén replicados en todos los data centers, he dicho que las peticiones que haces van al datacenter más cercano, que luego este tenga que pedirlo a otro data center o no ya dependerá de los datos que tenga. Lo que seguro que no están es centralizados en un solo sitio porque sería una tontería enorme.
Así si alguien sube un vídeo en EEUU seguramente se replique en los servidores locales y se comunique a los otros data centers un cambio en los índices de búsqueda, si luego yo lo pido desde España el datacenter europeo que me haya tocado verá que no lo tiene y se lo pedirá a uno de EEUU y lo guardará en su caché para que el siguiente que lo pida en Europa lo encuentre más rápidamente, y a partir de un número de peticiones seguramente lo marcará como muy visitado y lo persistirá también en los data centers europeos. Algo así como los DNS, si yo le pido a mi DNS una dirección y no la tiene irá a buscarla a otro DNS de jerarquía superior hasta que la encuentre en algún sitio o falle la búsqueda, una vez que la haya encontrado se la guarda localmente para futuras consultas, no vuelve a pedirla cada vez, lo que no implica que tenga una copia local de todos los dominios del mundo.
Evidentemente esto es un ejemplo muy simplificado y seguramente sea muchísimo más complejo, Google tiene montada su propia red "interna" entre data centers, sus propias bases de datos y su propio mecanismo de sincronización mundial, por ejemplo el año pasado hizo público como lo hacía, aunque ahora seguramente tenga ya algo más avanzado, cuando lo publican es porque ya tienen algo mejor: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf
#33 Pero hombre, no me seas simple. Te pueden falsear una o dos ubicaciones, incluso las de origen y destino si quieres, pero no te pueden falsear TODOS y cada uno de los nodos intermedios, que en el 99,99% de las ocasiones ni siquiera corresponden a nombres reconocibles y por tanto ninguna compañía se molesta en falsear su ubicación por motivos de márketing.
Por eso, obteniendo el camino, puedes perfectamente rastrear la ubicación. De hecho sólo los programas de juguete para los cuales la ubicación no es un dato crítico pueden basarla en buscar un rango de IP en una base de datos como tú dices. Cualquier programa con cara y ojos se basa en el trazado de nodos hasta las proximidades del punto destino. Incluso los sistemas de ubicación no-GPS de los móviles funcionan así.
No te hagas tantas pajillas y haz la simple prueba, hombre, que estás hablando por hablar. Haz un simple "traceroute" y ubica todos los nodos resultantes con cualquier base de datos de IP, verás que el camino te determina perfectamente el origen y el destino, y que en caso de haber alguna ubicación falseada queda descaradamente descartada como "outlier".
"he dicho que las peticiones que haces van al datacenter más cercano, que luego este tenga que pedirlo a otro data center o no ya dependerá de los datos que tenga"
Obviamente, la no disponibilidad hace que el camino sea más largo, bien sea por intranet o mucho más usualmente por extranet (porque montar una red interna a nivel internacional no es algo tan trivial como tú pareces suponer, es virtualmente imposible si no posees cableado propio, y la mayoría de compañías no tienen). Y aunque tú le restes importancia al hecho, eso contraviene tu tesis principal de que las peticiones sólo llegan hasta nodos próximos. Las peticiones siempre siguen saltando hasta que encuentran un servidor concreto que las puede servir directamente.
Es más, te equivocas rotundamente al afirmar que un datacenter intermedio "pide" la información a otro datacenter para luego servírsela al cliente. Eso es ineficiente de cojones. Lo que hace el datacenter intermedio si no puede servir directamente la petición es pasar la petición del cliente (usualmente enriqueciéndola con metadatos) a otro datacenter para que éste la sirva directamente al cliente, de nuevo alargando el camino con ello y aproximándolo más a nodos centrales. Cualquier otra cosa es menos eficiente y más costosa para la compañía.
De todos modos ése no es el tema.
No me hacía falta la lección sobre replicación de metadatos al estilo DNS, gracias. Tú sólo hablas de datos estáticos, que se puede replicar periódicamente, y crees que eso es todo. Pero justamente gracias a compañías como Google, Internet hace años que ya no funciona únicamente así. Si tú vas a Youtube y cuelgas un vídeo desde España, éste puede abrirse AL INSTANTE en Japón y obviamente aún no se ha replicado en ninguna parte ni siquiera en forma de metadatos. Insisto, se puede acceder AL INSTANTE, y no "luego" como tú convenientemente estipulas para que dé tiempo de replicar sus metadatos. Si lo accedes desde Japón nada más colgarlo en España, la petición de búsqueda va a ir de Japón a bases de datos centrales en todos los continentes (actualizadas al colgar el vídeo) para averiguar temporalmente dónde demonios está el vídeo solicitado, y finalmente a España para acceder al vídeo en sí. Te puede parecer exagerado, pero no hay otra manera de hacer que los datos dinámicos sean accesibles al instante.
Aplica lo mismo al correo, a los sistemas de almacenamiento remotos, y en general a cualquier servicio dinámico accesible vía Internet. La latencia de replicación no es una opción aceptable en la mayoría de servicios utilizados hoy en día.
Por poner otro ejemplo dinámico menos evidente, si tu móvil informa a Apple de que tu ubicación actual está en Madagascar (por ejemplo), esta información tiene que centralizarse lo antes posible para ser procesada en el siguiente lote de análisis, y por ello los nodos intermedios (los de Apple también) irán pasando el paquete hasta llegar lo más cerca posible de un sistema de nodos centrales que se dedican a analizar dichos datos. Puedes comprobarlo trivialmente viendo que en cosa de minutos el asistente de Apple instalado en tu móvil te proporciona datos "online" de Madagascar y no de tu ubicación habitual. Los metadatos de ubicación que maneja el servicio no vienen directamente del cliente, sino de servidores que centralizan dichos metadatos.
Y aprovechando el mismo ejemplo, incluso si te ubican por antenas de telefonía, esos datos de tu ubicación pasan por servidores centrales de la compañía telefónica de turno.
#33 Pero hombre, no me seas simple. Te pueden falsear una o dos ubicaciones, incluso las de origen y destino si quieres, pero no te pueden falsear TODOS y cada uno de los nodos intermedios, que en el 99,99% de las ocasiones ni siquiera corresponden a nombres reconocibles y por tanto ninguna compañía se molesta en falsear su ubicación por motivos de márketing.
Quieres mirarte los datos y dejar de decir cosas sin sentido, te lo vuelvo a repetir, mira un traceroute a Google, o usa los de esta noticia, verás que viaja por la red del ISP y luego ya salta a las de Google, no hay nodos intermedios que te saquen las rutas porque como digo cuanto menos saltos y más proximidad menos costes para Google.
Por eso, obteniendo el camino, puedes perfectamente rastrear la ubicación. De hecho sólo los programas de juguete para los cuales la ubicación no es un dato crítico pueden basarla en buscar un rango de IP en una base de datos como tú dices. Cualquier programa con cara y ojos se basa en el trazado de nodos hasta las proximidades del punto destino. Incluso los sistemas de ubicación no-GPS de los móviles funcionan así.
Sí, y en este caso ese trazado es viajas por la red "local" (del país) y luego saltas a la IP de Google, con lo cual no puedes deducir absolutamente nada con tus grandes teorías de análisis de nodos.
No te hagas tantas pajillas y haz la simple prueba, hombre, que estás hablando por hablar. Haz un simple "traceroute" y ubica todos los nodos resultantes con cualquier base de datos de IP, verás que el camino te determina perfectamente el origen y el destino, y que en caso de haber alguna ubicación falseada queda descaradamente descartada como "outlier".
Yo ya te lo he dicho en mi anterior mensaje y en este, así que haz tú la prueba y demuéstrame ese estupendo análisis de nodos de proximidad a los servicios de Google, pero ya te aviso que un salto de un nodo europeo a uno de Google directamente no prueba absolutamente nada.
"he dicho que las peticiones que haces van al datacenter más cercano, que luego este tenga que pedirlo a otro data center o no ya dependerá de los datos que tenga"
Obviamente, la no disponibilidad hace que el camino sea más largo, bien sea por intranet o mucho más usualmente por extranet (porque montar una red interna a nivel internacional no es algo tan trivial como tú pareces suponer, es virtualmente imposible si no posees cableado propio, y la mayoría de compañías no tienen). Y aunque tú le restes importancia al hecho, eso contraviene tu tesis principal de que las peticiones sólo llegan hasta nodos próximos. Las peticiones siempre siguen saltando hasta que encuentran un servidor concreto que las puede servir directamente.
Venga deja de decir absurdeces, estamos hablando de Google, si fuera un ISP internacional sería el tercero por volumen, ¿y tu teoría es que no tiene redes propias? cuando llegas a esos volúmenes simplemente por cuestión de coste te sale a cuenta tener cableado propio porque el tráfico que viaja por tu red no te cuesta nada mientras que el que viaje por la de los demás te cuesta dinero.
A ver que no es tan difícil, tu petición llega al data center más cercano y este, si no tiene los datos, hace OTRA PETICIÓN distinta al otro data center, cuando este devuelve los datos el data center al que has enviado la petición te responde a ti, pero tu petición no viaja al otro datacenter, es tan estúpido como que me digas que cuando consulto cualquier web mi petición llega a la base de datos porque no hay otra forma que ir saltando nodos, no, tu petición llega al servidor web y esta se va a la base de datos o donde haga falta para recuperar lo que necesite para tu respuesta, pero lo hace con otras peticiones totalmente independientes, ¿o acaso me vas a decir que cuando leas este mensaje tu petición ha llegado al servidor de base de datos que tiene Meneame? Eso además de ser ridículo sería un problema de seguridad importante.
Es más, te equivocas rotundamente al afirmar que un datacenter intermedio "pide" la información a otro datacenter para luego servírsela al cliente. Eso es ineficiente de cojones. Lo que hace el datacenter intermedio si no puede servir directamente la petición es pasar la petición del cliente (usualmente enriqueciéndola con metadatos) a otro datacenter para que éste la sirva directamente al cliente, de nuevo alargando el camino con ello y aproximándolo más a nodos centrales. Cualquier otra cosa es menos eficiente y más costosa para la compañía.
¿Has trabajado con data centers? Porque lo que tu propones si es costoso, el tráfico en tu red no tiene coste alguno más allá del alquiler si no es propia, pero puedes enviar los datos que te apetezca, en el momento que sales a otra red te sale por una pasta, es más todos los servidores de caché del mundo, como Akamai se basan en tener el contenido lo más cerca del destinatario, no en enviarlo a donde esté el original porque es absurdo.
Pero claro tiene mucha más lógica tener todo Youtube, Google, GMail, ..., en un data center enorme en Mountain View, los otros data center de Google deben estar de adorno porque el traceroute prueba sin lugar a dudas que todas las peticiones acaban allí.
No me hacía falta la lección sobre replicación de metadatos al estilo DNS, gracias. Tú sólo hablas de datos estáticos, que se puede replicar periódicamente, y crees que eso es todo. Pero justamente gracias a compañías como Google, Internet hace años que ya no funciona únicamente así. Si tú vas a Youtube y cuelgas un vídeo desde España, éste puede abrirse AL INSTANTE en Japón y obviamente aún no se ha replicado en ninguna parte ni siquiera en forma de metadatos. Insisto, se puede acceder AL INSTANTE, y no "luego" como tú convenientemente estipulas para que dé tiempo de replicar sus metadatos. Si lo accedes desde Japón nada más colgarlo en España, la petición de búsqueda va a ir de Japón a bases de datos centrales en todos los continentes (actualizadas al colgar el vídeo) para averiguar temporalmente dónde demonios está el vídeo solicitado, y finalmente a España para acceder al vídeo en sí. Te puede parecer exagerado, pero no hay otra manera de hacer que los datos dinámicos sean accesibles al instante.
Te repito por enésima vez, te equivocas totalmente, eso de "AL INSTANTE" no es así, es más te contradices si tienes que actualizar las bases de datos ya no puede ser "al instante" actualizar varias cosas a nivel mundial requiere tiempo es más eso es precisamente lo que me intentas rebatir, esas "bases de datos continentales" que dices están en los data centers, y lo que llamas actualizar es lo que he dicho yo que es replicar los datos en esos data centers. Pero es que además he ido más allá y te he puesto como funciona Spanner, esa base de datos que no es centralizada sino que es distribuida a nivel mundial, presentado por ellos mismos, y que se llama Spanner, entre los ejemplos que pusieron en la presentación está el borrar un amigo en Google+ y como lo replican entre los data centers. Pero supongo que deben tener ese protocolo para replicar transacciones entre data centers para pasar el rato, porque en realidad no lo usan.
¿Y por qué no replicar contenido pesado como vídeos? Pues por lógica, hay vídeos que simplemente van a interesar a nivel local, hay otros que no van a interesar a nadie, invertir tiempo y recursos en replicar esa información por todo el mundo no tendría sentido, por lo tanto el contenido más pesado es más eficiente replicarlo cuando hay demanda de él.
Pero oye, vamos avanzando, ya has reconocido que como mínimo tienen data centers en varios lugares del mundo, ahora solo te queda decirme como llega mi petición de ese video de YouTube a ellos si todas las IPs de Google van a un único data center en Mountain View. Aunque bueno, igual son los mismos del protocolo de replicación, que lo hacen para pasar el rato y en realidad tampoco los usan para nada.
Aplica lo mismo al correo, a los sistemas de almacenamiento remotos, y en general a cualquier servicio dinámico accesible vía Internet. La latencia de replicación no es una opción aceptable en la mayoría de servicios utilizados hoy en día.
Venga ahora explícame como actualizas las "bases de datos continentales" esas tan maravillosas sin tener latencia, supongo que si lo llamas "actualización" en lugar de "replicación" debe saltarse las leyes de la física o se hace a nivel cuántico y aparece la información disponible en todas las "bases de datos continentales" de forma instantánea.
Por poner otro ejemplo dinámico menos evidente, si tu móvil informa a Apple de que tu ubicación actual está en Madagascar (por ejemplo), esta información tiene que centralizarse lo antes posible para ser procesada en el siguiente lote de análisis, y por ello los nodos intermedios (los de Apple también) irán pasando el paquete hasta llegar lo más cerca posible de un sistema de nodos centrales que se dedican a analizar dichos datos. Puedes comprobarlo trivialmente viendo que en cosa de minutos el asistente de Apple instalado en tu móvil te proporciona datos "online" de Madagascar y no de tu ubicación habitual. Los metadatos de ubicación que maneja el servicio no vienen directamente del cliente, sino de servidores que centralizan dichos metadatos.
Y aprovechando el mismo ejemplo, incluso si te ubican por antenas de telefonía, esos datos de tu ubicación pasan por servidores centrales de la compañía telefónica de turno.
¿Minutos? ¿Eso es lo que llamas "AL INSTANTE"?, no tengo nada de Apple pero si me dices que tarda minutos igual si que usa ese sistema tan maravilloso de una base de datos centrales. Lástima que Google utilice un sistema tan ineficiente y cuando conecto en un aeropuerto de otro continente nada más llegar me salga en pocos segundos cosas como la información del tiempo local en Google Now, si es que deberían centralizarlo todo como Apple.
El video es interesante, pero sabe a poco.
Por una serie de tubos.
A mí me gustaría saber más bien cómo se hacen los rescates a bancos e infiernos de esos.
Una transferencia de Ángela Merkel a varios bancos y de repente tienen más pasta en contabilidades?
Me encantaría saber cómo viaja el dinero (lejos de los pobres, eso fijo).
¿Os habeis fijado la cantidad de saltos que da la conexión de Francia a The Pirate Bay?
- Por la vía
-Cállate tonto que ya lo sabía
A saber que más habrá bajo el océano... ¿bob esponja?
por hilitos de plastilina, lo sabe todo el mundo
Cada uno puede mirar por donde pasan sus paquetes de datos. Por ejemplo para saber por donde "saltamos" para llegar a www.youporn.com
OS Microsoft:
TRACERT WWW.YOUPORN.COM
OS UNIX/LINUX
TRACEROUTE WWW.YOUPORN.COM
Veréis por donde pasan vuestros datos. Si probáis páginas webs feas (www.aljazeera.com o www.iran.ir por ejemplo) veréis que hay "saltos" que no se identifican, cosa que no pasa cuando trazas a youtube, google, amazon o cualquier web "normal"
#16 Otra en la que no se identifica algún router intermedio :
movistar.es
#16 No tienes ni puta idea de lo que hablas. Negativo.
#29 Un poco feo poner un negativo por eso, me parece que no es su utilidad teórica, almenos dile al chaval que las cosas se pueden configurar para que no respondan pings