Journal Les websockets sont pas secioures

Posté par (page perso) .
Tags : aucun
8
9
déc.
2010
Hello les moules !

Je suis pas très au parfum de ce que devait nous apporter les websockets, ce nouveau protocol de push-up qui devait faire fureur avec html5...

Mais il semblerait que la version actuelle soit morte avant d'avoir pu être utilisée: ce ne sera pas disponible dans Firefox 4 et Opera, pour cause de sécurité !

Bien sur il une nouvelle version fera certainement son apparition et sera intégrée aux navigateurs... mais ça repousse sont utilisation.

Chères moules webdevelopeurs, ne trouvez vous pas ça dommage, après le temps de stagnation avant de se décider à faire évoluer les choses ? A quand le web '11 ?

Y perd t-on beaucoup ?

les lien: http://hacks.mozilla.org/2010/12/websockets-disabled-in-fire(...)
http://www.ietf.org/mail-archive/web/hybi/current/msg04744.h(...)
  • # Ma compréhension de la techno

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

    D'après ce que j'ai compris, les websockets sont très intéressants pour le développeur d'application web. En effet, il permettent de notifier le navigateur.

    Par exemple, plutôt que d'envoyer une requête asynchrone en javascript toutes les minutes pour voir si on ne doit pas afficher un nouvel e-mail dans l'application de webmail, la connexion websockets permet, sans autre plugin, au serveur d'envoyer un message qui dit "nouveau mail" au navigateur qui va ainsi pouvoir faire ce qui est nécessaire pour l'afficher.

    On peut ainsi passer du polling à la publication ce qui est beaucoup plus efficace en terme de bande passante et de charge du serveur.
    • [^] # Re: Ma compréhension de la techno

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

      qui dit "nouveau mail"

      Y'a pas déjà un protocole pour les mails ?

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Ma compréhension de la techno

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

        Il y a un protocole qui permet au serveur de te notifier de l'arrivée d'un mail, sans requête de ta part?
        • [^] # Re: Ma compréhension de la techno

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

          Oui, IMAP IDLE.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Ma compréhension de la techno

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

            Merci!
            • [^] # Re: Ma compréhension de la techno

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

              Ce n'est pas utilisable dans un webmail, ce qui est le cœur du sujet ici puisqu'on parle du web, pas d'internet (j'adore être pompeux comme ça).

              Bon sinon, les mails c'est un exemple, actuellement Gmail pool (interroge) le serveur toutes les x secondes pour voir s'il y a un nouveau mail (ça peut se vérifier avec un outil de surveillance et de traçage des requêtes). De même que, mettons twitter, interroge son service régulièrement pour savoir si ton réseau à pas fait de nouvelles publications. Là, ben ton navigateur il attend sagement que le serveur le notifie qu'il y a un nouveau truc à afficher/télécharger/whatever. Le traitement de la notification étant à la discrétion du développeur.
              • [^] # Re: Ma compréhension de la techno

                Posté par . Évalué à 3.

                Au contraire on est en plein dans le sujet : le monsieur il dit qu’on est en train de réinventer des protocoles au-dessus d’http, alors qu’ils existent par ailleurs.

                Maintenant petites questions, ceci n’est pas un troll. Je précise parce qu’on est vendredi.
                — Se mettre en idle garde-t-il une connexion ouverte entre le client et le serveur ?
                — N’y-a-t-il pas de risque de sur-charge à avoir un tel type de fonctionnalité ? Car le serveur, à un moment ou un autre, doit garder une liste des clients à notifier.
                — En idle comment fait le serveur pour savoir si le client est toujours en attente ou s’il est parti, y compris à cause d’un arrêt inopiné (donc sans avoir pu prévenir le serveur) ? Du coup les serveurs ne risquent-ils pas de placer un timeout assez réduit, forçant les clients à régulièrement notifier les serveurs de leur présence… que devient alors l’intérêt de la notification serveur→client ?
                • [^] # Re: Ma compréhension de la techno

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

                  > Se mettre en idle garde-t-il une connexion ouverte entre le client et le serveur ?

                  Oui, la connexion reste ouverte.

                  > N’y-a-t-il pas de risque de sur-charge à avoir un tel type de fonctionnalité ?

                  Ça consomme un petit peu de ressources, mais bien fait, ça reste négligeable.

                  > En idle comment fait le serveur pour savoir si le client est toujours en attente ou s’il est parti, y compris à cause d’un arrêt inopiné (donc sans avoir pu prévenir le serveur) ?

                  Il peut faire confiance à TCP pour s'occuper de ça ou envoyer de temps à autres un ping (genre une fois toutes les 10 minutes).

                  > Du coup les serveurs ne risquent-ils pas de placer un timeout assez réduit, forçant les clients à régulièrement notifier les serveurs de leur présence… que devient alors l’intérêt de la notification serveur→client ?

                  C'est relativement coûteux d'établir une connexion. Il y a d'abord le 3-way handshake de TCP, puis éventuellement l'établissement de la session SSL (dans le cas d'HTTPS ou d'IMAPS par exemple) et surtout, ça demande au serveur de retrouver le contexte associé à ce client (vérifier des crédentiels, aller chercher des informations en base de données ou dans un fichier, etc.).
      • [^] # Re: Ma compréhension de la techno

        Posté par . Évalué à 7.

        1°) c'est un exemple parmi des millions d'autres ;
        2°) les webmails font partie du quotidien de tout le monde, et sont un exemple clair et facile à comprendre, même pour un non-développeur
        • [^] # Re: Ma compréhension de la techno

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

          1) Donne-moi un autre exemple alors, moi j'en vois pas.
          2) ... il y a déjà eu ce débat des milliers de fois (et c'est vrai qu'un logciel de mail demande de pouvoir recoder le noyau linux de tête pour être utilisé), mais le HTTP n'est pas fait pour remplacer le IMAP et il faut arrêter de tenter de remplacer tous les protocoles par HTTP !

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Ma compréhension de la techno

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

            1) Donne-moi un autre exemple alors, moi j'en vois pas.

            Google Doc, ça permet d'éviter de faire des refresh très rapide si personne n'écrit.

            2) ... il y a déjà eu ce débat des milliers de fois (et c'est vrai qu'un logciel de mail demande de pouvoir recoder le noyau linux de tête pour être utilisé), mais le HTTP n'est pas fait pour remplacer le IMAP et il faut arrêter de tenter de remplacer tous les protocoles par HTTP !

            Personne ne te force non plus à utiliser des applications qui nécessite websocket, si tu ne le veut pas, elles ne se chargeront pas toute seule sur ton navigateur.

            « 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: Ma compréhension de la techno

            Posté par . Évalué à 1.

            mais le HTTP n'est pas fait pour remplacer le IMAP et il faut arrêter de tenter de remplacer tous les protocoles par HTTP !

            Pourquoi tu parles d'IMAP ? C'est un protocole bon pour les applications qui tournent sur ta propre machine ça. On parle d'applications qui ne sont pas (entièrement) sur ta machine là, et de protocoles pour communiquer entre toi et ces applications. Après, en interne, elles font la tambouille qu'elles veulent, IMAP inclu.
          • [^] # Re: Ma compréhension de la techno

            Posté par . Évalué à 9.

            faut arrêter de tenter de remplacer tous les protocoles par HTTP !

            Il faudrait aussi arrêter de dire systématiquement "je n'ai pas d'usage de la feature X, elle n'a donc pas le droit d'exister".
          • [^] # Re: Ma compréhension de la techno

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

            > 1) Donne-moi un autre exemple alors, moi j'en vois pas.

            Au hasard, recevoir les derniers messages de la tribune dans la seconde où ils sont postés.

            C'est également très utile pour envoyer des notifications (penser à libnotify/growl mais sur une page web) : « Untel vous a assigné un ticket critique : "Websockets pas secures" » sur un outil de gestion de projets comme trac/redmine/retrospectiva.

            Ça pourrait également servir à mettre à jour les stocks d'un produit sur un site d'ecommerce qui organiserait des ventes flash.
            • [^] # Re: Ma compréhension de la techno

              Posté par . Évalué à 4.

              > > 1) Donne-moi un autre exemple alors, moi j'en vois pas.

              > Au hasard, recevoir les derniers messages de la tribune dans la seconde où ils sont postés.

              ca va encore etre le bordel à minuit
          • [^] # Re: Ma compréhension de la techno

            Posté par . Évalué à 5.

            WebSockets ne passe par HTTP que pour le handshake, donc non, WebSocket, c’est pas « IMAP remplacé par HTTP », c’est un protocole à part entière.
    • [^] # Re: Ma compréhension de la techno

      Posté par . Évalué à 2.

      Par exemple, plutôt que d'envoyer une requête asynchrone en javascript toutes les minutes pour voir si on ne doit pas afficher un nouvel e-mail

      Je ne voudrais pas trop m'avancer avec ma connaissance rudimentaire du HTML, mais le fait que la requête soit asynchrone ne permet-il pas justement au serveur de la compléter quand il veut ? (du genre astucieusement, quand on a reçu un nouvel email).

      C'est pas le principe de base du XmlHttpRequest ?
      • [^] # Re: Ma compréhension de la techno

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

        Ce que tu décris, c'est la méthode "Comet" :
        http://en.wikipedia.org/wiki/Comet_%28programming%29

        C'est effectivement très utilisé pour les clients qui ne supportent pas un vrai push.

        Mais c'est un gros hack. Ca fait exploser le nombre de connexions HTTP simultanés à maintenir entre les clients qui attendent et le serveur.
        • [^] # Re: Ma compréhension de la techno

          Posté par . Évalué à 6.

          > Ca fait exploser le nombre de connexions HTTP simultanés à maintenir entre les clients qui attendent et le serveur.
          Heu, WebSockets a exactement le même problème : un client WebSockets, c’est une connexion TCP à maintenir, et probablement sur le même processus que le serveur HTTP (si le handshake en WebSockets c’est du HTTP, c’est pas pour rien, mais pour pouvoir faire des serveurs HTTP+WebSockets ou ajouter WebSockets à des serveurs HTTP existants. Mon petit doigt me dit que ça doit être le cas pour GWS, mais je peux me tromper.)
          • [^] # Re: Ma compréhension de la techno

            Posté par . Évalué à 3.

            ca fait bcp de personnes qui font la conversation avec le petit doigt. Diantre, ou ais-je mis les pieds !
          • [^] # Re: Ma compréhension de la techno

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

            Heu, WebSockets a exactement le même problème : un client WebSockets, c’est une connexion TCP à maintenir,

            Sauf que plein de requête http, c'est plein de connexion tcp à maintenir jusqu'au timeout.

            « 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: Ma compréhension de la techno

              Posté par . Évalué à 3.

              Je ne vois pas en quoi la distinction WebSockets/Comet est pertinente de ce point de vue. Si tu veux faire du push, tu dois forcément maintenir une (et pour les bonnes implémentations, une seule) connexion TCP entre le serveur et le client. Plein de client WebSockets, c’est aussi plein de connections TCP à maintenir, ou j’ai loupé un épisode.
              • [^] # Re: Ma compréhension de la techno

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

                Il me semble que les connexions HTTP ont un timeout de 30 secondes, ce qui fait que si tu fait un refresh toutes les 10 secondes, tu te retrouves avec 3 connexions par client.

                Mais sans tenir compte de ça, refaire une nouvelle connexion TCP pour rien toutes les 10 secondes est plus coûteux question CPU et BP que maintenir une connexion vivante.

                « 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: Ma compréhension de la techno

                  Posté par . Évalué à 2.

                  "Il me semble que les connexions HTTP ont un timeout de 30 secondes, ce qui fait que si tu fait un refresh toutes les 10 secondes, tu te retrouves avec 3 connexions par client."
                  Mais si on fait un refresh, le navigateur ne va-t-il pas tout d'abord refermer la(les) connexion(s) ouverte(s) ? Ou (si cela est possible), en réutiliser une ?
                  • [^] # Re: Ma compréhension de la techno

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

                    Il me semble que tous les navigateurs ne le font pas.

                    « 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

  • # plus d'infos

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

    WebSockets, voyez ça comme de l'IP over HTTP (persistent, bi-directionnel), typiquement, comment faire un chat sans avoir à utiliser un vieux hack pourri avec XHR.

    WebSockets, c'est 2 choses:
    * une API
    * un protocole

    L'API, rien de plus simple. Le protocole, c'est compliqué.

    Protocol qui au début (v0.75) a été spécifié par le W3C. Là, on a trouvé une faille de sécu inhérent au protocole. La version suivant (v0.76) a fixé ça. Chrome et Safari ont shippé.

    L'IETF récupère le bébé (c'est un protocole, donc bon), et était sensé avoir une nouvelle version en très peu de temps. Comme d'hab, ça n'a pas marché (toujours en court de spécification).

    Découvert d'une (très sérieuse) faille de sécu dans le protocole v0.76.

    Fx4 et Opera décident de pas shippé (ils ne l'avaient pas encore fait).
    Chrome & Safari, on attend leur réaction.

    On attend la version de l'IEFT avec impatience :)
    • [^] # Re: plus d'infos

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

      comment faire un chat sans avoir à utiliser un vieux hack pourri avec XHR.

      En général, j'utilise 2 chat (1 de chaque sexe) pour cette opération :)

      « 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: plus d'infos

      Posté par . Évalué à 2.

      IP over HTTP.... cela va tunneler à mort...

      "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.