Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Спасибо вам огромное! Спасибо что продолжаете писать «вот это вот все». Это колосальный труд, я готов платить подписку за такие статьи. Вот что для меня был Хабр.
https://www.patreon.com/linkmeup
А мы и не против если нам трудовым рулём помогают))
Да, я тоже проникся. Думаю донейт был бы уместнее подписки, ибо это должно быть общедоступно.
eucariot, оставьте, пожалуйста, где-нибудь реквизиты для донейта. Спасибо Вам за ваши статьи! :)
Upd: опоздал с комментарием :) Вижу ссылку, спасибо.
eucariot, оставьте, пожалуйста, где-нибудь реквизиты для донейта. Спасибо Вам за ваши статьи! :)
Upd: опоздал с комментарием :) Вижу ссылку, спасибо.
Выше мой товарищ дал ссылку на патреон. Это просто возможность поддержать нас (а это ещё несколько серий подкастов) мелким рублём ежемесячно. При этом всё, что мы делаем, публикуется в открытом доступе.
Но есть и другие способы).
Но есть и другие способы).
Воу, не видел раньше эту серию постов. Это очень круто! Спасибо.
Теперь бы найти время перечитать все старые выпуски.
Теперь бы найти время перечитать все старые выпуски.
Планирую перенести всё на гитбук. Последние две статьи там уже есть: linkmeup.gitbook.io/sdsm
Поэтому в скором времени все статьи ждёт пересмотр и комментарии приветствуются.
Поэтому в скором времени все статьи ждёт пересмотр и комментарии приветствуются.
спасибо. стало хоть что то понятно.
но остатки ауры шаманизма всё ещё есть :)
но остатки ауры шаманизма всё ещё есть :)
Мне показалось или вы поклонник Лю Цысиня? :-)
Проблема QoS в том, что его очень не просто поддерживать в полностью рабочем состоянии на реальной сети. Особенно, если сеть не замерла в развитии.
Кто-то забывает на конечных системах маркировать трафик, кто-то путает маркировку, кто-то ставит новое сетевое оборудование и забывает делать настройки чтобы маркировка не сбрасывалась или правильно мапировалась, постоянно меняющиеся полосы арендованных каналов тоже требуют перенастроек и т.д. и т.п.
В общем, пока нет аварий и хватает полосы, то всё хорошо, но регулярно вылезают проблемы.
QoS это не та технология, которую сделал и забыл.
Учитывая нарастающие экономические проблемы у операторов и оптимизации персонала и прочих расходов, все эти непростые технологии вызывают только ощущение печали.
Кто-то забывает на конечных системах маркировать трафик, кто-то путает маркировку, кто-то ставит новое сетевое оборудование и забывает делать настройки чтобы маркировка не сбрасывалась или правильно мапировалась, постоянно меняющиеся полосы арендованных каналов тоже требуют перенастроек и т.д. и т.п.
В общем, пока нет аварий и хватает полосы, то всё хорошо, но регулярно вылезают проблемы.
QoS это не та технология, которую сделал и забыл.
Учитывая нарастающие экономические проблемы у операторов и оптимизации персонала и прочих расходов, все эти непростые технологии вызывают только ощущение печали.
Спасибо за статью, действительно труд огромный.
Хотелось бы конечно еще информации по иерархическому QoS, да и по мониторингу работы QoS.
Хотелось бы конечно еще информации по иерархическому QoS, да и по мониторингу работы QoS.
Спасибо, очень качественная статья. Пользуюсь Linux, как я понимаю, полисинг и шейпинг — это такая себе теоретическая теория, а на практике есть алгоритм (например, HTB), который все и реализует. Ну и еще момент — у нас для качественного доступа в тот же Интернет на маршрутизаторе (linux) пришлось делать буфер поменьше, чтобы пакеты дропались а не ставились в очередь. Если не ошибаюсь, нехорошее явление называется bufferbloat (раздувание буфера), и встречается не так редко.
Собственно, как я понимаю, весь DiffServ QoS строится по сути на одной вещи — на способности TCP сессий понижать скорость при потере пакетов.
Собственно, как я понимаю, весь DiffServ QoS строится по сути на одной вещи — на способности TCP сессий понижать скорость при потере пакетов.
полисинг и шейпинг — это такая себе теоретическая теория, а на практике есть алгоритм (например, HTB)
HTB — это ни что иное, как реализация Tokent Bucket.
Вопрос с длиной буфера тревожит каждого инженера и архитектор, разработчика и дизайнера. От вендора до конечного оператора. Это всегда компромис между тем, чтобы дропнуть пакет или доставить любой ценой, даже если поздно.
Собственно, как я понимаю, весь DiffServ QoS строится по сути на одной вещи — на способности TCP сессий понижать скорость при потере пакетов.
Только Congestion avoidance часть строится на особенностях TCP. То, как забирать пакеты из очередей, как шейпить, как классифицировать, на TCP не завязано напрямую. QoS гораздо шире.
Более того, около 10 лет назад функция Congestion Avoidance была вовсе под вопросом, потому что TCP использовался для сёрфинга — короткоживущих сессий с небольшим объёмом передаваемых данных — потеря здесь вызывает только ретрансмит — снижать нечего. Но в наше время видеоконтента его позиции восстановились)
не будет ли рынок двигаться в сторону разработки DPI и автоматизации конфигурирования QoS на ходу так сказать, в связи с постепенных уходом от сетевого нейтралитета операторов, которые тоже хотят денег?)
Разговаривать конечно можно будет предметно после того, как законники в США отрегулирует процессы контроля предоставления сервиса, взывания за этого платы и в принципе рамки дозволенного… и спустя пару лет будет видно где бабки оседают… НО какое место во всём этом займёт QoS уже сейчас интересно… а вдруг все просто раздуют себе трубы и будут только шейпингом заниматься…
Разговаривать конечно можно будет предметно после того, как законники в США отрегулирует процессы контроля предоставления сервиса, взывания за этого платы и в принципе рамки дозволенного… и спустя пару лет будет видно где бабки оседают… НО какое место во всём этом займёт QoS уже сейчас интересно… а вдруг все просто раздуют себе трубы и будут только шейпингом заниматься…
Спасибо. Интересная статья
Не понял tr-tcm. Завтра на свежую голову перечитаю, может дойдёт :)
Вопрос: а есть ли смысл в QoS в одноранговой сети? Примеры-то все с кучей маршрутизаторов. В каких случаях нужно QoS на коммутаторах настраивать?
Не понял tr-tcm. Завтра на свежую голову перечитаю, может дойдёт :)
Вопрос: а есть ли смысл в QoS в одноранговой сети? Примеры-то все с кучей маршрутизаторов. В каких случаях нужно QoS на коммутаторах настраивать?
В разделе Two Rate — Three Color Marking надо поправить картинки. Текст на них не соответствует смыслу статьи.
В тексте сказано, что «Если монет в ведре C не хватает — пакет помечается жёлтым, и из ведра P вынимаются B монет. », а на картинке — «Если монет в ведре С не хватает, а в Р хватает, вынимаются монеты из обоих.». Потом на второй картине сказано «Пока монет в ведре С хватает, они вынимаются только оттуда». А в статье сказано, что в этом случае монеты вынимаются из обоих ведер.
В тексте сказано, что «Если монет в ведре C не хватает — пакет помечается жёлтым, и из ведра P вынимаются B монет. », а на картинке — «Если монет в ведре С не хватает, а в Р хватает, вынимаются монеты из обоих.». Потом на второй картине сказано «Пока монет в ведре С хватает, они вынимаются только оттуда». А в статье сказано, что в этом случае монеты вынимаются из обоих ведер.
Марат, спасибо тебе за твой труд!
Помнится, году так в 2004-5м у нас начался взрывной рост трафика в нашей корпоративной сети, а соответственно и бум проблем: квакающий голос, рвущиеся факсы, отпадывающие сессии и т.п.
Наш главадмин, мой гуру и вообще, сказал мне тогда эти три заветные буквы «QoS», дал типовой конфиг, и подсказал направления раскопок. После неделизапоя изучения и тестов наконец-то залил конфиг на роутеры в продакшн и, О чудо!, все стало летать, голос просто пел, видео лилось ручьем, факсы порхали как птички, сессии хоть и подтормаживали иногда, но все равно стабильно работали «без единого разрыва». В общем начался некий цифровой коммунизм.
Далее, начал рыть L2 QoS, познакомился с «технологией для домохозяек» auto qos, в общем горизонтально расширял DS-Domain… Далее, когда пришли роутеры Huawei, и начал переносить политику QoS на них, оказалось, что, благодаря стараниям инженеров Cisco и их «технологиям для домохозяек», я знаю только самые верхушки предмета, а для продукции Уаувей нужны более глубокие знания…
В общем, процесс продолжается, и благодаря тебе и твоему труду такие как я получают новые векторы изучения и мотивацию. Спасибо тебе еще раз и продолжай в том же духе!
Далее хочется уже увидеть более подробные реализации на примере некой гетерогенной сети, причем начиная «с низов», т.е. с оконечного оборудования, L2-сегмента, перетекающего на MLS и далее на роутинг… В общем, полный цикл…
Помнится, году так в 2004-5м у нас начался взрывной рост трафика в нашей корпоративной сети, а соответственно и бум проблем: квакающий голос, рвущиеся факсы, отпадывающие сессии и т.п.
Наш главадмин, мой гуру и вообще, сказал мне тогда эти три заветные буквы «QoS», дал типовой конфиг, и подсказал направления раскопок. После недели
Далее, начал рыть L2 QoS, познакомился с «технологией для домохозяек» auto qos, в общем горизонтально расширял DS-Domain… Далее, когда пришли роутеры Huawei, и начал переносить политику QoS на них, оказалось, что, благодаря стараниям инженеров Cisco и их «технологиям для домохозяек», я знаю только самые верхушки предмета, а для продукции Уаувей нужны более глубокие знания…
В общем, процесс продолжается, и благодаря тебе и твоему труду такие как я получают новые векторы изучения и мотивацию. Спасибо тебе еще раз и продолжай в том же духе!
Далее хочется уже увидеть более подробные реализации на примере некой гетерогенной сети, причем начиная «с низов», т.е. с оконечного оборудования, L2-сегмента, перетекающего на MLS и далее на роутинг… В общем, полный цикл…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сети для самых матёрых. Часть пятнадцатая. QoS