Сравнительное исследование между TCP и UDP туннелем с использованием OpenVPN

Аннотация. Сравнение туннелей TCP и UDP недостаточно освещено в научной литературе. В этой работе мы используем OpenVPN в качестве платформы для демонстрации производительности между TCP / UDP. Фактически считается, что TCP-туннель обеспечивает постоянный туннель и, следовательно, обеспечивает надежную передачу данных между двумя конечными точками. Результаты, представленные в этой статье, демонстрируют, что действительно TCP в UDP-туннеле обеспечивает меньшую задержку. В этой статье была проведена серия тестов, UDP-трафик был отправлен внутри UDP-туннеля и TCP-туннеля последовательно. Те же тесты были выполнены с использованием трафика TCP.

Ключевые слова: сети, VPN, TCP / IP, UDP – соединение, TCP – соединение.

Вступление

IP - тунель — это канал связи по Интернет-протоколу (IP) между двумя сетями. Он используется для передачи другого сетевого протокола через инкапсуляцию. Это достигается путем инкапсуляции своего собственного сетевого протокола в пакеты TCP / IP, передаваемые через Интернет. IP-туннели используются для соединения двух отдельных IP-сетей, которые не связаны напрямую друг с другом. Туннельный протокол позволяет пользователю получить доступ к сетевому сервису, который базовая сеть не поддерживает. Туннелирование может скрыть природу трафика, проходящего через туннель, используя стандарт шифрования для переупаковки данных трафика в другую форму. Протокол туннелирования работает, используя часть данных пакета (полезную нагрузку) для переноса пакетов, которые предоставляют услугу, используя многоуровневую модель протокола, такую как модель модели взаимодействия открытых систем (OSI) или набор протоколов TCP / IP. Туннелирование используется во всех VPN[1]; Одним из доступных решений на уровне приложений с открытым исходным кодом является OpenVPN[2] (Open Virtual Private Network). Популярность VPN возросла из-за его низкой стоимости и безопасности, которую она обеспечивает. Компромиссы между TCP и UDP, независимо от использования VPN, всегда считаются одинаковыми: скорость — это трата за надежность, поскольку UDP не использует соединения, а сервер, отправляющий данные, теоретически не гарантирует, достигнет ли он пункта назначения или нет. Утверждается, что UDP быстрее, а TCP - более надежный. Эта статья фокусируется на таком сравнении и оценивает эффективность между туннелем UDP и туннелем TCP с использованием OpenVPN. В этой статье была проведена серия тестов, UDP-трафик был отправлен внутри UDP-туннеля и TCP-туннеля последовательно. Те же тесты были выполнены с использованием трафика TCP.

ВИРТУАЛЬНАЯ ЧАСТНАЯ СЕТЬ (VPN)

Виртуальная частная сеть (VPN) использует общедоступную сеть для подключения нескольких удаленных местоположений. VPN расширяет частную сеть, используя общедоступную сеть, такую как Интернет, путем установления соединения точка-точка и протоколов виртуального туннелирования. Это позволяет компьютеру обмениваться данными через общедоступные сети, как если бы он был подключен непосредственно к частной сети. VPN - это логическая сеть поверх уже существующей сети. Разные решения VPN работают на разных уровнях в модели Open System Interconnect (OSI). В туннелях трафик шифруется и отправляется с использованием нижних уровней в модели OSI. VPN-трафик отделяется от любого другого сетевого трафика с использованием зашифрованных туннелей между узлами VPN. Внутри туннеля перенаправленный трафик инкапсулируется в специальный формат пакета, в котором блочный шифр используется для шифрования трафика. Как упоминалось в предыдущем параграфе, VPN может работать на разных уровнях модели OSI. Тремя распространенными типами VPN являются VPN уровня приложений, VPN уровня сети и VPN уровня передачи данных. Secure Shell (SSH), Secure Sockets Layer (SSL) и OpenVPN — это VPN, которые работают на прикладном уровне модели OSI. Туннелируемый трафик инкапсулируется в заголовки для конкретного приложения перед отправкой на другую сторону с использованием доступного протокола транспортного уровня, такого как протокол пользовательских дейтаграмм (UDP) или протокол управления передачей (TCP).

СРАВНЕНИЕ МЕЖДУ TCP И UDP

Корректировки между TCP[3] и UDP[4] независимо от использования VPN всегда считаются одинаковыми: скорость - это жертва ради надежности, поскольку UDP не использует соединения, а сервер, отправляющий данные, теоретически не гарантирует, достигнет ли он пункта назначения или нет. Ориентированный протокол, что означает, что сквозная связь устанавливается с помощью рукопожатия. Как только соединение установлено, пользовательские данные могут отправляться в двух направлениях по соединению. По сравнению с TCP, UDP является более простым протоколом без установления соединения на основе сообщений, что означает, что сквозное соединение не выделено, и информация передается в одном направлении от источника к месту назначения без проверки готовности или состояния сервера. TCP управляет подтверждением, повторной передачей и тайм-аутом сообщения. TCP делает несколько попыток доставить сообщения, которые теряются по пути, поэтому в TCP нет пропущенных данных, и если когда-либо есть несколько тайм-аутов, соединение разрывается. Когда отправляется UDP-сообщение, нет никакой гарантии, что сообщение достигнет пункта назначения; это может потеряться по пути. Нет подтверждения, повторной передачи или тайм-аута. Если два сообщения отправляются последовательно, первое сообщение достигнет пункта назначения первым. Когда сегменты данных поступают в неправильном порядке, буферы TCP задерживают данные до тех пор, пока все данные не будут переупорядочены перед доставкой; при использовании UDP порядок поступления сообщений не может быть предсказан. Протокол TCP имеет обширные алгоритмы для обеспечения правильной доставки данных. Таким образом, объединение двух TCP-соединений приведет к тому, что алгоритмы обоих TCP-соединений будут работать параллельно. Протокол TCP не предназначен для такой работы, и проблемы могут возникать в разных ситуациях. Проблемы повторной передачи, распад TCP и двойная повторная передача, являются проблемами, вызванными туннелированием TCP в TCP. Проблемы могут возникать, когда оба стековых соединения повторно передают пакеты. В предыдущей работе, связанной с TCP в туннелировании TCP, не совсем ясно, насколько серьезными являются проблемы с повторной передачей. Набор протоколов TCP оснащен автоматическим восстановлением любых потерянных или потерянных данных. Этот протокол должен быть способен восстанавливаться после сбоя любого хоста в любой части сети и в любой точке передачи данных. Когда пакеты TCP передаются от одного конца к удаленному концу по сети, пакеты данных переупорядочиваются в той же последовательности, сгенерированной отправителем. Протокол обнаруживает, когда сегменты потока данных были отброшены сетью, переупорядочены, дублированы или повреждены. Отправитель может даже ретранслировать поврежденные сегменты. Этот процесс делает TCP надежным протоколом. Однако двойная повторная передача создает задержку. TCP должен был создать эффективный протокол с низкими издержками, набор протоколов, который имел бы минимальный объем передаваемых дополнительных данных. Эти дополнительные данные, называемые служебными данными, выполняют функцию упаковки для передаваемых данных и обеспечивают передачу данных. Туннель TCP - это технология, которая объединяет и передает пакеты, отправленные между конечными узлами, как одно TCP-соединение. В настоящее время многие приложения, такие как Secure Shell (SSH), виртуальные туннели (VTun) и Http Tunnel (HTun), используют TCP-туннель. Однако, поскольку большинство приложений, работающих на конечных хостах, обычно используют TCP, два элемента управления перегрузкой TCP (то есть конечный TCP и туннельный TCP) работают одновременно и создают помехи друг для друга. При определенных условиях использование туннеля TCP серьезно снижает сквозную производительность TCP. В частности, известно, что использование TCP-туннеля в течение некоторого времени резко снижает сквозную пропускную способность TCP. Это называется проблемой распада TCP.

ЭКСПЕРИМЕНТАЛЬНОЕ ИСПЫТАНИЕ

Процедура экспериментального тестирования состоит из четырех частей при оценке задержки. Будут созданы два туннеля: TCP-туннель и UDP-туннель с использованием OpenVPN в качестве базы. В туннеле TCP будет передаваться трафик TCP, а задержка будет записываться в секундах. Затем UDP-трафик будет отправлен в туннель TCP, и то же значение будет записано. Будет выполнен тот же тест, но с использованием туннеля UDP.[5]

Все измерения будут выполняться на узле сервера из-за его вычислительной мощности. Тесты будут проводиться через локальную сеть и среду глобальной сети. Сжатие для OpenVPN будет отключено, поскольку оно не является частью тестов. Во время измерений размер пакетов будет увеличен, и два разных графика будут построены с осями; задержка VPN-туннеля в зависимости от размера пакетов. Iperf будет использоваться для мониторинга задержки. Iperf, это инструмент для тестирования сети, который будет использоваться для измерения параметров во время экспериментов. Поскольку iperf может генерировать потоки данных TCP и UDP, это делает iperf подходящим для этого теста. Iperf также гибок и позволяет пользователю устанавливать различные параметры, которые могут использоваться в тесте или, альтернативно, оптимизировать или настраивать сеть. Iperf обладает функциональностью клиента и сервера и, следовательно, может измерять пропускную способность между двумя концами, как однонаправленно, так и двунаправленно. Был принят во внимание макет физической топологии, настроив полную топологию с использованием двух компьютеров: коммутатора и маршрутизатора. Настройка идентична реальному сценарию в реальном времени и, как ожидается, даст более точные значения для оценки производительности и анализа между туннелем TCP и UDP на основе OpenVPN. Программное обеспечение VPN с открытым исходным кодом, OpenVPN, было выбрано для многих компаний, и, согласно техническим дискуссиям, технологии VPN, использующие туннель UDP в качестве базы, должны обеспечить высокую скорость по сравнению с использованием OpenVPN с использованием TCP в качестве базы.

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

Таблица 1.

Настройка серверной части

Таблица 2.

Настройка клиентской части

Рисунок 1. Сравнение задержки между UDP и TCP внутри туннеля TCP

На рисунке (Рисунок 1) показано сравнение задержки между UDP и TCP в туннеле TCP в среде LAN, измеренное в секундах и размер пакета в мегабайтах. Туннель UDP дает увеличенную скорость передачи по сравнению с туннелем TCP при увеличении размера пакета. Интервал задержки в туннеле UDP становится больше, когда размер пакета увеличивается с 4 МБ до 10 МБ. Это может быть объяснено тем фактом, что когда VPN использует туннель TCP, соединения TCP будут использовать IP-пакеты, отправленные через VPN, что создает издержки TCP дважды. Таким образом, VPN-туннель на базе UDP имеет потенциал для чуть лучшей производительности. TCP обеспечивает двунаправленный туннель для данных, но полагается на пакеты, поэтому будут некоторые «административные» пакеты, например, подтверждает: это издержки TCP. Например, если сервер A отправляет 10 МБ клиенту B, клиент B также отправит несколько пакетов A, подтверждающих прием. При выполнении VPN через TCP VPN имеет свои собственные издержки на основе TCP и транспортирует административные пакеты для любого соединения в VPN. Поэтому график подтверждает проблему стекирования TCP при передаче трафика TCP через туннель TCP. Стекирование TCP начинается, когда размер сообщения достигает 2 МБ, поскольку разница в задержке до 2 МБ очень мала по сравнению с разницей в задержке после 2 МБ.

Рисунок 2. Сравнение задержки между UDP и TCP внутри туннеля TCP

С другой стороны, на графике (Рисунок 2) показано сравнение задержки между UDP и TCP при использовании туннеля UDP в среде локальной сети. При использовании UDP-туннеля у нас нет проблемы двойного стекирования. По сравнению с рисунком 1 задержка меньше для трафика TCP и UDP. Было сказано, что шифрование замедляет UDP-трафик, поскольку, когда биты данных отсутствуют, может потребоваться повторная отправка всего сообщения, что приводит к задержке. В ходе испытаний показано, что на UDP-сообщение не влияет механизм шифрования, когда его размер составляет от 1 до 10 МБ. Отправка TCP-трафика внутри TCP-туннеля не создает проблему двойного стекирования TCP, это доказано на рисунке 2. Когда мы сравниваем, например, два графика, время, необходимое для передачи TCP-сообщения размером 2 МБ, удваивается при использовании TCP-туннеля; задержка в туннеле TCP составляет около 10 секунд, тогда как в туннеле UDP задержка составляет около 5 секунд.

Заключение

Было выполнено сравнение производительности между туннельными соединениями TCP и UDP. Два различных сценариев. Использовались для тестирования два механизма VPN-туннелирования. Результаты показывают, что UDP-туннель лучше использует канал и, таким образом, обеспечивает радикально улучшенное время и скорость передачи по сравнению с TCP-туннелем. Результаты также демонстрируют, что действительно TCP в UDP-туннеле обеспечивает меньшую задержку.

Список литературы:

1. Материал из Википедии — VPN, URL: https://ru.wikipedia.org/wiki/VPN (дата обращения: 29.08.2019)
2. Материал из Википедии — OpenVPN, URL: https://ru.wikipedia.org/wiki/OpenVPN (дата обращения: 29.08.2019)
3. Материал из Википедии — TCP, URL: https://ru.wikipedia.org/wiki/Transmission_Control_Protocol (дата обращения: 27.08.2019)
4. Материал из Википедии — UDP, URL: https://ru.wikipedia.org/wiki/UDP (дата обращения: 28.08.2019)
5. Материал из Википедии — Trivial File Transfer Protocol, URL https://ru.wikipedia.org/wiki/Trivial_File_Transfer_Protocol (дата обращения: 26.08.2019)