Когда я пытаюсь загрузить файл через HTTP, загрузка иногда останавливается примерно через 30 МБ. Скорость загрузки снижается до 0 B / s, и данные не поступают. Когда я останавливаю загрузку и возобновляю ее снова, загрузка все равно зависает. Но когда я снова загружаю его из байта 0, все работает нормально до 30 МБ, когда он снова останавливается. Иногда через несколько часов он снова работает без проблем. Положение в файле при остановке загрузки может меняться, но в большинстве случаев оно составляет около 30–35 МБ.
В качестве менеджера загрузок использую wget. То же самое происходит при использовании curl и других менеджеров загрузки. Ошибка возникает независимо от сервера, с которого я загружаю. Я также наблюдал эту ошибку на других компьютерах Linux в моей сети. Все компьютеры в моей сети работают под управлением Gentoo Linux на x86.
Все интернет-соединения в моей сети проходят через сервер в моей сети, на котором работает прозрачный прокси-сервер Squid на порту 80. Этот сервер подключен к маршрутизатору, которым является Speedport W 700V от Deutsche Telekom AG. Этот маршрутизатор подключен к Интернету с помощью ADSL со скоростью 448 кбит / с вниз и 96 кбит / с вверх.
Я почти уверен, что проблема не в моем прозрачном прокси. Я отключил это, не решив проблему. Я также подключился к маршрутизатору напрямую через WLAN, не решив проблему. Еще пробовал скачивать через другой порт по HTTP. Кроме того, я попытался загрузить файл с помощью IPv6 с туннелем gateway6 со своего компьютера, что привело к точно такой же проблеме.
Странно то, что все отлично работает с FTP и HTTPS (также с wget на том же компьютере). Еще более странно: когда я возобновляю загрузку, которая зависла по HTTP с использованием FTP или HTTPS, загружаю таким образом несколько байтов, останавливаю wget и затем снова возобновляю с помощью HTTP, он снова загружает данные! Но через несколько МБ он может снова остановиться. К сожалению, файлы, загруженные таким образом, всегда ломаются (сумма MD5 неверна), поэтому в какой-то момент должны быть поддельные данные. Я попытался найти сообщения об ошибках HTML в загруженном файле, но grep -i html ничего не нашел. (Я не могу придумать способ поиска в файле сообщений об ошибках HTML, сжатых с помощью GZIP, поэтому я не пробовал это делать.)
Я попытался использовать strace на wget, когда он не смог возобновить загрузку, вы можете найти весь вывод на пастебине. Важные строки повторяются каждую секунду:
clock_gettime(CLOCK_MONOTONIC, {326102, 62176435}) = 0
) = 1
write(2, "78% [++++++++++++++++++++++++++++"..., 19578% [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ] 110,683,685 --.-K/s ) = 195
select(4, [3], NULL, NULL, {0, 949999}) = 0 (Timeout)
Совершенно не понимаю, в чем может быть причина этой проблемы. Кажется, что все, что вызывает проблему, говорит о HTTP. Кажется, что HTTP говорит так разумно, что даже распознает его в туннеле IPv6-over-IPv4. Но что это могло быть и почему это случается только иногда? Другая возможность заключается в том, что на моем компьютере есть проблема, такая же как и на других компьютерах Gentoo Linux.
У кого нибудь была такая проблема? В чем может быть причина и где я должен продолжить расследование, чтобы узнать больше о проблеме?
Обновить:
Я только что снова столкнулся с проблемой и попытался возобновить загрузку через WLAN маршрутизатора, и на этот раз это сработало. Может, я что-то не так делал во время последних тестов с WLAN. Возможно, проблема в моем прозрачном прокси-сервере. Это очень простой прокси-сервер Squid, который ничего не кеширует. Может быть интересен тот факт, что второй прокси-сервер Squid работает на том же компьютере на другом порту.
Обновить:
Загрузка снова зависла, и на этот раз я отключил все настройки брандмауэра и остановил все прокси-серверы. Мне не удалось возобновить загрузку с моего сетевого сервера, который напрямую подключен к маршрутизатору. Так что проблема не в моем прокси-сервере. Я попытаюсь обновить прошивку своего роутера сейчас, хотя у меня нет доступа к нему с правами администратора. Посмотрю, что я могу сделать.
Обновить:
Обновление моего роутера до последней версии не помогло. Я не вижу другой возможности, кроме как в этом виноват мой интернет-провайдер. Мое «решение» теперь - туннелировать весь трафик через SSH-сервер в другом месте.
Еще более странно: когда я возобновляю загрузку, которая зависла через HTTP с использованием FTP или HTTPS, загружаю таким образом несколько байтов, останавливаю wget и затем снова возобновляю использование HTTP, он снова загружает данные! Но через несколько МБ он может снова остановиться. К сожалению, файлы, загруженные таким образом, всегда ломаются (сумма MD5 неверна)
Это кричит «сломанный прокси». Протокол для возобновления загрузки HTTP никоим образом не сложен (это просто дополнительный заголовок), но это именно то, что сломанный прокси-сервер может испортить.
Бьюсь об заклад, если вы попытаетесь загрузить большой файл с помощью wget, дождетесь, пока он не завершится, а затем запустите wget -c, изменяя http на https, он возобновится нормально.
Этот пост действительно старый, и вся сетевая инфраструктура давно заменена, но я все же хотел опубликовать решение, которое я не публиковал в тот день.
Проблема была вызвана сетевой картой, которая подключила мой сетевой сервер к маршрутизатору. Замена карты решила проблему. Я не знаю, в чем именно была проблема. Должно быть, это была ошибка прошивки, вызванная некоторыми конкретными последовательностями байтов или некоторыми другими условиями.