Протокол передачи гипертекста (HTTP)

HTTP/1.1 (или более позднему) клиенту, который обнаруживает закрытие соединения после получения ответа с кодом состояния 100 (Продолжать, Continue), но до получения ответа с другим кодом состояния, следует повторить запрос, но уже не ожидать ответа с кодом состояния 100 (Продолжать, Continue).

 

 

Определения методов.

 

Множество общих для HTTP/1.1 методов приводится ниже. Хотя это множество может быть расширено, нельзя считать, что дополнительные методы имеют одиннаковую семантику, если они являются расширениями разных клиентов и серверов.

Поле заголовка запроса  Host должно сопровождать все HTTP/1.1 запросы.

 Безопасные методы.

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

В частности было принято  соглашение, что методы GET и HEAD никогда не должны иметь иного значения, кроме загрузки (retrieval). Эти методы следует рассматривать как "безопасные". Это позволяет агенту пользователя представлять другие методы, такие как POST, PUT и DELETE, таким образом, чтобы пользователь был проинформирован о том, что он запрашивает выполнение потенциально опасного действия.

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

 

Идемпотентные методы

Методы могут также  обладать свойством "идемпотентности" ("idempotence") в том смысле, что побочные эффекты от N > 0 идентичных запросов такие же, как от одиночного запроса (за исключение ошибок и проблем устаревания). Методы GET, HEAD, PUT и DELETE обладают данным свойством.

 

 

 

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

 

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

Цель кэширования в  HTTP/1.1 состоит в том, чтобы устранить потребность посылки запросов во многих случаях, и устранить потребность посылки полных ответов в других случаях. Кэширование уменьшает число пересылок информации по сети, требуемых для многих действий; мы используем для этой цели механизм "устаревания" ("expiration"). Кэширование снижает требования к пропускной способности сети; мы используем для этой цели механизм "проверки достоверности" ("validation").

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

• Только явным запросом на уровне протокола если ослабление вызывается клиентом или первоначальным сервером
• Только с явным предупреждением конечного пользователя если ослабление вызывается кэшем или клиентом

Таким образом протокол HTTP/1.1 предоставляет следующие важные элементы:

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

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

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

 

Предупреждения.

 

Всякий раз, когда кэш  возвращает ответ, который не является ни непосредственным (first-hand), ни "достаточно свежим" (в смысле условия 2 раздела 13.1.1), он должен присоединить предупреждение об этом, используя заголовок ответа Warning. Это предупреждение позволяет клиентам предпринимать соответствующие действия.

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

Предупреждения кэшируемы  всегда, так как не ослабляют прозрачность ответа. Это означает, что предупреждения могут быть переданы HTTP/1.0 кэшам без опасений; такие кэши просто передадут предупреждение дальше как заголовок объекта в ответе.

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

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

К ответу могут быть присоединены несколько предупреждений (как первоначальным сервером, так и кэшем), включая несколько предупреждений с одиннаковыми кодовыми номерами. Например, сервер может добавлять одно и тоже предупреждение как к английским текстам, так и к баскским.

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

Механизмы управления кэшем (Cache-control Mechanisms).

 

Основные механизмы кэша в HTTP/1.1 (указанные сервером время устаревания (expiration time) и указатель достоверности (validator)) - неявные директивы кэшу. Возможны случаи, в которых сервер или клиент должен обеспечить явные директивы HTTP кэшу. Мы используем для этой цели заголовок Cache-Control.

Заголовок Cache-Control позволяет клиенту или серверу передавать ряд директив как в запросах, так и в ответах. Эти директивы обычно отменяют испоьзуемые по умолчанию кэширующие алгоритмы. В качестве общего правила: если имеется очевидный конфликт между значениями заголовка, то должна применяться наиболее ограничивающая интерпретация (то есть та, которая, наилучшим образом сохранит семантическую прозрачность). Однако в некоторых случаях директивы управления кэшем (Cache-Control) явно указывают ослабление уровня семантической прозрачности (например,  "максимально-просроченный" ("max-stale") или "общий" ("public")).

 

 

 

ПРОКСИ-СЕРВЕР

 

Прокси-сервер (от англ. proxy — «представитель, уполномоченный») — служба в компьютерных сетях, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если прокси имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях. Также прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.

 

Использование

 

Чаще всего прокси-серверы  применяются для следующих целей:

Обеспечение доступа с  компьютеров локальной сети в  Интернет.

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

Сжатие данных: прокси-сервер загружает информацию из Интернета  и передаёт информацию конечному  пользователю в сжатом виде. Такие  прокси-серверы используются в основном с целью экономии внешнего трафика.

Защита локальной сети от внешнего доступа: например, можно  настроить прокси-сервер так, что  локальные компьютеры будут обращаться к внешним ресурсам только через  него, а внешние компьютеры не смогут обращаться к локальным вообще (они  «видят» только прокси-сервер). См. также NAT.

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

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

Многие прокси-серверы  используются для нескольких целей  одновременно. Некоторые прокси-серверы  ограничивают работу несколькими портами: 80 (HTTP), 443 (Шифрованное соединение HTTPS), 20,21 (FTP).

В отличие от шлюза, прокси-сервер чаще всего не пропускает ICMP-трафик (невозможно проверить доступность  машины командами ping и tracert).

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

 

 

 

 

 

Наиболее распространённые прокси-серверы

 

Squid — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. Разработан сообществом как программа с открытым исходным кодом (распространяется в соответствии с GNU GPL). Все запросы выполняет как один неблокируемый процесс ввода/вывода.

Используется в UNIX-like системах и в ОС семейства Windows NT. Имеет возможность взаимодействия с Active Directory Windows Server путём аутентификации через LDAP, что позволяет использовать разграничения доступа к интернет ресурсам пользователей, которые имеют учётные записи на Windows Server, также позволяет организовать «нарезку» интернет трафика для различных пользователей.

 

 

Microsoft Internet Security and Acceleration Server (обычно сокращается до Microsoft ISA Server) — прокси-сервер для защиты сети от атак извне, а также контроля интернет-трафика.

Позволяет организовать защиту локальной сети от вмешательств из сети Интернет и безопасно публиковать  различные виды серверов, дает возможность  распределять доступ пользователей  локальной сети к ресурсам Интернет. Оснащен средствами для анализа  посещаемых ресурсов, учета трафика, а также защиты против атак из сети Интернет. Имеет различные виды аутентификации и авторизации, в том числе  поддерживает аутентификацию Active Directory. Поддерживает как рабочие группы, так и домены Windows NT. Помимо всего имеет множество плагинов для отслеживания исходящего и входящего трафика. На Windows 2008 уже не устанавливается. На замену ISA Server пришёл Forefront.

 

 

3proxy — бесплатный кроссплатформенный прокси сервер. Основными отличительными особенностями являются небольшой размер (несколько сотен килобайт) и переносимость (есть версии для x86 и x64 платформ). Программа не имеет графического интерфейса, её настройка производится путём написания конфигурационного файла. Существует возможность запуска программы как в консольном режиме, так и в фоновом режиме в виде службы или демона. Де́мон (англ. daemon) — в системах класса UNIX — программа, работающая в фоновом режиме без прямого общения с пользователем.

 

 

UserGate — прокси-сервер для операционной системы Microsoft Windows. Основная функция программы — предоставление доступа в Интернет, экономия входящего трафика и ускорение загрузки веб-страниц.

 

 

Kerio WinRoute Firewall (ранее назывался WinRoute Pro) - это программный межсетевой экран, разработанный компанией Kerio Technologies и Tiny Software. Основными функциями программы являются: организация безопасного пользовательского доступа в Интернет, надежная сетевая защита ЛВС, экономия трафика и рабочего времени сотрудников за счет ограничения нецелевого доступа к различным категориям веб-контента.