Un VPN consomme-t-il plus de données ? Surcoût, keepalives et compteurs

La question arrive avec une alerte data après un mois de voyage : le VPN a-t-il mangé le forfait ? Un tunnel ajoute bel et bien des octets, car chaque paquet gagne un nouvel en-tête externe et la connexion transporte son propre trafic de contrôle. Ce qu'il ne fait pas, c'est doubler le fichier téléchargé ou empêcher le fournisseur de compter. La réponse honnête a deux moitiés : une sur le surcoût et une sur la façon dont les chiffres sont produits.

Le mythe : le VPN multiplie votre consommation

L'idée reçue est que le tunnelage double à peu près le trafic, si bien qu'un forfait disparaît deux fois plus vite. Il faudrait pour cela un surcoût proche de la taille de la charge utile, ce qui n'arrive qu'avec de très petits paquets et des protocoles bavards. En navigation et en streaming ordinaires, les octets supplémentaires représentent une petite fraction de l'ensemble, et le tunnel est rarement la raison pour laquelle un mois s'épuise tôt. Un tunnel instable est une autre histoire, et c'est là que vit la vraie multiplication.

Le fournisseur mesure la connexion externe quel que soit son contenu, donc un tunnel ne peut pas rendre le trafic gratuit. Il ne peut pas non plus cacher le volume à l'opérateur, car c'est l'opérateur qui le déplace.

Ce qui ajoute réellement des octets

L'encapsulation enveloppe chaque paquet dans un nouvel en-tête et l'authentification ajoute ses propres champs, le coût exact dépendant du protocole et des familles d'adresses utilisées. Les petits paquets souffrent le plus, car un en-tête fixe représente une part plus grande d'un total faible. Un transfert continu avec des charges de taille maximale paie proportionnellement moins, et c'est pourquoi deux personnes sur le même VPN peuvent voir des pourcentages très différents. La taille des paquets et la MTU décident de la part du chemin consacrée aux en-têtes plutôt qu'au contenu.

Les keepalives et les poignées de main ajoutent du trafic qui n'existe que pour garder le tunnel ouvert, et ils restent négligeables jusqu'à ce que quelque chose casse. Un lien instable en fait un coût réel, car chaque reconnexion répète la configuration et chaque flux interrompu invite l'application à réessayer. La nouvelle tentative est la partie chère : un envoi qui repart de zéro peut coûter plus qu'une semaine de keepalives.

Les applications envoient aussi plus que le contenu des fichiers. Les requêtes, les accusés et le bavardage du protocole existaient avant le tunnel et comptent toujours, donc la différence entre avec et sans est l'enveloppe, pas toute la conversation. L'enveloppe est la seule partie que le VPN possède vraiment.

Pourquoi deux compteurs ne concordent jamais

Quatre endroits peuvent signaler la consommation : le téléphone, l'application VPN, le routeur et l'opérateur, et chacun mesure une interface différente sur une fenêtre différente. Un compteur d'interface virtuelle voit le trafic intérieur tandis que l'interface physique voit les paquets extérieurs, donc les deux diffèrent d'environ le surcoût que vous cherchez à mesurer. Certaines vues d'attribution se chevauchent aussi, ce qui signifie qu'additionner chaque chiffre affiché peut compter deux fois les mêmes octets. Le cycle de facturation, la session de l'application et la réinitialisation du système commencent également à des moments différents.

Sur Android, la vue prise en charge de cela est NetworkStatsManager, qui rapporte des compartiments par interface et par uid sur des fenêtres temporelles. Pour tout ce qui touche à l'argent, faites davantage confiance à la comptabilité du fournisseur qu'au total d'une session d'application. L'application est une vue de confort et peut inclure ou exclure du trafic selon sa mise en œuvre, et un rapport retardé fait paraître fausse une lecture ultérieure alors que rien n'a changé.

adb shell dumpsys netstats | grep -A3 "iface=wlan0"
adb shell dumpsys netstats detail | grep -i vpn

Lisez le nom de l'interface sur chaque ligne avant de comparer quoi que ce soit. Deux totaux pour des interfaces différentes ne sont pas deux mesures de la même chose, et les traiter comme un seul produit un chiffre de surcoût qui est en réalité un écart comptable.

Mesurez une tâche répétable plutôt qu'un test de débit

Choisissez un compteur, un appareil, un réseau et une tâche, puis répétez la tâche et comparez les relevés. Un test de débit est le mauvais instrument car il consomme délibérément tout ce qu'il peut, et son coût peut dépasser le problème quotidien que vous examiniez. Mettez d'abord en pause les sauvegardes et les mises à jour, laissez l'activité de fond se calmer et notez le protocole et la version du client à côté du chiffre. Un envoi repris est une charge différente d'un transfert propre, donc comparer les deux ne mesure rien d'utile.

Si une comparaison directe entre en conflit avec vos exigences de confidentialité, comparez plutôt deux configurations VPN prises en charge et indiquez cette limite à côté du résultat. Notez quelle configuration a produit quel chiffre, afin que la comparaison survive au prochain lecteur.

Où regarder quand la facture et l'application ne concordent pas

Vérifiez d'abord la fenêtre, puis l'interface, puis la couche. Un écart qui survit aux trois est une question pour le fournisseur et non un réglage du client, et la réponse nomme généralement un retard de rapport ou un forfait partagé.

Gardez les réglages de mise à jour des applications et de données mobiles adaptés au forfait, et planifiez les transferts volumineux sur une connexion qui peut les supporter. Si vous partagez la connexion, vérifiez la couverture du point d'accès séparément, car le tunnel du téléphone ne dit rien sur la façon dont le trafic partagé est routé ou compté.