Кэширующий прокси-сервер

Автор работы: Пользователь скрыл имя, 10 Октября 2011 в 19:40, дипломная работа

Описание

Данный вид прокси-серверов так же используется и провайдерами. Как говорилось выше, Интернет состоит из большого количества серверов. Некоторые из них содержат веб-сайты, а некоторые являются лишь транспортными узлами, перенаправляющими трафик от пользователя к веб-сайту и обратно. Провайдеры заинтересованы в уменьшении объема трафика. Для этого они применяют технологию кэширования на своих серверах, чтобы отвечать на часть пользовательских запросов, не пересылая их дальше внутренней сети. Данный метод описан в RFC 2616, позволяющий сообщить прокси-серверам, что содержимое желательно кэшировать (Cache-Control: public).

Содержание

Введение………………….………………………………………………………3

1.ПОСТАНОВКА ЗАДАЧИ……………………………………………………..5

2.ОБЗОР СЕТЕЙ И ПРОКСИ-СЕРВЕРОВ…………………………………….6

2.1. Локальная сеть………………………………………………………..6

2.2. Функции различных прокси-серверов………………………………8

2.3. Сравнение «Кэширующего прокси-сервера» с другими прокси-серверами……………..……………………………………………….…..22

2.3.1. Squid………………………………………………………….22

2.3.2. DeleGate……………………...……………...………………..24

2.3.3. WinGate…………………………………………………........26

2.3.4. UserGate………………………………………………………27

2.3.5. Traffic Inspector……………………………………………....28

3. АРХИТЕКТУРА ПРИЛОЖЕНИЯ…………………………………………....30

3.1. Обоснование выбора языка программирования…………………….30

3.2. Протокол TCP…………………………………………………………31

3.3. Формат заголовка HTTP……………………………………………...35

3.4. Сокеты…………………………………………………………………38

3.5. Разработка структуры приложения………………………………....40

4.СОЗДАНИЕ ПРОГРАММЫ «КЭШИРУЮЩИЙ ПРОКСИ-СЕРВЕР» ...…42

4.1 Библиотеки и компоненты, которые использовались при разработке программы……………..……………………………………………….....42

4.2 Реализация функций программы «Кэширующий прокси-сервер»...47

5. КРАТКАЯ ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ…………………...………...56

Заключение……………………………………………………………………….60

Список литературы…..…………………………………………………………..61

Работа состоит из  2 файла

Диплом-текст.doc

— 873.50 Кб (Скачать документ)

          Аналогично, язык Си предлагает  только простые, последовательные  конструкции управления: проверки, циклы, группирование и подпрограммы, но не  мультипрограммирование,  параллельные операции, синхронизацию или сопрограммы.

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

    1. Протокол TCP

    Transmission Control Protocol (TCP) (протокол управления  передачей) — один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.Выполняет функции протокола транспортного уровня модели OSI.

    

                Рисунок 3.2.1 Структура  заголовка TCP пакета

    TCP — это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета (см. также T/TCP). В отличие от UDP гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.

    Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

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

    В отличие от традиционной альтернативы — UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP соединение можно разделить на 3 стадии:

  • Установка соединения

Процесс начала сеанса TCP называется «тройным рукопожатием».

     1. Клиент, который намеревается установить  соединение, посылает серверу сегмент  с номером последовательности  и флагом SYN.

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

     В случае успеха сервер посылает клиенту  сегмент с номером последовательности и флагами SYN и ACK, и переходит в  состояние SYN-RECEIVED.

     В случае неудачи сервер посылает клиенту  сегмент с флагом RST.

     2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

     Если  он одновременно получает и флаг ACK (что обычно и происходит), то он переходит  в состояние ESTABLISHED.

     Если  клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.

     Если  клиент не получает ответа в течение 10 секунд, то он повторяет процесс  соединения заново.

     3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние  ESTABLISHED.

     В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

  • Передача данных

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

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

В некоторых  случаях передающее приложение может  явно затребовать протолкнуть данные до некоторой последовательности принимающему приложению, не буферизируя их. Для этого используется флаг PSH. Если в полученном сегменте обнаруживается флаг PSH, то реализация TCP отдает все буферизированные на текущий момент данные принимающему приложению. «Проталкивание» используется, например, в интерактивных приложениях. В сетевых терминалах нет смысла ожидать ввода пользователя после того, как он закончил набирать команду. Поэтому последний сегмент, содержащий команду, обязан содержать флаг PSH, чтобы приложение на принимающей стороне смогло начать её выполнение.

  • Завершение соединения

    Завершение  соединения можно рассмотреть в  три этапа:

     - Посылка серверу от клиента флагов FIN и ACK на завершение соединения.

     - Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.

     - После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

    3.3 Формат заголовка HTTP

    Заголовки HTTP (HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару имя-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

    Примеры заголовков:

    Server: Apache/2.2.11 (Win32) PHP/5.3.0

    Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT

    Content-Type: text/plain; charset=windows-1251

    Content-Language: ru

    В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до первого двоеточия, называется именем (name), а что после неё — значением (value).

    Все заголовки в протоколе HTTP разделяются на четыре основных группы:

    General Headers (Основные заголовки) — должны включаться в любое сообщение клиента и сервера.

    Request Headers (Заголовки запроса) — используются только в запросах клиента.

    Response Headers (Заголовки ответа) — только для ответов от сервера.

    Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

    Именно  в таком порядке рекомендуется  посылать заголовки получателю.

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

    Все необходимые для функционирования HTTP заголовки описаны в основных RFC. При этом если не будет хватать существующих, то можно смело вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить Ms-Echo-Request и Ms-Echo-Reply, введённые корпорацией Microsoft для расширения WebDAV.

Общий формат  Название: Значение

    Название  параметра должно состоять минимум  из одного печатного символа (ASCII-коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.

    Значение  может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).

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

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

    Пример  с многострочными значениями и одинаковыми  именами заголовков:

    content-type: text/html;

    charset=windows-1251

    Allow: GET, HEAD

    Content-Length: 356

    ALLOW: GET, OPTIONS

    Content-Length:   1984

    Правильный  компактный вариант преобразования и интерпретации:

    Content-Type: text/html;charset=windows-1251

    Allow: GET,HEAD,OPTIONS

    Content-Length: 1984

    В этом случае не допустимо принимать  значение Content-Length равное 356. При объединении значений Allow чтобы не потерять семантический смысл была добавлена запятая в конец первого поля и убран бессмысленно дублирующийся элемент «GET».

    Язык  разметки HTML позволяет задавать необходимые  значения заголовков HTTP внутри <HEAD> с помощью тега <META>. При этом название заголовка указывается  в атрибуте http-equiv, а значение — в content. Почти всегда выставляется значение заголовка Content-Type с указанием кодировки чтобы избежать проблем с отображением текста браузером. Так же не лишним является указание значения заголовка Content-Language.

     3.4. Сокеты

     BSD-сокеты (разработанные сотрудниками Калифорнийского университета в Беркли) – это программный интерфейс для межпроцессорных коммуникаций (IPC). Именно этот интерфейс чаще всего используется для реализации сетевого взаиможействия между компьютерами. Протоколы Internet Protocol версии 4(IPv4), User Datagram Protocol (UDP), Transmission Control Protocol (TCP) и другие, в совокупности именуемые TCP/IPv4, - это стандарт де-факто для обмена данными между процессами, работающими на разных компьютерах в сети. А для доступа к этим протоколам из программы применяются BSD-сокеты.

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

     Интерфейс BSD-сокетов – это набор функций и типов данных. Впервые он появился в операционной системе BSD UNIX в начале 1980-х годов, а теперь включен почти во все варианты системы UNIX и поддерживается также на платформе Microsoft Windows (Winsock).

     API сокетов широко применяется в программах на языке C для реализации взаимодействия по протоколам TCP и UDP. Существует два основных вида приложений, в котрых используются сокеты: клиент и сервер. Клиентские приложения создают оконечную точку коммуникации и инициируют сеанс связи с удаленным серверным приложением. Напротив, серверное приложение пассивно ожидает запросов от клиента.

Титульный лист.doc

— 30.00 Кб (Открыть документ, Скачать документ)

Информация о работе Кэширующий прокси-сервер