1) В каких случаях и почему связь по шлейфу будет медленнее, чем по сети?
Loopback включает вычисление пакета setup + tcp chksum для обоих tx + rxна одной и той же машине, поэтому она должна выполнять вдвое больше обработки, в то время как с двумя машинами вы разделяете tx / rx между ними.Это может оказать негативное влияние на обратную связь.
2) При максимально быстрой отправке почему переключение TCP_NODELAY оказывает гораздо большее влияние на максимальную пропускную способность по сравнению с обратной связью, чем болеесеть?
Не уверен, как вы пришли к такому выводу, но петля против сети реализована очень по-разному, и если вы попытаетесь довести их до предела, вы столкнетесь с различными проблемами.Интерфейсы обратной связи (как упомянуто в ответе на 1) вызывают издержки обработки tx + rx на той же машине.С другой стороны, сетевые адаптеры имеют ряд ограничений по количеству ожидающих пакетов, которые они могут иметь в своих циклических буферах и т. Д., Что приведет к совершенно различным узким местам (и это сильно варьируется от чипа к чипу и даже от коммутатора, который междуих)
3) Как мы можем обнаружить и проанализировать управление перегрузкой TCP как потенциальное объяснение низкой производительности?
Контроль перегрузки включается только в случае потери пакетов,Вы видите потерю пакета?В противном случае вы, вероятно, достигнете пределов размера окна TCP по сравнению с коэффициентами задержки в сети.
4) Есть ли у кого-нибудь другие теории относительно причины этого явления?Если да, есть какой-нибудь способ доказать теорию?
Я не понимаю явления, на которое вы здесь ссылаетесь.Все, что я вижу в вашей таблице, это то, что у вас есть несколько сокетов с большим буфером отправки - это может быть вполне законно.На быстром компьютере ваше приложение, безусловно, будет способно генерировать больше данных, чем может выкачать сеть, поэтому я не уверен, что вы здесь классифицируете как проблему.
Последнее замечание: небольшие сообщениясоздать гораздо больший скачок производительности в вашей сети по разным причинам, например:
- фиксированные издержки на пакет (для заголовков mac + ip + tcp), и чем меньше полезная нагрузка, тембольше накладных расходов.
- многие ограничения NIC связаны с числом ожидающих пакетов, что означает, что при использовании пакетов меньшего размера вы столкнетесь с узкими местами NIC с гораздо меньшим количеством данных.
- сама сеть в виде издержек на пакет, поэтому максимальный объем данных, которые вы можете прокачать по сети, снова зависит от размера пакетов.