Почему интернет-загрузка настолько высоко, когда я на самом деле не загружаю много?
Интернет-пропускная способность Total Monthly
Я использую vnstat контролировать использование Интернета:
$ 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 / --
Я переключил ISPs 6 месяцев назад, и новый ISP придирчив на общем ежемесячном использовании, заставляющем меня обращать более близкое внимание на статистику.
Оперативное использование Интернета
Я регистрировал контролирующие опции, Просят Ubuntu и ответы указывать на nethogs который только сообщает о кБайт/с процессом, который является неизбежно Firefox или Chrome, оба сообщили в кБайт/с:
Это не полезно, потому что я уже знаю, что использую Chrome и Firefox. Вопрос "который вкладка?" или это - даже вкладка? Уведомление там является процессами, работающими как root? Я никогда не использую sudo с Chrome или Firefox.
Следственный 5W's загрузок данных
Существует 5 Вт:
- Кто загружает 70 ГБ данных из моего ноутбука каждый месяц? Я ежедневно копирую на gmail.com, который составляет 5,4 МБ сценариев, документов, параметров конфигурации и что нет. Это составляет 150 МБ в месяц. Кто захватывает других 69 ГБ?
- Какая программа захватывает эти данные? Я не могу использовать единственный идентификатор процесса для Chrome или Firefox как ответ. Я должен знать вкладку, которая указывает на веб-сайт. Я не могу использовать
rootи некоторый случайный IP-адрес как ответ. - Куда эти данные идут? т.е. IP-адрес.
- Когда это происходит? Это, когда я смотрю кино? Смотрение интернет-новостей в Аль-Джазире или RT? Своего рода пузырь уведомления на объеме загрузки был бы хорош.
- Почему? Мне не нужен ответ на тот вопрос. Другие 4 Вт будут достаточны. Это могло бы быть Хранилище 7, или это не могло бы быть. Вы не можете предъявить иск ЦРУ и если Вы не можете beat'em, необходимо просто заблокировать их.
Ежедневные интернет-привычки
Существует только шесть вещей, которые я ежедневно делаю в Интернете:
- Посещение Спрашивает Ubuntu и считало Q&As. Загрузки должны быть <1 МБ/день, потому что любой ответ, который я отправляю, - <30 КБ или обновление.
- Наблюдайте прямую телетрансляцию Al-Jazeera.com, которая использует HTML5 на youtube.com
- Смотрите rt.com/on-the-air, который использует Flash player
- Ежедневно копируйте мои сценарии, документы и конфигурационные файлы по электронной почте в мою учетную запись gmail.com, и .tar файл составляет 5,4 МБ.
- Смотрите кино на случайных веб-сайтах в разрешении на 1 080 пунктов, когда удачный, еще 480 пунктов или 720 пунктов, если не удачных.
- Поиск Google и посещает веб-сайты для исследования связанных с Linux/Ubuntu технических вопросов.
Сводка
Я знаком со Сдвигом + Esc в Chrome для контроля статистики сети в режиме реального времени Вкладкой Chrome, но что-то, что выполняет в фоновом режиме собирающие статистические данные, предпочтительно.
Я не запустил Windows 8.1 за хорошо более чем месяц, таким образом, загрузок не происходит там. Это - все в Linux/Ubuntu.
Что я могу сделать для сужения моего поиска крупных загрузок?
Спасибо за чтение настолько далеко.
2 ответа
Примечание: Этот ответ только обращается к некоторым желаемым, "Следственным 5W's Загрузок Данных".
Используйте tcpdump, чтобы получить весь пакетный трафик и использовать некоторую последующую обработку для извлечения желаемой информации.
sudo tcpdump -i enp4s0 -w 'ext-%F-%H-%M-%S.bin' -G 3600 -z /home/doug/bin/packet_post_processor2
Где:
мой интерфейс направления WAN enp4s0;
Имена файлов автоматически включают дату и время (требует дополнительного пакета, но я не могу вспомнить который);
Я прошу вращение файла однажды в час;
Каждый файл быть сообщением, обработанным packet_post_processor сценарий (2 для этого ответа).
Выполняющий последующую обработку сценарий:
#!/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.
C программу называют из сценария:
/*****************************************************************************
*
* 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:",
¤t_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 */
Обратите внимание, что некоторые файлы будут ударены со следующими часами, обрабатывая. Я зафиксирую это позже.
Быстрая сводка того, что делает выполняющий последующую обработку сценарий:
Во-первых, двоичный файл tcpdump файл преобразовывается в на пакетный сводный текст. Пример (мой адрес был изменен на 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
Это нарочно, что пакетная пара ARP включена в пример, так покажите что-то, что было бы исключено из последующей обработки.
Раздражающий пакет IGMP от частного IP LAN от моего ISP и будет также исключен из последующей обработки. Однако, если мой ISP когда-нибудь будет утверждать, что я пробежался через свой ежемесячный предел данных, то я укажу на такие пакеты, когда я скажу, за что я не заплачу. Заметьте две длины, показанные на каждой строке, первый является байтами на проводе, и второй является длиной полезной нагрузки. Мы хотим байты на проводе, и это - то, почему мы используем-e опцию с tcpdump.
Во-вторых, исходящий пакет может исключительно быть определен путем нахождения ": XXX.XXX.XXX.XXX". так извлеките все исходящие пакеты, не включая ARP и ICMP, с помощью grep.
В-третьих, используя пространство как разделитель, поле 13 является целевым IP-адресом, так используйте сложный набор переданных по каналу команд, чтобы извлечь, считать, и отсортировать целевые пакеты IP-адреса.
Forth, отсортируйте исходящие пакеты по целевому IP-адресу.
Пятый, используйте c программу, чтобы вычислить байты на IP и байты на IP/16 и отсортировать вывод в гистограммы.
Шестой, вручную исследуйте главные IP-адреса в попытке определить то, что продолжается. Обратите внимание, что очень часто можно найти связанное вперед поиском запрос DNS в выводе tcpdump.
Как пример, я посмотрел на свои данные WAN/LAN между 31.05.2017 8:09:33 и 09.08.2017 22:13:11 и отредактировал, в каком я нашел для различных IP-адресов.
Сначала вершина немногие количеством пакетов:
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)
Во-вторых, вершина немногие количеством байта:
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)
Заметьте, как, так как Netflix, например, использует много IP-адресов, он мог бы упасть ниже в рейтинге, чем это действительно должно быть, если бы все его IP-адреса рассматривали как один.
В-третьих, главные немного/16 групп количеством байтов. Заметьте, как Netflix является теперь крупнейшим:
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
Проблема сохраняется 7 января 2018 г. в Firefox
перейти к нижней части, «Изменить 6» , чтобы увидеть проблему только с Firefox
Проблема решена 13 декабря 2017 г.
перейти к нижней части, «Отредактируйте 5» , чтобы увидеть решение Chrome
Отвечая на 4 из 5 W
, я смог выделить, кто, что, куда и когда выгружаются данные:
- Who = rt.com / в эфире.
- What = плагин Flashplayer
- Где = в Google Chrome и Mozilla Firefox
- Когда = Утром и вечером, когда я смотрю международные новости
"Почему" может быть ошибкой, или это может быть шпионское ПО, или это может быть просто Flashplayer, настроенный для сбора информационных потоков для целей отчетов о сбоях.
В следующем разделе подробно описаны шаги по определению того, кто, что, где и когда.
Используйте vnstat -l для отслеживания загружаемого трафика.
Заранее приносим извинения за изображения экрана ниже, а не копирование и вставку текста. Я делал снимки, не зная, актуальна ли эта информация, до тех пор, пока не были сделаны все тесты.
Первый шаг в тестировании - закрыть все 10 вкладок Chrome и 3 вкладки Firefox.
Затем откройте терминал с помощью Ctrl + Alt + T и введите vnstat -l . Предполагается, что вы уже установили команду vnstat. Если нет, посмотрите этот ответ о vnstat в Ask Ubuntu.
Затем открывайте по одной вкладке Chrome или Firefox и отслеживайте уровень использования:
Просмотр 80-минутного документального фильма о ведущем певце / продюсере из ELO:
Контент в формате 720p.Один гигабайт загружен и 40 мегабайт выгружены - это 4% соотношение tx / rx и кажется нормальным.
Просмотр 5-минутной прямой трансляции новостей в формате Flashplayer с помощью Google Chrome:
Контент в формате 1080p. Было загружено 103,37 МБ, что нормально, но было загружено почти вдвое больше (192,62 МБ = 186%), что ненормально .
Просмотр 30 минут записанных новостей, которые можно загрузить из той же международной новостной компании:
Я много раз приостанавливал предварительно записанную загружаемую трансляцию на полчаса во время ее воспроизведения. Фактически затраченное время составило 72 минуты. Тем не менее, общее количество загрузок (они записаны с разрешением 720p) составляет 508,12 МБ, а количество загрузок - 21,63 МБ при соотношении tx / rx, равном 4%.
Сводка
Если вы не разработчик программного обеспечения, постоянно загружающий на github , или художник-фрилансер, постоянно загружающий вашу работу клиентам, нормальное соотношение TX / RX должно быть около 4% .
В этом случае ежемесячный учет в Интернете составлял 275,79 ГиБ загруженных и 70,54 ГиБ загруженных для соотношения tx / rx 26% . Виновником была прямая трансляция новостей Flashplayer, где соотношение tx / rx составляет 186% !
Параноидальные панды, живущие в бамбуковых лесах вокруг нас, могут подумать, что за этими большими загрузками стоит ЦРУ или АНБ. Думаю, это просто недостаток дизайна FlashPlayer.
Возможно, это могла быть российская телекомпания (RT), базирующаяся в Москве, использующая израильское программное обеспечение с ошибками.Я говорю это, потому что ранее обнаружил сбой на их новостном веб-сайте, когда раздел комментариев съедал 1 ГБ ОЗУ за несколько часов , пока вкладка не была обновлена. К сожалению, мои оригинальные вопросы и ответы, похоже, были удалены, но после публикации моих исходных вопросов и ответов здесь, в Австралии, кто-то прочитал его и устранил эту проблему. Надеюсь, похожие люди найдут эту ветку и исправят и эту проблему.
Это важно, потому что как потребители мы платим за просмотр СМИ. Мы не платим за то, чтобы то, что мы смотрим , загружалось с удвоенной пропускной способностью , чтобы «только Google знает где».
Правка - Тесты под ядром 4.12.10
Предыдущие тесты проводились под ядром 4.4.0-93 . Я только что установил ядро 4.12.10 , несколько раз перезагрузился и провел новые тесты. И для Firefox, и для Chrome результаты значительно улучшились, но соотношение tx / rx по-прежнему неприемлемо.
- Firefox в течение 5,33 минуты загружено 108,04 МБ и загружено 57,71 МБ при соотношении tx / rx 53,4%
- В Chrome за 5,57 минут загружено 117,34 МБ и загружено 59,75 МБ при соотношении tx / rx ] 50,9%
Собранные данные показаны ниже. В свете этих результатов я повторю тесты 4.4.0-93 после нескольких перезагрузок.
Firefox Flashplayer 5 минут живых новостей в 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 минут живых новостей в 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
Редактировать 2 - Чем больше вкладок вы открываете, тем хуже становится
Я был немного преждевременным с моим ядром версия 4.12.10 гипотеза.При дальнейшем расследовании просмотра прямой трансляции Flashplayer в Chrome с 6 открытыми вкладками соотношение tx / rx стало намного хуже. Я должен предположить, что каким-то образом Flashplayer собирает и передает данные для других вкладок, кроме своей собственной.
26-минутная прямая трансляция Flashplayer в Chrome с 5 открытыми другими вкладками:
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
Как и следовало ожидать, при разрешении 1080p общая загрузка составляет 718,79 МБ.Что шокирует, так это загруженные 1,13 ГиБ! Это дает отношение tx / rx 157% . Это приводит меня к выводу, мои результаты испытаний от 2 дней назад, и эти снимки экрана были мои обычные 10 вкладок Chrome и Firefox 3 вкладки открыты.
Следующий тест будет 7 открытых вкладок и делать нормальный серфинг / Задавайте вопросы и ответы Ubuntu в течение 1/2 часа и получить не-Flashplayer составляет только.
Редактировать 3 - Использование conky для мониторинга в реальном времени
Сначала результаты теста 7 открытых касаний, отвечая на вопрос Ubuntu (приведенный выше):
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
Затем тест с 7 открытыми вкладками, ничего не делая в течение 1/2 час на машине:
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
таким образом, мы можем видеть, даже когда ничего не происходит на вашей машине это нормально для Chrome для передачи пакетов, но размер маленький (529 KiB или так).
Conky text
Я добавил этот conky текст для отслеживания использования сети в реальном времени:
${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}
Conky display
Итоговые данные внизу указаны с момента последней загрузки, а не с момента включения conky.
Правка 4 - HTML5 не загружается, как Flashplayer
Я провел 27,5-минутный тест под ядром 4.12.10 канала новостей youtube.com в реальном времени (с 4-часовым сдвигом по времени) в разрешении 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 и загружено 19,49 MiB, что дает среднее соотношение tx / rx 4% . Этот тест был проведен с использованием браузера Chrome, но я ожидаю, что результаты браузера Firefox будут такими же. Поэтому можно с уверенностью предположить, что массовая загрузка данных ограничивается Flashplayer, а не HTML5.
Надеюсь, другие пользователи смогут протестировать мои выводы и прокомментировать их.
Тем временем я веду дискуссии с Дугом Смитисом (который разместил другой ответ здесь) в общем чате «Спросите Ubuntu» о его решении. Используя ответ Дуга, я надеюсь обнаружить физические IP-адреса, на которые собираются мои данные.
Редактировать 5 - 13 декабря 2017 - Проблема решена Ядро 4.14.4
За последние пару дней проблема исчезла сама по себе. Вероятно, обновление Flashplayer или обновление ядра:
- Скорость загрузки теперь составляет 8,33 МБ / 224,78 МБ = 4%
- Исправлена ошибка Chrome, из-за которой для увеличения экрана требовалось ~ 5 секунд
- Ошибка Chrome: изображение отставало примерно на 1 секунду голос исправлен
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
Примечание: В прошлом месяце я купил новый ноутбук, где проблема не исчезла. Однако в последние пару дней проблема исчезла сама по себе либо из-за обновления Chrome , версия 63.0.3239.84 (официальная сборка) (64-битная) , либо из-за того, что ядро 4.14.4 .
Редактировать 6 - 7 января 2018 г. - Проблема сохраняется Firefox версии 57.0.4
В последние пару дней у меня были проблемы с использованием Chrome, поэтому я начал использовать Firefox постоянно. Я также установил ядро 4.14.12 для тестирования исправлений ядра Meltdown:
- Скорость загрузки теперь составляет 254,76 МБ / 364,83 МБ = 70%
- Возникла ошибка Chrome, которая требовала ~ 5 секунд для увеличения экрана
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
Итак .... полный круг: (