net :: ERR_CONNECTION_RESET, когда большой файл занимает больше минуты

Question

У меня есть многочастная загрузка файла в форме с бэкэндом php.Я установил max_execution_time и max_input_time в php.ini на 180 и подтвердил при загрузке файла, что эти значения установлены и установлены TimeOut 180 в Apache.Я также установил

RewriteRule .* - [E=noabort:1]
RewriteRule .* - [E=noconntimeout:1]

Когда я загружаю файл 250 МБ в быстром соединении, он работает нормально.Когда у меня медленное соединение или кондиционер сетевого соединения, чтобы искусственно замедлить его, время ожидания того же файла и в Chrome дает мне net::ERR_CONNECTION_RESET через 1 минуту (и 5 секунд) надежно.Я также пробовал другие браузеры с таким же результатом, просто разные сообщения об ошибках.

Нет никаких признаков ошибки в любом журнале, и я пробовал как на http, так и https.

Что может привести к сбросу соединения для загрузки через 1 минуту?

РЕДАКТИРОВАТЬ

Теперь я также попытался создать простую форму загрузки, которая обходитлюбой фреймворк, который я использую, все еще тайм-ауты в 1 минуту.

Я также только что сделал сценарий сна, который тайм-ауты через 2 с половиной минуты, и это работает, загрузка страницы занимает около 2,5 минут, поэтому яя не вижу, как это связано с браузером или заголовком.

Я также использовал сервер с большим объемом оперативной памяти, чтобы убедиться, что он не связан с этим.Я тестировал на 3 разных серверах с разными спецификациями, но все с одной и той же базы CentOS 7.

Теперь я также обновился до PHP 7.2 и снова обновил соответствующие поля без изменений в проблеме.

EDIT 2 Технический стек для этого изолированного экземпляра:

• Apache 2.4.6
• PHP 5.6 / 7.2 (пробовал оба), имеет OPCache
• Redis 3.2.6 для хранения информации о сеансе и хранения ключа / значения (ElastiCache)
• PostgreSQL 10.2 (RDS)

Все остальное в моем техническом стеке было удалено из этой области тестирования, чтобы попытаться изолировать проблему.EFS находится в системе, но в моем наиболее изолированном тесте она просто использует EBS.

EDIT 3 Вот некоторые журналы от сетевого отладчика Chrome:

{"params":{"net_error":-101,"os_error":32},"phase":0,"source":    {"id":274043,"type":8},"time":"3332701830","type":69},
{"params":    {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":216,"net_error":-101,"ssl_error":1},"phase":0,"source":        {"id":274043,"type":8},"time":"3332701830","type":56},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":159},
{"phase":1,"source":    {"id":274038,"type":1},"time":"3332701830","type":164},
{"phase":1,"source":    {"id":274038,"type":1},"time":"3332701830","type":287},
{"params":    {"error_lib":33,"error_reason":101,"file":"../../net/socket/socket_bio_adapter.cc","line":113,"net_error":-101,"ssl_error":1},"phase":0,"source":    {"id":274043,"type":8},"time":"3332701830","type":55},
{"params":{"net_error":-101},"phase":2,"source":    {"id":274038,"type":1},"time":"3332701830","type":287},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":164},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":97},
{"phase":1,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":105},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":38},
{"phase":2,"source":{"id":274043,"type":8},"time":"3332701830","type":34},
{"params":{"net_error":-101},"phase":2,"source":{"id":274038,"type":1},"time":"3332701830","type":2},

Answer 1

Я столкнулся с подобной проблемой, в моем случае это было связано с mod_reqtimeout , добавив:

RequestReadTimeout header=20-40, MinRate=500 body=20, MinRate=500

в httpd.conf добились цели!Вы можете проверить документацию здесь .

Надеюсь, это поможет!

Answer 2

У меня была такая же проблема.Я использовал возобновляемый метод загрузки файлов, при котором, если Интернет отключается и снова подключается, загрузка возобновляется с того же прогресса.

Проверьте библиотеку https://packagist.org/packages/pion/laravel-chunk-upload

1. Установка

composer require pion/laravel-chunk-upload

Добавить поставщика услуг

\Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider::class

Опубликовать конфигурацию

php artisan vendor:publish --provider="Pion\Laravel\ChunkUpload\Providers\ChunkUploadServiceProvider"

Answer 3

На мой взгляд, это может быть относительно одного из них:

О apache config (/etc/httpd2/conf ou /etc/apache2/conf):

Timeout 300
max_execution_time = 300

О php config ('php.ini'):

upload_max_filesize = 2000M
post_max_size = 2000M
max_input_time = 300
memory_limit = 3092M
max_execution_time = 300

About PostgreSQL config (выполнить этот запрос):

SET statement_timeout TO 0;

About прокси , (или apache mod_proxy), это также может быть связано с настройкой тайм-аута прокси

Answer 4

ERR_CONNECTION_RESET обычно означает, что соединение с сервером было прервано без отправки какого-либо ответа клиенту.Это означает, что весь процесс PHP умер, не имея возможности правильно завершить работу.

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

Я бы порекомендовал вам попробовать некоторые из этих вещей:

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

2) Добавьте в свои настройки следующее:

memory_limit = 1024M

max_input_vars = 2000

upload_max_filesize = 300M

post_max_size = 300M

max_execution_time = 990

3) Попробуйте указать в своей форме следующие данные:

<input type="hidden" name="MAX_FILE_SIZE" value="300000000" /> 

4) В сценарии обработки, увеличьте время ожидания сеанса :

set_time_limit(200); 

5) Возможно, вам потребуется настроить размер буфера SSL в вашем файле конфигурации apache.

SSLRenegBufferSize 10486000

Имя и местоположение файла conf различаются в зависимости от дистрибутивов.

В Debian вы найдете файл conf в /etc/apache2/sites-available/default-ssl.conf

6) Несколько раз это mod_security module что предотвращает публикацию больших данных примерно 171 КБ.Попробуйте добавить / изменить следующее в mod_security.conf

SecRequestBodyNoFilesLimit 10486000
SecRequestBodyInMemoryLimit 10486000

Надеюсь, что-нибудь получится!