Загрузка файла зависает на 100

Обновлено: 04.07.2024

Вопрос заблокирован. Ответить на него невозможно.

Удалить запись? Все, что вы написали, станет недоступно. Не удалось прикрепить файл. Нажмите здесь, чтобы повторить попытку. Сейчас уведомления отключены и вы не получаете электронные письма о новых записях. Чтобы включить их, откройте свой профиль и перейдите в настройки уведомлений.

Добавить или удалить ссылку

We found the following personal information in your message:

This information will be visible to anyone who visits or subscribes to notifications for this post. Are you sure you want to continue?

Сейчас уведомления отключены и вы не получаете электронные письма о новых записях. Чтобы включить их, откройте свой профиль и перейдите в настройки уведомлений . Компания Google очень серьезно относится к неправомерному использованию своих сервисов. Мы рассматриваем подобные нарушения в соответствии с законодательством вашей страны. Получив вашу жалобу, мы изучим ее и примем необходимые меры. Мы свяжемся с вами только в том случае, если потребуется дополнительная информация или появятся интересующие вас сведения.

Если вам нужно, чтобы тот или иной контент был изменен согласно действующему законодательству, воспользуйтесь этим инструментом.

Запись не относится к теме, посвящена сторонним продуктам, написана в неуважительной форме или содержит персональную информацию. Запись содержит домогательства, дискриминационные высказывания, изображение наготы, вредоносный, противозаконный, сексуальный или рекламный контент или ее автор выдает себя за другое лицо. Компания Google очень серьезно относится к неправомерному использованию своих сервисов. Мы рассматриваем подобные нарушения в соответствии с законодательством вашей страны. Получив вашу жалобу, мы изучим ее и примем необходимые меры. Мы свяжемся с вами только в том случае, если потребуется дополнительная информация или появятся интересующие вас сведения.

Если вам нужно, чтобы тот или иной контент был изменен согласно действующему законодательству, воспользуйтесь этим инструментом.

Многие люди используют Google Chrome в качестве браузера по умолчанию как в личных, так и в рабочих целях. Это надежно и безопасно, когда речь идет о просмотре и загрузке контента из Интернета. Однако не все идеально в Google Chrome. Некоторые пользователи жалуются, что их загрузка Google Chrome зависает или застревает на 100%.

Если это так, у многих людей появляется ложная надежда. Скачивания сделаны? Могу я открыть файл? Придется ли мне еще ждать завершения отслеживания? Замораживание на 100% не гарантирует, что загрузка файла завершена.

Есть разные причины, по которым загрузка зависает. Расширение может прерывать процесс загрузки. Ваш антивирус может блокировать его, или может быть проблема с вашим сетевым подключением. В некоторых случаях в их браузере Google Chrome может быть ошибка. Эта проблема возникает как в приложении браузера Chrome для мобильного, так и в настольном компьютере.

Выполните тест скорости, чтобы убедиться, что у вас хорошее подключение к Интернету через Wi-Fi. Вы можете улучшить его, подняв роутер или разместив его там, где сигнал сильный.

  • В браузере Chrome откройте новое окно в режиме инкогнито.
  • Перейти к хром: // загрузки /.
  • Найдите загружаемый файл и проверьте, возобновляет ли он процесс.
  • Если нет, попробуйте приостановить его на несколько секунд и возобновить снова.
  • В браузере Chrome перейдите в хром: // расширения /.
  • Находясь на вкладках расширений, попробуйте отключить каждое расширение по одному и проверьте, возобновился ли процесс загрузки. Удалите расширение, из-за которого ваши загрузки останавливаются.

Вы также можете попробовать временно отключить антивирус и посмотреть, исправит ли он ошибку. Если это так, вы можете снова включить антивирус после успешной загрузки файла.

Какой из вышеперечисленных методов помог вам решить проблему с загрузкой в ​​Google Chrome? Вы можете сообщить нам об этом в комментариях ниже.

У Google Chrome тоже есть свои недостатки, и многие пользователи сообщают, что при загрузке определенных файлов загрузка останавливается на 100%. Это, безусловно, может быть раздражающей проблемой, и здесь я расскажу, как решить Google Загрузка Chrome застряла на 100% ошибка.

chrome_downloads

Почему я сталкиваюсь с этой ошибкой?

На самом деле существует множество причин, по которым вы можете столкнуться с этой ошибкой. Ошибка может быть вызвана любой из перечисленных причин, но не ограничиваясь ими:

Как решить проблему с загрузкой Google Chrome на 100%

В зависимости от того, почему вы можете столкнуться с этой ошибкой, существуют различные исправления, которые вы можете использовать для решения вашей проблемы. Здесь я расскажу о некоторых из этих исправлений, которые вы можете попробовать решить, чтобы Google Chrome не загружал ошибку.

Решение 1: найти другой источник

В случае отсутствия заголовков длины содержимого вы ничего не можете сделать, поскольку это проблема на стороне сервера. Что вы можете сделать, так это найти источник, отличный от того, с которого вы сейчас загружаете, и надеяться, что у нового сервера есть соответствующие заголовки, чтобы пользователи могли завершить загрузку.

content_length_image

Решение 2. Не допускайте, чтобы сторонние антивирусы передавали файлы для сканирования.

При использовании стороннего антивирусного программного обеспечения существуют определенные защитные меры, которые применяются приложением для защиты ваших загрузок. Это включает сканирование ваших загрузок в реальном времени, чтобы вы не использовали вредоносные файлы на своем устройстве. Многие популярные антивирусы имеют встроенную функцию безопасности.

Когда этот антивирус сканирует ваши файлы в режиме реального времени, вы можете заметить, что загрузка зависает на 100% и, кажется, продолжается вечно. Хотя это хорошая функция, она может иногда приводить к зависаниям и зависаниям на вашем устройстве.

Попробуйте найти в своем антивирусе параметр, чтобы включить функцию веб-сканирования, которая сканирует загрузки в режиме реального времени. Отключение этой функции должно значительно уменьшить задержки, с которыми вы сталкиваетесь при загрузке определенных файлов.

web_antivirus

предосторожность: Отключение этой функции сделает ваше устройство уязвимым, и мы рекомендуем вам включить его снова после того, как вы закончите работу с этим конкретным файлом.

→ Существует другой метод, при котором стороннее антивирусное программное обеспечение может вызывать эти лаги. Иногда антивирус может конфликтовать с нативной антивирусной функцией Google Chrome, при которой оба файла сканируются одновременно. Это может привести к отставанию вашей системы и невозможности загрузки файлов Chrome.
Выключите антивирус на некоторое время, чтобы Chrome мог загрузить файл самостоятельно, а затем снова включите антивирус.

Решение 3. Диагностика сломанных расширений

Если вы начали наблюдать за этой ошибкой после установки расширения, возможно, что какое-то сломанное расширение вызывает ошибку, с которой вы столкнулись.

Чтобы проверить, так ли это, откройте страницу с файлом, у которого возникла ошибка при использовании Инкогнито Просмотр Режим. Запустите окно инкогнито, щелкнув правой кнопкой мыши значок на панели задач и выбрав Новое окно инкогнито.

Теперь загрузите файл в режиме инкогнито. Если загрузка работает нормально в режиме инкогнито, возможно, на вашем устройстве имеется какое-то сломанное расширение, которое вызывает эту ошибку.

Расширения по умолчанию отключены в этом режиме, и вы можете подтвердить, что ошибка была вызвана неработающим расширением, если вы больше не сталкиваетесь с этой ошибкой в ​​режиме инкогнито.

Начните с включения расширений одно за другим и проверьте, сохраняется ли ошибка.

Решение 4: очистить кэш-память Chrome и файлы cookie

Чтобы очистить данные Google Chrome, нажмите Ctrl + Shift + Delete в новой вкладке, чтобы открыть диалоговое окно Очистить данные просмотра. Здесь выберите All time из выпадающего меню Time range. Затем выберите Очистить данные.

clear_data_205

Решение 5. Переустановите Google Chrome

В крайнем случае, если все другие исправления не пройдены, вы можете попробовать выполнить чистую переустановку браузера Google Chrome. Это также поможет вам в случае, если у вас повреждена установка Chrome. Новая установка сбросит все испорченные файлы и настройки и снова сформирует библиотеки данных.

  • Удалите приложение Chrome с панели управления. Затем также удалите оставшиеся файлы. Чтобы удалить оставшиеся файлы, вы можете использовать сторонний очиститель ненужных файлов, такой как CCleaner.
  • Затем загрузите свежую копию установщика Chrome с веб-сайта Google и запустите установщик.
  • Подождите, пока установщик завершит работу.

Теперь проверьте, сохраняется ли проблема.

Вывод

Хотя Chrome является одним из лучших браузеров, доступных в Интернете, в нем есть некоторые ошибки, которые иногда могут приводить к тому, что загрузки не работают должным образом. Если вы тоже столкнулись с этой проблемой, теперь вы знаете, как решить Google Загрузка Chrome застряла на 100% ошибка с использованием одного или комбинации приведенных выше исправлений. Комментарий ниже, чтобы сказать нам, какой метод помог вам устранить ошибку, и обсудить то же самое.


Примечание: однажды наши коллеги по цеху, специалисты из другого сервиса по ускорению и защите сайтов, столкнулись с тем, что некоторые очень медленные скачивания файлов пользователями внезапно обрывались. Ниже мы приводим перевод их рассказа о возникшей проблеме с нашими комментариями.

Проблемные скачивания

Две вещи нас удивили в этой проблеме: во-первых, только пользователи мобильных устройств были подвержены проблеме, во-вторых, файл, который вызывал проблемы, был все-таки достаточно большим – порядка 30 мегабайт.

После плодотворной работы с tcpdump один из наших инженеров смог воспроизвести проблему. Оказалось, что достаточно положить большой файл для скачивания на тестовом домене, и использовать опцию --limit rate в команде curl :

Ковыряние в tcpdump показало, что всегда был RST-пакет, который прилетал с нашего сервера точно на 60 секунде после установки соединения:

Наш сервер точно делал что-то неправильно. RST-пакет, уходящий с нашего сервера, – это плохо. Клиент «ведет себя хорошо», присылает ACK-пакеты, потребляет данные с той скоростью, с которой может, а мы внезапно обрубаем соединение.

Не наша проблема?

Чтобы изолировать проблему, мы запустили базовый NGINX-сервер со стандартными настройками, и проблема оказалась легко воспроизводима локально:

Это показало, что проблема не является специфичной для нашей установки, это была более широкая проблема, связанная с NGINX.

После дальнейшего изучения, мы выяснили, что у нас используется настройка reset_timedout_connection . Это приводит к тому, что NGINX обрывает соединения. Когда NGINX хочет закрыть соединение по тайм-ауту, он задает SO_LINGER без тайм-аута на сокете, с последующим close() .

Это запускает RST-пакет вместо нормального завершения TCP-соединения. Вот лог strace из NGINX:

Мы могли бы просто отключить reset_timedout_connection , но это не решило бы проблему. Вопрос стоял так: почему вообще NGINX закрывает это соединение?

Далее мы обратили внимание на параметр send_timeout . Его значение по умолчанию – 60 секунд, в точности, как мы наблюдали в своем случае.

Также и не-NGINX проблема

C strace в руках мы посмотрели, что NGINX делает:


В конфигурации мы указали NGINX использовать sendfile , чтобы передавать данные. Вызов sendfile проходит успешно и отправляет 5 мегабайт данных в буфер отправки. Что интересно: это почти такой же размер, который у нас установлен по умолчанию в буфере записи:

Спустя минуту после первого вызова sendfile сокет закрывается. Что будет, если мы увеличим значение send_timeout до какого-то большего значения, например 600 секунд:

После первого большого «выпихивания» данных,
sendfile вызывается еще несколько раз. Между каждым последовательным вызовом он передает примерно 1,7 мегабайт. Между этими вызовами, примерно каждые 180 секунд, сокет постоянно пустел из-за медленного curl, так почему же NGINX не пополнял его постоянно?

Асимметрия

Девиз Unix: «всё является файлом». По-другому можно сказать «всё может быть прочитано или записано с помощью poll». Давайте рассмотрим поведение сетевых сокетов в Linux.

  • Вызов read() будет возвращать данные, доступные в сокете, пока он не опустеет.
  • poll отвечает, что сокет доступен для чтения, когда в нем есть какие-то данные.
  • Вызов write() будет копировать данные в буфер, пока буфер отправки не заполнится.
  • poll отвечает, что сокет доступен для записи, если в нем есть хоть сколько-нибудь свободного места.

Разные «пути» кода

Важно понять, что в ядре Linux есть два различных механизма работы исполняемого кода: по одному пишутся (отправляются) фактические данные, а по второму проверяется, является ли сокет доступным для записи.

  • Должно быть свободное место в буфере отправки.
  • Количество неотправленных данных, стоящих в очереди, должно быть меньше чем параметр LOWAT . В этом случае все было хорошо, поэтому просто опустим это условие.
  • Должно быть свободное место в буфере отправки.
  • Количество неотправленных данных, стоящих в очереди, должно быть меньше чем параметр LOWAT .
  • Свободное место в буфере отправки должно быть больше, чем половина занятого места в буфере.

Если мы вернемся к отслеживанию поведения NGINX, то во втором случае c sendfile мы увидели вот что:

Успешно были отправлены 1,7 мегабайт данных, это близко к 33% от 5 мегабайт, нашего дефолтного значения размера буфера отправки wmem.

Вероятно, такой порог был установлен в Linux чтобы избежать пополнения буферов слишком часто. Нет необходимости «пинать» отправляющую программу после каждого отправленного байта.

Решение

  1. Буфер отправки сокета заполнен на как минимум 66%.
  2. Скорость скачивания пользователем низкая, и буфер не опустошается до 66% за 60 секунд.
  3. Когда это происходит, буфер отправки не пополняется, он не считается доступным для записи, и соединение разрывается по тайм-ауту.

Существует несколько способов решить проблему.

Один – это увеличить send_timeout до, скажем, 280 секунд. Тогда при заданном размере буфера отправки, пользователи, чья скорость больше, чем 50Kb/s, не будут отключаться по тайм-ауту.

Другой вариант, это уменьшить размер буфера отправки tcp_wmem .

Ну и последний вариант, это пропатчить NGINX, чтобы он по-другому реагировал на тайм-аут. Вместо того, чтобы сразу закрывать соединение, можно посмотреть на объем данных в буфере отправки. Это можно сделать с помощью ioctl(TIOCOUTQ) . Тогда мы сможем понять, насколько быстро опустошается буфер, и возможно дать соединению еще чуть-чуть времени.

Крис Бранч подготовил патч для NGINX, в котором реализован вариант с опцией send_minimum_rate , которая позволяет определить насколько медленное скачивание разрешено клиенту.

Выводы

Сетевой стек Linux очень сложен. Хотя обычно все работает хорошо, иногда в нем можно найти сюрпризы.

Не все даже опытные программисты знают все его внутренности. Пока мы разбирались с этой ошибкой, мы поняли, что назначение тайм-аутов в отношении записи данных требует особого внимания, нельзя просто так взять и задать тайм-ауты на запись такие же, как для чтения.

И теперь мы знаем, что из-за значений wmem можно получить неожиданные тайм-ауты при отправке данных.

Читайте также: