Я тестирую скорость передачи файлов между двумя серверами Red Hat, подключенными к одному и тому же коммутатору в центре обработки данных, и решил использовать netcat, чтобы максимально устранить накладные расходы протокола.
Тестирование в режиме TCP прошло хорошо, и мне было интересно, как обстоят дела с UDP.
На моем приемном (клиентском) конце я запустил это:
nc -u -l 11225 -v > myfile.out
А затем на стороне отправки (сервера) я выполнил следующее:
cat myfile.out | nc -u myserver.foo.zzz.com 11225 -v
Размер файла, с которым я тестирую, составляет 38 ГБ, но передача, похоже, останавливается на вокруг 15 ГБ (один раз 14,9, другой 15,6).
Я проверил, добавив «-w 5000» на всякий случай, но без радости. Добавление -v ничего не показывает, кроме подтверждения того, что соединение произошло. Ошибок нет.
Итак - какие-нибудь предложения относительно того, почему бы прекратить передачу?
То, что вы видите, - это не тайм-аут. То, что вы видите, является результатом использования неправильного протокола для этой цели.
TCP будет управлять потоком, что означает, что он будет регулировать скорость передачи в соответствии с пропускной способностью сети и получателя. Кроме того, TCP будет повторно передавать потерянные пакеты.
UDP не делает ни того, ни другого. В nc
Команда, которую вы использовали, будет передавать пакеты так быстро, как считывать их с диска и передавать их в сетевой интерфейс. Если сеть или принимающая сторона не могут справиться с этим, они просто будут продолжать работать с той же скоростью и отправят данные только один раз.
Если вы видите, что на другой конец поступает только половина данных, это, вероятно, означает, что отправляющая машина способна отправлять данные в два раза быстрее, чем остальная часть системы может их обработать.
Если вы внимательно посмотрите на файл на принимающей стороне, вы обнаружите, что он не содержит только первую половину исходного файла. Скорее вы можете ожидать найти фрагменты по всему исходному файлу.