Journal Bittorrent = 35 % du traffic sur le web

Posté par  .
Étiquettes : aucune
0
4
nov.
2004
Bittorrent = 35 % du trafic sur le web

C'est ce que l'on peut lire dans une nouvelle de toolinux [1] qui vient de Reuters qui a pris ça depuis ... bref ... pour faire court c'est une étude de CacheLogic [2] une boite qui fournit des systèmes pour mesurer qualitativement et quantitativement les flux chez les FAI.

Bon c'est énorme le trafic P2P selon eux, c'est gossomodo plus de 50% de la bande-passante consommée.

Il y a pas si longtemps une autre nouvelle est passé sur le site de la FING sur le coup de gueule de Vint Cerf sur le multicast [3], il disait en gros que les FAI tarder a mettre en oeuvre le multicast et que sans multicast les promesses d'un internet "multimedia" à haut débit "populaire" ça ne marcherait pas.

Et ça c'est une réflexion que je me faisais déja depuis un moment, avec le haut-débit et le multicast, tout les internautes pourraient diffuser un flux multimédia à la vitesse maxi de l'upload vers le reste du monde quelque soit le nombre de clients connectés à ce flux. Autant dire qu'au niveau des usages, ce serait une véritable révolution, le P2P puissance 10. Enfin si je me gourre, dites le moi.

Y compris dans la diffusion d'une distribution linux. on peut imaginer mettre en ligne un fichier sous forme de flux et faire de la diffusion multicast en boucle. Le gars qui télécharge prendrait le flux en cours et le suivrait jusqu'a ce qu'il boucle et reconstituerait ensuite le fichier original.

Et la, plus besoin de serveur de fichier avec une bande passante de furieux ou meme de diffusion en P2P ....

Et ç'est la que je me dit que le P2P existe parce que le multicast n'est pas possible, non ?

Mais alors qu'est-ce qu'ils foutent nos FAI ? Pourquoi pas de multicast alors que technologiquement c'est au point depuis les années 80 ?

Comment qu'ils disaient déjà les anciens ? "Save the bandwidth" non ?

[1] La nouvelle de Toolinux http://www.toolinux.com/news/logiciels/monstrueux_succes_pour_bitto(...)
[2] La présentation de l'étude sur le site de CacheLogic: http://www.cachelogic.com/research/slide1.php(...)
[3] Le coup de gueule de Vint Cerf http://www.internetactu.net/?p=5039(...)
  • # ama

    Posté par  (site web personnel) . Évalué à 7.

    Mais alors qu'est-ce qu'ils foutent nos FAI ?
    Déjà qu'ils se font taper sur les doigts quand ils proposent du 512 en upload par l'asso des amis de Pascal N, je crois qu'ils n'ont tout simplement pas envie de se faire péter la gueule.
  • # web != internet

    Posté par  . Évalué à 10.

    Bittorrent utilise le web uniquement pour discuter avec le tracker (le "serveur" qui gère la liste des peers). Et encore, c'est sur un port différent de 80. Il serait bon que les gens prennent conscience de la différence entre Web et Internet (en particulier, Internet n'a pas été inventé au CERN :-)

    Pour ceux que ca intéresse:
    description du protocole de Bittorrent (pas super facile à lire) :
    http://bitconjurer.org/BitTorrent/protocol.html(...)
    et slides (powerpoint, mais nettement plus lisible) :
    http://mnl.cs.sunysb.edu/home/karthik/BitTorrent/BToverview.ppt(...)

    Je pense que le fonctionnement de BT pourrait être largement amélioré en implémentant un mécanisme de sélection des peers qui tiendrait compte de la proximité (et ça réduirait du meme coup le trafic sur internet). Connaissez-vous un réseau P2P qui fait ca ?
    • [^] # Re: web != internet

      Posté par  . Évalué à 3.

      J'ai repris betement le titre de la news sans le retoucher, méa culpa. C'est vrai que la confusion entre internet et le web est courante. Mais maintenant que le P2P a détroné le web en usage (voir sur le slide de CacheLogic les stats pour l'asie, si elle sont juste, c'est énorme : http://www.cachelogic.com/research/slide12.php(...) ) les gens vont confondre internet et P2P et penserons que c'est Marcel Napster qui a inventé l'internet ;-)

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: web != internet

      Posté par  . Évalué à 6.

      Y compris dans la diffusion d'une distribution linux. on peut imaginer mettre en ligne un fichier sous forme de flux et faire de la diffusion multicast en boucle.

      Ça fait un bon mois qu'une telle idée me turlupine :p

      Vu que tu es obligé d'utiliser de l'udp (l'acquitement mode tcp avec du multicast, c'est pas possible), faut faire dans la diffusion multicast fiable, en utilisant cette bibliothèque en gpl par exemple :
      http://www.inrialpes.fr/planete/people/roca/mcl/mcl_in_short.htm(...)


      Je pense que le fonctionnement de BT pourrait être largement amélioré en implémentant un mécanisme de sélection des peers qui tiendrait compte de la proximité (et ça réduirait du meme coup le trafic sur internet).

      Tu mesurerais la proximité au nombre de hops ?
      Ce n'est pas forcément la meilleure manière de choisir un chemin, cf les LSP dans MPLS, qui tiennent compte de l'engorgement des liaisons. Mais cela n'est pas visible du côté utilisateur :/

      Au portugal (ou en espagne), il me semble que les forfait offrent une certaine quantité de traffic national, un autre internationale. Les distinctions se font via les ip.
      • [^] # Re: web != internet

        Posté par  . Évalué à 3.

        L'adresse est en fait http://www.inrialpes.fr/planete/people/roca/mcl/mcl_in_short.html(...)

        J'avais visité cette équipe de l'inrialpes en juin. Ce qu'ils vont est vraiment intéressant. Le serveur échantillonne les données à transmettre en petits paquets, et calcule à partir des ces paquets de paquets de "checksum". Puis le serveur envoie en boucle ces paquets, dans un ordre aléatoire. Un client qui se connecte commence à recevoir n'importe quand, et grace aux paquets de "checksum", il pourra s'arrêter de recevoir des paquets bien avant d'avoir fait un tour complet, même s'il a raté quelques paquets en cours de route.

        A noter que cette solution libre et sans brevets est concurrente d'une solution américaine brevetée, et qu'une des motivations pour réaliser cette implém était de faire qqchose de comparable, mais sans brevets.

        Tu mesurerais la proximité au nombre de hops ?
        Ce n'est pas forcément la meilleure manière de choisir un chemin, cf les LSP dans MPLS, qui tiennent compte de l'engorgement des liaisons. Mais cela n'est pas visible du côté utilisateur :/


        Je ne sais pas, je n'y ai pas encore vraiment réfléchi. C'est quoi les LSP ? C'est quoi MPLS ? Tu peux m'éclairer ? Je n'ai pas trouvé grand chose de pertinent sur Google.
    • [^] # Re: web != internet

      Posté par  . Évalué à 6.

      >Je pense que le fonctionnement de BT pourrait être largement amélioré en implémentant un mécanisme de sélection des peers qui tiendrait compte de la proximité (et ça réduirait du meme coup le trafic sur internet). Connaissez-vous un réseau P2P qui fait ca ?


      J'y avait pensé, j'avais regardé les archives de la ML de bittorrent. Ca a été "refusé" pour plusieurs raison, notemment celle que le FAI était une couche en dessous de bittorrent et que ça ne devait pas rentrer en compte.
      • [^] # Re: web != internet

        Posté par  . Évalué à 1.

        En fait la boite qui a fait l'étude sur le trafic P2P propose un systéme de cache (sic), un genre de serveur proxy P2P : http://www.cachelogic.com/p2p/p2pcaching.php#(...)


        Ils n'en disent pas beaucoup sur leur technologie, mais il me semble que c'est basé sur des serveurs i386

        J'ai pas trouvé d'equivalent libre.... Par contre la question reste de savoir si pour les FAI faire du P2P caching est légal vu que cela peut etre considéré suivant ce qui est dans le cache comme de l'hebergement de fichier "piraté" et donc si j'ai bien compris l'aspect légal comme du recel de contrefaçon.

        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

        • [^] # Re: web != internet

          Posté par  . Évalué à 1.

          Le même problème s'était déjà posé ya longtemps avec les serveurs de cache web. Apparemment, la loi les a disculpés.
  • # multicast

    Posté par  . Évalué à 7.

    En l'état actuel des choses, le multicast n'est pas routé sur l'ensemble d'internet. Il ne l'est que sur une petite partie appelée Mbone, et dont la majorité des FAI ne sont pas "abonnés".


    En revanche, le multicast peut être déployé au sein d'un même opérateur.
    Ainsi Renater permet ainsi la transmision de paquets multicasts : http://www.renater.fr/Reseau/Multicast/(...) .
    Au niveau de son réseau interne, Free utilise le multicast pour distribuer les sources vidéos aux DSLAMs.

    Sinon, IPv6 permet de transporter "nativement" le multicast. (Au passage en supprimant le broadcast).
    • [^] # Re: multicast

      Posté par  . Évalué à 3.

      Sinon, IPv6 permet de transporter "nativement" le multicast. (Au passage en supprimant le broadcast).

      Les fournisseurs de tunnels IPv6 sur IPv4 fournissent-ils une connectivité multicast ?
      • [^] # Re: multicast

        Posté par  . Évalué à 1.

        Certains oui, certains non,

        Par exemple chez sixxs on peut voir que certains POP (le bout du tunnel auquel tu te connectes) le propose (enfin, en realité je crois pas qu'il y en ai qui le propose encore, mais c'est prevu :)
  • # Adresses limitées

    Posté par  . Évalué à 1.

    Je pense qu'il y aurait vite un problème de limite dans la plage d'adresse allouée au multicast : 224.0.0.0, je sais même pas si c'est en 255.0.0.0.

    De plus il faudrait gérer l'attribution de celles-ci, sinon, que se passe-t-il si plusieurs personnes émettent sur la même adresse ?

    Peut-être que l'IPv6 résoudrait le problème, mais là aussi, qu'est-ce qu'ils attendent pour basculer Internet en IPv6 !!!
    • [^] # Re: Adresses limitées

      Posté par  . Évalué à 5.

      Je pense qu'il y aurait vite un problème de limite dans la plage d'adresse allouée au multicast : 224.0.0.0, je sais même pas si c'est en 255.0.0.0

      Tu peux changer le ttl, qui définit la portée du flux multicast : un ttl de 1 correspond au lan, etc.. Voilà donc une manière d'éviter la catastrophe (et un FAI pourrait modifier ces ttl à la volée pour éviter qu'un abonné diffuse trop loin)

      voir http://www.infres.enst.fr/~dax/polys/multicast/(...)

      De plus il faudrait gérer l'attribution de celles-ci, sinon, que se passe-t-il si plusieurs personnes émettent sur la même adresse ?

      Bah c'est le bordel ;-) (déjà testé avec vlc : le flux est interompu, bascule de l'un vers l'autre avec des coupures)
      • [^] # Re: Adresses limitées

        Posté par  . Évalué à 1.

        Bah c'est le bordel ;-) (déjà testé avec vlc : le flux est interompu, bascule de l'un vers l'autre avec des coupures)

        En fait, on pourrait imaginer que les routeur d'accés filtrent l'émission sur une source qui emet déja. Et en LAN, le switch ? D'ailleur a ce propos, sur un LAN le multicast est diffusé comme un broadcast au niveau de la trame Ethernet, non ?
        Il existe des adresses MAC multicast, mais je ne sais pas si elle sont utilisé ou peuvent l'être pour la transmission des paquets multicast.

        Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

      • [^] # Re: Adresses limitées

        Posté par  . Évalué à 0.

        >>De plus il faudrait gérer l'attribution de celles-ci, sinon, que se passe-t-il si plusieurs personnes émettent sur la même adresse ?

        >Bah c'est le bordel ;-) (déjà testé avec vlc : le flux est interompu, bascule de l'un vers l'autre avec des coupures)


        pas forcement. j'ai testé sur un lan avec un serveur maison (que j'ai fait pour mon stage) et l'appli JMStudio (livrée avec le Java Media Framework) comme client. et bah kan tu mets deux serveurs qui emettent sur la meme adresse, coté client tu as deux fenetres avec les 2 flux. d'ailleurs ca m'a surpris, j'etais persuadé que ca allait fare de la merde...

        ca utilise le protocole RTP (sur UDP evidemment, sinon pas de multicast).
  • # Impact du mail négligeable ?

    Posté par  . Évalué à 1.

    Avec tous les virus, je me demandais quel était l'impact du mail sur le trafic sur Internet. Finalement, il a l'air très faible, puisqu'il n'apparait même pas sur http://www.cachelogic.com/research/slide12.php.(...) Ca doit plus être une calamité au niveau application (serveurs de mails saturés par le filtrage, le greylisting, etc ...) qu'au niveau réseau.
    • [^] # Re: Impact du mail négligeable ?

      Posté par  . Évalué à 1.

      Il faut se mefier aussi de leur étude, ils ont l'air serieux mais en même temps ils essayent de fourger leur serveurs de cache P2P. Disons qu'il ne sont pas desintéressé dans l'histoire....

      Cela dit, si je regarde ma machine, j'ai jamais vu le mail me saturé l'accés, alors que BT .... j'ai déja saturer mon 1024 facile et pas pendant 5 minutes, plutôt pendant des heures.... avec des trucs légaux, uniquement, bien sur. J'imagine qu'a coté de moi un stakhanoviste du download en mode patate, ça doit faire vraiment mal.

      Tiens en redigant la réponse je cherchais des stats et je suis tombé sur la page de stats MRTG de Nerim
      http://stats.nerim.net/nav/serveurs/(...)
      Et ben on vois assez facilement que le trafic mail c'est pas trés méchant, Usenet bouffe largement plus.
      Et si tu prend les stats a coté de la BP totale consommée :
      http://stats.nerim.net/nav/global/(...)
      Y a pas photo......(cela dit, chez nerim doit y avoir pas mal de gars qui ont leur MX et qui rentrent pas les graph)

      Quand je vois de belle stats comme ça, j'ai "l'envie d'aller chez Nerim même si c'est plus cher" qui me reprend.....dur....

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

Suivre le flux des commentaires

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