実際にあまりアップロードしないのに、なぜインターネットアップロードがそれほど高いのですか？
毎月のインターネット帯域幅の合計
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は毎月の合計使用量にこだわりがあり、統計に注意を払っています。
リアルタイムのインターネット利用
私はUbuntuの監視オプションをチェックし、答えはnethogsを指します。これはプロセスごとにKB /秒のみを報告します。これは必然的にFirefoxまたはChromeの両方がKB /秒で報告されます。
ChromeとFirefoxを使用していることが既にわかっているため、これは役に立ちません。質問は「どのタブ？」です。それともタブですか？ rootとして実行されているプロセスがあることに注意してください。 SudoをChromeまたはFirefoxで使用することはありません。
データアップロードの調査5W
5つのWがあります。
- 毎月私のラップトップから70 GBのデータをアップロードしているのは誰ですか？私は毎日5.4 MBのスクリプト、ドキュメント、構成設定などのgmail.comにバックアップしています。 1か月あたり150 MBです。他の69 GBを取得しているのは誰ですか？
- どのプログラムがこのデータを取得していますか？ ChromeまたはFirefoxに単一のプロセスIDを回答として使用することはできません。ウェブサイトを指すタブを知る必要があります。
rootとランダムなIPアドレスを回答として使用することはできません。 - このデータはどこに行きますか？すなわち、IPアドレス。
- これはいつ発生しますか？映画を見ているときですか？アルジャジーラまたはRTでインターネットニュースを見ていますか？アップロード量に関する何らかの通知バブルがいいでしょう。
- どうして？その質問に答える必要はありません。他の4 Wで十分です。 Vault 7である場合とそうでない場合があります。あなたはCIAを訴えることはできません。もしあなたが彼らを打ち負かすことができないならば、あなたはそれらを単にブロックすべきです。
毎日のインターネット習慣
インターネットで毎日やることは6つだけです。
- Ask Ubuntuにアクセスして、Q＆Aを読んでください。アップロードする回答は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関連の技術的な問題を調査します。
概要
私はよく知っています Shift + Esc in Chrome Chromeでリアルタイムでネットワーク統計を監視しますが、統計を収集するバックグラウンドで実行されるものが望ましいです。
1か月以上もWindows 8.1を実行していないので、アップロードは行われません。すべてLinux/Ubuntuにあります。
大量のアップロードの検索を絞り込むにはどうすればよいですか？
ここまで読んでくれてありがとう。
注：この回答は、「調査対象の5Wのデータアップロード」の一部のみを対象としています。
Tcpdumpを使用してすべてのパケットトラフィックをキャプチャし、後処理を使用して必要な情報を抽出します。
Sudo tcpdump -i enp4s0 -w 'ext-%F-%H-%M-%S.bin' -G 3600 -z /home/doug/bin/packet_post_processor2
どこ：
my WANインターフェイスはenp4s0;です。
ファイル名には自動的に日付と時刻が含まれます（追加のパッケージが必要ですが、どのパッケージを思い出せません）。
1時間に1回ファイルのローテーションを要求しています。
各ファイルは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が毎月のデータ制限を超えたと主張する場合は、支払わないことを言うときにそのようなパケットを指し示します。各行に2つの長さが表示されていることに注意してください。最初の長さはワイヤ上のバイトで、2番目の長さはペイロードの長さです。ワイヤ上にバイトが必要です。このため、tcpdumpで-eオプションを使用します。
次に、「：XXX.XXX.XXX.XXX。」を見つけることで発信パケットを一意に識別できるため、grepを使用して、ARPおよびICMPを除くすべての発信パケットを抽出します。
第3に、スペースを区切り文字として使用する場合、フィールド13は宛先IPアドレスです。したがって、複雑な一連のパイプコマンドを使用して、宛先IPアドレスパケットを抽出、カウント、およびソートします。
4番目に、送信パケットを宛先IPアドレスでソートします。
第5に、cプログラムを使用して、IPあたりのバイト数とIP/16あたりのバイト数を計算し、出力をヒストグラムにソートします。
第6に、何が起こっているのかを特定するために、上位の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アドレスが1つとして扱われた場合、実際よりもランキングが低くなることに注意してください。
第三に、バイト数による上位数/ 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
Firefoxで問題が2018年1月7日まで続く
下にスキップ、"Edit 6" Firefoxのみの問題を表示
2017年12月13日に解決された問題
下にスキップ、"Edit 5" Chromeソリューションを見る
5つのWのうち4つに答える
データが誰、何、どこで、いつアップロードされているかを分離できました。
- Who = rt.com/on-the-air。
- What = Flashplayerプラグイン
- Where = Google ChromeおよびMozilla Firefoxで
- When =国際ニュースを見る朝と夕方
「理由」はバグかもしれませんし、スパイウェアかもしれませんし、単にクラッシュレポートのために情報ストリームを収集するようにFlashplayerが設定されているかもしれません。
次のセクションでは、Who、What、Where、およびWhenを分離する手順について詳しく説明します。
vnstat -lを使用して、アップロードトラフィックを追跡します
テキストをコピーして貼り付けるのではなく、下の画面画像について事前におApび申し上げます。すべてのテストが完了するまで、情報が関連しているかどうかわからないスナップショットを撮りました。
テストの最初のステップは、10個のChromeタブと3個のFirefoxタブをすべて閉じることです。
次に、ターミナルを開きます Ctrl + Alt + T vnstat -lと入力します。これは、vnstatコマンドがすでにインストールされていることを前提としています。そうでない場合は、Ask Ubuntuのこの answer about vnstatを参照してください。
次に、ChromeまたはFirefoxタブを1つずつ開き、使用率を監視します。
ELOのリードシンガー/プロデューサーに関する80分のドキュメンタリーを見る：
コンテンツは720p形式です。 1ギガバイトのダウンロードと40メガバイトのアップロードは4％のTXとRXの比率であり、正常に見えます。
Google Chromeを使用してFlashplayer形式で5分間のライブニュース放送を視聴する：
コンテンツは1080p形式です。 103.37 MiBがダウンロードされましたが、これは通常ですが、その2倍近く（192.62 MiB = 186％）がアップロードされました。これはnot normalです。
同じ国際ニュース放送局からダウンロード可能な30分間の録画ニュースを見る：
再生中に、事前に記録された30分ダウンロード可能なブロードキャストを何度も一時停止しました。経過時間は実際には72分でした。それでも、合計ダウンロード数（720pで記録される）は508.12 MiBであり、tx対rxの比率が4％の場合、アップロードは21.63 MiBです。
概要
あなたがgithubに絶えずアップロードするソフトウェア開発者、またはクライアントに作品を絶えずアップロードするフリーランスのグラフィックアーティストでない限り、通常のtx to rx比は約4％である必要があります。
この場合、月次インターネットアカウンティングは275.79 GiBがダウンロードされ、70.54 GiBがアップロードされました。tx/ rx比は26％です。犯人は、tx/rx比が186％！であるFlashplayerライブニュース放送でした。
私たちの周りの竹林に住むパラノイアpandasは、CIAまたはNSAがこれらの大きなアップロードの背後にあると考えるかもしれません。 FlashPlayerの設計上の欠陥に過ぎないと思います。
おそらく、モスクワに本拠を置くロシアの放送局（RT）が、イスラエルのソフトウェアに不具合を使用している可能性があります。コメントセクションが 数時間で1 GBのRAMを消費する タブが更新されるまで、ニュースWebサイトで以前に不具合を発見したからです。残念ながら、元のQ＆Aは削除されたようですが、ここに元のQ＆AをAUに投稿した後、誰かがそれを読んでその問題を修正しました。同様の人がこのスレッドを見つけて、この問題も解決することを願っています。
消費者としてwatch mediaに支払うため、これは重要です。私たちが見ているものにお金を払っていません帯域幅の2倍でアップロードに「Googleだけがどこを知っているか」に。
編集-カーネル4.12.10でのテスト
以前のテストは、カーネル4.4.0-93の下で実施されました。カーネル4.12.10を新たにインストールし、数回再起動して新しいテストを実施しました。 FirefoxとChromeの両方で結果は大幅に改善されましたが、それでもtx/rx比は許容できません。
- 5.33分間のFirefoxでは、108.04 MiBがダウンロードされ、57.71 MiBがアップロードされ、tx/rx比が53.4％になります。
- 5.57分間のChromeでは、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
1080pのChrome Flashplayer 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仮説が少し早すぎました。 6個のタブを開いたChromeでFlashplayerのライブブロードキャストを見ると、tx/rx比がさらに悪化しました。どういうわけかFlashplayerは、それ以外のタブのデータを収集して送信していると推測する必要があります。
他の5つのタブが開いているChrome 26分間のFlashplayerライブブロードキャスト：
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の質問と回答を30分間行い、Flashプレーヤー以外の合計のみを取得します。
編集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
次に、マシン上で1/2時間、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テキストを追加しました。
${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がオンになってからではなく、最後のブートからのものです。
編集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ブラウザーの結果は同じになると思います。したがって、大量のデータのアップロードはHTML5ではなくFlashplayerに限定されると想定しても安全です。
うまくいけば、他のユーザーが私の調査結果を確認するためにテストし、以下にコメントできることを願っています。
それまでの間、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のバグが修正されました
- 画像の音声が約1秒遅れるというChromeのバグが修正されました
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
注：先月、問題が解決しない新しいラップトップを手に入れました。ただし、最後の2日間で、問題はChrome更新バージョン63.0.3239.84（公式ビルド）（64ビット）および/またはKernel 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のバグが復活しました
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
だから....完全な円:(