Что именно происходит, когда пользователь набирает в адресной строке google.com? Часть 2

Original author: alex
  • Translation
Часть 1

TLS handshake


Клиентский компьютер отправляет на сервер сообщение ClientHello, где указывает TLS-версию, список алгоритмов шифрования и доступные методы сжатия. Сервер отвечает сообщением ServerHello, содержащим такие же данные, плюс публичный сертификат сервера. Сертификат содержит публичный ключ, которым клиент зашифрует оставшуюся часть приветствия. Клиент проверяет, что сертификат подписан кем-либо из списка доверенных CA (Certificate Authority). Если проверка проходит, клиент создаёт последовательность псевдослучайных байтов и шифрует её с публичным ключом сервера. Эта последовательность используется для создания симметричного ключа.

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

С этого момента TLS-сессия передаёт данные по протоколу HTTP, зашифрованные симметричным ключом.

Протокол HTTP


Если пользователь использует браузер от Google, то вместо HTTP-запроса на содержимое страницы им будет отправлен запрос на апгрейд протокола с HTTP до SPDY. Если клиент не поддерживает протокол HTTP, он отправляет запрос на сервер в виде:

GET / HTTP/1.1
Host: google.com
Connection: close
[остальные заголовки]


Остальные заголовки содержат пары ключ-значение, разделённые двоеточиями. Каждая пара отделена от других символом новой строки. Если клиент использует более старые протоколы, чем HTTP/1.1, то в запросе не будет заголовка Host и версия в первой строчке будет другая – 1.0 или 0.9

В протоколе HTTP/1.1 задана возможность закрывать соединение после окончания получения ответа. Заголовок выглядит так:

Connection: close


Если клиент не поддерживает постоянные соединения, он обязан включать такой заголовок в любой запрос.

После отправки запроса и заголовков, браузер отправляет пустую строку, сигнализирующую об окончании контента запроса. Сервер отвечает кодом, обозначающим статус запроса, за которым следуют заголовки ответа:

200 OK
[заголовки ответа]


За ними идёт пустая строка, после которой клиенту вываливается HTML-содержимое страницы www.google.com. Затем сервер закрывает соединение, или оставляет его открытым, в зависимости от запросов клиента.

Если в заголовках HTTP-запроса от клиента содержалась информация, по которой можно определить, что после сохранения файла в кэше браузера он не менялся на сервере (например, браузер включил заголовок ETag), сервер может ответить так:

304 Not Modified
[заголовки ответа]


и не включать в ответ содержимое файла. Тогда браузер загружает файл из кэша.

После разбора HTML, браузер с сервером повторяют эту процедуру для каждого ресурса (картинки, файлы стилей, скриптов, и т.п.), на который есть ссылка из HTML. Только вместо запроса GET / HTTP/1.1 он будет указывать путь к файлу GET /$(URL относительно www.google.com) HTTP/1.1.

Если в HTML упомянут ресурс с домена, отличного от www.google.com, браузер повторяет шаги с момента получения адреса домена. Заголовок Host в запросе будет указывать нужное доменное имя вместо google.com

HTTP Server Request Handle


Сервер HTTPD (HTTP Daemon) обрабатывает запросы на стороне сервера. Самые популярные серверы — Apache или nginx для Linux и IIS для Windows. Когда сервер получает запрос, он разбирает его по следующим параметрам:

— метод запроса HTTP (GET, POST, HEAD, PUT или DELETE). В нашем случае это будет GET
— домен, в нашем случае google.com.
— путь/страница, в нашем случае / (путь по умолчанию)

Сервер проверяет:
— наличие виртуального хоста, соответствующего запрошенному домену
— этот домен принимает GET-запросы
— клиент имеет право делать такой запрос (возможные ограничения по ip, авторизация, и т.д.)

При наличии у сервера модуля преобразования путей (mod_rewrite у Apache или URL Rewrite у IIS) он пытается сопоставить запрос одному из заданных правил. Если правило найдено, сервер преобразовывает запрос согласно ему.

Затем сервер читает файл, соответствующий запросу. Если, например, Google работает на PHP, тогда сервер использует PHP для интерпретации файла индексов, и выдаёт результат интерпретации клиенту.

За кулисами браузера


После получения браузером всех ресурсов (HTML, CSS, JS, картинки, и т.д.) браузер парсит текстовые ресурсы (HTML, CSS, JS), и запускает рендер страницы. Для этого строится дерево DOM, затем оно обрабатывается, просчитывается расположение элементов и они выводятся на экран.

Браузер


Функция браузера – предоставить выбранный веб-ресурс, запросив его с сервера, и показать его в окне. Обычно это HTML-документ, но это может быть и PDF, картинка и другой контент. Местоположение ресурса задаётся универсальным идентификатором URI.

То, как браузер интерпретирует и показывает HTML-файл, задано в спецификациях HTML и CSS, которые поддерживаются консорциумом W3C (World Wide Web Consortium).

У всех браузеров обычно есть:
— адресная строка для вставки URI
— кнопки назад и вперёд
— возможность делать закладки
— кнопки обновления и останова
— кнопка «домой»

Высокоуровневая структура браузера


— интерфейс пользователя – кнопки, адресная строка, меню. Это всё, кроме основной части окна, в котором видна страница
— движок браузера – обрабатывает взаимодействие UI и движком рендера
— движок рендера – визуально отображает запрошенный контент
— сетевая часть – HTTP-запросы, и прочее
— бэкенд интерфейса – рисует меню-выпадушки, окна и прочие элементы. Этот интерфейс платформонезависим, а его работу обеспечивают методы интерфейса пользователя конкретной операционки
— интерпретатор JavaScript – разбирает и выполняет код
— хранение данных – куки и локальное хранилище (localStorage, IndexedDB, WebSQL и FileSystem).

Разбор HTML (парсер)


Движок рендера получает контент запрошенного документа, обычно кусочками по 8 Кб. Задача парсера – превратить разметку в дерево. Дерево парсера – древовидная структура DOM-элементов и узлов. DOM, или Document Object Model – это представление HTML-документа и его элементов для других движков, например для JavaScript. До обработки скриптов DOM имеет почти полное взаимно однозначное соответствие с разметкой.

Алгоритм парсера


HTML нельзя разобрать обычными парсерами, работающими сверху вниз или снизу вверх. Разметка слишком либеральная, браузеры допускают определённые ошибки в разметке, а работа скриптов иногда принуждает процесс разбора возвращаться к уже пройденным местам. В связи с этим процесс разбора иногда меняет входные данные. Подробнее алгоритм разбора описан в спецификации HTML5.

По окончанию парсинга


Браузер запрашивает внешние ресурсы (CSS, images, JavaScript, и т.д.). На этом этапе документ становится интерактивным и начинают обрабатываться скрипты, которые выполняются по готовности документа (режим deferred). Затем статус документа устанавливается в complete и запускается событие load.

Интерпретация CSS


Обрабатываются файлы CSS, содержимое тегов
  • +11
  • 34.4k
  • 5
Support the author
Share post

Comments 5

    0
    > После получения браузером всех ресурсов (HTML, CSS, JS, картинки, и т.д.) браузер парсит текстовые ресурсы (HTML, CSS, JS), и запускает рендер страницы. Для этого строится дерево DOM, затем оно обрабатывается, просчитывается расположение элементов и они выводятся на экран.

    А разве рендер не начинается сразу, как получен html/css/js?
    Ведь артинки догружаются позже, что мы регулярно и видим. Разве что это было специально прекешировано в js
      0
      Картинки подгружаются сразу, а рендеринг расставляет их туда куда нужно.
      –1
      Было бы интересно почитать про протокол SPDY и его использование…
        0
        Как-то внезапно прерывается повествование. Даже точки нет в конце.
          0
          Интересно, для кого этот текст. Наверное, для проходящих интервью? Я мечтаю о существовании такого же объяснения для не очень вовлечённых людей, самых начинающих, но этот текст, к сожалению, для них не подходит: сразу же огромное количество деталей, частностей, устаревших протоколов и непонятных аббревиатур.

          Only users with full accounts can post comments. Log in, please.