1
我有一個HTTP線程代理，即從客戶的每個請求我產生一個線程統計：現在我想收集一些統計像每秒（PPS）比特每秒（BPS）和包。使用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中的移位，但是我要反正報告它。他說的話基本上
，我所做的一切：在這裏你可以看到的功能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被接受PKTS -9153173178195537408及接受BITS -2444556543073261568 PER DELAY 1479847752267586 IS PPS -6185與BPS -1651 www.youtube.com DOWNLOAD DIVIDE ACCEPTED PKTS -9153173178195537408 AND ACCEPTED BITS -2444556543073261568 PER DELAY 2745 IS PPS -3334489318104020與BPS -890548831720678 www.youtube.com UPLOAD DIVIDE ACCEPTED PKTS -1866508824056485888 AND接受位-2458024441489261568 PER DELAY 1479847752270362是PPS -1261和BPS -1660'和s o on ... – elmazzun
請檢查我的編輯 –