Liste de partage de Grorico
Un consortium d'entreprises regroupant Energy Pool, Schneider Electric et le CEA ont annoncé hier le lancement du projet EnR-Pool, ayant pour objectif de favoriser le développement des énergies renouvelables grâce à la modulation participative de la consommation énergétique d'industriels à très forte consommation.
Ce lancement a eu lieu sur le site de Savoie Technolac (Le Bourget-du-Lac), en présence de M. le Sénateur Jean-Pierre Vial, Président de Savoie Technolac, Co-président fondateur de l'INES et membre de la commission Energie du Sénat.
Le projet EnR-Pool consiste à évaluer de quelle manière des clients industriels peuvent, en adaptant ponctuellement leur consommation électrique, contribuer à résoudre certaines problématiques liées à l'insertion des énergies renouvelables intermittentes sur le réseau, tout en améliorant leur compétitivité. Pour ce faire, EnR-Pool développera des solutions et des modèles économiques permettant de valoriser les mécanismes de délestage et de consommation à la demande grâce à la mise en œuvre du projet.
« La production aléatoire des énergies renouvelables n'est pas nécessairement corrélée avec les besoins des consommateurs et peut induire de réelles difficultés pour la gestion du système électrique, a expliqué Olivier Baud, Président Fondateur d'Energy Pool et Pilote du projet EnR-Pool. L'éolien et le solaire étant des énergies intermittentes et variables, mais prédictibles, le projet EnR-Pool a pour vocation d'apporter des solutions au problème d'équilibre entre production et consommation d'électricité, en s'appuyant sur une participation active des consommateurs. »
Le projet EnR-Pool est piloté par Energy Pool, en partenariat avec Schneider Electric et les équipes du CEA à l'INES, et financé par l'ADEME dans le cadre des Investissements d'Avenir à hauteur de 1,1 million d'euros sur un budget total de 2,3 millions d'euros. D'une durée de trois ans, EnR-Pool prévoit un programme d'actions visant à :
• agréger et mesurer la production de plusieurs centaines de MW d'énergies renouvelables d'origines éolienne et solaire ;
• étudier la fiabilité des outils de prévision de rendement existants ;
• relever la consommation de gros consommateurs issus de plusieurs grands sites industriels en France métropolitaine ;
• développer des systèmes permettant une évaluation des capacités de ces mêmes sites à faire de la modulation électrique et à contribuer à l'équilibrage du réseau électrique ;
• analyser les nouveaux mécanismes des marchés de l'énergie.
EnR-Pool vise ainsi à valider la faisabilité technique de la démarche puis à développer des systèmes et modèles d'affaires permettant de valoriser les efforts réalisés par l'ensemble des parties : consommateur, producteur, gestionnaire du réseau et acteur d'équilibre.
A terme, le principe de gestion de la demande d'électricité développée par EnR-Pool pourrait permettre de diminuer ou de décaler la consommation lorsque le vent chute et/ou le soleil se cache, et inversement de la stimuler lorsque la production est importante alors que la demande est faible. Le maintien de l'équilibre du réseau en serait ainsi facilité à moindre coût.
 |  |
HTTP est devenu au cours des dernières années le protocole à tout faire. Au départ prévu pour servir de l'information structurée par lien hypertexte, il est aujourd'hui utilisé pour tout et n'importe quoi. Cette évolution ne va pas sans poser de problèmes. C'est pourquoi sous l'égide de l'IETF un groupe de travail httpbis s'est mis en place.
Une nouvelle mouture du protocole tarte à la crèmeHTTP est donc en route. Faisons un petit tour de son histoire et des projets en cours, avant d'écouter ce qu'à a nous en dire Willy Tarreau qui s'est particulièrement investi dans le groupe de travail httpbis.
NdM : Merci à Nÿco, Florent Zara, patrick_g, Raoul Volfoni, baud123, warwick, Nils Ratusznik, NeoX, zebra3 et Benoît pour leur contributions à cette dépêche.
- lien n°1 : Page du groupe de travail httpbis à l'IETF
- lien n°2 : SPDY: An experimental protocol for a faster web
- lien n°3 : Proposition de Tim Berners-Lee à l'origine du web
- lien n°4 : Fil sur SPDY sur la mailing list de haproxy
- lien n°5 : L'annonce de HTTP Speed+Mobility sur le blog de msdn
- lien n°6 : Site de l'IETF
Sommaire
Un brin d'histoire
GET /
HTTP et son complice le HTML trouvent leur origine dans les travaux de Tim Berners-Lee sur l'hypertexte en 1989. C'est la naissance du WorldWideWeb.
La spécification de base est posée :
- un verbe décrivant l’action (uniquement GET en HTTP/0.9) ;
- une URI désignant la ressource ;
- un code de retour ;
- l’information au format MIME ;
- pas d’état (la connexion est fermée à chaque échange).
On notera que dès le départ HTTP se bat un peu contre lui même, puisque dès 1994 l'usage des cookies se répand sous l'impulsion de Lou Montulli qui les utilise pour l'une des premières boutiques en ligne.
HEAD / HTTP/1.0
Il faut attendre 1996 pour que soit standardisée la première version du protocole (HTTP/1.0 RFC 1945). Elle apporte de nouveaux verbes (POST, HEAD mais aussi PUT, DELETE, LINK, UNLINK).
Elle pose les bases des bonnes pratiques en termes d’en‐têtes et de formatage des réponses, elle normalise les codes d’erreurs ; bref, transforme HTTP en protocole complet. Il est intéressant de constater que cette version du protocole prévoit déjà la possibilité de gérer du cache côté client (en‐têtes Last-modified, Pragma, Expires) et la compression. La problématique d’une utilisation optimale de la bande passante était déjà à l’ordre du jour.
TRACE / HTTP/1.1
À peine un an plus tard la RFC 2068 spécifie une version améliorée du protocole. Complétée en 1999 par la RFC 2616, cette version ajoute les verbes OPTIONS, CONNECT et TRACE (rendant obsolètes au passage LINK et UNLINK), rend obligatoire l'en-tête Host et fixe le protocole dans sa forme actuelle.
L'essentiel des ajouts de HTTP/1.1 concerne avant tout la négociation de contenu et de langage (Accept, Accept-Language, Accept-Charset) ainsi que le pipelining au travers notamment du Keepalive (en-tête Connection). Elle offre en outre la possibilité de découper la réponse en plusieurs morceaux (Transfer-Encoding: chunked).
PATCH / HTTP/1.1
L'évolution du protocole est depuis relativement constante, mais mesurée. On notera la standardisation en 2000 du HTTPS, l'usage des en-têtes (Etag et Vary) pour la gestion du cache côté client et de la compression, l'ajout non normalisé du verbe PURGE utilisé par les proxies cache. Plus récemment, l'ajout du verbe PATCH (RFC 5789) qui n'a pas remué les foules ainsi que de quelques codes d'erreur (RFC 6585). D'autres possibilités viennent de l'évolution de protocoles tiers comme TLS (en particulier SNI qui met fin à l'obligation d'avoir une IP par site pour le HTTPS et favorise des initiatives comme HTTPS Everywhere).
Oui mais
Au vu de ce rapide tour d'horizon, il apparaît clairement que le protocole HTTP s'il a été largement adopté pour sa simplicité, a également toujours cherché à devenir ce qu'il n'est pas. Car, malgré le keepalive et les cookies, il reste fondamentalement un protocole déconnecté et sans états. Cela bien sûr se discute, mais il est quand même notable de constater qu'il aura fallu attendre cette année pour avoir une implémentation efficiente du keepalive dans le serveur web Apache (avec le mpm-event) ou encore que les cookies posent de vrais problèmes de vie privée (voir par exemple ce journal). De même, la gestion du cache côté navigateur, met en œuvre pas moins de quatre en-têtes tous optionnels (Pragma, Expires, Last-modified, Etag) ce qui rend l'implémentation quelque peu délicate et les effets de bord relativement nombreux. La compression, bien utile dans son ensemble, alourdit les traitements serveur comme client et somme toute les possibilités offertes par le format MIME sont relativement peu exploitées.
Du coup, avec l’avènement des smartphones, de la FullHD, du monde tout connecté toujours dans les nuages et des User-Agent à rallonge ("Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" , "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19", …) certains ont senti qu'une évolution majeure du protocole était inévitable.
HTTPbis
Push toi de là
L'une des questions centrales dans l'évolution de HTTP est celle du push. Si elle a été abordée très tôt avec le type multipart/x-mixed-replace de Netscape (dès 1995), le défaut de consensus fait qu'à l'heure actuelle la situation n'est toujours pas figée. Le HTML5 avec les Server Sent Event (type text/event-stream) et l'API websocket devrait y remédier, mais le modèle même de HTTP rend difficile l'utilisation optimale d'une connexion persistante vers le serveur. Cette question est au centre de HTTP/2.0
Va donc chez…
Pour répondre à cette problématique, Google a introduit en 2009 le protocole expérimental SPDY. Il est actuellement implémenté dans Chromium, Firefox ainsi que dans Apache httpd via mod_spdy. Ce protocole se présente comme une couche de session, s'intercalant entre HTTP et SSL offrant :
- le multiplexage des flux (plusieurs flux au sein d'une seule connexion tcp)
- la priorité des requêtes
- la compression des en-têtes
Bien que l'amélioration des performances ne fasse aucun doute (le protocole a été par exemple adopté par twitter), SPDY est loin d'être idéal dans la mesure où il ne se défait pas des défauts de HTTP/1.1 et qu'il pose quelques nouveaux problèmes.
Dans un message sur la liste de haproxy, Willy Tarreau explique :
SPDY est sympa et apporte un gros gain de performances, mais au prix d’une infrastructure beaucoup plus complexe et d’une résistance moindre aux attaques DoS. Il est à peu près 100 fois plus facile de faire un déni de service sur un serveur SPDY que sur un serveur HTTP parce qu’avec la compression des en‐têtes vous pouvez forcer le serveur à analyser et traiter de très grandes requêtes avec très peu d’octets. La compression des en‐têtes signifie aussi que le double buffering devient obligatoire ce qui a un coût au niveau des mandataires.
Pour le moment avec SPDY, le HTTP/1.1 peut être optimisé autant que possible. Mais il y a des problèmes inhérents à HTTP/1.1 qui devront être réglés avec HTTP/2.0 (CRLF, en‐têtes longs, folding, etc.).
SPDY fait actuellement l'objet d'un « draft » dans le cadre du groupe de travail httpbis.
Ne pas confondre vitesse et précipitation
Suite à l’initiative de Google, Microsoft a proposé sa propre vision de l’évolution de HTTP appelée Speed+Mobility. Celui‐ci reprend l’essentiel de SPDY en essayant de tenir compte des appareils nomades, et en particulier d’optimiser les accès réseau pour accroître la durée de vie des batteries. Un rôle plus important est accordé aux websockets, mais pour l’essentiel l’approche est relativement similaire à celle de Google.
La revanche du proxy
Pour une approche différente, il faudra attendre une proposition émanant de Willy Tarreau (HAProxy), Poul‐Henning Kamp (Varnish), Adrien de Croy (WinGate) et Amos Jeffries (Squid) nommée httpbis Network Friendly. Elle s’articule autour de quatre améliorations à HTTP/1.1 :
- codage binaire des en‐têtes (cela évite les cycles de compression / décompression et favorise un traitement rapide) ;
- groupement des en-têtes communs. Si l’on multiplexe les requêtes au sein d’une même connexion, il est alors inutile de repasser à chaque fois certains paramètres (Host, User-Agent, version de HTTP…) ;
- multiplexage des requêtes et des réponses (elles sont envoyées en parallèle et sans ordre) ;
- un modèle en couche favorisant la mutualisation des informations (éviter les copies et le travail redondant).
Gageons que ce draft issue de l’expérience et du pragmatisme des développeurs trouvera sa place dans la mêlée. Il est certain (au vu des discussions sur la liste de httpbis) que ses auteurs le défendent avec vigueur.
Enfin
Comme on a pu le voir, HTTP/2.0 est sur les rails. Beaucoup d'acteurs du secteur semblent militer pour une finalisation rapide et une adoption massive. La démocratisation du web mobile y est sans doute pour beaucoup. Le groupe httpbis semble très actif et de nombreux documents sont produits.
On peut sans doute se féliciter de voir la communauté se saisir du problème. D'autant plus que les gens d'Apache, de Mozilla et quelques figures historiques comme Roy Fielding viendront sans doute y mettre leur grain de sel.
Questions à Willy Tarreau
Willy Tarreau est l’auteur du répartiteur de charge HAProxy. Il est aussi le dernier mainteneur des branches 2.4, 2.6.27 et 2.6.32 du noyau linux.
Comment est née l’initiative du draft httpbis-Network-Friendly ?
Willy Tarreau : Au début de l’année, Mark Nottingham a lancé un appel à propositions pour HTTP/2.0 sur le groupe. En fait il avait déjà prévenu un certain nombre de participants en privé de son intention de lancer le sujet, ce qui a permis aux gens de se préparer à mettre de l’ordre dans leurs idées. Les développeurs de SPDY ont rapidement proposé un document qui décrit très précisément le fonctionnement de leur protocole. Toutefois, à la lecture du document, un certain nombre de points ont causé une certaine discorde sur le groupe de travail : la compression des entêtes est obligatoire, puisque c’est l’un des piliers de la solution, et il n’est pas prévu de pouvoir réutiliser le port 80 ; au lieu de ça, une mise en œuvre sur TLS était suggérée (mais non mentionnée dans le document), ce qui rend TLS obligatoire partout où du HTTP est utilisé.
Les contraintes sur la compression et sur TLS sont des éléments bloquants pour un grand nombre de composants communément appelés les « intermédiaires », c’est‐à‐dire tous ceux qui subissent HTTP car étant placés entre un client et un serveur, ils doivent le comprendre et se rendre les plus compatibles possibles, à des niveaux de performance qui sont souvent d’au moins un ordre de grandeur au‐dessus de celui des serveurs habituels.
Pour des répartiteurs de charge qui traitent un million de requêtes par seconde, il n’est même pas concevable de devoir d’abord décompresser une requête pour commencer à l’interpréter, le coût est important et les DDoS deviennent grandement facilités. De la même manière, tout le monde n’est
pas d’accord pour chiffrer tout et n’importe quoi, que ce soit pour des raisons légales, d’inutilité (ex : communications entre serveurs) ou de difficultés à gérer correctement les certificats (ce qui est toujours pitoyable, chacun d’entre‐nous ayant pris l’habitude de cliquer aveuglément sur « j’accepte les risques » sur son navigateur en visitant plein de sites mal configurés).
Du coup, un certain nombre de participants travaillant sur des produits dits « intermédiaires » ont commencé à utiliser les mêmes arguments contre certaines des propositions. Amos Jeffries, le mainteneur de Squid, avait offert de participer à un draft si certains voulaient se lancer. Personne n’en avait vraiment le temps. Puis les discussions allant bon train, à un moment Roy Fielding, l’auteur d’Apache qui est un des auteurs des specificationss HTTP m’a répondu « écoute, ce n’est pas la peine de répéter sans cesse les mêmes choses, ici tout le monde a bien compris ton point de vue, donc maintenant tu fais un draft et ce sera mieux pour tout le monde ». Finalement, il a réussi à me convaincre de l’utilité de ce draft, mais je ne me sentais pas de me lancer là‐dedans tout seul, je ne connaissais rien au processus de publication, je suis nul en XML (le langage des documents) et je n’avais pas la vision complète des problèmes à couvrir. Finalement, j’ai commencé à pondre quelques lignes et j’ai décidé de recontacter Amos pour lui demander si sa proposition tenait toujours. Il était ravi de pouvoir se lancer aussi, donc on a travaillé à concevoir une ébauche de protocole plusieurs jours d’affilée sans s’interrompre, lui étant en Nouvelle Zélande, il n’y avait pas de temps morts. Puis, au fur et à mesure que nos avis convergeaient, j’ai commencé à rédiger. J’en ai fait part à Mark qui m’a proposé un créneau de présentation à la conférence qui se tenait à Paris la semaine suivante, ce que j’ai accepté avec la sensation d’un poids important qui commençait à peser sur mes épaules, parce qu’il fallait finir de produire le draft coûte que coûte. J’ai proposé à Adrien de Croy de WinGate de se joindre à nous, parce qu’il avait de bonnes idées, puis à Poul Henning Kamp de Varnish, vu qu’il avait une vision différente mais très complémentaire. Et, à raison de 6 heures de travail par nuit, le draft a vu le jour la veille de sa présentation.
Quel est son apport par rapport aux drafts existants ?
Willy Tarreau : En plus de l'optimisation des échanges entre le client et le serveur, il est focalisé sur deux points pas du tout couverts par SPDY, qui sont la préservation des ressources des intermédiaires, et la réutilisation des infrastructures existantes. Le premier point est primordial. Si le nouveau standard multiplie par 10 le travail des intermédiaires, on peut dire adieu au load-balancing et à pas mal d'accélérateurs. Au lieu de ça, on doit réduire encore les coûts en évitant de répéter des entêtes déjà transmis, afin que le 100 Gbps qui arrive puisse être une réalité. J'ai discuté de nos propositions avec les auteurs de SPDY qui y sont très favorables, ils ont reconnu ne pas avoir traité ce sujet et sont ouverts à remplacer leur algorithme de compression par un équivalent du nôtre qui aura une efficacité comparable mais à un coût beaucoup plus faible.
Le second point sur la réutilisation des infrastructures existantes me semble important également : pour qu'un protocole puisse être déployé, il faut qu'il ait des utilisateurs. Dans les écoles, les administrations et les grandes entreprises, si l'on n'a pas de produit pour analyser le contenu des échanges effectués sur ce nouveau protocole et pour le filtrer, on ne l'ouvre pas. Il faut aussi qu'il soit supporté par les caches, sinon le surcoût de trafic non cachable va engendrer son blocage de force à plein d'endroits. Où est la motivation alors pour les petits sites à implémenter un protocole qui n'est pas déployé partout ? Si c'est pour ouvrir systématiquement les deux (HTTP/1.1 et HTTP/2.0) et gérer la sécurité en doublon, on sait bien comment ça va finir, les gros qui ont des moyens supporteront les deux et les petits ne supporteront que l'ancien et on se retrouve avec un HTTP à deux vitesses.
Du coup nous avons proposé une méthode permettant de réutiliser ce qui existe avec le port 80, et qui permet à un client de formuler ses requêtes en HTTP/1.1 avec des extensions 2.0 et de continuer ensuite en 2.0 si toute la chaîne le supporte, et ceci sans ralentissement. L'avantage est que les administrateurs de réseaux pourront toujours gérer leur politique de filtrage à leur guise et maintenir ces sites ouverts avec un déploiement progressif au fur et à mesure que leurs composants sont mis à jour.
L’autre draft principal qui a été proposé consiste à réutiliser la couche WebSocket comme protocole de transport et de véhiculer des messages de type SPDY entrelacés dedans. C’est une façon de régler le problème du port 80 sans avoir à tout réinventer, car il y a quand même beaucoup de bonnes choses dans SPDY. Ce draft a été publié par Gabriel Montenegro qui est l’un des responsables du groupe de travail WebSocket et qui travaille aussi chez Microsoft. Il travaillait à côté de moi sur son draft pendant les conférences, et m’en a expliqué les principes. Il faut d’abord savoir que les drafts sont des travaux individuels, et que même si les individus partagent souvent des points de vue avec leur entreprise, leurs travaux sont personnels et n’engagent qu’eux. Mais, là, la suite était inévitable, je lui ai dit « tu vas voir que les journaux vont faire leur une en racontant partout que c’est Microsoft qui riposte à Google ». Et ça n’a pas raté vu que la presse ne publie que ce qui fait sensation :-). Nulle part il n’a été dit que l’un des pères de WebSocket pensait d’abord intervertir les rôles pour que WebSocket devienne le transport de HTTP !
As-tu le sentiment que les choses progressent dans le bon sens ? Que la discussion est ouverte ?
Willy Tarreau : En partie, oui. On sent déjà depuis plusieurs mois une préférence marquée pour SPDY parce que pas mal de librairies permettent de l'intégrer facilement à des nouveaux développements, et c'est séduisant. Les gains en vitesse de chargement qu'il procure en environnement mobile sont incontestables. Au-dessus de ça, il y a des tensions inévitables et compréhensibles. Des personnes qui ont travaillé longtemps et qui ont vraiment fait un travail de fourmi comme celui-ci n'aiment pas que leurs travaux soient critiqués par des gens qui n'ont rien à montrer en face. D'autre part, ces personnes fondent parfois des espoirs de futurs projets dont cette brique serait une première étape, et l'acceptation ou non de leur travail leur cause alors un certain stress légitime. Mais le fait d'avoir pu discuter avec les personnes en face à face aide beaucoup, ça permet de mieux comprendre les motivations des uns et des autres, de leur faire comprendre qu'on nage dans le même sens et qu'on n'est pas concurrents, et de mieux parvenir à des compromis sur certains points. Je pense qu'aujourd'hui les auteurs de SPDY sont prêts à revoir leur mécanisme de compression sur lequel ils ont pourtant fait un travail considérable. Ils ne sont a priori pas encore décidés à repasser sur le port 80, mais le succès espéré de WebSocket qui utilise déjà cette méthode pourrait faire changer les avis une fois que cela marchera bien. Il ne faut pas précipiter les choses sur HTTP, on risque d'en avoir pour 20 nouvelles années, et si on se plante, on restera encore en 1.1 comme les 10 années passées depuis la dernière tentative échouée de mise à jour.
Une dernière remarque ?
Willy Tarreau : Participer aux groupes de travail de l’IETF est très prenant et très utile, parce qu’en remontant des problèmes avant qu’ils ne deviennent des standards, on évite d’avoir à implémenter n’importe quoi plus tard dans ses propres produits. Et ça ne peut marcher que s’il y a beaucoup de participants, car personne ne détient le savoir. C’est ce qui a été difficile sur WebSocket, il y avait trop peu de participants et ça ressemblait à des guerres de bandes rivales, mais on a quand même abouti à quelque chose de bien. Pour participer aussi à quelques autres projets, j’ai remarqué une chose qui est très marquante au début : les jeunes se préoccupent du présent et les vieux du futur ! Je veux dire que les nouveaux n’ont pas l’expérience des protocoles qui vivent 20 ans et pensent d’abord aux apports immédiats, alors que les anciens savent que les apports ne se mesurent que dans la durée. Et je dois dire que l’exercice consistant à se projeter dans le futur pour estimer les impacts de telle ou telle décision relève un peu de la science fiction. On conçoit par exemple HTTP/2.0 avec en tête le fait que quand il sera omniprésent, les plus gros serveurs disposeront d’une connectivité en Terabit/s, qui sera aussi la taille de chacun des points d’accès des gros sites comme les réseaux sociaux. Et ça, je dois dire que c’est un exercice assez difficile mais nécessaire. J’ai entendu, par exemple, Roy Fielding dire « Si j’avais pu imaginer qu’un jour l’en‐tête If-Modified-Since serait responsable à lui seul de 20 % du trafic montant des smartphones, je l’aurais appelé autrement ». Il faut donc essayer de penser à tout et apprendre à ne pas rire des hypothèses farfelues émises par ses voisins. Et ça c’est un vrai défi !
Des hackersont donné, lors de la conf LayerOne, une explication plutôt impressionnante sur la manière dont ils s'y sont pris pour cracker le fameux captcha ReCaptcha géré par Google. Pour arriver au bout de leur peine, ils n'ont pas essayé de reconnaitre le texte, mais ils se sont plutôt concentrés sur la partie audio du captcha. En effet, contrairement à la version texte qui propose des milliers de mots, la version audio de ReCaptcha ne "connait" que 58 mots d'anglais différents.
De quoi sérieusement réduire le champ des possibilités... Pour rendre le déchiffrement plus complexe, Google avait ajouté sur son ReCaptcha un fond sonore se rapprochant d'un murmure qui en tout logique est très difficile à filtrer, mais que nos hackers ont réussi à balayer d'une main quand ils se sont rendus compte qu'il s'agissait d'un nombre limité d'enregistrements d'émissions radio.
Résultat, un petit script baptisé Stiltwalker, capable de venir à bout de cette protection anti-spam presque aussi bien qu'un être humain.
Puissant non ? Bien évidemment, 1 heure après la présentation, Google a modifié ReCaptcha, rendant leur technique inopérante. C'était quand même bien joué !
Merci à Ben_1212 pour le partage.
Envie de voyager ? Mais pas un sous en poche ?
Faites un peu de repérage le temps de rassembler quelques économies grâce à Google qui vient de sortir le World Wonders Project qui comme son nom l'indique rassemble tous endroits les plus merveilleux de notre jolie planète. A vous de choisir ce que vous voulez voir... C'est classé par région du monde ou par thème et chaque endroit est documenté.
Des sites archéologiques de Pompéi au Mémorial de la paix d’Hiroshima, le World Wonders Project de Google a pour ambition de vous faire découvrir les merveilles du monde moderne et de l’Antiquité comme si vous y étiez.
Grâce à la technologie Street View, les internautes du monde entier peuvent maintenant découvrir les sites du patrimoine mondial. Street View, déjà disponible dans de nombreux pays, est une fonctionnalité extrêmement populaire de Google Maps. Elle permet aux internautes d’explorer un quartier et de s’y déplacer de manière virtuelle, grâce à des images panoramiques des rues. Les progrès de la technologie en matière de photographie nous permettent désormais de sortir des sentiers battus afin de photographier quelques-uns des lieux les plus importants au monde pour les faire découvrir à tous.
Street View a déjà rencontré un franc succès auprès des touristes et des explorateurs virtuels passionnés. Par ailleurs, le World Wonders Project constitue une ressource précieuse pour les étudiants et les enseignants qui peuvent désormais découvrir de manière virtuelle quelques-uns des sites les plus célèbres au monde. Ce projet permet d’enseigner de manière innovante l’histoire et la géographie aux élèves du monde entier.
Le World Wonders Project repose également sur l’intégration d’un vaste ensemble de technologies Google, permettant de mettre pour la première fois les merveilles du monde à la portée des internautes du monde entier. Le site Web du projet propose également à ses visiteurs de découvrir des modèles 3D, des vidéos YouTube et des photographies des célèbres sites du patrimoine mondial.
Avec la collaboration de partenaires tels que l’UNESCO, le World Monuments Fund et Cyark, le World Wonders Project veille à préserver le patrimoine mondial pour les générations à venir.
Bon, je ne suis pas d'accord avec tous les choix et il en manque bien d'autres (surtout en Auvergne :-)))), et les photos ne sont pas toujours d'une qualité optimale mais ça vaut quand même le coup d'y jeter un oeil.
Bon voyage !
Joerg Marx est un photographe allemand proche de la nature. Après avoir travaillé plusieurs années comme photojournaliste, il photographie désormais des paysages et autres lieux cachés, souvent remplis de souvenirs.
Dans cette série « Fields », Joerg dépeint la campagne bavaroise. Ce n’est pas par hasard que Joerg Marx a choisi ce thème : il vît entouré de ces champs, et les lignes et les différentes perspectives le fascinent. Le résultat est très graphique et on aime beaucoup.
Quand on lui demande quel est le message qu’il veut faire passer à travers cette série, il nous répond « aucun ». « Les images ne disent rien, elles montrent des choses ». Joerg n’essaie pas de faire passer un message à travers ces photos. Pour lui, on peut faire ce que l’on veut avec des photos, ce ne sont pas des messages écrits, mais plutôt des objets visuels qui laissent des traces dans nos esprits, nos corps et nos vies.
Découvrez quelques photos de cette série dans cet article. Vous pouvez retrouver l’ensemble des photos de cette série sur son compte Flickr.
Pour aller plus loin :
- K. Leidorf, des photos aériennes très inspirées
- Marc Hoppe, photographie de nus sculpturales
- Zander Olsen : des arbres et des lignes
Je ne connais pas le niveau de cuisine de l’artiste Isaac CORDAL. Ce n’est surement pas un top chef, mais c’est un créatif hors norme.
Son art de l’ombre consiste à transformer avec minutie une passoire de cuisine en modifiant le modelage des courbes, cet artiste belge sublime cet outil en visage humain.
Ces passoires ont été disposé avec stratégies dans les rues de Londres, près de Dalston. Une fois la nuit venue, les lampadaires éclairent de leur milles feux ces étranges objets laissant apparaître dans leur ombre des visages humains ou bibliques.
Poétique!
Tous les gènes ne s'expriment pas de la même façon. Certaines régions de l'ADN peuvent parfois être pourvues d'un groupement...
