Веб, HTTP и устройство веб-приложения

Курс посвящён веб-приложениям: программам, которые пользователь открывает в браузере, а данные которых живут на сервере. Прежде чем написать первую строку разметки, разберём механику, на которой держится всё остальное: что происходит между вводом адреса и появлением страницы на экране. Адрес, запрос, ответ, разбор документа, запросы за ресурсами, отрисовка — эта цепочка повторяется при каждом открытии любой страницы, и каждое её звено в дальнейшем получит отдельную тему. Здесь мы пройдём цепочку целиком, чтобы дальше было видно, какое место занимает HTML, где вступает в дело CSS и зачем странице скрипт.

Гипертекст и Всемирная паутина

Гипертекст и гипермедиа

Гипертекст — текст, содержащий ссылки на другие тексты, по которым читатель переходит в выбранном им порядке. Обычная книга читается от начала к концу; гипертекст не имеет единственного порядка чтения, его задаёт сам читатель, выбирая ссылку за ссылкой. Термин предложил Тед Нельсон в 1965 году, описывая файловую структуру для документов, которые меняются и связаны друг с другом ¹. Он же ввёл слово «гипермедиа» — то же самое, но для изображений, звука и видео; в обиходе закрепился первый термин, хотя современный веб гипермедийный по существу.

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

От идеи до современного состояния

В 1989 году Тим Бернерс-Ли, работавший в Европейской организации по ядерным исследованиям (CERN), предложил систему для хранения служебной документации, в которой документы были бы связаны ссылками и доступны с любого компьютера сети ². Из этого предложения выросли три составляющие, определяющие веб до сих пор: единообразный адрес ресурса (URL), протокол передачи гипертекста (HTTP) и язык разметки гипертекста (HTML). К концу 1990 года были написаны первый сервер и первый браузер, а в 1991 году система стала доступна за пределами CERN.

Веб часто отождествляют с интернетом, и это неточно. Интернет — сеть сетей, обеспечивающая доставку пакетов между машинами; он существовал за двадцать лет до веба и обслуживает электронную почту, передачу файлов и многое другое. Веб — один из сервисов поверх интернета: набор соглашений о том, как называть документы, как их запрашивать и как записывать. Именно эти соглашения мы будем изучать.

Базовая механика веба за тридцать лет не изменилась: пользователь называет адрес, браузер отправляет запрос, сервер возвращает документ, браузер его отображает. Изменилось содержание документа. Первые страницы были статичными: сервер отдавал файл как есть. С появлением форм страница научилась отправлять данные обратно, и сервер стал собирать документы на лету. С появлением скриптов страница научилась меняться прямо в браузере и запрашивать данные, не перезагружаясь. Так документ превратился в приложение: программу, которая выполняется в браузере и разговаривает с сервером. Механика запроса и ответа осталась прежней, и потому начинать надо с неё.

Адресация и протокол

URL

Единообразный указатель ресурса (Uniform Resource Locator, URL) — строка, по которой браузер находит ресурс в сети. Правила её записи закреплены стандартом ³. Рассмотрим адрес, в котором присутствуют все составляющие:

https://tasks.example.ru:8080/api/tasks?status=active&page=2#top

Схема https называет протокол, по которому следует обращаться к ресурсу. Хост tasks.example.ru — имя машины в сети; перед отправкой запроса браузер переводит его в числовой адрес, обращаясь к системе доменных имён (DNS). Порт 8080 — номер, по которому операционная система сервера различает программы, принимающие соединения; если порт не указан, он подразумевается схемой: 80 для http, 443 для https. Путь /api/tasks указывает ресурс внутри хоста; исторически он совпадал с путём к файлу на диске, у приложения же путь — имя, которое сервер истолковывает сам. Параметры запроса после ? — пары «имя — значение», соединённые знаком &; так странице передают уточнения: фильтр, номер страницы, поисковую строку. Фрагмент после # адресует часть документа и на сервер не отправляется: с ним работает только браузер, прокручивая страницу к нужному месту.

В адресе допустимы латинские буквы, цифры и небольшой набор знаков. Всё остальное — кириллица, пробел, сами служебные знаки внутри значений — передаётся в закодированном виде: каждый байт представления UTF-8 записывается как знак % и два шестнадцатеричных разряда. Слово «задачи» превращается в %D0%B7%D0%B0%D0%B4%D0%B0%D1%87%D0%B8, по два байта на букву. Адресная строка браузера показывает адрес в раскодированном виде для удобства чтения, но на сервер уходит закодированный.

Адрес может быть относительным: ссылка tasks.html в документе https://example.ru/app/index.html разрешается в https://example.ru/app/tasks.html, а /tasks.html — в https://example.ru/tasks.html, от корня хоста. Разметка документа почти целиком состоит из относительных адресов, и правила их разрешения понадобятся уже в теме 2.

HTTP: запрос и ответ

Протокол передачи гипертекста (HyperText Transfer Protocol, HTTP) устроен по схеме «запрос — ответ»: клиент отправляет запрос, сервер возвращает ответ, после чего обмен завершён. Актуальное описание семантики протокола содержится в стандарте ⁴. Сообщения обоих направлений имеют одинаковое строение: стартовая строка, заголовки, пустая строка, тело.

Стартовая строка запроса содержит метод, адрес ресурса и версию протокола: GET /api/tasks?status=active HTTP/1.1. Метод называет действие. GET запрашивает ресурс и не имеет тела; такой запрос не должен ничего менять на сервере, поэтому его можно повторять и кешировать. POST передаёт данные в теле запроса: отправка формы, создание записи. PUT заменяет ресурс целиком, PATCH изменяет его часть, DELETE удаляет. Заголовки запроса уточняют, кто и что просит: Host называет хост из адреса, User-Agent — программу-клиент, Accept и Accept-Language — предпочтительные формат и язык ответа, Cookie возвращает серверу ранее выданные им данные.

Стартовая строка ответа содержит версию протокола, код состояния и его словесное пояснение: HTTP/1.1 200 OK. Код — трёхзначное число, первая цифра которого задаёт класс. Класс 2xx означает успех: 200 — ресурс в теле ответа, 201 — ресурс создан, 204 — выполнено, тела нет. Класс 3xx — перенаправление: 301 и 302 сообщают, что ресурс находится по адресу из заголовка Location, и браузер переходит по нему сам; 304 означает, что ресурс не изменился и браузер может взять копию из своего кеша. Класс 4xx — ошибка на стороне клиента: 400 — запрос составлен неверно, 401 и 403 — требуется вход или доступ запрещён, 404 — по такому адресу ничего нет. Класс 5xx — ошибка на стороне сервера: 500 — сбой программы, 502 и 503 — сервер недоступен. Важная особенность: код 404 или 500 — это полноценный ответ с заголовками и, как правило, с телом; с точки зрения протокола обмен состоялся, просто результат отрицательный. Заголовки ответа описывают тело: Content-Type называет формат (text/html, text/css, application/json, image/svg+xml), Content-Length — размер, Cache-Control — как долго ответ можно хранить в кеше; Set-Cookie передаёт клиенту данные, которые тот будет возвращать в последующих запросах.

Последний заголовок отвечает на вопрос, который протокол иначе оставляет открытым. HTTP не хранит состояния: сервер не помнит предыдущих запросов клиента, и каждый запрос для него самостоятелен. Чтобы сервер узнавал вернувшегося пользователя, состояние переносится в самом обмене: сервер выдаёт клиенту метку в Set-Cookie, клиент прикладывает её к каждому следующему запросу в Cookie. На этом устроены сеансы и вход в систему, к чему мы вернёмся в теме 9.

Схема https означает тот же HTTP, но поверх шифрованного соединения (TLS). Шифрование скрывает содержимое обмена от посредников, а сертификат сервера подтверждает, что клиент разговаривает именно с тем хостом, который назван в адресе. Строение сообщений при этом не меняется. Не меняется оно и в новых версиях протокола: HTTP/2 и HTTP/3 передают те же методы, коды и заголовки в двоичном виде и эффективнее используют соединение, но для автора приложения выглядят так же, как текстовый HTTP/1.1.

Цикл загрузки страницы

Соединим адрес и протокол в последовательность действий, которую браузер выполняет при открытии страницы. Получив адрес, браузер узнаёт у системы доменных имён числовой адрес хоста, устанавливает с ним соединение — для https ещё и согласует шифрование — и отправляет запрос GET с путём из адреса. Сервер отвечает документом. Браузер начинает разбирать документ, не дожидаясь его конца, и по мере разбора обнаруживает ссылки на ресурсы: таблицы стилей, скрипты, изображения, шрифты. За каждым ресурсом отправляется отдельный запрос, нередко к другим хостам: библиотеки и шрифты часто лежат в сетях доставки содержимого, счётчики посещений — на серверах аналитики. Получив стили, браузер вычисляет раскладку и отрисовывает страницу; получив скрипты, выполняет их, и скрипты, в свою очередь, могут отправить новые запросы уже за данными.

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

Браузер как среда выполнения

Архитектура браузера

Браузер — программа, которая получает документы по HTTP и превращает их в изображение на экране и в среду для выполнения скриптов. Внутри он состоит из нескольких подсистем, и их разделение объясняет многое из того, что встретится в курсе ⁵.

Сетевой слой выполняет запросы и принимает ответы: именно он реализует протокол, разобранный выше. Разборщик HTML превращает текст документа в дерево элементов — объектную модель документа (DOM), с которой затем работают остальные подсистемы и скрипты. Разборщик CSS строит из таблиц стилей набор правил и сопоставляет их элементам дерева. Движок отрисовки вычисляет по дереву и стилям положение и размер каждого элемента (раскладку) и рисует результат. Интерпретатор JavaScript выполняет скрипты, которые читают и изменяют дерево документа, отчего движок перерисовывает страницу. Хранилище держит cookies и данные, которые страница сохраняет между посещениями.

Ключевые подсистемы объединяют в движок, и движков в современных браузерах три. Blink с интерпретатором V8 лежит в основе Chrome, а также Edge, Opera и Яндекс Браузера; WebKit с JavaScriptCore — в основе Safari; Gecko со SpiderMonkey — в основе Firefox. Для автора приложения это означает, что проверять страницу достаточно в трёх браузерах разных семейств, а не во всех существующих.

Каждая вкладка современного браузера выполняется в отдельном процессе, изолированном от других вкладок и от операционной системы. Страница не может читать файлы на диске пользователя, обращаться к другим вкладкам или к произвольным программам: всё, что ей доступно, — это набор интерфейсов, предоставленных браузером. Ограничение распространяется и на сеть: скрипт со страницы одного хоста по умолчанию не может читать ответы другого хоста. Это правило одного источника ещё встретится в теме 8, когда клиент и сервер данных окажутся на разных портах.

Инструменты разработчика

Все перечисленные подсистемы браузер показывает изнутри через инструменты разработчика, встроенные в каждый современный браузер и открываемые клавишей F12. Панель Elements отображает дерево документа — то, что построил разборщик, а не исходный текст; дерево живое, его можно править на месте и видеть результат. Панель Console выполняет команды JavaScript в контексте страницы и показывает ошибки скриптов. Панель Network перечисляет все запросы страницы с методом, кодом ответа, типом и размером, а по щелчку раскрывает заголовки и тело; здесь протокол виден без посредников. Панель Application показывает хранилище: cookies и сохранённые страницей данные.

Инструменты разработчика — рабочий инструмент курса на всём его протяжении. Проверять разметку, отлаживать стили, исследовать поведение скриптов и наблюдать обмен с сервером мы будем в них, а не догадками.

Стандартизация

Соглашения, из которых состоит веб, закреплены в открытых стандартах, и знать, где они лежат, полезно с первого дня. Адрес и протокол описаны документами RFC, которые выпускает Инженерный совет интернета (IETF): URL — в RFC 3986, семантика HTTP — в RFC 9110. Язык HTML и объектная модель документа развиваются в группе WHATWG как «живой стандарт» без номеров версий: спецификация обновляется непрерывно, а привычное обозначение HTML5 осталось от последней нумерованной редакции ⁶. Консорциум W3C, основанный в 1994 году Бернерсом-Ли, с 2019 года отвечает за CSS, доступность (WCAG) и ряд программных интерфейсов. Язык JavaScript стандартизирован под именем ECMAScript организацией Ecma International, редакции выходят ежегодно.

Стандарты не гарантируют одинакового поведения: браузеры реализуют их с разной полнотой и в разное время. Поэтому рядом со спецификациями существуют таблицы совместимости, показывающие, какая возможность в каком браузере поддерживается, и справочники, пересказывающие стандарты человеческим языком, — среди них Mozilla Developer Network (MDN). В курсе мы будем опираться на спецификации и MDN как на источники, которым можно верить, и с осторожностью относиться к случайным руководствам, часть которых описывает веб десятилетней давности.

Веб-приложение и его части

Клиент и сервер

Вернёмся к тому, с чего начали: веб-приложение — программа, разделённая на две части, работающие на разных машинах. Клиентская часть выполняется в браузере пользователя: она отображает данные, принимает ввод и выполняет ту часть логики, которую можно доверить браузеру. Серверная часть принимает запросы, применяет правила, хранит данные и отвечает документами или данными. Между ними — только HTTP: клиент ничего не знает об устройстве сервера, кроме адресов и формата ответов, сервер ничего не знает о клиенте, кроме содержания запросов.

Разделение обязанностей удобно рассмотреть на трёх поколениях веб-приложений. У статического сайта сервер — хранилище файлов: он отдаёт документы как есть, все данные записаны в самих документах, а любое изменение требует правки файлов. Приложение первого поколения отправляет ввод пользователя формой, сервер собирает новый документ на каждый запрос и возвращает его целиком; данные живут в базе на сервере, а каждое действие перезагружает страницу. Приложение с интерфейсом данных (API) разделяет обязанности иначе: сервер отдаёт данные в формате JSON, а страницу строит скрипт в браузере, запрашивая данные по мере надобности и меняя страницу без перезагрузки. Данные при этом по-прежнему хранятся на сервере, у клиента — только копия, которую он может дополнительно сохранить в браузере между посещениями.

Из разделения следует правило, к которому курс будет возвращаться. Клиентская часть работает на машине пользователя и целиком ему подконтрольна: он может изменить скрипт, отправить запрос в обход страницы, подставить любые значения. Всё, что важно для целостности данных, проверяет сервер; клиент делает проверки ради удобства, а не ради защиты. В теме 9 эта граница между доверенной и недоверенной частью будет рассмотрена подробно.

Ориентиры курса

Курс охватывает клиентскую часть веб-приложения. Мы будем писать документы на HTML, оформлять их на CSS, программировать поведение на JavaScript и обмениваться данными с сервером по HTTP. Серверную часть мы получим готовой: программа, отдающая данные в формате JSON по заранее известным адресам, будет запускаться одной командой, а её устройство рассмотрим обзорно в заключительной теме. Программирование серверной части, развёртывание и клиентские фреймворки остаются за рамками курса и лишь упоминаются там, где без этого не обойтись.

Учебное приложение курса — список задач. Оно пройдёт три состояния, повторяющие три поколения веб-приложений: сначала страница, размеченная и оформленная; затем приложение, работающее целиком в браузере и хранящее задачи локально; наконец, клиент, получающий и изменяющий задачи на сервере по HTTP. Инструменты на всём пути одни и те же: браузер с инструментами разработчика, текстовый редактор и локальный сервер, отдающий файлы по HTTP так же, как это делает настоящий.

Итоги темы

Веб — сервис поверх интернета, построенный на трёх соглашениях: адресе ресурса, протоколе передачи и языке разметки. Адрес состоит из схемы, хоста, порта, пути, параметров запроса и фрагмента; всё, что выходит за пределы латиницы и цифр, кодируется побайтно. HTTP — протокол без состояния по схеме «запрос — ответ»; сообщения состоят из стартовой строки, заголовков и тела, метод называет действие, код состояния — результат, а ответ с кодом ошибки остаётся полноценным ответом.

Загрузка страницы — не один запрос, а последовательность: документ, затем ресурсы, на которые он ссылается, позже данные, запрошенные скриптом. Браузер разбирает документ в дерево, применяет стили, отрисовывает результат и выполняет скрипты в изолированном процессе; инструменты разработчика показывают каждую из этих подсистем.

Веб-приложение разделено на клиент в браузере и сервер, связанные только HTTP. Клиент отображает и принимает ввод, сервер хранит данные и проверяет всё, что важно. В курсе мы строим клиентскую часть: от документа на HTML до приложения, обменивающегося данными с готовым сервером.

Литература

1. Nelson T. H. Complex Information Processing: A File Structure for the Complex, the Changing and the Indeterminate. — Proceedings of the 1965 20th National Conference, 1965, С. 84–100, DOI: 10.1145/800197.806036.
2. Berners-Lee T. Information Management: A Proposal. — 1989, https://www.w3.org/History/1989/proposal.html.
3. Berners-Lee T., Fielding R. T., Masinter L. Uniform Resource Identifier (URI): Generic Syntax. — 2005, DOI: 10.17487/RFC3986.
4. Fielding R. T., Nottingham M., Reschke J. HTTP Semantics. — 2022, DOI: 10.17487/RFC9110.
5. Kosaka M. Inside look at modern web browser. — 2018, https://developer.chrome.com/blog/inside-browser-part1.
6. {WHATWG}. HTML Living Standard. — 2026, https://html.spec.whatwg.org/multipage/.

Лабораторная работа 1. HTTP-обмен глазами браузера

• Объём: 6 академических часов
• Раздел курса: тема 1 «Веб, HTTP и устройство веб-приложения»
• Формируемые компетенции: ПК-2, ПК-6

Введение

Лекция по теме 1 описала веб-приложение как обмен запросами и ответами между браузером и сервером. Пока это описание остаётся словесным, оно легко принимается на веру и так же легко забывается. В настоящей работе обмен предстоит увидеть: каждая загрузка страницы раскладывается на десятки запросов, у каждого есть метод, адрес, код ответа и заголовки, и всё это браузер показывает в инструментах разработчика.

Вторая половина работы переносит наблюдение на собственную страницу. Мы развернём локальный сервер, получим от него документ по HTTP и убедимся, что механика та же, что у крупного сайта. Каталог, созданный в этой работе, станет приложением «Список задач», которое будет расти до конца практикума.

Цель работы

Освоить чтение HTTP-обмена в инструментах разработчика браузера на материале реального сайта и собственной страницы, обслуживаемой локальным сервером.

После выполнения работы студент сможет:

• разобрать URL на составляющие и указать, какая из них попадает в стартовую строку HTTP-запроса, а какая — в заголовок Host;
• по панели Network определить для любого запроса метод, код ответа, тип и размер содержимого и отличить запрос документа от запросов ресурсов;
• объяснить на примерах из собственного отчёта коды 200, 301/302, 304 и 404;
• показать, как символы кириллицы кодируются в адресе, и раскодировать фрагмент вручную;
• развернуть локальный статический сервер и получить свою страницу по адресу http://127.0.0.1:<порт>/;
• показать на уровне запросов разницу между открытием файла по file:// и по http://.

Теоретический минимум

Устройство URL, методы и коды состояния HTTP, цикл загрузки страницы и архитектура браузера изложены в учебном пособии, тема 1. Ниже — только то, что потребуется руками.

Инструменты разработчика. Открываются клавишей F12 или сочетанием Ctrl+Shift+I (Cmd+Option+I на macOS). Панель Network показывает запросы, сделанные страницей, начиная с момента открытия панели: если страница уже загружена, её нужно перезагрузить при открытой панели. Флажок Disable cache заставляет браузер запрашивать все ресурсы заново, флажок Preserve log сохраняет список при переходах между страницами. Кнопки фильтра по типу — Doc, CSS, JS, Img, Font, Fetch/XHR, Other — оставляют в списке запросы одного вида. Строка состояния внизу панели показывает число запросов, переданный объём и время завершения загрузки. Щелчок по запросу открывает его карточку: раздел Headers содержит общие сведения (адрес, метод, код ответа, адрес сервера), заголовки ответа и заголовки запроса; раздел Response — тело ответа как текст, Preview — тело в разобранном виде. В Firefox панель называется так же и устроена аналогично.

Коды состояния, которые встретятся в работе. 200 — запрос выполнен, тело содержит запрошенное. 301 и 302 — ресурс находится по другому адресу, который указан в заголовке Location; браузер переходит по нему сам. 304 — ресурс не изменился с прошлого раза, тело не передаётся, браузер берёт копию из своего кеша. 404 — по такому адресу на сервере ничего нет. Полная классификация — в пособии.

Кодирование адреса. В URL допустимы только символы латинского алфавита, цифры и небольшой набор знаков. Всё остальное, включая кириллицу и пробел, передаётся в виде байтов UTF-8, каждый байт записывается как % и два шестнадцатеричных знака. Буква «г» занимает в UTF-8 два байта, D0 и B3, и в адресе выглядит как %D0%B3. Адресная строка браузера показывает адрес в раскодированном виде для удобства чтения; в панели Network виден адрес, который ушёл на сервер.

Локальный сервер, localhost и порт. Адрес 127.0.0.1 и имя localhost обозначают саму машину, на которой запущен браузер. Порт — число, по которому операционная система различает программы, принимающие соединения; два сервера не могут одновременно слушать один порт. Локальный статический сервер отдаёт файлы из выбранного каталога по HTTP, ничего в них не меняя. В работе используется расширение Live Server для VS Code: после установки в строке состояния редактора появляется кнопка Go Live, которая запускает сервер на порту 5500 и открывает в браузере адрес http://127.0.0.1:5500/ (в некоторых сборках отображается как http://localhost:5500/). Сервер отдаёт файл index.html из открытой в редакторе папки и перезагружает страницу при каждом сохранении файла. Если VS Code недоступен, подойдёт любой статический сервер, например python -m http.server 8000, выполненный в каталоге проекта; тогда адрес будет http://127.0.0.1:8000/.

Минимальный документ. Устройство HTML-документа подробно разбирается в теме 2. В этой работе документ используется как готовая заготовка:

<!DOCTYPE html>
<html lang="ru">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Список задач</title>
</head>
<body>
  <h1>Список задач</h1>
  <p>Приложение курса «Разработка Web-приложений».</p>
</body>
</html>

Файл сохраняется в кодировке UTF-8 — иначе кириллица отобразится знаками вопроса. VS Code по умолчанию сохраняет в UTF-8; текущая кодировка видна в правой части строки состояния.

Консоль. Панель Console выполняет команды JavaScript в контексте открытой страницы. Язык разбирается начиная с темы 5; здесь достаточно ввести три готовые команды и записать, что они вернули.

Перечень оснащения

• Браузер Chrome, Chromium-совместимый или Firefox актуальной версии.
• Доступ в интернет к сайту из перечня вариантов и к ru.wikipedia.org.
• Для части 3: VS Code (обычная установка либо portable-сборка, не требующая прав администратора) с расширением Live Server; при отсутствии — Python 3 с модулем http.server.
• Каталог проекта tasks-app/, создаваемый в части 3.
• Части 1 и 2 выполняются в браузере и не требуют установки чего-либо.

Порядок выполнения работы

Сайт для частей 1 и 2 назначается по номеру варианта (см. «Варианты заданий»). Все скриншоты делаются с собственного экрана: в отчёте должны быть видны адрес сайта варианта и панель Network целиком.

Часть 1. Загрузка страницы как последовательность запросов

Задание 1.1. Откройте инструменты разработчика, перейдите на панель Network, включите Disable cache. Загрузите главную страницу сайта варианта. По строке состояния панели запишите число запросов, переданный объём и время завершения загрузки. Сделайте скриншот панели.

Задание 1.2. Найдите в списке запрос самого документа — как правило, он первый и имеет тип document. Откройте его карточку и заполните таблицу 1: полный адрес запроса, метод, код ответа, адрес сервера с портом, значения заголовков ответа Content-Type, Content-Length или Content-Encoding, Server (если есть), Cache-Control (если есть) и заголовков запроса Host, User-Agent, Accept, Accept-Language.

Задание 1.3. Пользуясь фильтрами по типу, посчитайте число запросов и суммарный объём для каждого вида: документ, стили, скрипты, изображения, шрифты, Fetch/XHR, прочее. Результат оформите таблицей 2. Отдельно укажите самый большой по объёму и самый долгий по времени ресурс. Выпишите все хосты, с которых загружались ресурсы, помимо основного: для каждого предположите, что он обслуживает (сеть доставки содержимого, счётчик посещений, шрифты, реклама).

Задание 1.4. Выберите три адреса из списка запросов: адрес документа, адрес ресурса с параметрами запроса после ? и адрес ресурса с другого хоста. Разберите каждый на составляющие: схема, хост, порт (явный или подразумеваемый схемой), путь, параметры запроса, фрагмент.

Результат. Скриншот панели, таблицы 1 и 2, перечень хостов с предположениями, разбор трёх адресов.

Часть 2. Коды состояния, перенаправления и кодирование адреса

Задание 2.1. Введите адрес сайта варианта со схемой http:// вместо https://. Найдите в панели запрос с кодом 301 или 302, запишите его заголовок Location и адрес, на котором браузер в итоге оказался. Если сайт варианта не перенаправляет, повторите опыт с http://cchgeu.ru/.

Задание 2.2. Запросите заведомо несуществующий путь на сайте варианта, например /no-such-page-lr01/. Запишите код ответа и заголовок Content-Type. Откройте раздел Response и убедитесь, что вместе с кодом 404 сервер прислал тело — как правило, страницу с сообщением. Сохраните первые строки тела в отчёт.

Задание 2.3. Снимите флажок Disable cache и перезагрузите главную страницу дважды. Найдите ресурсы, для которых во второй раз в колонке Size стоит «(memory cache)», «(disk cache)» или код ответа 304. Запишите три примера с адресами и объясните, чем повторная загрузка отличалась от первой.

Задание 2.4. Выполните на сайте варианта поиск по слову «гипертекст»; если поиска на сайте нет, используйте ru.wikipedia.org. Сравните адрес в адресной строке с адресом запроса в панели Network. Выпишите закодированный фрагмент и раскодируйте вручную первые две буквы, показав соответствие байтов и символов.

Задание 2.5. Откройте ru.wikipedia.org, включите фильтр Fetch/XHR и начните набирать слово в поле поиска. Найдите запросы к api.php с параметром action=opensearch. Для одного из них запишите метод, параметры адреса, код ответа, Content-Type и содержимое раздела Preview. Страница при этом не перезагружалась — зафиксируйте это наблюдение: именно так приложение тем 8–9 будет получать данные.

Результат. Таблица наблюдавшихся кодов с адресами и пояснениями, первые строки тела ответа 404, раскодированный фрагмент, скриншот раздела Preview с JSON.

Часть 3. Рабочее место и первая страница по HTTP

Задание 3.1. Установите или распакуйте VS Code, установите расширение Live Server. Создайте каталог tasks-app/, откройте его в редакторе как папку, создайте файл index.html с содержимым из теоретического минимума. Убедитесь, что файл сохранён в UTF-8.

Задание 3.2. Откройте index.html двойным щелчком из проводника. Запишите адрес из адресной строки и содержимое панели Network после перезагрузки: какие запросы видны, есть ли у них код ответа и заголовки. Сделайте скриншот.

Задание 3.3. Нажмите Go Live. Запишите адрес, который открылся, и заполните для запроса документа ту же таблицу, что в задании 1.2. Сравните карточку запроса с результатом задания 3.2 и с карточкой документа сайта варианта.

Задание 3.4. Добавьте в head строку <link rel="stylesheet" href="css/style.css">, а в body — строку <img src="/img/aidt-bac-webdev/topic-01/logo.svg" alt="Логотип">, не создавая самих файлов. Сохраните документ и зафиксируйте в панели Network два запроса с кодом 404. Затем создайте каталог css/ с файлом style.css, содержащим одно правило h1 { color: #6940ee; }, и каталог img/ с любым небольшим изображением logo.svg или logo.png (поправьте src под фактическое имя). Убедитесь, что коды сменились на 200, и запишите порядок, в котором браузер сделал три запроса.

Задание 3.5. Измените текст заголовка h1 в редакторе и сохраните файл — страница перезагрузится сама. Затем в панели Console выполните по очереди document.title, location.href и document.querySelector('h1').textContent, записав результат каждой команды. В панели Elements измените текст заголовка прямо в дереве, убедитесь, что страница отобразила изменение, перезагрузите её и зафиксируйте, что изменение исчезло.

Результат. Скриншоты панели Network для file:// и http://, таблица для запроса документа с локального сервера, список трёх запросов с кодами до и после создания файлов, результаты трёх команд консоли, каталог tasks-app/.

Часть 4. Выводы

Задание. Ответьте письменно на четыре вопроса, опираясь на собственные наблюдения и цифры из частей 1–3.

1. Из скольких запросов и к скольким хостам состояла загрузка одной страницы сайта варианта? Кто решает, какие запросы будут сделаны после запроса документа?
2. Чем ответ 404 отличается от ситуации «сервер недоступен»? Что именно прислал сервер в теле ответа 404 и зачем?
3. Почему при повторной загрузке часть ресурсов не запрашивалась с сервера? В чём выгода для пользователя и в чём — для сервера?
4. Чем открытие index.html по file:// отличается от открытия по http://127.0.0.1:5500/ с точки зрения панели Network? Почему для следующих работ понадобится именно сервер?

Результат. Письменные ответы на четыре вопроса.

Форма отчёта

Отчёт — один файл в формате Markdown lr01_<фамилия>.md и каталог lr01_<фамилия>_img/ со скриншотами, на которые файл ссылается. В отчёте должны присутствовать:

• номер варианта и адрес сайта;
• таблицы 1 и 2 части 1, перечень хостов, разбор трёх адресов;
• таблица кодов состояния части 2 с адресами, первые строки тела ответа 404, раскодированный фрагмент адреса;
• скриншоты: панель Network при загрузке сайта варианта, ответ 404, Preview с JSON, панель Network для file:// и для http://;
• таблица запроса документа с локального сервера, результаты команд консоли;
• ответы на четыре вопроса части 4.

Вместе с отчётом сдаётся каталог tasks-app/ — в следующей работе он продолжается. Способ передачи файлов преподавателю объявляется на занятии.

Варианты заданий

Номер варианта — порядковый номер студента в журнале группы; при числе студентов больше шестнадцати нумерация идёт по кругу.

Если сайт варианта недоступен из аудитории, студент сообщает об этом преподавателю и получает сайт из свободного варианта.

Контрольные вопросы

1. Какие части URL попадают в стартовую строку HTTP-запроса, какая — в заголовок Host, и что происходит с фрагментом после #?
2. Почему браузер делает десятки запросов ради одной страницы и откуда он узнаёт, какие именно?
3. Чем 301 отличается от 302 с точки зрения браузера и его кеша?
4. Сервер ответил кодом 404 и прислал страницу с текстом. Считать ли запрос выполненным? Что увидит программа, а что — человек?
5. Что означает код 304 и кому он выгоден?
6. Почему кириллица в адресе превращается в последовательности вида %D0%B3 и сколько байтов занимает одна русская буква?
7. Что обозначают localhost и порт, и почему два сервера не могут слушать один порт?
8. Что показывает панель Elements — файл на диске или что-то другое? Как это было проверено в работе?