У меня есть маршрутизатор, перенаправляющий трафик из одной сети в другую, и мне нужно знать, когда занятость очереди пакетов (на принимающей стороне / интерфейсе - rx) приближается к максимальной.
Однако после анализа следующих файлов (файловая система linux):
Я пришел к выводу, что эти файлы будут иметь значение для моей проблемы, только если маршрутизатор будет местом назначения или источником TCP-пакетов. Итак, как я обсуждал с профессором, эти показатели не имеют отношения к ситуации пересылки, так как пакеты не попадают в очереди TCP.
Если это правда, то где я могу найти информацию о текущей занятости очереди переадресации и ее максимальной занятости, если есть информация по этому поводу?
Этот роутер - он твой? Маршрутизация с использованием сети Linux? Если это так, вы, вероятно, захотите заменить его настоящим маршрутизатором, если только вы не знаете, что ваши ссылки на другие сети имеют низкую пропускную способность. Обычные Linux-боксы не создают особо эффективных маршрутизаторов. Настоящие маршрутизаторы, работающие под управлением Linux, обычно не будут использовать сеть Linux для быстрого пути, поэтому перечисленные вами файлы в этом случае не помогут. И если эти файлы находятся на вашем локальном хосте, а не на маршрутизаторе, они не помогут.
Единственное, что поможет, если это настоящий маршрутизатор, - это инструменты управления, которые он предоставляет. Большинство домашних маршрутизаторов не предоставляют эту информацию. Коммерческие маршрутизаторы могут, но используют собственный интерфейс или MIB SNMP. В MIB интерфейса SNMP есть запись для длины очереди вывода, но она устарела, вероятно, потому, что реальность более сложна, чем одно число для интерфейса (поскольку маршрутизаторы часто ставят в очередь для каждого потока, а не для каждого интерфейса). Возможно, есть еще одна MIB, которая поможет.
/sys/class/net/(interface)/tx_queue_len - это параметр конфигурации, сообщающий вам, какова максимальная длина очереди в пакетах в вашей локальной системе. Если вы не видите это на маршрутизаторе, и ваш маршрутизатор просто использует сеть Linux, это бесполезно.
Чтобы еще больше усложнить ситуацию, TCP использует различные методы (включая, помимо прочего, явное уведомление о перегрузке), чтобы избежать буферизации пакетов в маршрутизаторах между источником и местом назначения. Когда он работает идеально, максимальная перегрузка на любом маршрутизаторе на пути составляет в среднем один пакет! Причина этого в том, что лучше всего иметь минимум пакетов, буферизованных в сети, если у самого загруженного маршрутизатора всегда есть готовый пакет. Раздуваемые очереди в сети просто увеличивают сквозные задержки без увеличения производительности. Это довольно очевидно, но для его вывода потребовалось много научных исследований и экспериментов.
Итак, похоже, вы пытаетесь контролировать что-то, что на самом деле всегда должно быть максимум около 1, если все работает правильно. (Обратите внимание, что алгоритмы управления в TCP работают, даже если существует множество несвязанных TCP-соединений, совместно использующих любой из маршрутизаторов на пути. Они не работают, когда какая-либо из реализаций TCP не использует методы, и имеют тенденцию выходить из строя из-за дросселирования. и позволяя свиньям получить пропускную способность, к сожалению.)
Итак, я предполагаю, что вы пытаетесь сделать что-то, что не очень плодотворно, даже если это возможно.
Единственное, что вы можете сделать, - это периодически проверять связь с другим концом и фильтровать низкие частоты по времени отклика. Вы не будете знать, в каком направлении возникла пробка, но вы получите подсказку, когда возникнет пробка.