Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Nous avons essayé de comprendre pourquoi la ressource n’était pas chargée les premières fois puisque le réseau semble le permettre. Pour cela, nous avons effectué une étude à bas niveau, sur le protocole TCP qui est utilisé dans la plupart des cas par le mobile.

Concept

Nous avons développé un système client/serveur permettant de comparer les performances (c’est-à-dire : le débit, la latence et le taux de perte) de TCP et UDP.

Comparaison

Mesurer l’efficacité de TCP sur le canal de transmission “réseau cellulaire 2G dans le métro” revient à comparer ses performances avec celles maximales offertes par le canal ; c’est pourquoi nous avons utilisé UDP. En effet, UDP n’ayant aucune gestion d’acquittement ou de contention, le fait d’observer le transit de ces paquets entre le client et le serveur permet de caractériser le canal.

Mesures

Avec UDP, il est possible de trouver différentes informations sur le canal : comme il n’y a aucune gestion d’acquittement ou de contention, le fait d’inonder le réseau avec un débit plus important que sa capacité permet de mesurer son débit. À contrario, avec un faible débit, le fait de numéroter les paquets permet de connaître le taux de perte. De plus, créer une boucle d’échange de numéro de paquet reçu entre le client et le serveur donne une mesure de la latence. Les mêmes informations sont disponibles au niveau des sockets avec le protocole TCP.

Le serveur est un simple programme écrit en C utilisant les sockets de Berkeley ; tandis que le client est une application iOS, utilisant les mêmes sockets.

Résultats

Nous avons ainsi pu, avec deux iPhones identiques, sur le même opérateur, faire différentes acquisitions dans le métro parisien et comparer les principales caractéristiques des deux protocoles.

Nous avons fait les observations suivantes :

• Le téléchargement sur TCP suit la même tendance que sur UDP, sauf qu’il est ralenti sur des périodes (pouvant durer plusieurs minutes) pendant lesquels le téléchargement est inexistant.
• La latence est très variable, de valeurs proches de celles d’un réseau “classique”, jusqu’à plusieurs dizaines de secondes.
• le taux de perte est variable, il dépasse régulièrement les 10%, voire 20%.

Analyse

Pour comprendre ces arrêts de téléchargement, il faut se plonger un petit peu dans le fonctionnement de TCP. La détection d’une perte de paquet peut se faire de deux façons :

• Triple Acks, le serveur a reçu trois acquittements du destinataire (le mobile) lui indiquant qu’un paquet précédant n’a pas été reçu, dans ce cas le serveur va renvoyer le paquet manquant tout en continuant la suite des envois, la transmission n’est globalement pas perturbée.
• Timeout, le serveur n’a pas reçu de paquet d’acquittement depuis un certain temps (la durée de timeout). Il va alors arrêter l’envoi d’autre paquet et ne renvoyer que celui-là tant qu’il n’aura pas reçu l’acquittement.

Comme, à certains moments, le débit offert par le canal est très faible, la fenêtre d’envoi de TCP est trop petite pour avoir une détection de perte par triple Ack, le serveur détecte donc une perte de paquet par Timeout. De plus la durée de timeout est définie par la mesure de la latence par TCP, celle-ci est peu pertinente étant donné les fortes variations de latence observées sur le canal.

Nous avons alors effectué une acquisition plus précise, paquet par paquet avec Wireshark et Tcpdump, pendant une période de non-téléchargement.

Le phénomène est le suivant, dans certains cas, étant donné le fort taux de perte du réseau, le paquet qui doit être renvoyé est de nouveau perdu ; ce qui entraine, avec l’algorithme de Karn, son renvoi avec un intervalle de transmission qui augmente de façon exponentielle. Ce qui génère des périodes d’attentes très longues et, lorsque le serveur est configuré de façon “classique”, celui-ci coupe la connexion, laissant le client mobile dans un état d’attente.

Nous avons modifié et recompilé une version du noyau Linux dans laquelle nous avons supprimé, dans l’implementation de TCP, l’augmentation de l’intervalle de retransmission. Ce qui permet effectivement de réduire le délai d’attente ; cependant le rendement reste inférieur à celui d’UDP.

Conclusion

Nous avons utilisé la simplicité du protocole UDP pour pouvoir caractériser le canal de transmission d’un réseau opérateur en faible couverture. Ainsi, nous avons mesuré l’efficacité de TCP sur ce type de canal. Notre principale observation est que la mauvaise qualité du canal, couplée a l’algorithme de gestion de congestion de TCP, crée des phases pendant lesquelles aucun transfert n’est possible. C’est, généralement, ce phénomène que l’on observe lorsque l’on subit des blocages intempestifs du téléchargement en zone de faible couverture.

Finalement, nous pouvons dire que TCP reste relativement efficace étant donné la qualité médiocre du canal de transmission. Une modification à grande échelle de TCP coté serveur ne parait pas envisageable puisque c’est un problème qui ne s’applique que dans peu de cas, qui ne sont, de plus, pas prévisibles. Il est donc difficile de mettre en cause le fonctionnement du protocole. Une recherche d’amélioration à plus haut niveau, par exemple par segmentation et rejeu de requête, parait plus accessible.