Сайт кажется простым: ввёл адрес, нажал 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-резолвинга с наглядной схемой.

Это инструкция по установке сертификатов для владельцев ноутбуков и компьютеров с операционной системой Windows. Для корректной работы нужны корневые и выпускающие сертификаты

Установите корневые сертификаты

Откройте Госуслуги: https://www.gosuslugi.ru/crt

Установите каждый корневой сертификат по инструкции для Russian Trusted Root CA. Установка других сертификатов проводится аналогично

Скачайте корневые сертификаты → перейдите в папку «Загрузки» → извлеките сертификаты из архива → выберите Russian Trusted Root CA.cer → нажмите «Открыть» → выберите «Установить сертификат...»

В окне «Мастер импорта сертификатов» выберите «Текущий пользователь» → нажмите «Далее» → выберите «Поместить все сертификаты в следующее хранилище» → нажмите «Обзор» → выберите «Доверенные корневые центры сертификации» → нажмите «Далее»

В окне «Завершение мастера импорта сертификатов» нажмите «Готово» → выберите «Ок»

Если появится окно «Предупреждение системы безопасности» → нажмите «Да»

Установите выпускающие сертификаты

Установите каждый выпускающий сертификат по инструкции для Russian Trusted Sub CA. Установка других сертификатов проводится аналогично

Скачайте выпускающие сертификаты → перейдите в папку «Загрузки» → извлеките сертификаты из архива → выберите Russian Trusted Sub CA.cer → нажмите «Открыть» → выберите «Установить сертификат...»

В окне «Мастер импорта сертификатов» выберите «Текущий пользователь» → нажмите «Далее» → выберите «Автоматически выбрать хранилище на основе типа сертификата» → нажмите «Далее»

В окне «Завершение мастера импорта сертификатов» нажмите «Готово» → выберите «Ок»

Процедуру установки необходимо повторить для каждого выпускающего сертификата

Очистите кеш вашего браузера

Очистите кеш браузера на устройстве, с которого осуществляется доступ. Это необходимо для корректной работы с ресурсами, защищёнными сертификатами безопасности Минцифры

VK.RU стал основным адресом для пользователей «Вконтакте» // Коммерсантъ, 17.07.2026 (12:30)

VK.RU стал основным адресом для пользователей «Вконтакте» // Вконтакте, 17.07.2026

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

Переходите на vk.ru. Здесь все тот же «ВКонтакте», но быстрее и надежнее, чем vk.com.

Теперь давайте воспользуемся соцсетью, перейдя на одну из записей по ссылке или из колокольчика.

Ой, а что же это случилось? А как так вышло? Проверим, что же это за сценарии у нас не загружаются с CDN.

Ой, только недавно полученный сертификат уже отозван.

Я, пожалуй, никак комментировать это не буду.

• инфраструктуры и DevOps;

• Go, C#, Java;

• мобильной разработки;

• машинного обучения и работы с данными;

• тестирования и автоматизации QA;

• информационной безопасности;

• менеджмента и научпопа с фокусом на космонавтику и суперкомпьютеры;

• робототехники.

В рамках конференции пройдет отдельный трек «Робозон». Здесь роботы сортируют, рисуют, готовят и играют в настолки. Можно собрать свой мини-конвейер в DIY-зоне, устроить личный тест-драйв железным помощникам и посмотреть финал «Робозон» — хакатона по роботизации сортировочных центров. А между активностями — доклады об умной сортировке, стереозрении, поддержке сотни собственных устройств по измерению габаритов товаров и тестах ИИ-ускорителей.

А еще гостей ждут: IT-квесты, Burning Talks и Ozon DSGN. Обсудите карьеру с HR, заберите мерч и останьтесь на вечернюю часть. На одной площадке выступят Нейромонах Феофан, Кассета, ХЛЕБ, Jane Air, DJ Groove и Александр Анатольевич.

• Откройте Госуслуги в браузере Safari

  Если используете мобильное приложение «Госуслуги» — выйдите из него. Продолжите установку, открыв страницу https://www.gosuslugi.ru/crt в браузере Safari

• Скачайте профиль для Apple iOS → нажмите «Разрешить»

  Если процесс выполняется верно, появится сообщение о скачивании файла. В противном случае вы увидите окно с набором текстовых символов. Если это произошло, заново откройте страницу в браузере Safari и повторите загрузку в нём

• Перейдите в «Настройки» → выберите «Профиль загружен» → в окне «Установка профиля» нажмите «Установить»

  Установите сертификаты сразу после загрузки, иначе они удалятся автоматически

• Введите код-пароль для устройства → в окне «Предупреждение» нажмите «Установить» → в окне «Установка профиля» выберите «Установить» → в окне «Профиль установлен» нажмите «Готово»

После установки включите доверие сертификатам УЦ Минцифры

Включите доверие ко всем корневым сертификатам по инструкции для Russian Trusted Root CA. Для остальных сертификатов процедура обеспечения доверия аналогичная

• Перейдите в «Настройки» → выберите «Основные» → «Об этом устройстве» → «Доверие сертификатам» → включите доверие сертификату Russian Trusted Root CA, передвинув ползунок вправо

• В оповещении «Корневой сертификат» нажмите «Дальше»

Процедуру включения доверия нужно провести для каждого корневого сертификата

• Перейдите в раздел «Настройки» → выберите Safari

• В окне «Очистить историю и данные» нажмите «Очистить» → выберите «Закрытие вкладок»

Lets Encrypt добавил в пользовательское соглашение запрет на выдачу сертификатов для стран под санкциями США

https://habr.com/ru/news/1045878/

И вот печальный итог. Вчера посреди просмотра VK Video на ТВ выдается уведомление о том, что пропало соединение с интернетом. Я проверяю — соединение с интернетом есть, перезапускаю приложение и ТВ, и вижу такое.

Не удалось подтвердить именно отзыв сертификата, но признаки следующие. Дамп обмена TLS показывает SNI=vk.ru, и после сообщения Server Hello сервер же отправляет еще одно нераспознанное сообщение (ignored unknown record). На вид оно не зашифровано, возможно, повреждено, например, воздействием ТСПУ, но больше похоже, что в системе ТВ просто отсутствует необходимый сертификат корневого удостоверяющего центра (root CA), служащий основой построения цепочки доверия в инфраструктуре публичных ключей.

Дело в том, что на ПК все сайты VK открываются штатно, и заверены они сертификатом HARICA (Hellenic Academic and Research Institutions CA), действительным с 16 июня 2026 года. С высокой вероятностью сертификат был выпущен именно в связи с санкционными ограничениями, о которых стало известно 13 июня, а заменили сертификат именно 18 июня.

Далее о ТВ: это LG 2019 года, webOS 5.5.0 (05.50.00, она еще раз в несколько месяцев обновляется), приложение VK Video тоже актуальной версии 2.4.26 (23.12.2025 — давно не обновлялось, но они в основном обновляют его содержимое внутри архитектуры SPA). Учитывая, что сертификат корневого удостоверяющего центра HARICA выпущен в марте 2021 года, есть вероятность, что он мог быть обновлен в системе webOS, но, вероятно, этого не было сделано. Попросту это не самый распространенный центр сертификации, я сталкиваюсь с ним впервые.

Согласно ранее происходившим похожим случаям, у меня есть некий шанс добавить нужный сертификат самостоятельно, по крайней мере квалификации позволяет:
https://webos-forums.ru/topic7006.html

Однако, сперва все же нужно написать в VK: are you ahueli tam? Ну и погуглить, конечно, что отсылает меня сюда без особой надежды:
https://otvet.mail.ru/question/232947352

Самое же забавное, что otvet.mail.ru принадлежит тоже VK, и там-то они действительно отозванный сертификат еще не заменили. Если точнее, там почти наверняка отдельный сертификат, так как новый сертификат HARICA — DV на *.vk.com, а отозванный сертификат GlobalSign — OV на *.otvet.mail.ru, но сути это не меняет: GlobalSign отзывает сертификаты у VK, и их чем-то нужно заменять. Заменять адекватно, что явно уже не получилось без потерь.

То есть круг замкнулся. В попытке хоть что-то выяснить относительно ситуации с отозванным сертификатом попадаем на другой отозванный сертификат.

А так-то санкции нам на пользу!

Теперь облачной базе данных можно выдать бесплатный публичный IPv6-адрес.

Полезно, если:

1️⃣ Уже раскатали IPv6 в своей инфраструктуре и не хотите держать IPv4 только ради базы

2️⃣ Масштабируете проект и постепенно уходите от дефицитных IPv4-адресов

3️⃣ Строите cloud-native или корпоративную инфраструктуру, где важна поддержка IPv6.

Подключается в пару кликов: при создании новой базы или в настройках существующей «Сеть» → «Публичный IPv6-адрес». Если переключателя IPv6 у базы нет — значит, на вашей сети он пока недоступен.

При защищенном TLS-подключении адрес автоматически привяжется к техническому домену базы. Остальные детали в документации →

Фича появилась не случайно — ее давно просили в разделе идей (тут и тут), теперь она в проде.

Привязать айпишник к базе →