Утилита для сравнения производительности udp и tcp для передачи больших объемов данных - PullRequest
2 голосов
/ 07 сентября 2011

Я ссылался на разные темы о надежной UDP и TCP для передачи больших файлов.Однако, прежде чем принять решение о выборе UDP вместо TCP (и добавить механизм надежности в UDP), я хочу оценить производительность UDP и TCP.Есть ли какая-нибудь утилита в Linux или Windows, которая может дать мне этот тест производительности?

Я обнаружил, Iperf - одна из таких утилит.Но когда я использовал Iperf на двух Linux-машинах для отправки данных с использованием как udp, так и tcp, я обнаружил, что TCP работает лучше, чем UDP для 10 МБ данных.Это меня удивило, так как общеизвестно, что UDP работает лучше, чем TCP.

Мои вопросы:

  1. Всегда ли UDP работает лучше, чем TCP?или есть какой-то конкретный сценарий, где UDP лучше, чем TCP.

  2. Существуют ли опубликованные критерии для проверки этого факта?

  3. Существует ли какая-либо стандартная утилита для измерения производительности TCP и UDP в конкретной сети?

Заранее спасибо

Ответы [ 2 ]

2 голосов
/ 07 сентября 2011

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

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

Используйте UDP, когда вам нужна многоадресная передача, то есть рассылка, чтобы сказать больше, чем сказать несколько получателей. Используйте UDP, когда управление окнами и управление перегрузкой TCP не оптимизированы, например, высокоскоростные каналы глобальной сети с высокой задержкой: см., Например, ускорители UDT и WAN.

Найдите любую документацию по производительности для 10 сетевых адаптеров GigE. Основная проблема заключается в том, что аппаратное обеспечение недостаточно быстрое для насыщения сетевой карты, поэтому многие поставщики обеспечивают полную разгрузку стека TCP / IP. Также рассмотрите файловые серверы, такие как NetApp и др., Если используется программное обеспечение, вы можете увидеть настройку MTU для увеличения размеров, чтобы уменьшить нагрузку на процессор. Это популярно для низкоуровневого оборудования, такого как устройства SOHO NAS от ReadyNAS, Synology и т. Д. С высокопроизводительным оборудованием, если вы разгрузите весь стек, то, если аппаратное обеспечение будет способно, можно добиться лучшей задержки с нормальными размерами Ethernet MTU, и Jumbograms становятся устарели.

iperf в значительной степени является инструментом для тестирования сети, но он не всегда будет лучшим на платформах Windows. Вам нужно взглянуть на собственный инструмент Microsoft NTttcp:

http://msdn.microsoft.com/en-us/windows/hardware/gg463264.aspx

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

0 голосов
/ 30 октября 2015
  1. UDP НЕ всегда быстрее, чем TCP.Есть много поворотов производительности TCP, включая RSS / vRSS.Например, TCP в Linux-on-HyperV может получить 30 Гбит / с, а в Linux-on-Azure - 20 Гбит / с.// Я думаю, что для Windows VM, это похоже;также на других платформах virt, таких как XEN, KVM, TCP, работали еще лучше.

  2. Существует множество инструментов для измерения: iPerf, ntttcp (Windows), ntttcp-for-Linux, netperf,etc:

    iPerf3: https://github.com/esnet/iperf

    Windows NTTTCP: https://gallery.technet.microsoft.com/NTttcp-Version-528-Now-f8b12769

    ntttcp-для-Linux: https://github.com/Microsoft/ntttcp-for-linux

    Netperf: http://www.netperf.org/netperf/

...