Что планируется

• Работа с метриками была в новинку, поэтому будет произведена работа по устранению избыточности некоторых метрик

• В конфигах заранее будут добавлены примеры дашбордов

• Небольшой рефакторинг хэндлеров DNS

• Будет вестись подготовка к рефакторингу (планируется разбить обработчик на 3 слоя выдачи: локальные, кэш, апстрим)

Информация

Github репозиторий: https://github.com/vesh95/dnso

DockerHub: https://hub.docker.com/repository/docker/vesh95/dnso/general

Просто подборка саунда, который вдохновлял все это время: https://music.yandex.ru/playlists/a3aa20b0-8d3a-4772-b883-96...

Выясняется, что ДНС не доставляет уцененные товары. Вообще. Именно на уценку доставки нет. Совсем нет.

Это можно было бы объяснить, если бы я брала технику он-лайн. Мол, непоняла, про недостатки везите обратно (так сказать фильтр тепленьких на голову покупателей). Но ведь:

А) год назад доставка была.

Б) покупаю оффлайн, все недостатки товара пощщупаны, увидены своими глазами.

В) ТОЛЬКО САМОВЫВОЗ.

Вызывать Яндекс-доставку для меня не вариант! Зимой вызывала, ну его нафиг. Одна печаль и нервы. Во-первых, мастурбеки, которым похрен, что и как везти. Везут хуже, чем мешок с картошкой. Таскают тоже неаккуратно. При замечаниях и/или просьбах - "моя твоя не понимать" и все. Любые аргументы не воспринимаются, компенсация на 200 рублей при следующем заказе от Яндекса за испорченные вещи выглядит насмешкой. Поэтому этот вариант не рассматриваю. При всем перечисленном Яндекс доставка ещё и дороже в три раза, чем в ДНС. Что сводит разницу между новым и уцененным девайсом к незначительной, а покупку с учётом всех принимаемых рисков - сомнительной выгоды.

Отдельно "порадовала" служба доставки ДНС и магазин. На мой вопрос, как я могла заранее узнать об отсутствии доставки на уценку? - Никак! На сайте об этом НИГДЕ не написано. Итог, техника не куплена. Просрано почти 4 часа моей жизни. Около трех занял путь туда/обратно и чуть более часа на разговоры с продавцами и службой доставки.

В связи с чем, вопрос к ДНС в чем логика? В чем смысл отказа от доставки уцененной крупногабаритной техники? Чтоб она и дальше стояла занимала место? Очень интересно понять в чем эффективность данного принятого Вами решения. Почему об этом на Вашем сайте нет ни слова? Что за изощренный вид неуважение к покупателям?

Я к чему все это. Доверие к ДНС было заоблачным.

Поэтому когда мне потребовалась зарядка для телефона в авто я сразу попиздовал к ним. Купил адаптер Dexp (насколько я знаю, это из СТМ) за 499 с быстрой зарядкой и провод, который поддерживает 100ват за 499 рублей.

Через пару смен адаптер перестал заряжать. Я подумал, что похуй. На следующий день купил такой же. Отработал два дня, и перестал заряжать.

Я подумал, ну похуй, стоимость чашки кофе, куплю еще. Купил еще два. один основной, другой запасной.

И КАК ЖЕ Я ОХУЕЛ, КОГДА ОБА ЭТИХ ПОДЕЛКИ ПЕРЕСТАЛИ РАБОТАТЬ.

КАЖДУЮ СУКА СМЕНУ Я ВТЫКАЮ ЭТО ГОВНО В ПРИКУРИВАТЕЛЬ В НАДЕЖДЕ, ЧТО ОНО БУДЕТ РАБОТАТЬ И КАЖДЫЙ РАЗ ЭТО ЕБАНАЯ ЛОТЕРЕЯ.

5 СМЕН СОРВАЛАСЬ ИЗ-ЗА ТОГО, ЧТО ЭТО КИТАЙСКОЕ ГОВНО НЕ РАБОТАЕТ. ТОЧНЕЕ РАБОТАЕТ, НО ВСЕГО ПАРУ ДНЕЙ. МНЕ ПРОСТО НЕГДЕ ЗАРЯДИТЬ СМАРТФОН И Я ПИЗДУЮ ДОМОЙ, НА СЛЕДУЮЩИЙ ДЕНЬ ПОЛУЧАЯ ПИЗДЮЛЕЙ, КОРРЕКТИРОВОК И ШТРАФОВ ОТ АДМИНИСТРАТОРОВ ПРОЕКТА.

Так.... К чему это я все.

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

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

Я - я. К- Консультант.

К:

- Чем я могу вам посочь?

Я:

- Скажите, на упаковке указана гарантия 18 месяцев. Это Так?

К:

- Ну, смотря, как использовать...

Я:

- Как их можно использовать? Заряжать смартфон в авто, это же их задача?

К:

- Ну если у вас авто не сертифицировано и не на гарантии...

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

На что он мне говорит:

- Ты чк думал дешевую зарядку купил и все? Ну ты че не врубаешься, что дешевая зарядка не будет работать. Возьми за 4999 и ваще проблем не будет. Если ты не знал, надо покупать зарядки за нормальную стоимость.

На что я ему отвечаю:

- На вашей заряде dexp указаны характеристики, она поддерживает быструю зарядку и гарантийный срок - 18 месяцев. Нет никаких ограничений по сроку или току. Это так?

- Да, но все зависит от эксплуатации.

- Я работаю в каршаринге, все машины обслужены и исправны. Но ваши зарядки горят каждый день.

И тут он выдает то, от чего у меня падает забрало и я хочу ему просто разбить кукуху.

- Ну если ты нищеброд, то у тебя не только зарядки, но я вся твоя жизнь будет гореть.

Я чуть не сорвался. Но ушел взял очередную зарядку, которая сгорит через пару дней. Но теперь я буду собирать чеки, упаковки и видеозаписи.

И дело не в стоимости. Дело в том, что ваша техника подводит не то чтобы в неподходящий момент.

ОНА ПОДВОДИТ ВСЕГДА

При этом нам предложили **обменять его на другой товар, но только с доплатой**, что вызывает закономерные вопросы: если товар действительно относится к категории, не подлежащей обмену/возврату, почему магазин готов его обменять на более дорогой?

Я дополнительно позвонил на горячую линию DNS и подробно объяснил ситуацию. Мне подтвердили, что цена на момент покупки действительно составляла около **3399 рублей**, а также сообщили, что в данной ситуации возврат возможен в установленный срок.

После этого я снова обратился в магазин и сообщил сотрудникам информацию, полученную от горячей линии. Управляющий магазина, **Баденов С. Б.**, тем не менее отказал в возврате и выдал отказ в письменном виде.

Отдельно меня удивило объяснение управляющего: якобы если бы мой отец оформил покупку **через приложение/сайт**, товар можно было бы вернуть, а поскольку пенсионер приобрёл его непосредственно в магазине, возврат невозможен.

**DNS, как это понимать?**

Почему покупатель, особенно пожилой человек, должен сначала разбираться в вашем приложении и оформлять заказ онлайн, чтобы получить возможность воспользоваться своими правами?

Почему один и тот же товар в один и тот же период продаётся по разной цене — **3399 рублей на сайте и 4000 рублей непосредственно в магазине**?

Почему покупателю не сообщили об этой разнице в цене в момент покупки?

На каком конкретно основании данный аэрогриль отнесён магазином к товару, который нельзя вернуть/обменять? Прошу предоставить ссылку именно на соответствующий пункт законодательства и объяснить, каким образом он применяется к **данной модели аэрогриля**, учитывая, что товар не вскрывался и не использовался.

И главное: почему сотрудники магазина сначала предлагают обмен на другой товар с доплатой, а затем утверждают, что товар вообще не подлежит обмену?

Прошу руководство DNS провести проверку по данной ситуации, проверить:

— цену данного товара на сайте и в магазине на **25.08.2026**;

— основания отказа в возврате;

— письменный отказ управляющего;

— консультацию, которую мы получили на горячей линии DNS;

— правомерность объяснения о том, что при покупке через сайт возврат возможен, а при покупке непосредственно в магазине — нет.

Мы не просим какого-то особого отношения из-за того, что покупатель пенсионер. Мы просим **одинакового и понятного отношения к покупателям и соблюдения законодательства о защите прав потребителей**.

DNS, пожалуйста, дайте публичный ответ по данной ситуации и объясните, на каком основании пенсионеру, купившему новый и нераспечатанный товар непосредственно в вашем магазине, отказано в возврате.

Документы, чек, письменный отказ магазина и подтверждение цены на сайте готовы предоставить.

номер заказа : Б-26220623

Судебный эксперт подтвердил: вандальные работы по подмене компонентов были выполнены профессионально прямо в сервисном центре DNS.

Итог для ритейлера закономерный. Суд удовлетворил иск потребителя и взыскал с ООО «ДНС Ритейл»:

Вместо ремонта одной карты DNS заплатит почти 450 тысяч рублей. Ссылка на дело: https://судебныерешения.рф/92997105/extended

(PS извините за использование AI)

UPDATE:

Многие спрашивают или даже обвиняют потребителя в том, что она сама подменила плату и другие компоненты. Однако у потребителя осталась видеозапись, сделанная при сдаче товара в сервисный центр DNS. На оригинальной плате видеокарты RTX 4080 присутствует маркировка V22047. При этом на подменённом «франкенштейне» (плате от RTX 4090) указана совсем другая маркировка — V22028. Таким образом, при раскадровке видео эту разницу в маркировках можно легко обнаружить и доказать подмену.

RTX4080 => https://www.dns-shop.ru/product/27ba47b83dfced20/videokarta-...

RTX4090 => https://www.dns-shop.ru/product/77ed192f2811ed20/videokarta-...

Сайт кажется простым: ввёл адрес, нажал Enter — и через мгновение видишь страницу. Но до этого момента браузер успевает проделать целую цепочку работы: найти сервер, установить соединение, получить HTML, загрузить дополнительные файлы и собрать из них изображение на экране.

Обычно мы не замечаем эти этапы. Они становятся заметны, когда сайт начинает тормозить. Задержка может появиться ещё до обращения к серверу — например, во время DNS-резолвинга, — или уже после получения ответа, когда браузер разбирает JavaScript и строит интерфейс.

Я выбрал эту тему, потому что хотел разобраться, что именно происходит между вводом адреса и появлением страницы. Разберём этот путь от адресной строки до первого отрисованного пикселя и посмотрим, на каком этапе может возникнуть задержка.

❯ Коротко: семь шагов одного клика

Прежде чем разбирать каждый этап подробно, полезно увидеть картину целиком.

1. Разбор URL — браузер понимает, что вы имеете в виду.

2. DNS-резолвинг — имя сайта превращается в IP-адрес.

3. Установка соединения — рукопожатия TCP и, для HTTPS, TLS.

4. HTTP-запрос и ответ — браузер спрашивает, сервер отвечает.

5. Разбор HTML, CSS и JavaScript — превращение кода в структуру.

6. Рендеринг — структура превращается в пиксели на экране.

7. Дозагрузка ресурсов — картинки, шрифты, кеш и CDN.

Дальше — подробно о каждом шаге.

❯ Сначала — вся цепочка загрузки страницы

Когда вы вводите что-то в адресную строку, браузер сначала решает: это адрес сайта или поисковый запрос. Если похоже на адрес — начинается разбор.

Полный URL состоит из нескольких частей.

• Протокол (http или https) — по какому «языку» будет вестись общение.

• Домен (например, timeweb.cloud) — имя сервера, к которому нужно обратиться.

• Порт (обычно скрыт: по умолчанию 80 для http и 443 для https) — «дверь», через которую сервер принимает соединения.

• Путь (/blog/article) — какой именно документ или раздел нужен.

• Параметры запроса (?id=123) — дополнительные данные для сервера.

• Якорь (#section) — часть страницы, к которой нужно прокрутить; сервер его даже не увидит, это забота браузера.

Прежде чем куда-то обращаться, браузер проверяет несколько вещей на месте: не сохранена ли страница в собственном кеше и не входит ли домен в список принудительного HTTPS. Это список сайтов, которые нельзя открывать по незащищенному http, даже если так написано в адресе, — он называется HSTS.

❯ Шаг 2. DNS: превращаем имя сайта в IP-адрес

Компьютеры и маршрутизаторы в интернете работают с числами — IP-адресами вида 192.0.2.1. Люди же запоминают имена: timeweb.cloud куда удобнее, чем набор цифр. Служба, которая связывает одно с другим, называется DNS — Domain Name System, или система доменных имен.

Чтобы найти IP-адрес нужного домена, браузер проходит цепочку проверок, и любая из них может дать готовый ответ и остановить поиск.

• Кеш браузера — может, этот адрес уже искали недавно.

• Кеш операционной системы — то же самое, но на уровне всей системы.

• Файл hosts — локальный список «имя → адрес», который можно отредактировать вручную.

• Рекурсивный DNS-резолвер — обычно сервер провайдера или публичный сервис вроде 1.1.1.1 или 8.8.8.8.

Если ни один из уровней не помог, в дело вступает сам резолвер. Он опрашивает корневые серверы (их адреса зашиты в каждый резолвер) и получает ссылку на серверы зоны — например, .cloud или .ru. Затем обращается к ним и получает ссылку уже на авторитетный сервер конкретного домена, который и отдает финальный ответ — IP-адрес. Результат резолвер запоминает на время, указанное в настройках домена (TTL), чтобы не повторять всю цепочку при следующем запросе.

Обычно DNS-запросы летают по протоколу UDP на порт 53 — он быстрее TCP, потому что не требует установки соединения. Часть современных браузеров и резолверов также умеет шифровать DNS-запросы через DNS-over-HTTPS или DNS-over-TLS, чтобы провайдер не видел, какие сайты вы посещаете.

Проверить, какой IP-адрес сейчас связан с доменом, можно самостоятельно. В терминале Linux и macOS для этого используют:

dig timeweb.cloud

В Windows аналогичную проверку можно выполнить командой:

nslookup timeweb.cloud

Команда покажет полученный IP-адрес и сведения об ответе DNS. Время полной загрузки страницы лучше смотреть отдельно — во вкладке Network в инструментах разработчика браузера.

❯ Шаг 3. Устанавливаем соединение: TCP и TLS

IP-адрес найден. Теперь браузеру нужно установить соединение с сервером. Для обычного HTTPS здесь участвуют два протокола: TCP отвечает за транспорт, а TLS — за шифрование.

Сначала — рукопожатие TCP, протокола, который отвечает за надежную доставку данных. Оно состоит из трех сообщений: клиент отправляет SYN («хочу соединиться»), сервер отвечает SYN-ACK («принято, я тоже готов»), клиент подтверждает ACK («отлично, начинаем»). После этого обмена соединение считается установленным.

Если сайт работает по HTTPS — а сегодня это подавляющее большинство сайтов — поверх TCP сразу начинается второе рукопожатие, уже TLS, протокола шифрования. Браузер отправляет Client Hello: какие версии TLS и шифры он поддерживает, и имя сайта, к которому обращается. Это нужно, чтобы сервер с несколькими доменами на одном IP понял, какой сертификат показать. Сервер отвечает Server Hello: выбранный шифр и сертификат, который браузер проверяет на подлинность — совпадает ли имя, не истек ли срок действия, подписан ли он доверенным центром сертификации. Если все сходится, стороны договариваются об общем ключе шифрования, и дальнейшее общение становится зашифрованным.

TLS 1.3 обычно требует меньше сетевых обменов, чем TLS 1.2, поэтому соединение может установиться быстрее. При повторном подключении браузер также способен возобновить ранее созданную сессию. Режим 0-RTT возможен только при определённых условиях и не является обязательной частью каждого соединения.

HTTP/3 работает поверх QUIC — транспорта на основе UDP. В QUIC транспортные механизмы и TLS тесно связаны, поэтому при установлении соединения можно сократить число сетевых обменов. Кроме того, потеря одного пакета не обязательно блокирует передачу независимых потоков, как это может происходить при использовании TCP.

❯ Шаг 4. Отправляем HTTP-запрос и получаем ответ

Соединение готово — можно отправлять сам запрос. Выглядит он примерно так: метод (чаще всего GET — «дай мне документ»), путь к нужной странице и набор заголовков. Заголовки — это служебная информация: какой браузер отправляет запрос, какой формат ответа он ожидает и какие cookies уже сохранены для этого сайта.

На стороне сервера запрос обычно проходит через несколько узлов. Балансировщик нагрузки распределяет его между несколькими машинами. Обратный прокси, например nginx, может сразу отдать закешированную копию страницы или передать запрос дальше — серверному приложению, которое обращается к базе данных за нужными данными. Ответ собирается в обратном порядке и уходит к браузеру.

Ответ сервера тоже состоит из нескольких частей. Код состояния показывает, как все прошло: 200 значит все хорошо, 301 — ресурс переехал, 404 — не найдено, 500 — ошибка на сервере. Дальше идут заголовки — например, тип содержимого или правила кеширования, — и тело ответа, обычно HTML-код страницы.

Важная деталь: то, как физически передаются запрос и ответ, зависит от версии HTTP. В HTTP/1.1 на одно соединение приходится один запрос за раз. Поэтому браузеры исторически открывали сразу несколько параллельных соединений к одному серверу — как правило, около шести, — чтобы грузить ресурсы одновременно. HTTP/2 решил эту проблему иначе: он умеет вести сразу много запросов и ответов в рамках одного соединения — это называется мультиплексированием. А еще он сжимает заголовки, чтобы не гонять одни и те же данные повторно. HTTP/3 пошел еще дальше и убрал саму причину проблемы, отказавшись от TCP в пользу QUIC.

❯ Шаг 5. Браузер разбирает HTML, CSS и JavaScript

Получив HTML, браузер не ждет, пока загрузится весь документ, — он начинает разбирать его сразу, по мере поступления данных. Из тегов строится DOM — дерево, отражающее структуру документа: какие элементы вложены друг в друга, какой у них текст и атрибуты.

Стоит браузеру встретить ссылку на таблицу стилей, он запускает параллельную загрузку CSS-файла. Разобранные стили складываются в похожее дерево — CSSOM, которое описывает, как должен выглядеть каждый элемент.

JavaScript может вмешаться в этот процесс. Обычный тег <script> способен приостановить разбор HTML до загрузки и выполнения файла. Атрибуты async и defer изменяют это поведение, но работают по-разному: async запускает скрипт сразу после его загрузки, а defer сохраняет порядок выполнения скриптов и запускает их после завершения разбора документа.

Когда DOM и CSSOM готовы, браузер объединяет их в дерево рендеринга — тоже похожее на DOM. Но без скрытых элементов вроде тех, что помечены display: none, и без служебных тегов вроде head.

❯ Шаг 6. Рендеринг: как дерево превращается в картинку

Дерево рендеринга описывает, что нужно показать, но изображением ещё не является. Сначала браузер рассчитывает размеры и координаты элементов, затем рисует их и собирает отдельные слои в итоговый кадр.

Сначала — layout, раскладка: для каждого элемента вычисляются точные размеры и координаты на странице. Затем — покраска (paint): элементы закрашиваются цветом, получают текст, границы, тени и фон, обычно на нескольких отдельных слоях. Последний этап — компоновка (compositing): все слои собираются в итоговое изображение, и часто эта работа перекладывается на видеокарту, что особенно заметно на анимациях и прокрутке.

Практическое следствие: если JavaScript потом меняет структуру или стили страницы, браузеру может понадобиться заново пройти часть этих этапов. Это стоит времени и может ощущаться как подтормаживание интерфейса. Именно поэтому в вопросах производительности веб-страниц часто советуют менять как можно меньше элементов на странице за один раз.

❯ Шаг 7. Дозагрузка ресурсов, кеширование и ускорение

Первый ответ сервера — обычно только HTML. Внутри него браузер находит ссылки на картинки, шрифты, дополнительные стили и скрипты и запрашивает их тоже, по возможности параллельно.

Чтобы не гонять одни и те же файлы по сети заново, существует несколько уровней кеширования. Браузер хранит уже загруженные файлы локально и, ориентируясь на заголовки вроде Cache-Control, решает, можно ли использовать сохраненную копию вместо нового запроса. Если сайт использует CDN — сеть серверов, распределенных географически, — статичные файлы отдаются с ближайшего к пользователю сервера, а не с одного центрального. Некоторые сайты дополнительно используют service worker — скрипт, который может перехватывать запросы браузера и обслуживать их из локального хранилища даже без подключения к интернету.

Небольшие, но полезные приемы ускорения — это подсказки браузеру вроде preconnect (заранее установить соединение с нужным сервером) или preload (заранее загрузить конкретный файл, который точно понадобится).

❯ Зачем это знать на практике

При диагностике медленной загрузки обычно начинают со вкладки Network в инструментах разработчика. Она показывает, сколько времени заняли DNS, установка соединения, ожидание ответа, загрузка и обработка ресурсов. Так можно понять, на каком именно участке появляется задержка. Если долго выполняется DNS-запрос, стоит проверить резолвер. Если сервер долго отвечает, причину нужно искать в приложении, базе данных или настройках кеша. Если задержка появляется уже при рендеринге, внимание стоит обратить на JavaScript и стили.

Для тех, кто выбирает хостинг или настраивает сервер, из всей этой цепочки видно: на скорость влияет буквально каждый шаг. Играют роль близость сервера к пользователю, поддержка современных версий HTTP и TLS, настройка кеширования. Эти решения измеряются в миллисекундах и складываются в разницу, которую замечает пользователь.

❯ Итоги

Между нажатием Enter и готовой страницей происходит гораздо больше, чем кажется. Браузер может сначала обратиться к кешу, затем найти IP-адрес через DNS, установить соединение, получить HTML и только после этого начать строить изображение страницы.

Поэтому медленная загрузка — это не одна универсальная проблема. Задержка может появиться на этапе DNS, при соединении с сервером, во время ожидания ответа или уже в браузере, когда выполняется JavaScript и перерисовывается интерфейс. Вкладка Network помогает отделить один случай от другого.

❯ Что почитать дальше

• MDN Web Docs, «How the web works» — подробный разбор всего пути запроса от адресной строки до отрисованной страницы (на английском языке).

• RFC 9110 (HTTP Semantics) и RFC 9114 (HTTP/3) — официальные спецификации для тех, кто хочет разобраться в деталях протоколов.

• Cloudflare Learning Center, статья «What is DNS» — доступное объяснение DNS-резолвинга с наглядной схемой.