есть ли способ уменьшить окно подтверждения на уровне TCP, чтобы уменьшить возникающую болтливость?
На уровне приложения у вас нет большого контроля над тем, что происходит всетевые уровни связи, все это обрабатывается API более низкого уровня..NET Framework предоставляет вам только некоторые типы, построенные на основе этих API, чтобы упростить процесс реализации.
Принимая во внимание, что подтверждения делают TCP надежным, эти подтверждения могут гарантировать, что все данные были отправлены на другую сторону соединения.Вы можете переключиться на использование UDP, который не использует подтверждения, то есть вы никогда не сможете проверить, были ли данные получены успешно, что отлично подходит для связи в реальном времени (для баланса между скоростью и качеством), но не для отправки файлов, так какмы хотим, чтобы файл был полностью передан, а не только 96% от общего файла.Единственный способ убедиться, что мы получили полный файл, - это заставить получателя уведомить нас о том, что он действительно получил пакеты.
Для меня это звучит как проблема, связанная с инфраструктурой / сетевой архитектурой.Поэтому я лично не буду пытаться исправить это на уровне приложения.Использование класса WebClient и, следовательно, TCP, похоже на правильный протокол для вашего варианта использования.Поэтому, на мой взгляд, вы выполнили свою работу и правильно загрузили файл.
Если у вас есть такая возможность, я бы попытался разместить сеть доставки контента (CDN) между сервером и клиентом, чтобы CDN мог разгрузить загрузку и выгрузить на пограничный сервер, который находится рядом с вашим сервером.физическое местонахождение.
Если это невозможно, проявите изобретательность и, например, у вас будет второй сервер в Великобритании, который синхронизируется с файлами, расположенными на сервере в США.По причинам, связанным с временем и деньгами, я бы не стал этого делать и просто принял бы задержку как есть;80 мс приемлемо для меня.