L’époque où l’on utilisait une session par application est bien évidemment révolue depuis longtemps… Chaque navigateur/OS utilise des techniques différentes pour améliorer l’expérience des utilisateurs en ouvrant simultanément plusieurs sessions TCP. Une étude montre les disparités selon les environnements: on a ratio de 1/5 entre ceux qui ouvrent le moins de session et les plus gourmands. Idem l’ouverture des sessions dans le temps n’est pas homogène entre navigateurs. J’ai réalisé dans mon lab NAT64 un petit test rapide qui met en évidence ce constat:
| Site | Browser | Nb sessions |
| www.facebook.com | Chrome | 15 |
| www.facebook.com | Firefox | 18 |
| maps.google.com | Chrome | 50 |
| maps.google.com | Firefox | 60 |
| igoogle | Chrome | 143 |
| igoogle | Safari | 35 |
Cela confirme que la plupart des applications grand public sont sur-consommatrices de sessions TCP. Dans l’hypothèse où cela est NATté derrière des CGN comme cela va être le cas avec les smartphones, on imagine la conséquence sur:
- La qualité de l’expérience utilisateur
- Scalabilité de la solution nécessaire pour accueillir les 50 milliards d’équipements mobiles attendus d’ici environ 3 ans.
- Les coûts associés en termes OPEX/CAPEX
- La difficulté à résoudre les problèmes et à logguer les sessions (identification des utilisateurs et de leurs usages)
Ne vaut-il pas mieux éviter d’être NATé en revenant à un modèle end-to-end simple permis par IPv6?
Accéder à l’étude: http://opensourceaplusp.weebly.com/experiments-results.html
Authors
2 commentaires
143 session pour Chrome ?
Cela ne viendrai pas de la fonctionnalité de pré-connexion ?
Le test a été fait assez rapidement et j’avoue avoir été plus dans l’expérience que dans l’explication! Je vais refaire le test rapidement (pour confirmer le chiffre) et voir comment l’expliquer! Toute aide est bienvenue!