Cher journal, j'espère que ce titre n'est pas trompeur, en tout cas je n'ai pas trouvé mieux.
SPDY (à prononcer SPeeDY), est un concept de Google qui vise à remplacer certaines requêtes HTTP (toutes si possible?)
Ils recherchent deux effets :
- réduire la latence (chargement d'une page, d'une appli web...)
- réduire la charge pour le serveur
Pour résumer, voici ce que Google reproche à HTTP (version complète en anglais dans leur "livre blanc", lien 2) :
- HTTP n'est pas fait pour la latence (à l'époque de sa création, ils avaient d'autres chats à fouetter)
- Souvent, HTTP utilise une connexion par requête (normalement on peut enchainer plusieurs requêtes dans une même connexion, mais si le serveur ne répond pas rapidement, le client ouvre plusieurs connexions...)
- Les requêtes ne sont initiées que par le client (pas de push possible)
- Entêtes non compressées (et bien trop longues : cookies, useragent......)
- Entêtes redondantes (puisque envoyées pour chaque requête)
- Compression optionnelle (malheureusement gzip n'est pas obligatoire)
Ils ont (a priori) étudié des solutions déjà proposées, mais rien ne semble correspondre. Ils proposent donc SPDY.
D'après ce que j'ai compris pour le moment, SPDY c'est, pour résumer :
- compatible avec l'existant : il utilise TCP et SSL (c'est la moindre des choses...)
- un HTTP bien élevé, qui privilégie une seule connexion pour passer plein de requêtes
- des entêtes réduites au stricte minimum, et le maximum d'info compressées
- une bonne intégration de SSL
- une méthode pour que le serveur contact le client pour du push
Pour plus d'info, je vous conseil le lien (2).
Concrètement, sont déjà dispo :
- la description du protocole (3)
- un navigateur compatible, une branche chromium (4)
Ils ont bien sûr codé un serveur hybride HTTP/SPDY pour tester l'ensemble, il sera bientôt disponible, en open-source.
(1) Site officiel : [http://sites.google.com/a/chromium.org/dev/spdy/]
(2) Page explicative : [http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepa(...)]
(3) Le protocole : [http://sites.google.com/a/chromium.org/dev/spdy/spdy-protoco(...)]
(4) Chromium modifié : [http://src.chromium.org/viewvc/chrome/trunk/src/net/flip/]
Journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP
13
nov.
2009
# Et comme serveur ?
Posté par Mr Kapouik (site web personnel) . Évalué à -6.
[^] # Re: Et comme serveur ?
Posté par pampryl . Évalué à 10.
# Un serveur qui fait du push
Posté par gUI (Mastodon) . Évalué à 2.
Mis à part passer une nouvelle étape dans l'intrusivité des pubs et autres pollutions, vous voyez un exemple concret de bonne application du push ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Un serveur qui fait du push
Posté par Julien Gilbert . Évalué à 3.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Un serveur qui fait du push
Posté par Psychofox (Mastodon) . Évalué à 5.
[^] # Re: Un serveur qui fait du push
Posté par dyno partouzeur de drouate . Évalué à 10.
[^] # Re: Un serveur qui fait du push
Posté par mota (site web personnel) . Évalué à 10.
Par exemple dans Gmail, pour pas que le serveur ne subisse de requete inutile toutes les X secondes/minutes pour checker les nouveaux mails.
De meme pour wave.
Ca representerait beaucoup d'economie pour mountain view un protocole integrant le push, et par extension, avec ce cher et magnifique web 2.0, le reste du monde en profiterait.
[^] # Re: Un serveur qui fait du push
Posté par bubar🦥 (Mastodon) . Évalué à 3.
quoi ? c'est vendredi aussi sur /.
[^] # Re: Un serveur qui fait du push
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 7.
Allez, un exemple qui n'est pas boursier:
soit Koha, logiciel de gestion de bibliothèque (bib de bouquins) full web. Les lecteurs/étudiants/utilisateurs peuvent poser des demandes de réservation depuis le web. Actuellement, les bibliothécaires ne peuvent être informés que de 3 manières :
- soit on envoie un mail
- soit la bibliothécaire regarde la page ad-hoc régulièrement
- soit on fait un ajax qui va interroger toutes les mn. Ce qui n'est pas top en matière de perfs.
Voilà, c'est l'exemple qui me vient immédiatement à l'esprit, (c'est du vécu quotidien). Je pourrais citer plein d'autres exemples dû au coté "déconnecté du web" : "j'ai changé ce paramètre sur ce poste, je vois rien sur le poste d'à coté : ah, mais oui ma bonne dame, faut cliquer sur F5 pour recharger la page pour voir vos changements pris en compte"
PS : pour utiliser ggdocs (avec modération) depuis quelques temps, je dois dire que je suis TRES impressionné de l'édition collaborative d'un document...
[^] # Re: Un serveur qui fait du push
Posté par jeffcom . Évalué à 7.
[^] # Re: Un serveur qui fait du push
Posté par leoboy . Évalué à 8.
Typiquement, des outils comme Jffnms ne sont pas capables de montrer l'apparition d'une alarme en temps réel; il faut rafraîchir la page web.
Avec SPDY, on pourrait avoir les alertes remontées en "temps réel".
Les exemples sont nombreux et ne manquent pas. Rien que dans le giron de la réservation en ligne, des outils transactionnels et de la surveillance d'événements temps réel, il y a des ouvertures.
Amha, la question est plutôt de savoir :
-S'il ne faudrait pas plutôt inclure cela dans une nouvelle mouture de HTTP (mais surtout, est-ce faisable sans que ce soit trop galère ?)
-Si ca ne vaudrait pas le coup que l'IETF y participe, ou que Google consulte un peu plus de monde (peut-être est-ce déjà le cas, d'ailleurs)
-Si cela deviendrait un vrai standard ouvert, appuyé par une RFC, sans royalties ou brevets.
A suivre pour le moment, donc.
[^] # Re: Un serveur qui fait du push
Posté par M . Évalué à 3.
[^] # Re: Un serveur qui fait du push
Posté par leoboy . Évalué à 8.
La dernière news date d'octobre 1999, il y a donc... 10 ans
Certaines des mailing-lists ne reçoivent plus de messages depuis 2003.
Mais dans le principe, peut-être. Faut voir, la spec initiale a bientôt 14 ans... Est-t-elle toujours réaliste par rapport à ce que l'on sait faire, ce que l'on a besoin de faire aujourd'hui ?
[^] # Re: Un serveur qui fait du push
Posté par M . Évalué à 5.
[^] # Re: Un serveur qui fait du push
Posté par Julien Gilbert . Évalué à 10.
désolé.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Un serveur qui fait du push
Posté par Ummon . Évalué à 9.
[^] # Re: Un serveur qui fait du push
Posté par galactikboulay . Évalué à -1.
[^] # Re: Un serveur qui fait du push
Posté par leoboy . Évalué à 9.
Regarde, même les policiers se mettent à remplacer "maghrébin" par "auvergnat"... (Doit-t-on en déduire que les policiers ont de l'humour, ou bien que leur travail devient triste... ?)
Et puis, c'est connu, les sockets vont par deux (autrement, il y a un problème). C'est pour cela qu'on parle d'une paire de chaussettes dans le monde réel, terme qui n'est rien d'autre qu'un abus de langage récupéré du monde informatique.
[^] # Re: Un serveur qui fait du push
Posté par phoenix (site web personnel) . Évalué à 10.
[^] # Re: Un serveur qui fait du push
Posté par meumeu1402 . Évalué à 4.
Il y a un temps de latence important parfois, mais j'ai pu remaquer que ça marchait mieux quand il fait froid
[^] # Re: Un serveur qui fait du push
Posté par Kerro . Évalué à 3.
[^] # Re: Un serveur qui fait du push
Posté par phoenix (site web personnel) . Évalué à 1.
[^] # Re: Un serveur qui fait du push
Posté par Croconux . Évalué à 3.
[^] # Re: Un serveur qui fait du push
Posté par steph1978 . Évalué à 2.
alors, étant donné que le besoin existe, et quitte à inventer un nouveau protocole, pourquoi ne pas le prendre en compte ?
# Ouah !
Posté par nomorepost . Évalué à 10.
ses messages qui transitent en clair et qui bouffent la bande passante, ...
Ben oui, il était prévu pour un usage simple à la base: consulter des documents avec des hyperliens.
Quelle découverte !
Après avoir tout fait passer dans des trames HTTP pour passer les pare-feu qui n'ouvrent qu'un port, après avoir introduit un langage moisi pour ajouter l'interactivité, après avoir contourné le protocole pour échanger des données comme on veut dans les 2 sens, après avoir dénaturé le HTML et transformé les navigateurs en client lourd (riches pardon), voilà t'y pas qu'il faut remettre à plat tout ça !
Alléluia, Google propose de réinventer les bon vieux protocoles d'antan.
(Les jeunes peuvent pas connaitre) et propose le client multi-protocole (c'ets plus un navigateur, là) qui va avec.
Qu'ils sont fort chez Google.
Mais comme c'est Google , c'est forcément bien.
Nul doute que le vilain Krosoft, le castrateur Apple et le perfide Adobe vont pas en rester là et qu'on se retrouvera vite 40 ans en arrière.
Une ère nouvelle de croissance des offre d'emploi informatiques s'offre à nous, mes frères !
Et si on passait directement au XMPP, ca serait pas mieux ?
Vive le Vendredi !
[^] # Re: Ouah !
Posté par CrEv (site web personnel) . Évalué à 3.
ha ben oui, ça résoudra surement le problème de latence d'avoir du xml bien verbeux plutôt que du plain text qu'on pourrait ptetre gziper par contre
on me siffle dans l'oreille que google aurait aussi travaillé sur un xmpp modifié pour être plus léger, moins verbeux, non ?
[^] # Re: Ouah !
Posté par nomorepost . Évalué à 2.
Il suffit de s'accorder au départ des échanges avec un mode "debug" ou non
C'est pas une évolution du même ordre que de travestir un protocole non connecté en connecté.
[^] # Re: Ouah !
Posté par vg . Évalué à 5.
[^] # Re: Ouah !
Posté par steph1978 . Évalué à 2.
Donc pas en concurrence avec SPDY.
Bien au contraire, à lire les objectifs de SPDY, ça paraît un bon cas d'usage.
[^] # Re: Ouah !
Posté par vg . Évalué à 3.
Je trouve que SPDY se trouve un peu entre TCP et XMPP, il offre un transport bidirectionnel mais sans spécifier pour autant un format pour les données ou pour les échanges entre les clients, il devrait être très simple d'ailleurs de faire passer du XMPP au dessus de SPDY.
Mon avis c'est que le couple XMPP (pour les données) + HTTP (pour le binaire) est une solution beaucoup plus propre, fiable et évolutive que SPDY. Et je suis pas certain que SPDY puisse puisse faire mieux au niveau fonctionnalités sans avoir avoir une verbosité du même ordre que XMPP (après un coup de gzip).
[^] # Re: Ouah !
Posté par benoar . Évalué à 6.
Bon, c'est clair que l'effet réseau joue beaucoup, et que Google est bien positionné pour modifier l'écosystème par son écrasante domination. Mais ça n'est pas une bonne nouvelle quand ils décideront de choses un peu moins "bonnes" ...
# Push
Posté par Romuald Delavergne . Évalué à 2.
Cela impliquera donc beaucoup de chose comme de la publicité non sollicitée comme évoqué ci-dessus mais surtout lors des premières failles du navigateur, de gros problèmes à grande échelle. Car le navigateur devient de plus en plus l'application indispensable d'un poste client (bientôt serveur ?).
[^] # Re: Push
Posté par Thomas Pedoussaut . Évalué à 1.
[^] # Re: Push
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
Toi pas, mais des milliers de marketeux ont déjà pleins d'idées super pour te bourrer la face de pub.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Push
Posté par nomorepost . Évalué à -8.
http://linuxfr.org/~liberf0rce/28428.html
Nos ami Google ont juste rajouté qu'en plus ca ne soit plus du HTTP.
Bref bon courage aux futurs navigateurs pour supporter les différents "standards" qui vont émerger.
Reste à savoir si ca reste du Minitel 2.0 ou si c'est vraiment décentralisé.
[^] # Re: Push
Posté par vjm . Évalué à 10.
Ca devient insupportable d'entendre Minitel 2.0 à tout bout de champ surtout dans la bouche de personnes qui selon toutes vraisemblances ne comprennent rien de ce qu'ils racontent.
[^] # Re: Push
Posté par Vador Dark (site web personnel) . Évalué à 6.
[^] # Re: Push
Posté par Étienne . Évalué à 5.
- Le client envoie une requête
- Le serveur répond
- Le client envoie une requête
- Le serveur répond
- etc.
En SPDY, le client lit sur la socket en permanence pour que le serveur puisse également être à l'initiative de certaines requête, comme dit plus haut pour éviter d'avoir à poller des changements d'état.
Une connexion en HTTP est directement liée à la connexion TCP sous-jacente, en SPDY, la connexion HTTP se traduit plutôt par l'ouverture d'un flux sur la connexion TCP. Par exemple si j'ai en permanence 3 onglets ouverts sur https://linuxfr.org/my https://linuxfr.org/journal et https://linuxfr.org/forums il me faut 3 connexion http (voir une par fichier si je ne fait pas de keep-alive qui n'est pas obligatoire), avec SPDY, j'ouvre une connexion TCP sur laquelle j'ouvre 3 flux SPDY.
Étienne
[^] # Re: Push
Posté par nomorepost . Évalué à 7.
Quitte à renoncer à HTTP autant s'affranchir d'une architecture client/serveur (au sens fournisseur de service unique) et promouvoir une vraie architecture distribuée.
Notamment, en permettant à des noeuds de communiquer sans obligation de passer par un noeud central.
On s'assure ainsi qu'aucun fournisseur ne s'approprie des données dont la valeur est renforcée par le partage des autres et on s'oriente vers une vraie "information distribuée".
Qu'est-ce qui fait la valeur ajoutée de del.icio.us ?
Le fait que je puisse y mettre mes bookmarks ou le fait que les tags proposés soient pertinents parce qu'ils s'appuient sur ce que partage les autres.
Or, ai-je le droit ou la possibilité de reprendre ces données, l'infrastructure qui va avec, de rajouter un autre noeud au réseau pour proposer des services complémentaires ?
Si je forke, je repars de rien. Comment donc encourager une alternative libre et concurrentielle.
Or plus on renforce cette valeur ajoutée tout en privilégiant ce modèle centralisé et plus on renonce aux valeurs de libertés.
La seule victoire du web social libre aujourd'hui est Wikipédia alors que la bataille de la liberté se déporte (Facebook, Google Maps , google vs Wikia search, de.icio.us, flickr, ...) des logiciels vers les données.
Petit à petit ces informations se croisent, conquièrent de nouvelles plateformes et nous devenons encore plus dépendants car elles nous apportent. Et pourtant nous ne les maitrisons pas.
D'où ma provocation, je préfère privilégier une architecture complètement distribuée qu'une architecture "centralisée" qui se voudrait un HTTP amélioré.
Surtout s'il risque de conduire à l'explosion des standards.
Voilà pourquoi j'accueille fraichement cette nouvelle.
Malgré le fait que le protocole, le client et le serveur soient ouverts, Google gade parfaitement en tête qu'il pourra continuer à contrôler le "contenu" surtout si le conteneur est joli.
La liberté de l'information (y compris celle de respecter ma vie privée) m'importe plus encore que celle du logiciel.
[^] # Re: Push
Posté par M . Évalué à 4.
Donc on est obligé de maintenir une connection tcp pour chaque client. J'espère que les serveurs seront costaud pour tenir la charge.
[^] # Re: Push
Posté par Étienne . Évalué à 1.
Étienne
[^] # Re: Push
Posté par Elfir3 . Évalué à 3.
Genre réponse serveur :
HTTP/2.0 200 OK
Connexion-Type: push
etc.
Pour ce qui est de la compression, n'y a-t-il pas déjà moyen de compresser les échanges ? Il me semblait avoir vu quelque chose dans l'esprit dans la config d'apache, à moins d'avoir encore abusé du rhum ce jour là bien sur...
[^] # Re: Push
Posté par Victor . Évalué à 4.
[^] # Re: Push
Posté par Éric (site web personnel) . Évalué à 1.
- Au final avec le keep alive les serveurs laissent déjà les connexions ouvertes un moment, sauf qu'en plus ils laissent X connexions ouvertes par clients, X étant habituellement supérieur à 1
- Que ce mécanisme a heureusement un timeout, mais qu'au final ça oblige à réouvrir souvent la connexion TCP (et encore plus si on désactive le keep alive), ce qui est très lourd aussi pour les serveurs.
Le compromis entre connexion permanente (et le timeout correspondant) et connexion limitée à une seule requête est difficile à donner, il dépendra certainement de chaque serveur, mais ni le "bouh les connexions persistantes c'est le mal" ni le "il faut garder les connexions ouvertes pendant 12 heures" ne sont probablement des bonnes idées.
# tout dans le navigateur, et surtout sur leurs serveurs
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 5.
Si on veut de l'interactivité, on fait une vrai application lourde qui pourra alors communiquer avec des services web en toute tranquilité.
Ha mais peut-être que comme ça, google n'aurait plus le contrôle sur l'application utilisée et les données … Peut-être qu'il devrait tout passer en NX alors … 'fin j'ai du mal à comprendre l'intérêt du truc pour ma part.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par Romeo . Évalué à 2.
C'est quand même super pratique pour tout ce qui est mail (imap est basé sur ce principe, de mémoire, non ?).
Les flux rss ? plus besoin de faire 36000 requêtes par jour.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par Julien Humbert . Évalué à 5.
Bah oui les gros sites vont se prendre pas mal de requêtes inutiles, parce que bien entendu le client RSS ira vérifier plusieurs fois par jour (selon la configuration) et si on compte plusieurs milliers de personnes, bah ça en fait une masse.
Fallait réfléchir avant de répondre directement au commentaire précédent.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par 태 (site web personnel) . Évalué à 2.
Si chaque client fait une requête et une seule, le fait d'ajouter du push ne diminue pas la charge du serveur. Pour que le serveur pouse aux 36000 clients la mise à jour, il faut que le client ait initié la requête. Donc au lieu d'un aller-retour avec HTTP, on a un aller et deux retours avec SPDY.
> Fallait réfléchir avant de répondre directement au commentaire précédent.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par Julien Humbert . Évalué à 2.
Maintenant faisons un exemple avec un blog quelconque de google : http://googlewebmastercentral.blogspot.com/ (au hasard)
Celui-ci aurait donc pas loin de 70000 clients RSS qui envoient une requête toutes les 30 minutes (toujours selon un exemple, rien de scientifique) ça fait quand même pas mal de requêtes inutiles, puisque ça ne poste que très rarement plusieurs fois par jour.
Bien entendu je ne dis pas non plus que le système est pourri et que SPDY serait beaucoup mieux, je ne connais pas les implications que ça apporte, mais c'est simplement que en soit il y a quelque chose qui pourrait être amélioré, ou pas.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par Grunt . Évalué à 4.
Ben oui, XMPP par exemple. C'est bien XMPP. Et Google s'en sert déjà.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: tout dans le navigateur, et surtout sur leurs serveurs
Posté par bubar🦥 (Mastodon) . Évalué à 5.
Google souhaite accélérer remplacer /accélérer HTTP
S'il s'agit d'un protocole supplémentaire, bingo. Rendre les navigateurs compatibles avec un protocole en plus n'est pas prendre le contrôle de quoi que ce soit, mais de permettre un réseau plus propre d'une manière globale, en rapport avec les nouvelles utilisations, comme certaines des Google apps.
S'il s'agit de remplacer l'existant, franchement, là... ha ? bon ? hummm...
C'est comme dire que http est mieux et plus propre que ftp pour le transfert de fichiers. Ok c'est certainement vrai, mais perso, tout faire passer en http et par le 80... non ça va j'ai assez de moutarde pour mes frites, merci :)
# Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . Évalué à 1.
On peut mettre ce que l'on veut dans les entêtes non ? Exemple dernièrement de la nouvelle entête pour permettre au xmlhttprequest d'aller taper à la porte d'un serveur distant.
Ne serait-il pas possible de faire évoluer HTTP en ajoutant de nouvelles entêtes qui seraient simplement ignorées par les serveurs ne gérant pas ? C'est bien ce qui se passe pour le Content-Machin: gzip non ?
Si le client n'accepte pas speedy, il n'envoie pas la première entête. Si le serveur n'accepte pas speedy, il ne renvoie pas la réponse speedy puisqu'il ignore tout bêtement l'entente envoyée. On ne casse pas la compatibilité avec http, on peut avoir une transition en douceur et cela peut permettre :
1) entêtes réduites à partir de la deuxième requête (la première devant être compatible http standard)
2) plusieurs get dans la même requête à partir de la deuxième requête (ce qui consomme ce n'est pas la première requête, c'est les 400 autres pour l'xmlhttprequest ou les dizaines d'images
3) compression des entêtes à partir de la deuxième requête.
Ensuite, c'est quoi qui pose problème actuellement pour le push. Si on ouvre la socket et qu'elle reste ouverte, pourquoi le serveur ne peut pas envoyer de son plein gré des données ?
Si le problème c'est de demander au serveur d'ouvrir lui même la connexion, comme ces choses là vont passer les NAT et comment ces choses là vont s'assurer que l'ordinateur qui répond derrière est toujours le bon ?
Je n'ai sûrement rien compris au protocole, mais là comme cela je ne vois pas l'intérêt de casser le web (ou de créer un web 2.0 ;) pour ces points particuliers qui, j'ai l'impression, peuvent être règles avec http.
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par vjm . Évalué à 3.
[1] http://www.ietf.org/tao.html
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par Sylvain Sauvage . Évalué à 4.
Bêtement parce que le client n’attend pas de données à ce moment-là. Il n’attend des données qu’après avoir émis une requête (qui, au passage, peut avoir un « corps » après l’entête, POST). Donc, si le serveur envoie sans requête, le client ne lira pas les données non sollicitées ou les lira à la place de la réponse à sa requête suivante.
Le push change donc totalement le comportement Question-Réponse du HTTP.
Ensuite, rien n’empêche un HTTP/1.2 ou 2.0 (avec des requêtes nouvelles plutôt que des entêtes, p.ex. des requêtes d’abonnement (= une Question, plusieurs Réponses)). SPDY pourrait alors servir de base de discussion.
Le problème de SPDY, c’est plutôt le SSL obligatoire : en plus de la charge supplémentaire souvent inutile (intérêt du SSL pour une simple recherche ?), ça nécessite un certificat, et on sait déjà la quantité de certificats non signés et on va encore plus habituer les utilisateurs à accepter des certificats pourris…
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par CrEv (site web personnel) . Évalué à 2.
ça je pense que c'est possible, mais en quoi faire grossir les entête (et par la même les besoins en terme de bande passante) vont faire baisser la latence d'HTTP et réduire la bande passante utilisée ?
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par Guillaum (site web personnel) . Évalué à 5.
# envoi de la requete de la page, tout a fait normal, avec une unique entete en plus :
GET /mapage HTTP/1.0
Speedy-Accept: Version; multiples_get, push, truc;
Le serveur repond :
200 OK
Speedy-Accept: multiples_get
// ici il envoie le contenu de la page /mapage et reste en attente
Ici, le client sait maintenant qu'il peut faire ses multiples requetes, toujours sur la meme connexion, entre temps il a chargé mapage et sait donc quelles ressources suplementaires il doit traiter.
Speedy-Mget /mapage, image1, image2, image3, image4
Speedy-Priority: by-size
Et la le serveur envoie TOUT, compressé à mort.
On a donc une requete http classique pour la premiere page (dont le contenu de retour peut etre compressé), mais ensuite, en reutiliant la meme socket, on fait une operation pour recuperer les ressources necessaires)
Donc la requete de la page initiale est au meme prix qu'avant, mais les requetes suivantes (les images/styles/videos/...) de la page sont bien moins lourdes, puisque elles se font en une unique requete sur le meme canal.
Et comme cela, on peut dès demain avoir du speedy sur nos machines. C'est rétro compatible, mais si le serveur gere et le browser gere, on y gagne.
[^] # Re: Pas possible de faire évoluer HTTP ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
# Touche pas à (mon) grisbi !
Posté par Prae . Évalué à 6.
Rien que le push, c'est - de mon point de vue - une très bonne idée, ca évite les surcharges serveurs de requète inutile et les applis webs pourront attendre des données sans avoir à faire while(timeout) dans tous les sens.
Alors on en voit déjà crier au scandale "ouuuuuuuais les marketeux touuuuuuussa". Bah vous savez quoi, vous n'avez qu'a faire un module adblock version SPDY.
(c'est sûr que si c'était la fondation mozilla qui avait proposé cela, personne n'aurait crier au loup ...)
[^] # Re: Touche pas à (mon) grisbi !
Posté par Anthony Jaguenaud . Évalué à 10.
Le http n’est pas censé remplacer TCP, il est normalement au dessus. L’évolution des serveurs, enfin, des langages ainsi que le javascript, à fait qu'on peut faire des applications portables « distribuées » facilement. Du coup, le serveur n'a pas d'initiative ! Ben mince, c’est un protocole client/serveur.
S'il faut un nouveau protocole, aucun problème. Après, il faudra des applications côté serveur et côté client. Bientôt même les ports protocolaires ne serviront plus.
Je vote pour un protocole par application, après libre à vous d’utiliser une application multi-protocole.
[^] # Re: Touche pas à (mon) grisbi !
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Brefle, c'est pas forcément optimisé de tout faire passer par les même tuyaux, mais c'est beaucoup plus facile à maintenir.
Y'a du bon et du moins bon...
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Touche pas à (mon) grisbi !
Posté par Physche . Évalué à 8.
Cependant, il ne faut pas oublier que cette situation provient des administrateurs réseaux incompétents. Ceux qui ne comprennent pas le réseau. Ceux qui pensent qu'un port TCP, c'est un trou dans un mur qu'il faut reboucher le plus vite possible. Ceux qui n'arrive pas à imaginer qu'un port, c'est simplement une astuce pour lancer plusieurs services qui écoutent sur une même adresse IP.
Aujourd'hui, il n'est quasiment plus possible d'utiliser d'autres protocoles que HTTP (sur les ports 80 et 443) dans les entreprises.
La situation est pire que ce que tu décris, il n'y a pas que les protocoles IRC et NNTP qui ont été remplacés par HTTP, mais aussi la quasi-totalité des applications d'entreprises.
Désormais, au lieu de multiplexer les différents services au niveau TCP, on le fait au niveau de l'application, et tout communique en HTTP.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Avez-vous plus confiance dans le couple Apache+AjaxTerm qu'en OpenSSH ?
Pour moi, une grosse partie des DSI sont responsables d'avoir limité internet au port 80 et 443 et de limiter en plus cela au HTTP ! A limiter le nombre de protocole, on complexifie HTTP.
Un jour, le firewall HTTP sera indispensable et on aura des cartes réseau qui feront les calculs "offload" du HTTP pour ne pas surcharger les machines ;-)
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à -1.
Le problème avec Openssh est qu'il permet trop facilement de faire du reverse tunnelling, et donc de permettre un accès entrant directement sur le réseau de l'entreprise. Certe on peut faire la même chose sur du http, mais ca se detecte , et ce n'est pas parce que qu'on ne peut pas arrêter la peste qu'on ne doit rien faire contre le choléra...
Quant à n'autoriser que http en sortie, c'est aussi parce que c'est le protocol pour lequel on trouve le plus facilement des proxy avec des fonctions 'avancés' intégrées (filtrage d'url, support d'icap, interception ssl...).
[^] # Re: Touche pas à (mon) grisbi !
Posté par allcolor (site web personnel) . Évalué à 2.
est qu'il permet trop facilement de faire du reverse tunnellingPour ça faut être en interne. Et je ne vois pas ce que AjaxTerm empêche si une fois le shell accédé je peux ouvrir une connexion ssh vers l'extérieur. Et même si une fois à l'intérieur je n'ai accès qu'au port 80 et 443, un corkscrew + accès vers un serveur ssh externe sur le port 443 et je peux faire ce reverse.
Le seul moyen est alors de bannir la commande ssh une fois le shell accèdé... mais si j'ai accès au port 80, rien ne m'empêche d'accèder à l'extérieur et sur une page jsp par exemple qui laisse ouvert la connexion http et qui permet de faire du reverse à partir de là.
Là ou je veux en venir, c'est que ça ne sécurise rien du tout.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à 0.
J'ai peut-être mal compris, mais il me semble qu'on parle d'accés ssh en sortie, donc depuis l'interne ?
corkscrew + accès vers un serveur ssh externe sur le port 443
Il y a des moyens pour détecter et interdire ça. J'ai déjà vu des gens renvoyés pour ça...
Là ou je veux en venir, c'est que ça ne sécurise rien du tout.
OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet, c'est sur que ça fera avancer la sécurité. On ne peut pas tout bloquer, ça ne veut pas dire qu'il ne faut rien bloquer.
[^] # Re: Touche pas à (mon) grisbi !
Posté par allcolor (site web personnel) . Évalué à 1.
J'ai peut-être mal compris, mais il me semble qu'on parle d'accés ssh en sortie, donc depuis l'interne ?Désolé /o\ j'ai mal lu.
Il y a des moyens pour détecter et interdire ça. J'ai déjà vu des gens renvoyés pour ça...J'aimerais les connaître... à part une analyse statistique de l'utilisation de la bp je vois pas... le 443 c'est le port ssl, donc un proxy à part en faisant un man in the middle grossier, ne peut pas lire ce qui passe sur le port.
Mais comme je l'ai dit, rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne. Alors oui je ne dis pas qu'il ne faut pas mettre ces barrières ni qu'elles ne servent à rien en soi... mais qu'elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur (étant donné que cette personne y est déjà à l'intérieur).
Et les techniques si dessus sont largement accessible... il ne faut pas un tas de connaissance pour les mettre en œuvre.
[^] # Re: Touche pas à (mon) grisbi !
Posté par allcolor (site web personnel) . Évalué à 2.
J'ai accès à une machine en interne. J'ai accès à mes emails. Je peux éxécuter des programmes (shell, java, whatever).
Je peux écrire un prog qui se connecte à la boite mail et en fonction du sujet par exemple exécute le contenu du corps du message.
A partir de là, de l'extérieur je n'ai plus qu'a envoyer un email pour que des commandes soit exécutées sur la machine interne.
Faire ce qui est ci-dessus ne demande pas plus d'une heure à mettre en place.
Alors ces sécurités sont là uniquement pour se protéger de personnes qui ne sont pas absolument déterminées à faire ça. Enfin là je fais de l'argument de bar ;-)
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à 1.
Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).
rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.
elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.
Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
C'est la réponse classique des DSI quand je dis cela !
Il y a une différence entre tout bloquer et bloquer intelligemment. Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y. La personne faisant des aller et retour physique entre les sites X et Y, elle peut déjà transporter autant de données qu'elle le souhaite en pratique.
Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort, c'est aussi savoir quels sont les besoins et savoir un peu ce qui passe. Tout mettre dans du HTTPS, c'est se rendre aveugle.
Mais les DSI ne veulent pas gérer des règles de firewall variable et les maintenir dans le temps ! Donc on ferme tout. A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à 1.
Je suis prêt à devenir un deçaïdeur praissé \o/
Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y.
Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la boite ont accès à ton serveur externe, et donc au tunnel ?
Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort
Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes en pagaille (sauf à utiliser un firewall authentifiant), être sur d'être prévenu quand l'accès n'est plus nécessaire, être réactif parce que 'l'ip fixe de mon serveur perso chez moi à changé, vous pouvez mettre à jour les règles c'est méga urgent', ou encore parce que 'on m'a changé ma machine, vous pouvez remettre mes droit sur le firewall, c'est méga urgent (toujours)' ?
L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces accès qui découlent le plus souvent d'une organisation a l'arrache et pour lesquelles elle se fera taper sur les doigts en cas de problème. oui, je m'ennerve là :)
A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)
C'est pas nouveau, on peut faire des ponts avec le wifi aussi. Il suffit de les bloquer sur le poste de travail lorsqu'il est connecté au réseau filaire, ou les interdire complétement ,suivant ce que l'on veut.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
> boite ont accès à ton serveur externe, et donc au tunnel ?
Auncun. Dis donc, mon serveur, il est pour tous les gens de mon labo, pas seulement pour ce contrat avec cette boite. Si la boite veut un accès exclusif, qu'elle achète son serveur et les logiciels qui vont avec !
Cela dis, ça ne leur pose aucun soucis car encore une fois, un accès via ajaxterm est en pratique équivalent, en plus chiant pour l'utilisateur, a un accès via ssh.
> Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes
Désolé, je ne marche qu'en IP fixe... Effectivement, si chez vous, tout le monde change tout le temps, je comprends que vous ayez des soucis. Chez moi, une machine a toujours la même IP. Une IP, cela se spoof par une personne malveillante mais il y a alors un acte conscient, réfléchi et donc faute grave en regard du règlement intérieur.
> L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces
> accès qui découlent le plus souvent d'une organisation a l'arrache
Tu mélange deux choses. Déjà, pour moi, le service informatique est au service de la recherche donc des utilisateurs et non l'inverse. Ensuite, il y a un contrat de collaboration. Que je sois d'accord ou non est une autre chose. Ce contrat a été signé par les directions, donc je le met en place si techniquement cela est possible.
Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe (IP Renater, fonction publique, risque effectivement MONSTRUEUX pour la boite !), je me fais chier à monter un serveur Apache + AjaxTerm. Votre incompétence en terme d'organisation dans vos DSI, avec le poids des lourdeurs et le fait de ne rien ouvrir fait qu'heureusement, il y a des gens comme nous qui ouvre quand même pour qu'à la fin, cela marche.
Mais cela me prends un temps fou et ce sont mes utilisateurs qui trinquent.
Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche. Au final, le risque global toi + moi est bien plus élevé mais tu t'en fou car ta petite DSI pourra dire que rien ne passe et que vous tournez toujours avec votre firewall à 10 règles ! Mais tu te mens en passant puisque en pratique, tu acceptes du SSH sur HTTP...
Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ? A force de trop fermer, moi je dis que vous allez vous prendre un réseau parallèle sans vous en rendre compte.
[^] # Re: Touche pas à (mon) grisbi !
Posté par briaeros007 . Évalué à 3.
bon ben on va bypasser la sécu hein.
A force de faire de la sécu conne, on la bypasse
[^] # Re: Touche pas à (mon) grisbi !
Posté par 2PetitsVerres . Évalué à 2.
Mais bon, voilà, avant que les gens qui décident ne se rendent compte de ça, faudra un bon moment /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Touche pas à (mon) grisbi !
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Touche pas à (mon) grisbi !
Posté par Meku (site web personnel) . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à 0.
> boite ont accès à ton serveur externe, et donc au tunnel ?
Auncun
OK, comprends donc que la boite en face ne veuille pas forcement déporter sa sécurité. Après si le contrat est mal fait, ou qu'ils ne veulent pas payer plus cher pour faire quelque chose de propre, ce n'est pas la faute de la sécurité. Tu as tees objectifs, ils ont les leurs.
Chez moi, une machine a toujours la même IP.
C'est ton choix, ce n'est pas celui de la majorité des grandes entreprises pour des raisons evidente de flexibilité. Un utilisateur non admin aura du mal à spoofer.
Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe
Une seule IP ? Je vais finir par croire que tu bosse dans une boite de 10 personnes !
Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche
Vilain procès d'intention, j'essaye juste d'expliquer le point de vue du bord opposé au tiens. Dans les fait, oui, le risque pris par ma boite est plus limité qu'avec un tunnel ssh accessible potentielement au monde entier si ton réseau n'est pas sécurisé. Mission accomplie, par ici les pepettes.
tu acceptes du SSH sur HTTP...
j'accepte http, pas ssh et ses port forwarding/reverse tunneling
Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ?
Ca c'est un vrai enjeu d'avenir, mais certaines boites interdisent tout simplement la connexion usb de ce genre d'appareil su un poste d'entreprise.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Dis donc, relis depuis le début ou je vais finir par croire que tu ne comprends rien. Du coup, cela ne m'intéresse même plus de débattre avec toi. Entre deux boites de 10000 personnes, je parle d'ouvrir une porte entre une IP de la boite A et une IP de la boite B mais tu n'y comprends rien, tellement tu es arcbouté sur tout fermer.
> Ca c'est un vrai enjeu d'avenir, mais certaines boites interdisent tout simplement la
> connexion usb de ce genre d'appareil su un poste d'entreprise.
Tu parles toujours d'interdire... et je te parle de réseau parallèle. Si tu connectes une clef USB de 32Go deux fois par jours, devines quel est le débit de fuite ;-)
Avec les clefs USB, l'ADSL à la maison et les applications google, pour moi, il y a déjà un réseau parallèle dans beaucoup de situation.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . Évalué à -1.
Question de point de vue, du miens c'est toi qui ne comprends rien.
Du coup, cela ne m'intéresse même plus de débattre avec toi.
Effectivement je préfére aussi arreter de débattre avec quelqu'un qui ne sais pas regarder depuis la fenetre des autres.
[^] # Re: Touche pas à (mon) grisbi !
Posté par briaeros007 . Évalué à 2.
Moi j'oserais faire ça pour bypasser le fw de la boite ? meuh non...
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Faya . Évalué à 3.
HTTP existe, est documenté, fonctionne, ...
Les applications clientes utilisant ce protocol sont légions, populaires, simples.
Les langages permettant de l'utiliser correctement sont matures.
Si on arrive à l'utiliser pour des applications d'entreprises, ou est le problème ? Pour moi ça permet juste d'éviter d'avoir 10 clients lourds à installer - maintenir.
Ça me fait un peu penser à ceux qui râlaient lorsque penso avait écrit une application Iphone pour lire Linuxfr : ça paraît effectivement absurde de coder un truc à part pour quelque chose qu'un navigateur sait très bien faire. Bin si le navigateur sait faire des clients riches pour utiliser mon appli lourde ... pourquoi pas ?
[^] # Re: Touche pas à (mon) grisbi !
Posté par steph1978 . Évalué à 1.
Et je le déplore car ça reste une réflexion très intéressante.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Victor . Évalué à 1.
Rien d'autre à faire entre les deux, aucune conf spécifique, ça juste marche comme on dit par ici :)
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Victor . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par tyoup . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Touche pas à (mon) grisbi !
Posté par tyoup . Évalué à 1.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Victor . Évalué à 2.
# Question pour les connaisseurs de XMPP
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Question pour les connaisseurs de XMPP
Posté par Nÿco (site web personnel) . Évalué à 1.
1/ c'est compressé avec un plutôt bon taux, donc cool
2/ c'est sérialisé-désérialisé, donc bof effectivement
> Je sais par exemple que XMPP a des difficultés à traverser les NAT.
Ben tu sais mal alors ;-) Une connection XMPP client/serveur sur TCP/5222 peut passer facilement les NAT à condition qu'on laisse le port ouvert, sinon passer par les ports 80 ou 443, et encore mieux passer non pas sur TCP, mais sur HTTP, via BOSH.
De plus Jingle et ICE permettent le traversement des NAT, soit via négociation média, soit tout simplement par relais public (soit en P2P direct si pas de NAT).
[^] # Re: Question pour les connaisseurs de XMPP
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Le vrai probleme:
Posté par RB . Évalué à 1.
- bcp plus de socketa à allouer du coté serveur
Mais le plus grave:
Les outils actuels pour faire des pages ne sont absolument pas adaptés à ça. Toute la logique est basée sur une requête = un résultat. Un script PHP/ASP/... n'est pas fait pour tourner longtemps, il est prévu pour renvoyer une seule réponse (un seul set de headers, un seul body).
On peut vraiment dire ici que google médiatise une problématique connue depuis très longtemps mais on peut vraiment se demander si étendre http est une solution alors que l'ensemble des éléments devrait être repensé.
[^] # Re: Le vrai probleme:
Posté par kowalsky . Évalué à 1.
Ton script n'est pas obligé de "tourner longtemps". Si un socket est resté ouvert par le serveur, au niveau de ton script, tu ne t'en souci pas. Comme actuellement...!
Ton script fera un print sur la sortie sur un évènement donné et le serveur s'occupe du reste, à savoir, selon ton script, qu'elle client recevra ton print.
[^] # Re: Le vrai probleme:
Posté par RB . Évalué à 1.
[^] # Re: Le vrai probleme:
Posté par Étienne . Évalué à 1.
Je pense le contraire, ne serait-ce que parce que tu rajoute une sémantique en disant quels sont les flux qui ont besoin de rester ouverts (le flush où il y a du PUSH) et quels sont ceux qui peuvent être fermés. Le problème actuel du keep-alive (et la raison pour laquelle il est désactivé sur un bon nombre de serveur), c'est qu'on ne sait jamais si une connexion doit rester ouverte ou pas, donc tout ce qu'on peut faire c'est avoir un temps d'inactivité au bout duquel on coupe la connexion. En permettant de cibler les flux qui doivent rester ouverts, tu peux déjà fermer toutes les connexions sur lesquels il n'y a pas de flux en PUSH. D'autre part, tu multiplexe ta connexion pour y faire passer plusieurs flux et par là même tu diminue ton nombre de connexions. Si on prend l'exemple de linuxfr :
Un utilisateur qui ouvre la page d'accueil et la page des journaux
En SPDY
On va ouvrir une seule connexion avec 2 flux, pas besoin de PUSH, on peut fermer la connexion après le chargement des 2 pages
avec du HTTP en Keep-Alive
On ouvre 2 connexions qui restent ouvertes jusqu'à expiration du timeout.
Un utilisateur qui ouvre la page d'accueil et la tribune
En SPDY
Il ouvre une connexion avec 2 flux dont l'un en PUSH. Lorsque les 2 pages sont chargées, la connexion reste ouverte car il reste un fluxh en PUSH. L'utilisateur n'a pas besoin de solliciter le serveur toute les quelques secondes, le serveur peut envoyer des données seulement lorsqu'un nouveau message arrive.
En HTTP avec du Keep-Alive
On ouvre 2 connexions, la première se ferme à expiration du timeout, tandis que l'autre reste ouverte mais le client doit en plus solliciter le serveur toutes les quelques secondes pour récupérer les nouveaux message.
Je pense que globalement, avec un protocole qui permet de caractériser les flux, le serveur peut faire des choix plus éclairés que de simplement attendre la fin d'un timeout, et par là même mieux gérer ses connexions et ses ressources.
Quand au problème sur les autres outils, il a bien fallut développer des framework pour faire de l'Ajax depuis quelques années, et on n'a que l'embarras du choix, je ne pense pas qu'il faudra très longtemps si ce protocole (ou un similaire) débarque, pour voir apparaître de nombreuses solutions techniques.
# W3C
Posté par Mars . Évalué à 1.
Quoiqu'on en dise, client Rss compris jusqu'à présent c'était l'usager qui contrôlait sa demande d'info, avec SPDY j'ai comme un doute. A voir...
Pour les paranoïaque - dont je dois très certainement faire partie -, après que Google veuille contrôler toutes nos info, même si ses créateurs s'en défendent, il semblerait que la firme de Mountain View veuille nous imposer celles - les info of course - que l'on ne souhaitent pas obligatoirement voir s'afficher sur son navigateur. Bon OK c'est déjà le cas, mais la tâche n'en serait elle pas grandement facilitée et ce de manière plus pernitieuse ?
Quoiqu'il en soit on ne peut empêcher le progrès, plus exactement toute idée d'évolution (en bien ou en mal) mais dans le cas présent il me semble - et je ne vois pas ce qui l'empêcherait - que ce protocole comme bien d'autres auparavant peut très bien vivre sa vie au côté d' HTTP et non de s'y substituer.
Je m'étais toujours demander pourquoi Google avait créé son navigateur Chrome, et même son OS. Le fait que l'on ne parle que d'une nouvelle approche de l'informatique domestique et professionnelle avec le cloud computing pour lesquelles les anciens OS (Windows, MacOS, Linux) - ceux de l'ancien monde - ne seraient pas adaptés, pour justifier ces sorties me semblait un tantinet léger.
Avec la présentation de SPDY j'ai l'impression qu'ainsi Google se met à l'abri d'un manque d'enthousiasme des concepteurs de Navigateurs. Cette démarche ressemblerait - si je ne m'enduit pas trop d'erreurs - à celle pratiquée par Microsoft pendant ses premières années de l'Internet.
[^] # Re: W3C
Posté par kowalsky . Évalué à 4.
Pour les paranoïaque - dont je dois très certainement faire partie -, après que Google veuille contrôler toutes nos info, même si ses créateurs s'en défendent, il semblerait que la firme de Mountain View veuille nous imposer celles - les info of course - que l'on ne souhaitent pas obligatoirement voir s'afficher sur son navigateur.Premierement, google ne veut rien t'imposer, lis la fin de la news :
Pour plus d'info, je vous conseil le lien (2).
Concrètement, sont déjà dispo :
- la description du protocole (3)
- un navigateur compatible, une branche chromium (4)
Ils ont bien sûr codé un serveur hybride HTTP/SPDY pour tester l'ensemble, il sera bientôt disponible, en open-source.
Et si il y a bien une boite qui fait ce qu'elle dit en matière de libre, c'est google.
Donc, je pourrais installer un serveur chez moi et faire du push sur mon site de tchat afin que chaque client ne fasse pas une requette toute les deux seconde.
Ensuite, le serveur ne peut faire du push QUE SI LE CLIENT s'est connecté au site. Le client qui choisis le site à visiter, comme aujourd'hui. Donc si les pushs ne te plaisent pas, tu fermes le site et voila tout.
Tout ce que propose SPDY est faisable avec JavaScript, mais c'est plus lourd, c'est tout.
[^] # Re: W3CTout ce que propose SPDY est faisable avec JavaScript, mais c'est
Posté par nomorepost . Évalué à 2.
Tout ce que propose SPDY est faisable avec JavaScript, mais c'est plus lourd, c'est tout.
Adapter tous les navigateurs et les serveurs c'est vraiment plus lourd que ca ?
http://www.icefaces.org/main/ajax-java/ajaxpush.iface
[^] # Re: W3C
Posté par Mars . Évalué à 0.
Ensuite, le serveur ne peut faire du push QUE SI LE CLIENT s'est connecté au site.Comment sais tu au préalable que le site que tu vas visité fait du push ?
Et si il y a bien une boite qui fait ce qu'elle dit en matière de libre, c'est googlePersonnellement je ne peux juger vu que je n'ai pas de portable sous Androïd, mais je vois de plus en plus de posts qui mettent à mal cette assertion. Pour certains c'est vraiment une légende.
Je ne sais si ces reproches sont justifiés mais question respect des libertés individuelles Google répond rarement sans traîner des pieds aux recommandation de Bruxelles. Le Libre c'est les 4 libertés fondamentales certes, mais c'est aussi un état d'esprit. Et là ils se comportent comme une vulgaire entreprise capitalistique. Voir leur position en Chine vis-à-vis des dissidents et des autorités chinoises...
Leur relation au monde de l'édition pose aussi problème de ce côté de l'atlantique. Dans ce domaine ils ont vraiment tendance à imposer leurs vues profitant de leur puissance financière et technique. On est loin de l'état d'esprit de Burning Man...
Toutes choses qui font que je ne fais pas confiance en Google
[^] # Re: W3C
Posté par kowalsky . Évalué à 4.
Comment sais tu au préalable que le site que tu vas visité fait du push ?Comment sais tu qu'un site fait du javascript avant d'y aller ? Je dirais même que c'est encore plus facile avec du spdy. Si ton url commence par spdy:// , mefie toi, c'est un site fait par des vilains... :)Je ne sais si ces reproches sont justifiés mais question respect des libertés individuelles Google répond rarement sans traîner des pieds aux recommandation de Bruxelles. Le Libre c'est les 4 libertés fondamentales certes, mais c'est aussi un état d'esprit. Et là ils se comportent comme une vulgaire entreprise capitalistique.De quelle 4 libertés fondamentale parle tu ? C'est pas un truc de GNU ça ?Google, c'est Google_Summer_of_Code entre autre. C'est du blé dans firefox, du blé dans plein de projets. C'est aussi à chaque fois ou presque le choix de protocole ouvert.
Je ne vois pas pourquoi ils ne se comporteraient pas comme une vulgaire boite capitaliste, c'est une vulgaire boite capitaliste.
Franchement, je ne fait pas de corporatisme, je m'en fou grave de google (à part le GSoC :) ), mais ils ne se tournent quasi jamais ferme le "closed source", n'essaye pas d'enfermer les utilisateurs, etc... ça pourrait être gravement pire.
Voir leur position en Chine vis-à-vis des dissidents et des autorités chinoises...Tu propose quoi. Tu dirige google, tu propose quoi pour le cas chinois ? Pas de google ? Un google de l'état ? un google un peu "different" ? Et sinon, ça me fait bien marrer les critiques sur le google chinois, parce que le google (et le yahoo) français n'affiche pas de lien pro-nazi, ont viré l'acceuil de pirate bay(mais la c'est revenu), les sites pro-pédophiles, les sites pro-anorexie, etc...[^] # Re: W3C
Posté par Mars . Évalué à 1.
donc merci pour spdy://
2/ la polémique sur Google ça ne date pas d'aujourd'hui. Il y a les inconditionnels et les autres. Inutiles d'ostraciser ces derniers.
Concernant les problèmes d'éthique il n'y a pas que la Chine qui pose problème, Je remarque que ce soir la Suisse porte plainte contre Google au sujet de Google Street. La CNIL en a fait de même il y a quelques temps.
Que je sache aussi dans Gmail il y a des trucs closed source. Pour Androïd je crois avoir lu qq chose de ce genre. Mais je ne me rappelle plus à quel sujet.
Je n'ai pas de problème avec le moinssage, mais si on ne peut plus émettre un avis plutôt négatif sur Google non pas sur ses produits qui sont presque tous remarquables et très souvent largement au dessus de la concurrence et qui plus est innove plus que de raison (cf Wave) je trouve ça dommage
[^] # Re: W3C
Posté par kowalsky . Évalué à 2.
Mais sinon, tu peux avoir un avis négatif sur google, mais je ne veux même pas savoir ce que tu pense de Microsoft ou Apple !! :)
1/ je ne suis pas technicienne du netça existe ça ? :) :)[^] # Re: W3C
Posté par allcolor (site web personnel) . Évalué à 2.
Comment sais tu au préalable que le site que tu vas visité fait du push ?Il y a déjà plein de site qui font du (pseudo) push... avec javascript et du poll ou du long polling (mieux). Visites-tu les sites avec js désactivé ? si oui tu es cohérent avec ton avis ci-dessus, si non ton argumentaire est absurde.
Au pire même sans js, tu as toujours le meta tag refresh kipu qui pourra toujours faire un semblant de push (ouais du polling quoi :D ) qui bouffe du cpu et de la bp.
[^] # Re: W3C
Posté par __o . Évalué à 1.
Pour faire une comparaison:
RSS avec HTTP:
- Je télécharge le flux RSS toutes les heures pour voir si il a changé
La même chose avec du push, en schématisant:
- Je télécharge le flux RSS une fois. Si je veux des mises à jour, je laisse la connexion ouverte, le serveur m'enverra juste les nouveaux articles sur cette même connexion. Après le client RSS en fait ce qu'il veux.
[^] # Re: W3C
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Mais il y a les timeout, même sur tcp, donc ta connexion sur le flux RSS ne durera pas 5 jours s'il n'y a des posts que tous les 5 jours. Donc pour la maintenir, il faudra de temps en temps qu'un paquet circule pour dire que tu existes encore.
Tout cela pour dire qu'une connexion pour qu'elle se maintienne doit avoir un certain flux, même si on n'a rien a se dire.
[^] # Re: W3C
Posté par __o . Évalué à 1.
# Bof
Posté par Chavenay . Évalué à 1.
Par exemple :
-Modifier TCP pour pouvoir envoyer des données dans le paquet qui demande la connexion. W. Richard Stevens l'a écris dans un de ses livres.
-Envoyer les fichiers Javascript tokenisés.
Y a sûrement plein d'autres idées
[^] # Re: Bof
Posté par Éric (site web personnel) . Évalué à 1.
Pour les js tokenisés, faudrait que toutes les vm fassent un travail similaire, je ne sais pas si c'est réaliste.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.