Разработка приложения HTTP сервера

Основная задача-разработка сервера, работающего по протоколу HTTP, обрабатывающего запросы множества клиентов. После получения запроса, сервер проверяет его корректность и наличие ресурса, после этого отправляет клиенту сообщение содержащее ресурс в случае отсутствия ошибок, иначе отправляет сообщение, содержащее код ошибки.
Защита на отлично 22.06.14 ТГТУ ...

Оглавление
Введение 4
Задачи HTTP сервера 5
Протоколы и стандарты 9
TCP/IP 9
TCP и UDP 9
Установка TCP соединений 10
Порты 10
IP адреса 11
HTTP 11
Структура данных HTTP 12
HTTP методы 14
Ответы сервера 16
Виртуальные хосты 17
Выбор контента на стороне сервера 18
Устойчивые соединения 18
Прокси и кеш 19
Практическая часть 22
Цель курсовой работы 22
Постановка задачи разработки 22
Формализация требований к программному средству 22
Основные требования к HTTP серверу: 22
Выбор инструмента разработки и его обоснование 23
Проектирование системы 24
Список классов 24
Описание функционирования программы 26
Заключение 26
Список использованной литературы 27
Приложение 28
Руководство пользователя 28
Исходный текст программы 29

Протокол передачи Гипертекста (HTTP) - протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Первой версией HTTP, известной как HTTP/0.9, был простой протокол для передачи необработанных данных через Интернет. HTTP/1.0, как определено в RFC 1945 , был улучшением этого протокола, позволяя сообщениям иметь MIME-подобный формат, содержащий метаинформацию о передаваемых данных и имел модифицированную семантику запросов/ответов. Однако, HTTP/1.0 недостаточно хорошо учитывал особенности работы с иерархическими прокси-серверами (hierarchical proxies), кэшированием, постоянными соединениями, и виртуальными хостами (virtual hosts). Кроме того, быстрое увеличение не полностью совместимых приложений, называющих тот протокол, который они использовали "HTTP/1.0", потребовало введения версии протокола, в которой были бы заложены возможности, позволяющие приложениям определять истинные возможности друг друга. Эта спецификация определяет протокол "HTTP/1.1". Этот протокол содержит более строгие требования, чем HTTP/1.0, гарантирующие надежную реализацию возможностей. Практически информационные системы требуют большей функциональности, чем просто загрузку информации, включая поиск, модификацию при помощи внешнего интерфейса, и аннотацию (annotation). HTTP предоставляет открытый набор методов, которые указывают цель запроса. Они основаны на дисциплине ссылки, обеспеченной Универсальным Идентификатором Ресурса (URI), как расположение (URL) или имя (URN), для идентификации ресурса, к которому этот метод применяется. Сообщения передаются в формате, подобном используемому электронной почтой, как определено Многоцелевыми Расширениями Электронной Почты (MIME). HTTP также используется как обобщенный протокол связи между агентами пользователей и прокси-серверами/шлюзами (proxies/gateways) или другими сервисами Интернета, включая такие, как SMTP, NNTP, FTP, Gopher, и WAIS. Таким образом, HTTP закладывает основы многосредного (hypermedia) доступа к ресурсам для разнообразных приложений

Любой запрос или ответ, обладающий телом, использует эти поля.“Referer” используется клиентским приложением для определения родительского документа, использованного для запроса текущего документа. Эти данные могут быть сохранены на сервере для дальнейшего анализа.HTTP методыHTTP методы похожи на команды консольного приложения. Ответ сервера определяется HTTP методом, который использовал клиент в своем запросе.Стандарт HTTP/1.1 определяет следующие методы: GET, POST, OPTIONS, HEAD, TRACE, PUT, DELETE, CONNECT. Наиболее часто используемые методы - это GET и POST.Метод GET используется для получения запрошенной информации без возможности отправки дополнительных данных в теле самого запроса. Ранее (до HTTP 1.0) GET был единственным методом для запроса информации.Метод POST похож на метод GET,но POST имеет тело запроса для передачи дополнительных данных серверу. Обычно информация, передаваемая с помощью POST, используется для генерации динамического контента или для сохранения передаваемых данных для других приложений. Метод POST появился в HTTP 1.0.Для передачи информации серверу методом GET, клиент добавляет ее к URI запроса. Однако это может привести к некоторым проблемам:Длина URI может вызвать ошибку обработки на сервере.Некоторые клиенты могут передавать URI только определенной длины.Большинство клиентов показывают пользователю добавленную к URI информацию.Хотя метод POST является лучшим способом передачи данных на сервер, некоторые приложения используют для этой цели метод GET, особенно для передачи небольших объемов данных или для возможности добавления закладок на URL.Все остальные методы используются гораздо реже и будут рассмотрены более кратко:HEAD. Этот метод запрашивает только заголовки ответа сервера. Он может использоваться, например, когда проверяется существование определенного документа на сервере. Ответ выглядит так же, как если бы Вы запросили его методом GET, но только не содержит тело сообщения.OPTIONS. Используя этот метод, клиент может запросить список методов и опции сервера для определенного ресурса.TRACE. Метод TRACE схож с командой Ping в TCP/IP. Сообщение этого запроса обязательно содержит в заголовке поле “Max-Forwards”. Каждый раз, когда это сообщение проходит через прокси-сервер, значение данного поля уменьшается на единицу. Сервер, который получил это сообщение с нулевым значением, отсылает ответ. Если сообщение получает сервер, которому оно адресовалось, то он отсылает ответ, не обращая внимания на значение поля “Max-Forwards”. Используя последовательность таких запросов, клиент может узнать все прокси-сервера, используемые при передаче запрошенного ресурса.PUT. Используется для передачи серверу файлов. Этот метод схож с командой PUT, используемой в FTP. Использование данного метода несет угрозу безопасности сервера и поэтому почти никогда не используется.DELETE. Этот метод удаляет на сервере файл, заданный в URI. Так как данный метод также является угрозой безопасности, то ни один из популярных HTTP серверов не обрабатывают его. Метод DELETE очень схож с командой DELETE в FTP.CONNECT. Эта команда используется для создания безопасного SSL соединения через прокси-сервер. Прокси-сервер должен открыть безопасное соединение с сервером назначения и передать все данные вне зависимости от их содержания.Ответы сервераКак рассказано выше, каждый ответ сервера всегда содержит строку статуса. Все ответы сервера разделены на 5 различных категорий. Код ответа - это трехзначное число. Каждая категория обладает уникальной первой цифрой кода:1хх Информационные - Например: 100 Продолжение (100 Continue).2хх Успешные - Например: 200 ОК.3хх Перенаправление - Направляет на другой URL.4хх Ошибка клиента - Например: 404 Не найдено (404 Not found) или 403 Не доступен (403 Forbidden).5хх Ошибка сервера - Например: 500 Внутренняя ошибка сервера (500 Internal Server Error).Виртуальные хостыВиртуальные хосты - это концепция, позволяющая нескольким логическим веб-серверам располагаться на одном физическом сервере (даже с одним IP адресом). Вот несколько реализаций этой концепции:Физический сервер связан с множеством IP адресов, и каждый IP адрес используется одним логическим сервером.Физический сервер связан с одним IP адресом, а логические серверы используют разные порты. В URL это выглядит так: http://www.xyz.com:81/.Физический сервер связан с одним IP адресом. Несколько доменных имен связываются с этим IP адресом. Все логические веб-сервера прослушивают один единственный порт. Сервер различает запросы, используя поле HOST, которое является обязательным в HTTP запросах в HTTP версии 1.1.HTTP/1.0 явно не поддерживал виртуальные хосты. Веб-сервер, управляющий множеством доменов, различал запросы по IP адресу назначения или по порту. Так как различные порты редко использовались для виртуальных хостов, то серверу необходим был для каждого домена отдельный IP адрес. Когда Интернет начал стремительно расти, количество свободных IP адресов стало резко сокращаться. Решение, основанное на разных портах, было неудобным и могло вызвать путаницу, если пользователь забудет указать номер порта.В HTTP/1.1 было введено новое поле HOST, которое стало обязательным для каждого HTTP запроса. И сейчас сервер может обслуживать множество доменов по одному IP адресу и порту, различая назначения запроса, используя поле HOST.Выбор контента на стороне сервераУ разных пользователей наилучшим образом отображаются разные версии одного документа. Серверный выбор контента. В этом случае сервер решает, какую версию запрошенного документа следует отправить клиенту. Используя заголовок Accept, клиент может предоставить серверу список поддерживаемых форматов и языков. Проанализировав этот список, сервер попытается выбрать наиболее подходящую версию.Клиентский выбор контента. В предыдущем методе не определено поведение в ситуации, когда ни одна из запрошенных версий не существует на сервере. Так как передача списка всех поддерживаемых форматов в желаемом порядке нереальна, то клиент может использовать заголовок Accept со значением Negotiate. В этом случае сервер вернет список доступных версий документа вместо самого документа. И при следующем запросе клиент может напрямую запросить выбранную версию.Устойчивые соединенияHTTP версии 1.0 ограничивался лишь одним TCP соединением для каждого запроса. Во времена разработки HTTP, HTML документы обычно состояли только из одного файла, поэтому такой протокол был вполне достаточен. С тех пор отдельные веб-страницы выросли до мультимедийных сайтов. И теперь одна страница стала состоять из множества файлов. Теперь страницы содержат: изображения, звуки, анимацию и прочее. Так, например, главная страница популярного новостного сайта сегодня нуждается примерно в 150 различных файлах. А открытие и закрытие TCP соединения для каждого файла создает дополнительную задержку и увеличивает нагрузку на сервер. Поэтому разработчики вскоре добавили в заголовок поле “Connection: keep-alive” для возможности повторного использования TCP соединения, не смотря на то, что он не являлся частью стандарта HTTP.Поэтому в HTTP/1.1 было официально введено понятие устойчивого соединения и поле Connection. Сейчас по умолчанию соединение является устойчивым. Когда один из корреспондентов не желает использовать соединение дальше, он устанавливает значение “Сonnection: close” для уведомления, что соединение будет закрыто после того, как выполнится текущий запрос. Прокси и кешПо статистике известно, что большой процент используемого трафика состоит из небольшого числа HTML документов. Также известно, что большинство из этих документов не меняется со временем. Кеширование - это технология, применяемая для временного сохранения копий запрошенных документов либо на стороне клиентских приложений, либо на прокси-серверах, находящихся между клиентом и сервером.Прокси-сервера. Прокси-сервер - это хост, играющий роль передающего агента для HTTP запроса. Клиент, сконфигурированный на использование прокси-сервера, никогда не запросит документы у веб-сервера напрямую. С каждым запросом он открывает соединение с указанным прокси-сервером и запрашивает у него либо доставить документ. Если прокси-сервер не имеет запрошенного документа, то он отправляет запрос далее. Количество прокси-серверов не ограничено одним на запрос. Следовательно, прокси-сервер может быть сконфигурирован на использование другого прокси-сервера. Технология использования нескольких прокси-серверов называется ‘каскадом серверов’. Прокси-сервера используются по двум причинам:Клиенты могут быть не в состоянии соединиться с веб-сервером напрямую. Часто прокси-сервера играют роль посреднического узла между приватной сетью и общедоступной сетью по соображениям безопасности. Клиент в приватной сети не имеет доступа к общедоступной сети, но он может запросить прокси-сервер перенаправить запросы в общедоступную сеть.Кеширующие прокси-сервера часто используются из-за соображений сохранения производительности и повышения пропускной способности сети. Документ, часто запрашиваемый несколькими узлами, запрашивается только один раз с сервера. Прокси-сервер может сохранить копию для ответа на следующие запросы на этот же документ без соединения с сервером.Управление кешем. Хотя кеширование, безусловно, является хорошей технологией, она имеет свои проблемы. При кешировании документа необходимо определить, как долго этот документ будет пригодным для последующих запросов. Также некоторая информация является закрытой и не может кешироваться вовсе. Поэтому управление кешем является комплексной задачей, которая поддерживается протоколом HTTP с помощью различных полей заголовков. Наиболее важные из них:If-modified-Since. Клиент может запросить документы по условию. Если клиент или прокси имеют копию документа, они могут запросить сервер прислать документ только в том случае, если он был изменен после указанной даты. Сервер возвращает документ, если он был изменен, или возвращает “304 Not Modified”, если изменений не было.Expires. Используя это поле, сервер может назначать передаваемому документу время жизни. Клиент или прокси, способные кешировать и обрабатывать это поле, запросят заново этот документ только тогда, когда пройдет время, указанное в этом поле.Last-Modified. Если сервер не может добавить время жизни документа, то клиенты или прокси могут использовать алгоритм, основанный на дате Last-Modified, полученной вместе с документом. HTTP/1.1 не указывает конкретных действий для обработки этой возможности. Клиенты и прокси могут быть сконфигурированы для использования этого поля на свое усмотрение.Дополнительно HTTP/1.1 включает несколько полей заголовка для расширенного управления кешем. Серверы и клиенты могут запрашивать запрещенные для кеширования документы. Также серверы могут явно разрешать кеширование, а клиенты даже могут запрашивать документ у прокси-сервера, только в том случае, если это кешированная копия документа. Клиенты также могут информировать кеширующие прокси-сервера о том, что они готовы принять истекшие копии запрашиваемого документа.Практическая частьЦель курсовой работыОсновная цель курсовой работы-разработка приложения –HTTP сервера.Постановка задачи разработкиРисунок 2.1 Потоки данныхОсновная задача-разработка сервера, работающего по протоколу HTTP, обрабатывающего запросы множества клиентов. После получения запроса, сервер проверяет его корректность и наличие ресурса, после этого отправляет клиенту сообщение содержащее ресурс в случае отсутствия ошибок, иначе отправляет сообщение, содержащее код ошибки Формализация требований к программному средствуОсновные требования к HTTP серверу:Поддержка метода GETПередача правильного типа контентаПоддержка множественных запросов(многопоточность)Возможность настройки директории расположения контента и порта сервераПравильная обработка неподдерживаемых и ошибочных запросовВыбор инструмента разработки и его обоснованиеВ качестве языка программирования был выбран язык Java-платформа Java SE. Java-платформа, зарекомендовавшая себя в качестве платформы для разработки сетевых приложений. Java Platform, Standard Edition, сокращенно Java SE (ранее Java 2 Standard Edition или J2SE) — стандартная версия платформы Java 2, предназначенная для создания и исполнения апплетов и приложений, рассчитанных на индивидуальное пользование или на использование в масштабах малого предприятия. Не включает в себя многие возможности, предоставляемые более мощной и расширенной платформой Java 2 Enterprise Edition (J2EE), рассчитанной на создание коммерческих приложений масштаба крупных и средних предприятий. Среда разработки-NetBeans, поставляемая в одном пакете дистрибутива с платформой Java. NetBeans IDE — свободная интегрированная среда разработки приложений (IDE) на языках программирования Java, JavaFX, Ruby, Python, PHP, JavaScript, C++, Ада и ряде других. Для разработки программ в среде NetBeans и для успешной инсталляции и работы самой среды NetBeans должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии. Среда разработки NetBeans по умолчанию поддерживала разработку для платформ J2SE и J2EE. Начиная с версии 6.0 Netbeans поддерживает разработку для мобильных платформ J2ME, C++ (только g++), PHP и Ruby без установки дополнительных компонентов.Проектирование системы Рисунок 2.2 Алгоритм работы HTTP-сервераСписок классовserver.Response.HeaderКласс, формирующий заголовок ответа сервераserver.OptionsКласс чтения опций сервера из файлаserver.ParseHeaderКласс обработки заголовка запросаserver.ResponseКласс, формирующий ответ на запрос-заголовок и тело ответа, а так же посылает их клиентуserver.ServerAppКласс приложения, в котором располагается функция main и создается экземпляр класса WebServerserver.WebServerДля каждого запроса создает поток, который обрабатывает данный запросТаблица 2.1 Список классов и краткое описаниеРисунок 2.3 Граф связей классовОписание функционирования программыПеред запуском HTTP-сервера, пользователь должен задать настройки:Расположение контента Имя хоста Порт сервераИмя заглавной страницыПосле настройки пользователь может запустить сервер при помощи командной строкиПри помощи браузера можно зайти на соответствующий хост и просмотреть содержимое сайта. ЗаключениеВ результате выполнения курсовой работы был разработан простейший HTTP-сервер, обладающийвсем необходимым функционалом, удовлетворяющим стандарту HTTP 0.9 . В процессе тестирования серьезных ошибок выявлено не было. Применение данного сервера в коммерческих целях неоправданно, т.к. он обладает малым функционалом, не поддерживает современные стандарты и не может обрабатывать большое количество запросов одновременно. С другой стороны, HTTP-сервер имеет преимущество-кроссплатформенность, и может использоваться на любых платформах. Список использованной литературыШилдт Г. Java 2. Наиболее полное руководство. М. BVH 2007г.http://www.javaportal.ru/java/articles/java_http_web/article04.htmlhttp://ru.wikipedia.org/wiki/HTTPhttp://www.lib.ru/WEBMASTER/rfc2068/http://apachedev.ru/2006/03/12/the-apache-modeling-project-glava-2-chast-1/http://www.eventhelix.com/RealtimeMantra/Networking/http_sequence_diagram.pdfПриложение Руководство пользователяНастройка параметров HTTP-сервера:Файл настроек сервера располагается в директории сервераПример файла настроек:path=C:/WebServer/host/index=index.htmport=80host=notebookЗапуск сервера: Запуск осуществляется из командной строкиПросмотр заголовков запроса и ответа в стандартном выводе сервераОшибки сервера:404 Not Found (Не найдено)Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.501 Not Implemented (Не реализовано)Сервер не поддерживает возможностей, необходимых для обработки запроса.400 Bad Request (Плохой запрос)Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.Исходный текст программыServerApp.java/* * ServerApp.java */package server;import java.util.logging.Level;import java.util.logging.Logger;import org.jdesktop.application.Application;/** * The main class of the application. */public class ServerApp extends Application { private WebServer SRV; @Override protected void startup() { try { SRV=new WebServer(); SRV.start(); } catch (Exception ex) { Logger.getLogger(ServerApp.class.getName()).log(Level.SEVERE, null, ex); } } /** * A convenient static getter for the application instance. * @return the instance of ServerApp */ public static ServerApp getApplication() { return Application.getInstance(ServerApp.class); } /** * Main method launching the application. */ public static void main(String[] args) { launch(ServerApp.class, args); }}WebServer.javapackage server;import java.io.*;import java.net.*;//----------------------------------------------------------/** * * @author noW */public class WebServer implements Runnable { private int port=80; private Thread thrd=null; private ServerSocket s; Options opt; Response res; String host; public WebServer()throws Exception{ opt=new Options(); port=opt.GetPort(); host=opt.GetHost(); System.out.println(host); } public void SetPort(int port){ this.port=port; } public void run(){ try { s = new ServerSocket(this.port, 0, InetAddress.getByName(host)); System.out.