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

Ответ

При вводе URL в адресную строку браузера и нажатии Enter происходит последовательность шагов, направленная на получение и отображение веб-страницы:

  1. Парсинг URL: Браузер разбирает введенный URL на компоненты: протокол (HTTP/HTTPS), доменное имя, порт (если указан), путь и параметры запроса.
  2. Поиск в кэше: Браузер проверяет свой кэш (DNS-кэш, HTTP-кэш) на наличие запрошенных ресурсов. Если ресурс найден и актуален, он загружается из кэша, что ускоряет отображение страницы.
  3. DNS-запрос: Если доменное имя не найдено в кэше, браузер отправляет DNS-запрос для преобразования доменного имени (например, example.com) в IP-адрес (например, 93.184.216.34). Этот процесс включает обращение к локальному DNS-резолверу, а затем, при необходимости, к корневым, TLD и авторитативным DNS-серверам.
  4. Установление TCP-соединения: Получив IP-адрес сервера, браузер инициирует установление TCP-соединения с этим сервером на соответствующем порту (80 для HTTP, 443 для HTTPS) с помощью трехстороннего рукопожатия (three-way handshake).
    • Для HTTPS также происходит TLS/SSL-рукопожатие для установления зашифрованного соединения, обеспечивающего безопасность данных.
  5. Отправка HTTP-запроса: После установления соединения браузер формирует HTTP-запрос (обычно GET для получения страницы) с необходимыми заголовками (например, Host, User-Agent, Accept) и отправляет его на сервер.
    GET /path/to/resource HTTP/1.1
    Host: example.com
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
  6. Обработка запроса сервером: Сервер принимает запрос, обрабатывает его (например, выполняет логику приложения, запрашивает данные из базы данных) и формирует HTTP-ответ.
  7. Получение HTTP-ответа: Браузер получает HTTP-ответ от сервера, который включает статус-код (например, 200 OK, 404 Not Found), заголовки (например, Content-Type, Content-Length) и тело ответа (HTML-документ, CSS, JavaScript, изображения).

    HTTP/1.1 200 OK
    Content-Type: text/html; charset=UTF-8
    Content-Length: 12345
    Date: Thu, 01 Jan 1970 00:00:00 GMT
    
    <!DOCTYPE html>
    <html>
    <head>...</head>
    <body>...</body>
    </html>
  8. Рендеринг страницы: Браузер начинает парсить полученный HTML, строит DOM-дерево, запрашивает дополнительные ресурсы (CSS, JavaScript, изображения), строит CSSOM-дерево, объединяет их в Render Tree и отображает страницу на экране, постепенно отрисовывая контент.

Ответ 18+ 🔞

А, ну это классика, блядь! Сидишь такой, вводишь в строку «youtube.com» и думаешь: «Ща посмотрю, как там этот мудак с гитарой». А под капотом-то, ёпта, целая операция разворачивается, овердохуища процессов! Слушай, как оно на самом деле.

Первым делом, браузер твой этот URL как мандарина чистит. Разбирает нахуй: где протокол, где домен, где путь, где все эти вопросики и амперсанды. «Ага, — думает, — HTTPS, значит, шифроваться будем, пидарасы не подслушают».

Дальше — смешное. Он лезет в свои тайные закрома, в кэш, и начинает там шариться. «А не сохранил ли я, блядь, уже этот сайт? А то в прошлый раз полчаса грузился, ебать мои старые костыли!». Если находит свежие файлы — всё, красота, сразу показывает. Но обычно нихуя не находит.

Тут начинается цирк с DNS. Браузеру нужен IP-адрес, а у него только буквы — «youtube.com». Он такой: «Ну ясный пиздец, опять преобразовывать». И несёт запрос местному DNS-резолверу, типа: «Слышь, пацан, где этот ютуб живёт?». А тот сам может не знать, и начинает дергать корневые сервера, потом сервера зоны .com, и так далее, пока не выяснит, что youtube.com — это, например, 142.250.185.206. Адресок получил — можно в гости.

Дальше — установление связи, ебать тебя в сраку. TCP-рукопожатие, три пакета туда-сюда: «Привет, я браузер» — «Привет, я сервер, давай дружить» — «Окей, дружим». Если сайт на HTTPS (а щас все на нём), то поверх этого начинается ещё и TLS-рукопожатие, где они обмениваются криптографическими ключами, словно шпионы на мосту. «Пароль — „огурчик“, подтверждаю». Всё, тоннель защищённый построили.

И вот, наконец-то, браузер выдыхает и отправляет сам запрос, прямую просьбу. Формирует он HTTP-пакет, типа:

GET /videos/котики_смешные HTTP/1.1
Host: youtube.com
User-Agent: Mozilla/5.0 (Я, блядь, самый современный браузер, принимай меня)
Accept: text/html,дай мне всё, что есть, я всё съем

Шлёт это добро по только что налаженной трубе.

Сервер, получив послание, начинает суетиться. «Ага, — думает, — опять котиков запросили». Лезет в базу данных, шаманит там, собирает HTML, картинки, стили — весь комплект. Формирует ответ. Если всё хорошо, шлёт статус 200 OK и сам HTML в придачу:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html>
<head><title>Уморительные котики</title></head>
<body>Вот тебе, жопа, твои котики...</body>
</html>

А вот тут-то и начинается самое интересное, блядь — рендеринг! Браузер получает эту простыню из тегов и офигевает. Он начинает её парсить, строить из неё DOM-дерево — скелет страницы. Потом видит: «О, а тут ещё CSS файлик подключен!». Бежит за ним, ждёт, качает, строит CSSOM-дерево — это как шкура на скелет.

Потом он склеивает DOM и CSSOM в одно целое — Render Tree. И начинает, сука, рисовать! Сначала макет расставляет, потом краски наводит, пиксель к пикселю. А если там ещё JavaScript влезет, который DOM на ходу меняет, то вообще пиздец — браузеру приходится пересчитывать всё по новой, ебать его в сраку!

И только после всей этой ебалы, через сотни миллисекунд, ты, наконец, видишь вкладку с загруженной страницей и этими долгожданными усатыми мордами. Вот так-то, а ты думал — нажал Enter и всё. Хуй там! Целая сага, ёперный театр!