ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 Проект: Анализ производительности TCP и UDP
новая страница
Даже интересно, почему браузер Chrome работает намного быстрее, чем Firefox, при просмотре видео на Youtube? Да, и как любопытный студент я запустил Wireshark и перехватил немного трафика, и вот что я обнаружил.
По данным wiki1 , QUIC используется более чем в половине всех подключений веб-браузера Chrome к серверам Google.
QUIC — это протокол, целью которого является улучшение веб-приложений, которые в настоящее время используют TCP 2 , путем создания нескольких мультиплексированных UDP, а некоторые даже называют его «TCP/2». Предполагается, что предстоящий HTTP/3 (Internet-Draft от февраля 2021 г.) также будет использовать QUIC.
Подождите... Мы используем UDP вместо TCP? Нам сказали, что UDP ненадежен, почему он может «устареть» TCP. Сравнение двух протоколов (TCP и UDP) аналогично сравнению поезда с самолетом, а не сравнения Boeing с Airbus (оба транспорта ). Однако мы все еще можем сравнить их с некоторыми ключевыми показателями, чтобы понять, что QUIC выбрал для улучшения UDP.
новая страница
новая страница
Сравнение протоколов транспортного уровня — непростая задача, поскольку существует множество факторов, которые могут повлиять на результат:
Некоторые параметры протокола (например, TCP) оставлены на усмотрение реализации (что приводит к использованию TCP/IP Fingerprinting, позволяющему злоумышленнику, среди прочего, идентифицировать операционную систему хоста), что означает, что эти различия могут иметь незначительное влияние на измерение производительности
Непосредственный маршрут, по которому проходят пакеты, безусловно, повлияет на результат, поэтому непосредственные маршрутизаторы, узкие места между ними и другой трафик также могут повлиять на результаты.
Как упоминалось выше, мы часто не можем быть уверены в пропускной способности этих непосредственных ссылок или просто связи между клиентом и сервером. В одной из упомянутых статей было сделано предположение, что в ссылке не будет никаких коллизий.
Мы видели, что буфер мог повлиять на производительность этих протоколов, и важна не только его программная часть, но и аппаратная часть, и часто мы не могли полностью контролировать эти детали более низкого уровня.
В большинстве предыдущих работ авторы часто реализовывали специальную программу для проведения эксперимента, нам также необходимо учитывать влияние того, как эти программные реализации могут повлиять на результат, скажем, интервал, с которым отправляются UDP-пакеты, и есть ли ограничения в язык, используемый для нашей настоящей цели, для интервалов отправки.
Учитывая все эти соображения, мы будем использовать простую топологию сети с настройками, максимально приближенными к реальности. Если основные детали, такие как размер очереди буфера или протоколы, мы будем использовать одинаковые для обоих протоколов. Таким образом, мы будем сравнивать TCP и UDP через IPv4 на проводных хостах типа «один к одному», используя в качестве показателей производительности пропускную способность, среднюю задержку и средний джиттер.
Мы отправим пакеты размером 10, 100 и range(1e4, 1e5, 1e4) , каждый из 1472 байтов в приложении UDP и эквивалентное количество байтов в приложении TCP, чтобы наблюдать за потоками приложений TCP и UDP.
JitterSum содержит сумму всех значений сквозного джиттера (изменения задержки) для всех полученных пакетов потока. Здесь мы определяем джиттер пакета как изменение задержки относительно последнего пакета потока, т.е.
новая страница
Первый вопрос при планировании указанного эксперимента — моделировать или нет. В нашем исследовании лучше использовать моделирование, поскольку мы можем лучше контролировать упомянутые соображения. Самым большим недостатком является то, как мы можем быть уверены, что результат «настоящий»? Ответ на этот вопрос заключается в том, что пока у нас есть четко определенный объем эксперимента и частые проверки работоспособности этих объемов, мы можем иметь представление о том, насколько «реальными» могут быть результаты.
ns-3 — это сетевой симулятор дискретных событий с открытым исходным кодом, используемый в основном в исследовательских или образовательных целях и написанный на C++. Сам симулятор имеет подробную документацию, доступную в Интернете.
Для нашей нынешней цели нам нужно только понять основные абстракции ns-3
{ ширина=75% }
Это похоже на процессы в нашем компьютере: он использует «сокеты» для отправки данных на нижний уровень. Мы установим готовое приложение BulkSendApplication в ns-3 используя TCP-сокет, UDPClient и UDPServer для отправки UDP-пакетов, а также FlowMonitor в обоих случаях для мониторинга пакетов.
Мы будем отправлять пакеты с интервалом в 2 микросекунды, что соответствует задержке основного канала, указанной ниже.
Здесь речь идет о полезной нагрузке. Поскольку MTU равен 1500, естественно, мы захотим использовать 1500 байт. Однако заголовок IP и заголовок UDP требуют 20 + 8 байт, поэтому мы должны использовать 1472 вместо 5 . Это подтверждается моделированием; использование пакета размером 1500 байт может снизить производительность пропускной способности.
BulkSendApplication«Этот генератор трафика просто отправляет данные как можно быстрее до MaxBytes или до тех пор, пока приложение не будет остановлено (если MaxBytes равно нулю). Как только буфер отправки нижнего уровня заполнен, он ждет, пока не освободится место, чтобы отправить больше данных, по сути сохраняя постоянный поток данных.».
Мы устанавливаем MaxBytes равным общему количеству байт (PacketCount * PacketSize) UDP для сравнения производительности, а SendSize не имеет значения в некоторых экспериментах.
Также называется InternetStackHelper , который обычно включает в себя UDP, TCP-сокеты, IPv4 и для нашей настоящей цели TrafficControlLayer , который включает в себя очередь, и когда она заполняется, он уведомляет верхний уровень.
Это соответствует как аппаратному обеспечению (сетевым картам, сетевым картам), так и их программным драйверам, а также включает очередь для пакетов, поэтому в ns-3 существует два уровня очередей.
Это конечные хосты, на которые мы можем установить Application , InternetStack и NetDevice , аналогично нашему компьютеру. Мы создадим два Node и соединим их чем-то вроде кабеля Ethernet.
Предоставляет канал связи с Node , и мы будем использовать канал CSMA (например, Ethernet). Важными деталями здесь являются выбор атрибутов, доступных для настройки: MTU, DataRate и Delay. Мы будем использовать стандартный MTU (без Jumbo-фреймов, иногда доступный для конкретной сети), гигабитный и задержку 2 микросекунды. Причина 2 микросекунд заключается в том, что свет проходит 600 м, по сравнению с другими исследованиями, использующими нулевую задержку.
новая страница
Результаты следующие:
Мы заметили, что пропускная способность UDP для отправленных 14720 и 147200 байт превысила 1000 Мбит/с (наша пропускная способность составляет 1 Гбит/с). Затем мы рассмотрели потерю пакетов
Мы видим, что в 147200 байтах потеряно 97 пакетов из 100. Можно с уверенностью сказать, что нам следует отказаться от этих двух вопросов и продолжить расследование.
Мы также можем видеть, что пропускная способность TCP постепенно увеличивалась и стабилизировалась на уровне около 400 Мбит/с.
Из-за отсутствия контроля трафика пакеты UDP могут «застревать» в очередях нижнего уровня. Результат также может быть вызван нашей быстрой постоянной отправкой пакетов, вызывающей перегрузку. Для подтверждения потребуется дальнейшее расследование, например, уменьшение буфера, чтобы увидеть, действительно ли увеличивается задержка.
Средняя задержка падает сразу после «пика», а затем снова постепенно увеличивается. Это может быть связано с настройкой cwnd для предотвращения перегрузок. Необходимо дальнейшее исследование, поскольку нам нужно подтвердить, что алгоритм контроля перегрузки действительно создает такие шаблоны, поскольку в ns-3 для него есть много вариантов (Veno, Cubic... и т. д.).
Ожидается, что средний джиттер уменьшится по мере «стабилизации» системы и изменения задержки будут меньше.
Отсутствие контроля трафика в UDP означает, что пакеты будут непрерывно опускаться в стек и отправляться без помех, изменение задержки должно быть минимальным, в то время как задержка последовательных пакетов может быть большой из-за упомянутого управления трафиком.
новая страница
BulkSendApplication позаботился о том, чтобы после заполнения буфера отправки нижнего уровня оно ждало. Таким образом, единственное место, где мы можем отбрасывать пакеты, — это канал, в который нам нужно будет внести ошибку.
UDPClient не имеет такого контроля трафика, поэтому мы можем наблюдать потерю пакетов.
Это может быть просто пропускная способность (более высокая пропускная способность) и джиттер (меньшее изменение задержки). Большая средняя задержка в основном связана с отсутствием контроля трафика, который QUIC стремится переместить «алгоритм контроля перегрузки в пространство пользователя… а не в пространство ядра» 1 .
https://github.com/alfredtso/ns-3-project
новая страница
учебные ресурсы ns-3
Черновик HTTP/3
БЫСТРЫЙ ↩ ↩ 2
QUIC GoogleDoc ↩
Юань-Ченг Лай, Ахсан Али, доктор медицинских наук Шохраб Хоссейн, Инь-Дар Лин, Моделирование производительности и анализ потоков TCP и UDP в программно определяемых сетях, Журнал сетевых и компьютерных приложений, том 130, 2019 г., страницы 76–88, ISSN 1084-8045 ↩
Цзинъи Хэ, С.-Х.Гэри Чан, Производительность TCP и UDP для Интернета в оптических сетях с коммутацией пакетов, Компьютерные сети, Том 45, выпуск 4, 2004 г., страницы 505–521, ISSN 1389–1286 ↩
Эрик Гамсс, Рина Сурос, Модель верхней границы пропускной способности TCP и UDP в IPv4 и IPv6, Журнал сетевых и компьютерных приложений, том 31, выпуск 4, 2008 г., страницы 585–602, ISSN 1084–8045 ↩ ↩ 2
Шахрудин Аванг Нор, Раайд Алубади, Висам Абдуладим Камил, Моделирование производительности протоколов TCP, SCTP, DCCP и UDP в сети 4G, Procedia Computer Science, том 111, 2017 г., страницы 2–7, ISSN 1877-0509 ↩
