Холодный старт
Когда пользователь вводит доменное имя в браузере или запускает приложение, начинается не мгновенная магия — а многоступенчатый процесс разрешения. Система сначала проверяет локальный кэш устройства: браузер, операционная система, резолвер на уровне ядра. Если записи там нет, запрос уходит дальше — к рекурсивному DNS-серверу провайдера или публичному resolver'у вроде Cloudflare.
Первый запуск всегда медленнее. Это cold cache: процессору нужно не только дождаться ответа от сервера, но и пройти через рукопожатия TCP/TLS, если используется защищённый протокол. После этого результат сохраняется в кэше на время TTL — Time To Live. Если он равен 300 секундам, следующие треть часа запросы будут идти почти мгновенно: система просто вытаскивает адрес из памяти.
В мобильной среде этот механизм работает по-другому. Сети 4G и 5G имеют другую архитектуру передачи данных, и DNS-серверы операторов часто перегружены. По данным исследований, типичная задержка на Wi-Fi составляет 20–50 миллисекунд, на 4G/LTE — 50–150 мс, а на 3G — уже 200–500 мс. На плохо покрытых участках цифра может перевалить за секунду. Это напрямую влияет на время загрузки приложения: если DNS тратит полсекунду, а приложение делает десять запросов к разным сервисам — пользователь ждёт около пяти секунд до того, как интерфейс отрисует что-то полезное.
Переключения и потери пакетов
Мобильные устройства постоянно меняют точку подключения. Пользователь идёт через улицу, сигнал пропадает, телефон переключается с одной вышки на другую, или оператор предлагает роуминг. Каждое такое переключение может вызвать потерю DNS-сессии или сброс кэша. Приложение вынуждено заново запрашивать адрес сервера — и снова платит за cold cache.
Существует ещё один нюанс: некоторые мобильные сети автоматически переключают протокол с UDP на TCP при больших ответных пакетах или нестабильной связи. TCP надежнее, но медленнее из-за необходимости установки соединения и подтверждения каждого пакета. Это добавляет несколько десятков миллисекунд к каждому запросу, что на фоне общей задержки уже заметно.
Провайдеры используют свои DNS-серверы — например, стандартные для оператора мобильной связи. Эти сервера могут быть географически удалены от пользователя или перегружены во время пиковых нагрузок. В результате часть абонентов получает старый IP, часть — новый. Это создаёт эффект «хаотичных задержек»: у одного человека сайт грузится нормально, у другого — зависает.
Кэширование на уровне сети тоже имеет ограничения. Авторитетные DNS-серверы отвечают не мгновенно: они могут обрабатывать запросы по очереди или иметь очередь из тысяч pending-запросов во время всплесков активности. Если запись выпала из кэша, резолвер вынужден заново обходить всю цепочку — от root-зоны до авторитетного сервера. Это увеличивает latency и расходует пропускную способность канала.
Оптимизация на уровне устройства
Некоторые приложения пытаются обойти ограничения мобильного интернета. Например, они подключаются к публичным DNS-серверам вроде 8.8.8.8 или 1.1.1.1, минуя провайдерскую инфраструктуру. Это снижает задержку, если сервер находится ближе географически. Но есть обратная сторона: публичные резолверы тоже могут быть перегружены или блокироваться при плохом соединении.
Операционные системы тоже кэшируют DNS. На Android это сервис resolv.conf, на iOS — встроенный механизм resolver'а Apple. Если пользователь вручную меняет настройки сети или использует VPN, старые записи в кэше могут устареть быстрее, чем ожидается. Это создаёт ситуации, когда исправленный домен недоступен для части пользователей, пока не истечёт TTL или не произойдёт принудительное обновление.
В 5G-сетях исследуются подходы к размещению DNS прямо на edge — ближе к базовой станции. Виртуализированная инфраструктура позволяет сократить путь запроса и уменьшить задержку, особенно для микромаштабных сервисов mMTC (massive machine-type communications). Но это требует дополнительных затрат на оборудование и настройку. Пока большинство операторов опираются на традиционную архитектуру с центральными резолверами.
Безопасность и её цена
Существуют альтернативные протоколы DNS: DoH — DNS over HTTPS, DoT — DNS over TLS. Они шифруют трафик, защищая от подмены записей. Но шифрование добавляет время на рукопожатие и расшифровку. На мобильных сетях это может увеличивать задержку ещё на 50–100 миллисекунд.
В некоторых случаях операторы блокируют запросы к публичным DNS, предпочитая использовать свои внутренние серверы. Это снижает риски утечек или подмены адресов, но увеличивает latency из-за удалённости инфраструктуры. Пользователю приходится выбирать между скоростью и безопасностью — хотя в идеале система должна обеспечивать то и другое одновременно.
Иногда задержки вызваны не инфраструктурой, а качеством сигнала. На границе зоны покрытия телефон пытается удерживать соединение, пакеты теряются или дублируются. Резолвер получает искажённые ответы или вовсе теряет сессию. Пользователь видит ошибку «не удалось разрешить домен», хотя сервер работает нормально.
Что происходит в пиковые моменты
Во время спортивных трансляций, концертов или других событий тысячи пользователей одновременно пытаются подключиться к одному и тому же контенту. DNS-серверы сталкиваются с резким скачком нагрузки. Очередь запросов растёт, время ответа увеличивается. Если сервер не масштабируется автоматически, он начинает отваливаться или отвечать через секунды — что для мобильного приложения равносильно таймауту.
Провайдеры обычно имеют резервные решения: переключение на дополнительные узлы, балансировку нагрузки между регионами. Но если все узлы находятся в одном дата-центре или одной географической зоне, это не помогает. Нужно распределённое присутствие резолверов по всему миру — как у крупных публичных операторов.
Для разработчиков мобильных приложений это означает необходимость учитывать DNS-задержки при проектировании архитектуры. Не все запросы должны идти к одному и тому же серверу: можно использовать CDN с локальными узлами, которые сами управляют разрешением адресов. Или реализовать повторные попытки с экспоненциальной задержкой — если первый запрос не прошёл, подождать несколько секунд и отправить второй.
Итог без выводов
DNS в мобильных сетях работает иначе, чем на стационарном интернете. Задержки возникают не потому, что технология устарела, а из-за ограничений беспроводной связи, архитектуры сети и поведения пользователей. Первый запрос всегда медленнее — это не баг, а особенность cold cache. Переключения между вышками и операторами сбрасывают кэш, увеличивая время загрузки.
Операторы и разработчики пытаются решить эти проблемы через кэширование, оптимизацию резолверов и распределённую инфраструктуру. Но пока мобильные устройства вынуждены балансировать между скоростью, безопасностью и надёжностью. И пока пользователи остаются с задержками, которые кажутся случайными, но имеют вполне понятные технические причины.