Journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP

Posté par (page perso) .
Tags : aucun
29
13
nov.
2009
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/]
  • # Et comme serveur ?

    Posté par (page perso) . Évalué à -6.

    Il existe un serveur compatible déjà ou on a juste un client ?
  • # Un serveur qui fait du push

    Posté par . Évalué à 2.

    Je ne sais pas si je dois être taxé de paranoïa, mais je ne suis pas fan du tout de ce concept.

    Mis à part passer une nouvelle étape dans l'intrusivité des pubs et autres pollutions, vous voyez un exemple concret de bonne application du push ?
    • [^] # Re: Un serveur qui fait du push

      Posté par . Évalué à 3.

      Et encore, tu as pas vu l'intégration de adsense dans le code

      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 . Évalué à 5.

      oui : le trading boursier en ligne. Notemment pour des trus qui vont très vite comme le FOREX.
    • [^] # Re: Un serveur qui fait du push

      Posté par (page perso) . Évalué à 10.

      Oui.

      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 (page perso) . Évalué à 7.

      ah oui, il y a plein d'application concrètes de ce genre de choses.
      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 . Évalué à 8.

      Oui : Le monitoring, par exemple.

      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 . Évalué à 3.

        Tu veux dire faire un truc comme http://www.w3.org/Protocols/HTTP-NG/ ?
        • [^] # Re: Un serveur qui fait du push

          Posté par . Évalué à 8.

          Ca a juste l'air un peu mort, HTTP-NG.

          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 . Évalué à 5.

      J'espere que leur mecanisme de push passera les firewall, NAT & co.
      • [^] # Re: Un serveur qui fait du push

        Posté par . Évalué à 10.

        oui mais il faudra pusher très fort.

        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 . Évalué à 9.

        Une chausette TCP est bidirectionnelle.
        • [^] # Re: Un serveur qui fait du push

          Posté par . Évalué à -1.

          C'est quoi cette manie de traduire socket par chaussette ?
          • [^] # Re: Un serveur qui fait du push

            Posté par . Évalué à 9.

            Mais parce qu'il faut savoir rire un peu en informatique ! La vie est déjà assez triste comme ça...

            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 (page perso) . Évalué à 10.

          Moi j'accroche mes chaussettes à ma cheminé, et en effet, si je met une carotte, le lendemin, je me retrouve avec des cadeaux ;) mes chaussettes sont donc bien bidirectionnelle :D
        • [^] # Re: Un serveur qui fait du push

          Posté par . Évalué à 3.

          Cho7 serait bi ? Diantre, on en apprend tous les jours...
    • [^] # Re: Un serveur qui fait du push

      Posté par . Évalué à 2.

      on peut déjà faire du push avec http mais il faut bricoler.
      alors, étant donné que le besoin existe, et quitte à inventer un nouveau protocole, pourquoi ne pas le prendre en compte ?
  • # Ouah !

    Posté par . Évalué à 10.

    Le protocole HTTP est tout pourri avec son mode non connecté
    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 (page perso) . Évalué à 3.

      > Et si on passait directement au XMPP, ca serait pas mieux ?

      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 . Évalué à 2.

        Et alors le zippage à la volée reste possible sans changer le protocole non ?
        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 . Évalué à 5.

        Enfin le XML se compresse très bien quand même, et gzip et TLS sont intégrés depuis longtemps dans XMPP.
    • [^] # Re: Ouah !

      Posté par . Évalué à 2.

      XMPP est transporté par http
      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 . Évalué à 3.

        Heu, XMPP peut être transporté par HTTP avec BOSH mais c'est juste une option, le transport normal de XMPP se fait en TCP ...

        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 . Évalué à 6.

      C'est chiant quand même : on nous bassine toujours avec le "worse is better" quand on dit que HTTP c'est de la merde. Mais dès que Google trouve une "solution" qui est de remplacer HTTP (et comme tu dis, par quelque chose de pas très nouveau), ça devient tout de suite l'idée du siècle ...

      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 . Évalué à 2.

    Si le serveur est capable de faire du push, cela ne veut pas dire que notre simple navigateur deviendra un serveur ? On passe du modèle Client/Serveur à Serveur/Serveur, bref c'est plus du Web.
    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 . Évalué à 1.

      Le push peut se faire en ouvrant un channel specifique sur le poste de travail. "Je m'abonne aux /notifications_nagios_3.1/ arrivant depuis nagios.mondomaine.fr". Je vois pas comment on peut envoyer de la pub par ce biais.
      • [^] # Re: Push

        Posté par (page perso) . Évalué à 8.

        Je vois pas comment on peut envoyer de la pub par ce biais.
        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 . Évalué à -8.

      Eh oui, un navigateur qui fait à la fois serveur et client Web, ca te rappelle pas un certain Opéra Unité.
      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 . Évalué à 10.

        Reste à savoir si ca reste du Minitel 2.0 ou si c'est vraiment décentralisé.

        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 (page perso) . Évalué à 6.

        Le mec qui n'a rigoureusement rien compris au truc quoi...
      • [^] # Re: Push

        Posté par . Évalué à 5.

        Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données. Par rapport au modèle du HTTP qui est du style

        - 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 . Évalué à 7.

          Et donc, on retrouve bien un nouveau protocole d'échange bidirectionnel en mode connecté comme il en existe déjà.

          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 . Évalué à 4.

          Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données.
          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 . Évalué à 1.

            Seules les connexions avec des flux en PUSH ont besoin de rester ouvertes, pour les connexions sans flux en PUSH, c'est identique au keep-alive du HTTP actuel. Et tu peut toujours configurer du côté serveur la durée d'une connexion sans activité.

            Étienne
            • [^] # Re: Push

              Posté par . Évalué à 3.

              Si tel est le cas, pourquoi réinventer un nouveau protocole alors qu'il "suffirait" d'ajouter une extension à l'ancien pour faire du push ?

              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 . Évalué à 4.

                C'est un peu ce que fais SPDY mais en ajoutant d'autres trucs en plus, non ?
          • [^] # Re: Push

            Posté par (page perso) . Évalué à 1.

            Oui mais :

            - 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 (page perso) . Évalué à 5.

    Plutôt que de tordre http pour tout faire rentrer dans le navigateur, n'existe-t-il pas déjà d'autre solutions ?
    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 . Évalué à 2.

      Tu comprends pas l'interet de faire du push ?
      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.
      • [^] # Re: tout dans le navigateur, et surtout sur leurs serveurs

        Posté par . Évalué à -1.

        Si ton client RSS fait 36000 requêtes par jour, le problème n'est pas technique, c'est juste que tu es un gros boulet.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: tout dans le navigateur, et surtout sur leurs serveurs

          Posté par (page perso) . Évalué à 5.

          C'est peut-être pas un seul client qui fait 36000 requêtes par jour mais 36000 personnes qui font 1 requête …

          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 (page perso) . Évalué à 2.

            > C'est peut-être pas un seul client qui fait 36000 requêtes par jour mais 36000 personnes qui font 1 requête …

            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 (page perso) . Évalué à 2.

              Oui mais une requête par jour pour du RSS c'est pas vraiment la réalité (enfin j'imagine), j'ai pas de statistiques sous la main non plus. Disons que dans mon cas j'ai une requête toutes les 30 minutes pour l'ensemble des flux, néanmoins sur tout ces flux y'a guère qu'une dizaine pour lesquels les requêtes sont effectivement utiles à intervalle aussi régulier. On pourrait dire ben j'ai qu'à configurer pour chaque flux, mais bon j'ai pas le temps ni l'envie.

              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 . Évalué à 4.

      n'existe-t-il pas déjà d'autre solutions ?
      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 . Évalué à 5.

      L'intérêt du truc est dénaturé par le titre même de la dépêche, titre hautement trollifère !! :
      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 (page perso) . Évalué à 1.

    HTTP reste un protocole texte sur une socket qui reçois des entêtes (une requêtes) et répond avec des entêtes + un corps.

    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 . Évalué à 3.

      Rien ne dit qu'il ne s'agit pas de lancer le débat autour d'une mise à jour sérieuse de HTTP, la dernière tentative ayant échoué en 1999. Entre temps le web a beaucoup évolué et les besoins aussi. Et surtout, une règle de l'IETF est "We reject kings, presidents and voting. We believe in rough consensus and running code" [1]. Au moins là on a le running code et on peut évaluer. L'étape intelligente suivante c'est d'aller faire un BoF au prochain meeting IETF. C'est con, c'était cette semaine...

      [1] http://www.ietf.org/tao.html
    • [^] # Re: Pas possible de faire évoluer HTTP ?

      Posté par . Évalué à 4.

      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 ?

      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 (page perso) . Évalué à 2.

      > 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 ?

      ç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 (page perso) . Évalué à 5.

        Si l'on doit récuperer 50 elements sur une page, imaginons le scénario :

        # 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.
  • # Touche pas à (mon) grisbi !

    Posté par . Évalué à 6.

    En lisant certains commentaires, j'ai eu l'impression de lire des vieux ronchons qui veulent pas qu'on touche à leur joujou. Si le "web" doit être figé pour 50 ans encore, on a pas fini d'être dans la merde. Surtout avec les nouvelles features qui arrivent.

    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 . Évalué à 10.

      Oui et non, j’ai l’impression que le http devient un protocol poubelle. Après avoir remplacé en grande partie le ftp, les newsgroups (qui ne servent pas qu’à télécharger Windows) et l’irc (où on ne trouve pas que des liens et explication pour télécharger Windows) on voudrait encore ajouter des trucs, pour le rendre encore plus souple.
      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 (page perso) . Évalué à 2.

        Dans ce que tu dis, je vois la même chose que la convergence "tout IP" : téléphonie, télévision, radio, etc. Quand les fibres seront un peu plus grosses, on pourra même y faire passer du café (Américain dans un premier temps, parce que le café Turc, il faut des plus gros tuyaux ;)

        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...
      • [^] # Re: Touche pas à (mon) grisbi !

        Posté par . Évalué à 8.

        Je suis tout à fait d'accord.

        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 (page perso) . Évalué à 7.

          Je travaille avec un boite qui interdit ssh en sortie pour soi disant des questions de sécurité. Bilan, ils me demandent de monter un serveur web avec ajaxterm pour pouvoir avoir un accès à une console sur mes machines de calcul !

          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 . Évalué à -1.

            Avez-vous plus confiance dans le couple Apache+AjaxTerm qu'en OpenSSH ?

            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 (page perso) . Évalué à 2.

              est qu'il permet trop facilement de faire du reverse tunnelling

              Pour ç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 . Évalué à 0.

                Pour ça faut être en interne.
                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 (page perso) . É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 (page perso) . Évalué à 2.

                    Exemple à la con:

                    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 . Évalué à 1.

                    à part une analyse statistique de l'utilisation de la bp je vois pas
                    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 (page perso) . Évalué à 5.

                  > OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet,

                  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 . Évalué à 1.

                    C'est la réponse classique des DSI quand je dis cela !
                    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 (page perso) . Évalué à 8.

                      > 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 ?

                      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 . Évalué à 3.

                        moi ou ca me fait le plus délirer, c'est quand on te demande de dl un truc (eclipse par exemple), parce que tu dois l'installer sur des postes, et que la DSI considère que c'est un virus ... :]
                        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 . Évalué à 2.

                          Et du coup, c'est génial pour l'entreprise, car 1) la sécu, il faut la payer, puis on la contourne, et 2) contourner la sécu, c'est une perte de temps pour celui qui le fait.

                          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 (page perso) . Évalué à 3.

                            3) Ça ne choque plus personne de contourner la sécu jusqu'au jour où se sera un virus qui fout tout en l'air.

                            « 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 (page perso) . Évalué à 1.

                          Dans le même genre : les sites d'universités, qui regorgent d'informations techniques, et qui sont bloqués car les catégories « institutions scolaires » et « matériaux éducatifs » sont filtrées... (on peu quand même y accéder en cliquant sur un bouton, m'enfin c'est quand même débile de ne pas les laisser accessibles par défaut).
                      • [^] # Re: Touche pas à (mon) grisbi !

                        Posté par . Évalué à 0.

                        > 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 ?

                        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 (page perso) . Évalué à 3.

                          > Une seule IP ? Je vais finir par croire que tu bosse dans une boite de 10 personnes !

                          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 . Évalué à -1.

                            tu n'y comprends rien, tellement tu es arcbouté sur tout fermer.
                            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 . Évalué à 2.

            tu met ton ssh sur le port 443 :]
            Moi j'oserais faire ça pour bypasser le fw de la boite ? meuh non...
            • [^] # Re: Touche pas à (mon) grisbi !

              Posté par (page perso) . Évalué à 2.

              Il ne s'agit pas de contourner leur DSI, les décisions sont validées des deux cotés. Je ne veux pas me retrouver avec une multinationale sur le dos ! C'est un contrat de collaboration et nous, nous fonctionnons en réunion, contre rendus de réunion validé par les participants. Comme cela, il n'y a pas de lézard...
      • [^] # Re: Touche pas à (mon) grisbi !

        Posté par . Évalué à 3.

        Je ne comprend pas (vraiment) les raisons pour lesquelles il faudrait utiliser http juste pour des pages web statiques. Je n'y connais pas grand chose mais :
        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 . Évalué à 1.

      Malheureusement, quand on voit la vitesse d'adoption de la v6 du protocole IP, on peut douter du remplacement 'rapide' du protocole http par qqch de plus adapté aux usages de maintenant.
      Et je le déplore car ça reste une réflexion très intéressante.

  • # Question pour les connaisseurs de XMPP

    Posté par (page perso) . Évalué à 3.

    Il y a pas mal de réactions qui parlent de XMPP. J'avais un peu étudié le protocole il y a quelques années et je l'avais trouvé vraiment flexible. Mais je suis plutôt développeur haut niveau. Un connaisseur pourrait-il compléter les remarques sur l'opportunité d'utiliser XMPP pour ce genre de fonctionnalités ? Le fait que le XML soit lourd, c'est une chose, mais je pense qu'il y a beaucoup d'autres arguments (pour et contre) l'utilisation de XMPP. Je sais par exemple que XMPP a des difficultés à traverser les NAT.
    • [^] # Re: Question pour les connaisseurs de XMPP

      Posté par (page perso) . Évalué à 1.

      > Le fait que le XML soit lourd,

      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).
  • # Le vrai probleme:

    Posté par . Évalué à 1.

    Le probleme en rendant http bidirectionnel:

    - 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 . Évalué à 1.

      Toute la logique est basée sur une requête = un résultat. Un script PHP/ASP/... n'est pas fait pour tourner longtemps

      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 . Évalué à 1.

        Les nouveaux programmes doivent être capables de "pusher" des événements a certains moments, donc on parle bien d'applications qui tournent en permanence du coté serveur. Ça n'exclut la possibilité de mélanger les 2 comportements.
    • [^] # Re: Le vrai probleme:

      Posté par . Évalué à 1.

      - bcp plus de socketa à allouer du coté serveur
      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 . Évalué à 1.

    Je n'ai surement pas tout saisi sur ce qui c'est dit, mais une chose m'étonne - du coup j'ai peur de dire une c...rie mais bon je me lance - c'est le fait que personne ne rapporte ce que la W3C pense de cette proposition ? De même T.Berners-Lee a t'il pris position sur cette proposition parce qu'il me semble que cette notion de Push ça change complètement l'esprit du Web originel ?

    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 . É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 . É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 . É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 google
        Personnellement 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 . É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 . Évalué à 1.

            1/ je ne suis pas technicienne du net
            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 . Évalué à 2.

              JE pense que si tu as été moinssé c'est plus parce que tu as reporté des "on m'a dit qu'il parait que google serait" etc...

              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 (page perso) . É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 . Évalué à 1.

          Heu le push c'est pas une popup hein!

          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 (page perso) . Évalué à 3.

            Oui, mais.

            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.
  • # Bof

    Posté par . Évalué à 1.

    Pourquoi s'attaquer au problème uniquement sur la couche HTTP ?

    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 (page perso) . Évalué à 1.

      Parce que modifier la couche applicative demande juste une évolution des navigateurs et des serveurs web. Modifier la couche TCP demandera des modifications dans l'OS, avec potentiellement des implications sérieuses sur la compatibilité hors des questions serveur web.

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.