Программирование сокетов: устанавливают ли некоторые интернет-провайдеры ограничение скорости загрузки по FTP?
В настоящее время я пытаюсь решить проблему клиента с функцией загрузки по FTP в одном из наших продуктов. Эта функция позволяет клиентам загружать файлы (<1 МБ) на центральный FTP-сервер для дальнейшей обработки. Код клиента FTP был написан собственными силами на VB.NET.
Клиент сообщает, что он получает сообщение об ошибке «Соединение принудительно закрыто удаленным хостом» при попытке загрузить файлы размером от 300 до 500 КБ. Однако мы тестировали это собственными силами с файлами гораздо большего размера (условно говоря), то есть 3 МБ и выше, и никогда не получали эту ошибку. Мы загрузили на тот же FTP-сервер, к которому подключается клиент, используя те же учетные данные для входа на FTP, с той лишь разницей, что мы делали это из нашего офиса.
Я знаю, что протокол TCP имеет встроенное управление потоком, поэтому не должно иметь значения, сколько данных отправляется за один вызов Send, поскольку протокол будет регулировать себя соответствующим образом, чтобы соответствовать внутренним ограничениям сервера (если я правильно помню. ..)
Поэтому я могу думать только о том, что промежуточный хост между клиентом и маршрутизатором искусственно ограничивает скорость клиента и отключает его (мы отправляем данные файла в цикле кусками по 512 байт).
Это цикл, который используется для отправки данных (буфер - это массив байтов, содержащий данные файла):
For i = 0 To buffer.Length - 1 Step 512
mDataSocket.Send(buffer, i, 512, SocketFlags.None)
OnTransferStatus(i, buffer.Length)
Next
Возможно ли, что интернет-провайдер клиента (или его собственный брандмауэр) налагает искусственное ограничение скорости на количество данных, которые наш клиентский код может отправить в течение заданного периода времени? Если да, то как лучше всего справиться с этой ситуацией? Я предполагаю, что очевидным решением было бы ввести задержку в нашем цикле отправки, если нет способа сделать это на уровне сокета.
Мне кажется очень странным, что интернет-провайдер будет обрабатывать нарушение ограничения скорости, убивая клиентское соединение. Почему бы им просто не положиться на внутренний механизм управления / регулирования потока TCP / IP?
Ответы 5
Я не думаю, что провайдер попытается остановить передачу файлов размером 500 КБ. Я не эксперт ни в разъемах, ни в интернет-провайдерах ... просто высказываю свои мысли по этому поводу.
Сделайте поиск Comcast и BitTorrent. Вот одна статья.
+1. Это могло бы объяснить, почему соединение разрывается, а не просто дросселируется (поскольку кажется, что мотивом является полное прекращение общего доступа к файлам в их сети). Думаю, я забыл, насколько закулисными могут быть интернет-провайдеры ;-)
Попробуйте изолировать проблему:
- Позвольте клиенту загрузить тот же файл на другой сервер. Может проблема в клиентском ... FTP-клиенте.
- Получите файл у клиента и загрузите его самостоятельно вместе со своим клиентом и посмотрите, сможете ли вы воспроизвести проблему.
В конце концов, даже если файл размером 3 МБ работает нормально, файл размером 500 КБ не обязательно будет работать, потому что проблема может зависеть от состояния и возникать при завершении передачи файла.
Да, интернет-провайдеры могут устанавливать ограничения на пакеты по своему усмотрению (хотя это сомнительно с этической точки зрения). У моего интернет-провайдера, например, нет проблем с отключением любого P2P-трафика, который его оборудование может перехватить. Он называется формирование трафика.
Однако для FTP-трафика это очень неприятно, но вы никогда не узнаете. Дело в том, что они никогда не сбрасывают ваши сокеты с формированием трафика, они только сбрасывают пакеты. Протокол tcp обрабатывается на каждой стороне груши, поэтому вы можете отбросить все пакеты между ними, и сокет останется в живых. В некоторых случаях, если один из компьютеров выходит из строя, сокет остается активным, если вы не пытаетесь его использовать.
Я думаю, вам лучше всего будет использовать плохую конфигурацию брандмауэра / прокси на стороне клиента. Лучше объяснения здесь.
Либо это, либо неисправный или плохо настроенный маршрутизатор или кабель на клиентских установках.
Статья, на которую ссылается Марк Рэнсом, похоже, подразумевает, что некоторые интернет-провайдеры действительно сбрасывают TCP-соединение. Таким образом, похоже, что интернет-провайдеры могут сделать это, отбрасывая отдельные пакеты или разрывая соединение. И ... я согласен с "этически сомнительным" аспектом.
500k - это ужасно мало в наши дни, поэтому я был бы немного удивлен, если бы они подавили что-то такое маленькое.
Я знаю, что вы уже разбили свой запрос на части, но можете ли вы определить, передаются ли какие-либо данные? Всегда ли происходит сбой кода в одной и той же точке цикла? Можете ли вы посмотреть журналы ftp-сервера? А как насчет трассировки всего стека? Вы пытались связаться с интернет-провайдером и спросить его, какие у него политики?
Тем не менее, если предположить, что некоторые данные проходят, можно подумать, что у интернет-провайдера есть формирование трафика, и правила вступают в силу после того, как были записаны x байтов. Что может произойти, так это при data> x тайм-аут сокета истекает до отправки данных, вызывая исключение.
Имейте в виду, что ftp-клиенты создают другое соединение для передачи данных, но если сервер обнаруживает, что управляющее соединение закрыто, он обычно прерывает соединение для передачи данных. Еще одна вещь, которую нужно проверить, - убедиться, что контрольное соединение все еще живо.
Наконец, ftp-серверы обычно поддерживают возобновляемые передачи, поэтому, если все остальные средства не работают, возобновление неудачной передачи может быть самым простым решением.
+1 Все хорошие моменты. Командное соединение остается открытым во время передачи, но, тем не менее, это интересный момент. Я не помню, чтобы читал это в RFC, но опять же я написал FTP-клиент около 4 лет назад - моя память, вероятно, немного нечеткая ;-)
Вопрос не в количестве отправляемых данных, а в том, как часто данные передаются по сети. Мне интересно, известны ли какие-либо интернет-провайдеры, которые искусственно накладывают какое-то ограничение скорости поверх TCP, то есть вы можете отправлять только максимум 100 КБ / с, иначе соединение будет закрыто.