Запрет Firefox обхода дисковых кешей в запросе (как отключить «Race Cache With Network»)? - PullRequest
2 голосов
/ 12 февраля 2020

Начиная с версии 59, Firefox имеет функцию под названием Race Cache With Network (RCWN). Если Firefox обнаружит, что диск работает медленно, он может решить начать сетевые запросы немедленно, не дожидаясь кэша. Это компромисс: если сетевые запросы выигрывают гонку, задержка улучшается; если выигрывает кэш, пропускная способность сети теряется.

Это полезная функция, но есть один сценарий, в котором она нежелательна. Предположим, WebExtension необходимо обновить ресурсы в фоновом режиме (например, один раз в час). Задержка здесь не важна, хотя правильное кэширование крайне важно, так как вам нужно платить за исходящий трафик c на стороне сервера.

Мой вопрос заключается в том, как отключить RCWN на уровне запроса. Как вы можете создать запрос (через fetch или XMLHttpRequest), который всегда будет сначала проверять кеш, а только потом выдавать сетевой запрос. Другими словами, никогда не гонитесь и никогда не обходите кеш.

Я знаю, что эту функцию можно отключить с помощью конфигураций (network.http.rcwn.enabled), но это не решение. Во-первых, вам нужно убедить каждого пользователя изменить это предпочтение. Во-вторых, RCWN - полезная функция, которая обеспечивает ценность при обычном серфинге, где важна задержка. Если заставить пользователей отключить его, это приведет к неоптимальному просмотру.

Существует небольшая документация по RCWN, которая ожидает, что эти слайды , но я нашел ее реализацию в исходном коде Firefox :

nsresult nsHttpChannel::OpenCacheEntryInternal(...) {
  ...
  if (sRCWNEnabled && maybeRCWN && !mApplicationCacheForWrite) {
    bool hasAltData = false;
    uint32_t sizeInKb = 0;
    rv = cacheStorage->GetCacheIndexEntryAttrs(openURI, extension, &hasAltData,
                                               &sizeInKb);

    // We will attempt to race the network vs the cache if we've found
    // this entry in the cache index, and it has appropriate attributes
    // (doesn't have alt-data, and has a small size)
    if (NS_SUCCEEDED(rv) && !hasAltData &&
        sizeInKb < sRCWNSmallResourceSizeKB) {
      MaybeRaceCacheWithNetwork();
    }
  }
  ...
}

Я пытался понять понятие «alt-data», но не смог найти никаких источников. Насколько я знаю, это означает альтернативные данные. Может ли это быть использовано (либо сервером, либо через запрос клиента), чтобы заставить кэшированные данные быть помеченными как alt-data, чтобы гонки не происходили?

Еще одна идея, которая у меня была: в выборке запрос, клиенты могут установить Cache-Control: only-if-cached, но это меняет семантику c. Он должен остановить гонки, но если нет попадания, он вернет устаревший результат и не спросит сервер. Может быть, это можно было бы использовать, чтобы сначала попробовать такой запрос, и только потом сделать реальный сетевой запрос. Не очень элегантно, хотя. Есть ли лучшее решение этой проблемы?


Примечания: для получения дополнительной информации Firefox позволяет анализировать RCWN через about:networking#rcwn, а кеш через about:cache. Если вы проверите RCWN, вы увидите, что гонки не так уж редки, даже если у вас есть SSD. В сетевом мониторе обработанные запросы будут помечены в переданном столбце, например, как 100.86 KB (raced).

1 Ответ

0 голосов
/ 24 февраля 2020

Поскольку WebAssembly. {CompileStreaming, instantiateStreaming} оба принимают Response, у нас есть ссылка на исходную запись кэша, поэтому мы можем использовать API alt-data (в настоящее время используемый кэшем байт-кода JS) для кэширования компьютера. код. Позже, с интеграцией wasm-esm (https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration), мы могли бы дополнительно подключиться через nsScriptLoader.

Это предназначено для включения явного кэширования IDB, которое недавно было удалено из wasm spe c (ошибка 1469395) и побейте неявный asm. js кэширование, которое мы делаем в dom / asmjscache. Ядро (де) механизма сериализации все еще присутствует (и активно используется asm. js кешированием).

Существующая поддержка потоковой передачи wasm, на которой она будет основываться, - FetchUtil :: StreamResponseTo JS: https://searchfox.org/mozilla-central/source/dom/fetch/FetchUtil.cpp#530 и интерфейс alt-data, который нам нужно использовать, это nsICacheInfoChannel, который позволяет нам получить поток для сериализованного модуля.

Похоже, нам потребуются некоторые скромные изменения в alt- API данных: ошибка 1487100. Тем временем, мы можем получить что-то вроде работы, безоговорочно установив предпочтительный тип alt-data «wasm» в fetch ().

Когда alt-data реализован для DOM Cache API (ошибка 1336199), эта же поддержка должна работать только для DOM Cache / ServiceWorker, что, возможно, предоставит доступ к большей квоте и меньшему оттоку.

...