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

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

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

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

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

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

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

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

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

Идентификация отправителя. Пакеты 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.

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

|Байты |Разряды |

| |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 |

| | | | |0 |

|0 |Порт источника |Порт получателя |

|4 |Длина протокольного блока |Проверочная сумма |

|8 . . |Данные |

Номера портов источника и получателя определяют прикладной процесс,

инициировавший данное соединение. Закрепление номеров портов осуществляется

в соответствии с Рекомендацией RFC-1700.

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

протокола UDP

Протокол UDP ведет для каждого порта две очереди: очередь пакетов,

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

портом в сеть.

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

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

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

набором высокоуровневых сервисов, идентифицированных номерами портов,

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

[pic]

Хотя к услугам протокола UDP может обратиться любое приложение, многие

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

транспортного уровня TCP. Дело в том, что протокол UDP выступает простым

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

TCP, не берет на себя никаких функций по обеспечению надежности передачи.

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

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

С другой стороны, функциональная простота протокола UDP обуславливает

простоту его алгоритма, компактность и высокое быстродействие. Поэтому те

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

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

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

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

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

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

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

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

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

Модель OSI (Open System Interconnect Reference Model, Эталонная модель

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

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

Эта модель описывает функции семи иерархических уровней и интерфейсы

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

который он предоставляет вышестоящему уровню, и протоколом - набором правил

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

работающих на разных компьютерах.

Идея состоит в том, что вся сложная процедура сетевого взаимодействия

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

выполняющихся объектами, соотнесенными с уровнями модели. Модель построена

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

сообщаются непосредственно друг с другом с помощью соответствующих

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

выполняют. Задача объектов - предоставить через стандартизованный интерфейс

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

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

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

находящемуся на другом компьютере. Через стандартизованный интерфейс

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

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

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

ни один из процессов не знает и не имеет необходимости знать, как именно

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

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

они движутся.

Эти процессы, с другой стороны, могут находиться не на самом верхнем

уровне модели. Предположим, что они через стандартный интерфейс

взаимодействуют с приложениями вышестоящего уровня и их задача

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

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

друг другу. При этом сущность этих данных и их интерпретация для

рассматриваемых процессов совершенно не важны.

Возможна также взаимозаменяемость объектов одного уровня (например,

при изменении способа реализации сервиса) таким образом, что объект

вышестоящего уровня не заметит подмены.

Вернемся к примеру: приложения не знают о том, что их данные

преобразуются именно путем фрагментации/сборки, им достаточно знать то, что

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

данных. Если же для какой-то другой сети понадобится не фрагментация/сборка

пакетов, а, скажем, перестановка местами четных и нечетных бит, то процессы

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

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

действия нижележащих уровней скрыты от них.

Объекты, выполняющие функции уровней, могут быть реализованы в

программном, программно-аппаратном или аппаратном виде. Как правило, чем

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

Организация сетевого взаимодействия компьютеров, построенного на

основе иерархических уровней, как описано выше, часто называется

протокольным стеком.

Уровни модели OSI

Ниже перечислены (в направлении сверху вниз) уровни модели OSI и

указаны их общие функции.

. Уровень приложения (Application) - интерфейс с прикладными процессами.

. Уровень представления (Presentation) - согласование представления

(форматов, кодировок) данных прикладных процессов.

. Сеансовый уровень (Session) - установление, поддержка и закрытие

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

. Транспортный уровень (Transport) - обеспечение безошибочного сквозного

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

. Сетевой уровень (Network) - фрагментация и сборка передаваемых

транспортным уровнем данных, маршрутизация и продвижение их по сети от

компьютера-отправителя к компьютеру-получателю.

. Канальный уровень (Data Link) - управление каналом передачи данных,

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

обнаружение ошибок в канале и их коррекция.

. Физический уровень (Physical) - физический интерфейс с каналом

передачи данных, представление данных в виде физических сигналов и их

кодирование (модуляция).

Модель OSI предложена достаточно давно, однако протоколы, на ней

основанные, используются редко, во-первых, в силу своей не всегда

оправданной сложности, во-вторых , из-за существования хотя и не

соответствующих строго модели OSI, но уже хорошо зарекомендовавших себя

стеков протоколов (например, TCP/IP).

Поэтому модель OSI стоит рассматривать, в основном, как опорную базу

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

Стек протоколов TCP/IP

TCP/IP - собирательное название для набора (стека) сетевых протоколов

разных уровней, используемых в Интернет. Особенности TCP/IP:

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

аппаратного обеспечения;

независимость от физической среды передачи;

система уникальной адресации;

стандартизованные протоколы высокого уровня для распространенных

пользовательских сервисов.

[pic]

Рис. 4. Стек протоколов TCP/IP

Стек протоколов TCP/IP делится на 4 уровня: прикладной (application),

транспортный (transport), межсетевой (internet) и уровень доступа к среде

передачи (network access). Термины, применяемые для обозначения блока

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

транспортного уровня - TCP и UDP, поэтому на рисунке 6 изображено два

стека. Как и в модели OSI, данные более верхних уровней инкапсулируются в

пакеты нижних уровней (см. рис. 5). [pic]

Рис. 5. Пример инкапсуляции пакетов в стеке TCP/IP

Примерное соотношение уровней стеков OSI и TCP/IP показано на рис. 6.

[pic]

Рис. 6. Соотношение уровней стеков OSI и TCP/IP

Ниже кратко рассматриваются функции каждого уровня и примеры

протоколов. Программа, реализующая функции того или иного протокола, часто

называется модулем, например, “IP-модуль”, “модуль TCP”.

Уровень приложений

Приложения, работающие со стеком TCP/IP, могут также выполнять функции

уровней представления и частично сеансового модели OSI; например,

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

передачи и т.п.

Распространенными примерами приложений являются программы telnet, ftp,

HTTP-серверы и клиенты (WWW-броузеры), программы работы с электронной

почтой.

Для пересылки данных другому приложению, приложение обращается к тому

или иному модулю транспортного уровня.

Транспортный уровень

Протоколы транспортного уровня обеспечивают прозрачную (сквозную)

доставку данных (end-to-end delivery service) между двумя прикладными

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

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

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

получателя на транспортном уровне выполняет номер порта (или проще - порт).

Анализируя заголовок своего пакета, полученного от межсетевого уровня,

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

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

соответствующему прикладному процессу (возможно, после проверки их на

наличие ошибок и т.п.). Номера портов получателя и отправителя записываются

в заголовок транспортным модулем, отправляющим данные; заголовок

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

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

На транспортном уровне работают два основных протокола: UDP и TCP.

TCP (Transmission Control Protocol - протокол контроля передачи) -

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

сеансом связи (устанавливает, поддерживает и закрывает соединение) между

процессами и обеспечивает надежную (безошибочную и гарантированную)

доставку прикладных данных от процесса к процессу.

Данными для TCP является не интерпретируемая протоколом

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

частям. Каждая часть передается в отдельном TCP-сегменте. Для продвижения

сегмента по сети между компьютером-отправителем и компьютером-получателем

модуль TCP пользуется сервисом межсетевого уровня (вызывает модуль IP).

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

услугами TCP.

Протокол UDP

UDP (User Datagram Protocol, протокол пользовательских дейтаграмм)

фактически не выполняет каких-либо особых функций дополнительно к функциям

межсетевого уровня (протокола IP). Протокол UDP используется либо при

пересылке коротких сообщений, когда накладные расходы на установление

сеанса и проверку успешной доставки данных оказываются выше расходов на

повторную (в случае неудачи) пересылку сообщения, либо в том случае, когда

сама организация процесса-приложения обеспечивает установление соединения и

проверку доставки пакетов (например, NFS).

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

предваряются UDP-заголовком, и сформированный таким образом UDP-пакет

отправляется на межсетевой уровень.

UDP-заголовок состоит из двух 32-битных слов:

[pic]

Значения полей:

. Source Port - номер порта процесса-отправителя.

. Destination Port - номер порта процесса-получателя.

. Length - длина UDP-пакета вместе с заголовком в октетах.

. Checksum - контрольная сумма. Контрольная сумма вычисляется таким же

образом, как и в TCP-заголовке ; если UDP-пакет имеет нечетную длину,

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

После заголовка непосредственно следуют пользовательские данные,

переданные модулю UDP прикладным уровнем за один вызов. Протокол UDP

рассматривает эти данные как целостное сообщение; он никогда не разбивает

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

сообщений для пересылки в одном пакете. Если прикладной процесс N раз

вызвал модуль UDP для отправки данных (т.е. запросил отправку N сообщений),

то модулем UDP будет сформировано и отправлено N пакетов, и процесс-

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

сообщений.

При получении пакета от межсетевого уровня модуль UDP проверяет

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

номер порта указан в поле “Destination Port”.

Если проверка контрольной суммы выявила ошибку или если процесса,

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

пакеты поступают быстрее, чем модуль UDP успевает их обрабатывать, то

поступающие пакеты также игнорируются. Протокол UDP не имеет никаких

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

не обеспечивает приход сообщений в порядке отправки, не производит

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

поэтому он является ненадежным протоколом без установления соединения. Если

приложение нуждается в подобного рода услугах, оно должно использовать на

транспортном уровне протокол TCP.

Максимальная длина UDP-сообщения равна максимальной длине IP-

дейтаграммы (65535 октетов) за вычетом минимального IP-заголовка (20) и UDP-

заголовка (8), т.е. 65507 октетов. На практике обычно используются

сообщения длиной 8192 октета.

Примеры прикладных процессов, использующих протокол UDP: NFS (Network

File System - сетевая файловая система), TFTP (Trivial File Transfer

Protocol - простой протокол передачи файлов), SNMP (Simple Network

Management Protocol - простой протокол управления сетью), DNS (Domain Name

Service - доменная служба имен).

Межсетевой уровень и протокол IP

Основным протоколом этого уровня является протокол IP (Internet

Protocol).

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

одного IP-адреса к другому. IP-адрес является уникальным 32-битным

идентификатором компьютера (точнее, его сетевого интерфейса). Данные для

дейтаграммы передаются IP-модулю транспортным уровнем. IP-модуль предваряет

эти данные заголовком, содержащим IP-адреса отправителя и получателя и

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

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

физических интерфейсов) для отправки по каналу передачи данных.

Не все компьютеры могут непосредственно связаться друг с другом; часто

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

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

маршруту. Задача определения маршрута для каждой дейтаграммы решается

протоколом IP.

Когда модуль IP получает дейтаграмму с нижнего уровня, он проверяет IP-

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

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

конкретно - указано в заголовке дейтаграммы). Если же адрес назначения

дейтаграммы - чужой, то модуль IP может принять два решения: первое -

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

определив маршрут следования - так поступают промежуточные станции -

маршрутизаторы.

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

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

единое целое на компьютере-получателе. Это тоже задача протокола IP.

Если модуль IP по какой-либо причине не может доставить дейтаграмму,

она уничтожается. При этом модуль IP может отправить компьютеру-источнику

этой дейтаграммы уведомление об ошибке; такие уведомления отправляются с

помощью протокола ICMP, являющегося неотъемлемой частью модуля IP. Более

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

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

установления соединения между компьютерами протокол IP не имеет. Эта задача

возложена на транспортный уровень.

Многие IP-адреса имеют эквивалентную форму записи в виде доменного

имени (например, IP-адрес 194.84.124.4 может быть записан как

maria.vvsu.ru). Преобразование между этими двумя формами выполняется

службой DNS (Domain Name Service). Доменные имена обсуждаются в курсе

“Введение в Интернет”, служба DNS рассматривается в курсе “Технологии

Интернет”. Доменные имена введены для удобства использования человеком. Все

TCP/IP-процессы и коммуникационное оборудование используют только IP-

адреса.

Протоколы IP и ICMP подробно рассмотрены в главе 2.

Уровень доступа к среде передачи

Функции этого уровня: отображение IP-адресов в физические адреса сети

(MAC-адреса, например, Ethernet-адрес в случае сети Ethernet). Эту функцию

выполняет протокол ARP;

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

извлечение дейтаграмм из кадров. При этом не требуется какого-либо контроля

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

TCP/IP такой контроль возложен на транспортный уровень или на само

приложение. В заголовке кадров указывается точка доступа к сервису (SAP,

Service Access Point) - поле, содержащее код протокола межсетевого уровня,

которому следует передать содержимое кадра (в нашем случае это протокол

IP);

определение метода доступа к среде передачи - то есть способа, с помощью

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

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

коллизий и т.п.).

. определение представления данных в физической среде;

. пересылка и прием кадра.

Стек TCP/IP не подразумевает использования каких-либо определенных

протоколов уровня доступа к среде передачи и физических сред передачи

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

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

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

передается дейтаграмма, в MAC-адрес. Часто в качестве уровня доступа к

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

IP поверх ATM, IP поверх IPX, IP поверх X.25 и т.п.

ЧАСТЬ II Электронная коммерция.

Термин "электронная торговля"

1. Общие понятия об «Е-Коммерции»

Электронный бизнес: повышение эффективности бизнеса, основанное на

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

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

добавленной стоимости. Понятие "электронный бизнес" шире понятия

"электронная коммерция", касающегося только коммерческой деятельности,

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

заказчиками.

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

аренду, предоставление лицензий, поставка товаров, услуг или информации с

использованием компьютерных сетей или Интернета. Понятие "электронная

коммерция" шире, чем "коммерция в Интернете", поскольку в него входят все

виды электронной коммерческой деятельности.

Интернет-коммерция, торговля в Интернете: коммерческая деятельность в

Интернете, когда процесс покупки/продажи товаров или услуг (весь цикл

коммерческой/финансовой транзакции или ее часть) осуществляется электронным

образом с применением Интернет-технологий.

Существует два класса систем для электронной коммерции: - "Бизнес-

Бизнес" (Business-to-Business - B2B) и "Бизнес-Потребитель" (Business-to-

Customer - B2C). К системам В2С относятся:

. web-витрина - оформленный web-дизайновскими средствами прайс-

лист торговой компании, не содержащий бизнес-логики торгового

процесса;

. Интернет-магазин, содержит кроме web-витрины всю необходимую

бизнес логику для управления процессом Интернет-торговли (бэк-

офис).

. Торговая Интернет-система (ТИС), которая представляет собой

Интернет-магазин, бэк-офис которого полностью (в режиме

реального времени) интегрирован в торговый бизнес-процесс

компании.

Интернет-торговля - только часть электронной коммерции, но очень бурно

развивающаяся часть. Торговые операции через Интернет могут осуществлять

многие организации - и производители товаров/услуг, и дистрибьюторы, и

розничные торговые компании.

Из известных трех типов систем Интернет-торговли: (web-витрины, Интернет-

магазины и ТИС), в России практически нет ТИС, очень мало Интернет-

магазинов, зато огромное количество web-витрин. Чем привлекательны и

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

С точки зрения покупателя все три решения выглядят одинаково. Связано

это с тем, что покупатель имеет дело с внешним оформлением любой системы, а

это всегда web-каталог, система навигации и система оформления заказов.

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

использования web-каталога и системы навигации.

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

преимуществах Интернет-магазинов и ТИС. Преимущества эти проявляются в том,

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

счет с учетом стоимости доставки и страховки. Кроме того, он сможет увидеть

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

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

компаний, которые предоставят лучшие цены и хороший сервис. Именно на этих

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

клиентуры Интернет-торговцы.

С точки зрения продавцов эти три решения различаются весьма

значительно. Web-витрина обходится торговым компаниям недорого, но:

. web-витрина позволяет организовать только торговлю на заказ,

наладить торговлю с реального склада практически невозможно;

. ее использование не уменьшает затраты продавцов на содержание

штата и операционные расходы;

. web-витрина представляет собой очень неповоротливое решение с

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

организации маркетинговых акций;

. имидж компании, открывшей и поддерживающей простую web-витрину

всегда хуже, чем у компании, организовавшей Интернет-торговлю

при помощи полнофункционального Интернет-магазина или ТИС. Но

самое главное, организация Интернет-торговли при помощи web-

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

часто нерентабельным делом.

Интернет-магазин существенно более выгоден торговой компании (особенно

среднего бизнеса), которая хочет реально управлять всем процессом Интернет-

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

склада, уменьшить число менеджеров по продажам и т.д. На создание Интернет-

магазина потребуется больше разовых затрат по сравнению с витриной, но они

будут намного более эффективными, поскольку использование Интернет-

магазинов существенно рентабельнее по обороту, чем использование web-

витрин. При этом существует реальная альтернатива самостоятельному созданию

громоздкого Интернет-магазина - аренда решения у специализированной

компании. В этом случае большие разовые (и часто непроизводительные)

затраты равномерно распределяются во времени.

2. Успехи Интернет – Торговли 2002 года.

Интернет-торговля пошла в гору

Первый квартал этого года был очень удачным для В2С-сектора, считает

исследовательская компания comScore Networks. По сравнению с аналогичным

периодом прошлого года онлайновые продажи за первые три месяца выросли на

50%, достигнув отметки в $17 млрд. и побив даже рекордные для прошлого года

показатели четвертого, рождественско-новогоднего периода на 8%. И это - не

считая оборотов интернет-аукционов. Более того, весь 2002 год обещает стать

весьма доходным для интернет-бизнеса.

Особенно впечатляющих результатов добился туристический бизнес,

переживавший в 4-м квартале спад из-за терактов в США, у многих отбивших

желание путешествовать. Однако в первом квартале ситуация кардинально

изменилась - по сравнению с аналогичным периодом прошлого года продажи в

данном секторе подскочили на 87%, а с четвертым кварталом - на 39%,

достигнув цифры в $6,98 млрд.

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

их долю пришлось $2,4 млрд., что на 44% выше показателей первого квартала

прошлого года, но на 11% ниже, чем в праздничном 4-м квартале. Продажи

программного обеспечения повысились на 12%, до $236 млн., это произошло за

счет роста интереса к антивирусному и бухгалтерскому ПО. Продажи

канцтоваров достигли $1,7 млрд., что на 35% выше, чем в первом квартале

прошлого года и на 56% больше, чем в 4-м квартале. Столь существенный рост

объясняется большими закупками канцтоваров школьниками и офисными

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

спортивных товаров также резко выросли - на 145% по сравнению с аналогичным

периодом прошлого года и достигли показателя в $250 млн. Неплохой доход

принесли продажи видео, подскочившие на 45% по сравнению с первым кварталом

прошлого года и на 3% - с праздничным периодом, и достигшие $234 млн.

Правда, успех сопутствовал не всем интернет-магазинам. Разочарование

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

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

продажи книг упали на 5%, до $557 млн. Онлайновые продажи музыки снизились

до $230 млн., в то время как в праздничный период они были на уровне $1,3

млрд. Снижение оборотов торговли в данных секторах объясняется тем фактом,

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

период, а сейчас их сезон миновал.

Другая исследовательская компания - BizRate - также представила свои

данные, освещающие положение в В2С-секторе в первом квартале текущего года.

BizRate осуществляет мониторинг рынка В2С в США на основе данных, собранных

в ходе опросов клиентов 2000 американских онлайновых магазинов. Данные,

полученные компанией, свидетельствуют о том, что число онлайновых

транзакций, совершенных на рынке США в январе-марте 2002 г., составило

91,47 млн. по сравнению с 68,29 млн. транзакций в первом квартале 2001 г.

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

составив в первом квартале 2002 г. $127 по сравнению с $120 за аналогичный

период 2001 г.

Год, столь удачно начавшийся, обещает быть и дальше весьма

благополучным для интернет-торговли. BizRate объявила о пересмотре прогноза

развития американского В2С-рынка на 2002 г. в сторону увеличения. Ранее

ожидаемый объем совокупных продаж в $45,20 млрд. был пересмотрен до $51,48

млрд. Таким образом, рост розничного сектора электронной коммерции, по

оценкам BizRate, в 2002 г. составит не 26%, а 44%. По итогам прошлого года

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

интернет на рынке США, составила $35,87 млрд.

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

показателей, ожидания BizRate относительно рынка В2С остаются одними из

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

скромные цифры по совокупной выручке компаний в 2002 г. ($39,3 млрд.)

представлены только Jupiter MMX. Прогнозы других аналитических агентств, в

частности, Forrester Research, eMarketer, GartnerG2 и IDC, гораздо более

оптимистичны и составляют $74,0 млрд., $75,0 млрд., $91,9 млрд. и $116,8

млрд. соответственно.

3. Преимущества электронной коммерции

Если розничные электронные магазины для российского рынка это все еще

экзотика, то преимущества ведения деловых операций через Интернет многие

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

экономического кризиса и связано с преимуществами, которые получит фирма

после применения интернет-технологий.

Имеется множество преимуществ, вот лишь некоторые из них:

. значительно увеличивается оперативность получения информации, особенно

при международных операциях;

. значительно сокращается цикл производства и продажи, т.к. больше нет

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

снижается вероятность возникновения ошибок ввода;

. значительно снижаются затраты, связанные с обменом информацией за счет

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

. использование интернет-технологий электронной коммерции позволяет

компании стать более открытой по отношению к клиентам;

. позволяет легко и быстро информировать партнеров и клиентов о

продуктах и услугах;

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

электронный магазин на корпоративном сайте.

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