Мультиплексирование разнесенного TCP/IP трафика

Шифрование методом публичного ключа использует "public key" для шифрации и "private key" для дешифрации данных /5/.

5.2 Программа сетевого анализа netstat

Ядро операционной системы ведет разнообразную статистику об объектах, имеющих отношение к сети.

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

Хотя, netstat выдает информацию о разных типах сокетов, интерес представляют только соеты из адресных доменов inet(AF_INET). Это можно сделать при вызове netstst с опцией -f inet. По умолчанию сокеты, привязанные к адресу INADDR_ANY, не выводятся, но этот режим отключается опцией -a.

В данном случае, Proto - тип используемого протокола. Recv-Q, Send-Q-статистика сокета, Local Address, Foreign Address - адреса локальной, удаленной стороны. Слово LISTEN в колонке state означает, что сервер ждет запроса от клиента. Далее приведем вывод для сервера доменных имен, работающего на машине bsd:

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 localhost.domain *.* LISTEN

tcp 0 0 bsd.domain *.* LISTEN

udp 0 0 localhost.domain *.*

udp 0 0 localhost.domain *.*

При обращении к серверу эхо-контроля с помощью telnet появится соединение в состоянии ESTABLISHED (установлено):

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 localhost.7501 localhost.domain ESTABLISHED

tcp 0 0 localhost.domain localhost.7501 ESTABLISHED

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

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

5.3 Использование программы tcpdump

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

Пользовательская компонента tcpdump взаимодействует с компонентой в ядре при помощи библиотеки libpcap (для перехвата пакетов), взаимодействующей с пакетным фильтром BPF (BSD packet filter), которая абстрагирует системно-зависимые детали общения с канальным уровнем стека протоколов. Этот процесс изображен на рис. 5.1. Показано, как tcpdump считывает необработанные пакеты с помощью BPF, а также изображено еще одно приложение, читающее данные из стека TCP/IP. В случае вызова tcpdump без параметров, он перехватывает все пакеты и выводит информацию о них. Однако полезнее указать какой-нибудь фильтр, чтобы видеть только нужные пакеты и не отвлекаться на остальные.

Перехват пакетов с помощью BPF



Рис. 5.1

Для отражения всех пакетов, прошедших через сетевой интерфейс ed1 необходимо вызвать tcpdump с ключом -i ed1. А для сохранения сеанса в файл на диске используется выражение > tee имя-файла. tcpdump позволяет варировать настройками фильтра, позволяет получать данные внутри пакета, выводит разнообразную информацию /6/.

5.4 Программа исследования топологии сети traceroute

Утилита traceroute - это важный инструмент для нахождения ошибок маршрутизации, изучения трафика в Internet и исследования топологии сети /3/. Когда маршрутизатор получает датаграмму, у которой в поле TTL находится единица (или нуль), он отбрасывает ее и посылает отправителю ICMP-сообщение «истекло время в пути».

Программа traceroute использует это свойство. Сначала она посылает получателю UDP-датаграмму, в которой TTL установлено в единицу. Когда дата-грамма доходит до первого маршрутизатора, тот определяет, что поле TTL равно единице, отбрасывает датаграмму и посылает отправителю ICMP-сообщение. Так можно узнать адрес первого промежуточного узла (из поля «адрес отправителя» в заголовке ICMP). И traceroute пытается выяснить его имя с помощью функции gethostbyaddr. Чтобы получить информацию о втором узле, traceroute повторяет процедуру, на этот раз установив TTL равным двум и т.д.

Когда датаграмма с достаточно большим начальным значением TTL наконец доходит до получателя, TTL будет равно единице, но, поскольку дальше переправлять датаграмму некуда, стек TCP/IP попытается доставить ее ожидающему приложению. Однако traceroute установлено в качестве порта назначения такое значение, которое вряд ли кем-то используется, поэтому хост-получатель вернет ICMP-сообщение «порт недоступен». Получив такое сообщение, traceroute определяет, что конечный получатель обнаружен, и трассировку можно завершить.

Некоторые маршрутизаторы ошибочно переправляют далее датаграммы, в которых TTL равно нулю. Если такое происходит, то следующий маршрутизатор, например N + 1, отбросит датаграмму и вернет ICMP-сообщение «истекло время в пути» (рис.5.2). На дальнейшей итерации маршрутизатор N + 1 получит датаграмму со значением TTL, равным единице, и вернет обычное ICMP-сообщение. Таким образом, маршрутизатор N + 1 появится дважды: первый раз в результате ошибки предыдущего маршрутизатора, а второй - после корректного отбрасывания датаграммы с истекшим временем работы.

Схема работы программы traceroute



Рис.5.2

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

6. Описание системы мультиплексирования tcp/ip трафика, запуск, мониторинг, контроль работы

6.1 Принцип работы системы

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

1) c физической точки зрения перехват (доступ к каналам связи) всех частей текста затруднителен;

2) представляет сложность восстановление исходного текста без какой-либо его части.

На рис. 6.1, представлена одна из структур сети, где этот принцип может быть использован.

Структура сети с резервированием

Рис. 6.1

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

На рис.6.1 можно выделить два очевидных маршрута. В первом случае часть потока направляется от демультиплексора через router1 к антенне 1, далее, по спутниковому каналу, через спутник 1 и Антенну 2, происходит дальнейшая трансляция router-ом 3 в Передатчик 1. Там пакеты, обрабатываются и снова отправляются через Router 3, но уже в радиоканал Антена3 - Спутник2 - Антена4, достигая шлюза (router2) и мультиплексора. В. Вторым путем передачи можно считать цепочку Демультиплексор-Router1-Router4-Передатчик2-Router4-Router2-Мультиплексор. Таким способом трафик разбивается по двум различным маршрутам. Система работает на прокладном уровне пользуясь услугами транспортного и нижними уровнями TCP/IP, а именно (TCP, IP, протоколами канального уровня). Это означает полное отсутствие привязки к протоколам верхнего уровня, так как программы системы сами представляют собой приложения высоких уровней. На (рис.6.2) показано взаимодействие системы со стеком протокола ТCP/IP.

Взаимодействие системы со стеком протокола TCP/IP

Рис 6.2

Данные приложения на демультиплексоре разбиваются (демультиплексируются) на две части, в соответствии с алгоритмом работы программы, передавая каждую часть своему TCP приложению. Каждое из TCP приложений, совместно с TCP приложением на соответствующем передатчике заботится о надежной доставке передаваемых данных от демультиплексора к передатчику. После обработки данных на уровне TCP пакеты передаются уровню IP. В заголовке полученного IP - пакета в поле отправитель стоит IP-адрес демультиплексора, а в поле получатель - IP адрес передатчика. Система Router-ов занимается маршрутизацией IP - пакета в сети опираясь на адрес получателя, и таблицу маршрутизации. На передатчике данные пройдя стек TCP и IP попадают в приложение, которое снова посылает их в сеть, но уже в другое TCP/IP соединение (от передатчика к мультиплексору). В мультиплексоре приложение собирает (мультиплексирует) исходный текст из двух TCP/IP соединений "зная" правило (коэффициенты) мультиплексирования. Любое из приложений не заботится о правильности доставки данных, опираясь на TCP. Таким образом на рис. 6.2 установлено 4 TCP/IP соединения, два между демультиплексором к передатчиками и два между передатчиками и мультиплексором.

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

В силу сказанного можно объяснить необходимость присутствия Передатчиков 1 и 2. Так как, работая на уровнях ниже 3-го, мы не можем оперировать прохождением пакетов через те или иные устройства, в силу недоступности и невозможности изменения правил маршрутизации, то остается способ выделения виртуального канала на основе промежуточных пунктов прохождения трафика. Таким образом, можно принудительно задавать пункты, выстраивая их в цепь. В качестве таких пунктов и работают передатчики. Исходя из плотности расположения передатчиков, можно так же рассуждать о возможном пути следования пакетов. Если от пункта А до пункта Б в каждом сетевом узле будет находиться передатчик, то путь трафика однозначно определен как показано на рис 6.3, и поток от A до C пройдет строго через пункт B.

Прохождение трафика через промежуточный пункт

Рис. 6.3

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

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

Это аналогично тому, что при использовании маршрутизации 3-го уровня (ip), ничего нельзя говорить о mac - адресах начального и конечного пунктов передачи данных.

Значения полей (отправителя и адресата) в заголовках пакетов разных уровней и их изменения при прохождении участков сети показаны на рис.6.4.

Заголовки пакетов разных уровней

Рис. 6.4

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

В последней строке показана цепь установленных tcp/ip соединений. Вертикальными стрелками показаны правила изменения полей в пакетах нижнего уровня на основе заголовков в пакете верхнего.

Так, например mac адрес в Ethernet пакете изменяется на основе ip - адреса в ip пакете и на основе таблицы маршрутизации.

Если рассматривать изменение ip -адреса при прохождении данных по цепочке от демультиплексора к мультиплексору, то оно осуществляется благодаря трансляции потока передатчиком из одного tcp/ip соединения в другое (маршрутизация на сеансовом уровне).

С точки зрения сетевых устройств элементы данной системы имеют вид, показанный на рис. 6.5 (стрелки - направление передачи данных, пунктирные стрелки - направление установления соединения).

Демультиплексор - сервер.

Первое что он делает, принимает соединения от передатчиков.

Сетевая архитектура системы

Рис. 6.5

После установления двух соединений начинается процесс передачи и демультиплексирования. Из буфера стандартного входа (STDIN), считывается часть потока данных, согласно коэффициентам мультиплексирования, и посылается в первый установленный сокет. После этого снова происходит считывание части потока, но данные уже посылаются во второй сокет, и т.д. Исполнение программы происходит, до получения сигнала SIGINT (прерывание от терминала), после чего все сокеты переходят в состояние TIME-WAIT, и работа завершается. Мультиплексор, как и демультиплексор - сервер, но его отличие в том, что он читает из сокетов фрагменты соответствующей длины, и помещает их в буфер стандартного выхода (STDOUT). Во многом другом, их принципы схожи. Передатчик совмещает в себе совокупность из двух клиентских частей, каждая из которых подключается к соответствующему серверу, образуя пару сокетов. После успешного установления соединений происходит считывание байта из входящего сокета (от демультиплексора) и его запись в исходящий сокет (мультиплексору). Разумеется, запуск передатчиков-клиентов производиться после запуска серверов (мультиплексора и демультиплексора).

Данная схема мультиплексирования представлена на рис. 6.6.

Мультиплексирование с задаными коэффициентами

Рис. 6.6

6.2 Листинги программ и их описание

Листинги программ написаны на языке Си, под операционную систему FreeBSD, все используемые функции описаны в разделе 4. Модули, используемые в программах, являются стандартными Unix - библиотеками. Блок-схемы функционирования приведены на рис.П.1.

6.2.1 Листинг программы "Демультиплексор"

Серверная часть строится в соответствии с п.4.2, рис.4.2. Ее основная задача принять два соединения от клиентов-передатчиков, образовав пару TCP/IP - соединений. Демультиплексорная часть занимается непосредственно считыванием данных из буфера STDIN и разнесения их, т.е. записи в TCP/IP соединения, в соответствии с коэффициентами мультиплексирования m и n. Листинг программы имеет вид:

/* подключение используемых библиотек*/

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <stdio.h>

int main(void) {

/* Определение используемых в программе переменных */

struct sockaddr_in local, localj;

int s;

int m,m1,n,n1;

int s1, s1j;

int rc;

char buf[1], bufj[1];

char xr[1];

/* Серверная часть */

local.sin_family = AF_INET; /* заполняем структуру sockaddr_in*/

local.sin_port = htons (7501); /*локальный порт 7501*/

local.sin_addr.s_addr = htonl(INADDR_ANY); /*интерфейс-любой*/

n=1; /* коэффициенты мультиплексирования*/

m=1;

s=socket (AF_INET, SOCK_STREAM, 0); /*получаем тип сокета*/

if ( s < 0) /*SOCK_STREAM - TCP*/

{

perror ("errror Socket visov");

exit (1);

}

rc = bind (s, (struct sockaddr *)&local, sizeof (local)); /*привязываем сокет *//* к локальному адресу*/

if ( rc < 0)

{

perror ("errror Bindt visov");

exit (1);

}

rc = listen( s, 5); /*помечаем сокет как прослушивающий*/

if (rc)

{

perror ("errror Listen visov");

exit (1);

}

s1=accept (s, NULL, NULL); /*принимаем соединение 1*/

printf("S1-OK\n");

if (s1<0)

{

perror ("errror Accept visov");

exit (1);

}

s1j=accept (s, NULL, NULL); /*принимаем соединение 2*/

printf("S2-OK\n");

if (s1j<0)

{

perror ("errror Accept visov");

exit (1);

}

/*оба соединения установлены*/

printf("!!!\n");

while (1) {

/* конец серверной части */

/* Начало раздела "Демультиплексорная часть" */

n1=0;

while (n1<n) {

scanf("%c", buf); /*считываем n символов из STDIN*/

if ((*buf) != '\n') { /*игнорируя символ \n (перевод строки) */

rc=send (s1, buf, 1, 0); /*посылаем в 1-й сокет*/

if (rc<0) {

perror ("error send visov");

exit(1); };

n1++;

};

while (m1<m) {

scanf("%c", buf); /*считываем n символов из STDIN*/

if ((*buf) != '\n') { /*игнорируя символ \n (перевод строки) */

rc=send (s1j, buf, 1, 0); /*посылаем во 2-й сокет*/

if (rc<0) {

perror ("error send visov");

exit(1); };

m1++;

} ;

/* Конец раздела "Демультиплексорная часть" */

};

exit(0);

}

6.2.2 Листинг программы "Мультиплексор"

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

Мультиплексорная часть занимается считыванием данных из двух TCP/IP соединений, мультиплексированием (объединением) полученных частей текста в одну в соответствии с коэффициентами n и m, и выводом результата в STDOUT (стандартный вывод - дисплей).

Листинг программы имеет вид:

/* подключение используемых библиотек*/

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <stdio.h>

int main(void)

{

/* Определение используемых в программе переменных */

struct sockaddr_in local, localj;

int s;

int s1, s1j;

int m1,m,n1,n;

int rc;

char buf[1], bufj[1];

char xr[1];

/* Серверная часть */

local.sin_family = AF_INET;

local.sin_port = htons (7501);

local.sin_addr.s_addr = htonl(INADDR_ANY);

n=1;

m=1;

s=socket (AF_INET, SOCK_STREAM, 0);

if ( s < 0)

{

perror ("errror Socket visov");

exit (1);

}

rc = bind (s, (struct sockaddr *)&local, sizeof (local));

if ( rc < 0)

{

perror ("errror Bind visov");

exit (1);

}

rc = listen( s, 5);

if (rc)

{

perror ("errror Listen visov");

exit (1);

}

s1=accept (s, NULL, NULL);

printf("S1-OK\n");

if (s1<0)

{

perror ("errror Accept visov");

exit (1);

}

s1j=accept (s, NULL, NULL);

printf("S2-OK\n");

if (s1j<0)

{

perror ("errror Accept visov");

exit (1);

}

/* соединения установлены */

printf("!!!\n");

/* конец серверной части */

while (1) {

/* Начало раздела "Мультиплексорная часть" */

for (n1=0; n1<n; n1++) { /*считываем n символов из 1-го сокета*/

rc=recv(s1,buf,1,0);

if (rc<0)

{

perror ("errror recv");

exit (1);

}

printf ("1 | %c\n", buf[0]); /*посылаем их в STDOUT*/

}

for (m1=0; m1<m; m1++) { /* считываем m символов из второго сокета*/

rc=recv(s1j,buf,1,0);

if (rc<0)

{

perror ("errror recv");

exit (1);

}

printf ("2 | %c\n", buf[0]); /*посылаем в STDOUT*/

}

};

/* Конец раздела "Мультиплексорная часть" */

exit(0);

}

6.2.3 Листинг программы "Передатчик"

Раздел "клиентская часть" построен по схеме п.4.1, рис.4.1., ее основная цель явиться инициатором подключений к серверам "мультиплексор" и "демультиплексор". После успешного исполнения раздела "клиентская часть" управление передается разделу "передатчик". Он читает символ из одного TCP/IP - соединения (с демультиплексором), и записывает его в другое TCP/IP - соединение (с мультиплексором).

Листинг программы имеет вид:

/* подключение используемых библиотек*/

#include <sys/types.h> /* используемые библиотеки*/

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <stdio.h>

int main(void)

{

/* Определение используемых в программе переменных */

struct sockaddr_in peer, peer1;

int s, s1;

int rc, rc1;

char buf[1];

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

peer.sin_family = AF_INET;

peer.sin_port = htons(7501); /* порт демультиплексора*/

peer.sin_addr.s_addr=inet_addr("192.168.20.1"); /* адрес демультиплексора*/

s=socket( AF_INET, SOCK_STREAM, 0); /* получаем TCP - сокет демультиплексора */

if (s < 0)

{

perror("Error of socket visov");

exit(1);

}

rc=connect(s, (struct sockaddr *)&peer, sizeof(peer)); /*подключаемся к демультиплексору*/

if (rc)

{

perror ("error of connect");

exit (1);

}

printf("Split Station Found. Connect!\n");

peer1.sin_family = AF_INET;

peer1.sin_port = htons(7501); /*порт мультиплексора*/

peer1.sin_addr.s_addr=inet_addr("192.168.20.2"); /*адрес мультиплексора*/

s1=socket( AF_INET, SOCK_STREAM, 0); /* получаем TCP - сокет мультиплексора */

if (s1 < 0)

{

perror("Error of socket visov");

exit(1);

}

rc1=connect(s1, (struct sockaddr *)&peer1, sizeof(peer1)); /* присоединяемся к мультиплексору*/

if (rc1)

{

perror ("error of connect");

exit (1);

}

printf("Combine Station Found. Connect!\n");

printf("!!!\n");

/* оба соединения установлены*/

/* конец клиентской части */

while (1) {

/* Начало раздела "Передатчик" */

rc=recv(s, buf, 1, 0); /* читаем байт из сокета демультиплексора */

if (rc<0)

{

perror ("error of recv");

exit (1);

}

printf("%с\n",buf); /* отображаем его на экране */

rc=send(s1, buf, 1, 0); /* записываем в сокет мультиплексора */

if (rc<0)

{

perror ("error of send");

exit (1);

}

/* конец раздела "Передатчик" */

}

}

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

Пусть имеется сеть, в которой вероятность доступа к одному каналу (А) - достаточно велика, а к другому каналу (B) - мала.

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

Схема шифровки текста на стороне демультиплексора.

Данные предназначенные для передачи по сети в демультиплексоре демультиплексируется побайтно на две части с коэффициентами 1:1. Одна часть полученного текста маскируется (операция сложения по модулю 2) другой частью, после чего полученная последовательность посылается в канал А. В канал В посылается любая из частей полученных после демультиплексирования. Таким образом, в канал А посылается как бы "шифрованный" текст, а в канал В, как бы "шифр" к тексту А, но этот "шифр", так же как и "расшифрованный" текст А, является частью исходного текста.

Пример:

Необходимо передать сообщение "система безопасности". После демультиплексирования имеем два сообщения: "ссеабзпсот" и "итм еоанси".

В кодировке windows=1251 шестнадцатеричные коды символов соответственно следующие "E1 E1 A5 A0 A1 A7 AF E1 AE E2" и "A8 E2 AC 20 A5 AE A0 AD E1 A8".

После сложения по модулю два этих шестнадцатеричных последовательностей получим последовательность "49 03 09 80 04 09 0F 4C 4F 4A" или в кодах символов "C§>b_>"^a\". Полученная последовательность посылается в канал А. А любая из последовательностей "ссеабзпсот" или "итм еоанси" посылается в канал В.

Процесс восстановления исходного текста на стороне мультиплексора таков. Текст из канала А маскируется текстом из канала В. Это дает возможность получить исходную комбинацию, маскированную В на стороне демультиплексора. Полученный текст мультиплексируется (чередованием байт) с коэффициентами 1:1 c текстом канала В, восстанавливая исходную последовательность переданную по сети.

Пример: получили две последовательности "C§>b_>"^a\" и "итм еоанси". Сложив их побайтно по модулю 2 получим последовательность "ссеабзпсот". Имея "ссеабзпсот" и "итм еоанси", мультиплексируем их, восстанавливая сообщение "система безопасности". Схема мультиплексирования с маскированием канала представлена на рис 6.7.

Мультиплексирование с маскированием канала

Рис. 6.7

В листинге программы "Демультиплексор" раздел "Демультиплексорная часть" заменяется следующим фрагментом C-кода:

/* Начало раздела "Демультиплексорная часть " */

n=1;

n1=0;

while (n1<n) {

scanf ("%c", buf); /* считываем из STDIN символ */

if ((*buf) != '\n') { /* игнорируя \n (возврат строки) */

n1++;

}

}

m=1;

m1=0;

while (m1<m) {

scanf("%c", bufj); /* считываем из STDIN второй символ */

if ((*bufj) !='\n') { /* игнорируя \n (возврат строки) */

m1++;

}

}

(*xr)=(*buf)^(*bufj); /* маскируем первый символ вторым */

printf ("1 | %c | %c \n", buf[0], xr[0]); /* выводим кодированный символ */

printf ("2 | %c\n", bufj[0]); /* выводим маскирующий символ */

rc=send(s1, xr, 1, 0); /* посылаем кодированный символ в первое TCP/IP соединение */

if (rc<0) { perror ("error send visov"); /*проверка ошибки вызова send */

exit(1); }

rc=send(s1j, bufj, 1, 0); /* посылаем маскирующий символ во второе TCP/IP соединение */

if (rc<0) { perror ("error send visov"); /* проверка ошибки */

exit(1);

}

/* конец раздела "Демультиплексорная часть" */

В листинге программы "Мультиплексор" раздел "Мультиплексорная часть" заменяется следующим фрагментом C-кода.

rc=recv(s1, xr, 1, 0); /* читаем из первого TCP/IP соединения кодированный символ */

if (rc<0)

{

perror("error recv"); /* проверка ошибки */

error(1);

}

rc=recv(s1j, bufj, 1, 0); /* читаем из второго соединения маскирующий символ */

if (rc<0)

{

perror("error recv");

error(1);

}

(*buf)=(*xr)^(*bufj); /* расшифровываем кодированный символ */

printf("1 | %с | %c\n", xr[0], buf[0]); /* выводим расшифрованный символ*/

printf("2 | %c\n", bufj[0]); /* выводим маскирующий символ*/

6.4 Сравнение системы мультиплексирования с протоколом socks

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

Протокол socks представляет собой установленное tcp/ip соединение между socks-клинтом и socks-сервером, а уже socks-сервер устанавливает соединение с серверами протоколов верхних уровней (http, ftp, pop3 и т.д.). Описываемая система мультиплексирования не несет как таковой функции посредника (proxy), в отличие от socks, но так же как и proxy, позволяет скрывать глобальные ip-адреса конечных пунктов. Так же система мультиплексирования организует пару tcp/ip соединений на сторонах мультиплексора и демультиплексора. Отличие данной системы от socks еще и в том, что данные подвергаются соответствующей обработке после чего одна их часть посылается в один сокет, а другая - в другой. Основная функция socks - тунеллирование протоколов верхних уровней. В данной системе значения клиента и сервера, играют роль скорее с точки зрения сетевого взаимодействия, в socks направление соединения, а следовательно и их функции определяются протоколами верхних уровней.

6.5 Запуск и мониторинг системы

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

На рис.6.8 изображена схема мониторинга и запуска системы мультиплексирования.

Схема запуска и мониторинга системы



Рис. 6.8

На хостах мультиплексор, демультиплексор, передатчик 1 и передатчик 2, работающих по системой Unix, установлены серверы OpenSSH. На хосте, с которого происходит управление, запущены четыре процесса-SSH-клиента (putty - для Windows или ssh - для Unix). Каждый из них подключается к соответствующим серверам, выступая в роли “зеркала” удаленного терминала. Все операции будут проводиться только на управляющем компьютере.

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

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 *.7501 *.* LISTEN

Здесь тип используемого протокола - TCP, Local Address - *.7501 означает, что это может быть любой интерфейс и номер порта 7501. Удаленный адрес - любой адрес и порт удаленного приложения (*.*). Слово LISTEN - сервер ждет запросов на соединение от клиента.

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

tcp 0 0 raz.7501 trans1.1024 STABLISHED

Следует обратить внимание на изменения после подключения. Соединение образованное четырьмя параметрами (локальные хост (raz) и порт 7501, и удаленные хост (trans1) и его порт 1024) находится в состоянии ESTABLISHED (установлено).

После того, как сервера запущены можно запускать клиенты-передатчики. После запуска первого передатчика, случае успеха выводится сообщение на серверах вида "S1-OK", после запуска второго передатчика - "S2-OK", и "!!!". Сообщение "!!!" означает что оба соединения установлены, и серверу больше нет необходимости принимать подключения. На каждом из передатчиков в случае соединения выводятся сообщения вида " Split Station Found. Connect!" (Демультиплексор найден, успешное подключение!), "Combine Station Found. Connect!" (Мультиплексор найден, успешное подключение!) и сообщение "!!!" (все подключения прошли успешно).

В выводе программы netstat на передатчиках будет строка, отражающая соединения с серверами вида:

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp 0 0 trans1.1024 raz.7501 ESTABLISHED

tcp 0 0 trans1.1025 sob.7501 ESTABLISHED

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

Таким образом, raz-демультиплексор, sob-мультиплексор, trans1 и trans2 - передатчики. Схема их подключений и значения сокетов (адрес и порт) на каждом из них показаны на рис. 6.9.

Схема подключений и значения сокетов



Рис. 6.9

Работа системы происходит следующим образом:

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

1 | a

Это сообщение означает, что в первый сокет послан символ a.

Если на "демультиплексоре" вводится последовательность "программа", с коэффициентами мультиплексирования 1:1, то на экране появятся следующие строки:

1 | п

2 | р

1 | о

2 | г

1 | р

2 | а

1 | м

2 | м

1 | а

На передатчике 1 отобразится сообщение "порма", на передатчике 2 сообщение "ргам".

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

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

1 | s | g

2 | o

где, "g"-кодируемый символ, "s" -(закодированный маской "o" символ "g"), посылаемый в канал 1.

"o" - символ (маска для "s"), посылаемый в канал 2.

На стороне мультиплексора данные строки примут вид:

1 | s | g

2 | o

"s" - принятый символ из 1-го канала.

"o" - символ принятый из 2-го канала

"g" - символ, раскодированный из "s" с помощью маски "o".

Таким образом и в демультиплексоре и в мультиплексоре, читая последний столбец сверху вниз, получаем исходное сообщение.

6.6 Листинги и описания tcp-сессий, полученных с помощью tcpdump

На каждом из хостов запущена программа tcpdump, и все соединения установлены. Значения сокетов соответствуют рис 5.6. В ходе отправки с демультиплексора последовательности "qwerty" получены следующие образы tcp - сессий.

На Демультиплексоре:

Первые три строки - трехстороннее квитирование (SYN, ACK+SYN, ACK). Инициатор соединения trans1 (передатчик1).

Следующие три строки - трехстороннее квитирование. Инициатор - trans2 (передатчик 2).

Далее показан - сеанс передачи пакетов raz>trans от демультиплексора (raz) к передатчикам (trans). От передатчиков trans>raz строки подтверждения приема ack демультиплексором.

Сессия имеет вид:

22:58:48.250218 trans1.1024 > raz.7501: S 3900350886:3900350886(0) win 65535 <mss 16344> (DF)

22:58:48.250379 raz.7501 > trans1.1024: S 3634649525:3634649525(0) ack 3900350887 win 65535 <mss 16344>

22:58:48.250420 trans1.1024 > raz.7501: . ack 1 win 65535 (DF)

22:59:11.697439 trans2.1026 > raz.7501: S 1407604832:1407604832(0) win 65535 <mss 16344> (DF)

22:59:11.697514 raz.7501 > trans2.1026: S 1611546978:1611546978(0) ack 1407604833 win 65535 <mss 16344>

22:59:11.697558 trans2.1026 > raz.7501: . ack 1 win 65535 (DF)

22:59:23.935844 raz.7501 > trans1.1024: P 1:2(1) ack 1 win 65535 (DF)

22:59:23.936132 raz.7501 > trans2.1026: P 1:2(1) ack 1 win 65535 (DF)

22:59:24.031638 trans1.1024 > raz.7501: . ack 2 win 65534 (DF)

22:59:24.031674 raz.7501 > trans1.1024: P 2:6(4) ack 1 win 65535 (DF)

22:59:24.031712 trans2.1026 > raz.7501: . ack 2 win 65534 (DF)

22:59:24.031725 raz.7501 > trans2.1026: P 2:6(4) ack 1 win 65535 (DF)

22:59:24.131633 trans1.1024 > raz.7501: . ack 6 win 65530 (DF)

22:59:24.131665 trans2.1026 > raz.7501: . ack 6 win 65530 (DF)

На мультиплексоре:

Здесь вывод tcpdump аналогичен выводу на демультиплексоре, но в данном случае значения сокетов уже другие, и передача ведется от передатчиков (trans>sob) в сторону мультиплексора (sob), a мультиплексор отправляет положительные квитанции ack (sob>trans), при получении пакетов.

Сессия имеет вид:

22:58:48.251577 trans1.1025 > sob.7501: S 2600980707:2600980707(0) win 65535 <mss 16344> (DF)

22:58:48.251666 sob.7501 > trans1.1025: S 382763383:382763383(0) ack 2600980708 win 65535 <mss 16344>

22:58:48.251694 trans1.1025 > sob.7501: . ack 1 win 65535 (DF)

22:59:11.698520 trans2.1027 > sob.7501: S 140910856:140910856(0) win 65535 <mss 16344> (DF)

22:59:11.698558 sob.7501 > trans2.1027: S 861879306:861879306(0) ack 140910857 win 65535 <mss 16344>

22:59:11.698581 trans2.1027 > sob.7501: . ack 1 win 65535 (DF)

22:59:23.936055 trans1.1025 > sob.7501: P 1:2(1) ack 1 win 65535 (DF)

22:59:23.936288 trans2.1027 > sob.7501: P 1:2(1) ack 1 win 65535 (DF)

22:59:24.031694 sob.7501 > trans1.1025: . ack 2 win 65534 (DF)

22:59:24.031738 sob.7501 > trans2.1027: . ack 2 win 65534 (DF)

22:59:24.031861 trans1.1025 > sob.7501: P 2:3(1) ack 1 win 65535 (DF)

22:59:24.031985 trans2.1027 > sob.7501: P 2:3(1) ack 1 win 65535 (DF)

22:59:24.131681 sob.7501 > trans1.1025: . ack 3 win 65533 (DF)

22:59:24.131694 trans1.1025 > sob.7501: P 3:6(3) ack 1 win 65535 (DF)

22:59:24.131711 sob.7501 > trans2.1027: . ack 3 win 65533 (DF)

22:59:24.131724 trans2.1027 > sob.7501: P 3:6(3) ack 1 win 65535 (DF)

22:59:24.231634 sob.7501 > trans1.1025: . ack 6 win 65530 (DF)

22:59:24.231659 sob.7501 > trans2.1027: . ack 6 win 65530 (DF)

На передатчике 1:

Первые шесть строк - установление соединений передатчика 1 с демультиплексором (trans1>raz), и мультиплексором (trans1>sob). Инициатор - сам передатчик 1. Далее идет сеанс связи, демультиплексор отправляет пакеты (raz>trans1), передатчик подтверждает ack (trans1>raz), затем, передатчик отправляет мультиплексору (trans1>sob), мультиплексор подтверждает ack принятые данные (sob>trans1).

Сессия имеет вид:

22:58:48.250218 trans1.1024 > raz.7501: S 3900350886:3900350886(0) win 65535 <mss 16344> (DF)

22:58:48.250379 raz.7501 > trans1.1024: S 3634649525:3634649525(0) ack 3900350887 win 65535 <mss 16344>

22:58:48.250420 trans1.1024 > raz.7501: . ack 1 win 65535 (DF)

22:58:48.251577 trans1.1025 > sob.7501: S 2600980707:2600980707(0) win 65535 <mss 16344> (DF)

22:58:48.251666 sob.7501 > trans1.1025: S 382763383:382763383(0) ack 2600980708 win 65535 <mss 16344>

22:58:48.251694 trans1.1025 > sob.7501: . ack 1 win 65535 (DF)

22:59:23.935844 raz.7501 > trans1.1024: P 1:2(1) ack 1 win 65535 (DF)

22:59:23.936055 trans1.1025 > sob.7501: P 1:2(1) ack 1 win 65535 (DF)

22:59:24.031638 trans1.1024 > raz.7501: . ack 2 win 65534 (DF)

22:59:24.031674 raz.7501 > trans1.1024: P 2:6(4) ack 1 win 65535 (DF)

22:59:24.031694 sob.7501 > trans1.1025: . ack 2 win 65534 (DF)

22:59:24.031861 trans1.1025 > sob.7501: P 2:3(1) ack 1 win 65535 (DF)

22:59:24.131633 trans1.1024 > raz.7501: . ack 6 win 65530 (DF)

22:59:24.131681 sob.7501 > trans1.1025: . ack 3 win 65533 (DF)

22:59:24.131694 trans1.1025 > sob.7501: P 3:6(3) ack 1 win 65535 (DF)

22:59:24.231634 sob.7501 > trans1.1025: . ack 6 win 65530 (DF)

На передатчике 2:

Вывод tcpdump на стороне передатчика2, аналогичен выводу на передатчике 1, но вместо trans1, используется имя trans2.

Сессия имеет вид:

22:59:11.697439 trans2.1026 > raz.7501: S 1407604832:1407604832(0) win 65535 <mss 16344> (DF)

22:59:11.697514 raz.7501 > trans2.1026: S 1611546978:1611546978(0) ack 1407604833 win 65535 <mss 16344>

22:59:11.697558 trans2.1026 > raz.7501: . ack 1 win 65535 (DF)

22:59:11.698520 trans2.1027 > sob.7501: S 140910856:140910856(0) win 65535 <mss 16344> (DF)

22:59:11.698558 sob.7501 > trans2.1027: S 861879306:861879306(0) ack 140910857 win 65535 <mss 16344>

22:59:11.698581 trans2.1027 > sob.7501: . ack 1 win 65535 (DF)

22:59:23.936132 raz.7501 > trans2.1026: P 1:2(1) ack 1 win 65535 (DF)

22:59:23.936288 trans2.1027 > sob.7501: P 1:2(1) ack 1 win 65535 (DF)

22:59:24.031712 trans2.1026 > raz.7501: . ack 2 win 65534 (DF)

22:59:24.031725 raz.7501 > trans2.1026: P 2:6(4) ack 1 win 65535 (DF)

22:59:24.031738 sob.7501 > trans2.1027: . ack 2 win 65534 (DF)

22:59:24.031985 trans2.1027 > sob.7501: P 2:3(1) ack 1 win 65535 (DF)

22:59:24.131665 trans2.1026 > raz.7501: . ack 6 win 65530 (DF)

22:59:24.131711 sob.7501 > trans2.1027: . ack 3 win 65533 (DF)

22:59:24.131724 trans2.1027 > sob.7501: P 3:6(3) ack 1 win 65535 (DF)

22:59:24.231659 sob.7501 > trans2.1027: . ack 6 win 65530 (DF)

6.7 Детальный контроль маршрута прохождения трафика

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

Программа traceroute пытается определить маршрут между двумя хостами в сети, заставляя каждый промежуточный маршрутизатор посылать ICMP-сообщение об ошибке хосту-отправителю. Сначала нужно несколько раз запустить программу и посмотреть, что она выдает. Проследим маршрут между хостом 195.161.21.211 (dual-up клиент сервера удаленного доступа компании Коммед г.Омск) с которого запускается программа, и web-сервером компании Транстелеком (www.transtelecom.ru ).

Число слева в каждой строке - это номер промежуточного узла. За ним идет имя хоста или маршрутизатора в этом узле и далее - IP-адрес узла. Имя разрешается через адрес с помощью обратной службы DNS. Если узнать имя не удается, то traceroute печатает только IP-адрес. Такая ситуация наблюдается в узлах 12 и 17. Как видно, по умолчанию программа пыталась определить имя хоста или маршрутизатора трижды, а три числа, следующие за IP-адресом, - это периоды кругового обращения (RTT) для каждой из трех попыток. Если при очередной попытке на запрос никто не отвечает или ответ теряется, то вместо времени печатается «*».

Компьютер www.transtelecom.ru расположен в Москве и в Internet, до него 17 узлов. Сначала данные проходят через два маршрутизатора компании “Коммед”, потом еще через два маршрутизатора отдела “ТУСМ” г.Омска, а затем через маршрутизатор 207.106.20.45, попадает в сеть “Ростелеком”, и через города Новосибирск, Екатеринбург, Самара, попадает в Москву. Там, через крупного интегратора “telia” данные попадают в сеть компании “transtelecom”. И наконец, на шаге 17 маршрут подходит к компьютеру www.transtelecom.ru.

Вывод traceroute имеет вид:

1 r23-L0.commed.ru (195.161.21.94) 150.871 ms 142.906 ms 131.963 ms

2 r26-E0.commed.ru (195.161.21.116) 132.810 ms 133.664 ms 137.269 ms

3 tusm2-E1.omsk.ru (195.161.21.129) 171.606 ms 167.801 ms 158.824 ms

4 TUSM2-1.risp.ru (192.188.187.249) 161.164 ms 163.826 ms 163.534 ms

5 217.106.20.45 (217.106.20.45) 168.675 ms 173.645 ms 166.628 ms

6 bb-pos2-7-155M.Novosibirsk.Rostelecom.ru (195.161.2.89) 219.546 ms 168.251 ms 161.200 ms

7 bb-pos2-0-155M.Ekaterinburg.Rostelecom.ru (213.24.141.205) 191.923 ms 180.756 ms 178.627 ms

8 bb-pos1-1-155M.Samara.Rostelecom.ru (213.59.1.97) 199.892 ms 196.166 ms 189.254 ms

9 gsr-pos1-0-155M.Moscow.Rostelecom.ru (195.161.2.113) 226.834 ms 210.213 ms 217.987 ms

10 bgw2-giga4-0-0.Moscow.Rostelecom.ru (195.161.0.2) 219.439 ms 213.286 ms 210.761 ms

11 s-fre-i1-pos4-2.telia.net (193.45.36.201) 237.923 ms 229.481 ms 240.064 ms

12 193.45.129.5 (193.45.129.5) 235.952 ms 243.059 ms 227.270 ms

13 sto-b1-pos10-0.telia.net (213.248.66.57) 227.432 ms 234.065 ms 241.939 ms

14 teleross-01080-s-b1.c.telia.net (213.248.67.78) 264.093 ms 250.376 ms 253.656 ms 240.455 ms 243.059 ms

15 ccr-0.Moscow.ST.net (194.67.16.232) 258.448 ms

16 transtelecom-gw.Moscow.ST.NET (195.239.13.126) 262.856 ms 260.879 ms 261.286 ms

17 195.218.193.13 (195.218.193.13) 265.186 ms 269.078 ms 258.675 ms

6.8 Мультиплексирование с определенными коэффициентами по n каналам

Пусть поток I мультиплексируется на n каналов, с определенными коэффициентами, причем, вероятности доступа к каждому из них p1,p2,p3,p4...pn. Условие полной вероятности раскрытия информации имеет вид Ai=pi*f(ni,k), где ni - коэффициент мультиплексирования для i-го канала. ni, с другой стороны можно найти используя формулу ni=ai/a1+a2+a3+...+ai+...+an, где ai - величина части сообщения посылаемой в канал i, а a1+a2+a3+...+ai+...+an - величина исходного (полного) сообщения. Можно провести балансировку общих вероятностей раскрытия сообщения для каналов по условию A=A1=A2=A3=...An.

Функция f(ni,k) - вероятность (сложность) раскрытия сообщения по фрагменту исходного текста зависит от k, где k-коэффициент избыточности, причем, чем больше избыточность, тем больше f(ni,k).

Для уменьшения избыточности текста (повышения энтропии) можно применять архивацию данных, например по Лемпелю-Зиву.

7. Экономическое обоснование. Определение цены программы

7.1 Затраты на оплату труда, отчисления на социальное страхование

Для определения затрат на основную заработную плату рассчитывается трудоемкость всех видов работ: исследовательских, проектных, конструкторских, связанных с разработкой и отладкой программы. В зависимости от масштабов работ, трудоемкость измеряется в человеко-месяцах, человеко-днях или человеко-часах (нормо-ч). Определение вышеперечисленных расходов производится методом прямого расчёта.

Расчет трудоемкости произведём отдельно для каждого вида работ и по исполнителям с учетом условий производства. Результаты расчета приведены в таблице 7.1.

Таблица 7.1 Трудоемкость работ

Наименование работ	Категория работников	Общая трудоемкость, чел.-дни
	Научный рук.	Инженер-программист
1	2	3	4
Разработка и получение технического задания	3	3	6
Разработка структурной схемы работы программного обеспечения	2	10	12
Разработка алгоритма функционирования программного обеспечения	3	5	8
Написание программного обеспечения	5	10	15
Отладка программного обеспечения	4	6	10
Итого:	17	34	51

Чтобы перевести трудоемкость из человеко-дней в человеко-месяцы, необходимо разделить эту величину на число рабочих дней в месяце,час:

, (7.1)

где Fp - фонд рабочего времени в месяце,167час.;

tсм - продолжительность рабочего дня,8 час.

Dр мес = 21час.

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

Dр Научный руководитель =0,809 чел-мес.

Dр Инженер-программист = 1,62 чел-мес.

Кроме оплаты по тарифу, в фонд основной заработной платы включаются премии производственным категориям работников и доплаты по районному коэффициенту, составляющие соответственно 3 % и 15 % к тарифной ставке. Расчет фонда основной заработной платы приведен в таблице 7.2.

Таблица 7.2 Фонд основной заработной платы

Наимен. категории работников	Dp, чел-мес.	Должностной оклад, руб.	Премии, руб.	Доплаты по районному коэффициенту, руб.	Месячный ФЗП одного работника, руб.	ФЗП на весь объем работ, руб.
Научный руководитель	0,809	3000,00	90,00	463,50	3553,50	2874,8
Инженер-программист	1,62	1900,00	57,00	293,55	2250,55	3645,9
Итого:		6520,7

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

, (7.2)

где 305 - количество рабочих дней в году при шестидневной рабочей неделе;

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

Здесь tотп=24+1, т.е. продолжительность очередного отпуска равна 25 дням. Рассчитаем Кдоп:

Кдоп=8,93 %.

Величина дополнительной заработной платы равна,руб:

, (7.3)

Сз доп= 582,29 руб.

Общий фонд заработной платы составляет,руб:

, (7.4)

Сз=7120,988 руб.

Тесно связаны с общим фондом заработной платы затраты отчислений на социальное страхование, которые принимаются в размере 35,8 % от общего фонда заработной платы.

Сосс=2549,314руб.

7.2 Расходы по содержанию и эксплуатации оборудования

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

В связи с тем, что компьютер находится в эксплуатации более 5 лет, то в связи с постановлением правительства РФ от 01.01.02 №1 «О классификации основных средств, включаемых в амортизационные группы», общая сумма расходов на амортизацию составляет 20% от стоимости компьютера.

, (7.5)

Сам = 1974,00 руб.

Общий расход электроэнергии:

, (7.6)

где Рai - суммарная мощность компьютера и монитора, Вт;

Fgi - действительный фонд времени работы оборудования, ч;

i = 0,7 - коэффициент загрузки оборудования во времени;

Цi - цена за единицу энергии, руб.

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

Цена 1 кВт*ч электроэнергии - 0,72 руб.

Cэ= 12,1 руб.

Расходы по содержанию и эксплуатации оборудования,руб:

, (7.7)

Собор= 1986,10 руб.

7.3 Себестоимость устройства управления

Уровень цены зависит от издержек производства нормально работающего предприятия (себестоимости) и нормативной прибыли:

, (7.8)

где Кпр -величина плановых накоплений в долях единицы;

Кпр=15 %. Результаты расчета по статьям затрат приведены в таблице 7.7.

Таблица 7.7 Себестоимость устройства управления

№	Наименование статьи затрат	Сумма затрат, руб.
1	2	3
1.	Общий фонд заработной платы	7120,988
2.	Отчисления на социальные страхования	2549,314
3.	Расходы на содержание и эксплуатацию оборудования	1986,10
Итого полная себестоимость:	11656,402

Ц=13404,862руб.

Расчетная цена проектируемого устройства управления составляет: 13404,87 рублей.

8. Обеспечение безопасности при работе с видеодисплейными терминалами

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

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

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

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

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

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

Требования к временным режимам работы:

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

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

3) требования к организации диалога формируются из максимальной естественности взаимодействия пользователя с программным средством, определяется параметрами: доступность, время реакции на ответ, число вариантов ответов в вопросах типа “Меню”;

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

5) достаточное рабочее пространство (исключающее или сокращающее время пребывания в неудобных рабочих позах);

6) оптимальное расположение рабочего места и безопасные проходы;

7) учитывается потребность в обзоре, конфигурация панелей индикации.

8.2 Использование жидкокристаллической матрицы как дисплейного устройства ЭВМ

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

Одна из главных особенностей LCD-эргономика. Какой бы современный CRT монитор Не был установлен, он излучает. При столкновении электрона с поверхностью возникает рентгеновское излучение. Другим, вредным недостатком является мерцание изображения. Это связано с технологией формирования изображения на экране. Современные мониторы позволяют работать на частоте от 75 Гц, что является минимальным для спокойной работы за компьютером. В совокупности электромагнитное и рентгеновское излучение, мерцание изображения оказывают очень вредное воздействие - быстро утомляется зрение и создается нервное напряжение. При продолжительной каждодневной работе за CRT монитором практически у всех пользователей в той или иной степени снижается острота зрения, а у некоторых появляются головные боли, ухудшается общее самочувствие, возникает нервное перенапряжение, которое может привести даже к нервному расстройству.