当我实际上没有上传太多时，为什么互联网上传如此之高？

每月互联网带宽总量

我使用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 ，它们只按流程报告KB /秒，这些流程不可避免地以KB /秒为单位报告Firefox或Chrome：

这没有用，因为我已经知道我使用的是Chrome和Firefox。 问题是“哪个标签？” 或者它甚至是一个标签？ 请注意，有进程以root身份运行？ 我从不在Chrome或Firefox上使用sudo。

调查5W的数据上传

有5个W：

• 谁每月从我的笔记本电脑上传70 GB的数据？ 我每天备份到gmail.com，这是5.4 MB的脚本，文档，配置设置，什么不是。 这是每月150 MB。 谁抓住其他69 GB？
• 什么程序正在抓取这些数据？ 我无法使用Chrome或Firefox的单个进程ID作为答案。 我需要知道指向该网站的标签。 我不能使用root和一些随机IP地址作为答案。
• 这些数据在哪里？ 即IP地址。
• 这是什么时候发生的？ 我在看电影的时候吗？ 在Al-Jazeera或RT观看互联网新闻？ 上载量上的某种通知泡沫会很好。
• 为什么？ 我不需要回答这个问题。 其他4 W就足够了。 它可能是Vault 7，也可能不是。 你不能起诉中央情报局，如果你不能击败你，你应该阻止他们。

每日上网习惯

我每天只在互联网上做六件事：

• 访问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。
• 谷歌搜索和访问网站，以研究Linux / Ubuntu相关的技术问题。

摘要

我熟悉Chrome中的Shift + Esc ，可以通过Chrome Tab实时监控网络统计信息，但最好在后台收集统计信息。

我有一个多月没有运行Windows 8.1，所以上传不会发生在那里。 这一切都在Linux / Ubuntu中。

我可以做些什么来缩小搜索大量上传的范围？

感谢您阅读此内容。

Answer 1

注意：此答案仅解决了一些所需的“Investigative 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.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 ac program. ./tcpdump_bytes outgoing.srt outb.txt out16.txt sort --general-numeric-sort outhistob.txt sort --general-numeric-sort 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, * ie 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  #include  #include  #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 */ 

请注意，一些文件将在接下来的几小时处理中被破坏。 我稍后会解决这个问题。

快速总结后处理脚本的作用：
首先，将二进制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 

Answer 2

问题在2018年1月7日在Firefox中持续存在

跳到底部， “编辑6”以查看Firefox唯一的问题

问题已于2017年12月13日解决

跳到底部， “编辑5”以查看Chrome解决方案

回答5 W中的4个

我能够隔离数据上传的Who，What，Where和When：

• Who = rt.com /直播。
• 什么 = Flashplayer插件
• Where =在Google Chrome和Mozilla Firefox中
• 当我看国际新闻时 =早晨和晚上

“为什么”可能是一个错误，也可能是间谍软件，或者可能只是Flashplayer已被配置为收集信息流以进行崩溃报告。

下一节将详细介绍隔离Who，What，Where和When的步骤。

使用vnstat -l跟踪上传流量

提前为下面的屏幕图像道歉，而不是文本复制和粘贴。 在完成所有测试之前，我拍摄的快照不知道信息是否相关。

测试的第一步是关闭所有10个Chrome标签和3个Firefox标签。

接下来使用Ctrl + Alt + T打开终端并键入vnstat -l 。 假设您已经安装了vnstat命令。 如果没有，请在Ask Ubuntu中查看关于vnstat 答案 。

然后一次打开一个Chrome或Firefox标签并监控使用率：

观看ELO主唱/制作人的80分钟纪录片：

内容采用720p格式。 下载1千兆字节和上传40兆字节是4％tx到rx的比率，看起来很正常。

使用Google Chrome观看Flashplayer格式的5分钟直播新闻：

内容采用1080p格式。 103.37 MiB是下载的，这是正常的但几乎是上传量的两倍（192.62 MiB = 186％），这是不正常的 。

观看可从同一国际新闻广播机构下载的30分钟录制新闻：

我在播放时多次暂停了半小时预先录制的可下载广播。 经过的时间实际上是72分钟。 尽管如此，总下载量（以720p记录）为508.12 MiB，上传量为21.63 MiB，tx与rx之比为4％。

摘要

除非您是不断上传到github或自由图形艺术家的软件开发人员不断将您的工作上传到客户端，否则正常的tx与rx之比应该约为4％ 。

在这种情况下，每月互联网会计下载275.79 GiB，上传70.54 GiB，tx / rx比率为26％ 。 罪魁祸首是Flashplayer直播新闻广播，其中tx / rx比率为186％ ！

生活在我们周围的竹林中的偏执pandas可能会认为CIA或NSA是这些大型上传的背后。 我认为这只是FlashPlayer中的一个设计缺陷。

也许是莫斯科的俄罗斯广播公司（RT）使用以色列软件出现故障。 我这样说是因为我之前在他们的新闻网站上发现了一个小故障，评论部分会在几个小时内占用1 GB的RAM，直到标签刷新为止。 不幸的是，我的原始问答似乎已被删除，但在AU发布我原来的问答后，有人阅读并解决了这个问题。 希望类似的人会找到这个线程并解决这个问题。

这很重要，因为作为消费者，我们付钱观看媒体。 我们没有付费将我们观看的内容以两倍的带宽上传到“只有Google知道在哪里”。

---

编辑 – 内核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在1080p的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 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在1080p播出5分钟直播新闻：

 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浏览器中观看Flash播放器直播，有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％ 。 这导致我从2天前结束我的测试结果，那些屏幕快照有我常用的10个Chrome标签和3个Firefox标签打开。

接下来的测试将是7个标签打开并正常冲浪/询问Ubuntu问题和答案半小时并且仅获得非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个标签的测试打开半小时：

 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左右）。

坚定的文字

我添加了这个简洁的文本来监控网络实时使用情况：

 ${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那样上传

我在1080p的youtube.com直播新闻频道（时间为4小时）的内核4.12.10下进行了27.5分钟的测试：

 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 General Chat Room与Doug Smythies（他在此发布其他答案）讨论他的解决方案。 使用Doug的答案，我希望发现我的数据将要发送的物理IP地址。

---

编辑5 – 2017年12月13日 – 问题解决了内核4.14.4

在过去的几天里，问题已经消失了。 可能是Flashplayer更新或内核更新：

• 上传率现在是8.33 MiB / 224.78 MiB = 4％
• 花费约5秒钟来最大化屏幕的Chrome错误是固定的
• 图像的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％
• 花了〜5秒钟来最大化屏幕的Chrome bug回来了

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 

所以….完整的圆圈:(