La réécriture d’URL récursive

Le fichier .htaccess

Mod_rewrite, ou la réécriture des URL "à la volée"

Site Web :
Webmaster Hub

Ingénieur de formation, j’ai depuis longtemps été attiré par l’informatique et le système d’exploitation Unix en particulier (premier système perso sous Unix fin 1978)

Après plus de 20 ans d’administration de systèmes Unix en tant que freelance au 4 coins de la planète, j’ai eu envie de faire autre chose et de poser mes valises en 2002.

L’étude du Php est simple lorsqu’on a "parlé couramment" le langage C pendant si longtemps. J’ai donc créé mes premiers sites dynamiques, en partant de la feuille blanche. Ensuite, le besoin de découvrir le monde du référencement m’a attiré vers les forums spécialisés, sur lesquels j’ai eu l’occasion d’enrichir mes connaissances sur le sujet, et y découvrir les plaisirs de la modération.

L’envie de démarrer un forum dédié aux Webmasters, ratissant plus large que le domaine du référencement, a germé lentement dès cette époque et a donné la naissance du Hub le 18 août 2003.

Articles de l'auteur :
Le PageRank par l’exemple
L’algorithme du PageRank expliqué - 2ème partie
L’algorithme du PageRank expliqué
La réécriture d’URL récursive
Le Round-Robin DNS de Google
Mod_rewrite, ou la réécriture des URL "à la volée"
Le fichier .htaccess

Comment ça marche ?

Le Round-Robin DNS de Google

1er septembre 2003, par Dan

Google a réparti ses nombreux serveurs dans différents centres de données (datacenters) de par le monde.

Datacentres Google	( Google en change régulièrement )
www-ab.google.com	Sterling (Virginie, Etats-Unis)
www-cw.google.com	Palo Alto (Etats-Unis, Californie)
www-dc.google.com	Washington DC (Etats-Unis)
www-ex.google.com	Santa Clara (Californie, Etats-Unis)
www-fi.google.com	(Europe,Supposé en Finlande ??)
www-gv.google.com	Dublin (Europe Irlande)
www-in.google.com	Santa Clara (Californie, Etats-Unis)
www-sj.google.com	San Jose (Californie, Etats-Unis)
www-va.google.com	Herndon (Virginie, Etats-Unis)
www-zu.google.com	Zurich (Suisse)

Lorsque vous émettez une requête vers http://www.google.com (ou .fr, .be,.ch...), votre requête est redirigée vers l’un des centres de données Google selon des critères de géolocalisation et de charge de ces derniers.

Cela se fait très simplement au niveau des résolutions de nom faites par les serveurs DNS, qui vous feront pointer sur l’un des ces datacentres.

Lorsque vous interrogez les DNS pour le domaine google.com, vous remarquerez que le TTL (time to live) est de l’ordre de 5 minutes (environ). Cela signifie que toutes les requêtes que vous envoyez à Google durant cette période utiliseront la même adresse IP que celle retournée lors de la première interrogation.

Une fois ce laps de temps écoulé, l’adresse IP correspondant à Google dans votre cache DNS sera considérée comme expirée et une nouvelle résolution de nom sera faite. En clair, vous aurez alors 90% de chances d’être mis en communication avec un autre datacentre.

En quoi cela impacte les recherches ?

C’est simple, comme il est matériellement impossible de maintenir tous les datacentres parfaitement synchronisés, les bases de données de certains centres seront "plus à jour" que d’autres. Ce qui fait qu’en interrogeant Google, les résultats pour une même recherche peuvent varier à quelques minutes d’intervalle.

Les plus grosses variations se remarquaient lorsque Google faisait des mises à jour mensuelles de ses bases de données. Les résultats variaient tellement d’un datacentre à l’autre, qu’ils donnaient l’impression de danser... d’où le nom de la "Google Dance"

Cette "Google Dance" n’a plus lieu actuellement, comme Google est passé à une indexation en continu, mais des essais peuvent être effectués de temps à autre sur l’un des datacentres, ce qui refait danser Google pour quelques heures ou quelques jours, et met la communauté mondiale des webmasters en ébulition.