ДОМАШНИЙ ШЛЮЗ И СПОСОБ АНАЛИЗА ОНЛАЙН-ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЯ И МОНИТОРИНГА КАЧЕСТВА СЕТЕВЫХ УСЛУГ

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

Область техники

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

Уровень техники

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

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

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

СУТЬ ИЗОБРЕТЕНИЯ

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

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

А10 - сбор онлайн-данных о пользователе, а именно: анализ пакета данных, поступающего в домашний шлюз, согласно характеристикам объекта, подлежащего мониторингу, и генерирование соответствующего CSV-файла онлайн-поведения согласно проанализированным данным, а также пересылка файла на FTP-сервер.

А20 - мониторинг качества сетевых услуг, а именно: периодическое моделирование, посредством домашнего шлюза, кодового вызова по РРРОЕ, активная инициация определения доступности услуг TCP, DNS, HTTP и FTP, генерирование соответствующего CSV-файла качества сетевых услуг согласно результату определения и пересылка файла на FTP-сервер.

А30 - анализ CSV-файла онлайн-поведения и CSV-файла качества сетевых услуг для получения результатов, касающихся онлайн-поведения пользователя и качества сетевых услуг.

В вышеприведенном решении, на этапе А10 и этапе А20, CSV-файл онлайн-поведения и CSV-файл качества сетевых услуг пересылаются на конкретный FTP-сервер согласно циклу пересылки, обеспечиваемому интегральной терминальной системой управления.

В вышеприведенном решении, на этапе А30, статистический анализ осуществляется посредством WEB-клиента.

В вышеприведенном решении, на этапе А10, точка ловушки устанавливается в NF_PREROUTING_HOOK в оболочке Netfilter ядра Linux домашнего шлюза, пакет данных анализируется в функции ловушки согласно характеристикам объектов, подлежащих мониторингу, достоверная информация пересылается на уровень приложений с помощью средства передачи данных Netlink, и уровень приложений в дальнейшем сортирует достоверную информацию для получения результата, касающегося онлайн-поведения пользователя.

В вышеприведенном решении процесс анализа пакета данных в домашнем шлюзе является следующим.

А101 - анализ IP-адреса, порта и протокола пакета данных в точке ловушки в NF_PREROUTING_HOOK в оболочке Netfilter, когда пакет данных проходит сквозь ядро Linux.

А102 - определение, является ли протокол пакета данных IPPROTO_TCP; если да, процесс переходит к А103, тогда как в противном случае процесс переходит к А104.

А103 - выполнение анализа QQ для определения, является ли порт назначения 80; если да, процесс переходит к А105, тогда как в противном случае процесс переходит к А106.

А104 - определение, является ли пакет данных IPPROTO_ICMP; если да, добавляют 1 к числу пакетов icmp, тогда как в противном случае процесс переходит к А116.

А105 - выполнение анализа протокола HTTP.

А106 - определение, является ли порт назначения 25; если да, процесс переходит к А107, в противном случае процесс переходит к А108.

А107 - анализ отправленной почты.

А108 - определение, является ли порт назначения 110; если да, процесс переходит к А109, тогда как в противном случае процесс переходит к А110.

А109 - анализ полученной почты.

А110 - определение, является ли порт назначения 1863; если да, процесс переходит к A111, тогда как в противном случае процесс переходит к А112;

A111 - анализ входа в MSN.

А112 - определение, является ли порт назначения 1863; если да, процесс переходит к А113, тогда как в противном случае процесс переходит к А114;

А113 - анализ выхода из MSN.

А114 - определение, является ли порт назначения 16000; если да, процесс переходит к А115, тогда как в противном случае процесс возвращается к А102 для анализа следующего пакета данных.

A115 - анализ AliWangWang.

A116 - определение, является ли протокол пакета данных IPPROTO_UDP; если да, процесс переходит к А117, тогда как в противном случае процесс возвращается к А102 для анализа следующего пакета данных.

А117 - осуществление анализа QQ.

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

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

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

В вышеприведенном решении качество сетевых услуг включает временную задержку, джиттер, уровень потери пакетов, а также доступность услуг HTTP/FTP.

В вышеприведенном решении мониторинг качества сетевых услуг включает следующие этапы.

А201 - получение номера SN, адреса ping-сервера, адреса назначения DNS, адреса FTP-сервера, имени пользователя, пароля и другой информации об устройстве шлюза путем считывания конфигурационного файла config.

А202 - создание дочернего потока net_monitor.

А203 - осуществление этапа А204, если дочерний поток net_monitor успешно создан, тогда как в противном случае осуществление этапа А205.

А204 - выполнение дочернего потока net_monitor, установление последовательности цикла таймера в дочернем потоке net_monitor для выполнения следующих тестов: получение основной информации о пользователе, ping-тест адреса назначения, тест доступности FTP-сервера, тест доступности HTTP-сервера, тест временной задержки DNS и джиттера.

А205 - мониторинг дочернего потока net_monitor.

А206 - определение, нормально ли существует дочерний поток net_monitor; если да, процесс переходит к А202, тогда как в противном случае происходит завершение мониторинга качества сетевых услуг.

В вышеприведенном решении, на этапе А10 и этапе А20, согласно периодам пересылки при различных интервалах в конфигурационном файле сгенерированные CSV-файл онлайн-поведения и CSV-файл качества сетевых услуг пересылаются на конкретный FTP-сервер в пакетном режиме, при этом соответствующие CSV-файл онлайн-поведения и CSV-файл качества сетевых услуг в шлюзе удаляются.

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

Когда домашний шлюз запускается, интегрированная терминальная система управления сначала считывает значение величины срабатывания, относящееся к онлайн-поведению пользователя, в конфигурационном файле beh.conf, при этом, если значение величины срабатывания равно 0, какая-либо обработка не осуществляется; в противном случае определяется, существуют ли одновременно процесс сбора онлайн-данных о пользователе collect_data и процесс мониторинга качества сетевых услуг net_monitor, при этом, если да, оба процесса сначала прерываются, а затем возобновляются для входа в процедуру, которую осуществляет домашний шлюз; в противном случае, если не существует ни collect_data, ни net_monitor, оба процесса запускаются; если существует один из collect_data и net_monitor, процесс, который существует, прерывается и запускается другой процесс; принимается сигнал, посланный активным процессом, и выполняется функция обработки сигнала.

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

Согласно настоящему изобретению также обеспечивается домашний шлюз, и домашний шлюз содержит модуль сбора онлайн-данных о пользователе и модуль мониторинга качества сетевых услуг. Модуль сбора онлайн-данных о пользователе осуществляет анализ пакета данных, поступающего в домашний шлюз, согласно характеристикам объекта, подлежащего мониторингу, и генерирует соответствующий CSV-файл онлайн-поведения согласно проанализированным данным, а также пересылает файл на FTP-сервер; модуль мониторинга качества сетевых услуг периодически моделирует кодовый вызов по РРРОЕ, активно инициирует определение доступности услуг TCP, DNS, HTTP и FTP, генерирует соответствующий CSV-файл качества сетевых услуг согласно результату определения и пересылает файл на FTP-сервер.

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

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ:

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

фиг. 2 представляет собой схему последовательности процесса сбора онлайн-данных о пользователе согласно настоящему изобретению;

фиг. 3 представляет собой схему последовательности процесса анализа протокола HTTP согласно настоящему изобретению;

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

фиг. 5 представляет собой схему осуществления сбора основной информации о пользователе согласно настоящему изобретению;

фиг. 6 представляет собой схему реализации доступности услуг HTTP согласно настоящему изобретению;

фиг. 7 представляет собой схему последовательности процесса реализации уровня достижения временной задержки DNS согласно настоящему изобретению;

фиг. 8 представляет собой схему взаимодействия домашнего шлюза с системой управления домашним шлюзом, если шлюз запускается, согласно настоящему изобретению; и

фиг. 9 представляет собой схему взаимодействия домашнего шлюза с системой управления домашним шлюзом, если шлюз работает, согласно настоящему изобретению.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

А10 - сбор онлайн-данных о пользователе, а именно: анализ пакета данных, поступающего в домашний шлюз, согласно характеристикам объекта, подлежащего мониторингу (в том числе разнообразного программного обеспечения для мгновенного обмена сообщениями и игрового программного обеспечения), генерирование соответствующего CSV-файла онлайн-поведения согласно проанализированным данным в соответствии с определенным форматом и пересылка файла на FTP-сервер.

А20 - мониторинг качества сетевых услуг, а именно: периодическое моделирование, посредством домашнего шлюза, кодового вызова по РРРОЕ, активное инициирование определения доступности услуг TCP, DNS, HTTP и FTP, генерирование соответствующего CSV-файла качества сетевых услуг согласно результату определения и пересылка файла на FTP-сервер.

А30 - анализ CSV-файла онлайн-поведения и CSV-файла качества сетевых услуг для получения результатов, касающихся онлайн-поведения пользователя и качества сетевых услуг.

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

(1) Сбор онлайн-данных о пользователе

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

Сбор онлайн-данных о пользователе осуществляется путем установки точки ловушки в оболочке Netfilter ядра Linux, при этом пакет данных поступает в точку ловушки, то есть входит в функцию ловушки, пакеты данных различных типов, подлежащие мониторингу, анализируются в функции ловушки для получения фактической информации о мониторинге, достоверная информация направляется на уровень приложений с помощью средства передачи данных Netlink, и уровень приложений в дальнейшем фильтрует эту информацию для получения данных, которыми интересуется пользователь, генерирует соответствующий CSV-файл онлайн-поведения и пересылает файл на FTP-сервер. Суть сбора онлайн-данных о пользователя, в основном, заключается в следующем:

(a) запись всех URL, доступных пользователю, и времени, анализ протоколов HTTP (доменное имя верхнего уровня и полностью определенное имя домена), извлечение информации HTTP, включающей: поисковый механизм (Google, Baidu, Youdao и тому подобное) и ключевые слова под поисковыми механизмами и доменами веб-сайтов потребления (ALI, taobao и тому подобное);

(b) анализ почты, полученной и отправленной почтовым клиентом, извлечение почтовой информации, такой как получатели, отправители и темы; и

(c) анализ приложений, таких как QQ, MSN, AliWangWang и Feixin, и извлечение информации о приложениях, такой как название приложения и время доступа.

Процесс анализа пакета данных в домашнем шлюзе представлен следующими этапами.

А101 - анализ IP-адреса, порта и протокола пакета данных в точке ловушки в NF_PREROUTING_HOOK в оболочке Netfilter, когда пакет данных проходит сквозь ядро Linux.

А102 - определение, является ли протокол пакета данных IPPROTO_TCP; если да, процесс переходит к А103, тогда как в противном случае процесс переходит к А104.

А103 - выполнение анализа QQ для определения, является ли порт назначения distport 80, если да, процесс переходит к А105, тогда как в противном случае процесс переходит к А106.

А104 - определение, является ли пакет данных IPPROTO_ICMP; если да, выполнить icmppkg++ (добавление 1 к числу пакетов icmp), тогда как в противном случае процесс переходит к А116.

А105 - выполнение анализа протокола HTTP (процесс анализа является таким, как показано на фиг. 3).

А106 - определение, является ли порт назначения distport 25; если да, процесс переходит к А107, в противном случае процесс переходит к А108.

А107 - анализ отправленной почты.

А108 - определение, является ли порт источника srcport 110; если да, процесс переходит к А109, в противном случае процесс переходит к А110.

А109 - анализ полученной почты.

А110 - определение, является ли порт источника srcport 1863; если да, процесс переходит к A111, тогда как в противном случае процесс переходит к А112.

A111 - анализ входа в MSN.

А112 - определение, является ли порт назначения distport 1863; если да, процесс переходит к А113, тогда как в противном случае процесс переходит к А114.

А113 - анализ выхода из MSN.

А114 - определение, является ли порт назначения distport 16000; если да, процесс переходит к А115, тогда как в противном случае процесс возвращается к А102 для анализа следующего пакета данных.

А115 - анализ AliWangWang.

А116 - определение, является ли протокол пакета данных IPPROTO_UDP; если да, процесс переходит к А117, тогда как в противном случае процесс возвращается к А102 для анализа следующего пакета данных.

А117 - осуществление анализа QQ.

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

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

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

Как показано на фиг. 3, процесс анализа протокола HTTP содержит следующие этапы.

А1051 - определение, содержит ли пакет данных GET; процесс переходит к А1052, если да, тогда как в противном случае процесс переходит к А1055.

А1052 - определение, является ли полученная ссылка обычным URL; если да, процесс переходит к А1053, тогда как в противном случае процесс переходит к А1055.

А1053 - определение, содержит ли пакет данных HOST; процесс переходит к А1052, если да, тогда как в противном случае процесс переходит к А1055.

А1054 - указание того, что протокол не является протоколом HTTP, и возврат к 0.

А1055 - указание того, что протокол является протоколом HTTP, и возврат к 1.

(2) Мониторинг качества сетевых услуг

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

А201 - получение номера SN, адреса ping-сервера, адреса назначения DNS, адреса FTP-сервера, имени пользователя, пароля и другой информации устройства шлюза путем считывания конфигурационного файла config.

А202 - создание дочернего потока net_monitor.

А203 - осуществление этапа А204, если дочерний поток net_monitor успешно создан, тогда как в противном случае осуществление этапа А205.

А204 - выполнение дочернего потока net_monitor, установление последовательности цикла таймера в дочернем потоке net_monitor для выполнения следующих тестов: получение основной информации о пользователе, ping-тест адреса назначения, тест доступности FTP-сервера, тест доступности HTTP-сервера, тест временной задержки DNS и джиттера.

А205 - мониторинг дочернего потока net_monitor.

А206 - определение, нормально ли существует дочерний поток net_monitor; если да, процесс переходит к А202, тогда как в противном случае осуществляется завершение мониторинга качества сетевых услуг.

После того как модуль мониторинга качества сетевых услуг в домашнем шлюзе получает уникальный SN домашнего шлюза, модуль использует дочерний поток net_monitor модуля мониторинга качества сетевых услуг, основная функция дочернего потока net_monitor заключается в периодическом и циклическом использовании подмодулей для осуществления мониторинга качества сетевых услуг (модуль получения основной информации о пользователе, модуль осуществления ping-теста адреса назначения, модуль осуществления теста доступности FTP-сервера, модуль осуществления теста доступности HTTP-сервера и модуль осуществления теста временной задержки DNS), эффективность выполнения программ повышается за счет использования подмодулей в дочернем потоке net_monitor.

Функцией для получения основной информации о пользователе является get_user_basic_info(), процесс является таким, как показано на фиг. 5, соответствующие параметры считываются из XML-файла терминала, соответствующие параметры получают с помощью системных команд, продолжительность онлайн получают за счет функции конверсии времени, и все записывается в CSV-файл и пересылается на FTP-сервер.

Этап получения соответствующих параметров и продолжительности онлайн состоит в следующем.

А20411 - считывание соответствующих параметров из XML-файла терминала, определение, имеется ли команда считывания момента включения питания; если да, процесс переходит к А20416, в противном случае процесс переходит к А20412.

А20412 - определение, имеется ли команда отображения МАС-адреса; если да, процесс переходит к А20416, тогда как в противном случае процесс переходит к А20413.

А20413 - определение, имеется ли команда считывания времени онлайн; если да, процесс переходит к А20416, тогда как в противном случае процесс переходит к А20414.

А20414 - определение, имеется ли команда считывания времени офлайн; если да, процесс переходит к А20416, тогда как в противном случае процесс переходит к А20415.

А20415 - определение, имеется ли команда отображения текущего времени; если да, процесс переходит к А20416, тогда как в противном случае процесс осуществляет выход.

А20416 - конвертирование соответствующих параметров согласно конкретному формату.

Основной функцией для реализации доступности HTTP-сервера является http_service_test_entry(), процесс является таким, как показано на фиг. 6, количество случаев запроса считывается в конфигурационном файле config, количество случаев запроса, количество случаев успеха, количество случаев недоступности и количество случаев превышения пороговой величины инициализируются, URL затем анализируется, HTTP-клиент посылает запрос на соединение серверу для получения основной информации о пользователе, и информация о пользователе записывается в CSV-файл и пересылается на FTP-сервер.

Этап анализа URL и этап отправки HTTP-клиентом запроса на соединение серверу для получения основной информации о пользователе являются следующими.

А20421 - выполнение HTTP-запроса для соединения с сервером после инициализации и анализа URL.

А20422 - определение, является ли количество случаев запроса меньшим, чем предварительно заданное количество случаев запроса; если да, выполняется А20423, тогда как в противном случае выполняется А20427.

А20423 - определение, получена ли информация о хосте; если да, процесс переходит к А20424, тогда как в противном случае процесс осуществляет выход.

А20424 - определение, является ли соединение успешным; если да, процесс переходит к А20425, тогда как в противном случае процесс осуществляет выход.

А20425 - определение, является ли соединение HTTP 302; если да, процесс переходит к А20427, тогда как в противном случае процесс переходит к А20426.

А20426 - определение, является ли соединение HTTP 200, если да, процесс возвращается к А20422, тогда как в противном случае процесс переходит к А20427.

А20427 - определение, является ли количество случаев попытки большим чем 5; если да, процесс осуществляет выход, тогда как в противном случае процесс возвращается к А20423.

Основной функцией для осуществления получения данных о соединении TCP является ping_test_entry().

Основной функцией для осуществления временной задержки DNS и джиттера является dns_test_entry(), при этом процесс является таким, как показано на фиг. 7, параметры (в том числе количество случаев теста DNS, домен назначения теста DNS или IP назначения) инициализируются в конфигурационном файле config, результат трассировки получают за счет конвейерной команды popen, анализ и составление статистики осуществляются по результату трассировки, результат записывается в CSV-файл, и CSV-файл затем пересылается на FTP-сервер.

Основной функцией для реализации доступности FTP-сервера (скорость пересылки на/отправки FTP) является FTP_service_test(), распечатывается размер файла, пересылаемого каждый раз, и получают время пересылки и скорость пересылки путем получения времени пересылки FTP и размера файла.

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

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

1) Интерфейс инициализации: перезапускается домашний шлюз после отсутствия питания домашнего шлюза, и осуществляется инициализация; или осуществляется инициализация, после того как ITMS рассылает IP, имя пользователя/пароль, связанные с FTP. Если инициализация успешно осуществлена, флаг успешности инициализации устанавливается как 1, скрипты get tr069 удаляются, должны остаться лишь оболочки скриптов для пересылки; если инициализация осуществлена неуспешно, флаг успешности инициализации устанавливается как 0, таким образом, осуществлена ли инициализация успешно, можно определить за счет флага при пересылке.

2) Интерфейс пересылки: сначала определяется, обозначает ли флаг инициализации успех, если да, непосредственно выполняются скрипты для пересылки; если флаг инициализации не обозначает успех, инициализация осуществляется снова; если инициализация осуществлена успешно, флаг устанавливается как 1, скрипты информации get tr069 удаляются, лишь скрипты для пересылки остаются; если инициализация осуществлена неуспешно, флаг устанавливается как 0, сгенерированные файлы удаляются.

Согласно экспериментальной статистике необходимо 30 секунд от первой операции для получения IP и узла tr60 wan link. Если инициализация или генерирование скриптов не осуществлены успешно при инициализации, инициализация или генерирование скриптов могут выполняться снова при выполнении пересылки FTP.

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

(3) Осуществление статистического анализа CSV-файла онлайн-поведения и CSV-файла качества сетевых услуг в WEB-клиенте

Передача данных между ITMS и домашним шлюзом осуществляется следующим образом.

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

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

Значение величины срабатывания, относящееся к онлайн-поведению пользователя, в конфигурационном файле beh.conf считывается, если величина указывает на то, что не осуществляется открытие и обработка; в противном случае определяется, существуют ли одновременно процесс сбора онлайн-данных о пользователе collect_data и процесс мониторинга качества сетевых услуг net_monitor; если да, оба процесса сначала прерываются, а затем возобновляются для входа в процедуру, которую осуществляет домашний шлюз; в противном случае, если не существует ни collect_data, ни net_monitor, оба процесса запускаются; если существует один из collect_data и net_monitor, процесс, который существует, прерывается, а другой процесс запускается; получают сигнал, отправленный активным процессом (активный процесс отвечает за передачу данных между терминальной системой управления и домашним шлюзом), и выполняется функция обработки сигнала.

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

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