Votre service de mesure de performance de l'accès Internet utilise plus que probablement TCP et peut-être aussi UDP. Cette partie prendra plus que probablement une bonne moitié de votre rapport. Pour analyser comment votre accès Internet est mesuré par le site web que vous analysez, procédez comme suit:

- utilisez votre navigateur sans aucune autre application lancée et exportez les clés SSL qu'il utilise
- capturez tous les paquets échangés en utilisant wireshark (pas juste les entêtes, capturez aussi le contenu des paquets)
- identifiez quels sont les paquets capturés qui sont bien liés à votre site web (comme vous capturez des paquets sur votre interface réseau, vous pourriez voir des paquets échangés par d'autres ordinateurs ou applications)
- essayez d'abord d'estimer comment le service que vous analysez sélectionne le serveur de test qu'il va utiliser (ces services disposent de différents serveurs de test)
- analysez ensuite comment la mesure du délai est effectuée (requête HTTP, connexion TCP courte, ping, UDP, ... ?)
- analysez ensuite comment la mesure de débit est effectuée (une connexion TCP, plusieurs connexions TCP, ...) en upload et download

Si d’autres mesures sont proposées, décrivez les et expliquez comment elles fonctionnent

Vous pouvez également utiliser l'extension développeur de votre navigateur pour simuler différentes caractéristiques en termes de débit et de latence et voir comment le site de mesure réagit.

 Il y a plusieurs optimisations que vous pourriez détecter :
  • le nombre de connexions TCP parallèles qui sont utilisées pour la mesure.   Dans Wireshark, vous pouvez facilement extraire les paquets de début et fin de connexion avec le filter "tcp.flags.fin==1 or tcp.flags.syn==1 or tcp.flags.reset==1"
  • Les options TCP. Une implémentation TCP récente devrait supporter les options suivantes :
    • TCP Window scale (définie dans RFC7323) : quelle est la valeur du scaling factor annoncée par le serveur et votre portable ?
    • TCP Timestamps options (définie dans RFC7323)
    • TCP Selective Acknowledgements option (définie dans RFC2018) 
  • Certains sites web pourraient aussi supporter
    • TCP Fast Open (RFC7413) qui permet d’envoyer des données dans le SYN durant l’ouverture de la connexion. Les versions récentes de Linux, MacOS et Windows supportent TFO. Vous pouvez aussi essayer avec tracebox (voir http://www.tracebox.org ou scary) pour voir si votre serveur le supporte.
    • TCP Explicit Congestion Notification (RFC3168)vqui permet aux routeurs de marquer les paquets plutôt que de les jeter en cas de congestion
  • La valeur initiale de la fenêtre de congestion du serveur. Cette fenêtre de congestion initiale a un impact sur les performances pour les transferts TCP courts. Le site http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ permet de réaliser cette mesure pour des sites HTTP (pas HTTPS). Vous pouvez aussi inférer cette valeur sur base de la trace paquets que vous avez collecté. En première approximation, la fenêtre initiale devrait être proche du burst de paquets que vous allez recevoir après la négociation TLS et l'envoi du GET HTTP.
  • Le round-trip-time des principales connexions TCP. Plus le rtt est court, plus TCP parviendra à obtenir de bonnes performances en général. Si votre serveur utilise un CDN, vous aurez un rtt très faible. Les mesures RIPE Atlas vous permettent de voir le délai mesuré via ping depuis une centaine de noeuds RIPE Atlas vers votre serveur. Ces mesures sont faites en faisant une résolution du nom de domaine de votre serveur sur chaque noeud RIPE Atlas.
  • Les connexions TCP se terminent-elles de façon ordonnée (via l’échange de FIN) ou de façon abrupte (via l’envoi d’un RST par le serveur) ? 
Pour les mesures en upload, si vous utilisez Linux, vous pouvez essayer changer le mécanisme de contrôle de congestion en utilisant 
sysctl -w net.ipv4.tcp_congestion_control=cubic  (défaut)
sysctl -w net.ipv4.tcp_congestion_control=bbr (plus récent)

Linux supporte plus d'une dizaine de contrôleurs de congestion, mais ils ne sont pas tous compilés par défaut dans les kernels des distributions.


Modifié le: vendredi 1 juillet 2022, 17:28