Обмен информацией между сотрудниками в коммерческой организации

Особенности архитектуры технологии "клиент-сервер", ее преимущества, стадии проектирование, концепция и перспектива использования. Достоинства и недостатки "интеллектуальных серверов", назначение протокола управления передачей и алгоритм хеширования.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 06.05.2015
Размер файла 303,3 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

План

Введение

1. Описание предметной области

2. Технология «клиент-сервер»

3. Протокол TCP

4. Алгоритм хеширования

5. MySQL

6. Мicrosoft Visual Studio

Введение

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

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

Второй слой -- коммуникационное оборудование. Кабельные системы, повторители, коммутаторы, маршрутизаторы и модульные концентраторы превратились в полноправные компоненты сети. Сегодня коммуникационное устройство может представлять собой сложное специализированное мультипроцессорное устройство, которое нужно конфигурировать, администрировать и оптимизировать его работу в сети.

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

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

Архитектура «клиент-сервер» представляет собой модель взаимодействия компьютеров в сети. Как правило, один компьютер в сети располагает информационно-вычислительными ресурсами, такими, как мощные процессоры, программные приложения, базы данных и различные сервисы. Другие же компьютеры пользуются ими. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса (Resource Server -- RS), а компьютер, который пользуется этим ресурсом, -- клиентом (Clients). Конкретный сервер характеризуется видом ресурса, которым он владеет. Если используемым ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого состоит в обслуживании запросов клиентов по выдаче или преобразованию данных. Если применяется файловая система или система пересылки сообщений, то говорят о файловом или почтовом сервере.

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

К таким информационным системам в первую очередь стоит отнести автоматизированные системы управления. Прежде всего главным становится создание базы данных, которые позволяют обрабатывать и хранить данную информацию. Предметом исследования данного курсового проекта является анализ возможности создания автоматизированной системы при помощи СУБД MySQL, а так же языков С#.

1. Описание предметной области

Коммерческая организация.

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

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

2) Выбор собеседника. После входа в систему, сотрудник имеет возможность просмотреть все предложенные для него путевки на различные базы отдыха.

Курорты характеризуются следующими критериями:

Страна

Цена

Количество дней

Транспорт

Сведения о клиенте в БД:

Ip_k

ФИО

Адрес

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

При работе с системой Сотрудник должен иметь возможность решать следующие задачи:

­ Вести учёт проданных путевок;

­ Проводить регистрацию новых клиентов;

Каждый клиент должен иметь возможность решать следующие задачи:

­ просматривать каталог, т.е. краткое описание всех доступных курортов;

­ Делать предварительный заказ путевки.

2. Технология «клиент-сервер»

Архитектура клиент-сервер предъявляет специфические требования как к клиенту, так и к серверу. Программа, удовлетворяющая этим требованиям, может считаться клиент-серверным приложением, выполняющим распределенную обработку данных (рис. 1.1).

Рис. 1.1 Клиент, связывающийся с сервером по сети

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

Преимущества клиент-серверных систем

· Клиент-серверный подход -- модульный, причем серверные программные компоненты компактны и автономны.

· Поскольку каждый компонент выполняется в отдельном защищенном процессе пользовательского режима, сбой сервера не повлияет на остальные компоненты операционной системы.

· Автономность компонентов делает возможным их выполнение на нескольких процессорах на одном компьютере (симметричная многопроцессорная обработка) или на нескольких компьютерах сети (распределенные вычисления).

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

Проектирование клиент-серверной системы

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

Стадии разработки

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

Рис. 1.2 Стадии проектирования клиент-серверной базы данных

Концепция

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

Логика

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

Физическое решение

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

Перспектива

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

Особенности клиента

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

Особенности сервера

В состав серверной части должны входить основные исполняемые файлы, библиотеки и все остальные файлы, необходимые для поддержки доступа пользователей по сети. Кроме того, надо изучить требования к ресурсам сервера и на их основе принять решение относительно аппаратной конфигурации, учитывая тип процессора (например, SQL Server поддерживает процессоры Alpha AXP, MIPS и 32-разрядные процессоры семейства Intel x86) и ресурс памяти (чем больше клиентов, тем больше потребуется ОЗУ для сохранения и увеличения быстродействия).

Системы клиент-сервер

Клиент-серверная система управления базой данных может опираться на несколько типов распределения обязанностей между клиентом и сервером:

· «интеллектуальные» клиенты;

· «интеллектуальный» сервер;

· смешанные системы;

· многоуровневые системы. Схему реализации выбирают на основе анализа требований к:

· сетевому графику;

· ресурсам клиента и сервера;

· производительности базы данных.

«Интеллектуальные» клиенты

Это один из самых распространенных методов реализации клиент-серверных приложений (рис. 1.3). «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.

Рис. 1.3 Бизнес-логика реализована на клиенте

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

Достоинства «интеллектуальных» клиентов

· Простота архитектуры, что облегчает разработку и сопровождение системы.

· Наличие хорошо известных и достаточно мощных средств разработки (например, Visual Basic 5.0).

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

Недостатки «интеллектуальных» клиентов

· Выполнение бизнес-правил на клиенте иногда увеличивает сетевой трафик из-за необходимости передавать клиенту все данные для принятия решения на основе правил.

· Для модификации бизнес-логики необходимо повторное развертывание всех клиентов.

«Интеллектуальные» серверы

Перенеся все бизнес-правила на SQL Server, где они реализуются в виде хранимых процедур, Вы создадите «интеллектуальный» сервер (рис. 1.4). Роль сервера в такой клиент-серверной системе много шире простого хранилища файлов, доступных множеству пользователей сети. Интеллект сервера проявляется в способности выполнять команды (SQL-запросы) и возвращать результирующий набор данных.

Рис. 1.4 Бизнес-логика реализована на центральном сервере

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

Достоинства «интеллектуальных» серверов

· Увеличение производительности: бизнес-логика выполняется в том же адресном пространстве, что и код доступа к базе данных, и, кроме того, тесно интегрирована с механизмом поиска данных SQL Server. Это означает, что данные не нужно перемещать или копировать перед обработкой, а значит, сетевой трафик минимизируется.

· На сервере легче обеспечивать целостность данных.

· При необходимости бизнес-логика модифицируется централизованно, без изменения клиентов.

Недостатки «интеллектуальных» клиентов

· Повышение требований к ресурсам сервера, где выполняются все запросы и манипуляции с данными.

· Ограниченный выбор средств разработки: хранимые процедуры, например, создают на языке Transact-SQL. Хотя SQL Server поддерживает вызовы кода, написанного на других языках, этот подход сложен и в общем случае менее эффективен, нежели разработка тех же функций на Transact-SQL.

Смешанные системы

В рамках двухуровневой реализации возможны и смешанные варианты, обладающие достоинствами как интеллектуальных серверов, так и интеллектуальных клиентов (рис. 1.5). Например, клиентский компонент смешанного решения, разработанный средствами Visual Basic, может вызывать хранимые процедуры SQL Server.

Рис. 1.5 Смешанные системы: интеллектуальные клиенты и интеллектуальный сервер

Достоинства смешанных систем

· Часть бизнес-логики может быть реализована в клиентской части.

· Серверный код (например, хранимые процедуры SQL Server) одновременно доступен многим клиентам, что снижает накладные затраты при выполнении однотипных запросов.

· Эффективность работы клиентов меньше зависит от сетевого трафика.

Недостатки смешанных систем

· Бизнес-логика распределена между клиентом и сервером.

· Модернизация приложения требует распространения новых версий клиентской части среди широкой аудитории.

Многоуровневые системы

Многоуровневая система (иногда ее называют трехуровневой) позволяет разделить пользовательский интерфейс, бизнес-правила и базу данных (рис. 1.6).

Рис. 1.6 Пользовательский интерфейс, бизнес-правила и база данных размешены отдельно

В многоуровневой системе бизнес-правила реализуются как отдельные библиотеки (DLL). Их (например, написанные на Visual Basic) можно разместить на сервере. Клиент, библиотеки и база данных составляют распределенные сервисы многоуровневой системы.

Сервисы

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

Сервисная модель -- это метод рассмотрения приложения как набора средств или сервисов, которые удовлетворяют запросы клиентов. Моделирование программы в виде набора отдельных сервисов позволяет повторно использовать компоненты, предоставляет доступ к ним другим приложениям и помогает распределять их выполнение между несколькими компьютерами сети.

В типичных бизнес-приложениях возможны сервисы трех категорий.

Типы сервисов

Тип сервиса

Размещение

Назначение

Пользовательский

Клиент

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

Бизнес-сервис

Сервер

Реализация основных стратегий, генерация информации на основе данных и поддержка целостности среды принятия бизнес-решений

Сервис данных

Сервер

Структуризация данных, их хранение, извлечение и поддержка целостности

Достоинства многоуровневых систем

Разделение компонентов интерфейса, бизнес-правил и хранения данных. Возможность применения интеллектуальных клиентов. Возможность применения сервисов.

Недостатки многоуровневых систем

Необходимы сервер и сеть. Увеличивается сетевой трафик.

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

«интеллектуальные» клиенты;

· «интеллектуальный» сервер;

· смешанные системы;

· многоуровневые системы.

3. Протокол TCP

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

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

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

В условиях, когда стратегические и тактические сети компьютерных коммуникаций возникают и исчезают, важно обеспечить средства для их со единения, а также стандартные протоколы коммуникации между процессами, которые бы поддерживали большой диапазон прикладных программ. Предвидя потребность в таких стандартах, Представительство Секретариата Обороны по научно-исследовательским и опытно- конструкторским работам предъявило протокол управления передачей (Transmission Control Protocol - TCP), описанный здесь, на основе стандартизации DoD протокола коммуникаций между процессами.

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

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

Протокол TCP основывается на концепциях, впервые описанных авторами Cerf и Kahn в документе .TCP занимает в многоуровневой архитектуре протоколов нишу непосредственно над протоколом Internet, который позволяет протоколу TCP отправлять и получать сегменты информации переменной длины, заключенные в оболочку Internet датаграмм. Internet датаграмма предоставляет средства для адресации отправителя и получателя сегментов TCP в различных сетях. Протокол Internet также осуществляет любую фрагментацию и сборку сегментов TCP, необходимую для осуществления передачи и доставки через множество сетей и промежуточных шлюзов. Протокол Internet также обрабатывает информацию о приоритете, классификации безопасности, а также осуществляет разграничение TCP сегментов. Так что данная информация может быть передана напрямую через множество сетей.

Уровни протоколов

верхний уровень

TCP

протокол Internet

коммуникационная сеть

Рис. 1

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

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

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

Интерфейсы

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

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

Интерфейс между протоколом TCP и протоколами более низкого уровня за дан в значительно меньшей степени, за исключением того, что должен существовать некий механизм, с помощью которого эти два уровня могут асинхронно обмениваться информацией друг с другом. Обычно полагают, что протокол нижнего уровня задает данный интерфейс. Протокол TCP спроектирован так, чтобы работать с весьма разнообразной средой объединенных компьютерных сетей. В данном документе предполагается, что протокол более низкого уровня - это Internet [2].

Действие

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

· базовая передача данных

· достоверность

· управление потоком

· разделение каналов

· работа с соединениями

· приоритет и безопасность

Основные действия протокола TCP в каждой из этих областей описаны в следующих параграфах.

Базовая передача данных

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

Иногда пользователям бывает необходимо убедиться в том, что все данные, переданные ими протоколу TCP, уже отправлены. Для этой цели определена функция проталкивания (push). Чтобы убедиться в том, что данные, отправленные протоколу TCP, действительно переданы, отправитель указывает, что их следует протолкнуть к получателю.

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

Достоверность

Протокол TCP должен иметь защиту от разрушения данных, потери, дублирования и нарушения очередности получения, вызываемых коммуникационной системой Internet. Это достигается присвоением очередного номера каждому передаваемому октету, а также требованием подтверждения (ACK) от программы TCP, принимающей данные. Если подтверждения не получено в течении контрольного интервала времени, то данные посылаются повторно. Со стороны получателя номера очереди используются для восстановления очередности сегментов, которые могут быть получены в неправильном порядке, а также для ограничения возможности появления дубликатов.

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

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

Управление потоком

Протокол TCP дает средства получателю управлять количеством данных, посылаемых ему отправителем. Это достигается возвратом так называемого "окна" (window) вместе с каждым подтверждением, которое указывает диапазон приемлемых номеров, следующих за номером последнего успешно принятого сегмента. Окно определяет количество октетов, которое отправитель может послать до получения дальнейших указаний.

Разделение каналов

Чтобы позволить на отдельно взятом компьютере многим процессам одновременно использовать коммуникационные возможности уровня TCP, протокол TCP предоставляет на каждом хост-компьютере набор адресов или портов. Вместе с адресами сетей и хост-компьютеров на коммуникационном уровне Internet они образуют сокет (socket - разъем).

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

Соотнесение портов и процессов осуществляется каждым хост- компьютером самостоятельно. Однако оказывается полезным связывать часто используемые процессы (такие как "logger" или сервис с разделением времени) с фиксированными документированными сокетами.

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

Работа с соединениями

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

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

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

Приоритет и безопасность

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

2. Идеология протокола

2.1 Элементы системы объединенных сетей

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

Здесь предполагается, что компьютерные сети могут быть либо локальными (например, ETHERNET), либо большими сетями (например ARPANET), но в любом случае они основываются на технологии коммутации пакетов. Реальными агентами, создающими и потребляющими сообщения, циркулирующие в сети, являются процессы. Протоколы различных уровней в сетях, на шлюзах и на хост-компьютерах поддерживают систему коммуникаций между процессами, которая обеспечивает двунаправленный поток данных по логическим соединениям между портами процессов.

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

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

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

Модель действия

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

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

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

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

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

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

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

Программное обеспечение хост-компьютера

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

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

Интерфейсы

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

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

Связь с другими протоколами

Нижеприведенная диаграмма иллюстрирует место протокола TCP в иерархии протоколов

Рис.2 Взаимосвязь протоколов

Предполагается, что протокол TCP будет в состоянии эффективно поддерживать протоколы более высокого уровня. Протокол TCP должен легко взаимодействовать с такими протоколами более высокого уровня, как ARPANET Telnet или AUDIN II THP to the TCP.

Надежные коммуникации

Поток данных, посылаемый на TCP соединение, принимается получателем надежно и в соответствующей очередности.

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

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

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

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

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

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

Протокол TCP волен произвольным образом связывать порты с процессами.

Однако при любой реализации протокола необходимо придерживаться нескольких основополагающих концепций. Должны присутствовать общеизвестные сокеты, которые протокол TCP ассоциирует исключительно с "соответствующими им" процессами. Мы представляем себе, как будто процессы могут "владеть" портами и что процессы могут инициировать соединения только с тех портов, которыми они владеют. (С точки зрения реализации протокола "владение" ограничивается хост-компьютером, однако мы можем представить себе команду пользователя по запросу порта (Request Port) или же метод выделения группы уникальных портов данному процессу, например посредством ассоциирования старших байтов в имени порта с данным процессом).

Соединение задается командой OPEN (открыть), сделанной с локального порта и имеющей аргументом чужой сокет. В ответ на такой запрос программа протокола TCP предоставляет имя локального (короткого) со единения. По этому имени пользователь адресуется к данному соединению при последующих вызовах. О соединениях следует помнить кое-какие вещи.

Мы предполагаем, что имеется некая структура данных, называемая блоком управления передачей (Transmission Control Block -TCB), предназначенная для сохранения описанной выше информации. Можно было бы реализовать протокол таким образом, чтобы локальное имя для соединения было бы указателем на структуру TCB последнего. Запрос OPEN указывает также, осуществляется ли соединение активным образом, или же происходит пассивное ожидание соединения извне.

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

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

Общеизвестные сокеты представляют собой удобный механизм априорного привязывания адреса сокета с каким-либо стандартным сервисом. Например, процесс "сервер для программы Telnet" жестко связан с конкретным сокетом. Другие сокеты могут быть зарезервированы за передатчиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером, а также Sink-процессами (последние три пункта связаны с обработкой текстов). Адрес сокета может быть зарезервирован для доступа к процедуре "просмотра", которая могла бы указывать сокет, через который можно было бы получить новообразованные услуги. Концепция общеизвестного сокета является частью TCP спецификации, однако собственно асоциирование сокетов с услугами выходит за рамки данного описания протокола.

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

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

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

Процедура установки соединения использует флаг управления синхронизацией (SYN) и трижды обменивается сообщениями. Такой обмен называется трехвариантным подтверждением .

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

Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN.

Коммуникация данных

Набор данных, передаваемых по соединению, можно рассматривать как поток октетов. Пользователь, отправляющий данные, указывает при запросе по посылку, следует ли данные, отправляемые при этом запросе, немедленно проталкивать через сеть к получателю. Указание осуществляется установкой флага PUSH (проталкивание).

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

Нет нужды привязывать функции проталкивания к границам сегмента. Данные, содержащиеся в каком-либо сегменте, могут быть результатом одного или нескольких запросов на посылку. Или же один запрос может породить несколько сегментов.

Целью функции проталкивания и флага PUSH является проталкивание данных через сеть от отправителя к получателю. Функция не осуществляет обработки самих данных.

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

Приоритет и безопасность

Протокол TCP использует тип сервиса и опцию безопасности протокола Internet с тем, чтобы пользователям протокола TCP обеспечить приоритет и безопасность на каждом соединении. Не все модули протокола TCP обязательно будут действовать в многоуровневой системе обеспечения безопасности. Некоторые модули ограничиваются только обычными, неспецифическими соединениями, другие ограничиваются лишь первым уровнем безопасности и закрытости. Следовательно, некоторые реализации протокола TCP и услуг для пользователей могут использовать лишь часть многоуровневой системы безопасности. Модули TCP, действующие в многоуровневой системе безопасности, должны адекватным образом выставлять в отсылаемых сегментах флаги безопасности и приоритета. Такие модули TCP должны также позволять своим клиентам или вышестоящим протоколам, таким как Telnet и THP, указывать требуемый уровень безопасности, закрытости и приоритета для устанавливаемых соединений.

2.10 Принцип устойчивости

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

4. Алгоритм хеширования

MD5 (англ. Message Digest 5) -- 128-битный алгоритм хеширования, разработанный профессором Рональдом Л. Ривестом изМассачусетского технологического института (Massachusetts Institute of Technology, MIT) в 1991 году. Предназначен для создания «отпечатков» или дайджестов сообщения произвольной длины и последующей проверки их подлинности.

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

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

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

Почему популярные хэширующие функции, такие как md5() и sha1() не подходят для паролей?

Такие хэширующие алгоритмы как MD5, SHA1 и SHA256 были спроектированы очень быстрыми и эффективными. При наличии современных технологий и оборудования, стало довольно просто выяснить результат этих алгоритмов методом "грубой силы" для определения оригинальных вводимых данных.

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

Алгоритм MD5 уязвим к некоторым атакам, например возможно создание двух сообщений с одинаковой хеш-суммой, поэтому его использование не рекомендуется. Альтернативой являются алгоритмы семейства SHA-2.

MD5 -- один из серии алгоритмов по построению дайджеста сообщения, разработанный профессором Рональдом Л. Ривестом из Массачусетского технологического института. Был разработан в 1991 году, как более надёжный вариант предыдущего алгоритма MD4. Описан в RFC 1321. Позже Гансом Доббертином были найдены недостатки алгоритма MD4.

В 1993 году Берт ден Бур (Bert den Boer) и Антон Босселарс (Antoon Bosselaers) показали, что в алгоритме возможны псевдоколлизии, когда разным инициализирующим векторам соответствуют одинаковые дайджесты для входного сообщения.

В 1996 году Ганс Доббертин (Hans Dobbertin) объявил о коллизии в алгоритме, и уже в то время было предложено использовать другие алгоритмы хеширования, такие как Whirlpool, SHA-1 или RIPEMD-160.

Из-за небольшого размера хеша в 128 бит можно рассматривать birthday атаки. В марте 2004 года был запущен проект MD5CRK с целью обнаружения уязвимостей алгоритма, используя birthday атаки. Проект MD5CRK закончился 17 августа 2004 года, когда Ван Сяоюнь (Wang Xiaoyun), Фэн Дэнго (Feng Dengguo), Лай Сюэцзя (Lai Xuejia) и Юй Хунбо (Yu Hongbo) обнаружили уязвимости в алгоритме.

1 марта 2005 года Arjen Lenstra, Xiaoyun Wang и Benne de Weger продемонстрировали построение двух X.509 документов с различными открытыми ключами и одинаковым хешем MD5.

18 марта 2006 года исследователь Властимил Клима (Vlastimil Klima) опубликовал алгоритм, который может найти коллизии за одну минуту на обычном компьютере, метод получил название «туннелирование».

В конце 2008 года US-CERT призвал разработчиков программного обеспечения, владельцев веб-сайтов и пользователей прекратить использовать MD5 в любых целях, так как исследования продемонстрировали ненадёжность этого алгоритма.

Схема работы алгоритма MD5

На вход алгоритма поступает входной поток данных, хеш которого необходимо найти. Длина сообщения может быть любой (в том числе нулевой). Запишем длину сообщения в L. Это число целое и неотрицательное. Кратность каким-либо числам необязательна. После поступления данных идёт процесс подготовки потока к вычислениям.

Ниже приведены 5 шагов алгоритма:

Шаг 1. Выравнивание потока

Сначала дописывают единичный бит в конец потока (байт 0x80), затем необходимое число нулевых бит. Входные данные выравниваются так, чтобы их новый размер был сравним с 448 по модулю 512(). Выравнивание происходит, даже если длина уже сравнима с 448.

Шаг 2. Добавление длины сообщения[править | править вики-текст]

В оставшиеся 64 бита дописывают 64-битное представление длины данных (количество бит в сообщении) до выравнивания. Сначала записывают младшие 4 байта. Если длина превосходит , то дописывают только младшие биты(эквивалентно взятию модуля от ). После этого длина потока станет кратной 512. Вычисления будут основываться на представлении этого потока данных в виде массива слов по 512 бит.

Шаг 3. Инициализация буфера

Для вычислений инициализируются 4 переменных размером по 32 бита и задаются начальные значения шестнадцатеричными числами (порядок байтов little endian, сначала младший байт):

А = 01 23 45 67; //0x67452301

В = 89 AB CD EF; //0xEFCDAB89

С = FE DC BA 98; //0x98BADCFE

D = 76 54 32 10. //0x10325476

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

Определим ещё функции и константы, которые нам понадобятся для вычислений.

· Потребуются 4 функции для четырёх раундов. Введём функции от трёх параметров -- слов, результатом также будет слово.


Подобные документы

  • Основные понятия серверов. Модель клиент-сервер. Классификация стандартных серверов. Недостатки файл-серверной системы. Криптографические методы защиты информации. Серверы удаленного доступа. Методы и средства обеспечения безопасности информации.

    контрольная работа [36,3 K], добавлен 13.12.2010

  • Проектирование информационной системы на основе архитектуры "файл-сервер", "клиент-сервер", многоуровневой архитектуры, Intranet-системы. Преимущества и недостатки файл-серверного подхода при обеспечении многопользовательского доступа к базе данных.

    лабораторная работа [220,5 K], добавлен 02.02.2015

  • Преимущества и недостатки использования двух типов базовых архитектур Клиент-сервер и Интернет/Интранет, их компоненты и экономическая целесообразность. Информационные взаимосвязи компонентов WEB-узла, взаимодействие браузера, сервера и сценария CGI.

    реферат [324,4 K], добавлен 22.06.2011

  • Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.

    курсовая работа [88,9 K], добавлен 11.04.2010

  • Особенности программной архитектуры клиент-сервер, взаимодействие серверов и пользователей сети Интернет согласно сетевым протоколам. Классификация служб по выполняемым функциям: доступ к гипертекстовому контенту, файлам, проведение телеконференций.

    реферат [31,5 K], добавлен 12.07.2015

  • Основные концепции разработки приложения в архитектуре MVVM. Проектирование базы данных, предназначенной для сбора информации о дорожно-транспортных происшествиях. Классификация и типы архитектуры "клиент–сервер", ее основные достоинства и недостатки.

    курсовая работа [4,1 M], добавлен 25.11.2015

  • Описание предметной области и разработка электронного учебника на основе архитектуры "клиент – сервер". Тестирование программы менеджера и создание интерфейса главного меню. Вход в программу в качестве пользователя и обеспечение перехода к данным лекций.

    курсовая работа [1,5 M], добавлен 26.02.2015

  • Создание клиент-серверного приложения на основе технологии CORBA. Проектирование многоуровневой системы, в которой клиент при помощи банкомата выполняет необходимые операции. Способы реализации серверов в разных каналах для ускорения обработки данных.

    лабораторная работа [1,1 M], добавлен 08.06.2009

  • Описания программного продукта компании 1С, предназначенного для быстрой разработки прикладных решений. Исследование типов архитектур построения баз данных. Технология с сетью и файловым сервером. Анализ особенностей трехзвенной архитектуры клиент-сервер.

    курсовая работа [401,4 K], добавлен 12.01.2015

  • Функциональная модель системы. Проектирование схемы базы данных. Проектирование архитектуры системы. Принцип технологии клиент-сервер. Построение схемы ресурсов. Выбор программных средств. Разработка базы данных с использованием Microsoft SQL Server.

    дипломная работа [1,1 M], добавлен 30.03.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.