Określanie aktywności/statystyk obciążenia TCP

Question

Chciałbym wyszukać licznik aktywności ładunku TCP (całkowita liczba bajtów odebranych) dla danego deskryptora pliku lub danego interfejsu. Najlepiej dany deskryptor pliku, ale dla interfejsu wystarczy. Idealnie chciałbym wiedzieć o wszelkich bajtach, które zostały potwierdzone, nawet te, których nie przeczytałem w przestrzeni użytkownika (jeszcze?).

Widziałem funkcję TCP_INFO z getsockopt(), ale żadne z pól nie zawiera zapisu "Całkowita liczba bajtów odebranych" lub "Całkowita liczba przesłanych bajtów (potwierdzonych, np.)", O ile wiem.

Ja również widziałem netlinkIFLA_STATS + RTNL_TC_BYTES i (pole rx_bytes) SIOCETHTOOL + ETHTOOL_GSTATSioctl() dla interfejsów, a te są świetne, ale nie sądzę, że będą w stanie rozróżniać między napowietrznej/nagłówki pozostałych warstw i rzeczywiste bajty ładunku.

procfs ma /proc/net/tcp ale wydaje się, że nie zawiera również tego, czego szukam.

Czy istnieje sposób na uzyskanie tych konkretnych danych?

EDYCJA: tryb promiscuous ma niewiarygodny wpływ na przepustowość, więc nie mogę wykorzystać niczego, co go wykorzystuje. Nie wspominając już o tym, że wdrażanie dużych części stosu IP w celu określenia, które pakiety są odpowiednie, wykracza poza mój zamierzony zakres tego rozwiązania.

Celem jest posiadanie nadrzędnego/bez zaufania/drugiego odgadnięcia, jakie wartości przechowuję z recvmsg().

Prawą rzeczą, którą należy wykonać, jest prawidłowe śledzenie tych wartości, ale warto mieć prosty "Hej OS? Ile bajtów otrzymałem na tym gnieździe na naprawdę?"

Answer 1

Być może statystyki w/proc/net/dev mogą pomóc. Nie jestem zaznajomiony z liczeniem ładunku z pełnymi pakietami, w tym z nagłówkami, więc to sprawia, że ​​pytanie jest trudniejsze.

Jeśli chodzi o statystyki dotyczące poszczególnych deskryptorów plików, nie jestem świadomy żadnych standardowych środków, aby uzyskać te informacje.

Jeśli można kontrolować uruchamianie programów, dla których potrzebne są statystyki, można użyć biblioteki "przechwytującej", która implementuje własne metody read(), write(), sendto() i recvfrom() wywołuje, przekazuje połączenia do standardowej biblioteki C (lub bezpośrednio do wywołania systemowego), utrzymuje liczniki aktywności i znajduje sposób na opublikowanie tych wartości.

Answer 2

Czy chcesz to dla diagnozy, lub dla rozwoju?

Jeśli diagnoza, tcpdump może powiedzieć dokładnie, co dzieje się w sieci, filtrowane przez port i szczegóły hosta.

Jeśli na rozwój, może nieco więcej informacji na temat tego, co starasz się osiągnąć pomogłoby ...

ifconfig daje RX i TX sumy.

ifconfig pobiera te dane z/proc/net/dev (jak widać za pomocą strate ifconfig).

Istnieją również wartości Send/Receive-Q podane przez netstat -t, jeśli jest bliżej tego, co chcesz.

Answer 3

Można również użyć wywołania ioctl z SIOCINQ, aby uzyskać ilość oczekujących nieprzeczytanych danych w buforze odbiorczym. Oto wykorzystanie ze strony człowieka: http://man7.org/linux/man-pages/man7/tcp.7.html

int value; 
error = ioctl(tcp_socket_fd, SIOCINQ, &value); 

Dla statystykach interfejs TCP, możemy użyć "netstat -i -p tcp", aby znaleźć statystyki na zasadzie per-interface.

Answer 4

W przypadku, gdy nie chcesz po prostu policzyć całkowity RX/TX na interfejs (który jest już dostępny w ifconfig/tools iproute2) ...

Jeśli spojrzeć w/proc nieco więcej, można uzyskać nieco więcej informacji. Dokładniej: /proc/<pid>/net/dev.

Przykładowe wyjście:

Inter-| Receive            | Transmit 
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed 
    eth0: 12106810846 8527175 0 15842 0  0   0 682866 198923814 1503063 0 0 0  0  0   0 
    lo: 270255057 3992930 0 0 0  0   0   0 270255057 3992930 0 0 0  0  0   0 
    sit0:  0  0 0 0 0  0   0   0  0  0 0 0 0  0  0   0 

Jeśli zacząć szukać, informacja pochodzi od Linux kernelnet/core/net-procfs.c (PROCFS prostu wykorzystuje te informacje). Wszystko to oczywiście oznacza, że ​​potrzebujesz konkretnego procesu do śledzenia.

Możesz przeglądać informacje dostępne w /proc lub jeśli potrzebujesz czegoś bardziej stabilnego, powielanie funkcji net-procfs specjalnie dla twojej aplikacji może mieć sens.