СДСМ-15. О качестве обслуживания.
Теперь с возможностью Запросы на извлечение .
И вот мы подошли к теме QoS. Знаете почему только сейчас и почему это будет заключительная статья всего курса СДСМ? Потому что качество обслуживания чрезвычайно сложно.
Сложнее, чем все, что случалось раньше в цикле.
Это не какой-то волшебный архиватор, который ловко на лету сожмёт трафик и запихнет ваш гигабит в стомегабитный аплинк.
QoS — это пожертвование чем-то ненужным, заталкивание негодного в рамки дозволенного.
QoS настолько опутано ореолом шаманства и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование, полагая, что достаточно кидать деньги на проблемы и бесконечно расширять ссылки.
Правда, они еще не осознают, что при таком подходе они неизбежно потерпят неудачу.
Либо бизнес начнет задавать неудобные вопросы, либо возникнет масса проблем, которые почти не связаны с шириной канала, а напрямую зависят от эффективности его использования.
Ага, VoIP активно машет рукой из-за кулис, а мультикастовый трафик саркастически похлопывает по спине.
Поэтому давайте просто осознавать, что QoS — это необходимость, вам так или иначе придется этому научиться, и почему бы не начать сейчас, в спокойной обстановке.
Содержание 1. Как определяется качество обслуживания?
- Потери
- Задержки
- Джиттер
- Лучшее усилие
- Интегрированные услуги
- Дифференцированные услуги
- Совокупное поведение
- Многопольный
- На основе интерфейса
- Опускание хвоста и опущение головы
- КРАСНЫЙ
- ВРЕД
- Первым прибыл, первым обслужен
- Приоритетная очередь
- Честная очередь
- По-круговой
- Формирование
- полиция
- Механизмы «дырявого» ведра и ведра токенов
Прежде чем читатель нырнет в эту дыру, я дам ему три рекомендации:1. Как определяется качество обслуживания? Компании ожидают, что сетевой стек будет просто хорошо выполнять свою простую функцию — доставлять поток битов от одного хоста к другому: без потерь и в предсказуемое время.
- Не все проблемы можно решить расширением полосы пропускания.
- QoS не расширяет полосу пропускания.
- QoS об управлении ограниченными ресурсами.
Из этого короткого предложения вы можете получить все показатели качества сети:
- Потери
- Задержки
- Джиттер
Потери
Эта метрика показывает, сколько пакетов, отправленных источником, достигло места назначения.Причиной потерь могут быть проблемы с интерфейсом/кабелем, перегрузка сети, битовые ошибки, блокировка правил ACL. Приложение решает, что делать в случае убытков.
Он может игнорировать их, как в случае телефонного разговора, когда запоздалый пакет больше не нужен, или может отправить его повторно, как это делает TCP, чтобы гарантировать точную доставку исходных данных.
Как управлять потерями, если они неизбежны, в главе «Управление перегрузками».
Как использовать отходы во благо – в главе «Предотвращение перегрузок».
Задержки
Это время, необходимое данным для перемещения от источника к месту назначения.
Общая задержка состоит из следующих компонентов.
- Задержка сериализации ( Задержка сериализации ) — время, за которое узел разложит пакет на биты и поместит его в ссылку на следующий узел.
Это определяется скоростью интерфейса.
Так, например, передача пакета размером 1500 байт через интерфейс 100Мбит/с займет 0,0001 с, а по интерфейсу 56 Кбит/с — 0,2 с.
- Задержка передачи сигнала в среде ( Задержка распространения ) является результатом пресловутого ограничения скорости распространения электромагнитных волн.
Физика не позволяет добраться от Нью-Йорка до Томска по поверхности планеты менее чем за 30 мс (реально около 70 мс).
- Задержки, вызванные QoS - это томление посылок в очередях( Задержка в очереди ) и последствия формирования ( Формирование задержки ).
Сегодня мы будем много и нудно говорить об этом в главе «Регулирование скорости».
- Задержка обработки пакетов ( Задержка обработки ) — время решить, что делать с пакетом: поиск, ACL, NAT, DPI — и доставить его с входного интерфейса на выходной интерфейс.
Но в тот день, когда Juniper разделил плоскости управления и данных в своем M40, задержка обработки стала незначительной.
Термин, относящийся к задержке, но не синоним – РТТ ( Время поездки туда и обратно ) — это путь туда и обратно.
При пинге и трассировке вы видите именно RTT, а не одностороннюю задержку, хотя значения коррелируют.
Джиттер
Разница в задержках между доставкой последовательных пакетов называется джиттером.
Как и задержка, джиттер не является проблемой для многих приложений.
И даже, казалось бы, какая разница – посылку доставили, что еще? Однако это важно для интерактивных сервисов.
Возьмем для примера ту же телефонию.
По сути, это оцифровка аналоговых сигналов с разделением на отдельные порции данных.
На выходе получается довольно равномерный поток пакетов.
На принимающей стороне имеется небольшой буфер фиксированного размера, в который сохраняются последовательно поступающие пакеты.
Для восстановления аналогового сигнала их необходимо определенное количество.
В условиях плавающих задержек следующий кусок данных может не прийти вовремя, что равносильно потере, и сигнал не может быть восстановлен.
Именно качество обслуживания вносит наибольший вклад в изменчивость задержки.
Об этом тоже много и нудно написано в тех же главах Ограничение скорости.
Это три основные характеристики качества сети, но есть еще две, которые также играют важную роль.
Незаказная доставка
Ряд приложений, таких как телефония, НАН , КЕС чрезвычайно чувствительны к доставке пакетов вне очереди, когда они приходят к получателю не в том порядке, в котором были отправлены.Это может привести к потере подключения, ошибкам и повреждению файловой системы.
И хотя доставка вне очереди формально не является характеристикой QoS, она определенно относится к качеству сети.
Даже при использовании протокола TCP, который толерантен к проблемам такого типа, возникают дублирующиеся подтверждения и повторные передачи.
Пропускная способность
Он не выделяется в качестве метрики качества сети, поскольку фактически его недостатки приводят к трем упомянутым выше.Однако в наших реалиях, когда для некоторых приложений он должен быть гарантирован или, наоборот, должен быть ограничен контрактом, а например MPLS TE резервирует его на протяжении всего LSP, о нем стоит упомянуть, хотя бы как о слабой метрике.
Механизмы контроля скорости мы рассмотрим в главах «Ограничение скорости».
Почему характеристики могут ухудшиться? Итак, начнем с очень примитивной идеи о том, что сетевое устройство (будь то коммутатор, маршрутизатор, межсетевой экран и т. д.) — это всего лишь еще один кусок трубы, называемый каналом связи, такой же, как медный провод или оптический кабель.
Тогда все пакеты пролетают в том же порядке, в котором они пришли, и не испытывают никаких дополнительных задержек — задерживаться негде.
Но на самом деле каждый маршрутизатор восстанавливает из сигнала биты и пакеты, что-то с ними делает (об этом мы пока не думаем), а затем преобразует пакеты обратно в сигнал.
Имеется задержка сериализации.
Но в целом это не страшно, потому что это навсегда.
Это не проблема, если ширина выходного интерфейса больше входного.
Например, на входе устройства есть гигабитный порт, а на выходе к этому же гигабитному порту подключена радиорелейная линия 620 Мбит/с? Никто не запретит отправлять гигабитный трафик по формально гигабитному каналу.
Ничего с этим не поделаешь - 380 Мбит/с прольются на пол.
Это потери.
Но при этом мне бы очень хотелось, чтобы самое худшее было показано - видео с YouTube, и телефонный разговор исполнительного директора с директором завода не прерывался и даже не прохрипел.
Хотелось бы, чтобы у голоса была выделенная линия.
Или имеется пять входных интерфейсов и один выходной интерфейс, и одновременно пять узлов начали пытаться отправить трафик одному получателю.
Добавим щепотку теории VoIP (статья, о которой никто никогда не писал) — она очень чувствительна к задержкам и их вариациям.
Если для TCP-потока видео с youtube (на момент написания QUIC - пока остается экспериментом) задержки даже в секунды ничего не стоят благодаря буферизации, тогда директор после первого же такого разговора с Камчаткой вызовет к себе начальника техотдела.
В прежние времена, когда автор цикла еще делал домашнее задание по вечерам, проблема стояла особенно остро.
Модемные соединения были скорость 56к .
А когда на такое соединение приходил полуторакилобайтный пакет, он занимал всю линию на 200 мс.
Никто больше не мог пройти в этот момент. Голос? Нет, не слышал.
Вот почему вопрос MTU так важен — пакет не должен занимать интерфейс слишком долго.
Чем медленнее, тем меньше требуется MTU. Это задержки.
Сейчас канал свободен и задержка небольшая, через секунду кто-то начал скачивать большой файл и задержки увеличились.
Это дрожание.
Таким образом, необходимо, чтобы голосовые пакеты пролетали по трубе с минимальными задержками, а youtube подождет. Доступные 620 Мбит/с необходимо использовать для передачи голоса, видео, а также для B2B-клиентов, покупающих VPN. Хочется, чтобы один трафик не угнетал другой, а значит, нужна гарантия пропускной способности.
Все вышеперечисленные характеристики универсальны относительно характера сети.
Однако существует три разных подхода к их достижению.
2. Три модели QoS
- Best Effort – никаких гарантий качества.
Все равны.
- IntServ – гарантия качества каждого потока.
Резервирование ресурсов от источника к получателю.
- DiffServ – без избыточности.
Каждый узел сам определяет, как обеспечить необходимое качество.
Лучшее усилие (BE)
Никаких гарантий.Самый простой подход к реализации QoS, с которого начались IP-сети и который практикуется до сих пор — иногда потому, что этого достаточно, но чаще потому, что о QoS никто не думал.
Кстати, когда вы отправляете трафик в Интернет, он там будет обрабатываться как BestEffort. Поэтому важный трафик, например телефонный разговор, может проходить через VPN, размещенные через Интернет, не очень надежно (в отличие от VPN, предоставляемой провайдером).
В случае с BE все категории трафика равноправны, ни одной из них не отдается предпочтение.
Соответственно, нет никаких гарантий ни по задержке/джиттеру, ни по пропускной способности.
У этого подхода несколько парадоксальное название — Best Effort, которое вводит в заблуждение новичка словом «лучший».
Однако фраза «Я сделаю все возможное» означает, что говорящий постарается сделать все, что в его силах, но ничего не гарантирует. Для реализации BE ничего не требуется — это поведение по умолчанию.
Его дешево производить, персоналу не нужны глубокие специфические знания, а QoS в этом случае никак не настроить.
Однако эта простота и статичность не приводит к тому, что подход Best Effort нигде не используется.
Он находит применение в сетях с высокой пропускной способностью, без перегрузок и всплесков трафика.
Например, на трансконтинентальных линиях или в сетях каких-то дата-центров, где нет переподписки.
Другими словами, в сетях без перегрузок и где нет необходимости особым образом обрабатывать какой-либо трафик (например, в телефонии), BE вполне уместен.
ИнтСерв
Предварительное резервирование ресурсов для потока на всем пути от источника до места назначения.В условиях растущего бессистемного Интернета отцы сетей MIT, Xerox и ISI решили добавить элемент предсказуемости, сохранив при этом его производительность и гибкость.
Таким образом, в 1994 году идея IntServ родилась в ответ на бурный рост трафика реального времени и развитие мультикаста.
Затем его сократили до IS. Название отражает стремление одновременно предоставлять услуги для оперативного и неоперативного типов трафика в одной сети, предоставляя первым приоритетное право использования ресурсов за счет резервирования полосы пропускания.
Сохранилась возможность повторного использования полосы пропускания, на которой все зарабатывают деньги и благодаря которой IP взлетел.
Миссия по резервированию была поручена протоколу RSVP, который для каждый поток резервирует полосу пропускания для каждый сетевое устройство.
Грубо говоря, прежде чем установить сеанс односкоростного трехцветного маркера или начать обмен данными, конечные хосты отправляют путь RSVP, указывающий необходимую пропускную способность.
И если обоим будет возвращен RSVP Resv, они смогут начать общаться.
При этом, если доступных ресурсов нет, то RSVP возвращает ошибку и хосты не могут общаться или будут идти через BE. Пусть теперь самые смелые из читателей представят, для чего любой Интернет-потоки сегодня будут сигнализироваться заранее.
Учтем, что для этого требуются ненулевые затраты процессора и памяти для каждый транзитный узел, задерживает фактическое взаимодействие на какое-то время, становится понятно, почему IntServ оказался практически мертворожденной идеей — нулевая масштабируемость.
В каком-то смысле современное воплощение IntServ — это MPLS TE с адаптированной для передачи меток версией RSVP — RSVP TE. Хотя здесь, конечно, не End-to-End и не per-flow. IntServ описан в РФК 1633 .
Документ в принципе интересен, чтобы оценить, насколько можно быть наивным в прогнозах.
Диффсерв
DiffServ сложен.Когда в конце 90-х стало ясно, что сквозной подход IntServ к IP потерпел неудачу, IETF созвал в 1997 году рабочую группу «Дифференцированные услуги», которая разработала следующие требования для новой модели QoS:
- Никакой тревоги (Аджос, отвечайте!).
- На основе агрегированной классификации трафика, вместо того, чтобы фокусироваться на потоках, клиентах и т. д.
- Имеет ограниченный и детерминированный набор действий по обработке трафика этих классов.
И дальше всю дорогу мы будем говорить только о DiffServ.
Стоит отметить, что имя DiffServ не является противоположностью IntServ. Оно отражает то, что мы дифференцируем услуги, предоставляемые различным приложениям, а точнее их трафик, другими словами, мы разделяем/дифференцируем эти виды трафика.IntServ делает то же самое — различает типы трафика BE и Real-Time, передаваемые в одной сети.
И IntServ, и DiffServ относятся к способам дифференциации услуг.
3. Механизмы DiffServ Что такое DiffServ и почему он лучше IntServ? Если говорить очень просто, трафик делится на классы.
Пакет, поступающий в каждый узел, классифицируется и к нему применяется набор инструментов, который по-разному обрабатывает пакеты разных классов, обеспечивая тем самым разные уровни обслуживания.
Но просто не будет .
DiffServ основан на идеологически последовательной концепции IP. PHB — поведение на каждом переходе .
Каждый узел на пути трафика самостоятельно решает, как вести себя в отношении входящего пакета, на основе его заголовков.
Назовем действия маршрутизатора с пакетом моделью поведения ( Поведение ).
Число таких моделей детерминировано и ограничено.
Модели поведения на разных устройствах по отношению к одному и тому же трафику может быть разными, поэтому они для каждого перехода.
Концепции Поведение И ПОБ В статье я буду использовать их взаимозаменяемо.
Здесь есть небольшая путаница.PHB — это, с одной стороны, общая концепция независимого поведения каждого узла, а с другой — конкретная модель на конкретном узле.
Мы разберемся с этим позже.
Модель поведения определяется набором инструментов и их параметрами: Policing, Dropping, Queuing, Scheduling, Shaping. Используя существующие модели поведения, сеть может предоставлять различные классы обслуживания ( Класс обслуживания ).
То есть разные категории трафика могут получать разные уровни обслуживания в сети, применяя к ним разные PHB. Соответственно, в первую очередь необходимо определить, к какому классу обслуживания относится трафик – классификация( Классификация ).
Каждый узел самостоятельно классифицирует входящие пакеты.
После классификации происходит измерение ( Измерение ) — сколько бит/байт трафика данного класса поступило на маршрутизатор.
По результатам сумки можно раскрасить ( Раскраска ): зеленый (в пределах установленного лимита), желтый (за пределами лимита), красный (совсем запутался).
Если необходимо, то происходит полисинг ( полиция ) (извините за такую кальку, есть вариант получше - напишите, поменяю).
Полисер в зависимости от цвета пакета назначает действие по отношению к пакету — пропустить, отбросить или перемаркировать.
После этого пакет должен оказаться в одной из очередей ( Очередь ).
Для каждого класса обслуживания выделяется отдельная очередь, что позволяет дифференцировать их за счет использования разных PHB. Но еще до того, как пакет попадет в очередь, он может быть отброшен ( капельница ), если очередь заполнена.
Если он зеленый, то пройдет, если желтый, то, скорее всего, его отбросят, если очередь заполнена, а если красный, то это верный смертник.
Условно вероятность отбрасывания зависит от цвета пакета и заполненности очереди, куда он собирается отправиться.
На выходе из очереди срабатывает шейпер ( Создатель ), задача которого очень похожа на задачу полисера — ограничивать трафик до заданного значения.
Вы можете настроить собственные формирователи для отдельных очередей или даже внутри очередей.
О разнице между шейпером и полисером в главе Speed Limit. Все очереди в конечном итоге должны объединиться в один выходной интерфейс.
Вспомните ситуацию, когда 8 полос на дороге сливаются в 3. Без регулировщика это превращается в хаос.
Разделение на очереди не имело бы смысла, если бы выходные данные были такими же, как входные.
Поэтому есть специальный диспетчер( Планировщик ), который циклически удаляет пакеты из разных очередей и отправляет их на интерфейс ( Планирование ).
По сути, сочетание набора очередей и диспетчера — это важнейший механизм QoS, который позволяет применять разные правила к разным классам трафика, обеспечивая одним широкую полосу пропускания, другим — низкую задержку, а третьим — отсутствие пропусков.
Далее пакеты поступают на интерфейс, где пакеты преобразуются в поток битов — сериализация ( Сериализация ), а затем средний сигнал.
В DiffServ каждый узел ведет себя независимо от других; не существует протоколов сигнализации, которые бы указывали, какая политика QoS в сети.
При этом внутри сети хотелось бы, чтобы трафик обрабатывался одинаково.
Если хотя бы один узел будет вести себя по-другому, вся политика QoS пойдет насмарку.
Для этого, во-первых, на всех роутерах настраиваются одинаковые классы и PHB для них, во-вторых, используется маркировка ( Маркировка ) пакета – в заголовке записана его принадлежность к определенному классу (IP, MPLS, 802.1q).
Прелесть DiffServ в том, что следующий узел может доверять этой маркировке для классификации.
Такая зона доверия, в которой действуют одни и те же правила классификации трафика и одни и те же модели поведения, называется доменом DiffServ ( DiffServ-домен ).
Таким образом, на входе в домен DiffServ мы можем классифицировать пакет на основе 5-кортежа или интерфейса, метки ( Замечание/перезапись ) это по правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
То есть в DiffServ нет явной сигнализации, но узел может сообщить всем, кто следует за ним, какой класс ему нужно предоставить этому пакету, ожидая, что ему будут доверять.
На стыках между доменами DiffServ политики QoS должны быть скоординированы (или нет).
Вся картина будет выглядеть примерно так: 
Чтобы было понятно, приведу аналог из реальной жизни.Как вы, возможно, уже заметили, DiffServ чрезвычайно (или бесконечно) сложен.Полет на самолете (не Победа).
Существует три класса обслуживания (CoS): Эконом, Бизнес, Первый.
При покупке билета происходит классификация – пассажир получает определенный класс обслуживания в зависимости от цены.
В аэропорту происходит маркировка (Remark) – выдается билет с указанием класса.
Есть две модели поведения (PHB): Best Effort и Premium. Есть механизмы, реализующие поведенческие модели: общий зал ожидания или VIP-зал, маршрутка или общий автобус, удобные большие сиденья или плотные ряды, количество пассажиров на одного бортпроводника, возможность заказа алкоголя.
В зависимости от класса присваиваются модели поведения – Эконом Best Effort, Бизнес – Премиум Базовый и Первый – Премиум SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX. ! При этом два Премиум-класса отличаются тем, что один дает стакан полусладкого, а другой - безлимитный Бакарди.
Затем по прибытии в аэропорт все входят через одни и те же двери.
Тех, кто пытался пронести с собой оружие или не имеет билета, не пустят (Дроп).
Бизнес и экономика попадают в разные залы ожидания и разный транспорт (Очереди).
Сначала на борт разрешен первый класс, затем Бизнес, затем Эконом (Расписание), но затем все они летят к месту назначения на одном самолете (интерфейс).
В этом же примере полет на самолете — это задержка передачи (Propagation), посадка — это задержка сериализации (Serialization), ожидание самолета в залах — Queuing, а паспортный контроль — Processing. Обратите внимание, что и здесь задержка обработки обычно незначительна в общем масштабе времени.
В следующем аэропорту отношение к пассажирам может быть совсем иное – у него другой PHB. Но при этом, если пассажир не поменяет авиакомпанию, то, скорее всего, отношение к нему не изменится, потому что одна компания — один DiffServ-домен.
Но мы проанализируем все описанное выше.
При этом в этой статье я не буду вдаваться в нюансы физической реализации (они могут отличаться даже на двух платах одного роутера) и не буду рассказывать о HQoS и MPLS DS-TE. Порог входа в круг инженеров, разбирающихся в технологии QoS, гораздо выше, чем для протоколов маршрутизации, MPLS или, прости меня Радя, STP. И несмотря на это, DiffServ заслужил признание и внедрение в сетях по всему миру, поскольку, как говорится, обладает высокой масштабируемостью.
В оставшейся части статьи я буду анализировать только DiffServ. Ниже мы разберем все инструменты и процессы, указанные на иллюстрации.
По мере развития темы буду кое-что показывать на практике.
Мы будем работать со следующей сетью: 
Trisolarans — клиент провайдера linkmeup с двумя точками подключения.
Желтая область — это домен DiffServ сети linkmeup, где применяется единая политика QoS. Linkmeup_R1 — это CPE-устройство, находящееся под контролем провайдера и, следовательно, в доверенной зоне.
С ним поднимается OSPF и взаимодействие происходит через чистый IP. Внутри ядра сети MPLS+LDP+MP-BGP с L3VPN, простирающееся от Linkmeup_R2 до Linkmeup_R4. Все остальные комментарии я предоставлю по мере необходимости.
4. Классификация и маркировка В своей сети администратор определяет классы обслуживания, которые он может предоставлять трафику.
Поэтому первое, что делает каждый узел при получении пакета, — это его классифицирует. Есть три способа:
- Совокупное поведение ( Б.
А.
) Просто доверьтесь маркировке посылки в ее заголовке.
Например, поле IP DSCP. Называется он так потому, что под одной меткой в поле DSCP агрегируются различные категории трафика, ожидающие одинакового поведения по отношению к себе.
Например, все сеансы SIP будут объединены в один класс.
Число возможных классов обслуживания и, следовательно, моделей поведения ограничено.
Соответственно, невозможно для каждой категории (а тем более для потока) выделить отдельный класс — его приходится агрегировать.
- На основе интерфейса
Все, что приходит на конкретный интерфейс, должно быть помещено в один класс трафика.
Например, мы точно знаем, что к этому порту подключен сервер базы данных и ничего больше.
А в другом — рабочее место сотрудника.
- Мультиполе ( М.
Ф.
) Анализируйте поля заголовка пакета — IP-адреса, порты, MAC-адреса.
Вообще говоря, произвольные поля.
Например, весь трафик, идущий в подсеть 10.127.721.0/24 на порту 5000, должен быть помечен как трафик, условно требующий обслуживания 5 класса.
На входе в домен DS мы никому не доверяем, поэтому классификация осуществляется вторым или третьим способом: на основе адресов, протоколов или интерфейсов определяется класс обслуживания и соответствующее ему цифровое значение.
На выходе из первого узла эта цифра кодируется в поле DSCP IP-заголовка (или в другом поле Traffic Class: MPLS Traffic Class, IPv6 Traffic Class, Ethernet 802.1p) — происходит перемаркировка.
Внутри домена DS этой маркировке принято доверять, поэтому транзитные узлы используют первый метод классификации (BA), который является самым простым.
Никакого сложного анализа заголовков, просто посмотрите на зафиксированное число.
На стыке двух доменов можно классифицировать по интерфейсу или MF, как я описал выше, а можно с оговорками полагаться на метку BA. Например, доверяйте всем значениям, кроме 6 и 7, и переименуйте 6 и 7 как 5. Такая ситуация возможна, когда провайдер подключает юридическое лицо, имеющее собственную политику маркировки.
Провайдер не против его сохранить, но в то же время не хочет, чтобы трафик попадал в тот класс, в котором передаются его пакеты сетевого протокола.
Совокупное поведение
BA использует очень простую классификацию – вижу число, понимаю класс.Так что это за номер? И в каком поле это написано?
- Класс трафика IPv6
- Класс трафика MPLS
- Ethernet 802.1p
Я имею в виду коммутирующий заголовок, на основании которого устройство определяет, куда отправить пакет, чтобы он приблизился к получателю.
Теги: #Сетевые технологии #Системное администрирование #стандарты связи #сети для самых маленьких #сети для самых маленьких
-
Все Вирусы Удалены С Пк Антивирусом Nortan
19 Oct, 24 -
Как Выбирать С Умом
19 Oct, 24 -
Изображение Catalyst 2.5
19 Oct, 24 -
Jquery Easyui Datagrid + Yii Framework
19 Oct, 24
