Sur la capture N°1, je ne vois aucun chargement de page web. On voit juste du trafic arrière-plan de Google, lié probablement à Chrome.

Sur la capture N°2, il y a une grosse parie qui est du trafic HTTP/3 (trafic UDP). Tout est caché, on ne peut rien analyser.

Toutefois, il y a un peu de trafic TCP. Notamment une connexion TCP sur "partenaire.bemove.fr"

Voici les paquets en question :



Le premier paquet, c'est toi (192.168.1.65) qui établie la connexion vers partenaire.bemove.fr (62.210.235.151). Le paquet est perdu, on doit attendre une seconde avant la retransmission.

La seconde tentative est la bonne. Ton PC demande à monter la connexion https (Client Hello, un paquet qui envoi la suite d’algorithmes supportés) et là de nouveau paquet perdu. Le paquet Client Hello sera renvoyé 6 fois pour avoir enfin la réponse Server Hello (Choix de la version de la suite d’algorithmes).

On a ensuite les échanges de clés qui se passent bien.

Ensuite ton PC envoie "Change Cipher Spec" (Passage du client en mode chiffré avec la clé master comme clé symétrique) et de nouveau paquet perdu. Il faudra attendre la troisième tentative pour avoir une réponse.

TLS 1.3 n'est pas encore monté qu'on a déjà perdu bêtement 6,3 secondes (c'est énorme) alors que cela doit être fait en quelques dizaines de ms vu que le serveur semble proche.

La connexion ne sera finalement pas utilisée, car le navigateur à, au vu les problèmes à monter la connexion, démarré une seconde connexion vers "partenaire.bemove.fr". Cette seconde connexion va aussi avoir des paquets perdus, mais moins. TLS 1.3 est monté en 1,15 seconde, c'est mieux que les 6,3 secondes observées ici, mais ce n'est pas acceptable.

Il y a visiblement des pertes de certains de paquets. Tu as une IPv4 dédiée ou tu es derrière du CG-Nat (IPv4 publique mutualisée entre plusieurs clients) ?

Je viens de regarder le baromètre IPv6 Arcep, Ozone à 25% de clients FttH avec un IPv4 dédiée. Tu es probablement en mutualisé.

Je ne sais pas si tu peux le voir dans la box, mais qu'elle est l'IP fournie pas le réseau ?

Si c'est une IP dans ces plages, c'est une IP mutualisée, avec un CG-Nat qui pourrait être la cause du problème (c'est une hypothèse, pas la seule)

Récapitulatif des plages d'IP privées :
- 10.0.0.0/8 (10.0.0.0 – 10.255.255.255) - RFC 1918 : 16 777 216 IPv4
- 100.64.0.0/10 (100.64.0.0 - 100.127.255.255) -  RFC 6598 : 4 194 304 IPv4
- 172.16.0.0/12 (172.16.0.0 – 172.31.255.255) - RFC 1918 : 1 048 574 IPv4
- 192.168.0.0/16 (192.168.0.0 – 192.168.255.255) - RFC 1918 : 65 536 IPv4
- fd00::/8  - RFC 4193

Sur le site d'Ozone, tu peut rediriger des ports ?

Il te propose une option IPv4 dédiée à 8 €/mois ?

Pourais-tu faire une capture de 10 chargements de la page de référence 2 (grande taille) : https://lafibre.info/navigateurs/surf-web/
(le tout dans une même capture wireshark) pour que je regarde ?

Si tu peux rediriger les ports, tu fais partie des 25% avec IPv4 dédiée (gratuitement, sûrement lié à ton ancienneté, tu es client depuis de nombreuses années ?).

En aucun cas je te demande de prendre l'option. On cherche à comprendre l'architecture.

Étonnant. Cela serait en fonction des collectes ?

Tu n'avais pas vidé le cache, doit la requête est toute petite (et pas de paquet perdu).

Tout le transfert (avec ouverture de la connexion et monter TLS 1.3, transfert de la page) s'est fait en 0,08 seconde pour comparer avec les temps précédents.

La connexion est rapide, ce qui pose problème, c'est les paquets perdus et il est possible que ce ne soit pas sur l'accès.

Tu as le support Orone au téléphone ?