Проблемы начинаются при попытке обдумать практическую сторону:
- в каком формате хранить эти индексные файлы?
Предлагаю следующую общую структуру файла индекса, лежащего в корневой папке каждого хоста:
1. Заголовок (1 Б):
- номер версии (для возможности адаптации под последующие изменения структуры индексного файла) - 1 Б
2. Данные по хосту (~ 17 - 34 Б):
- имя - ~ 17 Б (взята средняя длина имени хоста по собственному кэшу)
- ? размер папки в кэше (для целей реалтаймового подсчета размера кэша) - 4 Б (размер папки до 32 ГБ)
- версия HTTP (для учета в случае возможной оптимизации запросов) - 1 Б
- IP-адрес (для целей кэширования DNS) - 4 Б
- время последнего обновления IP-адреса (для кэширования DNS) - 8 Б
3. Метаданные по файлам хоста (~ до 300 Б / файл):
- имя без имени хоста - до 200 Б
- код ответа сервера (для кэширования ответов 3xx и 4xx) - 1 Б
- дата последнего доступа (для автоматической очистки кэша) - 8 Б
- Last-Modified (для формирования If-Modified-Since) - 8 Б
- Date (для проверки критерия свежести и
предугадывания) - 8 Б
- Expiration time - 8 Б
- Content-Type, если формат НС не распознает самостоятельно либо распознает, но результат не совпадает с полем ответа. Еще лучше, имхо, сохранять все и исключить из НС код распознавания - ? Б
- Content-Encoding, если кодировку НС не распознает самостоятельно либо распознает, но результат не совпадает с полем ответа. Опять же, лучше, имхо, сохранять все и исключить из НС код распознавания - ? Б
- Cache-Control: no-cache (вместе с Pragma: no-cache), must-revalidate, мож еще какие директивы управления кэшем (для опционального обеспечения стандартного /как велит rfc2616/ поведения НС при желании пользователя) - 1 Б
Полям индексного файла можно присвоить уникальные однобайтовые идентификаторы, которые будут предварять начало каждого поля. Таким образом, при отсутствии соответствующих данных в ответе сервера либо нецелесообразности их сохранения можно будет смело не записывать их в индексный файл.
В процессе нахождения файла индекса в памяти к данным блока 3 можно добавлять тело файла (в случаях, когда сейчас файл считывается в RAM-кэш). Таким образом, индекс, на мой взгляд, способен заменить и DNS, и RAM-кэши.
Отдельно по поводу полноценности замены DNS-кэша. Если мы ни один файл из хоста не пишем в кэш или удаляем всю папку хоста из кэша, то отказываемся от экономии и, вероятно, не планируем туда возвращаться. Зачем тогда держать запись DNS для такого хоста? По-моему, хранение DNS в индексе все-таки оправдано. Как минимум тем, что все рядом, а также не надо хранить в памяти параллельную структуру с повторением в ней имен хостов.
Еще вопрос - в качестве имени хоста и файла хранить:
- имя до преобразования URL2File?
- преобразованное имя?
- то и другое?
