Статистика сетевого интерфейса windows 10 redstone | Настройка серверов windows и linux

Беспроводные сети

Беспроводные сети подвержены воздействию ряда факторов, которые могут повредить или потерять пакеты при передаче, например радиопомехи (RFI),[6] радиосигналы, слишком слабые из-за расстояния или многолучевое замирание, неисправное сетевое оборудование или неисправные сетевые драйверы.

Вай фай является по своей сути ненадежный и даже когда два одинаковых Вай фай приемники расположены в непосредственной близости друг от друга, они не демонстрируют аналогичных схем потери пакетов, как можно было бы ожидать.[7]

Сотовые сети может возникнуть потеря пакетов из-за “высокого частота ошибок по битам (BER), нестабильные характеристики канала и мобильность пользователей ».[8] Преднамеренное регулирование TCP не позволяет беспроводным сетям работать со скоростью, близкой к их теоретической потенциальной скорости передачи, поскольку неизмененный TCP обрабатывает все отброшенные пакеты, как если бы они были перегрузка сети, и так может задушить беспроводные сети даже если они на самом деле не перегружены.[8]

Влияние дисциплины в очередях

Есть много дисциплины очередей используется для определения отбрасываемых пакетов. Большинство базового сетевого оборудования будет использовать ФИФО формирование очереди для пакетов, ожидающих прохождения через узкое место, и они будут отбрасывать пакет, если очередь будет заполнена на момент получения пакета.

Этот тип отбрасывания пакетов называется падение хвоста. Другие механизмы полной очереди включают случайное раннее выпадение или же взвешенное случайное раннее выпадение. Отбрасывание пакетов нежелательно, так как пакет либо утерян, либо должен быть повторно передан, и это может повлиять на пропускную способность в реальном времени; однако увеличение размера буфера может привести к буфер что по-своему влияет на задержку и дрожание во время перегрузки.

В случаях, когда качество обслуживания ограничивает скорость соединения, пакеты могут быть намеренно отброшены, чтобы замедлить работу определенных служб, чтобы обеспечить доступную пропускную способность для других служб, отмеченных как более важные (например, используемых в дырявое ведро алгоритм).

Возможности протоколирования и статистики для настройки шлюза

Для получения диагностической информации, статистических
данных и сообщений об ошибках рекомендуется выполнить следующие действия:

·       Вручную
запустить перехватчик ipsm-app из консоли вместо запуска службы /etc/init.d/ipsmapp:

/opt/VPNagent/bin/ipsm-app
–f

При этом в консоль будут выводиться диагностические сообщения
подсистем DPDK, а также, в зависимости от настроек, статистика по количеству
пакетов и их дамп в шестнадцатеричном виде.

·       Просмотреть
файл статистики, указанный в параметре stats_fileфайлаipsm_dpdk.cfg.

Содержимое имеет вид:

Wed 12 Jul 2022 17:28:10 0300

port: 0  name: 86:00.0 mtu: 9700  link
speed: 10000Mbps  full-duplex  autonegotiation  link
up

port: 0   sent:        0
/ 0       , sent_total:        0
/ 0      

port: 0   recv:        0
/ 0       , recv_total:        0
/ 0      

port: 0   drop:        0,
drop_total:        0

port: 0   rate (Mbps):        0
in          0 out

port: 0  sendq:        0,
sq_ovf_cnt:        0

port: 0  ipkts:        0,  opkts:        0

port: 0 ipktst:        0,
opktst:       27

port: 0

port: 0

port: 0

port: 0

port: 1  name: 85:00.0 mtu: 9600  link
speed: 10000Mbps  full-duplex  autonegotiation  link
up

port: 1   sent:        0
/ 0       , sent_total:        0
/ 0      

port: 1   recv:    23508
/ 12036096, recv_total:  3627936 / 1857503232

port: 1   drop:    23520,
drop_total:  3627696

port: 1   rate (Mbps):       91
in          0 out

port: 1  sendq:        0,
sq_ovf_cnt:        0

port: 1  ipkts:    23520,  opkts:        0

port: 1 ipktst:  3627936, opktst:        0

port: 1

port: 1

port: 1 d8    23520 

port: 1 d8t  3627696 

Информация обновляется раз в секунду.

Статистика, представляемая по каждому порту отдельно:

sent – пакетов/байтов отправлено за секунду, sent_total
– пакетов/байтов отправлено всего с момента запуска;

recv – пакетов/байтов получено за секунду, recv_total
– пакетов/байтов получено всего с момента запуска;

drop – отброшено пакетов за секунду, drop_total
– отброшено пакетов всего с момента запуска;

rate – текущая скорость приема и отправки трафика
на данном порту в мегабитах в секунду;

sendq – текущая длина очереди исправления пересортировки
пакетов (sendqueue);

sq_ovf_cnt – количество переполнений
очереди исправления пересортировки пакетов (sendqueue);

free_pool – количество свободных буферов
на данном порту (в DPDK) под пакеты;

ipkts/opkts – количество принятых/отправленных
пакетов за секунду (из статистики сетевой карты);

ipktst/opktst – количество принятых/отправленных
пакетов всего с момента запуска (из статистики сетевой карты).

Статистика по типам ошибок (получаемая от сетевой карты).
С окончанием “t” – всего с момента запуска, иначе за секунду. Статистика
об ошибках выводится только при их наличии.

imiss – входящие пакеты, отброшенные из-за переполнения
очереди сетевой карты (FIFO);

ierr – всего ошибок на входящих пакетах;

oerr – всего исходящих пакетов, отброшенных из-за
ошибок на передаче;

imbuf – входящие пакеты, отброшенные из-за ошибок
в выделении памяти.

Статистика по дополнительной информации об ошибках во
входящих пакетах (например, ошибка в контрольной сумме ip либо tcp) либо
ошибках при их приёме. Эти ошибки учитываются в счётчике ierr/ierrt,
но не обязательно приводят к уничтожению пакета.

Например, пакет успешно
принимается сетевой картой при ошибке в контрольной сумме 3-4 уровней.
Отображается только при наличии таких ошибок и включенной опции hw_ip_checksum.
Значения с окончанием “t” – всего с момента запуска. Иначе – за
секунду.

e0 – неправильная контрольная сумма протокола
4 уровня (TCP);

e1 – неправильная контрольная сумма IP-заголовка;

e2 – неправильная контрольная сумма внешнего IP-заголовка.

:/>  Как проверить видеокамеру на компьютере windows 7. Как включить камеру на ноутбуке под управлением Windows

Строка, содержащая вывод вида “d8  3   d8t
70” – статистика отбрасыванию пакетов. Значения с окончанием “t”
– всего с момента запуска. Иначе – за секунду. Значения выводятся только
для ненулевых счётчиков.

d1 – пакеты, отброшенные при ошибках на
отправке в сеть (параметр tx_retries). Обычно появляются
при приближении к теоретическому пределу пропускной способности сети для
данного размера пакетов.

d2 – входящие пакеты, отброшенные при невозможности
передать их на обработку. Появляются при загруженности обрабатывающих
потоков (упёрлись в максимальную производительность по шифрованию/фильтрации).

d3 – пакеты, отброшенные. если данный интерфейс
имеет состояние (pa_state), отличное от PCAP_PASS (состояние по умолчанию
для uncontrolled-интерфейсов) и PCAP_PROCESS (состояние controlled-интерфейсов).
Состояние интерфейса устанавливается платформо-независимой частью в зависимости
от того, загружена LSP или DDP.

d4 – ошибка при получении входящего пакета
от DPDK. Это возможно при серьёзной вычислительной перегрузке и нехватке
ресурсов.

d5 – пакеты, отброшенные при неудаче отправки
внутрь tcp/ip стека ОС на интерфейс vEth<N>.

d6 – пакеты, отброшенные из-за ошибок в
работе с памятью, при подготовке к передаче пакетов в платформо-независимую
часть.

d7 – пакеты, отброшенные при удалении платформо-независимой
частью структуры packet_data_t.

d8 – пакеты, отброшенные платформо-независимой
частью. Должны, в основном, быть заметны как DROP в klogview (см. «Специализированные
команды»).

d9 – фреймы, отброшенные при получении из сети
или стека ОС, имеющие значение поля ethertype, отличное от 0x0800 (IPv4),
0x0806 (ARP) и не указанное в параметре allowed_ethertypes.

d10 – фреймы, отброшенные при получении с виртуального
интерфейса vEthN, если ему соответствует порт LAN.

d11 – фреймы, полученные на порту WAN либо
полученные из стека ОС на виртуальный интерфейс vEthN, отброшенные механизмом
фильтрации по vlan id.

Информация о текущем статусе порта, включающая mtu, link,
link speed, duplex state, autonegotiation state, отображается однократно
при отправке в ipsm-app сигнала SIGUSR2:

pkill -SIGUSR2 ipsm-app

port: 1  name: 85:00.0 mtu: 9600  link
speed: 10000Mbps  full-duplex  autonegotiation  link
up

Вся статистика может быть сброшена отправкой в ipsm-app
сигнала SIGUSR1:

pkill -SIGUSR1 ipsm-app

·       Просмотреть
файл дампа кадров ethernet, указанного в параметре frames_fileфайлаipsm_dpdk.cfg.

Содержимое имеет вид:

22-12-16 19:29:55.922  p1 in    [126] 90e2ba4c0271 a8f94bf7d6bb 0800

45040070fd8a40003f119d31c0a81037c0a80f35 01f401f4005c2d7a

22-12-16 19:29:55.922  p1 out*  [126] 90e2ba4c0271 a8f94bf7d6bb 0800

45040070fd8a40003f119d31c0a81037c0a80f35 01f401f4005c2d7a

22-12-16 19:29:55.971  p1 in    [142] 90e2ba4c0271 a8f94bf7d6bb 0800

4500008000144000fe32db7ac0a81037c0a80f35 e8cd0a4a00000003

22-12-16 19:29:55.972  p0 out    [60] ffffffffffff 000c2922b756 0806

0001080006040001000c2922b756aca4de8b000000000000aca4de89

22-12-16 19:29:55.972  p0 in     [60] 000c2922b756 000c293fd99f 0806

0001080006040002000c293fd99faca4de89000c2922b756aca4de8b

p<N> –- номер порта, на котором получен дамп кадра
ethernet.

[NN] длина кадра ethernet, вместе с заголовком.

Для улучшения восприятия пробелами отделены MAC-адреса,
заголовок ethernet, заголовок IPv4 (при наличии).

in – входящие (из сети) кадры, out – исходящие
(в сеть), in* – входящие (из tcp/ip стека ОС, с интерфейса
vEth<N>), out* – исходящие (в tcp/ip стек ОС на интерфейс
vEth<N>).

Кадры, отмеченные как in*/out*,
можно просмотреть в выводе tcpdump на соответствующем интерфейсе vEth<N>.

·       Просмотреть
файл ошибок и предупреждений /tmp/ipsm-app/error.log.

В данный файл попадают следующие ошибки и предупреждения:

Ошибки, возникшие при инициализации ipsm-app.

Ошибки при изменении MTU либо других настроек портов.

Ошибки в конфигурационном файле ipsm_dpdk.cfg.

Ошибки в выделении памяти.

Критические системные ошибки.

Изменения mtu интерфейсов vEth<N> и соответствующих
им физических портов.

·       Просмотреть
файл протоколирования подсистем dpdk, указанный в параметре rte_log_file.

Восстановление пакетов для надежной доставки

По сквозной принцип Интернет-протокол оставляет ответственность за восстановление пакетов посредством повторной передачи отброшенных пакетов на конечные точки – компьютеры, отправляющие и получающие данные. Они находятся в лучшем положении, чтобы решить, необходима ли повторная передача, потому что приложение, отправляющее данные, должно знать, лучше ли передать сообщение полностью или частично, прошла ли необходимость отправки сообщения, и как контролировать количество потребляемой полосы пропускания для учета любых перегрузок.

Сетевые транспортные протоколы, такие как TCP, предоставляют конечным точкам простой способ обеспечить надежная доставка пакетов, так что отдельные приложения не должны реализовывать логику для этого самостоятельно. В случае потери пакета получатель запрашивает повторную передачу, или отправитель автоматически повторно отправляет любые сегменты, которые не были подтверждены.[15] Хотя TCP может восстанавливаться после потери пакетов, повторная передача отсутствующих пакетов снижает пропускная способность соединения, поскольку получатели ожидают повторных передач и потребляют дополнительную полосу пропускания.

Такие протоколы как Протокол пользовательских датаграмм (UDP) не восстанавливает потерянные пакеты. Ожидается, что приложения, использующие UDP, при необходимости будут реализовывать свои собственные механизмы обработки потери пакетов.

Диагностика

Потеря пакетов обнаруживается надежными протоколами, такими как TCP. Надежные протоколы автоматически реагируют на потерю пакетов, поэтому, когда такой человек, как сетевой администратор необходимо обнаруживать и диагностировать потерю пакетов, они обычно используют информацию о состоянии от сетевого оборудования или специальных инструментов.

В Протокол управляющих сообщений Интернета обеспечивает эхо функциональность, при которой передается специальный пакет, который всегда дает ответ. Такие инструменты как пинг, трассировка, и MTR используйте этот протокол для визуального представления пути, по которому проходят пакеты, и для измерения потерь пакетов на каждом прыгать.[b]

:/>  Домашний медиа-сервер скачать на Windows бесплатно

Многие маршрутизаторы имеют страницы состояния или журналы, где владелец может найти количество или процент пакетов, отброшенных за определенный период.

Допустимая потеря пакетов

Потеря пакетов тесно связана с качество обслуживания соображения. Допустимая величина потери пакетов зависит от типа отправляемых данных. Например, для передача голоса по IP трафик, один комментатор считает, что «[m] проверка одного или двух пакетов время от времени не повлияет на качество разговора.

Потери от 5% до 10% общего потока пакетов значительно повлияют на качество».[12] Другой описал потерю пакетов менее 1% как «хорошо» для потокового аудио или видео и 1-2,5% как «приемлемую».[13]

Измерение

Потеря пакетов может быть измерена как частота потери кадров определяется как процент кадров, которые должны были быть отправлены сетью, но не были.[11]

Контроль трафика windows 10

Для того, чтобы точно понимать на, что идет ваш трафик, советую поставить специальное программное обеспечение, по типу Kerio Kontrol, для общего подсчета входящих и исходящих пакетов, в Windows 10 Redstone, есть встроенные средства, не такие информативные, но все же.

Нажимаем сочетание клавиш WIN R и вводим ncpa.cpl. У вас откроется оснастка сетевые подключения Windows.

Щелкаете по нужному сетевому интерфейсу правым кликом и выбираете Состояние.

В открывшемся окне, вы увидите два значения Отправлено и Принято, это и есть входящие и исходящие сетевые пакеты на ваши интерфейсы. Они по умолчанию считаются в байтах, поделите это число на 1024000 и получите сколько мегабайт вы потратили.

Вторым методом посмотреть сетевую статистику пакетов в Windows 10 будет команда netstat, ее вы должны выполнить в командной строке.

netstat -e

В итоге вы получаете тоже статистику по входящим и исходящим пакетам, тут же вы видите, количество отброшенных пакетов и ошибок.

Если укажите дополнительный ключ -s, то увидите статистику по протоколам ipv4 и ipv6.

netstat -e -s

Можно получить статистику только по протоколу ICMP, для этого выполните

netstat -s -p icmp

Для циклического опроса состояния сетевых соединений используется запуск программы с указанием интервала вывода статистических данных в секундах.

netstat -e 2 – отображать статистику по Ethernet с интервалом 2 секунды.

netstat –f 5 – каждые 5 секунд отображать статистику сетевых соединений с использованием полных DNS-имен узлов.

netstat -n 10 | find /i “имя соединения” – каждые 10 секунд отображать статистику по установленным соединениям.

Как видите утилита netstat, не плохой счетчик трафика для windows 10.

Третьим методом посмотреть счетчик трафика для windows 10, будет у нас Диспетчер задач. Точнее его вкладка Производительность, на ней есть пункт открыть монитор ресурсов.

Переходим в мониторе ресурсов на вкладку сеть. Тут вы видите три раздела

  1. Это Процессы, в нем вы видите программы и процессы, которые в момент своей работы используют сетевой интерфейс.
  2. Сетевая активность, тут вы увидите, сколько каждый из процессов потратил трафика, на какой адрес в сети или интернете он обратился.
  3. TCP подключения. Тут вы увидите на какие порты вы подключаетесь. Например в примере MS Edge видно, что подключается на 80 и 443 порт.

Перегрузка сети

Перегрузка сети является причиной потери пакетов, которая может повлиять на все типы сетей. Когда контент поступает в течение длительного периода в данный маршрутизатор или сегмент сети со скоростью, превышающей возможную для отправки, нет другого выхода, кроме как отбрасывать пакеты.[3] Если один маршрутизатор или канал ограничивают пропускную способность всего пути или сети в целом, это называется горлышко бутылки. В некоторых случаях пакеты намеренно отбрасываются процедурами маршрутизации,[9] или с помощью сетевых методов устрашения для целей оперативного управления.[10]

Последствия

Потеря пакетов напрямую снижает пропускная способность для данного отправителя, поскольку некоторые отправленные данные никогда не принимаются и не могут считаться пропускной способностью. Потеря пакетов косвенно снижает пропускную способность, поскольку некоторые протоколы транспортного уровня интерпретируют потерю как указание на перегрузку и корректируют свою скорость передачи, чтобы избежать перегрузки.

Когда необходима надежная доставка, увеличивается потеря пакетов задержка из-за дополнительного времени, необходимого для повторной передачи.[а] При отсутствии повторной передачи пакеты с наихудшими задержками могут быть предпочтительно отброшены (в зависимости от дисциплина в очереди used), что приводит к снижению общей задержки.

Примечания

  1. ^Во время типичной перегрузки сети не все пакеты в потоке отбрасываются. Это означает, что неотброшенные пакеты будут приходить с малой задержкой по сравнению с повторно переданными пакетами, которые прибывают с большой задержкой. Мало того, что повторно переданные пакеты должны пройти часть пути дважды, отправитель не поймет, что пакет был отброшен, пока он либо не сможет получить подтверждение о получении в ожидаемом порядке или не получает подтверждения в течение достаточно длительного времени, что предполагает, что пакет был отброшен, а не просто задержан.
  2. ^В некоторых случаях эти инструменты могут указывать отбрасывание пакетов, завершающихся небольшим количеством переходов, но не тех, которые достигают места назначения. Например, маршрутизаторы могут давать эхо-сигналу пакетов ICMP низкий приоритет и отбрасывать их предпочтительно в пользу траты ресурсов на подлинные данные; это обычно считается артефактом тестирования и может быть проигнорировано в пользу сквозных результатов.[14]
:/>  Исправлено: аудиосервисы не отвечают в Windows 10

Причины

В протокол Интернета (IP) разработан в соответствии с сквозной принцип как наилучшая доставка сервис, с намерением сохранить логику маршрутизаторы необходимо реализовать как можно проще. Если сеть сделала надежная доставка гарантии сами по себе, что потребует хранить и пересылать инфраструктура, в которой каждый маршрутизатор выделял пакетам значительный объем дискового пространства, ожидая подтверждения того, что следующий узел правильно их получил.

Надежная сеть не сможет поддерживать гарантии доставки в случае отказа маршрутизатора. Надежность также нужна не для всех приложений. Например, с live потоковое мультимедиа, важнее быстро доставить недавние пакеты, чем гарантировать, что в конечном итоге будут доставлены устаревшие пакеты.

Приложение или пользователь также могут решить повторить операцию, которая занимает много времени, и в этом случае к бремени доставки исходного набора будет добавлен другой набор пакетов. Такая сеть может также нуждаться в командование и контроль протокол для управления перегрузкой, добавляющий еще большую сложность.

Чтобы избежать всех этих проблем, Интернет-протокол позволяет маршрутизаторам просто отбрасывать пакеты, если маршрутизатор или сегмент сети слишком заняты для своевременной доставки данных. Это не идеально для быстрой и эффективной передачи данных, и не ожидается, что это произойдет в незагруженной сети.[4] Отбрасывание пакетов действует как неявный сигнал о том, что сеть перегружена, и может заставить отправителей уменьшить объем используемой полосы пропускания или попытаться найти другой путь.

Например, используя воспринимаемую потерю пакетов в качестве обратной связи для обнаружения перегрузки, Протокол управления передачей (TCP) спроектирован таким образом, что чрезмерная потеря пакетов заставит отправителя задросселировать и прекратить переполнение узкого места данными.[5]

Пакеты также могут быть отброшены, если Контрольная сумма заголовка IPv4 или Ethernet последовательность проверки кадра указывает, что пакет поврежден. Потеря пакетов также может быть вызвана атака отбрасывания пакетов.

Рекомендации

  1. ^
  2. ^Тиан, Е; Сюй, Кай; Ансари, Нирван (март 2005 г.). «TCP в беспроводной среде: проблемы и решения»(PDF). Радиосвязь IEEE: S27 – S32. Архивировано из оригинал(PDF) на 2022-08-09. Получено 2022-02-19.
  3. ^ абКуроз, Дж. Ф. и Росс, К. В. (2022). Компьютерные сети: подход сверху вниз. Нью-Йорк: Аддисон-Уэсли. п. 36.
  4. ^Kurose, J.F .; Росс, К. (2022). Компьютерные сети: подход сверху вниз. Нью-Йорк: Аддисон-Уэсли. стр.42 –43. Доля потерянных пакетов увеличивается по мере увеличения интенсивности трафика. Следовательно, производительность на узле часто измеряется не только с точки зрения задержки, но и с точки зрения вероятности потери пакета … потерянный пакет может быть повторно передан на сквозной основе, чтобы гарантировать, что все данные в конечном итоге будут переданы. от источника до места назначения.
  5. ^Куроз, Дж. Ф. и Росс, К. В. (2008). Компьютерные сети: подход сверху вниз. Нью-Йорк: Аддисон-Уэсли. п. 282-283.
  6. ^Дэвид С. Салиерс, Аарон Стригель, Кристиан Поеллабауэр, Надежность беспроводной связи: переосмысление потери пакетов 802.11(PDF), заархивировано из оригинал(PDF) на 2022-07-12, получено 2022-05-12CS1 maint: несколько имен: список авторов (связь)
  7. ^Дэвид С. Салиерс, Аарон Стригель, Кристиан Поеллабауэр, Надежность беспроводной связи: переосмысление потери пакетов 802.11(PDF), заархивировано из оригинал(PDF) на 2022-07-12, получено 2022-03-09CS1 maint: несколько имен: список авторов (связь)
  8. ^ абЕ Тянь; Кай Сюй; Нирван Ансари (март 2005 г.). «TCP в беспроводной среде: проблемы и решения»(PDF). Радиосвязь IEEE. IEEE. Архивировано из оригинал(PDF) на 2022-08-09. Получено 2022-02-19.
  9. ^Перкинс, C.E. (2001). Ad Hoc Networking. Бостон: Эддисон-Уэсли. п. 147.
  10. ^«Управление приложениями путем управления характеристиками сети» Вахаб Пурнагшбанд, Леонард Клейнрок, Питер Рейхер и Александр Афанасьев ICC 2022
  11. ^RFC 1242
  12. ^Мэнсфилд, К. И Антонакос, Дж. Л. (2022). Компьютерные сети из LAN в WAN: оборудование, программное обеспечение и безопасность. Бостон: Технологии курсов, обучение Cengage. п. 501.
  13. ^«Архивная копия». Архивировано из оригинал на 2022-10-10. Получено 2022-05-16.CS1 maint: заархивированная копия как заголовок (связь)
  14. ^«Потеря пакета или задержка на промежуточных переходах». Получено 2007-02-25.
  15. ^Куроз, Дж. Ф. и Росс, К. В. (2022). Компьютерные сети: подход сверху вниз. Нью-Йорк: Аддисон-Уэсли. п. 242.

Оставьте комментарий

Adblock
detector