Часть 1
Клиентский компьютер отправляет на сервер сообщение ClientHello, где указывает TLS-версию, список алгоритмов шифрования и доступные методы сжатия. Сервер отвечает сообщением ServerHello, содержащим такие же данные, плюс публичный сертификат сервера. Сертификат содержит публичный ключ, которым клиент зашифрует оставшуюся часть приветствия. Клиент проверяет, что сертификат подписан кем-либо из списка доверенных CA (Certificate Authority). Если проверка проходит, клиент создаёт последовательность псевдослучайных байтов и шифрует её с публичным ключом сервера. Эта последовательность используется для создания симметричного ключа.
Сервер расшифровывает последовательность своим приватным ключом и создаёт на её основе свою копию симметричного ключа. Клиент отправляет сообщение Finished, шифруя хэш всей передачи симметричным ключом. Сервер создаёт свой хэш, и расшифровывает хэш от клиента для их сверки. Если они идентичны, он отправляет своё сообщение Finished, которое также зашифровано симметричным ключом.
С этого момента TLS-сессия передаёт данные по протоколу HTTP, зашифрованные симметричным ключом.
Если пользователь использует браузер от Google, то вместо HTTP-запроса на содержимое страницы им будет отправлен запрос на апгрейд протокола с HTTP до SPDY. Если клиент не поддерживает протокол HTTP, он отправляет запрос на сервер в виде:
Остальные заголовки содержат пары ключ-значение, разделённые двоеточиями. Каждая пара отделена от других символом новой строки. Если клиент использует более старые протоколы, чем HTTP/1.1, то в запросе не будет заголовка Host и версия в первой строчке будет другая – 1.0 или 0.9
В протоколе HTTP/1.1 задана возможность закрывать соединение после окончания получения ответа. Заголовок выглядит так:
Если клиент не поддерживает постоянные соединения, он обязан включать такой заголовок в любой запрос.
После отправки запроса и заголовков, браузер отправляет пустую строку, сигнализирующую об окончании контента запроса. Сервер отвечает кодом, обозначающим статус запроса, за которым следуют заголовки ответа:
За ними идёт пустая строка, после которой клиенту вываливается HTML-содержимое страницы www.google.com. Затем сервер закрывает соединение, или оставляет его открытым, в зависимости от запросов клиента.
Если в заголовках HTTP-запроса от клиента содержалась информация, по которой можно определить, что после сохранения файла в кэше браузера он не менялся на сервере (например, браузер включил заголовок ETag), сервер может ответить так:
и не включать в ответ содержимое файла. Тогда браузер загружает файл из кэша.
После разбора HTML, браузер с сервером повторяют эту процедуру для каждого ресурса (картинки, файлы стилей, скриптов, и т.п.), на который есть ссылка из HTML. Только вместо запроса GET / HTTP/1.1 он будет указывать путь к файлу GET /$(URL относительно www.google.com) HTTP/1.1.
Если в HTML упомянут ресурс с домена, отличного от www.google.com, браузер повторяет шаги с момента получения адреса домена. Заголовок Host в запросе будет указывать нужное доменное имя вместо google.com
Сервер 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).
Движок рендера получает контент запрошенного документа, обычно кусочками по 8 Кб. Задача парсера – превратить разметку в дерево. Дерево парсера – древовидная структура DOM-элементов и узлов. DOM, или Document Object Model – это представление HTML-документа и его элементов для других движков, например для JavaScript. До обработки скриптов DOM имеет почти полное взаимно однозначное соответствие с разметкой.
HTML нельзя разобрать обычными парсерами, работающими сверху вниз или снизу вверх. Разметка слишком либеральная, браузеры допускают определённые ошибки в разметке, а работа скриптов иногда принуждает процесс разбора возвращаться к уже пройденным местам. В связи с этим процесс разбора иногда меняет входные данные. Подробнее алгоритм разбора описан в спецификации HTML5.
Браузер запрашивает внешние ресурсы (CSS, images, JavaScript, и т.д.). На этом этапе документ становится интерактивным и начинают обрабатываться скрипты, которые выполняются по готовности документа (режим deferred). Затем статус документа устанавливается в complete и запускается событие load.
Обрабатываются файлы CSS, содержимое тегов
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, содержимое тегов
