Реферат: Разработка методов определения эффективности торговых интернет систем

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

          Сложная структура. Является совокупностью типовых, классических структур. Часто сеть простой структуры создается на основе сети передачи информации сложной структуры (левая нижняя структура).

3. Протоколы передачи данных

3.1 Основы TCP/IP

Термин "TCP/IP" обычно обозначает все, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы UDP, ARP, ICMP, TELNET, FTP и многие другие. TCP/IP - это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется "internet". Если речь идет о глобальной сети, объединяющей множество сетей с технологией internet, то ее называют Internet.

Модуль IP создает единую логическую сеть

Архитектура протоколов TCP/IP предназначена для объединенной сети, состоящей из соединенных друг с другом шлюзами отдельных разнородных пакетных подсетей, к которым подключаются разнородные машины. Каждая из подсетей работает в соответствии со своими специфическими требованиями и имеет свою природу средств связи. Однако предполагается, что каждая подсеть может принять пакет информации (данные с соответствующим сетевым заголовком) и доставить его по указанному адресу в этой конкретной подсети. Не требуется, чтобы подсеть гарантировала обязательную доставку пакетов и имела надежный сквозной протокол. Таким образом, две машины, подключенные к одной подсети могут обмениваться пакетами.

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

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

3.2 Функции протокола IP

Протокол IP находится на межсетевом уровне стека протоколов TCP/IP. Функции протокола IP определены в стандарте RFC-791 следующим образом: “Протокол IP обеспечивает передачу блоков данных, называемых дейтаграммами, от отправителя к получателям, где отправители и получатели являются компьютерами, идентифицируемыми адресами фиксированной длины (IP-адресами). Протокол IP обеспечивает при необходимости также фрагментацию и сборку дейтаграмм для передачи данных через сети с малым размером пакетов”.

Протокол IP является ненадежным протоколом без установления соединения. Это означает, что протокол IP не подтверждает доставку данных, не контролирует целостность полученных данных и не производит операцию квитирования (handshaking) - обмена служебными сообщениями, подтверждающими установку соединения с узлом назначения и его готовность к приему данных. Протокол IP обрабатывает каждую дейтаграмму как независимую единицу, не имеющую связи ни с какими другими дейтаграммами в Интернет. После того, как дейтаграмма отправляется в сеть, ее дальнейшая судьба никак не контролируется отправителем (на уровне протокола IP). Если дейтаграмма не может быть доставлена, она уничтожается. Узел, уничтоживший дейтаграмму, может оправить по обратному адресу ICMP-сообщение о причине сбоя.

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

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

Общий сценарий работы модуля IP на каком-либо узле сети, принимающего дейтаграмму из сети, таков:

·     с одного из интерфейсов уровня доступа к среде передачи (например, с Ethernet-интерфейса) в модуль IP поступает дейтаграмма;

·     модуль IP анализирует заголовок дейтаграммы;

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

·     если дейтаграмма является фрагментом большей дейтаграммы, ожидаются остальные фрагменты, после чего из них собирается исходная большая дейтаграмма;

·     из дейтаграммы извлекаются данные и направляются на обработку одному из протоколов вышележащего уровня (какому именно - указывается в заголовке дейтаграммы);

·     если дейтаграмма не направлена ни на один из IP-адресов данного узла, то дальнейшие действия зависят от того, разрешена или запрещена ретрансляция (forwarding) “чужих” дейтаграмм;

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

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

·     При получении данных от вышестоящего уровня для отправки их по сети IP-модуль формирует дейтаграмму с этими данными, в заголовок которой заносятся адреса отправителя и получателя (также полученные от транспортного уровня) и другая информация; после чего выполняются следующие шаги:

·     если дейтаграмма предназначена этому же узлу, из нее извлекаются данные и направляются на обработку одному из протоколов транспортного уровня (какому именно - указывается в заголовке дейтаграммы);

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

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

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

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

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

Хостами называются узлы IP-сети, не являющиеся маршрутизаторами. Обычно хост имеет один IP-интерфейс (например, связанный с сетевой картой Ethernet или с модемом), хотя может иметь и несколько.

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

3.3 RTP - Протокол передачи видео- и аудиоинформации в реальном масштабе времени

Стремительный рост Internet предъявляет новые требования к скорости и

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

одного увеличения емкости сети недостаточно, необходимы разумные и

эффективные методы управления графиком и контролем загруженности линий

передачи.

В приложениях реального времени отправитель генерирует поток данных с

постоянной скоростью, а получатель (или получатели) должен предоставлять

эти данные приложению с той же самой скоростью. Такие приложения включают,

например, аудио- и видеоконференции, живое видео, удаленную диагностику в

медицине, компьютерную телефонию, распределенное интерактивное

моделирование, игры, мониторинг в реальном времени и др.

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

Несмотря на то что TCP позволяет поддерживать множество разнообразных

распределенных приложений, он не подходит для приложений реального

времени.

Эту задачу и призван решить новый транспортный протокол реального времени

— RTP (Real-Time Transport Protocol), который гарантирует доставку данных

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

могут быть воспроизведены в реальном времени.

Принципы построения протокола RTP

RTP не поддерживает каких-либо механизмов доставки пакетов, обеспечения

достоверности передачи или надежности соединения. Эти все функции

возлагаются на транспортный протокол. RTP работает поверх UDP и может

поддерживать передачу данных в реальном времени между несколькими

участниками RTP-сеанса.

Для каждого участника RTP сеанс определяется парой транспортных адресов

назначения пакетов (один сетевой адрес — IP и пара портов: RTP и RTCP).

Пакеты RTP содержат следующие поля: идентификатор отправителя,

указывающий, кто из участников генерирует данные, отметки о времени

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

стороной с правильными интервалами, информация о порядке передачи, а также

информация о характере содержимого пакета, например, о типе кодировки

видеоданных (MPEG, Indeo и др.). Наличие такой информации позволяет

оценить величину начальной задержки и объема буфера передачи.

В типичной среде реального времени отправитель генерирует пакеты с

постоянной скоростью. Они отправляются через одинаковые интервалы времени,

проходят через сеть и принимаются получателем, воспроизводящим данные в

реальном времени по их получении. Однако ввиду изменения времени задержки

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

интервалы времени. Для компенсации этого эффекта поступающие пакеты

буферизуются, придерживаются на некоторое время и затем предоставляются с

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

Поэтому для функционирования протокола реального времени необходимо, чтобы

каждый пакет содержал временную метку— таким образом получатель может

воспроизвести поступающие данные с той же скоростью, что и отправитель.

Поскольку RTP определяет (и регулирует) формат полезной нагрузки

передаваемых данных, с этим напрямую связана концепция синхронизации, за

которую частично отвечает механизм трансляции RTP — микшер. Принимая

потоки пакетов RTP от одного или более источников, микшер, комбинирует их

и посылает новый поток пакетов RTP одному или более получателям. Микшер

может просто комбинировать данные, а также изменять их формат, например,

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

система хочет принять участие в сеансе, но ее канал до сети не имеет

достаточной емкости для поддержки всех потоков RTP, тогда микшер получает

все эти потоки, объединяет их в один и передает последний новому члену

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

импульсно-кодовой модуляции. Заголовок RTP, генерируемый микшером,

включает идентификатор отправителя, чьи данные присутствуют в пакете.

Более простое устройство — транслятор, создает один исходящий пакет RTP

для каждого поступающего пакета RTP. Этот механизм может изменить формат

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

для передачи данных из одного домена в другой. Например, потенциальный

получатель может оказаться не в состоянии обрабатывать высокоскоростной

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

конвертирует видео в формат более низкого качества, требующий не такой

высокой скорости передачи данных.

Методы контроля работы

Протокол RTP используется только для передачи пользовательских данных —

обычно многоадресной — всем участникам сеанса. Совместно с RTP работает

протокол RTCP (Real-time Transport Control Protocol), основная задача

которого состоит в обеспечении управления передачей RTP. RTCP использует

тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но

другой номер порта.

RTCP выполняет несколько функций:

Обеспечение и контроль качества услуг и обратная связь в случае

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

сеанса могут оценить, насколько хороши работа и прием других участников.

Сообщения отправителя позволяют получателям оценить скорость данных и

качество передачи. Сообщения получателей содержат информацию о

проблемах, с которыми они сталкиваются, включая утерю пакетов и

избыточную неравномерность передачи. Обратная связь с получателями важна

также для диагностирования ошибок при распространении. Анализируя

сообщения всех участников сеанса, администратор сети может определить,

касается данная проблема одного участника или носит общий характер. Если

приложение-отправитель приходит к выводу, что проблема характерна для

системы в целом, например, по причине отказа одного из каналов связи, то

оно может увеличить степень сжатия данных за счет снижения качества или

вообще отказаться от передачи видео — это позволяет передавать данные по

соединению низкой емкости.

Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое

описание отправителя. Они предоставляют больше информации об отправителе

пакетов данных, чем случайным образом выбранный идентификатор источника

синхронизации. Кроме того, они помогают пользователю идентифицировать

потоки, относящиеся к различным сеансам.

Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг

и обратной связи с целью управления загруженностью, а также с целью

идентификации отправителя, все участники периодически посылают пакеты

RTCP. Частота передачи этих пакетов снижается с ростом числа участников.

При небольшом числе участников один пакет RTCP посылается максимум

каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому

участники ограничивают частоту RTCP-пакетов в зависимости от общего

числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5%

от общего трафика сеанса.

Формат заголовка протокола RTP

RTP — потоко -ориентированный протокол. Заголовок RTP-пакета создавался с

учетом потребностей передачи в реальном времени. Он содержит информацию о

порядке следования пакетов, чтобы поток данных был правильно собран на

принимающем конце, и временную метку для правильного чередования кадров

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

например, видео и аудио.

Каждый пакет RTP имеет основной заголовок, а также, возможно,

дополнительные поля, специфичные для приложения.

Использование TCP в качестве транспортного протокола для этих приложений

невозможно по нескольким причинам:

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

Другой широко используемый протокол транспортного уровня — LJDP не имеет

части ограничений TCP, но и он не предоставляет критической информации о

синхронизации.

Несмотря на то, что каждое приложение реального времени может иметь свои

собственные механизмы для поддержки передачи в реальном времени, они имеют

много общих черт, а это делает определение единого протокола весьма

желательным.

Эту задачу и призван решить новый транспортный протокол реального времени

— RTP (Real-time Transport Protocol), который гарантирует доставку данных

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

могут быть воспроизведены в реальном времени.

3.4 Протокол управления передачей RTCP

Протокол управления передачей RTCP (Real-Time Transport Control Protocol)

работает с несколькими адресатами для обеспечения обратной связи с

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

же самый базовый транспортный протокол, что и RTP (обычно, UDP), но другой

номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем

остальным участникам сеанса.

RTCP выполняет следующие функции:

• обеспечение качества услуг и обратной связи в случае перегрузки;
• идентификация отправителя;
• оценка размеров сеанса и масштабирование.

Многоадресность RTCP-пакетов дает возможность участникам группы оценить

качество приема и сообщить о своих проблемах (например, утере пакетов,

избыточной неравномерности передачи). Обратная связь с получателями важна

также для диагностики ошибок при распространении пакетов.

RTCP-пакеты содержат стандартное текстовое описание отправителя,

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

идентифицировать потоки, относящиеся к различным сеансам. Например, они

дают возможность определить, что одновременно открыты отдельные сеансы для

передачи аудио- и видеоинформации.

Оценка размера сеанса и масштабирование осуществляются управлением

частотой передачи RTCP-пакетов. При небольшом числе участников один

RTCP-пакет посылается максимум каждые 5 секунд. Цель состоит в том, чтобы

трафик RTCP не превышал 5% от общего трафика сеанса.

3.5 Протокол UDP

Протокол UDP намного проще, чем ТСР; он полезен в ситуациях, когда мощные механизмы обеспечения надежности протокола ТСР не обязательны. Заголовок UDP имеет всего четыре поля: поле порта источника (source port), поле порта пункта назначения (destination port), поле длины (length) и поле контрольной суммы UDP (checksum UDP). Поля порта источника и порта назначения выполняют те же функции, что и в заголовке ТСР. Поле длины обозначает длину заголовка UDP и данных; поле контрольной суммы обеспечивает проверку целостности пакета. Контрольная сумма UDP является факультативной возможностью.

Главным применением протокола UDP являются системы Internet Name Server, и Trivial File Transfer, SNMP.

Структура протокольного блока

Номера портов источника и получателя определяют прикладной процесс, инициировавший данное соединение. Закрепление номеров портов осуществляется в соответствии с Рекомендацией RFC-1700.

Мультиплексирование и демультиплексирование прикладных протоколов с помощью протокола UDP

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

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

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

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

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

3.6 Семиуровневая модель OSI

Модель OSI (Open System Interconnect Reference Model, Эталонная модель взаимодействия открытых систем) представляет собой универсальный стандарт на взаимодействие двух систем (компьютеров) через вычислительную сеть.

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

Страницы: 1, 2, 3, 4, 5, 6, 7