Por que o upload de internet é tão alto quando na verdade eu não carrego muito?

5

Largura total de banda da Internet mensal

Eu uso vnstat para monitorar o uso da 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  /      --    

Eu troquei ISPs 6 meses atrás e o novo ISP é exigente com o uso mensal total, fazendo com que eu preste mais atenção às estatísticas.

Uso da Internet em tempo real

Eu verifiquei as opções de monitoramento no Ask Ubuntu e as respostas apontam para nethogs , que apenas relata KB / Sec por processo, o que é inevitável que o Firefox ou o Chrome sejam reportados em KB / seg:

Isso não é útil porque eu já sei que uso o Chrome e o Firefox. A questão é "qual guia?" ou é mesmo uma aba? Observe que há processos sendo executados como root ? Eu nunca uso sudo com o Chrome ou o Firefox.

5W investigativos de dados enviados

Existem 5 W's:

  • Quem está enviando 70 GB de dados do meu laptop todos os meses? Eu backup diário para gmail.com que é de 5,4 MB de scripts, documentos, definições de configuração e quais não. São 150 MB por mês. Quem está pegando os outros 69 GB?
  • Qual programa está pegando esses dados? Não posso usar uma única ID de processo para o Chrome ou o Firefox como resposta. Eu preciso saber a guia que aponta para o site. Eu não posso usar root e algum endereço IP aleatório como resposta.
  • Para onde vão esses dados? ou seja, endereço IP.
  • Quando isso está acontecendo? É quando estou assistindo a um filme? Assistindo notícias da internet na Al-Jazeera ou RT? Algum tipo de bolha de notificação no volume de carga seria bom.
  • Por quê? Eu não preciso de uma resposta para essa pergunta. Os outros 4 W serão suficientes. Pode ser o Vault 7 ou pode não ser. Você não pode processar a CIA e se você não pode vencê-los, você deve apenas bloqueá-los.

Hábitos diários na Internet

Há apenas seis coisas que faço diariamente na internet:

  • Visite o Ask do Ubuntu e leia Q & amp; As. Os uploads devem ser de & lt; 1 MB / dia porque qualquer resposta que eu postar é & lt; 30 KB ou atualização.
  • Assista à TV ao vivo da Al-Jazeera.com, que usa HTML5 no youtube.com
  • Assista rt.com/on-the-air que usa o Flash Player
  • Faça backup diário dos meus scripts, documentos e arquivos de configuração via e-mail para minha conta do gmail.com e o arquivo .tar é de 5,4 MB.
  • Assista a um filme em sites aleatórios em resolução de 1080p quando tiver sorte, ou então em 480p ou 720p quando não tiver sorte.
  • Pesquise no Google e visite sites para pesquisar problemas técnicos relacionados ao Linux / Ubuntu.

Resumo

Estou familiarizado com o Shift + Esc no Chrome para monitorar as estatísticas da rede em tempo real pelo Chrome Tab, mas é preferível algo que seja executado nas estatísticas de coleta em segundo plano. / p>

Eu não corri o Windows 8.1 em mais de um mês, então os uploads não estão acontecendo lá. Está tudo no Linux / Ubuntu.

O que posso fazer para restringir minha pesquisa pelos uploads em massa?

Obrigado por ler isso agora.

    
por WinEunuuchs2Unix 01.09.2017 / 03:16

2 respostas

2

Observação: essa resposta apenas aborda alguns dos "5Ws investigativos de upload de dados" desejados.

Use o tcpdump para capturar todo o tráfego de pacotes e use pós-processamento para extrair as informações desejadas.

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

Onde:
minha interface voltada para WAN é enp4s0 ;
Os nomes dos arquivos incluem automaticamente a data e a hora (requer um pacote adicional, mas não me lembro quais); Estou pedindo a rotação de arquivos uma vez por hora; Cada arquivo deve ser processado pelo script packet_post_processor (2 é para essa resposta).

O script de pós-processamento:

#!/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://sobrelinux.info/questions/28447/why-is-internet-upload-so-high-when-i-dont-actually-upload-much"Usage - 
    /*****************************************************************************
*
* 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 */
file-name" exit 1 fi # check that the file actually exists: if [ ! -f ] then echo "tcpdump binary file 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 >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.

O programa c chamado de dentro do script:

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 

Observe que alguns arquivos serão reprovados no processamento das próximas horas. Eu vou consertar isso depois.

Um breve resumo do que o script de pós-processamento está fazendo:
Primeiro, o arquivo binário tcpdump é convertido em texto por sumários de pacotes. Exemplo (meu endereço foi alterado para XXX.XXX.XXX.XXX):

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)

É de propósito que um par de pacotes ARP seja incluído no exemplo, portanto, mostre algo que seria excluído do processamento posterior.
O pacote IGMP irritante de um IP de LAN privada é do meu provedor e também será excluído do processamento posterior. No entanto, se o meu ISP afirmar que eu ultrapassei meu limite de dados mensais, indicarei esses pacotes quando disser que não vou pagar. Observe dois comprimentos mostrados em cada linha, o primeiro é bytes no fio e o segundo é o comprimento da carga útil. Queremos bytes no fio, e é por isso que usamos a opção -e com o tcpdump.

Em segundo lugar, o pacote de saída pode ser identificado exclusivamente encontrando ": XXX.XXX.XXX.XXX.", portanto, extraia todos os pacotes de saída, não incluindo ARP e ICMP, usando grep.

Em terceiro lugar, usando o espaço como um delimitador, o campo 13 é o endereço IP de destino, portanto, use um grupo complicado de comandos canalizados para extrair, contar e classificar os pacotes de endereço IP de destino.

Para frente, classifique os pacotes de saída pelo endereço IP de destino.
Quinto, use o programa c para calcular bytes por IP e bytes por IP / 16 e classificar a saída em histogramas.

Em sexto lugar, investigue manualmente os principais endereços IP na tentativa de identificar o que está acontecendo. Observe que, com muita frequência, é possível encontrar a consulta DNS de pesquisa direta relacionada na saída tcpdump.

Como exemplo, examinei meus dados de WAN / LAN entre 2017-05-31 08:09:33 e 2017-08-09 22:13:11 e editei o que encontrei para os vários endereços IP. < br>
Primeiro os poucos mais por contagem de pacotes:

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)

Em segundo lugar, os poucos mais por contagem de bytes:

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

Observe como, como o Netflix, por exemplo, usa muitos endereços IP, ele pode cair mais baixo no ranking do que deveria, se todos os seus endereços IP fossem tratados como um.

Em terceiro lugar, os primeiros grupos / 16 grupos por contagem de bytes. Observe como o Netflix é agora o maior:

%pre%     
por Doug Smythies 01.09.2017 / 23:38
2

O problema persiste em 7 de janeiro de 2018 no Firefox

pule para baixo, "Editar 6" para ver apenas o problema do Firefox

Problema resolvido em 13 de dezembro de 2017

pule para baixo, "Editar 5" para ver a solução do Chrome

Respondendo 4 dos 5 W's

Consegui isolar quem, o quê, onde e quando os dados estão sendo enviados:

  • Quem = rt.com / on-the-air.
  • What = Plug-in do Flashplayer
  • Onde = no Google Chrome e no Mozilla Firefox
  • Quando = manhã e noite, quando vejo notícias internacionais

O "Porquê" pode ser um bug ou pode ser um spyware ou pode simplesmente ser o Flashplayer configurado para coletar fluxos de informações para fins de relatório de falhas.

A próxima seção detalha as etapas para isolar quem, o que, onde e quando.

Use vnstat -l para acompanhar o tráfego de upload

Pedimos desculpas antecipadamente por imagens de tela abaixo, em vez de copiar e colar em texto. Eu tinha tirado fotos sem saber se as informações eram relevantes até que todos os testes fossem feitos.

O primeiro passo no teste é fechar todas as 10 guias do Google Chrome e três guias do Firefox.

Em seguida, abra um terminal com Ctrl + Alt + T e digite vnstat -l . Isso pressupõe que você já tenha instalado o comando vnstat. Caso contrário, consulte esta resposta sobre vnstat em Ask Ubuntu.

Em seguida, abra uma guia do Google Chrome ou Firefox por vez e monitore as taxas de uso:

Assistindo documentário de 80 minutos sobre o vocalista / produtor da ELO:

O conteúdo está no formato 720p. Um Gigabyte baixado e 40 Megabytes enviados é uma taxa de 4% tx para rx e parece normal.

Assistindo 5 minutos de transmissão de notícias ao vivo no formato Flashplayer usando o Google Chrome:

O conteúdo está no formato 1080p. 103,37 MiB foi baixado, o que é normal, mas quase o dobro desse valor (192,62 MiB = 186%) foi carregado, o que é não normal .

Assistindo a 30 minutos de notícias gravadas baixadas da mesma emissora internacional de notícias:

Pausei a transmissão descarregável pré-gravada de meia hora várias vezes enquanto estava sendo reproduzida. O tempo decorrido foi, na verdade, de 72 minutos. No entanto, o total de downloads (eles são registrados em 720p) é de 508,12 MiB e os uploads são de 21,63 MiB para uma taxa de TX / TX de 4%.

Resumo

A menos que você seja um desenvolvedor de software fazendo upload constante para github ou um artista gráfico freelance fazendo upload constante de seu trabalho para clientes, a proporção normal de tx para rx deve ser de 4% .

Nesse caso, a contabilização mensal da Internet foi de 275,79 GiB baixados e 70,54 GiB enviados para uma taxa tx / rx de 26% . O culpado foi a transmissão de notícias ao vivo do Flashplayer, onde a relação tx / rx é 186% !

Os pandas paranóicos que vivem nas florestas de bambu ao nosso redor podem pensar que a CIA ou a NSA está por trás desses grandes carregamentos. Eu acho que é apenas uma falha de design no FlashPlayer.

Talvez seja a emissora russa (RT) baseada em Moscou que usa software israelense com falhas. Eu digo isso porque eu descobri anteriormente uma falha em seu site de notícias, onde a seção de comentários seria consuma 1 GB de RAM em algumas horas até que a guia seja atualizada. Infelizmente, meu Q & amp; A original parece ter sido excluído, mas depois de postar meu Q & A original aqui na AU, alguém leu e corrigiu esse problema. Espero que pessoas semelhantes encontrem este tópico e corrijam este problema também.

Isso é importante porque, como consumidores, estamos pagando para assistir a mídia. Não estamos pagando para ter o que assistimos carregado com o dobro da largura de banda para "apenas o Google sabe onde".

Editar - Testes no Kernel 4.12.10

Testes anteriores foram conduzidos sob o kernel 4.4.0-93 . Eu fresco instalado kernel 4.12.10 e reiniciei um par de vezes e realizou novos testes. Tanto para o Firefox quanto para o Chrome, os resultados são muito melhores, mas ainda assim as taxas de transmissão / recepção são inaceitáveis.

  • O Firefox por 5,33 minutos tem 108,04 MiB baixados e 57,71 MiB enviados para a relação tx / rx de 53,4%
  • O Google Chrome por 5,57 minutos tem 117,34 MiB baixados e 59,75 MiB enviados por uma taxa de tx / rx de 50,9%

Os dados coletados são mostrados abaixo. À luz desses resultados, vou refazer 4.4.0-93 testes após reiniciar algumas vezes.

Firefox Flashplayer 5 minutos de notícias ao vivo em 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

Flashplayer do Google Chrome 5 minutos de notícias ao vivo em 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

Editar 2 - As coisas pioram quanto mais guias você abrir

Eu estava um pouco prematuro com a minha versão do kernel 4.12.10 hypothesis. Ao investigar mais detalhadamente ao assistir a uma transmissão ao vivo do Flashplayer no Chrome com seis guias, a proporção entre o tx e o rx ficou muito pior. Eu tenho que supor que, de alguma forma, o Flashplayer está reunindo e transmitindo dados para outras abas além da sua.

Transmissão ao vivo do Flashplayer de 26 minutos com cinco outras guias abertas:

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

Como pode ser esperado em 1080p, o download total é de 718.79 MiB. O que é chocante é o 1,13 GiB carregado! Isto dá uma relação tx / rx de 157% . Isso me leva a concluir os resultados dos testes de 2 dias atrás e os snapshots da tela tinham 10 guias do Chrome e 3 abas do Firefox abertas.

O próximo teste será de 7 abas abertas e fazendo surf normal / Faça perguntas e respostas do Ubuntu por meia hora e receba apenas totais não Flashplayer.

Editar 3 - Usando o conky para monitorar em tempo real

Primeiro, os resultados do teste de 7 torneiras abrem, respondendo a uma pergunta do Ubuntu (a acima):

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

Em seguida, um teste com 7 guias abertas sem fazer nada por meia hora na máquina:

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

Assim, podemos ver que, mesmo quando nada está acontecendo na sua máquina, é normal que o Chrome transmita pacotes, mas o tamanho é pequeno (529 KiB ou mais).

Conky text

Eu adicionei este texto conky para monitorar o uso em tempo real da rede:

${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}

Exibição Conky

Os totais na parte inferior são desde a última inicialização, não desde que o conky foi ativado.

Editar 4 - o HTML5 não é enviado como o Flashplayer faz

Executei um teste de 27,5 minutos no Kernel 4.12.10 de um canal de notícias ao vivo do youtube.com (com intervalo de 4 horas) a 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 MiB foram baixados e 19,49 MiB foram enviados, dando a média da relação tx / rx de 4% . Este teste foi feito usando o navegador Chrome, mas espero que os resultados do navegador Firefox sejam os mesmos. Portanto, é seguro assumir que os uploads massivos de dados estão limitados ao Flashplayer e não ao HTML5.

Espero que outros usuários possam testar para confirmar minhas descobertas e comentar abaixo.

Enquanto isso, eu estou mantendo discussões com Doug Smythies (que postou a outra resposta aqui) no Ask Ubuntu General Chat Room sobre sua solução. Usando a resposta de Doug, espero descobrir os endereços IP físicos para os quais meus dados estão indo.

Editar 5 - 13 de dezembro de 2017 - Problema resolvido Kernel 4.14.4

Nos últimos dias, o problema desapareceu por conta própria. Provavelmente uma atualização do Flashplayer ou atualização do kernel:

  • Taxa de upload é agora 8,33 MiB / 224,78 MiB = 4%
  • Erro do Chrome de demorar ~ 5 segundos para maximizar a tela é corrigido
  • O bug do Chrome de imagem sendo ~ 1 segundo atrás da voz é corrigido

vnstat -l results

 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

Observação: No mês passado, recebi um novo laptop onde o problema persistia. No entanto, nos últimos dois dias, o problema desapareceu por conta própria ou de uma atualização do Chrome Versão 63.0.3239.84 (compilação oficial) (64 bits) e / ou porque Kernel 4.14.4 está sendo usado.

Edit 6 - Jan 07 2018 - O problema persiste no Firefox versão 57.0.4

Nos últimos dias, tive problemas ao usar o Chrome, então comecei a usar o Firefox em tempo integral. Eu também instalei o kernel 4.14.12 para testar os patches do kernel do Meltdown:

  • Taxa de upload é agora 254.76 MiB / 364.83 MiB = 70%
  • Erro no Chrome de demorar ~ 5 segundos para maximizar a tela.

vnstat -l results

 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

Então ... círculo completo: (

    
por WinEunuuchs2Unix 03.09.2017 / 18:51