每月互联网总带宽
我用来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 个月前更换了 ISP，新的 ISP 对每月总使用量非常挑剔，这导致我更加关注统计数据。
实时互联网使用情况
我检查了 Ask Ubuntu 中的监控选项，答案指出nethogs它只按进程报告 KB/Sec，而 Firefox 或 Chrome 都以 KB/Sec 为单位报告：
这没什么用，因为我已经知道我使用 Chrome 和 Firefox。问题是“哪个选项卡？”或者它甚至是一个选项卡？注意到有进程以 身份运行吗root？我从未在 Chrome 或 Firefox 中使用 sudo。
数据上传的调查 5W 原则
有 5 个 W：
- 谁每个月从我的笔记本电脑上传 70 GB 的数据？我每天都会将 5.4 MB 的脚本、文档、配置设置等备份到 gmail.com。每月 150 MB。谁拿走了剩下的 69 GB？
- 哪个程序正在抓取这些数据？我无法使用 Chrome 或 Firefox 的单个进程 ID 作为答案。我需要知道指向网站的标签。我无法使用
root一些随机 IP 地址作为答案。 - 这些数据要去哪里？即 IP 地址。
- 这是什么时候发生的？是在我看电影的时候吗？是在看半岛电视台或 RT 的网络新闻时吗？上传音量时有某种通知气泡就好了。
- 为什么？我不需要这个问题的答案。其他 4 个 W 就足够了。它可能是 Vault 7，也可能不是。你不能起诉 CIA，如果你不能打败他们，你就应该阻止他们。
日常上网习惯
我每天上网只做六件事：
- 访问 Ask Ubuntu 并阅读问答。上传量应小于 1 MB/天，因为我发布的任何答案都小于 30 KB 或更新。
- 在 youtube.com 上观看使用 HTML5 的 Al-Jazeera.com 直播电视
- 使用 Flash Player 观看 rt.com/on-the-air
- 每天通过电子邮件将我的脚本、文档和配置文件备份到我的 gmail.com 帐户，.tar 文件大小为 5.4 MB。
- 如果幸运的话，可以在随机网站上以 1080p 的分辨率观看电影，如果运气不好，则可以以 480p 或 720p 的分辨率观看电影。
- 通过 Google 搜索并访问网站来研究 Linux/Ubuntu 相关的技术问题。
概括
我熟悉使用Chrome 中的Shift+Esc通过 Chrome Tab 实时监控网络统计信息，但最好是在后台运行某些程序来收集统计信息。
我已有一个多月没有运行 Windows 8.1，因此无法上传。一切都在 Linux/Ubuntu 上进行。
我该怎么做才能缩小大量上传内容的搜索范围？
感谢您读到这里。
答案1
注意：此答案仅解决部分所需的“数据上传的调查 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://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 数据包，以便显示将被排除在进一步处理之外的内容。
来自私有 LAN IP 的烦人的 IGMP 数据包来自我的 ISP，也将被排除在进一步处理之外。但是，如果我的 ISP 声称我已超出每月数据限制，我会在说我不会支付费用时指出此类数据包。请注意每行显示的两个长度，第一个是线路上的字节数，第二个是有效载荷长度。我们想要线路上的字节数，这就是我们在 tcpdump 中使用 -e 选项的原因。
其次，可以通过查找“：XXX.XXX.XXX.XXX.”唯一地标识传出的数据包，因此使用 grep 提取所有传出的数据包（不包括 ARP 和 ICMP）。
第三，使用空格作为分隔符，字段 13 是目标 IP 地址，因此使用一组复杂的管道命令来提取、计数和排序目标 IP 地址数据包。
第四，按目标 IP 地址对传出的数据包进行排序。
第五，使用 c 程序计算每个 IP 的字节数和每个 IP/16 的字节数，并将输出排序为直方图。
第六，手动调查排名靠前的 IP 地址，以尝试确定发生了什么。请注意，通常可以在 tcpdump 输出中找到相关的正向查找 DNS 查询。
举个例子，我查看了 2017-05-31 08:09:33 至 2017-08-09 22:13:11 之间的 WAN/LAN 数据，并编辑了针对各个 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 地址视为一个 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
答案2
2018 年 1 月 7 日 Firefox 中的问题仍然存在
跳至底部，“编辑 6”只看到 Firefox 的问题
问题已解决 2017 年 12 月 13 日
跳至底部，“编辑 5”查看 Chrome 解决方案
回答 5W 问题中的 4 个
我能够隔离正在上传数据的人员、内容、地点和时间：
- WHO= rt.com/ 直播。
- 什么= Flashplayer 插件
- 在哪里= 在 Google Chrome 和 Mozilla Firefox 中
- 什么时候= 早上和晚上我看国际新闻
“为什么”可能是错误，可能是间谍软件，也可能只是 Flashplayer 已配置为收集信息流以用于崩溃报告目的。
下一节详细介绍了隔离谁、什么、哪里和何时的步骤。
用于vnstat -l跟踪上传流量
提前为下面的屏幕截图而不是文本复制粘贴道歉。我拍了快照，但直到所有测试完成后才知道这些信息是否相关。
测试的第一步是关闭所有 10 个 Chrome 标签和 3 个 Firefox 标签。
接下来使用 ++Ctrl打开终端并输入。这假设您已经安装了 vnstat 命令。如果没有，请参阅此AltTvnstat -l回答vnstat在 Ask Ubuntu 中了解详情。
然后一次打开一个 Chrome 或 Firefox 标签并监控使用率：
观看有关 ELO 主唱/制作人的 80 分钟纪录片：
内容为 720p 格式。下载 1 GB 并上传 40 MB 时，tx 与 rx 比率为 4%，看起来很正常。
使用 Google Chrome 观看 Flashplayer 格式的 5 分钟现场新闻广播：
内容为 1080p 格式。下载了 103.37 MiB，这很正常，但上传了几乎两倍的量（192.62 MiB = 186%），这不正常。
观看可从同一国际新闻广播公司下载的 30 分钟录制新闻：
我在播放半小时的预录可下载广播时多次暂停。实际用时为 72 分钟。尽管如此，总下载量（以 720p 录制）为 508.12 MiB，上传量为 21.63 MiB，发送与接收比率为 4%。
概括
除非你是一个不断向客户上传的软件开发人员，github或者是一个不断向客户上传作品的自由平面设计师，否则正常的 tx 与 rx 比率应该约为4%。
在这种情况下，每月的互联网计费为下载 275.79 GiB，上传 70.54 GiB，tx/rx 比率为26%罪魁祸首是 Flashplayer 直播新闻，其 tx/rx 比率为186%！
生活在我们周围竹林里的偏执熊猫可能会认为 CIA 或 NSA 是这些大量上传的幕后黑手。我认为这只是 FlashPlayer 的一个设计缺陷。
可能是俄罗斯广播公司（RT）位于莫斯科，它使用了以色列的软件，但存在故障。我之所以这么说，是因为我之前发现他们的新闻网站上有一个故障，评论部分会几个小时内消耗 1 GB 的 RAM直到刷新标签。不幸的是，我的原始问答似乎已被删除，但在 AU 上发布我的原始问答后，有人阅读了它并修复了这个问题。希望类似的人能找到这个帖子并修复这个问题。
这很重要，因为作为消费者，我们付钱手表媒体。我们不会为观看的内容付费。以两倍带宽上传改为“只有谷歌知道在哪里”。
编辑-内核 4.12.10 下的测试
之前的测试是在内核下进行的4.4.0-93。我全新安装了内核4.12.10，重启了几次，然后进行了新的测试。对于 Firefox 和 Chrome，结果都有了很大的改善，但 tx/rx 比率仍然不可接受。
- Firefox 在 5.33 分钟内下载了 108.04 MiB，上传了 57.71 MiB，tx/rx 比率为53.4％
- Chrome 在 5.57 分钟内下载了 117.34 MiB，上传了 59.75 MiB，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。经过进一步调查，在 Chrome 中观看 Flashplayer 直播时打开了 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 MiB，这在意料之中。令人震惊的是上传量只有 1.13 GiB！这给出了 tx/rx 比率157%。这让我得出两天前的测试结果，那些屏幕快照中我通常打开了 10 个 Chrome 标签页和 3 个 Firefox 标签页。
下一个测试将打开 7 个标签并进行正常浏览 / 询问 Ubuntu 问题和答案半小时，并仅获取非 Flashplayer 总数。
编辑 3-使用 conky 进行实时监控
首先是回答 Ubuntu 问题（上面的问题）的 7 次点击测试结果：
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 个选项卡，半小时内不做任何操作：
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 文本
我添加了这个 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 那样上传
我在内核 4.12.10 下对 youtube.com 直播新闻频道（时差 4 小时）进行了 27.5 分钟的测试，分辨率为 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。
希望其他用户可以测试以确认我的发现并在下面发表评论。
与此同时，我在 Ask Ubuntu 通用聊天室与 Doug Smythies（他在这里发布了另一个答案）讨论他的解决方案。使用 Doug 的答案，我希望发现我的数据要发送到的物理 IP 地址。
编辑 5 - 2017 年 12 月 13 日 - 问题已解决 内核 4.14.4
在过去的几天里，问题已经自行消失。可能是 Flashplayer 更新或内核更新：
- 上传速率现在为 8.33 MiB / 224.78 MiB = 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 - 2018 年 1 月 7 日 - 问题仍然存在 Firefox 版本 57.0.4
在过去的几天里，我在使用 Chrome 时遇到了问题，因此开始全职使用 Firefox。我还安装了内核4.14.12来测试 Meltdown 内核补丁：
- 上传速率现在为 254.76 MiB / 364.83 MiB = 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
那么... 圆满结束 :(