4. Очереди

PreviousКороткий итог по классификации Next5. Предотвращение перегрузок

Last updated 6 years ago

4. Очереди

Существует на самом деле всего лишь три группы инструментов обеспечения QoS, которые активно манипулируют пакетами:

(Congestion Avoidance) — что делать, чтобы не было плохо.
(Congestion Management) — что делать, когда уже плохо.
(Rate Limiting) — как не пустить в сеть больше, чем положено, и не выпустить столько, сколько не смогут принять.
Но все они по большому счёту были бы бесполезны, если бы не очереди.
В парке аттракционов нельзя отдать кому-то приоритет, если не организовать отдельную очередь для тех, кто заплатил больше. Такая же ситуация в сетях. Если весь трафик в одной очереди, не получится выдёргивать из её середины важные пакеты, чтобы дать им приоритет. Именно поэтому после классификации пакеты помещаются в соответствующую данному классу очередь. А далее одна очередь (с голосовыми данными) будет двигаться быстро, но с ограниченной полосой, другая помедленнее (потоковое вещание), зато с широкой полосой, а какой-то ресурсы достанутся по остаточному принципу. Но в пределах каждой отдельной очереди действует то же правило — нельзя выдернуть пакет из середины — только из его изголовья.
Каждая очередь обладает определённой ограниченной длиной. С одной стороны это диктуется аппаратными ограничениями, а с другой тем, что нет смысла держать пакеты в очереди слишком долго. VoIP пакет не нужен, если он задержался на 200мс. TCP запросит переотправку, условно, после истечения RTT. Поэтому отбрасывание — не всегда плохо. Разработчикам и дизайнерам сетевого оборудования приходится находить компромисс между попытками сохранить пакет как можно дольше и напротив не допустить бесполезной траты полосы, пытаясь доставить уже никому не нужный пакет.
В нормальной ситуации, когда интерфейс/чип не перегружен, утилизация буферов около нуля. Они амортизируют кратковременные всплески, но это не вызывает их продолжительного заполнения. Если же трафика приходит больше, чем может обработать чип коммутации или выходной интерфейс, очереди начинают заполняться. И хроническая утилизация выше 20-30% — это уже ситуация, к которой нужно принимать меры.

PreviousКороткий итог по классификации Next5. Предотвращение перегрузок

Last updated 6 years ago

(Congestion Avoidance) — что делать, чтобы не было плохо.
(Congestion Management) — что делать, когда уже плохо.
(Rate Limiting) — как не пустить в сеть больше, чем положено, и не выпустить столько, сколько не смогут принять.
Но все они по большому счёту были бы бесполезны, если бы не очереди.
В парке аттракционов нельзя отдать кому-то приоритет, если не организовать отдельную очередь для тех, кто заплатил больше. Такая же ситуация в сетях. Если весь трафик в одной очереди, не получится выдёргивать из её середины важные пакеты, чтобы дать им приоритет. Именно поэтому после классификации пакеты помещаются в соответствующую данному классу очередь. А далее одна очередь (с голосовыми данными) будет двигаться быстро, но с ограниченной полосой, другая помедленнее (потоковое вещание), зато с широкой полосой, а какой-то ресурсы достанутся по остаточному принципу. Но в пределах каждой отдельной очереди действует то же правило — нельзя выдернуть пакет из середины — только из его изголовья.
Каждая очередь обладает определённой ограниченной длиной. С одной стороны это диктуется аппаратными ограничениями, а с другой тем, что нет смысла держать пакеты в очереди слишком долго. VoIP пакет не нужен, если он задержался на 200мс. TCP запросит переотправку, условно, после истечения RTT. Поэтому отбрасывание — не всегда плохо. Разработчикам и дизайнерам сетевого оборудования приходится находить компромисс между попытками сохранить пакет как можно дольше и напротив не допустить бесполезной траты полосы, пытаясь доставить уже никому не нужный пакет.
В нормальной ситуации, когда интерфейс/чип не перегружен, утилизация буферов около нуля. Они амортизируют кратковременные всплески, но это не вызывает их продолжительного заполнения. Если же трафика приходит больше, чем может обработать чип коммутации или выходной интерфейс, очереди начинают заполняться. И хроническая утилизация выше 20-30% — это уже ситуация, к которой нужно принимать меры.