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

HTTP Сжато: HTTP Web Структура

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Connections
HTTP Succinctly: HTTP State and Security

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

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

Ресурсы Redux

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

  • Рецепт для салата брокколи
  • Результаты поиска для "Chicago pizza"
  • История болезни 123-го пациента

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

Но, есть много вещей, которые вы не можете сделать с URL -адресом. Скорее, есть много вещей, которые URL-адрес не может сделать. Например, URL-адрес не может ограничивать клиента или сервер определенным типом технологии. Все говорят HTTP. Не  имеет значения, является ли ваш клиент C ++, а ваше веб-приложение - в Ruby.

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

URL-адрес не может даже указать представление конкретного ресурса, а ресурс может иметь несколько представлений. Как мы изучили ранее, клиент может запросить конкретное представление, используя заголовки в сообщении HTTP-запроса. Клиент может запрашивать определенный язык или определенный тип контента. Если вы когда-либо работали с веб-приложением, которое допускает согласование контента, вы видите гибкость ресурсов в действии. JavaScript может запрашивать данные 123-го пациента в формате JSON, C # может запрашивать один и тот же ресурс в формате XML, а браузер может запрашивать данные в формате HTML. Они все работают с одним и тем же ресурсом, но используют три разных представления.

Есть еще одна вещь, которую URL-адрес не может сделать - он не может сказать, что пользователь хочет делать с ресурсом. URL-адрес не указывает, хочу ли я получить ресурс или отредактировать ресурс. Задача сообщения HTTP-запроса заключается в описании этого намерения с использованием одного из стандартных методов HTTP. Как мы говорили во второй части этой сессии, существует ограниченное количество стандартных HTTP-методов, включая GET, POST, PUT и DELETE.

Когда вы начинаете думать о ресурсах и URL-адресах, как мы находимся в этой главе, вы начинаете видеть веб-сайт как часть своего приложения и как гибкий архитектурный уровень, на который  вы можете опираться. Для более глубокого понимания этой линии мышления см. знаменитую диссертацию Роя Филдинга под названием «Архитектурные стили и дизайн сетевых архитектурных решений». Эта диссертация - это статья, в которой представлен стиль архитектуры представления репрезентативных состояний (REST) ​​и подробно рассматривается идеи и концепции в этом разделе и следующем. Статья находится в http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.


Видимый протокол-HTTP

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

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

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


Добавить значение

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

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

Аналогично, когда приложение создает ответное сообщение HTTP, сервер имеет возможность взаимодействовать с сообщением на выходе. Опять же, это может быть простая операция регистрации, но также может быть прямой модификацией самого сообщения. Например, сервер может узнать, поддерживает ли клиент gzip-сжатие, поскольку клиент может рекламировать этот факт через заголовок Accept-Encoding в HTTP-запросе. Сжатие позволяет серверу принимать 100-килобайтный ресурс и превращать его в ресурс 25 КБ для более быстрой передачи. Вы можете настроить многие веб-серверы для автоматического использования сжатия для определенных типов контента (обычно это текстовые типы), и это происходит без самого приложения, беспокоясь о сжатии. Сжатие является дополнительным значением, предоставляемым самим программным обеспечением веб-сервера.

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


Прокси-сервера

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

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

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

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

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

Figure 6: Forward and reverse proxies
Прямые и обратные прокси -сервера

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

Некоторые другие популярные службы прокси включают следующее.

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

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

Прокси могут обеспечить дополнительный уровень безопасности, отфильтровывая потенциально опасные HTTP-сообщения. В частности, сообщения, такие как они могут пытаться найти уязвимость межсайтового скриптинга (XSS) или запустить атаку SQL-инъекций.

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

Наконец, стоит отметить, что прокси не должен быть физическим сервером. Fiddler, инструмент, упомянутый в предыдущей главе, является отладчиком HTTP, который позволяет вам захватывать и проверять сообщения HTTP. Fiddler работает, сообщая Windows о пересылке всего исходящего HTTP-трафика на порт 8888 по IP-адресу 127.0.0.1. Этот IP-адрес является адресом loopback, что означает, что трафик просто переходит непосредственно на локальный компьютер, где Fiddler теперь прослушивает порт 8888. Fiddler принимает сообщение HTTP-запроса, регистрирует его, пересылает его в пункт назначения и также захватывает ответ перед отправкой ответа локальному приложению. Вы можете просмотреть настройки прокси-сервера в Internet Explorer (IE), перейдя в меню ToolsInternet Options, щелкнув вкладку Connections  и нажав кнопку LAN Settings. В разделе Proxy Server нажмите кнопку Advanced, чтобы просмотреть сведения о прокси-сервере.

Figure 7: Proxy settings in Internet Explorer
Настройки прокси-сервера в Internet Explorer

Прокси - прекрасный пример того, как HTTP может влиять на архитектуру веб-приложения или веб-сайта. Есть много услуг, которые вы можете накладывать на сеть, не влияя на приложение. Одна услуга, которую мы хотим рассмотреть более подробно, - это кеширование.


Кэширование

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

Первое, что нужно знать, это два типа кешей.

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

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

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

В HTTP 1.1 ответное сообщение с кодом состояния 200 (OK) для HTTP GET-запроса кэшируется по умолчанию (что означает, что доверенные лица и клиенты кэшируют ответ). Приложение может влиять на это значение по умолчанию, используя соответствующие заголовки в ответе HTTP. В HTTP 1.1 этот заголовок является заголовком Cache-Control, хотя вы также можете увидеть заголовок Expires во многих сообщениях. Заголовок Expires все еще находится вокруг и широко поддерживается, несмотря на то, что он устарел в HTTP 1.1. Pragma - еще один пример заголовка, используемого для управления поведением кэширования, но он также действительно подходит только для обратной совместимости. В этой книге я сосредоточусь на Cache-Control.

Ответ HTTP может иметь значение для Cache-Control publicprivate или no-cache. Значение public общедоступных прокси-серверов может кэшировать ответ. Значение private означает, что только браузер может кэшировать ответ. Значение no-cache означает, что никто не должен кэшировать ответ. Существует также значение no-store, то есть сообщение может содержать конфиденциальную информацию и не должно сохраняться, но должно быть удалено из памяти как можно скорее.

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

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

Примечание. В ASP.NET вы можете управлять этими настройками с помощью Response.Cache.

Сервер также может указать значение max-age в Cache-Control. Значение max-age - это количество секунд для кэширования ответа. По истечении этих секунд запрос должен всегда возвращаться на сервер для получения обновленного ответа. Давайте посмотрим на некоторые примеры ответов.

Вот частичный ответ Flickr.com на один из файлов Flickr CSS.

Обратите внимание, что Cache-Control позволяет публичным и частным кэшам кэшировать файл, и они могут поддерживать его на протяжении более 315 миллионов секунд (10 лет). Они также используют заголовок Expires, чтобы указать конкретную дату истечения срока действия. Если клиент соответствует HTTP 1.1 и понимает Cache-Control, он должен использовать значение в max-age вместо Expires. Обратите внимание, что это не означает, что планы Flickr используют один и тот же файл CSS в течение 10 лет. Когда Flickr меняет свой дизайн, он, вероятно, просто использует другой URL для своего обновленного файла CSS.

Ответ также включает заголовок Last-Modified, чтобы указать, когда последнее изменение было изменено (это может быть просто время запроса). Логика кэша может использовать это значение в качестве валидатора или значение, которое клиент может использовать для проверки того, сохраняется ли кэшированное представление. Например, если агент решает, ему необходимо проверить ресурс, он может выполнить следующий запрос.

Заголовок If-Modified-Since сообщает серверу, что клиент нуждается только в полном ответе, если ресурс изменился. Если ресурс не изменился, сервер может ответить сообщением 304 Not Modified.

Сервер сообщает клиенту: Идите дальше и используйте байты, которые вы уже кэшировали.

Другой валидатор, который вы обычно увидите, - это ETag.

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


Где мы?

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

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.