Почему загрузка интернета так высока, когда я загружаю немного?
Общая месячная пропускная способность интернета
я использую 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 / --
Я переключил интернет-провайдеров 6 месяцев назад, и новый интернет-провайдер требователен к общему ежемесячному использованию, что заставляет меня уделять больше внимания статистике.
Интернет в реальном времени
Я проверил параметры мониторинга в Ask Ubuntu, и ответы указывают на nethogs который сообщает только КБ / с по процессу, который неизбежно означает, что Firefox или Chrome оба сообщают в КБ / с:
Это не полезно, потому что я уже знаю, что я использую Chrome и Firefox. Вопрос в том, "какая вкладка?" или это даже вкладка? Обратите внимание, что процессы выполняются как root? Я никогда не использую sudo с Chrome или Firefox.
Следственные 5W загрузки данных
Есть 5 W:
- Кто загружает 70 ГБ данных с моего ноутбука каждый месяц? Я делаю резервное копирование ежедневно на gmail.com, который составляет 5,4 МБ скриптов, документов, настроек конфигурации, а что нет. Это 150 МБ в месяц. Кто захватывает остальные 69 ГБ?
- Какая программа захватывает эти данные? Я не могу использовать один идентификатор процесса для Chrome или Firefox в качестве ответа. Мне нужно знать вкладку, которая указывает на сайт. Я не могу использовать
rootи какой-то случайный IP-адрес в качестве ответа. - Куда идут эти данные? т.е. IP-адрес.
- Когда это происходит? Это когда я смотрю фильм? Смотря новости в интернете в Аль-Джазире или РТ? Какой-то пузырь уведомлений о загрузке будет неплохо.
- Зачем? Мне не нужен ответ на этот вопрос. Другие 4 W будет достаточно. Это может быть Vault 7 или нет. Вы не можете подать в суд на ЦРУ, и если вы не можете победить их, вы должны просто заблокировать их.
Ежедневные интернет-привычки
В Интернете я делаю только шесть вещей:
- Посетите Ask Ubuntu и прочитайте Q&As. Загрузка должна быть <1 МБ / день, потому что любой ответ, который я публикую, составляет < 30 КБ или обновление.
- Смотрите Al-Jazeera.com в прямом эфире, который использует HTML5 на youtube.com
- Смотрите rt.com/on-the-air, который использует Flash Player
- Ежедневно делайте резервные копии моих скриптов, документов и файлов конфигурации по электронной почте на мою учетную запись gmail.com, а размер файла.tar составляет 5,4 МБ.
- Посмотрите фильм на случайных веб-сайтах в разрешении 1080p, если вам повезет, иначе - 480p или 720p, если вам не повезет.
- Поиск в Google и посещение веб-сайтов для изучения технических проблем, связанных с Linux/Ubuntu.
Резюме
Я знаком с Shift + Esc в Chrome, чтобы отслеживать сетевую статистику в режиме реального времени с помощью Chrome Tab, но то, что работает в фоновом режиме, собирает статистику предпочтительнее.
Я не запускал Windows 8.1 более месяца, так что загрузки там не происходит. Это все в Linux/Ubuntu.
Что я могу сделать, чтобы сузить свой поиск массовых загрузок?
Спасибо, что прочитали это далеко.
2 ответа
Примечание. В этом ответе рассматриваются только некоторые из желаемых "Исследовательских 5W загрузок данных".
Используйте 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://Ask-ubuntu.ru/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-адреса частной локальной сети получен от моего интернет-провайдера и также будет исключен из дальнейшей обработки. Однако, если мой провайдер когда-нибудь заявит, что я превысил мой месячный лимит данных, я укажу на такие пакеты, когда скажу, что я не буду платить. Обратите внимание на две длины, показанные в каждой строке: первая - это байты на проводе, а вторая - длина полезной нагрузки. Нам нужны байты в проводнике, и поэтому мы используем опцию -e с tcpdump.
Во-вторых, исходящий пакет может быть однозначно идентифицирован путем нахождения ": XXX.XXX.XXX.XXX.", Поэтому извлеките все исходящие пакеты, кроме ARP и ICMP, используя grep.
В-третьих, используя пробел в качестве разделителя, поле 13 является IP-адресом назначения, поэтому используйте сложную группу переданных команд для извлечения, подсчета и сортировки пакетов IP-адресов назначения.
Далее сортируйте исходящие пакеты по IP-адресу назначения.
В-пятых, используйте программу c для вычисления байтов на IP и байтов на IP/16 и сортировки выходных данных в гистограммы.
В-шестых, вручную исследуйте верхние IP-адреса в попытке определить, что происходит. Обратите внимание, что очень часто можно найти соответствующий DNS-запрос прямого просмотра в выводе tcpdump.
В качестве примера я посмотрел на свои данные WAN/LAN между 2017-05-31 08:09:33 и 2017-08-09 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
Мне удалось определить, кто, что, где и когда загружает данные:
- Кто = rt.com / в эфире.
- Что = плагин 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 загруженных мегабайт имеют соотношение tx к rx 4% и выглядят нормальными.
Просмотр 5 -минутной прямой трансляции новостей в формате Flashplayer с помощью Google Chrome:
Контент в формате 1080p. Было загружено 103,37 МБ, что является нормальным, но почти в два раза больше (192,62 МБ = 186%), что не является нормальным.
Просмотр 30 минут записанных новостей, загружаемых с того же международного вещателя новостей:
Я приостанавливал предварительно записанную загружаемую трансляцию 1/2 часа много раз, пока она воспроизводилась. Прошедшее время фактически составило 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 ГБ ОЗУ за несколько часов до обновления вкладки. К сожалению, мои первоначальные вопросы и ответы, кажется, были удалены, но после публикации моих первоначальных вопросов и ответов здесь, в AU, кто-то прочитал их и исправил эту проблему. Надеюсь, что подобные люди найдут эту ветку и исправят эту проблему.
Это важно, потому что мы, как потребители, платим за просмотр СМИ. Мы не платим за загрузку того, что мы смотрим, с удвоенной пропускной способностью, чтобы "только 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 МБ для коэффициента передачи / 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 каким-то образом собирает и передает данные для других вкладок, кроме своей.
Прямая трансляция Chrome с 26 -минутным Flashplayer с 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 и 3 вкладки Firefox.
Следующий тест будет состоять из 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 КиБ или около того).
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 дисплей
Итоги внизу указаны с момента последней загрузки, а не с момента включения conky.
Редактировать 4 - HTML5 загружается не так, как Flashplayer
Я выполнил 27,5 -минутный тест под Kernel 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 МиБ было загружено и 19,49 МиБ было загружено, что дало среднее соотношение tx/rx 4%. Этот тест был выполнен с использованием браузера Chrome, но я ожидаю, что результаты браузера Firefox будут такими же. Поэтому можно предположить, что массовые загрузки данных ограничены Flashplayer, а не HTML5.
Надеемся, что другие пользователи могут проверить, чтобы подтвердить мои выводы и комментарии ниже.
Тем временем я проводил обсуждения с Дагом Смитисом (который разместил другой ответ здесь) в Общем чате Ask Ubuntu по поводу его решения. Используя ответ Дуга, я надеюсь узнать физические IP-адреса, на которые будут отправляться мои данные.
Редактировать 5 - 13 декабря 2017 - Проблема решена Ядро 4.14.4
В последние пару дней проблема ушла сама собой. Вероятно, обновление Flashplayer или обновление ядра:
- Коэффициент загрузки теперь 8,33 МиБ / 224,78 МиБ = 4%
- Исправлена ошибка Chrome, длившая ~5 секунд для увеличения экрана
- Исправлена ошибка Chrome изображения, находящегося ~1 секунда за голосом
Результаты vnstat -l
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 - Янв 07 2018 - Проблема сохраняется Firefox версии 57.0.4
В последние пару дней у меня были проблемы с использованием Chrome, поэтому я начал использовать Firefox на полную ставку. Я также установил ядро 4.14.12 проверить исправления ядра Meltdown:
- Коэффициент загрузки теперь 254,76 МиБ / 364,83 МиБ = 70%
- Возникла ошибка Chrome: ~5 секунд, чтобы развернуть экран
Результаты vnstat -l
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
Итак.... полный круг:(