Разработка простого http proxy сервера с поддержкой аутентификации пользователей и учетом потребленного трафика по группам и пользователям

Простой http proxy с поддержкой аутентификации и учетом потребленного трафика по группам и пользователям.

Содержание

Содержание. 2

Задание. 3

Общие сведения. 4

Разработка сети предприятия. 5

Реализация курсового проекта. 6

Принцип работы.. 6

Структура базы данных. 7

Описание реализации. 8

Известные недостатки. 8

Задание

Общие сведения

Разработка сети предприятия

[x1] 

Реализация курсового проекта

Темой курсового проекта являлась задача разработки простого http proxy сервера с поддержкой аутентификации пользователей. Соответственно только зарегистрированные пользователи будут иметь возможность пользоваться услугами данного сервиса. Дополнительно должен вестись учет потребленного пользователями сетевого трафика и должна быть реализована возможность блокирования пользователей превысивших свой лимит трафика. Кэшировать полученные результаты не требовалось.

Основным источником информации о протоколе http являются RFC-1945 (HTTP/1.0) и RFC-2068 (HTTP/1.1).

Раздел 11 RFC-2068 определяет базовые механизмы аутентификации пользователей в протоколе HTTP/1.1. По сравнению с протоколом HTTP/1.0, в версии 1.1 была добавлена еще одна схема аутентификации, которая более подробно описана вRFC-2069. В текущей версии proxy сервера реализована поддержка только базовой (Basic) схемы аутентификации.

Далее фактически следует материал из 11 раздела RFC.

[x2] 

Принцип работы

На рисунке 1. показана примерная схема работы proxy сервера. Первоначально пользователь посылает запрос proxy серверу получить какой-либо ресурс (например html страницу) с определенного web сервера (1). Proxy сервер посылает HTTP ответ со специальным кодом возврата 401 (необходима аутентификация) и специальным образом сформированным заголовком (WWW-Authenticate поле должно присутствовать в заголовке). Клиентский Internet browser получив ответ с требованием аутентификации должен будет запросить имя пользователя и пароль. После чего посылается запрос с установленными параметрами авторизации (Authorization поле должно быть установлено в заголовке запроса) (3) – клиентский Internet browser эти действия делает самостоятельно. Proxy сервер получив запрос (3) анализирует заголовок, находит поле Authorization, декодирует base64, полученная строка содержит имя пользователя и пароль. Затем proxy сервер проверяет соответствие имени пользователя и пароля. Если идентификация прошла успешно запрашиваем ресурс на Web сервере (4, 5) и возвращаем результат пользователю. Если во время процесса идентификации произошел какой-либо сбой (нет поля Authorization в запросе, неверная комбинация имени пользователя и пароля) proxy сервер снова посылает ответ (1) и процесс повторяется.

Схема работы

Рисунок 1.

Структура базы данных.

Информации о пользователях и о потребленном трафике храниться в базе данных. Структура ее очень проста (блокирование пользователей превысивших предел трафика ы текущей версии не реализовано) и показана на рисунке 2.

Структура базы данных

Рисунок 2

Таблица Users содержит информацию о зарегистрированных пользователях. Поле UserId – это искусственный числовой первичный ключ. UserName – уникальное имя пользователя, которое будет использоваться для аутентификации. Password – пароль для пользователя, который будет использоваться для аутентификации. Пароль в базе храниться в открытом виде.

Таблица Traffic используется для хранения информации о потребленном пользователем трафике. Поле TrafficId – искусственный числовой первичный ключ. UserId – числовой идентификатор пользователя, внешний ключ. FromIp – текстовое поле, содержит IP адрес (или имя) компьютера с которого пользователь пользовался proxy сервером. URL – текстовое поле, URL конкретного ресурса. Value – числовое поле, размер ресурса в байтах.

Описание реализации.

Proxy сервер был написан на языке c++ (в качестве компилятора использовался gcc) для OS Linux RedHat 7.3 (на этой системе проводилось тестирование, но в принципе код должен работать на любой POSIX системе). Для хранения информации о трафике использовалась СУБД PostgreSQL.

Известные недостатки.

В текущей версии взаимодействие с клиентом происходит по протоколу HTTP/1.0. Proxy написан с использованием блокирующих сокетов и для одновременной обработки нескольких клиентских запросов создаются отдельные дочерние процессы. В некоторых случаях это (плюс использование HTTP версии 1.0) очень сильно загружает операционную систему.

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