Кстати, интересный способ я подсмотрел во все том же файлике у них. А именно - парсить константные подстроки.

Под константными подстроками подразумеваются такие подстроки, которые вообще всегда одинаковые. Таким, например, является префикс HTTP/ в версии протокола (напоминаю: в плейнтексте маска протокола выглядит, как HTTP/1.1). Собственно, на этом примере я и узнал об этом

В этом, на самом деле, ничего особого нет. Но я, например, сначала так не сделал, поэтому может кому и полезно будет

Собственно, у нас же вот есть парсилка запросов хттп, так? И в ней есть состояния? Так почему бы не сделать посимвольное сравнение на состояниях? Ну, то есть, буквально захардкоженное префиксное дерево, но с сохранением состояния. Да, мы буквально посимвольно сравниваем каждый байт. Покажу на картинке ниже. В индиге, кстати, так сложилось, что выгоднее было это не реализовывать

Собственно, а какие еще у этого применения есть? Ну, например, можно использовать в жсон парсерах. true, false, null - это все тоже константные подстроки, так-то.

Оказывается, чтобы включить режим HTTPS only, можно не просто редиректить на идентичный url, только со scheme https (как это пока что работает у меня; см. пикрил)

https://https.cio.gov/hsts

Но есть нюанс: использование HSTS угробит мне самоподписанные сертификаты для локалхоста

Фанфакт: в среднем, чтобы загрузить веб-страницу, браузеру приходится сделать 70 дополнительных запросов для подгрузки ресурсов

https://httparchive.org/reports/page-weight#reqTotal

Да, Паша занимается экстримальным программированием. Я бы даже назвал его экстримистом

SSL vs. TLS

SSL изначально разработали в Netscape (если помните такой браузер). Аббревиатура расшифровывается, как Secure Sockets Layer. Его первая версия, SSLv1, была чисто внутренним продуктом, зато на продакшн выкатили уже SSLv2 и SSLv3. Но это была конкретно разработка компании, нежели стандарт, хоть де-факто таковым оно и являлось. Потом Netscape разорился, и на рфс выкатили бумаги по SSLv3 в качестве historic document. На его основе появился TLSv1, похожий, но не совместимый. Потом TLSv1.1, 1.2, и, наконец, в 2018 - TLSv1.3. Несмотря на то, что тлс был лучше и безопаснее, SSLv3 все равно считали достаточно надежным и продолжительное время использовали все же его, даже если клиент поддерживал TLS. Но вот, в какой-то момент пришли умники в очках, и указали на критические уязвимости. Вот SSL больше и не используют.

P.S. в TLSv1.0 тоже понаходили. По итогу тоже начали форсировать повсеместную поддержку 1.1

Красивый хак с логарифмом по основанию 2

https://github.com/allegro/bigcache/blob/main/utils.go#L14-L16

pavlo.gay

А теперь попробуйте перевести страницу на английский

чет я тут тыкался и прям разъебало

Да я буду щитпостить в перерывах между техническими постами

На 14 февраля расскажу, что такое ALPN, и с чем его едят

ALPN - Application Layer Protocol Negotiation. Представляет из себя расширение TLS (в мейнстрим имплементациях появился с 14-16 года в среднем). Фактически - позволяет еще на этапе TLS хэндшейка выбрать используемый далее протокол. Тобишь, буквально: указываешь, какие протоколы поддерживаешь (все токены зарегистрированы в IANA) - клиент выбирает - и вы дальше уже это говно используете.

По этому механизму, например, преимущественное большинство браузеров и поддерживают хттп2 - вместо того, чтобы начинать общение с хттп1.1 и дальше уже через заголовок Upgrade обновляться. Хоть и этот способ рудиментарным не объявлен, таковым фактически он и является. Минусы - его поддерживать тоже придется. Но в целом, не критично.

Фанфакт: это расширение в 2014 ввел наш славноизвестный гугл.

Вообще, по моим наблюдениям, с 97 года веб очень сильно тянет гугл. Что хттп2 - стандартизированная спустя 3 года версия гугловского SPDY, что ALPN как основной способ налаживания хттп2 транспорта, что хттп3 (который просто http2-over-quic). В принципе, имея убийственную связку из одного из самых популярных браузеров (который еще и evergreen, но об этом в следующем посте), не менее популярного сайта, а также четвертого по популярности веб-сервера - гораздо проще вводить новые, экспериментальные технологии, и тестировать их в жестоком и кровавом бою

evergreen браузерами называют те, которые обновляются самостоятельно в фоне. То есть - без явных просьб пользователя. Звучит хоть и не очень хорошо, но все же считается больше хорошим тоном, нежели наоборот. Например, из-за того, что обновления IE были привязаны к обновлению операционной системы, чисто вечнозелеными их назвать было сложно. Отсюда и пошла головная боль фронтэндеров, когда сайт нужно еще и под IE оптимизировать

Код Хаффмана и почему он такой классный

Жил-был Дэвид Хаффман. И вот подумал он: если у нас одни символы встречаются чаще других, то почему мы используем одинаковое количество бит для каждого?

Подумано - написано: подсчитав, сколько каких символов используется, мы можем построить бинарное дерево, где тем дальше от корня, чем реже встречается символ. Почему бинарное, и зачем вообще?

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

Понятие "таблица Хаффмана" же - это просто соотношение символа к его коду Хаффмана, чтобы не нужно было для каждого символа перебирать все дерево в поисках. Обычно - простая хэшмапа, хоть в некоторых ситуациях и можно выдумать что-то поинтереснее (например - LUT, который имеют O(1) доступ, отлично применимы для ascii; где-то даже был пост об этом).

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

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

Хаффман, к слову, используется вообще много где. Начиная от jpeg, заканчивая hpack в http/2. В hpack ситуация вообще интересная: несмотря на то, что логичным было бы использовать как раз таки вариацию с динамической перестройкой дерева, они все же пошли по другому пути. Они взяли некое "большое число типичных запросов", и построили статическую таблицу уже на их основе

Всех подписчиков поздравляю с 8 марта