Discussion :

[Andnotor]

Bonjour à tous !

Je vous propose aujourd'hui un tutoriel sur l'accélération du téléchargement de fichiers.

Vous disposez d'un accès Internet haut débit mais trouvez que le téléchargement est long et que la connexion n'est pas utilisée à son maximum ?
Vous pensez à un problème de configuration du router ? A un ordinateur trop ancien ? Pas du tout ! La raison est que l'hébergeur du site limite la bande passante.

Ce tutoriel va vous expliquer comment passer outre cette limitation à l'aide de plusieurs connexions et d'un fichier mappé.

N'hésitez pas à faire part de vos réactions et commentaires

[ShaiLeTroll]

Pas mal du tout !
Pour les curieux, un lien vers HTTP : le protocole du Web passé en revue - Transactions partielles expliquant le Range qui me semble un pré-requis nécessaire pour comprendre la partie "HTTP Server" exploité par ton tutoriel


Au lieu d'un format sur Range (qui est commenté dans le source comme deprecated), autant passer directement par Ranges

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
      //Télécharge un bloc
      Http.Request.Range := Format('%d-%d',[View.Offset, View.Offset +View.Size -1]);

Deviendrait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
    with Http.Request.Ranges.Add() do
    begin
      StartPos := View.Offset;
      EndPos := View.Offset +View.Size -1;
    end;

Cela renvoit-il une exception en cas de refus du Get du HTTP Range-Request - Error 416 ?
Ne faudrait-il pas protéger les threads de cela ?

[Andnotor]

Je vais ajouter ce lien en référence

Au lieu d'un format sur Range (qui est commenté dans le source comme deprecated), autant passer directement par Ranges

J'admets ne pas avoir été voir l'implémentation de Range. Un deprecated en commentaire n'attire pas vraiment l'attention
Au départ, je voulais même partir sur WinINet (ou WinHTTP) mais je me suis dit que l'intérêt de ce tuto n'était pas tellement la connexion elle-même (à part Range(s)). J'ai fait au plus simple

Cela renvoit-il une exception en cas de refus du Get du HTTP Range-Request - Error 416 ?
Ne faudrait-il pas protéger les threads de cela ?

Le test est fait en amont à l'appel de HEAD AcceptRanges := Response.AcceptRanges = 'bytes';. Si le téléchargement par fragment n'est pas supporté, c'est la méthode SingleDownload (GET sur TFileStream directement) qui est invoquée.

[ShaiLeTroll]

Le test est fait en amont à l'appel ...

OK, je ne suis pas allé aussi loin dans ton tutoriel, honte à moi de ne pas avoir tout lu

[Montor]

Intéressant

Ceci ne devrais pas fonctionner sous D7 version Indy obsolète
a noter que certains site empêchent d'ouvrir plusieurs entêtes de téléchargements en même temps

[BuzzLeclaire]

Dommage que ma connexion et surtout mon poste, n'a pas pu apporter d'eau à ton moulin.

En tous cas c'est trés pratique tout de même.

gg.

[Rayek]

Intéressant

Ceci ne devrais pas fonctionner sous D7 version Indy obsolète
a noter que certains site empêchent d'ouvrir plusieurs entêtes de téléchargements en même temps

Tu peux mettre à jour tes composants Indy avec les nouvelles versions

[Freem]

La raison est que l'hébergeur du site limite la bande passante.

En effet. Maintenant, si l'hébergeur dispose d'une faible bande passante et la bride donc pour pouvoir permettre à plus d'une personne de profiter du service, n'est-ce pas un manque de savoir vivre que de faire de telles requêtes fantôme?

Je ne dis pas ça dans le vent, mais en souvenir d'une discussion que j'avais eue à ce sujet avec la personne qui héberge progboards.com (le 1er forum de prog généraliste ou j'aie été, souvenirs, souvenirs) qui m'avais expliqué pourquoi les outils de téléchargement qui ouvrent plusieurs sockets font chier.

D'ailleurs, il m'avais aussi expliqué que c'est pour ça que certains sites bloquent les fragments ou, tout simplement, empêchent les utilisateurs de faire plusieurs téléchargements à la fois.

[Andnotor]

Et de quels hébergeurs parles-tu ? Des mêmes gentlemen qui te vendent une bande passante et des connexions illimitées 24/7 ?

...qui m'avais expliqué pourquoi les outils de téléchargement qui ouvrent plusieurs sockets font chier.

Et bien explique-nous ! A part multiplier les clients et les bénefs... je vois pas

[RaphAstronome]

D'ailleurs, il m'avais aussi expliqué que c'est pour ça que certains sites bloquent les fragments ou, tout simplement, empêchent les utilisateurs de faire plusieurs téléchargements à la fois.

Effectivement ce genre de comportement sur-consomme les ressources serveur et ralenti voir à l'extrême rend inaccessible le serveur pour les autres clients.

[Andnotor]

Effectivement ce genre de comportement sur-consomme les ressources serveur et ralenti voir à l'extrême rend inaccessible le serveur pour les autres clients.

Et même là, je ne vois pas trop le problème !
Surconsommation ? Je demande à télécharger un fichier d'une certaine taille, que ça prenne 1 minute ou une heure, j'aurai consommé la même bande passante.
Les ressources du serveur ? Sans être un expert, je pense qu'elles sont plus mises à rude épreuve en exécutant le même volume de données en scripts php que par du téléchargement

Le principe est que chaque tâche se connecte et se déconnecte (à moins d'un keep-alive accepté, mais rare) et télécharge moins d'un méga (Ce n'est pas la taille du fichier divisé par N threads). Si le serveur est "chargé" et retarde la Nième demande, ben voilà... on attend ! Mais s'il n'a rien à faire, Pourquoi se tourner les pouces

Je regrette cependant que vous notiez ce tutoriel d'un étoile uniquement pour l'idée qu'il véhicule et non pour son contenu. Mais... l'avez-vous même lu ?

[ouiouioui]

Moi je trouve sa excellent, et je te remercie pour ta participation.

[RaphAstronome]

Surconsommation ? Je demande à télécharger un fichier d'une certaine taille, que ça prenne 1 minute ou une heure, j'aurai consommé la même bande passante.

Pour le transfert de données je suis entièrement d'accord avec toi, pour le CPU aussi car les téléchargements prennent une puissance infime. Mais il n'y a pas que le CPU les transferts qui comptent.


Un téléchargement prend moins de RAM mais plus longtemps, le cout en RAM est la quantité de RAM utilisé * le temps de son utilisation :

Un script PHP qui prend 1Mo de RAM et qui dire 0.5s (c'est déjà pas mal pour une page normale). Il prendra son Mo et la libérera quasi tout de suite. 1*0.5 = 0.5 de cout en RAM

En supposant un téléchargement durant 15s avec un buffer de 128ko cela fait une conso de 0.128*15 = 1.92 de cout en RAM. Et 128k de buffer c'est peu, généralement c'est bien plus pour éviter aux disques de faire trop de déplacements de la tête de lecture.


Les scripts PHP tiennent en général dans le cache disque (et heureusement vu les includes ) pour les téléchargements la RAM est trop petite et chère pour proposer tous les fichiers, c'est généralement des I/O sur le disque donc très ralentisseur de serveur lorsqu'il y a des dizaines/centaines de connexions.


Ce n'est pas ton script qui est dangereux mais plutôt le fait que fait qu'il pourrait être utilisé n'importe comment typiquement en mettant 100 threads en parallèle et sans temps d'attente entre deux tentatives (j'ai déjà vu le cas avec d'autres accélérateurs de téléchargements). Tu parles de 15 threads : c'est déjà beaucoup, si tu as 10 téléchargeurs en même temps le serveur à tout de même 150 connexions, il en faut des slots Apache (ou équivalant sur un autre serveur).


D'ailleurs tu a déjà pu constater que les hébergeurs n'aiment pas et ce n'est peut être pas sans raison, ça leur coûte à force.

À noter encore qu'un test chez free.fr c'est révélé catastrophique ! L'impossibilité d'avoir plus de trois tâches concurrentes et un temps de latence exécrable rendent le téléchargement monothread plus rapide !

Clairement là leur répartiteur de charge te connecte sur un serveur poubelle qui prends les requêtes qu'ils n'aiment pas et qui sature à fond.

Remarque : ce n'est pas moi qui t'ai mis -1, moi j'ai juste mis +1 à Freem mais je n'ai moinsé personne sur ce sujet.

[Paul TOTH]

je suis d'accord avec RaphAstronome, le serveur est configuré pour accepter "n" clients. Pour les téléchargements, DVP utilise généralement le site FTP qui est configuré pour cela.

en découpant artificiellement ta requête en "x" sessions parallèles tu trompes le serveur sur le nombre de clients réels. Si tous les clients font ça la configuration du serveur devient impossible, tu penses gérer 1000 utilisateurs simultanés alors qu'en fait ce sont 10 utilisateurs multithreadés en 10 sessions et les autres sont refusés.

de plus avec des connexions ADSL2+ on arrive vite à des capacités de téléchargement supérieures à ce que le serveur propose. Alors oui le téléchargement est plus lent que ce qui est techniquement possible, mais le serveur ne peut pas octroyer tout ce que lui réclame chaque client, il doit bien partager ses ressources entre les différents clients. Et ce que le serveur a prévu "par client" c'est ce qu'il propose sur une seule connexion.

L'idéal en fait serait une généralisation du P2P

[Andnotor]

Un script PHP qui prend 1Mo de RAM et qui dire 0.5s (c'est déjà pas mal pour une page normale). Il prendra son Mo et la libérera quasi tout de suite.

Pas de différence, ça prendra le temps que le client ait pu rapatrier la donnée, peu importe d'où elle provient et en suivant ton raisonnement, limiter la bande passante est juste conserver le serveur occupé plus longtemps que ce qu'il devrait.

Les scripts PHP tiennent en général dans le cache disque

Les scripts oui ! Mais les données ? Tu penses vraiment que les BDs sont entièrement chargées en cache ?

Ce n'est pas ton script qui est dangereux mais plutôt le fait que fait qu'il pourrait être utilisé n'importe comment

Ne blâmons pas l'inventeur des allumettes quand les pyromanes ne savent pas s'en servir

de plus avec des connexions ADSL2+ on arrive vite à des capacités de téléchargement supérieures à ce que le serveur propose.

Donc en gros, les FAI qui proposent du downstream supérieures à 15M se fichent de leurs clients puisqu'on ne pourra de toute façon pas les utiliser
On achète une Ferrari, mais seule la première vitesse est utilisable...

[GoustiFruit]

Arrêtez de vous prendre le chou avec ça, tous les navigateurs fonctionnent de la même façon, du moins il ne coupent pas les téléchargements en x morceaux mais ils téléchargent les ressources de façon parallèle, avec un certain nombre de connexions pour les fichiers html, css, js, images, etc. Et personne ne leur reproche de vouloir télécharger plus vite pour avoir une navigation plus fluide.

[Paul TOTH]

Arrêtez de vous prendre le chou avec ça, tous les navigateurs fonctionnent de la même façon, du moins il ne coupent pas les téléchargements en x morceaux mais ils téléchargent les ressources de façon parallèle, avec un certain nombre de connexions pour les fichiers html, css, js, images, etc. Et personne ne leur reproche de vouloir télécharger plus vite pour avoir une navigation plus fluide.

ça n'a rien à voir, c'est le fonctionnement même de HTTP, tu télécharges un document HTML qui possède des liens vers d'autres ressources qui sont téléchargées (ou pas selon le cache) à leur tour.

avec FastDownload tu ajoutes une requête HEAD sur chaque ressource et tu multiplies les connexions en fonction de la taille de celle-ci...comme dit plus haut, un bon moyen de rendre dingue le serveur.

[Paul TOTH]

Donc en gros, les FAI qui proposent du downstream supérieures à 15M se fichent de leurs clients puisqu'on ne pourra de toute façon pas les utiliser
On achète une Ferrari, mais seule la première vitesse est utilisable...

ce que te propose ton FAI n'a rien à voir avec les hébergeurs. d'autre part tu peux atteindre les 15M (snif, si seulement je les avais) en téléchargeant depuis différents serveurs, une video sur Youtube, une distribution Linux, tes mails, la page dvp, etc...mais il ne faut pas demander aux serveurs de fournir 15M à chaque client !

[Andnotor]

ça n'a rien à voir, c'est le fonctionnement même de HTTP, tu télécharges un document HTML qui possède des liens vers d'autres ressources qui sont téléchargées (ou pas selon le cache) à leur tour.

La page html oui, ensuite plusieurs connexions sont ouvertes pour télécharger son contenu (le cache local c'est une autres histoire). IE8 utilise par défaut jusqu'à 6 connexions.

un bon moyen de rendre dingue le serveur

Mais est-ce le même serveur (Load-balancing) ?

...mais il ne faut pas demander aux serveurs de fournir 15M à chaque client !

Mais pourquoi pas Pourquoi partez-vous du principe que le serveur est toujours utilisé à 100% ?
C'est comme si j'avais un CPU six coeurs mais que le multitâche était interdit au cas où d'autres "clients" en avaient besoin !

Que la bande passante diminue en fonction du nombre d'accès concurrents, je peux le concevoir et l'admettre. Qu'elle soit limitée au cas où est plus difficile à avaler !

Maintenant, mon but n'était pas d'ouvrir un débat sur le mode d'accès Internet, sur la politesse envers les autres utilisateurs, sur les cheveux blancs que vont immanquablement se faire les webmasters et encore moins m'attirer leur foudre ! L'idée n'était pas non plus de saturer la connexion d'une PME ou de mettre leur serveur (local) à plat parce qu'un gugusse a décider de télécharger une grosse mise à jour plein pot pendant les heures de bureau !
Mais oui, lorsque j'ai commencé mes mesures, j'avais envie de voir jusqu'où on pouvait aller...

[GoustiFruit]

La page html oui, ensuite plusieurs connexions sont ouvertes pour télécharger son contenu (le cache local c'est une autres histoire). IE8 utilise par défaut jusqu'à 6 connexions.

Et Opera en utilise 16 par défaut et par serveur...