Что происходит при вводе URL в адресную строку браузера и нажатии Enter

Что проверяют

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

Как отвечать

Идите по цепочке и на каждом шаге называйте, как его сбой выглядит для пользователя:

• разбор ввода: браузер решает, адрес это или поисковый запрос. Если домен в списке HSTS, запрос сразу уходит по HTTPS, даже если набрали http://;
• кэши: Service Worker и HTTP-кэш могут отдать ответ, вообще не выходя в сеть;
• DNS: кэш браузера, кэш ОС и файл hosts, затем рекурсивный резолвер провайдера или DoH, который при промахе идёт к корневым серверам, серверам зоны и авторитетному серверу домена. Сбой виден как ERR_NAME_NOT_RESOLVED, проверяется через nslookup или dig;
• соединение: TCP-рукопожатие, затем TLS 1.3 с проверкой сертификата, SNI и выбором HTTP/2 через ALPN. HTTP/3 работает поверх QUIC на UDP и совмещает оба этапа. Просроченный сертификат даёт NET::ERR_CERT_DATE_INVALID;
• запрос и сервер: GET с заголовками и куками идёт через CDN, балансировщик и reverse proxy к приложению. В ответ может прийти не 200, а редирект 301 или 302, и цикл повторится для нового адреса;
• рендеринг: HTML разбирается в DOM, CSS в CSSOM, дальше render tree, layout, paint и композитинг. Синхронный <script> без defer или async останавливает разбор, пока не загрузится и не выполнится.

Для диагностики сошлитесь на вкладку Network с её Timing и на curl -v, который покажет DNS, TLS и заголовки без участия браузера.

Где спотыкаются

Забывают про HTTPS и TLS и описывают соединение так, будто всё идёт по открытому HTTP.

Уверены, что при каждом заходе браузер спрашивает корневые DNS-серверы. На деле почти всегда отвечает кэш на одном из уровней.

Заканчивают ответ на «сервер вернул 200 или 404». Без редиректов, кэша, рендеринга и способов проверки ответ для QA выглядит неполным.