8 lines
18 KiB
JSON
8 lines
18 KiB
JSON
{
|
||
"index": 364,
|
||
"slug": "firefox-увеличение-ожидания-загрузки-timeout-стр",
|
||
"title": "Firefox и долгий HTTP-запрос: как увеличить timeout, не скрыв неисправность",
|
||
"excerpt": "Если Firefox обрывает долгий запрос, сначала определите этап задержки. Затем временно измените response timeout в отдельном профиле и проверьте, что запрос действительно продолжает работу.",
|
||
"contentHtml": "<p>Страница в Firefox долго остаётся пустой, а затем появляется сообщение о сетевой ошибке. Вы повторяете запрос, видите тот же обрыв и меняете первый найденный параметр в <code>about:config</code>. Ошибка исчезает не всегда. Иногда браузер просто ждёт дольше, пока сервер, прокси или балансировщик всё равно не закроет соединение.</p>\\n<p>Цена такого решения — потерянное время и ложное чувство исправности. Администратор может повторить импорт, отчёт или выгрузку и получить вторую операцию. Пользователь может принять долгий белый экран за норму. Если запрос меняет данные, повторение повышает риск дубликатов. Увеличение таймаута не ускоряет сервер и не делает операцию надёжнее само по себе.</p>\n<p>Тезис статьи простой: меняйте таймаут Firefox только после того, как установили место задержки. Параметр <code>network.http.response.timeout</code> ограничивает ожидание HTTP-ответа на стороне браузера. Он не отменяет ограничения приложения, веб-сервера, reverse proxy, балансировщика, VPN или сети. Для разовой диагностики настройка полезна. Для обычного пользовательского сценария она почти всегда указывает на задачу для серверной архитектуры.</p>\n<figure><img src=\"/assets/illustrations/mascot-hero-2017-firefox-timeout-identity-v2-wide.png\" alt=\"Песочные часы рядом с окном Firefox и индикатором ожидания ответа\" loading=\"lazy\" /><figcaption>Иллюстрация показывает ожидание ответа. Само ожидание ещё не объясняет, какой слой задерживает запрос.</figcaption></figure>\n<h2>Что именно ждёт Firefox</h2>\n<p>Слово timeout описывает несколько разных пределов. Браузер может ждать DNS-ответ, установления TCP-соединения, TLS-рукопожатия, первого байта HTTP-ответа или оставшихся байтов тела. Эти этапы имеют разные причины и разные владельцы. Ошибка при соединении не лечится тем же параметром, что пауза перед первым байтом.</p>\n<p>В Firefox откройте DevTools сочетанием <code>Ctrl+Shift+E</code> или через меню разработчика и включите вкладку Network. Перезагрузите страницу с открытой панелью. Выберите проблемный запрос. В разделе Timings смотрите DNS Lookup, Connecting, TLS Setup, Waiting и Receiving. Названия и детализация могут отличаться по версии, но принцип сохраняется: сначала зафиксируйте этап, потом выбирайте гипотезу.</p>\n<p>Длинное Waiting обычно означает высокий TTFB: сервер получил запрос, но долго готовит первый байт. Причиной могут быть SQL-запрос, построение отчёта, обращение к внешнему API или блокировка. Длинное Receiving означает, что ответ уже начался, но тело передаётся медленно. Обрыв до ответа чаще связан с сетью, прокси, перегрузкой или лимитом соединения. Это не строгий диагноз, а способ сузить поиск.</p>\n<p>Сохраните HAR или хотя бы время начала, URL без секретов, статус, размер ответа и значения Timings. Не публикуйте cookies, токены и персональные параметры из HAR. Один скриншот ошибки не показывает, что произошло с запросом. Нужна запись конкретного этапа.</p>\n<h2>Механизм на примере</h2>\n<p>Представим учебный endpoint <code>https://example.test/report</code>. Он строит отчёт и отдаёт первый байт через 420 секунд. Firefox имеет локальный response timeout 300 секунд. Браузер завершит ожидание раньше ответа. Временное значение 600 секунд даст серверу шанс прислать результат. Это только учебный пример. Он не доказывает, что любой отчёт должен работать 420 секунд, и не является результатом измерений в production.</p>\n<pre><code># Учебная проверка. Не вставляйте секреты в командную строку.\ncurl --verbose --max-time 600 --output /tmp/report.out https://example.test/report\n\n# Если endpoint требует авторизацию, используйте безопасный способ\n# передачи заголовков и удалите файл после локальной проверки.</code></pre>\n<p>Команда нужна не для замены Firefox. Она помогает отделить проблему браузерного профиля от проблемы URL или сервера. Если <code>curl</code> также ждёт 420 секунд и завершается на лимите, менять Firefox первым не стоит. Если <code>curl</code> получает ответ быстро, а Firefox обрывает запрос, сравните профиль, расширения, прокси, кеш и параметры браузера.</p>\n<p>При HTTP-ответе сервер может отправить заголовки, статус и часть тела, а затем долго продолжать передачу. В таком сценарии важен не только response timeout. Проверьте лимиты на размер ответа, idle timeout и время жизни соединения на промежуточных узлах. Если приложение отправляет данные порциями, прокси может считать соединение активным; если приложение молчит, прокси может закрыть его раньше браузера.</p>\n<table><caption>Диагностика по наблюдаемому симптому</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Вероятная причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Долгое Waiting до первого байта</td><td>Приложение, база данных или внешний API</td><td>Сравнить TTFB, серверный trace и логи</td><td>Оптимизировать запрос или вынести работу в фон</td></tr><tr><td>Соединение закрывает прокси</td><td>Idle или upstream timeout</td><td>Сверить конфигурацию всех промежуточных узлов</td><td>Согласовать лимиты и добавить наблюдение</td></tr><tr><td>Только один профиль Firefox не загружает URL</td><td>Локальная настройка, расширение или кеш</td><td>Повторить в чистом профиле и без расширений</td><td>Сбросить изменённую настройку, затем проверить снова</td></tr><tr><td><code>curl</code> и Firefox завершаются одинаково</td><td>Сервер, сеть или общий прокси</td><td>Снять логи и повторить запрос из той же сети</td><td>Исправлять общий слой, не браузер</td></tr><tr><td>Ответ начался, но тело не заканчивается</td><td>Медленная выдача, большой ответ или разрыв потока</td><td>Смотреть Receiving, размер и серверные лимиты</td><td>Проверить потоковую выдачу, размер и idle timeout</td></tr></tbody></table>\n<h2>Как временно изменить настройку</h2>\n<p>Параметры <code>about:config</code> относятся к профилю Firefox. Mozilla предупреждает, что расширенные настройки могут повлиять на стабильность, безопасность и производительность. Поэтому не меняйте значение в основном профиле без записи исходного состояния. Для диагностики создайте отдельный профиль или заранее сохраните старое значение.</p>\n<p>В исходном коде Firefox для <code>network.http.response.timeout</code> указано значение 300 секунд. Это не обещание для всех выпусков: настройки Firefox могут меняться. В вашей версии значение может отсутствовать, быть переопределено политикой или работать иначе в конкретном сетевом сценарии. Проверяйте фактическую строку и версию браузера.</p>\n<ol><li>Зафиксируйте URL, время запроса, этап задержки и исходное значение параметра. Удалите секреты из заметки.</li><li>Повторите запрос в Network Monitor, затем тем же URL выполните ограниченную учебную проверку через другой HTTP-клиент.</li><li>Сверьте таймауты приложения, веб-сервера, reverse proxy, балансировщика и внешних зависимостей. Найдите минимальный предел, который может закрыть соединение.</li><li>Откройте в Firefox страницу <code>about:config</code>. Примите предупреждение только в профиле, предназначенном для диагностики.</li><li>Найдите <code>network.http.response.timeout</code>. Измените значение в секундах на небольшой срок, достаточный для проверки гипотезы, например 600 для учебного сценария.</li><li>Повторите тот же запрос с теми же входными данными. Сравните этапы Timings, статус, размер ответа и серверный лог.</li><li>После проверки верните исходное значение или нажмите Reset у изменённого предпочтения. Повторите запрос и убедитесь, что профиль не сохранил лишнюю настройку.</li></ol>\n<p>Не отключайте таймаут полностью. Бесконечное ожидание удерживает вкладку и сетевые ресурсы, затрудняет отмену и прячет отказ. Не ставьте несколько часов только потому, что операция однажды работала дольше минуты. Значение должно следовать из измеренного верхнего предела и запаса, а не из случайного числа.</p>\n<h2>Когда настройка не подходит</h2>\n<p>Если отчёт или импорт занимает минуты, браузерный запрос уже плохо подходит для пользовательского интерфейса. Серверу лучше принять задачу, вернуть идентификатор и выполнять работу в очереди. Клиент затем опрашивает статус или получает событие о завершении. Такой путь показывает прогресс, допускает повторную загрузку страницы и отделяет жизненный цикл задачи от вкладки.</p>\n<p>Для операций, которые меняют данные, одного увеличения timeout недостаточно. Браузер может не узнать, успел ли сервер сохранить запись до обрыва соединения. Повторный клик может создать дубликат. Используйте идемпотентный ключ операции, журнал состояния и явный способ узнать результат. Эти меры относятся к приложению, а не к Firefox.</p>\n<p>Если проблема возникает только в корпоративной сети, сравните прямой доступ и путь через прокси только с разрешения владельца сети. Не обходите политики безопасности и не меняйте TLS-проверки ради долгого запроса. Если сбой связан с DNS, VPN или маршрутом, response timeout не исправит доставку.</p>\n<p>Если параметр не найден, не создавайте его автоматически. Сначала проверьте версию Firefox, политику управления браузером и документацию к вашему выпуску. Создание неизвестного предпочтения может ничего не изменить и создаёт ложный след диагностики.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Диагностика завершена, когда вы можете назвать этап задержки, владельца этого этапа и предел, который закрывал соединение. Тот же запрос должен воспроизводимо пройти в выбранном тестовом профиле. В Network Monitor должны совпасть ожидаемый статус, TTFB или время передачи, размер ответа и финальный результат. Серверный лог должен содержать соответствующую операцию.</p>\n<p>Для временной настройки добавьте ещё два условия: исходное значение записано, а после проверки оно восстановлено. Если исправление требует постоянного увеличения таймаута для всех пользователей, оформите его на стороне приложения и инфраструктуры с измерением, лимитом и планом отмены. Изменение <code>about:config</code> в личном профиле не считается исправлением production-проблемы.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://support.mozilla.org/en-US/kb/about-config-editor-firefox\" target=\"_blank\" rel=\"noopener noreferrer\">Mozilla Support: Configuration Editor for Firefox</a> — официальная инструкция по открытию, поиску, изменению и сбросу расширенных предпочтений; страница предупреждает о рисках <code>about:config</code>.</li><li><a href=\"https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js\" target=\"_blank\" rel=\"noopener noreferrer\">Mozilla Searchfox: Firefox default preferences</a> — исходный файл Mozilla с декларацией <code>network.http.response.timeout</code>; значение и расположение могут измениться в будущих версиях.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Fundamentals\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Performance fundamentals</a> — официальная документация MDN о проверке сетевых запросов в Firefox Network Monitor и измерении задержек.</li></ul>"
|
||
}
|