Какая программа на сервере получает и обрабатывает запрос от вашего интернет-браузера

Обновлено: 15.05.2024

Клиент (обычно браузер) открывает соединение с сервером и отправляет запрос.

Сервер обрабатывает запрос, формирует ответ и закрывает соединение, если находит заголовок Connection: Close.

За этим обычно следует несколько заголовков, пустая строка, обозначающая конец заголовков, а иногда и данные тела. Заголовки могут предоставлять различную информацию о запросе или данных тела клиента. Заголовки обычно отправляются только для методов POST и PUT.

Сервер получает запрос и обрабатывает его. Он обрабатывает каждый запрос отдельно, хотя может обрабатывать много запросов одновременно. Каждый запрос разбит на ряд шагов, которые вместе составляют процесс обработки запроса.

Фильтры NSAPI

В предыдущих версиях веб-сервера NSAPI API позволял нескольким функциям SAF взаимодействовать при обработке запросов. Например, один SAF может использоваться для аутентификации клиента, после чего второй SAF будет генерировать содержимое.

В дополнение к существующим интерфейсам NSAPI в Sun Java System Web Server представлены фильтры NSAPI, которые позволяют функции перехватывать (и потенциально изменять) содержимое, представленное или созданное другой функцией.

Для получения дополнительной информации о фильтрах NSAPI в Sun Java System Web Server 6.1 см. главу 4, Создание пользовательских фильтров.

Два новых этапа NSAPI, Input и Output, можно использовать для вставки фильтров в obj.conf. Этапы Input и Output описаны далее в этой главе.

Процесс обработки запросов

После того, как виртуальный сервер выбран, файл obj.conf для класса виртуального сервера указывает, как обрабатывается запрос на следующих шагах:

Для обработки запроса

AuthTrans (перевод авторизации)

Проверьте всю информацию для авторизации (например, имя и пароль), отправленную в запросе.

NameTrans (перевод имени)

Перевести логический URI в путь локальной файловой системы.

PathCheck (проверка пути)

Проверьте правильность пути в локальной файловой системе и убедитесь, что запрашивающая сторона имеет права доступа к запрошенному ресурсу в файловой системе.

ObjectType (тип объекта)

Определить MIME-тип (многоцелевое кодирование почты Интернета) запрашиваемого ресурса (например, text/html, image/gif и т. д.) .

Ввод (подготовьтесь к чтению ввода)

Выберите фильтры, которые будут обрабатывать входящие данные запроса, прочитанные на этапе Service.

Вывод (подготовка к отправке вывода)

Выберите фильтры, которые будут обрабатывать исходящие данные ответа, созданные на этапе Service.

Сервис (генерировать ответ)

Создайте и верните ответ клиенту.

AddLog (добавление записей журнала)

Добавить записи в файл(ы) журнала.

Ошибка (служба)

Этот шаг выполняется только в том случае, если на предыдущих шагах возникла ошибка. При возникновении ошибки сервер регистрирует сообщение об ошибке и прерывает процесс.

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

Предварительные требования:	Базовая компьютерная грамотность. Базовое понимание того, что такое веб-сервер.
Цель:	Понимать взаимодействие клиент-сервер на динамическом веб-сайте и в частности, какие операции должны выполняться серверным кодом.

В обсуждении нет реального кода, потому что мы еще не выбрали веб-фреймворк для написания нашего кода! Тем не менее, это обсуждение по-прежнему очень актуально, потому что описанное поведение должно быть реализовано вашим кодом на стороне сервера, независимо от того, какой язык программирования или веб-фреймворк вы выберете.

Этот запрос включает:

Веб-серверы ожидают сообщений с запросами клиентов, обрабатывают их, когда они приходят, и отвечают веб-браузеру ответным сообщением HTTP. Ответ содержит код состояния ответа HTTP, указывающий, был ли запрос выполнен успешно (например, «200 OK» для успеха, «404 Not Found», если ресурс не может быть найден, «403 Forbidden», если пользователь не авторизован для просмотра ресурс и др.). Тело успешного ответа на запрос GET будет содержать запрошенный ресурс.

Как статические, так и динамические веб-сайты (обсуждаемые в следующих разделах) используют одни и те же протоколы/шаблоны связи.

Пример запроса/ответа GET

Вы можете сделать простой запрос GET, щелкнув ссылку или выполнив поиск на сайте (например, на главной странице поисковой системы).Например, HTTP-запрос, который отправляется, когда вы выполняете поиск в MDN по термину «обзор клиент-сервер», будет очень похож на текст, показанный ниже (он не будет идентичен, поскольку части сообщения зависят от вашего браузера/настройки). ).

Примечание. Формат сообщений HTTP определяется "веб-стандартом" (RFC7230). Вам не нужно знать такой уровень детализации, но, по крайней мере, теперь вы знаете, откуда все это взялось!

Запрос

Каждая строка запроса содержит информацию о нем. Первая часть называется заголовком и содержит полезную информацию о запросе, точно так же, как заголовок HTML содержит полезную информацию о HTML-документе (но не само фактическое содержимое, которое находится в теле):

Первая и вторая строки содержат большую часть информации, о которой мы говорили выше:

Остальные строки содержат информацию об используемом браузере и типах ответов, которые он может обрабатывать. Например, здесь вы можете увидеть, что:

Ответ

Первая часть ответа на этот запрос показана ниже. Заголовок содержит следующую информацию:

Первая строка содержит код ответа 200 OK , который говорит нам об успешном выполнении запроса.
Мы видим, что ответ имеет формат text/html ( Content-Type ).
Мы также видим, что он использует набор символов UTF-8 ( Content-Type: text/html; charset=utf-8 ).
Заголовок также сообщает нам, насколько он велик ( Content-Length: 41823 ).

В конце сообщения мы видим содержимое тела, которое содержит фактический HTML-код, возвращаемый запросом.

Остальная часть заголовка ответа включает информацию об ответе (например, когда он был сгенерирован), сервере и о том, как он ожидает, что браузер будет обрабатывать страницу (например, строка X-Frame-Options: DENY сообщает браузеру, что чтобы разрешить встраивание этой страницы в другой сайт).

Пример запроса/ответа POST

Запрос

Основное отличие состоит в том, что URL не имеет параметров. Как видите, информация из формы закодирована в теле запроса (например, полное имя нового пользователя задается с помощью: &user-fullname=Hamish+Willee ).

Ответ

Статические сайты

Статический сайт – это сайт, который возвращает одно и то же жестко запрограммированное содержимое с сервера при каждом запросе определенного ресурса. Так, например, если у вас есть страница о продукте в /static/myproduct1.html , эта же страница будет возвращена каждому пользователю. Если вы добавите на свой сайт еще один похожий продукт, вам нужно будет добавить еще одну страницу (например, myproduct2.html) и так далее. Это может стать действительно неэффективным — что произойдет, когда вы доберетесь до тысяч страниц продукта? Вы будете повторять много кода на каждой странице (базовый шаблон страницы, структура и т. д.), и если вы захотите что-то изменить в структуре страницы — например, добавить новый раздел «сопутствующие товары», — тогда вы приходится менять каждую страницу по отдельности.

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

Давайте повторим, как это работает, снова взглянув на диаграмму архитектуры статического сайта, которую мы рассматривали в предыдущей статье.

Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос GET с указанием URL-адреса его HTML-страницы. Сервер извлекает запрошенный документ из своей файловой системы и возвращает ответ HTTP, содержащий документ и код состояния ответа HTTP «200 OK» (указывающий на успех). Сервер может вернуть другой код состояния, например "404 Not Found", если файл отсутствует на сервере, или "301 Moved Permanently", если файл существует, но был перенаправлен в другое место.

Понимание того, как работают статические сайты, тем не менее полезно при изучении серверного программирования, поскольку динамические сайты обрабатывают запросы на статические файлы (CSS, JavaScript, статические изображения и т. д.) точно так же.

Динамические сайты

Использование базы данных позволяет эффективно хранить информацию о продуктах в легко расширяемом, модифицируемом и доступном для поиска виде.

Использование шаблонов HTML упрощает изменение структуры HTML, поскольку это нужно делать только в одном месте, в одном шаблоне, а не на тысячах статических страниц.

Структура динамического запроса

В этом разделе представлен пошаговый обзор «динамического» цикла HTTP-запросов и ответов, основанный на том, что мы рассмотрели в предыдущей статье, с более подробным описанием.Чтобы «сохранить реальность», мы будем использовать контекст веб-сайта менеджера спортивной команды, где тренер может выбрать название своей команды и размер команды в HTML-форме и получить предложенный «лучший состав» для своей следующей игры.

После того, как тренер отправит форму с названием команды и количеством игроков, последовательность операций следующая:

Веб-браузер создает HTTP-запрос GET на сервер, используя базовый URL-адрес ресурса ( /best ) и кодируя номер команды и игрока либо как параметры URL-адреса (например, /best?team=my_team_name&show=11), либо как его часть. шаблона URL (например, /best/my_team_name/11/ ). Запрос GET используется, поскольку запрос только извлекает данные (не изменяет данные).
Веб-сервер определяет, что запрос является «динамическим», и перенаправляет его в веб-приложение для обработки (веб-сервер определяет, как обрабатывать разные URL-адреса на основе шаблона). правила сопоставления, определенные в его конфигурации).
Веб-приложение определяет, что намерение запроса состоит в том, чтобы получить «список лучших команд» на основе URL-адреса ( /best/ ), и находит необходимые название команды и количество игроков из URL. Затем веб-приложение получает необходимую информацию из базы данных (используя дополнительные «внутренние» параметры, чтобы определить, какие игроки являются «лучшими», и, возможно, также получая идентификационные данные тренера, вошедшего в систему, с клиентской стороны). куки).
Веб-приложение динамически создает HTML-страницу, помещая данные (из базы данных) в заполнители внутри шаблона HTML.
Веб-приложение возвращает сгенерированный HTML-код в веб-браузер (через веб-сервер) вместе с кодом состояния HTTP 200 ("успешно"). Если что-то препятствует возврату HTML, веб-приложение вернет другой код, например "404", чтобы указать, что команда не существует.
Затем веб-браузер начнет обрабатывать возвращенный HTML-код, отправляя отдельные запросы для получения любых других файлов CSS или JavaScript, на которые он ссылается (см. шаг 7).
Веб-сервер загружает статические файлы из файловой системы и возвращает их непосредственно в браузер (опять же, правильная обработка файлов основана на правилах конфигурации и сопоставлении шаблонов URL-адресов).

Выполнение другой работы

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

Возврат чего-либо, отличного от HTML

Код веб-сайта на стороне сервера не должен возвращать фрагменты HTML или файлы в ответе. Вместо этого он может динамически создавать и возвращать другие типы файлов (текст, PDF, CSV и т. д.) или даже данные (JSON, XML и т. д.).

Идея возвращать данные в веб-браузер, чтобы он мог динамически обновлять свой собственный контент (AJAX), существует уже довольно давно. В последнее время стали популярными «одностраничные приложения», когда весь веб-сайт написан с помощью одного HTML-файла, который динамически обновляется при необходимости. Веб-сайты, созданные с использованием этого стиля приложений, требуют больших вычислительных затрат от сервера к веб-браузеру и могут привести к тому, что веб-сайты будут вести себя намного больше, чем нативные приложения (высокая скорость отклика и т. д.).

Веб-фреймворки упрощают веб-программирование на стороне сервера

Веб-фреймворки на стороне сервера значительно упрощают написание кода для обработки описанных выше операций.

Одна из наиболее важных операций, которые они выполняют, — предоставление простых механизмов для сопоставления URL-адресов различных ресурсов/страниц с определенными функциями обработчика. Это упрощает хранение кода, связанного с каждым типом ресурса, отдельно. Это также имеет преимущества с точки зрения обслуживания, поскольку вы можете изменить URL-адрес, используемый для доставки определенной функции, в одном месте, без необходимости изменять функцию обработчика.

Например, рассмотрим следующий код Django (Python), который сопоставляет два шаблона URL с двумя функциями представления. Первый шаблон гарантирует, что HTTP-запрос с URL-адресом ресурса /best будет передан функции с именем index() в модуле представлений. Вместо этого запрос с шаблоном " /best/junior " будет передан в функцию просмотра Junior().

Примечание. Первые параметры в функциях url() могут выглядеть немного странно (например, r'^junior/$' ), потому что они используют технику сопоставления с образцом, называемую "регулярными выражениями" (RegEx или RE).На данном этапе вам не нужно знать, как работают регулярные выражения, за исключением того, что они позволяют нам сопоставлять шаблоны в URL-адресе (а не жестко закодированные значения выше) и использовать их в качестве параметров в наших функциях представления. Например, в очень простом регулярном выражении может быть указано «соответствует одной прописной букве, за которой следует от 4 до 7 строчных букв».

Веб-фреймворк также позволяет функции представления легко извлекать информацию из базы данных. Структура наших данных определяется в моделях, которые представляют собой классы Python, определяющие поля, которые должны храниться в базовой базе данных. Если у нас есть модель с именем Team с полем "team_type", мы можем использовать простой синтаксис запроса, чтобы получить все команды определенного типа.

В приведенном ниже примере отображается список всех команд, которые имеют точное (с учетом регистра) значение team_type для "junior". Обратите внимание на формат: имя поля ( team_type ), за которым следует двойное подчеркивание, а затем используемый тип соответствия (в этот случай точный ). Есть много других типов спичек, и мы можем объединить их в гирляндную цепочку. Мы также можем контролировать порядок и количество возвращаемых результатов.

Очевидно, что веб-фреймворки могут помочь вам во многих других задачах. В следующей статье мы обсудим гораздо больше преимуществ и некоторые популярные веб-фреймворки.

Обзор

К этому моменту у вас должно быть хорошее представление об операциях, которые должен выполнять серверный код, и некоторые способы, которыми серверная веб-инфраструктура может упростить эту задачу.

В следующем модуле мы поможем вам выбрать лучший веб-фреймворк для вашего первого сайта.

Клиенты и серверы общаются, обмениваясь отдельными сообщениями (в отличие от потока данных). Сообщения, отправляемые клиентом, обычно веб-браузером, называются запросами, а сообщения, отправляемые сервером в качестве ответа, называются ответами.

Каждый отдельный запрос отправляется на сервер, который обрабатывает его и предоставляет ответ, называемый ответом. Между клиентом и сервером существует множество объектов, которые вместе называются прокси-серверами, которые выполняют различные операции и действуют, например, как шлюзы или кэши.

Клиент: пользовательский агент

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

Браузер всегда инициирует запрос. Он никогда не является сервером (хотя с годами были добавлены некоторые механизмы для имитации сообщений, инициированных сервером).

Чтобы отобразить веб-страницу, браузер отправляет исходный запрос на получение HTML-документа, представляющего страницу. Затем он анализирует этот файл, делая дополнительные запросы, соответствующие сценариям выполнения, информации о макете (CSS) для отображения и подресурсам, содержащимся на странице (обычно изображения и видео). Затем веб-браузер объединяет эти ресурсы, чтобы представить полный документ, веб-страницу. Сценарии, выполняемые браузером, могут извлекать больше ресурсов на более поздних этапах, и браузер соответствующим образом обновляет веб-страницу.

Веб-сервер

На противоположной стороне канала связи находится сервер, который обслуживает документ по запросу клиента. Сервер виртуально выглядит как одна машина; но на самом деле это может быть набор серверов, разделяющих нагрузку (балансировка нагрузки), или сложная часть программного обеспечения, опрашивающая другие компьютеры (например, кеш, сервер БД или серверы электронной коммерции), полностью или частично генерирующая документ по требованию.

Прокси

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

Когда клиент хочет связаться с сервером, конечным сервером или промежуточным прокси, он выполняет следующие шаги:

Запросы

Запросы состоят из следующих элементов:

Ответы

Пример ответа:

Ответы состоят из следующих элементов:

Заключение

Эта страница создана с помощью сети HTML, CSS и Javascript, отправленной вам Codecademy через Интернет. Интернет состоит из множества ресурсов, размещенных на разных серверах. Термин «ресурс» соответствует любому объекту в Интернете, включая файлы HTML, таблицы стилей, изображения, видео и сценарии. Чтобы получить доступ к контенту в Интернете, ваш браузер должен запрашивать у этих серверов необходимые ему ресурсы, а затем отображать эти ресурсы для вас. Этот протокол запросов и ответов позволяет просматривать эту страницу в браузере.

В этой ситуации ваш компьютер, который делает запрос, называется клиентом. Запрашиваемый вами URL-адрес принадлежит серверу.

Давайте рассмотрим пример того, как запросы GET (наиболее распространенный тип запросов) используются, чтобы помочь вашему компьютеру (клиенту) получить доступ к ресурсам в Интернете.

Вторая строка запроса содержит адрес сервера "www.codecademy.com" . Также могут быть дополнительные строки в зависимости от того, какие данные предпочитает отправлять ваш браузер.

Если серверу удается найти запрошенный путь, он может ответить заголовком:

Если сервер не может найти путь, запрошенный клиентом, он ответит заголовком:

Аналогия:

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

Доставщик почты возвращается на легком скоростном поезде, разрывая пути на обратном пути, и сообщает вам, что возникла проблема «404 Not Found». После проверки правописания того, что вы написали, вы понимаете, что ошиблись в названии газеты. Вы исправляете его и сообщаете исправленный заголовок доставщику почты.

На этот раз доставщик почты может забрать его из компании. Теперь вы можете спокойно читать свою газету, пока не решите, что хотите прочитать следующую страницу, после чего вы должны сделать еще один запрос и передать его доставщику почты.

Читайте также: