1  # 2. Механизмы DiffServ
  2  
  3  Что же собой являет DiffServ и почему он выигрывает у IntServ?
  4  
  5  Если очень просто, то трафик делится на классы. Пакет на входе в каждый узел классифицируется и к нему применяется набор инструментов, который по-разному обрабатывает пакеты разных классов, таким образом обеспечивая им разный уровень сервиса.
  6  
  7  Но просто [не будет](https://cs5.pikabu.ru/images/big_size_comm/2015-11_1/1446439461128686990.jpg).
  8  
  9  В основе DiffServ лежит идеологически выдержанная в традициях IP концепция **PHB — Per-Hop Behavior**. Каждый узел по пути трафика самостоятельно принимает решение о том, как вести себя относительно пришедшего пакета, на основе его заголовков.  
 10  Действия маршрутизатора с пакетом назовём моделью поведения \(**Behavior**\). Количество таких моделей детерминировано и ограничено. На разных устройствах модели поведения по отношению к одному и тому же трафику могут отличаться, поэтому они и per-hop.  
 11  Понятия **Behavior** и **PHB** я буду использовать в статье как синонимы.
 12  
 13  > Тут есть лёгкая путаница. PHB — это с одной стороны общая концепция независимого поведения каждого узла, с другой — конкретная модель на конкретном узле. С этим мы ещё разберёмся.
 14  
 15  ![](../.gitbook/assets/image-66.png)
 16  
 17  Модель поведения определяется набором инструментов и их параметров: Policing, Dropping, Queuing, Scheduling, Shaping.  
 18  Используя имеющиеся модели поведения, сеть может предоставлять различные классы сервиса \(**Class of Service**\).
 19  
 20  То есть разные категории трафика могут получить разный уровень сервиса в сети путём применения к ним разных PHB.
 21  
 22  Соответственно прежде всего нужно определить к какому классу сервиса относится трафик — классификация \(**Classification**\).
 23  
 24  Каждый узел самостоятельно классифицирует поступающие пакеты.
 25  
 26  ![](../.gitbook/assets/image-159.png)
 27  
 28  После классификации происходит измерение \(**Metering**\) — сколько битов/байтов трафика данного класса пришло на маршрутизатор.
 29  
 30  На основе результатов пакеты могут окрашиваться \(**Coloring**\): зелёный \(в рамках установленного лимита\), жёлтый \(вне лимита\), красный \(совсем берега попутал\).
 31  
 32  ![](../.gitbook/assets/image-149.png)
 33  
 34  Если необходимо, далее происходит полисинг \(**Policing**\) \(уж простите за такую кальку, есть вариант лучше — пишите, я поменяю\). Полисер на основе цвета пакета назначает действие по отношению к пакету — передать, отбросить или перемаркировать.
 35  
 36  ![](../.gitbook/assets/image-16.png)
 37  
 38  После этого пакет должен попасть в одну из очередей \(**Queuing**\). Для каждого класса сервиса выделена отдельная очередь, что и позволяет их дифференцировать, применяя разные PHB.
 39  
 40  Но ещё до того, как пакет попадёт в очередь, он может быть отброшен \(**Dropper**\), если очередь заполнена.
 41  
 42  Если он зелёный, то он пройдёт, если жёлтый, то его вполне вероятно, отбросят, если очередь полна, а если красный — это верный смертник. Условно, вероятность отбрасывания зависит от цвета пакета и наполненности очереди, куда он собирается попасть.
 43  
 44  ![](../.gitbook/assets/image-20.png)
 45  
 46  На выходе из очереди работает шейпер \(**Shaper**\), задача которого очень похожа на задачу полисера — ограничить трафик до заданного значения.
 47  
 48  Можно настроить произвольные шейперы для отдельных очередей или даже внутри очередей.  
 49  Об отличии шейпера от полисера в главе [Ограничение скорости](https://github.com/eucariot/SDSM/tree/18977ba74c4c0ba820de2c89dcdb904360d5c5d2/15.-qos/8.-ogranichenie-skorosti/sheiping-protiv-polisinga.md).
 50  
 51  Все очереди в итоге должны слиться в единый выходной интерфейс.
 52  
 53  Вспомните ситуацию, когда на дороге 8 полос сливаются в 3. Без регулировщика это превращается в хаос. Разделение по очередям не имело бы смысла, если бы на выходе мы имели то же, что на входе.  
 54  Поэтому есть специальный диспетчер \(**Scheduler**\), который циклически вынимает пакеты из разных очередей и отправляет в интерфейс \(**Scheduling**\).  
 55  На самом деле связка набора очередей и диспетчера — самый главный механизм QoS, который позволяет применять разные правила к разным классам трафика, одним обеспечивая широкую полосу, другим низкие задержки, третьим отсутствие дропов.
 56  
 57  Далее пакеты уже выходят на интерфейс, где происходит преобразование пакетов в поток битов — сериализация \(**Serialization**\) и далее сигнал среды.
 58  
 59  ![](../.gitbook/assets/image-162.png)
 60  
 61  В DiffServ поведение каждого узла независимо от остальных, нет протоколов сигнализации, которые бы сообщили, какая на сети политика QoS. При этом в пределах сети хотелось бы, чтобы трафик обрабатывался одинаково. Если всего лишь один узел будет вести себя иначе, вся политика QoS псу под хвост.
 62  
 63  Для этого, во-первых, на всех маршрутизаторах, настраиваются одинаковые классы и PHB для них, а во-вторых, используется маркировка \(**Marking**\) пакета — его принадлежность определённому классу записывается в заголовок \(IP, MPLS, 802.1q\).  
 64  И красота DiffServ в том, что следующий узел может довериться этой маркировке при классификации.
 65  
 66  Такая зона доверия, в которой действуют одинаковые правила классификации трафика и одни модели поведения, называется домен DiffServ \(**DiffServ-Domain**\).
 67  
 68  ![](../.gitbook/assets/image-39.png)
 69  
 70  Таким образом на входе в домен DiffServ мы можем классифицировать пакет на основе 5-Tuple или интерфейса, промаркировать \(**Remark/Rewrite**\) его согласно правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
 71  
 72  То есть явной сигнализации в DiffServ нет, но узел может сообщить все следующим, какой класс нужно обеспечить этому пакету, ожидая, что тот доверится.
 73  
 74  На стыках между DiffServ-доменами нужно согласовывать политики QoS \(или не нужно\).  
 75  Целиком картина будет выглядеть примерно так:
 76  
 77  ![](../.gitbook/assets/image-30.png)
 78  
 79  {% hint style="info" %}
 80  Чтобы было понятно, приведу аналог из реальной жизни.
 81  
 82  Перелёт на самолёте \(не Победой\).
 83  
 84  Есть три класса сервиса \(CoS\): Эконом, Бизнес, Первый.
 85  
 86  При покупке билета происходит классификация \(Classification\) — пассажир получает определённый класс сервиса на основе цены.
 87  
 88  В аэропорту происходит маркировка \(Remark\) — выдаётся билет с указанием класса.
 89  
 90  Есть две модели поведения \(PHB\): Best Effort и Premium.
 91  
 92  Есть механизмы, реализующие модели поведения: Общий зал ожидания или VIP Lounge, микроавтобус или общий автобус, удобные большие сиденья или плотностоящие ряды, количество пассажиров на одну борт-проводницу, возможность заказать алкоголь.
 93  
 94  В зависимости от класса назначаются модели поведения — эконому Best Effort, Бизнесу — Premium базовый, а Первому — Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX! При этом два Premium отличаются тем что, в одном дают бокал полусладкого, а в другом безлимит Бакарди.
 95  
 96  Далее по приезду в аэропорт все заходят через одни двери. Тех, кто попытался провезти с собой оружие или не имеет билета, не пускают \(Drop\). Бизнес и эконом попадают в разные залы ожидания и разный транспорт \(Queuing\). Сначала на борт пускают Первый класс, потом бизнес, потом эконом \(Scheduling\), однако потом они в пункт назначения все летят одним самолётом \(интерфейс\).
 97  
 98  В этом же примере перелёт на самолёте — это задержка передачи \(Propagation\), посадка — задержка сериализации \(Serialization\), ожидание самолёта в залах — Queuing, а паспортный контроль — Processing. Заметьте, что и тут Processing Delay обычно пренебрежимо мал в масштабах общего времени.
 99  
100  Следующий аэропорт может обойтись с пассажирами совсем иначе — его PHB отличается. Но при этом если пассажир не меняет авиакомпанию, то, скорее всего, отношение к нему не поменяется, потому что одна компания — один DiffServ-domain.
101  {% endhint %}
102  
103  Как вы могли уже заметить, DiffServ предельно \(или беспредельно\) сложен. Но всё описанное выше, мы разберём. При этом в статье я не буду вдаваться в нюансы физической реализации \(они могут различаться даже на двух платах одного маршрутизатора\), не буду рассказывать про HQoS и MPLS DS-TE.
104  
105  Порог входа в круг инженеров, понимающих технологию, для QoS значительно выше, чем для протоколов маршрутизации, MPLS, или, прости меня Радья, STP.  
106  И несмотря на это DiffServ заслужил признание и внедрение на сетях по всему миру, потому что, как говорится, хайли скэлэбл.  
107  Всю дальнейшую часть статьи я буду разбирать только DiffServ.
108  
109  Ниже мы разберём все инструменты и процессы, указанные на иллюстрации.
110  
111  ![](../.gitbook/assets/image-105.png)
112  
113  По ходу раскрытия темы некоторые вещи я буду показывать на практике.
114  
115  Работать мы будем вот с такой сетью:
116  
117  ![](../.gitbook/assets/image-174.png)
118  
119  Trisolarans — это клиент провайдера linkmeup с двумя точками подключения.
120  
121  Жёлтая область — это DiffServ-домен сети linkmeup, где действует единая политика QoS.  
122  Linkmeup\_R1 — это CPE устройство, которое находится под управлением провайдера, а потому в доверенной зоне. С ним поднят OSPF и взаимодействие происходит через чистый IP.  
123  В пределах ядра сети MPLS+LDP+MP-BGP с L3VPN, растянутый от Linkmeup\_R2 до Linkmeup\_R4.  
124  Все остальные комментарии я буду давать по мере необходимости.
125  
126  [_Файл начальной конфигурации_](https://docs.google.com/document/d/e/2PACX-1vRmqX4Zn20LhoAj-cmlZJq9XIB3YCE6VVgrh0Fa1E3cCW22R2S2xM4xIZu4PiTjBFvqulNLilmoaH7J/pub).
127