Русские Блоги
С HTTP на TCP. Что именно делает браузер, когда вы вводите строку символов в поле поиска браузера и нажимаете Enter?
Предисловие
Вопрос в названии должен быть более старым, но я все же хочу рассказать о своем собственном опыте. Предупреждение: следующий контент составлен автором, но мы постараемся обеспечить его правильность. Если вы не боитесь, что вас обманут, просто продолжайте читать!
0 Получите полную картину
Когда я был молод, WWW (World Wide Web) был почти синонимом Интернета. Разве Интернет не является Интернетом? Когда я вырос, я узнал, что WWW (World Wide Web) — доступный евангелист, который позволяет нам увидеть мощь Интернета, но это не Интернет.
World Wide Web — это приложение, работающее в Интернете, это больше похоже на систему, потому что для реализации этого приложения вам нужно собрать небольших партнеров, таких как браузер World Wide Web, сервер World Wide Web, документ World Wide Web. формат и протокол HTTP. При поддержке базовой сети эти компоненты взаимодействуют друг с другом, чтобы дать нам представление о мире в окне браузера.
1 Начало всего
Когда мы вводим строку символов в адресную строку и нажимаем Enter, вы обнаружите, что два предыдущих друга появились бессознательно — браузер и HTTP тоже приходят! В это время, прежде чем поздороваться, вы обычно нажимаете Enter. . . Два друга также хладнокровно повернулись, чтобы завершить свою миссию.
2 Увидеть его в толпе
Строка символов, которую мы ввели выше, кажется обычной, но она уникальна и называется единым указателем ресурса. www.bilibili.com, строка, которую часто называют веб-адресом, более уместно называть доменным именем в представлении браузера. Перед началом работы HTTP система доменных имен (DNS) сказала: позвольте мне показать вам путь вперед; HTTP сказал: прекратите говорить ерунду, скажите мне IP, соответствующий www.bilibili.com, я все еще тороплюсь.
Поэтому браузер поспешно вызвал UDP и запросил локальный сервер доменных имен. Локальный DNS не ответил сразу. Вместо этого он сказал, что вы подождите некоторое время, и я спрошу вас. Затем он спросил у корневого сервера доменных имен, на этот раз корневого имя домена. Сервер не знал, а затем попросил его запросить другой сервер доменного имени верхнего уровня. После долгого бега туда и обратно локальный DNS наконец запросил IP-адрес, соответствующий www.bilibili.com, а затем сказал HTTP.
3 тысячи миль вместе, Чанцзюань
HTTP получил IP-адрес и начал просить TCP подчиненных отправить мне сообщение в место, указанное IP.Номер дома — 80. Это должно быть безопасно и надежно, знаете ли!
TCP не такой безответственный, как UDP. Он очень осторожен. Обнаружив адрес и номер дома, указанные в IP, он трижды пожал руку другим, прежде чем уверенно подтвердить, что мы можем общаться друг с другом. В это время люди говорили, что я не из пожилых людей, я веб-сервер! Кроме того, ваша задача еще не завершена. Передайте этот документ, написанный в формате документа World Wide Web своему начальнику. TCP услышал это без жалоб и сказал, что обещает выполнить задачу. Хотя на дороге есть пробки, часто бывают флуды, но ПТС отлично справилась. HTTP сказал: TCP усердно работал. Я думаю, вам так нравится пожимать руки. Тогда идите и поговорите с другими людьми. TCP взволнован, когда вы это слышите. На этот раз вы пожали руку четыре раза.
4 Увидеть блеск мира
Браузер получил возвращенный документ от HTTP, что он сказал? Что это написано? , Никто вне экрана не может понять эту вещь, позвольте мне перевести.
5 Минимальный ток
Люди за пределами экрана смотрели на станцию B с улыбкой и хвалили браузер, HTTP, сервер, TCP, DNS, UDP — это здорово! В это время об этом услышали большие парни в нижней части сети, и они готовились к битве за честь.
Написано на скорую руку, напиши немного бесплатно и обнови, когда будет время!
Что стоит за простой загрузкой веб-странички в браузере
На собеседованиях мы часто просим кандидата рассказать настолько подробно, насколько он может, что происходит, когда вводишь в адресной строке браузера адрес сайта и нажимаешь кнопку “Ввод”. В зависимости от того, кого собеседуем — фронтендщика или бекендщика — мы ожидаем разные ответы. А как бы выглядел идеальный ответ на этот вопрос? Ниже мой вариант ответа.
Итак, пользователь вводит в адресной строке браузера адрес сайта и нажимает кнопку “Ввод”.
Браузер состоит из нескольких компонентов, одним из которых является User Interface. Адресная строка как раз является одной из частей этого компонента.
User Interface после ввода URL в адресной строке передаёт управление компоненту Browser Engine, который отвечает за взаимодействие различных компонентов браузера.
Чтобы сделать запрос по указанному URL, браузеру нужно знать IP сервера. Первым делом он смотрим в свой локальный кэш DNS.Компонент Browser Engine как раз имеет доступ к этому кэшу.
В браузере Chrome локальный кэш DNS . доступен по ссылке chrome://net-internals/#dns
Если там нет соответствующей записи, то браузер передаёт управление операционной системе, которая проверяет свой кэш DNS. Если и там отсутствует соответствующая запись, то ОС смотрит в локальные хосты (файл /etc/hosts в Unix-системах). Если запись о хосте отсутствует, то операционная система обращается к интернет провайдеру, у которого тоже есть свой кэш DNS на своих рекурсивных серверах DNS. В случае отсутствия записи в кэше на серверах DNS провайдера, запрос идёт на корневой DNS. У корневого DNS тоже есть кэш. Если соответствующей записи в кэше корневого DNS нет, запрос идёт дальше по цепочке серверов DNS.
К примеру, если адрес нашего сайта site.com.ua, то запросы к DNS выглядят так: site.com.ua.: . (корневой DNS) -> ua (DNS зоны “ua”) -> com (DNS зоны “com”)-> site.
Если на любом из этапов находится нужная запись, то она сохраняется во всех кэшах и управление возвращается браузеру, который уже знает IP нужного сервера.
Процесс получения IP адреса называется DNS lookup.
Далее Browser Engine смотрит в локальном кэше, нет ли запрашиваемой страницы. Если страницы в кэше нет, то Browser Engine передаёт управление компоненту Rendering Engine, который обращается к компоненту Networking Component, чтобы тот сделал запрос GET на указанный IP на порт 80 по протоколу HTTP или на порт 443 по протоколу HTTPS (в зависимости от указанного протокола в URL) со своими стандартными HTTP заголовками. Среди стандартных заголовков есть заголовок host, в котором передаётся хост запрашиваемого сайта (в нашем примере site.com.ua). Если в браузере хранятся куки к этому домену, то он отправляет их в заголовке cookie. Запрос будет выполнен, если соответствующий порт на пользовательском компьютере открыт.
На сервере запрос принимает веб-сервер (например, nginx или apache).
В конфигурационных файлах веб-сервера прописаны обслуживаемые хосты. Веб-сервер достаёт хост из заголовка запроса host и сопоставляет с теми, которые указаны в конфигурации. Если есть совпадение, то веб-сервер находит в конфигурационном файле правила обработки такого запроса и выполняет их. Дальнейшее поведение сервера зависит от технологии и особенностей приложения. Здесь может происходить работа с базами данных, кэшами, запросы к другим серверам и сервисам, выполнение различных скриптов. Для простоты представим, что приложение сгенерировало файл HTML, и веб-сервер отдал его браузеру.
Браузер получил файл HTML с соответствующими HTTP заголовками от сервера, в которых указана длина контента (заголовок Content-Length), тип контента (заголовок Content-Type со значением “text/html; charset=UTF-8” для файлов HTML), заголовки для кэширования. Если присутствуют кэширующие заголовки, то браузер сохраняет файл в локальный кэш.
Заголовки ответа сервера можно увидеть в Chrome DevTools на вкладке Networking, выбрав нужный запрос
Если длина контента больше нуля и тип контента поддерживается браузером, то браузер пытается его обработать. В нашем случае браузер получает файл HTML с соответствующим заголовком Content-Type. Браузер начинает разбор (parsing) этого файла с первой инструкции, которой является инструкция <!DOCTYPE>. DOCTYPE указывает на версию HTML, чтобы браузер понимал, каким правилам следовать во время разбора (какие теги как обрабатывать).
Если DOCTYPE отсутствует, то браузер переключится в режим quirks mode и попытается разобрать документ HTML, однако многие элементы будут проигнорированы. Если указан корректный DOCTYPE, то браузер будет работать в standards mode и будет разбирать документ в соответствии с правилами той версии, которая указана в DOCTYPE.
Rendering Engine начинает разбор документа HTML.
Создаётся DOM (Document Object Model). В браузере этот объект доступен по ссылке, которая хранится в переменной document. У документа есть несколько состояний. Первое состояние — loading. Оно означает, что документ только начал формироваться.
Состояние документа хранится в переменной document.readyState.
Также создаётся объект styleSheets, который будет хранить все стили.
Все стили на странице доступны по ссылке, которая хранится в переменной document.styleSheets.
Любой файл — это набор байтов. Браузер берёт полученный набор байтов и преобразует их в символы по таблице символов в соответствии с кодировкой, которая была передана в заголовке Content-Type. В нашем примере это кодировка UTF-8.
Следующий процесс —разбивание текста на смысловые блоки (tokenization). Так браузер распознаёт теги <html>, <head> и проч., а также понимает, какие правила к какому тегу применять (например, поддерживаемые атрибуты).
Далее токены собираются в узлы (nodes). Эти узлы и сохраняются в DOM со всеми взаимными связями.
Во время разбора, если Rendering Engine встречает ссылку на внешний ресурс, то он передаёт команду загрузить этот ресурс компоненту Networking Component. Это может быть ссылка на стили, скрипты, картинки и т.п. Networking Component ставит все ресурсы в очередь на загрузку. Каждому ресурсу Networking Component присваивает приоритет.
Приоритеты ресурсов можно посмотреть в Chrome DevTools на вкладке Networking в колонке Priority.
Так, у HTML, CSS и шрифтов самый высокий приоритет. У изображений приоритет изначально низкий, но если Rendering Engine обнаружит, что изображение попадает в поле видимости (view port) пользователя, то повысит приоритет до среднего. Приоритет скрипта зависит от положения на странице и способа загрузки. У асинхронных скриптов (async/defer) низкий приоритет. У скриптов, которые в документе перед изображениями — высокий, у тех, что после хотя бы одного изображение — средний.
По возможности браузер пытается загружать ресурсы параллельно. Однако, он не может загружать параллельно более 6 ресурсов с одного домена.
Кроме того, когда Rendering Engine отдаёт команду компоненту Networking Component на синхронную загрузку стиля или скрипта, он останавливает разбор документа.
С загрузкой стилей происходит подобный процесс преобразования из байтов в Object Model (CSSOM): байты -> символы -> токены -> узлы -> CSSOM.
Немного иначе происходит загрузка скрипта. Вместо того, чтобы вернуть управление Rendering Engine’у, Networking Component . передаёт управление JavaScript Interpreter, который преобразует байты в исполняемый код: байты -> символы -> токены -> Abstract Syntax Tree (evaluating). Далее в работу вступает компилятор, который оптимизирует AST, кэширует некоторые участки кода, компилирует его на лету (JIT compilation) в исполняемый код и исполняет (executing). Однако исполняется скрипт только, когда готова CSSOM. До тех пор скрипт стоит в очереди на исполнение.
Во многих современных браузерах во время исполнения JavaScript в отдельном потоке продолжается сканирование документа на наличие ссылок на другие ресурсы и постановка ресурсов в очередь на скачивание (Speculative parsing).
Каждый этап разбора HTML, CSS и JS можно увидеть в Chrome DevTools во вкладке Performance
Если при загрузке скрипта Rendering Engine видит у скрипта атрибут async, то он не останавливает разбор документа во время загрузки скрипта. Скрипт также станет в очередь на исполнение, дожидаясь, когда CSSOM будет готова.
Если при загрузке скрипта Rendering Engine видит у скрипта атрибут defer, то он не останавливает разбор документа во время загрузки скрипта, но когда скрипт загрузится, он станет в очередь на исполнение, которая заработает при возникновении события DOMContentLoaded. К этому моменту CSSOM будет уже готова.
Когда Rendering Engine заканчивает разбор документа, он вызывает событие DOMContentLoaded, и состояние документа меняется на interactive. При этом ресурсы (например, картинки) могут продолжать загружаться.
Когда все ресурсы загрузились, вызывается событие load, а состояние документа меняется на complete.
После того, как документ полностью разобран и сформированы DOM и CSSOM, Rendering Engine начинает построение Render Tree. В него попадут все элементы, которые нужно отрисовать. Некоторые элементы изначально могут быть невидимыми — их не нужно рисовать. Для каждого элемента, который “выпадает” из потока (например, используется position: absolute), будет создаваться отдельная ветка в Render Tree.
Во время Rendering Tree происходит сопоставление узлов из DOM и узлов CSSOM.
Свойства узла можно получить с помощью функции window.getComputedStyles(узел).
Когда Rendering Tree готов, Rendering Engine запускает процесс layout. Он заключается в вычислении размеров и позиций каждого элемента на странице.
Следующий этап — paint. Rendering Engine вычисляет цвет каждого пикселя.
И, наконец, последний этап — composite. Компонент UI Backend слой за слоем отрисовывает элементы на странице. При этом, если требуется отрисовать изображение, которое ещё не загрузилось, во время процесса layout, Rendering Engine зарезервирует место для изображения, если у него указаны ширина и высота. Rendering Engine вынесет на отдельный слой те элементы, стили которых содержат правила opacity, transform или will-change. Более того, эти слои Rendering Engine передаст для обработки GPU.
Если требуется отобразить текст, для которого используется нестандартный шрифт, то современные браузеры скроют текст до момента загрузки шрифта (flash of invisible text).
В современных браузерах скачивание документа, его разбор и отрисовка происходят по кускам, частями.
В документе HTML могут присутствовать некоторые мета-теги, которые могут менять порядок загрузки ресурсов, а также их приоритет.
К примеру, мета-тег dns-prefetch вынуждает Rendering Engine обратиться к Networking Component и получить IP нужного домена ещё до того, как Rendering Engine встретить его в документе.
Мета-тег prefetch вынудит Networking Component поставить указанный ресурс в очередь на загрузку с низким приоритетом.
Мета-тег preload вынудит Networking Component поставить указанный ресурс в очередь на загрузку с высоким приоритетом.
Мета-тег preconnect вынудит Networking Component заранее подключиться к другом хосту, то есть пройти нужные этапы: DNS lookup, redirects, hand shakes.
Что происходит, когда пользователь набирает в браузере адрес сайта
Простыми словами объясняем, как браузер подключается и общается с сервером.
За работу любого сайта обычно отвечает один из миллионов серверов, подключенных к интернету. Адрес сервера — это уникальный набор цифр, который называется IP-адресом. Например, для vc.ru— это сервер 85.119.149.83.
Поэтому первым делом браузеру нужно понять, какой IP-адрес у сервера, на котором находится сайт.
Такая информация хранится в распределенной системе серверов — DNS (Domain Name System). Система работает как общая «контактная книга», хранящаяся на распределенных серверах и устройствах в интернете.
Однако перед тем, как обращаться к DNS, браузер пытается найти запись об IP-адресе сайта в ближайших местах, чтобы сэкономить время:
- Сначала в своей истории подключений . Если пользователь уже посещал сайт, то в браузере могла сохраниться информация c IP-адресом сервера.
- В операционной системе . Не обнаружив информации у себя, браузер обращается к операционной системе, которая также могла сохранить у себя DNS-запись. Например, если подключение с сайтом устанавливалось через одно из установленных на компьютере приложений.
- В кэше роутера , который сохраняет информацию о последних соединениях, совершенных из локальной сети.
Не обнаружив подходящих записей в кэше, браузер формирует запрос к DNS-серверам, расположенным в интернете.
Например, если нужно найти IP-адрес сайта mail.vc.ru, браузер спрашивает у ближайшего DNS-сервера «Какой IP-адрес у сайта mail.vc.ru?».
Сервер может ответить: «Я не знаю про mail.vc.ru, но знаю сервер, который отвечает за vc.ru». Запрос переадресовывается дальше, на сервер «выше», пока в итоге один из серверов не найдет ответ об IP-адресе для сайта.
Как только браузер узнал IP-адрес нужного сервера, он пытается установить с ним соединение. В большинстве случаев для этого используется специальный протокол — TCP.
TCP — это набор правил, который описывает способы соединения между устройствами, форматы отправки запросов, действия в случае потери данных и так далее.
Например, для установки соединения между браузером и сервером в стандарте TCP используется система «трёх рукопожатий». Работает она так:
- Устройство пользователя отправляет специальный запрос на установку соединения с сервером — называется SYN -пакет.
- Сервер в ответ отправляет запрос с подтверждением получения SYN-пакета — называется SYN/ACK -пакет.
- В конце устройство пользователя при получении SYN/ACK-пакета отправляет пакет с подтверждением — ACK -пакет. В этот момент соединение считается установленным.
После установки соединения браузер отправляет специальный запрос, в котором просит сервер отправить данные для отображения страницы. В этом запросе содержится информация о самом браузере, временные файлы, требования к соединению и так далее.
Задача браузера — как можно подробнее объяснить серверу, какая именно информация ему нужна .
В общении браузера и сервера выделяют два типа запросов. GET-запрос используется для получения данных с сервера — например, отобразить картинку, текст или видео. POST-запрос — используется для отправки данных из браузера на сервер, например, когда пользователь отправляет сообщение, картинку или загружает файл.
Сервер получил запрос от браузера с подробным описанием того, что ему требуется. Теперь ему нужно обработать этот запрос. Этой задачей занимается специальное серверное программное обеспечение — например, nginx или Apache. Чаще всего такие программы принято называть веб-серверами.
Веб-сервер в свою очередь перенаправляет запрос на дальнейшую обработку к программе-обработчику — например, PHP, Ruby или ASP.NET. Программа внимательно изучает содержимое запроса — например, понимает, в каком формате нужно отправить ответ и какие именно файлы нужны. И собирает ответ.
Когда ответ сформирован, он отправляется веб-сервером обратно браузеру. В ответе как правило содержится контент для отображения веб-страницы, информация о типе сжатия данных, способах кэширования, файлы cookie, которые нужно записать и так далее.
Браузер распаковывает полученный ответ и постепенно начинает отображать полученный контент на экране пользователя — этот процесс называется рендерингом .
Сначала браузер загружает только основную структуру HTML-страницы. Затем последовательно проверяет все теги и отправляет дополнительные GET-запросы для получения с сервера различных элементов — картинки, файлы, скрипты, таблицы стилей и так далее. Поэтому по мере загрузки страницы браузер и сервер продолжают обмениваться между собой информацией.
Параллельно с этим на компьютер как правило сохраняются статичные файлы пользователя — чтобы при следующем посещении не загружать их заново и быстрее отобразить пользователю содержимое страницы.
Как только рендеринг завершен — пользователю отобразится полностью загруженная страница сайта.
Как работают HTTP-запросы
Если вы когда-нибудь давали интервью, вас могли спросить: «что происходит, когда вы что-то вводите в поле поиска Google и нажимаете ввод».
Это один из самых популярных вопросов, которые вам задают. Люди просто хотят посмотреть, сможете ли вы объяснить некоторые довольно базовые понятия и понять, как на самом деле работает Интернет.
В этом посте я проанализирую, что происходит, когда вы вводите URL-адрес в адресной строке браузера и нажимаете ввод.
Это очень интересная тема, которую я расскажу в блоге, так как она затрагивает многие технологии, о которых я могу рассказать в отдельных постах.
Это технология, которая очень редко изменяется и питает одну из самых сложных и широких экосистем, когда-либо созданных человеком.
Протокол HTTP
Во-первых, я упоминаю HTTPS, в частности, потому что вещи отличаются от HTTPS-соединения.
Я анализирую только URL-запросы
Современные браузеры имеют возможность узнать, является ли то, что вы написали в адресной строке, фактическим URL или поисковым термином, и они будут использовать поисковую систему по умолчанию, если это не действительный URL.
Я предполагаю, что вы вводите фактический URL.
Когда вы вводите URL и нажимаете ввод, браузер сначала создает полный URL.
Если вы только что ввели домен, например ip-calculator.ru, браузер по умолчанию ip-calculator.ru к нему HTTP:// по умолчанию ip-calculator.ru протокол HTTP.
macOS/Linux
Просто к вашему сведению. Windows может сделать некоторые вещи немного по-другому.
Этап поиска DNS
Браузер запускает поиск DNS, чтобы получить IP-адрес сервера.
Доменное имя — удобный способ для нас, людей, но Интернет организован таким образом, что компьютеры могут искать точное местоположение сервера по его IP-адресу, который представляет собой набор чисел, например 222.324.3.1 (IPv4).
Во-первых, он проверяет локальный кэш DNS, чтобы узнать, был ли домен разрешен недавно.
В Chrome есть удобный визуализатор DNS-кэша, который вы можете увидеть в chrome://net-internals/#dns
Если там ничего не найдено, браузер использует распознаватель DNS, используя системный вызов gethostbyname POSIX для получения информации о хосте.
gethostbyname
Сначала gethostbyname просматривает локальный файл hosts, который в macOS или Linux находится в /etc/hosts , чтобы проверить, предоставляет ли система информацию локально.
Если это не дает никакой информации о домене, система отправляет запрос на DNS-сервер.
Адрес DNS-сервера сохраняется в системных настройках.
- 8.8.8.8: публичный DNS-сервер Google
- 1.1.1.1: DNS-сервер CloudFlare
Большинство людей используют DNS-сервер, предоставленный их интернет-провайдером.
Браузер выполняет DNS-запрос по протоколу UDP.
TCP и UDP являются двумя основополагающими протоколами компьютерных сетей. Они находятся на том же концептуальном уровне, но TCP ориентирован на соединение, а UDP — это протокол без установления соединения, более легкий, используемый для отправки сообщений с небольшими издержками.
Как выполняется UDP-запрос, рассматривается в этом руководстве.
DNS-сервер может иметь IP-адрес домена в кэше. Если нет, он спросит корневой DNS-сервер . Это система (состоящая из 13 реальных серверов, распределенных по всей планете), которая управляет всем интернетом.
DNS-сервер не знает адреса каждого доменного имени на планете.
Он знает, где находятся DNS-преобразователи верхнего уровня .
Домен верхнего уровня — это расширение домена: .com , .it , .pizza и так далее.
Как только корневой DNS-сервер получает запрос, он перенаправляет запрос на этот DNS-сервер домена верхнего уровня (TLD).
Скажем, вы ищете ip-calculator.ru. DNS-сервер корневого домена возвращает IP-адрес TLD-сервера .ru.
Теперь наш распознаватель DNS будет кэшировать IP-адрес этого сервера TLD, поэтому ему не нужно будет снова запрашивать его у корневого DNS-сервера.
DNS-сервер TLD будет иметь IP-адреса официальных серверов имен для домена, который мы ищем.
Как? Когда вы покупаете домен, регистратор домена отправляет соответствующие TDL серверам имен. При обновлении серверов имен (например, при смене провайдера хостинга) эта информация будет автоматически обновляться регистратором вашего домена.
Это DNS-серверы хостинг-провайдера. Их обычно больше 1, чтобы служить резервной копией.
- ns1.example.com
- ns2.example.com
- ns3.example.com
DNS-распознаватель запускается с первого и пытается запросить IP-адрес домена (также с поддоменом), который вы ищете.
Это основной источник правды для IP-адреса.
Теперь, когда у нас есть IP-адрес, мы можем продолжить наше путешествие.
TCP-запрос подтверждения связи
С доступным IP-адресом сервера теперь браузер может инициировать TCP-соединение с этим.
Соединение TCP требует небольшого рукопожатия, прежде чем оно может быть полностью инициализировано, и вы можете начать отправку данных.
Как только соединение установлено, мы можем отправить запрос
Отправка запроса
Запрос представляет собой простой текстовый документ, структурированный точно так, как определено протоколом связи.
Он состоит из 3 частей:
- строка запроса
- заголовок запроса
- тело запроса
Строка запроса
Строка запроса устанавливается в одну строку:
- метод HTTP
- расположение ресурса
- версия протокола
Заголовок запроса
Заголовок запроса представляет собой набор пар field: value которые устанавливают определенные значения.
Есть 2 обязательных поля, одно из которых — «Host , а другое — «Connection , а все остальные поля являются необязательными:
Host указывает доменное имя, на которое мы хотим нацелиться, в то время как Connection всегда close если соединение не должно оставаться открытым.
Некоторые из наиболее часто используемых полей заголовка:
- Origin
- Accept
- Accept-Encoding
- Cookie
- Cache-Control
- Dnt
но существует много других.
Часть заголовка заканчивается пустой строкой.
Тело запроса
Тело запроса является необязательным, не используется в запросах GET, но очень часто используется в запросах POST, а иногда и в других глаголах, и может содержать данные в формате JSON.
Поскольку мы сейчас анализируем запрос GET, тело не заполнено, и мы не будем его больше рассматривать.
Ответ
Как только запрос отправлен, сервер обрабатывает его и отправляет ответ.
Ответ начинается с кода состояния и сообщения о состоянии. Если запрос успешен и возвращает 200, он начнется с:
Запрос может вернуть другой код состояния и сообщение, например, одно из следующих:
Затем ответ содержит список заголовков HTTP и тело ответа (которое, поскольку мы делаем запрос в браузере, будет HTML)
Разбор HTML
Браузер теперь получил HTML-код и начинает его анализировать, и он будет повторять точно такой же процесс, который мы сделали для всех ресурсов, необходимых для страницы:
- CSS файлы
- картинки
- фавикон
- Файлы JavaScript
- …
То, как браузеры отображают страницу, выходит за рамки, но важно понимать, что процесс, который я описал, предназначен не только для страниц HTML, но и для любого элемента, который обслуживается по HTTP.