5.2.1 Avantages et inconvénients

L'utilité de cette méthode réside dans la possibilité de réaliser des opérations seek efficientes, que nous ne pouvons pas réaliser avec le paradigme "transfert complet" ("full file transfer"). Quand le client réalise un seek, il finira le transfert du bloc en cours de transfert (s'il y a un) et le prochain bloc demandé commencera à la position du seek (Figure 53).

Figure 53 La stratégie du seek avec la méthode proposée

La quantité de données inutiles transférées sur le réseau sera au maximum la taille d'un bloc pour chaque seek. La quantité maximale des données inutiles transférée pour un seek dans les deux stratégies est présenté dans la Figure 54.

Figure 54 La quantité maximale des données inutiles transférées pour un seek dans les deux stratégies: "transfert par blocs" et "transfert complet"

Un autre avantage de cette méthode : le client peut contrôler, jusqu'à un certain degré, le débit de transfert pour un objet multimédia. L'uniformité de ce transfert dépend, parmi d’autres choses, de la taille des blocs du fichier transféré. Parce que le client demande les blocs nécessaires quand il a besoin, le serveur va répondre à ces requêtes le plus vite possible, mais les requêtes vont arriver suivant le débit de l'objet multimédia.

Dans la Figure 55 nous présentons une comparaison entre le débit réseau de ces deux stratégies HTTP, en utilisant un objet MPEG1 encodé à 1.5 Mbps. Nous observons que l'utilisation de notre stratégie permet de diffuser l'objet à un débit qui suit la taux réel d'encodage de l'objet. Par contre, l'autre stratégie de transfert HTTP (transfert complet) génère une utilisation qui n'a rien à voir avec le débit réel de l'objet.

Figure 55 Une comparaison entre les deux stratégies HTTP côté client (en utilisant un fichier MPEG1 a 1.5Mbps)

Un effet secondaire réside dans la croissance du nombre de requêtes traitées par le serveur Web. Dans la stratégie conventionnelle, le serveur ne devait traiter qu'un seul en-tête HTTP pour chaque objet. Au contraire, avec la stratégie "transfert par blocs" le nombre d'en-têtes est beaucoup plus élevé. La formule suivante permet de faire une approximation de ce nombre de requêtes pour le transfert d'un fichier :

( 13 )

Mais cette croissance n'est pas très contraignante, les serveurs Web actuels étant capables de traiter des milliers de requêtes simultanément (Chapitre 2). A la fin de ce chapitre nous montrons les performances réelles d'un serveur Web qui serve des flux avec la stratégie "transfert par blocs", et nous verrons que l'augmentation du nombre de requêtes ne pénalise pas les performances du système.