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

[Joseph W. Doherty]

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

[david.alfaro1]

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

[Joseph W. Doherty]

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

[david.alfaro1]

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

[Joseph W. Doherty]

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

[david.alfaro1]

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

[david.alfaro1]

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

[Joseph W. Doherty]

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

[jennylouise087]

Формирование трафика применяется только к исходящему трафику, поэтому параметры Bc/Be влияют на выходные очереди, а не на входящие. Входящий трафик не может быть сформирован, поскольку он уже прибыл, но он может быть буферизован или отброшен, если превышает объем, который может обработать интерфейс. Входной буфер отделен и не использует те же параметры формирования — если отправитель передает больше, чем может обработать
канал
, на входящей стороне происходит управление перегрузкой и отбрасывание пакетов, а не формирование.

[Joseph W. Doherty]

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