Исходное сообщение
"Mozilla внедряет CRLite для проверки проблемных TLS-сертифик..." Отправлено Аноним84701, 13-Янв-20 20:19
> Даже не смотря на сотни мегабайт, это определенно лучше, чем пинок на левые сервера по одному урлу То ли я чего-то фатально не понял, то ли там сильно лукавят c "гигабайтами" и размерами БД: > Например, в бинарной форме используемые при генерации исходные данные требуют около 16 ГБ памяти при хранении в СУБД Redis, а в шестнадцатеричном виде дамп всех серийных номеров сертификатов занимает около 6.7 Гб > ... > БД отозванных сертификатов занимает около 300 МБ Конечному пользователю не нужно хранить базу быстрого доступа или номера всех 100 млн. активных сертификатов (что и не далается и в сабже).  Т.е. 16ГБ памяти - это сугубо "проблемы мозилы при генерации сабжевой структуры". Конечному пользователю нужна только возможность (быстро) проверить, нет ли среди 750 000 отозванных определенного сертификата. Для этого достаточно передать список первых 128 или 64 бит или даже 32 (если уж учитывать возможность теста на ложные срабатывания) хеша этих сертификатов. А это: 750 000 * 16 = 12МБ или 750 000 * 8 = 6МБ, 750 000 * 4 = 3МБ. Однократно. В принципе, те же яйца в профиль, но передавая хеши, а не готовую структуру данных, имеем намного меньше проблем с обновлениями. Т.к. в отличие от сабжа (где, насколько я понял, каждый раз генерируется новая структура данных, сильно отличная от предыдущей, так что дельта-обновления "получаются неоправданно большими" ) можно при запросе просто передавать список хешей добавленных после определенной даты сертификатов, который [список] клиент самостоятельно добавит в базу – а не каждый раз заставлять качать полностью новую структуру размером в мегабайт.