Scientific journal

International Journal of Applied and fundamental research

ISSN 1996-3955

ИФ РИНЦ = 0,593

Введение

В настоящее время возрастают требования к скорости и постоянству передачи данных в информационных сетях: это достигается с помощью модернизации сетевого оборудования, а также посредством внедрения более эффективных протоколов [1-3]. Тем не менее рассмотрение вопроса обеспечения быстродействия в сети с точки зрения оборудования и протоколов физического и сетевого уровней не учитывает ключевую роль протоколов прикладного уровня модели Department of Defense (DoD). При этом данные протоколы непосредственно определяют, как данные обрабатываются, передаются и принимаются на уровне конечных пользователей.

Несмотря на активное развитие за счет широкого представления среди других протоколов, внедрение новых прикладных протоколов также сталкивается с вызовами: от обновления сетевой инфраструктуры до обеспечения совместимости различных частей информационных систем [2; 4]. В связи с этим традиционные протоколы, такие как File Transfer Protocol (FTP) и HyperText Transfer Protocol (HTTP), продолжают широко использоваться.

Поскольку в основе FTP и HTTP лежит идентичный стек технологий [5, c. 623–624], возникает вопрос, какой из данных протоколов при различных условиях предоставляет большую скорость передачи данных по сети.

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

Материалы и методы исследования

В рамках работы был проведён ряд экспериментов, сравнивающих скорость работы протоколов HTTP и FTP в рамках сценария передачи файлов разного размера по сети. При этом в экспериментах не применялись методы оптимизации передачи, предлагаемые различными реализациями протоколов.

В реальных условиях передача файлов осуществляется между двумя различными устройствами, взаимодействующими друг с другом по сети. Проведение эксперимента требовало наличия изолированной и контролируемой среды. Данные условия были достигнуты с помощью средств виртуализации: созданы две виртуальные машины, размещенные на одном физическом устройстве [6]. В рамках данной работы использовалась программа для виртуализации Oracle VM Virtual Box, на каждую используемую виртуальную машину было выделено 8 виртуальных ядер процессора, 4 ГБ оперативной памяти и 25 ГБ дискового пространства, были добавлены виртуальные сетевые адаптеры для работы с локальной сетью и для выхода в Интернет через физическое устройство, на котором работают машины [7]. В качестве операционной системы был установлен дистрибутив Linux «Ubuntu».

Для передачи данных между виртуальными машинами была произведена настройка внутренней сети, предполагающая включение сетевого адаптера с типом подключения «Внутренняя сеть». Таким образом, машины были объединены в локальную сеть. Для установления связи между виртуальными машинами необходимо, чтобы каждой из них соответствовал уникальный Internet Protocol (IP) адрес. В связи с этим была произведена установка статических адресов с помощью утилиты ip [8, c. 41–42]. Это позволило «напрямую» связать машины в виртуальной сети, что соответствует соединению устройств через патч-корд или коммутатор в физической среде.

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

Для настройки HTTP-сервера был выбран «nginx», поскольку он является одним из самых используемых веб-серверов и обладает высокой производительностью и гибкостью. Функциональность HTTP-сервера «nginx» включает в себя раздачу файлов. Для раздачи из локального каталога в файле конфигурации /etc/nginx/nginx.conf был отредактирован блок «http», внутрь которого был добавлен блок «server» с настроенным блоком «locations». В блоке «locations» был задан префикс, сравниваемый с Uniform Resource Identifier (URI) из запроса для перенаправления данного запроса в директорию, указанную в директиве «alias», что обеспечивает доступ к запрашиваемому ресурсу (листинг 1) [9, c. 16–19].

http {

server {

listen 192.168.1.10:8081;

location /files/ {

autoindex on;

alias /local_dir/;

}}}

Листинг 1. Настройки HTTP-сервера

Для проведения экспериментов были созданы тестовые файлы различных размеров: 100 МБ, 1 ГБ и 5 ГБ – для проверки работы протоколов при передаче малых, средних и больших объемов информации. Генерация файлов осуществлялась на «серверной» виртуальной машине с использованием утилиты fallocate, позволяющей быстро создавать файлы заданного размера с произвольным содержимым. Пример команды для создания файлов представлен в листинге 2.

fallocate -l 1G test_1GB.txt

Листинг 2. Команда для создания файла заданного размера

С помощью утилиты tc были установлены различные ограничения на входящий и исходящий трафик с виртуального адаптера. Для всех проведённых экспериментов была задана пропускная способность канала, равная 100 МБит/с; это значение можно считать максимально возможной скоростью передачи, поскольку локальная сеть использовалась только для передачи файлов. Вводились следующие виды помех: потеря (2%), повреждение (2%) и дублирование (5%) пакетов. Пример установки помехи приведен в листинге 3. В рамках каждого отдельного эксперимента устанавливалась только одна помеха. Данные уровни (вероятность возникновения помехи) были выбраны экспериментально: при превышении указанных уровней скорость передачи падает до менее чем 1 МБит/с, что заметно увеличивает время исследования без привнесения дополнительных эффектов. Все ограничения устанавливались на машине, с которой происходила «отдача» файлов.

tc qdisc add dev enp0s8 root netem loss 2%

Листинг 3. Установка потери 2% пакетов с помощью утилиты tc

Также был рассмотрен сценарий, при котором происходит разрыв соединения на некоторый отрезок времени: 5, 30, 60 или 120 с. Для этого был написан bash-скрипт, производящий физическое отключение сетевого адаптера на принимающей машине с помощью утилиты iptables [8, с. 113–117; 10, с. 356–360]. В листинге 4 представлен вариант скрипта для разрыва соединения на 120 с.

#!/bin/bash

INTERFACE=”enp0s8”

iptables -A INPUT -i “$INTERFACE” -j DROP

iptables -A OUTPUT -o “$INTERFACE” -j DROP

sleep 120

iptables -D INPUT -i “$INTERFACE” -j DROP

iptables -D OUTPUT -o “$INTERFACE” -j DROP

Листинг 4. Скрипт для имитации разрыва соединения на 120 с

После настройки тестовой среды был разработан алгоритм для измерения скорости передачи данных по протоколам FTP и HTTP, предусматривающий последовательную загрузку файлов заданного размера с фиксацией времени передачи. После каждой успешной загрузки файл удалялся, и устанавливалась пауза длительностью 30 с для обеспечения очистки кеша как на стороне сервера, так и на стороне клиента. По истечении паузы процедура передачи повторялась. Для каждого файла проводилось 5 последовательных итераций для минимизации влияния случайных факторов на результат и обеспечения репрезентативности измерений. Данный подход применялся для обоих протоколов и всех типов сетевых помех. Для автоматизации данного процесса были разработаны специальные скрипты, выполняющие последовательность шагов алгоритма для передачи по FTP (листинг 5) и HTTP (листинг 6) без вмешательства пользователя [10, с. 436–439]. Для загрузки данных по FTP использовалась утилита lftp с поддержкой командного интерфейса и гибкой настройки параметров передачи, что позволяет использовать её в автоматизированных сценариях, описанных выше. Для HTTP применялась утилита wget как одна из наиболее распространённых для загрузки файлов по HTTP [10, с. 207].

#!/bin/bash

for size in 100MB 1GB 5GB do

for ((i=0;i<=5;i++)); do

time lftp -e “set ssl:verify-certificate no; get /local_dir/test_$size.txt; bye” -u ftpuser,11 ftp://192.168.1.10

rm test_$size.txt

sleep 30

done

done

Листинг 5. Скрипт для проведения эксперимента с протоколом FTP

#!/bin/bash

for size in 100MB 1GB 5GB do

for ((i=0;i<=5;i++)); do

time

wget http://192.168.1.10:8081/files/test_$size.txt

rm test_$size.txt

sleep 30

done

done

Листинг 6. Скрипт для проведения эксперимента с протоколом HTTP

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

Результаты исследования и их обсуждение

На основании проведённых экспериментов были собраны данные о времени передачи файлов различных размеров при разных типах сетевых помех для FTP и HTTP. Для каждого случая было выполнено 5 последовательных измерений; в качестве итогового значения времени передачи использовалось среднее арифметическое по результатам этих измерений.

Также для сравнения протоколов была определена разница во времени передачи, рассчитываемая по формуле:

Разница ,

где tHTTP и tFTP –среднее время передачи по HTTP, FTP соответственно. Данное значение показывает, насколько быстрее происходит передача посредством FTP по сравнению с HTTP. Полученные результаты отражены в таблице 1.

Результаты эксперимента показывают, что при отсутствии сетевых помех время передачи по HTTP и FTP практически совпадает для средних и больших файлов. Незначительные различия объясняются скорее деталями реализации используемых инструментов, а не особенностями протоколов. Тем не менее при отсутствии помех передача малых файлов по HTTP происходит в среднем на 8% быстрее. Это можно объяснить тем, что FTP имеет более долгую процедуру инициализации передачи, требующую установления соединения для передачи команд, проведения аутентификации, запроса файла, открытия соединения для его передачи. В связи с этим на коротких временных отрезках передачи малого объема данных подобные задержки более заметны.

При появлении помех FTP в ряде случаев обеспечивает более стабильную и быструю передачу. Это может быть связано с тем, что FileZilla, применяемая в качестве FTP-сервера, оптимизирована для быстрых переотправок повреждённых или потерянных пакетов.

Таблица 1

Сравнение времени передачи по протоколам HTTP и FTP

Также, согласно описанной ранее методике, были проверены сценарии разрыва соединения между машинами на интервалах в 5, 30, 60 и 120 с. Результаты тестов приведены в таблице 2.

Таблица 2

Результаты тестирования на разрыв соединения при передаче по HTTP и FTP

Видно, что передача по FTP оказалась более устойчивой к длительному разрыву соединения по сравнению с HTTP. Однако это также можно объяснить особенностями реализации FTP-сервера, который дольше сохраняет соединения открытыми. Аналогичного эффекта можно добиться и при использовании HTTP, например, указав заголовок Keep-Alive [9, с. 86].

Заключение

В ходе работы была проведена настройка тестовой среды для сравнения скорости передачи данных с использованием протоколов HTTP и FTP. Результаты экспериментов были обработаны и представлены в сравнительных таблицах.

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