web-dev-qa-db-fra.com

Pourquoi le téléchargement sur Internet est-il si élevé alors que je n'en télécharge pas beaucoup?

Bande passante Internet totale mensuelle

J'utilise vnstat pour surveiller l'utilisation d'Internet:

$ vnstat

                      rx      /      tx      /     total    /   estimated
 eth0:
       Jul '17    210.70 GiB  /   51.00 GiB  /  261.71 GiB
       Aug '17    275.79 GiB  /   70.54 GiB  /  346.33 GiB  /  348.91 GiB
     yesterday      5.47 GiB  /    2.08 GiB  /    7.55 GiB
         today      2.89 GiB  /    1.36 GiB  /    4.26 GiB  /    5.52 GiB

 wlan0:
       Jul '17         0 KiB  /       0 KiB  /       0 KiB
       Aug '17         0 KiB  /       0 KiB  /       0 KiB  /       0 KiB
     yesterday         0 KiB  /       0 KiB  /       0 KiB
         today         0 KiB  /       0 KiB  /       0 KiB  /      --    

J'ai changé de fournisseur de services Internet il y a 6 mois et le nouveau fournisseur de services Internet est difficile en ce qui concerne l'utilisation mensuelle totale, ce qui m'a amené à accorder une plus grande attention aux statistiques.

Utilisation d'Internet en temps réel

J'ai vérifié les options de surveillance dans Ask Ubuntu et les réponses pointent vers nethogs qui ne signale que Ko/Sec par processus, ce qui est inévitablement Firefox ou Chrome déclarés en KB/Sec:

nethogs

Ce n'est pas utile car je sais déjà que j'utilise Chrome et Firefox. La question est "quel onglet?" ou est-ce même un onglet? Notez que des processus s'exécutant en tant que root? Je n'utilise jamais Sudo avec Chrome ou Firefox.

5W d'investigation de téléchargements de données

Il y a 5 W:

  • Qui télécharge 70 Go de données de mon ordinateur portable chaque mois? Je sauvegarde tous les jours sur gmail.com, ce qui correspond à 5,4 Mo de scripts, documents, paramètres de configuration et autres. C'est 150 Mo par mois. Qui s'empare des 69 Go restants?
  • Quel programme récupère ces données? Je ne peux pas utiliser un seul identifiant de processus pour Chrome ou Firefox comme réponse. J'ai besoin de connaître l'onglet qui pointe vers le site. Je ne peux pas utiliser root et une adresse IP aléatoire comme réponse.
  • Où vont ces données? c'est-à-dire l'adresse IP.
  • Quand est-ce que cela se passe? Est-ce quand je regarde un film? Regarder les nouvelles sur Internet à Al-Jazeera ou à RT? Une sorte de bulle de notification sur le volume de chargement serait Nice.
  • Pourquoi? Je n'ai pas besoin de réponse à cette question. Les 4 autres W suffiront. Il peut s'agir de Vault 7 ou non. Vous ne pouvez pas poursuivre la CIA en justice et si vous ne pouvez pas les battre, vous devriez simplement les bloquer.

Habitudes Internet quotidiennes

Je ne fais que six choses quotidiennement sur Internet:

  • Visitez Ask Ubuntu et lisez les questions et réponses. Les envois doivent être <1 Mo/jour, car toutes les réponses que je poste sont <30 Ko ou mises à jour.
  • Regarder la télévision en direct sur Al-Jazeera.com qui utilise HTML5 sur youtube.com
  • Regardez rt.com/on-the-air qui utilise Flash Player
  • Sauvegardez chaque jour mes scripts, documents et fichiers de configuration par courrier électronique sur mon compte gmail.com. Le fichier .tar fait 5,4 MB.
  • Regarder un film sur des sites Web aléatoires en résolution 1080p avec une chance, sinon en 480p ou en 720p sans la chance.
  • Recherchez sur Google et visitez des sites Web pour rechercher des problèmes techniques liés à Linux/Ubuntu.

Sommaire

Je connais Shift + Esc dans Chrome pour surveiller les statistiques du réseau en temps réel par Chrome Tab, mais il est préférable d’utiliser un élément fonctionnant en arrière-plan. La collecte de statistiques est préférable.

Je n'ai pas exécuté Windows 8.1 depuis plus d'un mois, donc les téléchargements ne se font pas là-bas. Tout est dans Linux/Ubuntu.

Que puis-je faire pour limiter ma recherche aux téléchargements massifs?

Merci d'avoir lu jusqu'ici.

4
WinEunuuchs2Unix

Remarque: cette réponse ne concerne que certains des "5W d'investigation de téléchargements de données" souhaités.

Utilisez tcpdump pour capturer tout le trafic de paquets et utilisez un certain post-traitement pour extraire les informations souhaitées.

Sudo tcpdump -i enp4s0 -w 'ext-%F-%H-%M-%S.bin' -G 3600 -z /home/doug/bin/packet_post_processor2

Où:
mon WAN interface en face est enp4s0;
Les noms de fichier incluent automatiquement la date et l'heure (nécessite un package supplémentaire, mais je ne me souviens plus lequel);
Je demande une rotation de fichier une fois par heure;
Chaque fichier sera post traité par le script packet_post_processor (2 correspond à cette réponse).

Le script de post-traitement:

#!/bin/dash
#
# packet_post_processor2 Doug Smythies. 2017.09.08
#    Edits as required for updated c prgram, and bad sort order.
#    There may be little use in sort by packets count, but for now
#    it remians.
#
# packet_post_processor2 Doug Smythies. 2017.09.01
#    This script will be called from the always running tcpdump.
#    It is called for every binary file rotation.
#    The purpose is to make summary files of things that one
#    may want to investigate in more detail later on.
#
#    This version is for WinEunuuchs2Unix and
# https://askubuntu.com/questions/951783/how-to-find-out-who-is-taking-70-gb-of-data-from-me-each-month
#

#check that the call included the file name, and only the file name, to use.
if [ $# -ne 1 ]
then
  echo "Usage - $0  file-name"
  exit 1
fi

# check that the file actually exists:
if [ ! -f $1 ]
then
  echo "tcpdump binary file $1 does not exist, aborting..."
  exit 1
fi

echo "data extraction 1: All the packets..."
# Note: Using the -e option will ease subsequent bytes per unit time calculations
Sudo tcpdump -n -tttt -e -r $1 >all_e.txt

echo "data extraction 2: The outgoing normal packets..."
# Note: We might want to check that something important doesn't get missed here.
# Note: replace the fake IP address with your actual IP address.
grep ": XXX\.XXX\.XXX\.XXX\." all_e.txt | grep Flags >outgoing.txt

echo "data extraction 3: Make a histogram of the destination IP addresses by packets..."
# Note: use field 13
cut -d" " -f13 outgoing.txt | sed 's/.[^.]*$//' | sort | uniq -c | sort -g >outhisto.txt

# Phase 2: Maximum packet count might not mean maximum byte count, so figure out maximum byte count

echo "data extraction 4: Sort the outgoing file by destination IP address."
LC_ALL=C sort -k 13 <outgoing.txt >outgoing.srt

echo "data extraction 5: Now, calculate bytes per IP and bytes per IP/16 and make sorted historgrams"
# Note: There might be some clever awk or whatever way to do this, but I have a c program.
./tcpdump_bytes outgoing.srt outb.txt out16.txt
sort --general-numeric-sort <outb.txt >outhistob.txt
sort --general-numeric-sort <out16.txt >outhistob16.txt

#Leave the intermidiate files, just for now, while we debug.
#
# packet_post_process. End.

Le programme c appelé depuis le script:

    /*****************************************************************************
*
* tcpdump_bytes.c 2017.09.08 Smythies
*       By sorting the input file before running this program, it can do bytes
*       per IP all on its own, and in one pass through the file. At this time,
*       it is for outgoing only. A future revision will add command line
*       options for incoming and such.
*       Might as well group by 1st 2 IP address bytes at the same time,
*       i.e. for some (not all) of those multiple IP situations.
*
* tcpdump_bytes.c 2017.09.01 Smythies
*       Count the bytes for all the packets in the passed file.
*       See also tcpdump_extract.c, from which this was taken.
*       This program is very quite, just printing bytes, unless there
*       is some error. The idea is that is part of something bigger and
*       therefore extra verbosity would just get in the way.
*
*       Note: The input tcpdump file needs to have been done
*             with the -e option.
*
*****************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_LENGTH 2000  /* maximum line length */

void main(int argc, char **argv){

   char in_buffer[MAX_LENGTH];
   char *infile, *outfile1, *outfile2;
   char *index, *index2;
   FILE *inf, *out1, *out2;
   unsigned current_bytes, sip3, sip2, sip1, sip0, sport, dip3, dip2, dip1, dip0, dport;
   unsigned dest_ip, dest_ip_16, dest_ip_old, dest_ip_16_old;
   unsigned num_lines, num_ips, num_16s;
   unsigned long long total_bytes, total_bytes_16;

   switch(argc){
   case 4:
      infile = argv[1];
      outfile1 = argv[2];
      outfile2 = argv[3];
      break;
   default:
      printf("tcpdump_bytes infile outfile1 outfile2\n");
      printf("  parse outgoing bytes per IP out of a sorted tcpdump file where the -e option was used.\n");
      printf("  infile is sorted tcpdump output file; oufile1 is bytes per IP; outfile 2 is bytes per IP/16.\n");
      exit(-1);
   } /* endcase */

   if((inf = fopen(infile, "rt")) == NULL){
      printf("Unable to open input file '%s'\n", infile);
      exit(-1);
   } /* endif */
   if((out1 = fopen(outfile1, "wt")) == NULL){
      printf("Error opening output file '%s'\n", outfile1);
      exit(-1);
   } /* endif */
   if((out2 = fopen(outfile2, "wt")) == NULL){
      printf("Error opening output file '%s'\n", outfile2);
      exit(-1);
   } /* endif */

   total_bytes = 0;
   total_bytes_16 = 0;
   dest_ip_old = 0;
   dest_ip_16_old = 0;
   num_lines = 0;
   num_ips = 0;
   num_16s = 0;

   while((fgets(in_buffer, MAX_LENGTH, inf)) != NULL){       /* do infile line at a time */
      num_lines++;

      if((index = strstr(in_buffer, "), length ")) != NULL){ /* find search string if it is there, then parse the data */
         sscanf(index, "), length %u: %u.%u.%u.%u.%u > %u.%u.%u.%u.%u:",
            &current_bytes,
            &sip3, &sip2, &sip1, &sip0,
            &sport,
            &dip3, &dip2, &dip1, &dip0,
            &dport);
      } else {
         printf("tcpdump_bytes: Got an odd line: %s", in_buffer);
      } /* endif */
      dest_ip_16 = (dip3 << 24) + (dip2 << 16);
      dest_ip = dest_ip_16 + (dip1 << 8) + dip0;
//    printf("debug: B: %u  S: %u.%u.%u.%u.%u  D: %u.%u.%u.%u.%u  %u  %u\n", current_bytes, sip3, sip2, sip1, sip0, sport, dip3, dip2, dip1, dip0, dport, dest_ip, dest_ip_16);

      if(dest_ip != dest_ip_old){
         if(total_bytes != 0){
            fprintf(out1, "%llu %u.%u.%u.%u\n", total_bytes, (dest_ip_old >> 24) & 0xff, (dest_ip_old >> 16) & 0xff, (dest_ip_old >> 8) & 0xff, dest_ip_old & 0xff);
            total_bytes = 0;
         } /* endif */
         dest_ip_old = dest_ip;
         num_ips++;
      } /* endif */
      total_bytes = total_bytes + (unsigned long long) current_bytes;

      if(dest_ip_16 != dest_ip_16_old){
         if(total_bytes_16 != 0){
            fprintf(out2, "%llu %u.%u.0.0/16\n", total_bytes_16, (dest_ip_16_old >> 24) & 0xff, (dest_ip_16_old >> 16) & 0xff);
            total_bytes_16 = 0;
         } /* endif */
         dest_ip_16_old = dest_ip_16;
         num_16s++;
      } /* endif */
      total_bytes_16 = total_bytes_16 + (unsigned long long) current_bytes;
   } /* endwhile */

   /* don't forget to output the last data */
   if(total_bytes != 0){
      fprintf(out1, "%llu %u.%u.%u.%u\n", total_bytes, dip3, dip2, dip1, dip0);
   } else {
      printf("tcpdump_bytes: Something is wrong. Last IP address has no bytes.\n");
   } /* endif */

   if(total_bytes_16 != 0){
      fprintf(out2, "%llu %u.%u.0.0/16\n", total_bytes_16, dip3, dip2);
   } else {
      printf("tcpdump_bytes: Something is wrong. Last IP/16 address has no bytes.\n");
   } /* endif */

   fclose(inf);
   fclose(out1);
   fclose(out2);
   printf("tcpdump_bytes: Done. Processed %d lines and %d IP addresses and %d /16 addresses\n", num_lines, num_ips, num_16s);
} /* endprogram */

Notez que certains fichiers seront obstrués lors du prochain traitement. Je vais arranger ça plus tard.

Un résumé rapide de ce que fait le script de post-traitement:
Tout d’abord, le fichier binaire tcpdump est converti en texte de résumé par paquet. Exemple (mon adresse a été changée en XXX.XXX.XXX.XXX):

2017-05-31 08:10:31.721956 00:22:b0:75:c2:bd > 6c:be:e9:a7:f1:07, ethertype IPv4 (0x0800), length 400: XXX.XXX.XXX.XXX.52779 > 38.113.165.77.443: Flags [P.], seq 1:347, ack 1, win 256, length 346
2017-05-31 08:10:31.826241 6c:be:e9:a7:f1:07 > 00:22:b0:75:c2:bd, ethertype IPv4 (0x0800), length 157: 38.113.165.77.443 > XXX.XXX.XXX.XXX.52779: Flags [P.], seq 1:104, ack 347, win 1026, length 103
2017-05-31 08:10:31.877945 00:22:b0:75:c2:bd > 6c:be:e9:a7:f1:07, ethertype IPv4 (0x0800), length 54: XXX.XXX.XXX.XXX.52779 > 38.113.165.77.443: Flags [.], ack 104, win 256, length 0
2017-05-31 08:10:32.603768 00:22:b0:75:c2:bd > 6c:be:e9:a7:f1:07, ethertype ARP (0x0806), length 42: Request who-has XXX.XXX.XXX.YYY tell XXX.XXX.XXX.XXX, length 28
2017-05-31 08:10:32.630960 6c:be:e9:a7:f1:07 > 00:22:b0:75:c2:bd, ethertype ARP (0x0806), length 60: Reply XXX.XXX.XXX.YYY is-at 6c:be:e9:a7:f1:07, length 46
2017-05-31 08:10:33.643468 00:90:d0:63:ff:00 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 10.197.248.13 > 224.0.0.1: igmp query v2
2017-05-31 08:10:37.448732 00:22:b0:75:c2:bd > 6c:be:e9:a7:f1:07, ethertype IPv4 (0x0800), length 90: XXX.XXX.XXX.XXX.53120 > 91.189.89.199.123: NTPv4, Client, length 48 

C'est à dessein qu'une paire de paquets ARP est incluse dans l'exemple. Indiquez donc un élément qui serait exclu du traitement ultérieur.
Le paquet IGMP agaçant provenant d’une adresse IP de réseau local privée provient de mon FAI et sera également exclu des traitements ultérieurs. Toutefois, si mon fournisseur de services Internet prétend que j'ai dépassé ma limite de données mensuelle, je signalerai ces paquets lorsque je dis ce pour quoi je ne paierai pas. Remarquez deux longueurs affichées sur chaque ligne, la première en octets sur le fil et la seconde en longueur de charge. Nous voulons des octets sur le réseau, et c’est pourquoi nous utilisons l’option -e avec tcpdump.

Deuxièmement, les paquets sortants peuvent être identifiés de manière unique en recherchant ": XXX.XXX.XXX.XXX.", Afin d'extraire tous les paquets sortants, à l'exclusion des fichiers ARP et ICMP, à l'aide de grep.

Troisièmement, en utilisant l’espace comme délimiteur, le champ 13 est l’adresse IP de destination. Utilisez donc un ensemble compliqué de commandes redirigées pour extraire, compter et trier les paquets d’adresses IP de destination.

Quatrièmement, triez les paquets sortants par adresse IP de destination.
Cinquièmement, utilisez le programme c pour calculer les octets par IP et les octets par IP/16, puis triez la sortie en histogrammes.

Sixièmement, recherchez manuellement les adresses IP principales pour tenter d’identifier ce qui se passe. Notez que très souvent, on peut trouver la requête DNS de recherche directe associée dans la sortie de tcpdump.

Par exemple, j'ai examiné mes données WAN/LAN entre le 31/05/2017 à 08h09h33 et le 2017-08-09 22h13:11 et les modifications que j'ai trouvées pour les différentes adresses IP.

Premièrement, le nombre le plus élevé par nombre de paquets:

packets IP Address      Added Comment
 299517 91.189.95.84    Ubuntu stuff
 301129 198.38.112.140  Netflix
 306815 17.253.31.206   Apple stuff
 319558 129.97.134.71   Ubuntu stuff (mirror, I think)
 333334 91.189.88.152   Ubuntu stuff
 352141 91.189.88.39    Ubuntu stuff
 353160 209.121.139.153 Telus (Microsoft updates streaming)
 368669 209.121.139.163 Telus (Microsoft updates streaming)
 389928 91.189.88.161   Ubuntu stuff
 396087 23.60.74.158    deploy.static.akamaitechnologies.com (?)
 421259 198.38.112.170  Netflix
 474506 17.253.31.205   Apple stuff
 477706 198.38.109.153  Netflix
 480452 198.38.112.159  Netflix
 540261 198.38.112.173  Netflix
 574592 198.38.112.132  Netflix
 710022 198.38.112.174  Netflix
 728434 209.121.139.144 Telus (Microsoft updates streaming)
 738839 198.38.112.130  Netflix
 883688 198.38.109.171  Netflix
1049778 198.38.112.154  Netflix
2166582 72.21.81.200    Hmmmm ? MCI Communications Services, (Skype, I think)
7512548 13.107.4.50     Microsoft (updates)

Deuxièmement, le nombre le plus élevé d'octets par octet:

Bytes    IP                     Added Comment
32358580 17.253.31.205          Apple stuff
32625068 198.38.112.159         Netflix
34220805 172.217.3.206          Google web crawler
36628021 198.38.112.173         Netflix
37022702 17.188.208.132         Apple stuff
39105254 198.38.112.132         Netflix
40697177 209.121.139.144        Telus Microsoft updates file streaming
48247623 198.38.112.174         Netflix
49537980 64.4.54.254            Microsoft
50358753 198.38.112.130         Netflix
59623846 198.38.109.171         Netflix
71532166 198.38.112.154         Netflix
98480036 207.167.198.18         Telus e-mail stuff
139907010 72.21.81.200          Hmmmm ? MCI Communications Services, (Skype, I think)
210138801 91.189.95.84          Ubuntu stuff
325511064 204.79.197.213        Microsoft (?) msedge.net storage.skyprod.akadns.net
479586878 13.107.4.50           Microsoft (updates)

Notez que, puisque Netflix, par exemple, utilise plusieurs adresses IP, le classement risque de tomber plus bas que prévu, si toutes ses adresses IP étaient traitées comme une seule.

Troisièmement, les quelques premiers/16 groupes par octets comptent. Remarquez comment Netflix est maintenant le plus gros:

107592753 209.52.0.0/16         cache.google.com (for example)
116538884 207.167.0.0/16        Telus e-mail stuff
120769715 17.188.0.0/16         Apple. store-025-failover2.blobstore-Apple.com.akadns.net (for example)
139261655 52.218.0.0/16         s3-us-west-2.amazonaws.com (for example) ? Hmmm...
147091123 172.217.0.0/16        Google web crawler
153146532 17.248.0.0/16         p46-keyvalueservice.fe.Apple-dns.net. Apple iCloud Drive
183300509 72.21.0.0/16          Skype (I think)
213119564 209.121.0.0/16        Telus Microsoft updates file streaming
333374588 204.79.0.0/16         Microsoft
354346088 91.189.0.0/16         Ubuntu stuff
488793579 13.107.0.0/16         Microsoft (updates)
621733032 198.38.0.0/16         Netflix
2
Doug Smythies

Le problème persiste le 7 janvier 2018 dans Firefox

aller au bas de la page, "Éditer 6" pour voir le seul problème de Firefox

Problème résolu 13 décembre 2017

aller au bas de la page, "Modifier 5" pour voir Chrome solution

Répondre à 4 des 5 questions

J'ai pu isoler les données de qui, quoi, où et quand:

  • Qui = rt.com/à la radio.
  • Quoi = plug-in Flashplayer
  • Where = dans Google Chrome et Mozilla Firefox
  • Quand = Matin et soir lorsque je regarde des informations internationales

Le "Pourquoi" peut être un bogue ou un logiciel espion ou simplement Flashplayer a été configuré pour collecter des flux d’informations à des fins de signalement des incidents.

La section suivante détaille les étapes à suivre pour isoler qui, quoi, où et quand.

Utilisez vnstat -l pour suivre le trafic de téléchargement

Veuillez nous excuser par avance pour les images d'écran ci-dessous plutôt que pour copier et coller du texte. J'avais pris des instantanés ne sachant pas si l'information était pertinente jusqu'à ce que tous les tests aient été effectués.

La première étape du test consiste à fermer les 10 onglets Chrome et les 3 onglets Firefox.

Ensuite, ouvrez un terminal avec Ctrl + Alt + T et tapez vnstat -l. Cela suppose que vous avez déjà installé la commande vnstat. Sinon, voyez ceci réponse à propos de vnstat dans Ask Ubuntu.

Ouvrez ensuite un onglet Chrome ou Firefox à la fois et surveillez les taux d'utilisation:

Regarder un documentaire de 80 minutes sur le chanteur/producteur d'ELO:

vnstat -l 720p movie putlockerhd.png

Le contenu est au format 720p. Un gigaoctet téléchargé et 40 Mo téléchargés correspondent à un rapport de 4% tx sur rx et semblent normaux.

Regarder des nouvelles en direct de 5 minutes au format Flashplayer avec Google Chrome:

vnstat chrome flash player rt on air.png

Le contenu est au format 1080p. 103,37 Mio ont été téléchargés, ce qui est normal, mais presque deux fois plus (192,62 Mio = 186%) ont été téléchargés, ce qui est pas normal .

Regarder 30 minutes de nouvelles enregistrées téléchargeables à partir du même diffuseur international:

vnstat -l rt.com-shows rt america.png

J'ai mis en pause la diffusion téléchargeable préenregistrée d'une demi-heure plusieurs fois pendant la lecture. Le temps écoulé était en réalité de 72 minutes. Néanmoins, le total des téléchargements (enregistrés à 720p) s'élève à 508,12 Mio et les téléchargements à 21,63 Mio pour un ratio tx: rx de 4%.

Sommaire

À moins que vous ne soyez un développeur de logiciels et que vous téléchargiez constamment sur github, ou qu'un graphiste indépendant publiez constamment votre travail sur des clients, le rapport tx/rx normal devrait être d'environ 4% .

Dans ce cas, la comptabilité Internet mensuelle était de 275,79 GiB téléchargés et de 70,54 GiB téléchargés pour un rapport tx/rx de 26% . Le coupable était l’émission en direct de Flashplayer où le rapport tx/rx était égal à 186% !

Les paranoïaques pandas vivant dans les forêts de bambous qui nous entourent pourraient penser que la CIA ou NSA est derrière ces gros envois. Je pense que c'est simplement un défaut de conception dans FlashPlayer.

Ce pourrait être le radiodiffuseur russe (RT) basé à Moscou utilisant un logiciel israélien avec des problèmes. Je dis cela parce que j’avais précédemment découvert un problème sur leur site Web d’actualités où la section de commentaires consomme 1 Go de RAM dans quelques heures jusqu’à ce que l’onglet soit actualisé. Malheureusement, mon Q & R original semble avoir été supprimé, mais après avoir posté mon Q & A original ici, quelqu'un l'a lu et a corrigé le problème. Espérons que des personnes similaires trouveront ce fil et régleront également ce problème.

Ceci est important car, en tant que consommateurs, nous payons pour regarder des médias . Nous ne payons pas pour que ce que nous regardons soit chargé deux fois plus de bande passante sur "Seul Google sait où".


Edition - Tests sous Noyau 4.12.10

Les tests précédents ont été effectués sous le noyau 4.4.0-93. J'ai fraîchement installé le noyau 4.12.10 et j'ai redémarré plusieurs fois pour effectuer de nouveaux tests. Pour Firefox et Chrome, les résultats sont grandement améliorés, mais les rapports tx/rx sont toujours inacceptables.

  • Firefox pendant 5.33 minutes a 108,04 MiB téléchargés et 57,71 MiB téléchargés pour un rapport tx/rx de 53,4%
  • Chrome pour 5,57 minutes a 117,34 Mio téléchargés et 59,75 Mio téléchargés pour un rapport tx/rx de 50,9%

Les données recueillies montrent ci-dessous. À la lumière de ces résultats, je vais refaire les tests 4.4.0-93 après avoir redémarré plusieurs fois.

Firefox Flashplayer 5 minutes nouvelles en direct à 1080p:

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        1 kbit/s     1 p/s          tx:        1 kbit/s     1 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   108.04 MiB  |       57.71 MiB
--------------------------------------+------------------
          max           14.72 Mbit/s  |    10.64 Mbit/s
      average            2.77 Mbit/s  |     1.48 Mbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     133538  |          104640
--------------------------------------+------------------
          max               1395 p/s  |        1219 p/s
      average                417 p/s  |         327 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                  5.33 minutes

Chrome Flashplayer 5 minutes en direct en 1080p:

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        0 kbit/s     0 p/s          tx:        0 kbit/s     0 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   117.34 MiB  |       59.75 MiB
--------------------------------------+------------------
          max           25.13 Mbit/s  |     9.92 Mbit/s
      average            2.88 Mbit/s  |     1.47 Mbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     139174  |          126372
--------------------------------------+------------------
          max               2363 p/s  |        1441 p/s
      average                416 p/s  |         378 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                  5.57 minutes

Edit 2 - La situation empire avec le nombre d'onglets ouverts

J'étais un peu prématuré avec la version de mon noyau 4.12.10 hypothèse. Enquêtant plus loin en regardant une diffusion Flashplayer en direct dans Chrome avec 6 onglets ouverts, le rapport tx/rx s'est beaucoup dégradé. Je dois supposer que Flashplayer recueille et transmet des données pour d’autres onglets que les siens.

Chrome 26 minutes de diffusion en direct de Flashplayer avec 5 autres onglets ouverts:

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        1 kbit/s     1 p/s          tx:        1 kbit/s     1 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   718.79 MiB  |        1.13 GiB
--------------------------------------+------------------
          max           30.10 Mbit/s  |    12.72 Mbit/s
      average            3.73 Mbit/s  |     6.00 Mbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                    1100634  |         1396530
--------------------------------------+------------------
          max               2616 p/s  |        1774 p/s
      average                696 p/s  |         883 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 26.33 minutes

Comme on peut s'y attendre à 1080p, le téléchargement total est de 718.79 Mio. Ce qui est choquant, c’est le 1.13 GiB uploadé! Cela donne un rapport tx/rx de 157% . Cela me conduit à conclure mes résultats de test d'il y a 2 jours et ces captures d'écran avaient mes onglets habituels 10 Chrome et 3 onglets Firefox ouverts.

Le prochain test consistera en 7 onglets ouverts et en surfant normalement/Posez des questions à Ubuntu pendant 1/2 heure et obtenez uniquement les totaux non Flashplayer.

Edit 3 - Utiliser conky pour surveiller en temps réel

Tout d'abord, les résultats de test de 7 robinets ouverts répondent à une question Ubuntu (celle ci-dessus):

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        1 kbit/s     1 p/s          tx:        2 kbit/s     3 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                     1.14 MiB  |         454 KiB
--------------------------------------+------------------
          max            2.40 Mbit/s  |      136 kbit/s
      average            9.35 kbit/s  |     3.64 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                       3699  |            2776
--------------------------------------+------------------
          max                257 p/s  |         163 p/s
      average                  3 p/s  |           2 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 16.63 minutes

Ensuite, un test avec 7 onglets ouverts ne fait rien pendant 1/2 heure sur la machine:

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        1 kbit/s     1 p/s          tx:        2 kbit/s     2 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                      766 KiB  |         529 KiB
--------------------------------------+------------------
          max             121 kbit/s  |      164 kbit/s
      average            3.33 kbit/s  |     2.30 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                       4752  |            3772
--------------------------------------+------------------
          max                256 p/s  |          24 p/s
      average                  2 p/s  |           2 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 30.70 minutes

Ainsi, nous pouvons voir que même si rien ne se passe sur votre ordinateur, il est normal que Chrome transmette des paquets, mais la taille est petite (529 Ko environ).

Texte Conky

J'ai ajouté ce texte conky pour surveiller l'utilisation du réseau en temps réel:

${color1}Network real-time monitoring
${color}Down: ${color green}${downspeed eth0}/s ${color}${goto 220}Up: ${color green}${upspeed eth0}/s
${downspeedgraph eth0 25,190 000000 ff0000} ${alignr}${upspeedgraph eth0
25,190 000000 00ff00}$color
Total: ${color green}${totaldown eth0} $color${alignr}Total: ${color green}${totalup eth0}
${color orange}${voffset 2}${hr 1}

Écran Conky

conky network real time 4.gif

Les totaux en bas sont depuis le dernier démarrage, pas depuis que conky a été allumé.

Modifier 4 - HTML5 ne télécharge pas comme Flashplayer

J'ai exécuté un test de 27,5 minutes sous le noyau 4.12.10 d'une chaîne d'informations en direct de youtube.com (avec décalage horaire de 4 heures) en 1080p:

rick@Dell:~$ vnstat -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:       12 kbit/s     4 p/s          tx:        3 kbit/s     2 p/s^C


 eth0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   474.04 MiB  |       19.49 MiB
--------------------------------------+------------------
          max           17.27 Mbit/s  |     2.16 Mbit/s
      average            2.35 Mbit/s  |    96.76 kbit/s
          min               0 kbit/s  |        0 kbit/s
--------------------------------------+------------------
  packets                     346609  |          198883
--------------------------------------+------------------
          max               1481 p/s  |        1047 p/s
      average                210 p/s  |         120 p/s
          min                  0 p/s  |           0 p/s
--------------------------------------+------------------
  time                 27.50 minutes

474,04 Mio ont été téléchargés et 19,49 Mio ont été téléchargés, ce qui donne un rapport tx/rx moyen de de 4% . Ce test a été effectué à l'aide du navigateur Chrome, mais je m'attends à ce que les résultats du navigateur Firefox soient identiques. Par conséquent, il est prudent de supposer que les transferts massifs de données sont limités à Flashplayer et non à HTML5.

Espérons que d'autres utilisateurs pourront tester pour confirmer mes conclusions et commenter ci-dessous.

Entre-temps, je discute avec Doug Smythies (qui a posté l'autre réponse ici) dans le forum de discussion Ask Ubuntu General à propos de sa solution. En utilisant la réponse de Doug, j'espère découvrir les adresses IP physiques sur lesquelles mes données seront transmises.


Édition 5 - déc 13 2017 - Problème résolu Kernel 4.14.4

Au cours des deux derniers jours, le problème est parti de lui-même. Probablement une mise à jour de Flashplayer ou du noyau:

  • Le taux de téléchargement est maintenant de 8,33 Mio/224,78 Mio = 4%
  • Un bug de Google Chrome prenant environ 5 secondes pour maximiser l'écran est corrigé
  • Un bogue de Google Chrome concernant l'image se trouvant à environ 1 seconde derrière la voix est corrigé

vnstat -l résultats

 enp59s0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   224.78 MiB  |        8.33 MiB
--------------------------------------+------------------
          max           10.26 Mbit/s  |      799 kbit/s
      average            2.48 Mbit/s  |    92.00 kbit/s
          min               2 kbit/s  |        4 kbit/s
--------------------------------------+------------------
  packets                     162124  |           95039
--------------------------------------+------------------
          max                886 p/s  |         408 p/s
      average                218 p/s  |         128 p/s
          min                  1 p/s  |           1 p/s
--------------------------------------+------------------
  time                 12.37 minutes

Remarque: Le mois dernier, j'ai eu un nouvel ordinateur portable où le problème persistait. Cependant, au cours des derniers jours, le problème a disparu de son propre choix, soit à partir d'une Chrome mise à jour Version 63.0.3239.84 (Build officiel) (64 bits) et/ou parce que le noyau 4.14.4 est utilisé.


Edit 6 - Jan 07 2018 - Le problème persiste Firefox version 57.0.4

Ces derniers jours, j’ai eu des problèmes d’utilisation de Chrome alors j’ai commencé à utiliser Firefox à plein temps. J'ai aussi installé le noyau 4.14.12 pour tester les correctifs du noyau Meltdown:

  • Le taux de téléchargement est maintenant de 254,76 Mio/364,83 Mio = 70%
  • Bogue de Google Chrome prenant environ 5 secondes pour maximiser l'écran est revenu

vnstat -l résultats

 enp59s0  /  traffic statistics

                           rx         |       tx
--------------------------------------+------------------
  bytes                   364.83 MiB  |      254.76 MiB
--------------------------------------+------------------
          max           15.23 Mbit/s  |     9.88 Mbit/s
      average            3.58 Mbit/s  |     2.50 Mbit/s
          min             195 kbit/s  |      100 kbit/s
--------------------------------------+------------------
  packets                     429358  |          364510
--------------------------------------+------------------
          max               1450 p/s  |        1229 p/s
      average                513 p/s  |         436 p/s
          min                147 p/s  |          94 p/s
--------------------------------------+------------------
  time                 13.93 minutes

Alors .... cercle complet :(

2
WinEunuuchs2Unix