Во время собеседований часто задают вопрос: что происходит, когда вы набираете в адресной строке браузера google.com «. Чаще всего человек не знает ответа или дает очень неполный ответ (здесь может иметь место нервозность).
Ответить на этот вопрос непросто, в основном потому, что, если вы хотите дать максимально полный ответ, вы можете бесконечно говорить об этом.
Этот пост предназначен для достижения общего подхода к вопросу с некоторыми ресурсами, где каждый элемент описан более подробно. На мой взгляд, этого должно быть более чем достаточно, чтобы достойно ответить на вопрос.
1. Пользователь вводит в адресной строке браузера
Когда пользователь что-то набирает на клавиатуре, сигналы отправляются в систему ОС, которая берет на себя ответственность за отправку события в браузер. Получив это событие, браузер запустит функции автозаполнения. Например, если пользователь набирает "go”, адресная строка браузера, скорее всего, предложит "google.com”, прежде чем он закончит ввод. Предложения, предоставляемые функциями автозаполнения, основаны на вашей истории поиска, закладках, файлах cookie и популярных поисковых запросах в Интернете. Пользователь также может увидеть предложения, представленные в раскрывающемся списке под адресной строкой. Выпадающий список открывается, когда алгоритмы предложений находят совпадения с введенной строкой (например, на рабочем столе Chrome отобразит до 6 предложений).
2. Является ли ввод поисковым запросом или URL-адресом?
Входные данные могут быть либо поисковым запросом, либо URL-адресом. Если то, что он набирает в адресной строке, не включает протокол (http:// или https://) или допустимое доменное имя, браузер интерпретирует его как поисковый запрос и передает его в поисковую систему браузера по умолчанию. С другой стороны, если браузер решит, что это действительный URL, он проверит свою схему и добавит http:// в начало ввода. Затем создается запрос с использованием порта 80 по умолчанию, GET метода и без базовой аутентификации.
2.1. HSTS (безопасность транспорта строки HTTP)
Мое последнее утверждение не совсем верно, на самом деле браузер проверит свой предварительно загруженный список HSTS (HTTP String Transport Security, см .: RFC 6797).
Как вы знаете, http:// небезопасен. Злоумышленник может перехватить это соединение, манипулировать им, чтобы выполнить целый ряд вредоносных взломов. Пользователь может быть перенаправлен на g00gle.com, где он может оказаться во власти злоумышленников, которые могут, например, перехватывать пароли.
HSTS - это стандарт безопасности, который позволяет веб-сайтам объявлять себя доступными только через безопасные соединения. Если веб-сайт находится в списке HSTS, браузер отправит свой запрос через HTTPS вместо HTTP, используя порт 443. В противном случае запрос будет отправить через HTTP.
Конечно, веб-сайт по-прежнему может использовать политику HSTS, не будучи в списке HSTS. Браузер выполнит первый запрос HTTP, а затем получит ответ, запрашивающий у браузера отправлять только запросы HTTPS. Этот запрос HTTP может оставить пользователя уязвимым для атаки перехода на более раннюю версию. По этой причине список HSTS в настоящее время включен в браузер.
Вы можете проверить, включен ли сайт в список HSTS на https://hstspreload.org - google.com не включен 😱.
Ресурсы:
- Вики Mozilla о предварительно загруженном списке HSTS: Firefox HSTS list
- Safari о защите от злоупотреблений HSTS
3. Поиск DNS
Браузер не может открыть любую веб-страницу, не зная ее IP-адреса. (Вы хотите узнать свой IP-адрес 😎? См .: https://whatismyipaddress.com/)
IP-адрес url (пример: google.com) можно найти с помощью процесса, называемого DNS-поиск. DNS (система доменных имен) - это база данных, которая поддерживает уникальные отношения между именем URL-адреса и IP-адресом, на который он ссылается. Например, www.google.com можно получить, набрав http://172.217.23.14 в адресной строке.
Браузеру необходимо будет выполнить следующие шаги в соответствующем порядке для достижения этой цели. Если текущая проверка не удалась, она перейдет к следующему шагу.
- Браузер проверяет, находится ли домен в локальных кэшах.
- Он может находиться в кеше браузера, если он был недавно посещен (вы можете проверить кеш DNS Chrome по адресу chrome: // net-internals / # dns)
- Кэш DNS: согласно настройкам TTL, в кеше DNS может существовать IP-адрес от любых предыдущих посещений. (хороший ресурс: ttl settings)
- Файл хостов: связанный IP-адрес может быть определен в файле хостов на компьютере пользователя. Браузер вызывает библиотеку
gethostbynameдля поиска на этом этапе (интересный ресурс: изменить файл hosts в Windows)
2. Браузер делает запрос к DNS-серверу, настроенному в вашей сетевой системе (настройки DNS), который обычно относится к вашему локальному маршрутизатору или кешу рекурсивных серверов DNS вашего интернет-провайдера. . IP-адрес мог быть кэширован там после предыдущих посещений любого другого пользователя, который запрашивал тот же веб-сайт.
3. Запрос поступит на корневые DNS-серверы. Каждый домен верхнего уровня (например, .com, .pt, .es) имеет свои собственные серверы имен, называемые DNS-серверами верхнего уровня. Их задача - перенаправить наш запрос на серверы имен, соответствующие нашему запрошенному домену верхнего уровня (TLD).
4. Запрос направляется на соответствующий DNS-сервер верхнего уровня для соответствующего домена (например, .com , если мы хотим найти google.com). Эти серверы направят запрос туда, где он может найти искомую информацию, в частности, на полномочные серверы имен.
5. Полномочные DNS-серверы содержат информацию о домене. При передаче запроса запрашивается запись доменного имени, которая содержит IP-адрес сервера, на котором размещен веб-сайт.
Ресурсы:
- Как ваш браузер находит веб-сайты
- комикс на тему как работает DNS (BEST 😍)
- Интересный ресурс для чтения о протоколе разрешения адресов: ARP
4. Браузер открывает соединение TCP-сокета с сервером.
Хорошо, теперь, когда браузер получил IP-адрес целевого сервера, он берет номер порта соответствующего протокола, вызывает функцию системной библиотеки socket и запрашивает поток сокетов TCP: AF_INET/AF_INET6 и SOCK_STREAM.
Затем запрос передается на транспортный уровень модели OSI (4-й уровень), где создаются сегменты TCP и порт назначения. добавляется в заголовок TCP. Транспортный уровень отвечает за сквозную связь по сети, качество и надежность.
Запрос отправляется на сетевой уровень (3-й уровень модели OSI), где IP-адрес назначения и IP-адрес устройства, выполняющего запрос, добавляются к сегменту для формирования пакета.
Сетевой уровень выбирает и управляет передачей данных между узлами в сети. Он отвечает за установку логического соединения, пересылку данных, маршрутизацию и создание отчетов об ошибках доставки.
Затем пакет доставляется на уровень канала данных (2-й уровень), где к пакету добавляется заголовок кадра, включающий MAC-адреса сетевого интерфейса и локального маршрутизатора.
После этого шага. пакет готов к передаче через физический уровень, проходя через все виды узлов, пока не достигнет целевого сервера.
4.1. Установить соединение
Перед началом передачи данных клиент и сервер должны обменяться набором параметров. Для начальной загрузки соединения сервер должен иметь пассивное открытое соединение, привязанное к порту, который прослушивает соединения. Соединение между ними осуществляется посредством процесса, называемого трехстороннее рукопожатие (SYN, SYN / ACK, ACK).
Все пакеты отправляются и принимаются с использованием потока TCP-соединения, показанного на изображении ниже:
5. Выполнение рукопожатия TLS.
Протокол установления связи TLS - это криптографический протокол, отвечающий за аутентификацию и обмен ключами. , чтобы установить или возобновить безопасные сеансы между сервером и приложением, например браузером. Протокол HTTPS - это не более чем HTTP через TLS. Процесс установления сеанса протоколом TLS показан на следующем изображении:
Вот результат рукопожатия TLS, выполняемого командой:
curl GET “https://www.google.com" -v
Ресурсы:
- Хорошая статья про TLS и TCP: гайки и болты
- Microsoft: Протокол рукопожатия TLS
- Сеть 101: TLS
6. Браузер отправляет HTTP-запрос на сервер.
Протокол передачи гипертекста (HTTP) - это магистраль связи в Интернете.
Как только соединение установлено, мы можем начать передачу данных между сервером и клиентом. Браузер отправит GET запрос с запросом веб-страницы, скажем google.com.
Заголовки будут содержать такую информацию, как метод, путь, идентификатор браузера (User-agent) и т. Д. Вот пример заголовков, установленных в запросе GET, выполненном в Chromium до google.com:
Сервер ответит сообщением с кодом состояния, который будет 200, если все в порядке. Если браузер содержит достаточно информации, веб-сервер может определить, что версия кэшированного файла не изменилась с момента последнего извлечения. В этом случае сервер ответит кодом состояния 304 Not Modified, а не данными. HTML (или PDF-файл, изображение и т. Д.) Будет извлечен из кеша браузера. Вот пример заголовков ответа, полученных из предыдущего GET в google.com, с кодом состояния 200:
Если вы никогда не видели HTTP-запросы и ответы в своем браузере, откройте инструменты разработки (инспектор) в Chrome или любом другом браузере и перейдите на вкладку сети.
7. Как сервер обрабатывает запрос.
HTTPD (HTTP Daemon) - это часть программного обеспечения, которое работает в фоновом режиме веб-сервера, прослушивает HTTP-запросы клиентов и обрабатывает эти запросы и ответы на стороне сервера. Обычно это Apache или nginx для Linux, IIS для Windows и может быть написан на множестве языков программирования, таких как: PHP, Ruby, Node и т. Д.
Сервер разбивает запрос по методу запроса (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS или TRACE), домену и пути. Если мы введем URL-адрес в адресную строку, он всегда будет GET. После прочтения запроса используются заголовки и файлы cookie для анализа того, что запрашивается, и при необходимости он также может переписать запрос (mod_rewrite Apache module).
Затем сервер соберет контент для ответа полезной нагрузки, который соответствует запросу. В случае google.com он вернется к индексному файлу в корневом пути /. Затем он проанализирует файл и передаст вывод клиенту.
7.1. Ответ сервера
Ответ сервера на запрос google.com url GET - это HTML-документ. Ответ включает некоторые заголовки, такие как код состояния, кеш страницы, тип сжатия, файлы cookie и т. Д.
Код статуса ответа важен, поскольку он сообщает клиенту статус ответа. Любой вид 2xx указывает на успех, 3xx указывает на то, что клиент будет перенаправлен, 4xx указывает на ошибки на стороне клиента, а ошибки 5xx указывают на ошибки на стороне сервера.
8. Как клиент (браузер) обрабатывает ответ.
Теперь, когда браузер получил ответ от сервера, будут проанализированы HTML, CSS и JS. Затем браузер проверит теги HTML и отправит любые GET requests для внешних ресурсов. Это могут быть ресурсы, такие как таблицы стилей CSS, файлы JavaScript, изображения и т. Д. После завершения анализа запускается процесс рендеринга, позволяющий отображать HTML в браузере.
8.1. HTML парсинг
Процесс синтаксического анализа HTML начинается с передачи потока символов Юникода с сетевого уровня на этап токенизации модели синтаксического анализа. Данные обычно передаются блоками по 8 КБ. В обязанности модели синтаксического анализа входит создание DOM (объектной модели документа), дерева элементов DOM и атрибутов узлов, которые представляют документ веб-страницы.
Вы можете подробнее прочитать об алгоритме синтаксического анализа в W3C parsing HTML documents.
В качестве примечания имейте в виду, что синтаксический анализ HTML-документа не является тривиальным. Из-за характера поставленной задачи язык очень снисходительный. Например, html может содержать элемент открывающего тега <p> без закрывающего тега </p>. Этот недопустимый синтаксис будет исправлен, и браузер просто продолжит выполнение своих задач. Процесс также является реентерабельным, что означает, что пока на этапе построения дерева обрабатывается токен, токенизатор может быть возобновлен, что приведет к эмиссии и обработке большего количества токенов до того, как закончится начальный процесс токена. Это поведение может быть вызвано динамическим кодом, например вызовом document.write().
<script>
document.write('<p>');
</script>
8.2. Получение ресурсов
Браузер начнет получать внешние ресурсы, как только он обнаружит узнаваемый тег, такой как <link>. О местонахождении этих ресурсов можно намекнуть браузеру, включив тег <link> внутри тега <head> с атрибутом rel, установленным как dns-prefetch, preconnect, prefetch или prerender, метод оптимизации веб-страниц (подсказки по ресурсам).
8.3. CSS
Когда браузер находит встроенную или внешнюю таблицу стилей CSS, он анализирует ее с помощью лексической и синтаксической грамматики CSS, которая будет использоваться для стилизации макетов и раскрасок веб-страниц. Каждый файл CSS анализируется в объект таблицы стилей со структурой, называемой CSSOM (объектная модель CSS).
Конструкция CSSOM, как и конструкция DOM, считается блокирующей отрисовку.
8.4. Дерево рендеринга
Конструкции CSSOM и DOM необходимы для создания дерева рендеринга, которое будет содержать всю информацию, необходимую браузеру для создания пикселей на странице. Следующее изображение демонстрирует способ построения дерева рендеринга.
8.5. JavaScript
Когда браузер завершает синтаксический анализ, он отмечает документ как интерактивный и начинает синтаксический анализ сценариев JavaScript, которые установлены как отложенные. Сценарии также можно установить как async, в этом случае синтаксический анализ HTML приостанавливается до тех пор, пока сценарий JS не будет проанализирован и выполнен.
Если обнаружен тег <script>, построение модели DOM будет приостановлено. Однако браузер будет ждать завершения построения CSSOM. Причина та же, что описана ранее, выполнение JS может изменить DOM и получить доступ или изменить CSSOM.
9. Рендеринг
Теперь, когда дерево рендеринга построено, браузер может перейти к этапу рендеринга. Дерево рендеринга используется для создания макета видимых элементов на странице.
На этапе макета браузер вычисляет размеры каждого элемента, а затем их положение в области просмотра. Он начнется с корня дерева рендеринга и будет обходить его.
Когда этап макета будет завершен, начнется этап покраски. Для этого процесса браузер будет использовать возможности графических процессоров или процессора, чтобы преобразовать дерево рендеринга в пиксели на экране.
9.1. Критический путь рендеринга
Возможно, вы слышали или знали об этой концепции раньше, если работаете в полевых условиях, и угадайте, что, я только что описал критический путь рендеринга в двух последних пунктах 🙃 (8 и 9).
Критический путь отрисовки - это минимальные шаги, которые браузер должен предпринять с момента получения первого байта HTML до момента, когда он впервые отрисовывает пиксели на экране.
Написание этого сообщения в блоге было для меня процессом обучения, я надеюсь, что те, кто дошел до конца, тоже чему-то научатся.
Ресурсы:
