HTTP: протокол, который каждый разработчик должен знать (часть 2)

В предыдущей статье нами были рассмотрены основы HTTP: схемы URL, коды состояния и заголовки запросов/ответов. Теперь мы рассмотрим некоторые тонкости HTTP, такие как обработка соединений, аутентификация и кэширование. Эти темы слишком обширны, но мы обсудим наиболее важные части.

HTTP-СОЕДИНЕНИЕ

Соединение между клиентом и сервером устанавливается обязательно до того, как они смогут “общаться” друг с другом, при этом используется самый надежный протокол-TCP. По умолчанию, TCP использует 80-ый порт. Поток разбивается на пакеты IP,что гарантирует получение пакетов в правильном порядке без потерь. HTTP-протокол прикладного уровня TCP, основанного на IP. HTTPS - защищенная версия HTTP, куда вставлены дополнительные уровни между HTTP и TCP, называемые TLS и SSL (Transport Layer Security и Secure Sockets Layer, соответственно). По умолчанию, HTTPS использует 443-ий TCP-порт, и в данной статье будет рассмотрен именно HTTPS- протокол.

Подключение HTTP идентифицируется как <исходный IP, исходный порт> и <IP приемника, порт приемника>. На клиентском уровне протокол представлен кортежем: <IP, порт>. Установка соединения между двумя конечными точками - процесс многоступенчатый. Он включает в себя следующие шаги:

• расчет IP адреса по имени хоста DNS,
• установление соединения с сервером,
• отправка запроса,
• ожидание ответа,
• закрытие соединения.

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

Чтобы избавиться от этих задержек, в HTTP/1.1 были введены постоянные соединения - долгоживущие соединения, которые остаются открытыми, пока клиент не закроет их. Эти соединения используются по умолчанию, а чтобы произвести транзакцию клиент должен установить соединение: “Connection: close” в заголовке запроса. Это значит, что сервер должен прервать соединение сразу после того, как оправит ответ клиенту.

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

Параллельные соединения в сочетании с постоянными соединениями - вот ответ сегодняшним технологиям сведения к минимуму задержки в сети. Углубленный анализ подключений HTTP рассмотрен в разделе Подключения (спецификация HTTP)

Обслуживание соединения со стороны сервера

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

• создание сокета для начала прослушивания 80-го (или другого) порта,
• получение запроса и анализ сообщения,
• обработку ответа,
• установку заголовка ответа,
• отправку ответа клиенту,

Естественно, это далеко не полный перечень операций. Для создания наиболее индивидуальных ответов веб-сайты и программы должны “понимать”, кто посылает запросы. За это отвечают процессы идентификации и аутентификации.

Идентификация и аутентификация

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

Существует несколько мер, при помощи которых сервер извлекает эту информацию, и большинство веб-сайтов используют гибридные методы:

• Заголовки запросов: From, Referer, User-Agent – их мы уже рассмотрели в части 1
• Client-IP - IP адрес клиента,
• Fat Urls - Сохранение состояния текущего пользователя, изменив URL и перенаправив на другой URL после каждого клика; каждый клик, по сути, накапливает состояние,
• Cookies - самый популярный и ненавязчивый подход.

Cookies позволяют серверу передавать обязательную информацию для исходящих сообщений с помощью заголовка ответа Set-Cookie. Cookie устанавливается с одной или более парой имя=значение, разделенных точкой с запятой (;), например: Set-Cookie: session-id=12345ABC; username=nettuts.

Сервер также может ограничить Cookie для конкретного домена или его части (domain и path),что делает их стойкими (неизменными) к истекающим значениям (expires). Cookies автоматически отсылаются браузером при каждом запросе к серверу, и браузер гарантирует, что в запросе отправлены только специальные domain- и path- cookies-сы. Заголовок запроса Cookie: name=value [; name2=value2] используется для отправки этих cookies на сервер.

“Лучший способ определить пользователя - попросить зарегистрироваться на сайте, но чтобы это реализовать потребуются усилия как со стороны разработчика, так и со стороны пользователя.”

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

Аутентификация

HTTP действительно поддерживает рудиментарную форму аутентификации, называемой Основной Проверкой Подлинности (Basic Authentication), точно также как и более надежную форму - Краткую Проверку Подлинности (Digest Authentication).

В Основной Проверке Подлинности сервер сразу же отвергает запрос клиента с WWW-Authenticate и кодом состояния 401 - Unauthorized. Увидев этот заголовок, браузер отображает диалоговое окно входа с запросом имени пользователя и пароля. Эта информация отправляется в фотмате BASE64 в заголовке запроса на аутентификацию. Теперь сервер может проверить запрос и разрешить доступ, если учетные данные верны. Некоторые серверы могут даже отправить заголовок Autentification-Info, содержащий дополнительные детали об аутентификации.

Следствием Основной Проверки Подлинности является Проверка Подлинности Прокси. Вместо веб-сервера, задача аутентификации состоит в запрашивании промежуточного прокси-сервера. Прокси-сервер отправляет заголовок Proxy-Authenticate с кодом статуса 407-Unauthorized. В свою очередь, клиенту предлагается посылать мандаты с помощью заголовка запроса Proxy-Authorization.

Краткая Проверка Подлинности похожа на Основную ПП техникой, схожей с WWW-Authenticate и заголовками авторизации, но Краткая ПП использует более надежные хэш-функции для шифрования имени пользователя и пароля (обычно- MD5 или KD дайджест-функций). Хотя Краткая ПП должна быть более безопасной, чем Основная ПП, веб-сайты обычно используют Основную ПП из-за её простоты. Для смягчения проблем безопасности Основные ПП используются в сочетании с SSL (Secure Sockets Layer).

Протокол Secure HTTP

Протокол HTTPS обеспечивает безопасное соединение в Интернете. Самый простой способ узнать, используете ли Вы его: проверить адресную строку браузера. Защищенный компонент HTTPs включает в себя вставленный слой шифрования / дешифрования между HTTP и TCP- Secure Sockets Layer (SSL) или улучшенный протокол Transport Layer Security (TLS).

SSL использует мощный алгоритм шифрования при помощи RSA и криптографии с открытым ключом. Так как безопасные транзакции в Интернете необычайно важны, разработка универсальных стандартов, основанных на Инфраструктуре Открытых Ключей (PKI) ведется уже давно.

Существующие клиенты / серверы не должны изменить способ обработки сообщения, так что большая часть тяжелой работы проходит в слое SSL. Таким образом, вы можете разрабатывать веб-приложения, используя Основные ПП и автоматически пользоваться преимуществами SSL за счет перехода на протокол https://. Однако, чтобы веб-приложение работало на протоколе HTTPS, необходимо иметь рабочий цифровой сертификат, развернутый на сервере.

Сертификаты

Также как человеку нужен паспорт для удостоверения личности, серверу нужен цифровой сертификат для идентификации. Сертификаты (или “certs”) выдаются Центром Сертификации (CA) и поручаются за Вашу личность в Интернете. CA хранят в себе PKI. Наиболее распространенная форма сертификатов- стандарт X.509 v3, который содержит такую информацию:

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

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

Как только сертификат сверен, вступает в силу полная и безопасная передача SSL.

Кэширование HTTP

Бытует мнение, что делать одну и ту же работу дважды является расточительством. Это- главный принцип концепции кэширования HTTP, фундаментальной основы Сетевой Инфраструктуры HTTP. Поскольку большинство операций проводятся в сети, кэш помогает экономить время, стоимость и пропускную способность, а также обеспечить улучшенную работу Интернета. Кэш используется в некоторых сетевых моментах, начиная с браузера до исходного сервера. В зависимости от расположения, кэш может разделяться на:

• Частный - (в самом браузере) кэширует имена пользователей, пароли, URL, историю посещения страниц и веб-контент. Как правило, ориентирован на пользователя.
• Общий - (развернутый) кэширует прокси между сервером и клиентом. Он гораздо обширнее, потому что работает на нескольких пользователей. Обычной практикой является хранение нескольких кэшированных прокси между клиентом и исходным сервером. Это помогает обслуживать наиболее часто используемый контент, и, в то же время, позволяет серверу обращаться к редко используемому содержанию.

Обработка кэша

Независимо от места нахождения кэша, процесс его обслуживания, в принципе, одинаков:

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

Конечно, сервер несет ответственность за то, чтобы и ответ и его заголовок всегда были правильными. Если какой-то документ не изменился, сервер должен ответить 304 Not Modified. Если кэшированная копия документа истекает, должен генерироваться новый ответ с модифицированными заголовками и возвращать код 200-OK. Если ресурс был удален, возвращается код 404- Not Found. Эти ответы помогают настроить кэш и убедиться, что “несвежее” содержание не хранится дольше положенного.

Заголовки управления кэшем

Теперь, когда уже стало понятно,как работает кэш, пора взглянуть на заголовки запросов и ответов, которые позволят кэшировать инфраструктуры. Поддержание контента в свежем и соответствующем современным требованиям виде - одна из основных задач кэша. Чтобы кэшированные копии согласовывались с сервером, HTTP предоставляет некоторые простые механизмы, а именно Истечение Срока Хранения Документов (Document Expiration) и Повторное Подтверждение от Сервера (Server Revalidation).

Истечение Срока Ханения Документов (Document Expiration)

HTTP позволяет исходному серверу прикреплять к документам срок их действия, используя заголовки ответа Cache-Control и Expires. Это помогает клиентам и другим серверам кэша узнавать, как долго документ является актуальным и действительным. Кэш может обслуживать копии до тех пор, пока не истечет срок действия документа. Когда срок действия документа истечет, кэш вместе с сервером должны проверить, появились ли новейшие копии или обновились ли локальные копии документов, соответственно.

Expires- один из старых заголовков ответа HTTP/1.0, который выводит значение, как абсолютную дату. Это полезно только тогда, когда часы на сервере синхронизированы с часами клиента. Он менее полезен, чем новейший заголовок Cache-Control: max-age=<s>, добавленный в версию HTTP/1.1. Здесь max-age - относительный возраст, отсчитываемый в секундах с того времени, когда был создан ответ. Таким образом, если срок хранения документа истекает на следующий день, заголовок Expires будет следующим: Cache-Control: max-age=86400.

Повторное подтверждение от сервера (Server Revalidation)

Как только истекает срок хранения кэшированного документа, кэш вместе с сервером должен перепроверить, был ли документ изменен. Это называется Повторным Подтверждением от Сервера и служит механизмом запросов устаревания документа. Только то,что срок хранения кэшированной копии истек, не означает, что на сервере обновился контент. Повторное Подтверждение - это всего лишь метод проверки, освежен ли кэш. Благодаря истечению срока хранения (пред. ответ сервера) кэш вместе с сервером не обязаны проверять каждый запрос, что позволяет экономить пропускную способность, время и снижает сетевой трафик.

“Сочетание истечения срока хранения документа и повторного подтверждения от сервера является довольно-таки эффективным механизмом, он и позволяет распределенным системам хранить копии данных с датой истечения срока хранения.”

Если известно, что контент часто изменяется, срок хранения может уменьшиться, позволяя системам чаще проводить повторную синхронизацию.

Стадия повторного подтверждения может быть пройдена по одному из двух заголовков запроса: Изменялось-Ли-Ранее ( If-Modified-Since) и Не-Отмечено-Ли (If-None-Match). Первый используется для проверки основных дат, а последний использует Entity-Tags (ETags), хэш содержимого. Эти заголовки используют значения даты или ETag’а, полученные из предыдущего ответа сервера. В случае Изменялось-Ли-Ранее ( If-Modified-Since) используется заголовок ответа Последнее-Измененное (Last-Modified), для Не-Отмечено-Ли (If-None-Match)- заголовок ответа- ETag.

Управление кэшированием

Срок действия документа должен быть определен сервером, сгенерировавшим этот документ. Если это веб-сайт какой-то газеты, срок хранения домашней страницы должен истекать каждый день (а в некоторых случаях и каждый час). HTTP предоставляет Cache-Control и Expires заголовки ответа чтобы установить срок истечения хранения документов. Как указано ранее, Expires основаны на абсолютных датах и не могут быть надежными в управлении кэшем.

Заголовки Cache-Control значительно полезнее и обладают некоторыми различными значениями для ограничения клиентов в кэшировании ответов. Такие как:

• Cache-Control: no-cache: клиент имеет право сохранить документ, однако, при каждом запросе должен получить повторное подтверждение от сервера. Существует заголовок совместимости HTTP/1.0, называемый Pragma: no-cache, который работает по тому же принципу,
• Cache-Control: no-store: клиенту строго запрещается хранить документ,
• Cache-Control: must-revalidate: просить клиента обойтись без расчета на свежесть контента и отправить на сервер запрос о перепроверке. В случае, если сервер недоступен, кэшированные ответы не обслуживаются.
• Cache-Control: max-age: устанавливает относительное время выдоха (в секундах) с момента, когда ответ уже создан.

Следует добавить, что если сервер не отправил ни одного заголовка Cache-Control, клиент может использовать свой собственный эвристический алгоритм установки истечения срока действия и определения “свежести” контента.

Клиентское ограничение “свежести”

Кэширование происходит не только на сервере, иногда оно может быть задано клиентом. Это позволяет клиенту ограничивать то, что он сам готов принять. Это возможно осуществить при помощи Cache-Control, но с другими значениями:

• Cache-Control: min-fresh=<s>: документ должен быть свежим, по крайней мере <s> секунд,
• Cache-Control: max-stale или Cache-Control: max-stale=<s>: документ нельзя обслуживать кэшем, если он был несвеж дольше <s> секунд,
• Cache-Control: max-age=<s>: кэш не может вернуть документ, который находится в нем дольше <s> секунд,
• Cache-Control: no-cache или Pragma: no-cache: клиент не примет кэшированный ресурс, пока он не будет повторно подтвержден.

HTTP кэширование на самом деле очень интересная тема, и существуют очень сложные алгоритмы для управления кэшированным контентом.

Резюме

Наш увлекательный тур по HTTP начался с основания URL-схем, кодов состояния и заголовков запроса/ответа. Опираясь на эти понятия, мы рассмотрели некоторые тонкости HTTP: соединение, идентификация и аутентификация, и кэширование. Надеюсь, тур был увлекательным, и дал достаточно базовых знаний для дальнейшего изучения протокола HTTP!

• Комментарии