1
私はHTTPのスレッドプロキシを使用しています。つまり、クライアントからのリクエストごとにスレッドを生成します：今はビット/秒（bps）やパケット/秒（pps）libpcapを使用して接続に関する統計を収集する
スレッドは接続を処理する場合、すべてのパケットに対してbpsとppsを計算しません。これを別のスレッドに残します。
クライアントからのHTTP要求ごとにスレッドを作成し、プロキシが要求されたリモートサーバに正常に接続した場合、proxtは実際のHTTP要求をサーバに送信し、データをルーティングする前に接続スレッドはログスレッドを作成します：接続がオープンになるまでbpsとppsを計算します。接続スレッドは、どのパケットをフィルタリングするか（ローカルIPアドレス、ローカルポート、リモートIPアドレス、リモートポート）についてログスレッドに通知します。したがって、すべてのログスレッドは親接続スレッドからのパケットのみをフィルタリングします。
パケットごとにbpsとppsを計算する際に問題が発生しています。ここで
は、ロギング、スレッド内のパケットの私のループ・キャプチャーの擬似コードです：
// pcap variables
pcap_t *handle;
struct pcap_pkthdr *header;
const u_char *pkt_data;
// timevals used to calculate delay from last filtered packet
struct timeval oldTimevalUpload;
struct timeval oldTimevalDownload;
memset(&oldTimevalUpload, 0, sizeof(oldTimevalUpload));
memset(&oldTimevalDownload, 0, sizeof(oldTimevalDownload));
// stopLogging is a boolean flag declared in connection "parent" thread:
// it is set to false when connection thread has done sending and
// receiving data and connection is going to be closed
while (((res = pcap_next_ex(handle, &header, &pkt_data)) >= 0) && (!stopLogging)) {
// check res
if (packet is upload) {
struct timeval difference;
timeval_subtract(&difference, &(header->ts), &oldTimevalUpload);
long long delay = (difference.tv_sec * 1000000) + difference.tv_usec;
long long acceptedPackets = ((long long)(pkt_data)) * 1000000;
long long acceptedBits = ((long long)(pkt_data+8)) * 8 * 1000000;
long long pps = acceptedPackets/delay;
long long bps = acceptedBits/delay;
debugRed(host << ", UPLOAD DIVIDE ACCEPTED PKTS " << acceptedPackets <<
" AND ACCEPTED BITS " << acceptedBits << " PER DELAY " << delay <<
" IS PPS " << pps << " AND BPS " << bps);
oldTimevalUpload.tv_sec = header->ts.tv_sec;
oldTimevalUpload.tv_usec = header->ts.tv_usec;
} else if (packet is download) {
// basically the same as above
}
}
debug("Quit logging connection " << localIPaddr << ":" << localPort << " and "
<< remoteIPaddr << ":" << remotePort);
pcap_close(handle);
そしてここでは、サンプル出力です：
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 1479811349890053 IS PPS 0 AND BPS 0
www.netflix.com DOWNLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 1479811350032141 IS PPS 0 AND BPS 0
www.netflix.com DOWNLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 4344 IS PPS 22845174953 AND BPS 182761414364
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 146464 IS PPS 677568822 AND BPS 5420551015
www.netflix.com DOWNLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 2815 IS PPS 35253797513 AND BPS 282030402841
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 2808 IS PPS 35341680911 AND BPS 282733470085
www.netflix.com DOWNLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 1120 IS PPS 88606642857 AND BPS 708853200000
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 1134 IS PPS 87512733686 AND BPS 700101925925
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 39658 IS PPS 2502381360 AND BPS 20019052498
www.netflix.com DOWNLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 176317 IS PPS 562846690 AND BPS 4502773890
www.netflix.com UPLOAD, DIVIDE ACCEPTED PKTS 99239440000000 AND ACCEPTED BITS 793915584000000 PER DELAY 136687 IS PPS 726034224 AND BPS 5808274261
私は、私のホームネットワークが500 MBps以上に耐えられる知っていたことはありません何かが間違っているはずです。
This pageは、bpsとppsを計算する方法を示しており、acceptedBitsに8 charsのシフトを説明していますが、とにかくそれを報告します。ここでは、機能pcap_next_exの第二と第三のパラメータを見ることができます：
基本的に、私は彼が言ったことをすべてやりました！なぜ私は大きくて奇妙なbpsとppsになるのですか？
Ubuntuで作業する14.04; libpcapバージョンを確認する方法を知っているが、locate libpcapはこれを与えないでください：あなたのコードで
/home/dexter/Desktop/wireshark-1.99.9/wiretap/libpcap.c
/home/dexter/Desktop/wireshark-1.99.9/wiretap/libpcap.h
/usr/lib/x86_64-linux-gnu/libpcap.a
/usr/lib/x86_64-linux-gnu/libpcap.so
/usr/lib/x86_64-linux-gnu/libpcap.so.0.8
/usr/lib/x86_64-linux-gnu/libpcap.so.1.5.3
/usr/share/doc/libpcap-dev
/usr/share/doc/libpcap0.8
/usr/share/doc/libpcap0.8-dev
/usr/share/doc/libpcap-dev/changelog.Debian.gz
/usr/share/doc/libpcap-dev/copyright
/usr/share/doc/libpcap0.8/CREDITS.gz
/usr/share/doc/libpcap0.8/README.Debian
/usr/share/doc/libpcap0.8/README.gz
/usr/share/doc/libpcap0.8/changelog.Debian.gz
/usr/share/doc/libpcap0.8/copyright
/usr/share/doc/libpcap0.8-dev/changelog.Debian.gz
/usr/share/doc/libpcap0.8-dev/copyright
/var/lib/dpkg/info/libpcap-dev.[list,md5sums]
/var/lib/dpkg/info/libpcap0.8-dev.[list,md5sums,preinst]
/var/lib/dpkg/info/libpcap0.8:amd64.[list,md5sums,postinst,postrm,shlibs,symbols]
私はあなたのアドバイスに従っ：今私は、負の数のXD 'www.youtube.comダウンロードDIVIDE ACCEPTED PKTS -9153173178195537408、受け入れBITS -2444556543073261568 DELAY PERを持っています1479847752267586はDELAY 2745 PER -2444556543073261568 PPS -6185と-1651 BPS www.youtube.comダウンロードDIVIDE ACCEPTED PKTS -9153173178195537408、受け入れBITS PPS -3334489318104020とBPS -890548831720678 www.youtube.com UPLOADのDIVIDE ACCEPTED PKTS IS IS -1866508824056485888と受け入れられたビット-2458024441489261568 PER DELAY 1479847752270362 IS PPS -1261 AND BPS -1660'およびs o on ... – elmazzun
私の編集を確認してください –