url-shortener - tin - url shortener free

¿Cómo los acortadores de URL garantizan URL únicas cuando no caducan? (1)

Hay muchas preguntas aquí sobre stackoverflow con respecto a los acortadores de URL, así como en otras partes de Internet, por ejemplo:

¿Cómo codificar un acortador de URL?

¿Cómo el acortador de URL calcula la clave de URL? ¿Cómo trabajan?

http://www.codinghorror.com/blog/2007/08/url-shortening-hashes-in-practice.html

Sin embargo, hay una cosa que no entiendo. Por ejemplo, http://goo.gl usa cuatro caracteres en este momento. Sin embargo, afirman que sus URL cortas no caducan. Como se mencionó en el artículo sobre codificación de horror, si no pueden reciclar las URL, en un momento dado, la única solución posible es agregar un carácter adicional.

Ok, hasta ahora todo bien. Con 4 caracteres que significa unos 15 millones de direcciones únicas. Para algo como Google Maps, no creo que sea mucho y si no puedes reciclar, supongo que se quedan sin direcciones disponibles con bastante rapidez.

Ahora por la parte que no entiendo. Mientras distribuyen direcciones, comienzan a quedarse sin direcciones no utilizadas. Tienen que verificar si una dirección recién generada no se ha emitido todavía. La posibilidad de que esto haya sucedido y la dirección ya está en uso aumenta. La solución directa, por supuesto, es generar una nueva URL una y otra vez hasta que encuentren una gratuita o hasta que hayan generado las 1.5 millones de alternativas. Sin embargo, esto seguramente no puede ser la forma en que lo hacen, ya que esto llevaría demasiado tiempo. Entonces, ¿cómo logran esto?

Además, es probable que haya varios visitantes a la vez que solicitan una URL corta, por lo que también deben tener algo de sincronización. Pero, ¿cómo debe gestionarse la situación cuando es necesario agregar el quinto carácter?

Finalmente, al hacer una investigación sobre cómo funcionan las URL de http://goo.gl , por supuesto, solicité una URL corta para un mapa en Google Maps varias veces. Ninguno de ellos jamás será usado. Sin embargo, cuando Google imponga estrictamente la política de URL que no caducan una vez emitidas, esto significa que hay muchas y muchas URL inactivas en el sistema. Una vez más, asumo que Google (y los otros servicios también) han encontrado una solución para este problema también. Podría imaginar un servicio de limpieza que recicle las URL que no se han visitado en las primeras 48 horas después de la creación o menos de 10 veces en la primera semana. Espero que alguien pueda arrojar algo de luz sobre este tema también.

En resumen, recibo el principio general de los acortadores de URL, pero veo varios problemas cuando estas URL no pueden caducar. ¿Alguien sabe cómo se pueden resolver los problemas mencionados anteriormente y hay otros problemas?

EDITAR

Ok, entonces this publicación de blog arroja algo de luz sobre las cosas. Estos servicios no generan nada al azar. Se basan en la funcionalidad de incremento automático de la base de datos subyacente y aplican una conversión simple en el ID resultante. Eso elimina la necesidad de verificar si ya existe una identificación (no existe) y la base de datos maneja la sincronización. Eso todavía deja una de mis tres preguntas sin respuesta. ¿Cómo se "saben" estos servicios si un enlace se usa realmente una vez creado?

¿Por qué los acortadores de URL no eliminan entradas?

Escribí TinyURL (hace una década) para devolver una entrada que no necesitaba. Su respuesta me hizo darme cuenta de lo ridículo que era: me dijeron " simplemente crea todas las URL que necesitas ". Y las figuras se hablan:

A: con 26 letras minúsculas + 26 mayúsculas + 10 dígitos (la opción de sitios razonables), UN carácter le da 62 posiciones (es decir, 62 URL acortadas), luego cada personaje adicional multiplica el número de posición por 62:

0 char = 1 URLs
1 char = 62 URLs
2 caracteres = 3,844 (1 URL para cada persona en una aldea)
3 caracteres = 238,328 (idem, en una ciudad)
4 caracteres = 14,776,336 (en el área de Los Ángeles)
5 caracteres = 916,132,832 (en América, N + Central + S)
6 caracteres ~ 56,800,235,580 (8 URL para cada persona en el mundo)
7 caracteres ~ 3,521,614,606,000 (503 por cada humano, 4 por cada página web en el mundo)
8 caracteres ~ 218,340,105,600,000 (31,191 URL para cada humano)
9 caracteres ~ 13,537,708,655,000,000 (~ 2 millones de URL para cada humano)
10 caracteres ~ 839,299,365,900,000,000 (~ 120 billones de URL para cada humano)
11 caracteres ~ 52,036,560,680,000,000,000

B - En realidad, las necesidades y usos son más bajos de lo que uno podría esperar. Pocas personas están creando URL cortas, y cada persona crea pocas URL. Las URL originales son suficientes en la mayoría de los casos. Los resultados son que los acortadores más populares, después de años, aún cubren las necesidades actuales con solo 4 o 5 caracteres, y agregar otro cuando sea necesario costará casi cero. Aparentemente, goo.gl y goo.gl/maps están usando cada uno 5 caracteres, youtube está usando 11 (usando los 62 caracteres anteriores, más el guión y quizás algunos otros).

C - El costo de hospedar (almacenar + operar) una URL es, por ejemplo, $ 1000 / año por 1Terabyte, con cada TB capaz de contener 5 mil millones de URL, por lo tanto, una URL cuesta 0.2 microcolar / año en el hospedaje. Sin embargo, el beneficio para el Acortador también es muy escaso, por lo que el negocio no es muy sólido. Para el usuario, el beneficio de una URL es difícil de evaluar, sin embargo, un enlace perdido costaría mucho más que el alojamiento.

D - No tiene sentido que el usuario cree una URL corta si corre el riesgo de quedar inoperativo en los próximos años, por lo que la persistencia es un gran atractivo para un acortador, y un acortador serio probablemente nunca dejará de servirlos a menos que sean obligados fuera del negocio; sin embargo, esto ya sucedió y, de todos modos, las URL cortas tienen su carga de inconvenientes y beneficios, como se explica en Wikipedia "acortamiento de URL" (riesgos de todo tipo de piratería, contra el usuario, los sitios de destino o el Acortador; por ejemplo, uno podría atacar a un Shortener solicitando bots números de giga de URLs, una amenaza que seguramente es defendida por la mayoría de los Shorteners).

Versalles, mar 12 de marzo de 2013 20:48:00 +0100, editado a las 21:01:25