поведение формирования трафика с входящим трафиком

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:09:00 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:09:00 GMT

Формирование трафика применяется только к исходящему трафику, поэтому параметры Bc/Be влияют на выходные очереди, а не на входящие. Входящий трафик не может быть сформирован, поскольку он уже прибыл, но он может быть буферизован или отброшен, если он превышает возможности интерфейса. Входной буфер отделен и не использует те же параметры формирования — если отправитель передает больше, чем может обработать канал, на входящей стороне происходит управление перегрузкой и отбрасывание пакетов, а не формирование. Кстати,
@jennylouise087
, я прочитал вышеуказанное несколько раз и, лично, нахожу его несколько запутанным, поскольку описанное может быть полностью точным или неточным в зависимости от того, что на самом деле имеется в виду. По сути, я считаю, что точность почти каждого утверждения в значительной степени зависит от неописанного контекста. Например, если взять самое первое утверждение, то формирователь применяется к исходящему трафику интерфейса, но его фактический эффект может распространяться вверх по потоку, вплоть до источника, что может замедлить скорость передачи и, следовательно, повлиять на объем получаемого трафика, видимого на входном интерфейсе устройства формирования. Кроме того, поскольку shaper замедляет эффективную скорость передачи на выходе и выполняет собственную буферизацию, логически фактическая очередь на выходе интерфейса не должна быть необходима, хотя физически она может использоваться для трафика, не удаленного из очереди shaper. (Как я упоминал в своих предыдущих ответах, shaper пытается имитировать физический интерфейс, но его фактическое поведение не совсем такое же. [Кстати, то же самое относится и к полисеру, фактическое поведение которого может отличаться или не отличаться от поведения формирователя.])

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:59 GMT

jennylouise087 — Sat, 14 Feb 2026 22:08:59 GMT

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:58 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:08:58 GMT

Я рад, что вы нашли мое объяснение полезным. Еще раз напомню, что трафик-шейпер используется для имитации более медленного/низкоскоростного физического интерфейса, поэтому при организации очередей/буферизации возникают практически те же проблемы, например, для физического интерфейса 10 Мбит/с или шейпера 10 Мбит/с. (Опять же, формирователи не ведут себя точно так же, как физические интерфейсы, но для целей формирования трафика различия обычно не имеют значения, по крайней мере, не имеют большого значения). Что касается входящего трафика, для управления трафиком вы можете фильтровать с помощью ACL или контролировать с помощью полицейского. Устройства часто имеют «входные» очереди, но, как правило, это «проблема», если входящий трафик попадает в очередь, и, поскольку это необычная проблема, часто у вас не так много вариантов для ее решения, кроме увеличения глубины очереди. Кроме того, когда заканчиваются буферы, часто достигается логический предел выделения, а не физическое исчерпание ОЗУ, но огромные очереди имеют свои собственные негативные последствия. На самом деле, за «правильным размером» распределения размера очередей/буферов стоит целая наука, но это тема, которая не очень хорошо понятна многим сетевым инженерам, которые даже часто думают, что «идеальным» вариантом всегда является нулевое количество пропущенных пакетов или что определенный уровень использования пропускной способности является либо хорошим, либо плохим.

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:57 GMT

david.alfaro1 — Sat, 14 Feb 2026 22:08:57 GMT

Здравствуйте, Джозеф Я искренне благодарен вам за объяснение. Вы правы, я был привязан к идее, что формирование трафика имеет какое-то отношение к управлению входящим трафиком, но, как вы объяснили, это связано с факторами, выходящими за рамки формирования трафика, и теперь мне все ясно. Твое терпение превосходит всякое воображение, еще раз большое спасибо. Я сохраню эту переписку в своей библиотеке. С уважением

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:56 GMT

david.alfaro1 — Sat, 14 Feb 2026 22:08:56 GMT

Здравствуйте, Джозеф, Спасибо за терпение. Я понимаю, что в серьезных случаях, в интерфейсах с низкой скоростью, где обычно применяется формирование трафика, если при сильной перегрузке выходные буферы, которые являются конечными (независимо от того, что входит или поступает), превышаются при определенной скорости передачи данных, при которой буферы полностью заполняются, и формирование трафика достигает своей максимальной емкости, то мы будем говорить о потере пакетов, учитывая полную занятость буферов, когда превышается эта предполагаемая чрезмерная скорость передачи данных, верно? С уважением, С уважением,

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:55 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:08:55 GMT

«Всегда» — на самом деле нет, но «часто» или «обычно» — да. В некоторых случаях может возникать очередь входящего трафика, но обычно это не имеет ничего общего с каким-либо узким местом в исходящем трафике (включая то, что может создать узкое место в исходящем трафике, хотя трафик-шейпер может создать проблему с входящим трафиком). Очереди входящего трафика или его потери могут быть вызваны недостаточной пропускной способностью платформы (которую может помочь преодолеть регулятор) и/или внутренним узким местом пропускной способности между входными и выходными портами (вероятно, потребуется несколько портов).

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:54 GMT

david.alfaro1 — Sat, 14 Feb 2026 22:08:54 GMT

Здравствуйте, Джозеф Большое спасибо за объяснение Позвольте мне уточнить, правильно ли я понимаю: как входящий, так и исходящий трафик, т. е. вся пропускная способность, будет определяться очередностью и формированием трафика на интерфейсе, или, другими словами, «узким местом» всегда будет исходящий трафик, контролируемый формированием трафика. Так ли это? Или я ошибаюсь?

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:53 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:08:53 GMT

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

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:52 GMT

david.alfaro1 — Sat, 14 Feb 2026 22:08:52 GMT

Здравствуйте, Джозеф Я понимаю, что формирование трафика не применимо к входящему трафику, я полностью это понимаю. Мой вопрос не в том, применимо ли оно к входящему или исходящему трафику, я полностью понимаю, что, как правило, оно применимо к исходящему трафику, так как я также полностью понимаю, как формирование трафика работает с исходящим трафиком. Но мой первоначальный вопрос заключается в том, что в целом (чтобы не повторять весь вопрос), что происходит с входящим трафиком, когда формирование трафика применяется на интерфейсе?

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:51 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:08:51 GMT

Как правило, формирование трафика не может применяться к входящему трафику.

Reply to поведение формирования трафика с входящим трафиком on Sat, 14 Feb 2026 22:08:50 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:08:50 GMT

Верно, хотя проблема сброса буфера не связана конкретно с «низкоскоростными интерфейсами», «сильной перегрузкой» или формирователем трафика (или полицейским). Общая причина потерь заключается в том, что скорость входящего трафика превышает скорость исходящего, и если избыток буферизуется/помещается в очередь, а емкость хранилища превышена (обычно логически, а не физически), вы вынуждены отбрасывать пакеты (кстати, не обязательно только вновь поступившие пакеты, хотя это и является нормой). Кстати, мое терпение далеко не исчерпано, но, поскольку вы, похоже, задаете один и тот же вопрос и/или сосредоточены на формировании трафика, либо мои предыдущие ответы были неясными (что всегда вполне возможно из-за моих недостатков в письменной речи), либо в вашем вопросе есть аспект, который я упустил и на который не ответил. Возможно, следующее поможет. Рассмотрим сетевое устройство с двумя интерфейсами. Если у этого устройства два интерфейса с одинаковой пропускной способностью, например, два интерфейса 100 Мбит/с, то (обычная) буферизация/очередь не нужна. Однако, если вышеуказанное устройство имеет один интерфейс 100 Мбит/с и один 10 Мбит/с, 10 до 100, как 100 до 100, не должно быть необходимости в буферизации/очереди. Однако, 100 до 10
МОЖЕТ
потребовать буферизации/очереди. (Вы понимаете, почему «может»?) Если устройство снова имеет два интерфейса 100 Мбит/с, но мы формируем трафик на одном из них со скоростью 10 Мбит/с, эффект потери должен быть примерно таким же, как у устройства с одним интерфейсом 100 Мбит/с и одним интерфейсом 10 Мбит/с. Т. е. особенно в отношении потери пакетов, из-за чрезмерно возможных буферных ресурсов, не имеет значения, что используется формирователь трафика, а не физический интерфейс с аналогичной пропускной способностью. NB: поведение устройства формирования трафика в некоторых аспектах никогда не будет соответствовать физическому интерфейсу с аналогичной пропускной способностью, а в других аспектах параметры как физического интерфейса, так и устройства формирования трафика должны соответствовать.