Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Tools & Tips
Code

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

by
Difficulty:IntermediateLength:LongLanguages:

Russian (Pусский) translation by Nadia Gonzales (you can also view the original English article)

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


Соединения HTTP

Между клиентом и сервером должно быть установлено соединение до того, как они смогут общаться друг с другом; HTTP использует надежный протокол транспортного уровня, TCP (* Transmission Control Protocol – протокол управления передачей; широко используемый в Internet протокол транспортного уровня из набора TCP/IP . Гарантирует доставку передаваемых пакетов данных в нужной последовательности, но трафик при этом может быть весьма неравномерен, так как пакеты испытывают всевозможные задержки. Здесь и далее прим. пер.), для реализации этого соединения. По умолчанию в сети для передачи данных используется TCP-порт 80. Последовательность данных, передаваемых по TCP-соединению, разбита на IP-пакеты (* порция информации, передаваемой через интернет; наряду с данными содержит адреса источника и получателя, а также поля, определяющие длину дейтаграммы, контрольную сумму заголовка и флаги, говорящие о фрагментации дейтаграммы); благодаря этому протоколу пакеты всегда прибывают в верном порядке. HTTP – протокол прикладного уровня на основе TCP, который, в свою очередь, работает на базе IP (*  протокол сетевого уровня (часть набора протоколов TCP/IP ), отвечающий за передачу и маршрутизацию сообщений между узлами Internet. Описан в RFC 791. Определяет правила, по которым данные разбиваются на пакеты, передающиеся между оконечными системами и маршрутизаторами).

HTTPS – это защищенная версия HTTP, согласно которой между HTTP и TCP добавляется дополнительный слой – TLS или SSL (Transport Layer Security (* протокол защиты (безопасности) транспортного уровня) или Secure Sockets Layer (* протокол безопасных соединений; протокол защищенных сокетов – спецификация протокола для передачи через Internet зашифрованных, аутентифицированных сообщений (например, электронных транзакций), разработанная в 1995 г. фирмой Netscape Communications. Стандарт де-факто. Версия SSL 2.0 принята в качестве стандарта IETF и применяется для проверки полномочий и шифрования данных на транспортном уровне при работе Web-браузера c Web-сервером. Для доступа к страницам, защищённым протоколом SSL, в URL вместо обычного префикса http, как правило, применяется префикс https (порт 443), указывающий на то, что будет использоваться SSL-соединение. Так как операции шифрования/дешифрования требуют много вычислительных ресурсов, то, чтобы снизить нагрузку на Web-серверы, используют аппаратные SSL-ускорители. Последняя версия протокола - SSL 3.0 получила широкое распространение) соответственно). По умолчанию HTTPS использует порт 433, и мы рассмотрим его позже в этой части.

HTTP and HTTPS layers

Соединение HTTP идентифицируется на основании <source-IP, source-port> и <destination-IP, destination-port> (* сокет (сочетание IP-адреса и номера порта (имеет и другие значения)) – интерфейс между прикладным и транспортным уровнем хоста, т. е. API между приложением и компьютерной сетью). На стороне клиента приложение, использующее HTTP, распознается при помощи набора <IP, port>. Установление соединения между двумя оконечными узлами локальной сети (ЛС) – процесс, состоящий из нескольких этапов:

Connection Delays
  • установление соответствия имени хоста IP-адресу при помощи DNS (*  Domain Name Server – сервер, осуществляющий преобразование имен доменов в IP-адреса; Domain Name System – Интернет-служба, представляющая собой распределённую по всему земному шару базу данных для иерархической системы имён сетей и компьютеров, подключённых к Сети, а также способ (протокол прикладного уровня) преобразования строчных адресов серверов Интернета в числовые IP-адреса. Определена в RFC 1034 и 1035 и др. Протокол DNS работает поверх протокола UDP и ему назначен порт с номером 53. DNS также часто используется для распределения нагрузки между дублирующими серверами ("зеркалами") популярных сайтов и почтовых серверов).
  • установление соединения с сервером
  • отправление запроса
  • ожидание ответа
  • закрытие соединения

Сервер обязуется всегда присылать верные заголовки и ответы.

Согласно HTTP/1.0 все соединения закрывались после осуществления единственной транзакции (* логическая единица работы (logical unit of work , LUW ), состоящая из запроса (например, к базе данных) и получения результатов его обработки. Механизм транзакций обеспечивает одновременный доступ к многих пользователей; в более широком смысле под транзакцией понимается одновременное и взаимозависимое взаимодействие между множеством компонент системы) (* то есть реализовывалось кратковременное соединение – передача в течение одного TCP-соединения только одного объекта). Таким образом, если клиент хотел запросить три отдельных изображения с сервера, то он устанавливал три отдельных соединения с удаленным хостом. Как вы можете судить по вышеприведенной схеме, из-за этого может возникнуть множество сетевых задержек  (* время, необходимое для пересылки данных между двумя компьютерами сети), в следствие чего пострадает качество опыта взаимодействия пользователя.

Для уменьшения числа сетевых задержек в HTTP/1.1 были введены постоянные соединения – долгосрочные соединения, которые остаются открытыми, пока клиент их не закроет. В HTTP/1.1 по умолчанию применяются постоянные соединения, и при установлении соединения для выполнения одной транзакции клиент должен добавить заголовок запроса Connection: close. Это сообщает серверу, что соединение необходимо закрыть после отправления ответа.

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

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

Реализация соединения на стороне сервера

Сервер обычно слушает соединения и принимает запросы на обслуживание. Выполняемые им действия включают:

  • открытие канала для начала прослушивания 80 порта (или какого-нибудь другого)
  • получение и разбор сообщения
  • формирование ответа
  • добавление заголовков ответа
  • отправление ответа клиенту
  • закрытие соединения при наличии заголовка запроса Connection: close

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


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

HTTP – протокол прикладного уровня на основе TCP, который, в свою очередь, работает на базе IP.

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

Для ее сбора имеется несколько способов, и большинство веб-сайтов используют их комбинацию:

  • Заголовки запроса: From, Referer, User-Agent - мы рассматривали их в Части  1.
  • IP-адрес клиента.
  • Fat Urls (* обогащенная ссылка; также называют  "extended link" – расширенная ссылка или "multi-tailed link" – ссылка со многими хвостами) – состояние (* информации о сессии текущего пользователя) сохраняется за счет изменения URL-адресов (* динамически сервером) и перенаправления его по мере просматривания сайта по иному адресу (* иному, чем был задан изначально, например: сервер присылает HTML-документ с  ...  <a href="/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-1145265-8016838">All Gifts</a><br> ... , где к каждому  URL-адресу добавляется суффикс «002-1145265-8016838»); по сути состояние аккумулируется при каждом переходе пользователя по URL-адресу.
  • Куки (* поддерживаемая протоколом НТТР текстовая запись размером до 4 Кбайт с данными о пользователе, возвращаемая Web-сервером при регистрации пользователя и хранящаяся на его ПК) – наиболее популярный и ненавязчивый подход (* из перечисленных здесь, поскольку только при нем от пользователя необходимо получить предварительное согласие на использование куки-файлов (предоставление персональной информации по согласию пользователя); однако сами куки можно поделить на категории в зависимости от их навязчивости (степень посягательства  на персональную информацию): от нулевой до высокой степени (подробнее тут https://www.cookielaw.org/blog/2012/2/16/how-intrusive-are-your-cookies.aspx)).

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

Сервер может также ограничить использование куки только для определенного домена или пути, а также он может сделать их постоянными (* пересылаемый в сети объект, время жизни которого не ограничено временем выполнения создавшей и использующих его программ) при помощи задания значения для заголовка Expires. Куки автоматически отправляются браузером при каждом запросе к серверу; также браузер гарантирует, что в запрос добавляются только специфические для определенного домена или пути куки. Для отправления этих куки на сервер используется заголовок запроса Cookie: name=value [; name2=value2].

Лучший способ идентификации пользователя – обязать его регистрироваться (sign up) или входить в приложение (log in), однако для реализации этой возможности необходимо приложить усилия как разработчику, так и пользователю.

Технологии наподобие OAuth (* Open Authorization – открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль) упрощают реализацию данной возможности, однако по-прежнему необходимо согласие пользователя. Важную роль при этом играет аутентификация (* служебная функция системы контроля доступа, обеспечивающая сопоставление введенных пользователем пароля и логина с хранимой учётной записью; в системе компьютерной безопасности - процесс, позволяющий установить, что пользователь или компьютер (сервер), пытающийся получить интерактивный доступ к определённой категории информации, компьютерной системе, вычислительной сети или электронной почте, действительно тот, за кого себя выдаёт. аутентификация отличается от авторизации (authorization) тем, что не управляет предоставлением или отказом в праве доступа к ресурсам. Процедура доказательства пользователем того, что он есть тот, за кого себя выдает, в частности, того, что именно ему принадлежит введенный им идентификатор); также это, вероятно, – единственный способ идентифицировать и опознать пользователя.

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

В самом протоколе HTTP реализована поддержка элементарной формы аутентификации – Basic Authentication, а также более защищенной – Digest Authentication.

При Basic Authentication сервер поначалу отклоняет запрос клиента и отправляет ответ с заголовком ответа WWW-Authenticate и кодом состояния 401 Unauthorized (* и соответствующей фразой). Получив этот заголовок, браузер отображает диалог для входа на сайт, запрашивая пароль и имя пользователя. Эта информация отсылается в закодированном при помощи кода Base-64 (* способ кодировки сообщений электронной почты, совместимый c MIME , стандартизован в RFC 2045.   Каждый символ в base64 заключает в себе ровно 6 битов данных. Таким образом, три байта (8 бит) могут быть представлены при помощи 4-х символов (по 6 бит) в base64) формате в заголовке запроса Authentication. После этого сервер проверить правильность данных в запросе и предоставить доступ в случае корректности данных. Некоторые серверы также могут присылать заголовок Authentication-Info с дополнительной информацией об аутентификации.

Authentication Challenge/Response

Логически вытекающий из Basic-Authentication способ аутентификации – Proxy Authentication. В этом случае запрос на аутентификацию отправляется не сервером, а промежуточным прокси. Прокси-сервер отсылает заголовок Proxy-Authenticate с кодом состояния 407 Unauthorized (* и соответствующей фразой). В ответ клиент должен отослать пароль и имя пользователя в заголовке запроса Proxy-Authorization.

Digest Authentication подобна Basic, и при ней используется та же самая техника «рукопожатия» при помощи заголовков WWW-Authenticate и Authorization, однако в этом случае используется более надежная хеш-функция для шифрования имени пользователя и пароля (обычно при помощи функций шифрования MD5 или KD). Хотя считается, что Digest Authentication намного надежнее, чем Basic, на веб-сайтах обычно используется Basic Authentication из-за своей простоты. Для повышения безопасности в паре с Basic Auth используется SSL.

HTTPS

HTTPS AddressBar

За счет протокола HTTPS (* HTTP Secure – протокол защищенной передачи гипертекстов;   расширение протокола НТТР; совместим с НТТР, но использует порт 443 протокола TCP) в сети реализуются защищенные соединения. Простейший способ удостовериться, что вы используете HTTPS – проверить адресную строку браузера. Защищенная передача в HTTPS обеспечивается за счет добавления слоя шифрования/дешифрования между HTTP и TCP. Им является SSL или его усовершенствованная версия – TLS.

В SSL используется надежная форма шифрования при помощи RSA (* RSA-кодирование (шифрование) – схема (алгоритм) асимметричного шифрования (asymmetric cipher) с открытыми ключами. Названа по фамилиям авторов: Rivest - Shamir - Adleman (Рон Райвест, Ади Шамир и Леонард Адлеман), разработавших эту схему шифрования в 1978 г.) и public-key cryptography (*  криптографии с открытым ключом; разработана Уайтфильдом Диффи (Whitfield Diffi) и Мартином Хеллманом в 1976 г. Использует асимметричное шифрование, т. е. раздельные ключи для шифрования и дешифрования - пару ключей, причём каждая пара обладает следующими свойствами: что-либо зашифрованное одним из них (ключ для шифрования называется открытым и доступен всем) может быть расшифровано с помощью другого (этот ключ называется закрытым, или секретным, ключом); имея только открытый ключ, невозможно получить другой, секретный). Поскольку очень важно, чтобы транзакции в сети были  безопасными, повсеместно используемая основанная на стандартах PKI (* Public-Key Infrastructure – инфраструктура (системы шифрования) с открытыми ключами; часть стандарта X.509 (стандарт на шифрование данных при их передаче в сетях); система, позволяющая удостоверится, что открытый ключ принадлежит именно тому лицу, за которое оно себя выдаёт. Использует для этого центры сертификации (Certificate Authority, CA)) разрабатывалась довольно тщательно.

Существующим клиентам/серверам нет необходимости менять свой способ обработки сообщений, поскольку основная часть тяжелой работы выполняется на уровне SSL. Поэтому вы можете разрабатывать ваше веб-приложение при помощи Basic Authentication и автоматически воспользоваться преимуществами SSL путем переключения на протокол https://. Однако для того чтобы ваше веб-приложение работало по HTTPS, на вашей сервере должен иметься действительный цифровой сертификат (* небольшой файл, зашифрованное содержимое которого уникальным образом идентифицирует пользователя или сайт, показывая, что вы можете доверять определённой информации, и обеспечивая безопасную конфиденциальную связь в Интернете. Он связывает имя объекта, принимающего участие в секретной транзакции (адрес электронной почты или сайта), с открытым ключом. В шифровании с открытыми ключами существует проблема пересылки таких ключей через Интернет. В основе цифровых сертификатов лежит идея цифровой подписи).

Сертификат

Так же само, как для подтверждения вашей личности вам необходимо удостоверение личности, для идентификации веб-сервера используется цифровой сертификат (* небольшой файл, зашифрованное содержимое которого уникальным образом идентифицирует пользователя или сайт, показывая, что вы можете доверять определённой информации, и обеспечивая безопасную конфиденциальную связь в Интернете. Он связывает имя объекта, принимающего участие в секретной транзакции (адрес электронной почты или сайта), с открытым ключом. В шифровании с открытыми ключами существует проблема пересылки таких ключей через Интернет. В основе цифровых сертификатов лежит идея цифровой подписи). Сертификаты выпускаются CA (* Certificate Authority – центр сертификации) и ручаются за достоверность вашей личности в сети. CA – это стражи  PKI. Наиболее распространенный  стандарт сертификатов – X.509 v3; в таком сертификате содержится следующая информация:

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

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

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


Кэширование

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

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

  • Приватный: внутри браузера; здесь кэшируются пароли, имена пользователей, URL-адреса, история посещений и веб-контент. Этот тип кэш-памяти обычно небольшого объема и предназначен для одного пользователя.
  • Публичный: располагаются на прокси для кэширования между сервером и клиентом. Объем памяти этого типа кэш-памяти намного больше, поскольку здесь обслуживается множество пользователей. Согласно устоявшейся практике (* общепринятая практика, но не являющаяся правилом) между клиентом и первоначальным сервером следует размещать множество прокси для кэширования. Благодаря этому облегчается обслуживание контента, к которому часто обращаются, и в то же время сохраняется возможность получить контент, который редко запрашивают.
Cache Topology

Поддерживание кэш-памяти

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

  • Получение сообщения запроса.
  • Разбор URL-адреса и заголовков.
  • Поиск локальной копии; в случае отсутствия получить ресурс и сохранить локально.
  • Проверка актуальности контента в кэш-памяти; выполнить запрос для обновления контента только при необходимости.
  • Формирование ответа из тела сообщения из кэша и обновленных заголовков.
  • Отправление ответа клиенту.
  • Фиксирование события в журнале регистрации событий (Необязательно)

Естественно, что сервер обязуется всегда присылать верные заголовки и ответы. Если документ не менялся, то сервер должен прислать ответ с кодом состояния (* и соответствующей фразой) 304 Not Modified. Если срок действительности копии из кэша истек, то сервер должен сгенерировать новый ответ с обновленными заголовками ответа и 200 OK. В случае, если ресурс удален, то должен быть прислан ответ с 404 Not Found. Благодаря этим ответам облегчается настраивание кэша и гарантируется, что устаревший контент не сохраняется слишком долго.

Заголовки для управления кэш-памятью

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

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

Использование срока действительности документа

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

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

Перепроверка ресурса на сервере

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

Комбинация перепроверки ресурса на сервере и использования срока действительности документа – очень эффективный механизм (* повышения качества использования сети); благодаря ему становится возможным поддержание в распределенных системах актуальности копий ресурсов на основе даты истечения срока.

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

Этап перепроверки может быть выполнен при помощи двух видов заголовков запроса: If-Modified-Since и If-None-Match. Первый используется для осуществления проверки на основе даты, тогда как во втором используется Entity-Tag  (ETag) – хэш-значение контента. В этих заголовках используются значения даты или ETag, полученные в предыдущем ответе сервера. В случае с заголовком If-Modified-Since используется заголовок ответа Last-Modified; для If-None-MatchETag.

Контроль возможности кэширования

Срок действительности документа должен определяться сервером, отправляющим документ. В случае новостного веб-сайта срок главной страницы  должен истекать по завершении одного дня (или иногда даже каждый час!). 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 – это очень интересная тема, и имеются очень сложные алгоритмы для управления контентом в кэше. За детальным рассмотрением данной темы обращайтесь к Caching section спецификации HTTP.


Резюме

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

Ссылки

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.