Как HTTP-кэши хранят кэшированные запросы? - PullRequest
0 голосов
/ 26 июня 2019

Как HTTP-кеши хранят свои запросы?Существует ли обычно используемый протокол для кэширования запросов или у каждой реализации есть свой метод кэширования?

РЕДАКТИРОВАТЬ : Под этим я подразумеваю, как серверы ФИЗИЧЕСКИ хранят кэшированные запросы, когда решение о кэшировании уже принято.

Я просматривал функциональность некоторых реализаций HTTP-кэша, таких как polipo , и обнаружил, что они хранят (по крайней мере) часть своего кэша в локальной файловой системе, но позже обнаружил, что кеши nginxфайлы / содержимое файла (имеется в виду, что есть более эффективный способ доступа к обналиченным запросам, чем их хранение в файловой системе).

Я поигрался с возможными идеями и попытался реализовать этот метод:

Hash request message -> store in a AVL -> access later using the hash value

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

И я использовал это как хеш-функцию:

static int hash( int size, request_t* bst_l) {

    unsigned long int hashval;
    int i = 0;

    // Convert our string to an integer
    while( hashval < ULONG_MAX && i < strlen( bst_l->MSG ) ) {
        hashval = hashval << 8;
        hashval += bst_l->MSG[ i ];
        i++;
    }

    return hashval % size;
}


, где размер - это размердерево AVL.

Исходя из этого, я ожидал уникальное значение хеш-функции для каждого уникального сообщения.Хотя я продолжаю получать одинаковые значения хеш-функции для разных запросов.Это из-за строки (hashval% size)?

Является ли вышеуказанный метод хорошим с точки зрения масштабируемости и эффективности?и если да, то хэш-функция соответствует ей правильно?Или есть более распространенный метод хеширования запросов?

Ответы [ 2 ]

2 голосов
/ 26 июня 2019

Чтобы ответить на ваши вопросы:

Как HTTP-кэши хранят свои запросы?

Это полностью зависит от клиента. Убедитесь, что вы соблюдаете заголовки кэша. См. Эту статью для получения дополнительной информации: https://www.keycdn.com/blog/http-cache-headers

Это из-за строки (hashval% size)?

Ну, да, это только дает вам size возможности.

Является ли вышеуказанный метод хорошим с точки зрения масштабируемости и эффективности? и если да, то хэш-функция соответствует ей правильно? Или есть более распространенный метод хеширования запросов?

Нет, похоже, это не работает, как вы заявляете. Смотрите этот ответ для правильной реализации:

https://stackoverflow.com/a/7666577/2416958


Из комментариев:

Серверная часть:

Это зависит от сервера. Это часто делается по-разному; Многие из них используют хэш и память. Но это не типично для http; это реализация сервера. Например, reddis .

Хеш (сервер) обычно генерируется на основе любого из них; URL-адрес вызова или домен, в котором он релевантен. Может быть пользовательской строкой, хешированной для быстрого доступа.


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

1 голос
/ 26 июня 2019

Это из-за линии (hashval % size)?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...