Разработка системы на структурном уровне



Скачать 145.25 Kb.
Дата17.11.2018
Размер145.25 Kb.
ТипПротокол

Разработка системы на структурном уровне

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

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

Выбор протокола.

Как было сказано выше удобней для реализации выбрать протокол прикладного уровня. Задачи, которые он должен выполнять, предельно просты:


  • установление соединения;

  • передача данных, конкретнее - файлов;

  • защита от несанкционированного доступа.

Таким образом, из всего многообразия протоколов можно выделить три, наиболее подходящих для решения описанных задач: FTP, HTTP, SMB. Причем два из них имеют дополненную реализацию с возможностью шифрования – FTPS и HTTPS, а в SMB встроенная шифрация.

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

Для грамотного выбора стоит рассмотреть каждый протокол в отдельности.

HTTP.


HyperText Transfer Protocol – протокол передачи гипертекстовых документов. В современных реализациях есть возможность передавать данные любого типа. HTTP используется в глобальной Сети для получения информации с веб-сайтов. Для идентификации ресурсов HTTP использует глобальные URI. При стандартной схеме запрос-ответ можно указать способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и прочее. Имеется также подробная спецификация в RFC 1945 и RFC 2616.

Основной особенностью протокола является то, что он не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Например, Cookies на стороне клиента или «Сессии» на стороне сервера. Т.е. браузер(сторона клиента в данном контексте), посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования. Такая особенность очень проста при реализации - она упрощает восстановление после краха системы. Если отказывает клиентская система, никакого восстановления не требуется, поскольку сервер не поддерживает никакой устойчивой информации о клиенте. Если же отказывает сервер, то клиент увидит, что на свои запросы он не получает ответы. Тогда клиент продолжает повторно посылать запросы до тех пор, пока сервер не ответит. И, поскольку запросы не зависят ни от какой ранней информации о состоянии, сервер получает запросы и может их обрабатывать

SMB.

Этот протокол предоставляет клиентским приложениям простой способ для чтения и записи файлов, а также способ запроса служб у серверных программ в различных типах сетевого окружения. Основанный также на технологии «клиент-сервер» имеет важное дополнение - когда клиент посылает в качестве запроса оппортунистические блокировки, то сервер вынужден отпустить уже предоставленную блокировку, так как другой клиент запросил открытие файла в режиме, несовместимом с предоставленной блокировкой. В типовой же модели блокировка не снимается. Конкретной спецификации для SMB нет, однако есть стандарты протокола для сервиса NetBIOS при использовании транспорта TCP/UDP. Эти стандарты описаны в RFC 1001(Концепции и методы) и RFC 1002(Подробные спецификации). В них также указано, что SMB может работать непосредственно поверх TCP, используя 445 порт, а также используя NetBIOS API, который занимает порты 137 и 139.



Серверы SMB предоставляют файловые системы и другие ресурсы (принтеры, почтовые сегменты, именованные каналы и т.д.) для общего доступа в сети. Клиенты соединяются с сервером, используя протоколы TCP/IP (а, точнее, NetBIOS через TCP/IP). После того, как соединение установлено, клиенты могут посылать команды серверу, который дает им доступ к ресурсам, позволяет открывать, читать файлы, писать в файлы и прочее.

Первый вариант протокола поддерживал основные операции работы с ФС:



  • присоединение к файловым и принтерным ресурсам и отсоединение от них

  • открытие и закрытие файлов

  • открытие и закрытие принтерных файлов

  • чтение и запись файлов

  • создание и удаление файлов и директорий

  • поиск директорий

  • получение и установление атрибутов файла

  • блокировка и разблокировка файлов

Однако для реализации системы можно обойтись и меньшим количеством операций. Но протокол SMB включает в себя главную возможность – механизм защиты файлов. Более того, он представлен на двух уровнях: user-level (пользовательский уровень) и share-level (уровень совместно используемого ресурса).

Аутентификация на уровне user-level предполагает, что клиент должен иметь имя пользователя и пароль. Если аутентификация прошла успешно, клиент имеет доступ ко всем доступным ресурсам сервера, кроме тех, что с share-level защитой. User-level защита дает возможность системным администраторам конкретно указывать, какие пользователи и группы пользователей имеют доступ к определённым данным.

Аутентификация на уровне share-level предполагает, что доступ к ресурсу контролируется паролем, установленным конкретно на этот ресурс. В отличие от user-level, этот уровень защиты не требует имя пользователя для аутентификации и не устанавливается никакая уникальность текущего пользователя.

Шифрация в протоколе SMB, о которой говорилось выше, проявляется при передачи пароля от клиента на сервер. На стороне клиента шифруется пароль и отправляется серверу, который производит дешифрацию и использует пароль по назнчению.

FTP.

File Transfer Protocol – стандартный протокол, предназначенный для передачи файлов по сети. Его часто используют для загрузки документов с частного устройства на открытые сервера. Протокол определен в RFC 959, но некоторые команды, например LIST, не имеют конкретной реализации. Это дает определенную свободу действий при создании системы на этом протоколе.



Особенностью FTP является использование множественного подключение. Т.е. один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (по стандартам это 21 порт), а через остальные происходит передача данных, при этом выделяется по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов в обоих направлениях. Для каждого канала данных открывается свой TCP порт, номер которого выбирается либо сервером, либо клиентом, в зависимости от режима передачи. Кроме того, протокол FTP имеет двоичный режим передачи, что сокращает накладные расходы трафика и уменьшает время обмена данными при передаче больших файлов.

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


Каждый протокол имеет свои достоинства и недостатки, упрощающие реализацию в одном, но усложняющие в другом. Однако можно свести выведенные различия по критериям в таблицу. Таблица №2 содержит различия между протоколами.

Свойство

HTTP

SMB

FTP

Основан на сессиях работы

Нет

Да

Да

Встроена аутентификация пользователей

Нет

Да

Да

Предусмотрен для передачи

Небольших текстовых файлов

Больших двоичных файлов

Больших двоичных файлов

Модель соединения

Одиночное подключение

Одиночное или двойное подключение

Множественное подключение

В основном приспособлен для приёма/передачи

Приёма

Приёма и передачи

Приёма и передачи

Поддерживает текстовый и двоичный режимы передачи

Нет

Нет

Да

Поддерживает указание типов передаваемых данных (MIME заголовки)

Да

Нет

Нет

Поддерживает операции над файловой системой (mkdir, rm, rename, и т. д.)

Нет

Да

Да

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


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

Серверная часть.

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

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

Рассматривая предлагаемые сервисы по поддержке и созданию виртуальных машин можно рассмотреть три сервиса: CloudServer от ActiveCloud, Аренда виртуальных серверов от ЛанКей и Виртуальные машины Microsoft Azure. Каждый из сервисов предоставляет в аренду удаленную виртуальную машину с операционной системой и возможностью хранения файлов. Для выбора стоит сравнить возможности трех сервисов.

CloudServer от ActiveCloud(http://www.activecloud.ru/ru/services/cloudserver/)

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

http://www.activecloud.ru/media/img/cloudsheme.png

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



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

Стоит отметить, что пробного бесплатного периода использования сервиса нет.
Аренда виртуальных серверов от ЛанКей(http://www.lankey.ru/oblachnie_servisi/arenda-virtualnyh-serverov/)

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

Рис.2 показывает окно выбора параметров виртуальной машины.

Не такой большой выбор операционных систем(Linux/Unix, Windows Server Standard, Windows Server Datacenter), также они не конкретизированы на этапе заявки.

Однако этот сервис предоставляет месяц бесплатного обслуживания.
Виртуальные машины Microsoft Azure (http://azure.microsoft.com/ru-ru/services/virtual-machines/).

Платформа Microsoft Azure позволяет создать не только виртуальные машины произвольной конфигурации, но и многое другое. Основной особенностью является запуск виртуальной машины для каждого экземпляра развернутого приложения. Более того, платформа дает возможность управления всеми сервисами из единого места, причем все сервисы могут быть взаимосвязаны друг с другом.

Виртуальные машины Microsoft Azure, которые предполагается использовать в проекте, обеспечат помимо базовых функций операционной системы, дополнительные: выделение ресурсов по требованию для неограниченного масштабирования, автоматическая синхронная репликация данных для повышения отказоустойчивости, обработка отказов инфраструктуры для обеспечения постоянной доступности и прочее. Есть уже предустановленные образы виртуальных машин с Windows Server, OpenSUSE, CentOS или Ubuntu. Рис.3 показывает возможности быстрого создания виртуальной машины.

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

На Рис.4 можно увидеть, что помимо широкого выбора образов можно установить свой образ виртуальной машины

Также имеется и предустановленные пакеты размеров с разными вариантами объема памяти и количества ядер процессора.

На данный момент эта платформа является одной из самых прогрессивных и простых в использовании.
Итог.

Для текущего проекта нет необходимости в высоких производительных мощностях, и требуется самая простая и доступная система. Естественно нужно учесть и тот факт, что проект является лишь вариантом построения системы облачного хранения файлов, поэтому для общего решения поставленной задачи можно обойтись одной виртуальной машиной с хорошо знакомой операционной системой. И если ActiveCloud не дает первоначального бесплатного использования сервиса, что недопустимо для учебного проекта, то при выборе между ЛанКей и Microsoft Azure стоит выбрать последний. Это объясняется простотой создания и использования, а также широкими возможностями платформы без дополнительных временных затрат.


Клиентская часть.

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

В настоящее время лидером по продажам в РФ являются смартфоны с операционной системой Android, следом за ними идут устройства от Aplle с iOS. Диаграмма №1 наглядно демонстрирует процентное соотношение по количеству продаж смартфонов на рынке мобильных устройств по данным салона связи «Евросеть» на первый квартал 2014 года.
При выборе стоит учесть и простоту загрузки приложения на устройство и возможности работы с файлами пользователя. Если говорить об iOS, то трудности возникают в основном с последним критерием: устройства с iOS не поддерживают внешние накопители и, как следствие, могут работать с файлами только внутри себя. Верно утверждение и о том, что iOS более «закрытая» система, чем Android. Последняя позволяет пользователям совершенно легально использовать внутренние системные каталоги, менять структуру или интерфейс, кроме того есть поддержка монтирования внешних накопителей. Таким образом, платформа Android оптимальный выбор для клиентской части проекта.
Теперь можно уточнить выбор в соответствии с другими пунктами и конкретизировать задачу. Текущее положение таково – FTP-сервер и FTP-клиент, Microsoft Azure как платформа для сервера и система Android как платформа для клиента.

На данном этапе отсутствует виртуальная машина – необходимо создать и настроить её, чтобы определиться с проектированием FTP-сервера.

Для создание необходимо задать следующие данные:


  • DNS-имя машины: olegoleg.cloudapp.com

  • Размер: Стандартный размер А1 с одним ядром и 1,75Гб памяти

  • Образ: Windows Server 2012

  • Имя пользователя и Пароль

Таких параметров вполне хватит для проверки работоспособности системы. Образ системы выбран Windows Server 2012 это обусловлено большой популярностью Windows систем среди обычных пользователей, а значит её настройка для конечного пользователя не вызовет труда.

После подключения к удаленной машине при помощи «Удаленного рабочего стола» можно увидеть ничем не отличающуюся от любого другого образа Windows Server систему. Главной задачей является увидеть, как располагаются логические диски и как правильно спроектировать сам сервер. На виртуальной машине есть два логических диска – C и D, причем диск D хранит временные файлы и после перезагрузки машины диск очищается. Имеет смысл хранит файлы пользователя разрабатываемой системы на диске C, либо создать дополнительный логический диск. Так или иначе приложение-сервер будет работать с этой системой как и с любой другой, особых алгоритмов при работе с файлами не требуется.

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

Остро стоит вопрос подключения к портам извне. Стоит напомнить, что виртуальная машина Microsoft Azure, как и любая другая находится в сети за виртуальным маршрутизатором, что не позволяет подключить к серверу по протоколу FTP в пассивном режиме – во-первых маршрутизатор не дает пройти пакетам на 21 порт машины, во-вторых остальные порты, использующиеся для передачи также не разрешены к использованию. Активный режим сервера невыгоден из-за отсутствия информации о клиенте, который может также находиться за маршрутизатором, и из-за тенденции к признанию активного режима устаревшим.

Microsoft Azure позволяет решить проблему с открытием доступа для портов. Для этого существуют т.н. Конечные точки(Endpoints). Каждая конечная точка входа ассоциируется с виртуальной машиной и указывает, пропускать ли трафик и на какой порт. Для создания конечной точки необходимо указать порт и протокол, однако может быть только 25 конечных точек, в связи с этим достаточно ограничиться 21 портом для передачи управляющих данных и портами с 1024 по 1028 для передачи данных. Сервер в пассивном режиме должен сам выбирать один из этих портов. Тогда после настройки список конечных точек для виртуальной машины должен выглядеть как рис.№4

Теперь, после создания виртуальной машины и её настройки можно конкретизировать задачу: Разработать FTP-сервер для виртуальной машины Microsoft Azure, а также разработать приложение для платформы Android, работающее с сервером.

Как было сказано выше FTP-сервер будет представлять консольное приложение для работы в среде Windows. Оптимальным выбором для разработки будет использование среды разработки MS Visual Studio 2012 и использование языка программирования C#.



FTP-клиент – приложения для устройств с ОС Android. Средой разработки выбирается Eclipse с дополнительно установленными плагинами, а использованным языком является язык Java, как повсеместно используемый при разработке на Android.
Каталог: files -> stud -> bakalavr
stud -> Инфекционные болезни
stud -> «Создание cd-rom раздела на usb-флеш-накопителе»
stud -> Контрольные вопросы Свойства одноранговых лвс. Харатеристика одноранговых лвс на базе Windows
stud -> Лабораторная работа №1 по дисциплине: «Программное обеспечение вычислительных сетей» Одноранговые лвс
stud -> Винирные покрытия
stud -> Конспект и на закрепление выполнение вопросы. Вклеенных распечатанных конспектов быть не должно
stud -> Методические указания к лабораторной работе Механизмы ос microsoft Windows
stud -> Лабораторная работа №1 по курсу "Операционные системы" "Механизмы ос microsoft Windows"


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница