Чайник из Юты

Я всё ещё жду, когда кто-то поставит сюда огоньки

У двоих, которые спали в соседней камере, в мгновение вскипела кровь и мозги. Интересно, можно ли это записать в тихую смерть во сне?

https://zero.sci-hub.se/5268/7dda7cee52d7eb3ec606a82d0f1b9a61/giertsen1988.pdf

Забавная ситуация с мгновенной декомпрессией 9 атмосфер. А вот фото человека, в следствии поместившегося в зазор 12.7см, уже не такое забавное

Да это же литералли ми

3 лучших контрибьютора в индиго

this is REAL Unicode emoji proposal done by REAL people

На каждую операцию чтения либо записи в сокет, я указываю дедлайн - таймаут, после которого операция зафейлится. При чтении я, например, таким образом могу отсекать idle подключения. Там нужно указывать абсолютное значение: ну, то есть, вот это вот time.Now().Add(90*time.Second). И я заметил, что это как-то... Дороговато! 50нс, если быть точным. Дорого, потому что я обычно в 500-600нс суммарно укладываюсь, вместе с парсингом, обработкой и формированием ответа

Не то, чтобы это особо интересно было, просто довольно занятный кейс. Я это дело оптимизировал посредством atomic.Int64, в который кладу раз в 500мс текущее время из отдельной горутины. 55нс превратились в 5.6нс. Нраица!

А, нет, я дегенерат. Я блять адрес передавал в ListenTCP() вместо network. А должен был литерал "tcp". Ну теперь-то ебать работает

За хотдоги спасибо, но у меня тут забавная ситуация. Я начал тыкать напрямую net.ListenTCP, чтобы иметь не-виртуальный метод SetDeadline() на листенере. Нюанс в том, что конструктор принимает *net.TCPAddr, который сначала надо ещё получить. Получаешь через net.ResolveTCPAddr(). А в него нельзя засунуть 0.0.0.0 - заглушка, которая слушает на всех интерфейсах - в отличии от net.Listen. Там, почему-то, всё работает нормально. И я всё никак вдуплить не могу, где именно здесь происходит эта магия

Вот у меня сущность приложения (indigo.App) довольно тупая, и принимает роутер только когда жмакают app.Serve(). Поэтому, на сколько портов индигу не вешай, роутер будет один и тот же использоваться. Из-за этого и появился virtual.Router, который берёт запрос, и перенаправляет его в соответствующий роутер. Но мне вот какая мысль пришла: это ведь можно и более элегантно реализовать!

Вот я навешиваю аппу на разные порты через App.Bind(addr). Я могу сюда же роутер и прокидывать! Всё равно на каждом порту свой листенер (каждый в своей горутине), тогда ещё и косты на виртуальный роутинг сводятся к нулю (сейчас там перебор массива на каждый запрос, в надежде, что доменов будет немного - если меньше 7, тогда норм). Но и прокидывать в прям каждый App.Bind() роутер отдельно не хочется (например, аргумент пришлось бы дублировать в ситуациях, когда я хочу навесить аппу на хттп и хттпс). Есть вариант - если в бинде не указан роутер, будет использован роутер, указанный в предыдущем бинде. Либо дефолтный (который будет передаваться так, как передается и сейчас - через App.Serve(r)). Сохраняется обратная совместимость, но общий Developer Experience ухудшается - какая-то магия, везде вариадики.

Но, сука, фича-то сладкая, так и манит гадина. Я сейчас и так тот единственный переданный роутер в аппу передаю каждому листенеру по отдельности, а листенер у меня - замыкание, поэтому, возможно, можно будет добавить какую-нибудь заглушку а-ля App.Bind(":8081", Virtual(TCP, r2)), где r2 - это роутер для какого-нибудь другого домена от переданного в последующий App.Serve(r). Не без дизайнерских проблем, но и с TLS тоже зафурыкает.

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

Та ебать

Bro writing about the most unnecessary feature of his pet-project with 46 likes:

bro writing a text for school

Но меня сейчас интересует другое. Серты с летсэнкрипта выписываются на 90 дней. То есть, каждые полтора месяца нужно их обновлять. Тут есть 2.5 варианта, как мне это делать:
1) DNS челленджи. Это когда в TXT поле кладёшь специально составленную строку, которая включает в себя токен от летсэнкрипта. Таким образом, сервис может быть уверен, что мы правда владеем доменом.
2) http и alpn челленджи. По сути, оба монофаллические, просто alpn через tls идёт. С http суть проста - открываешь на вебсервере ресурс /.well-known/acme-challenge/<token>, где token - как раз таки тот токен, который тебе летсэнкрипт и даст. За этим ресурсом должен лежать файл, в котором будет содержаться инфа по регистрации, и сам токен.

Собственно, я люблю циферки. Я на них дрочу, неистово, с неподдельным возбуждением. И мне становится очень грустно, перезагружать вебприложение каждые полтора месяца, чтобы обновлять сертификаты, тем самым теряя месячные аптаймы. Чисто технически, можно совершенно без проблем обновлять их на ходу - на момент обновления, просто делаем доступным такой ресурс на сервере, и кладём туда нужные данные. Получаем сертификаты - перезагружаем тлс листенер (да, клиентам придётся испытать тряску, но разрыв подключения на одну секунду раз в полтора месяца не смертелен; кому смертелен - тот будет использовать днс челленджи). Вуаля! Теперь индига может спокойно работать годами безостановочно. Один лишь недостаток - мне тогда придётся половину ACME самостоятельно имплементировать, чтобы это всё себе интегрировать. И хуже всего как раз таки с днс челленджами тогда придется - но, думается мне, здесь уж можно будет оставить ответственность на пользователе. А вынести метод "App.RenewCertificate()` мне всё равно придется, если я действительно буду это делать. И тогда уж точно можно будет киллерфичей назвать - пускай это и заботы реверс-прокси, зато можно будет теперь индигу саму как реверс-прокси ставить:)

Тогда уж надо будет столько всего интересного добавлять, дабы оно всё работало сносно и удобно. Но это уже тема совершенно иных лонгридов...

Но это лишь затравка (уж простите, нелюбители долгобукв). Сам сок происходит в методе App.AutoHTTPS(), который инициализирует tls листенер, в который прокидывает сертификаты автоматически. Проверяет, вешают автохттпс на домен ли, чтобы сунуть автосерт, а вот если вешают на ip адрес - ну, с летсэнкриптом (дефолтным провайдером у автосерта) сертификаты не выпишешь. Нет домена - нет сертификата. Вроде логично. На IP адреса я самостоятельно серты выписываю. Спойлер - идея плохая, для этого есть mkcert, который юзает локальный CA, чтобы браузеры меньше на говно исходили.

Ну и вот это - есть костыль. Я, например, намеренно упустил возможность того, что туда сунут ипв6, потому что имплементировать банально лень. Да и я без понятия, как оно себя поведёт, если сунуть туда чужой домен. Скорее всего, просто зафейлится tls.NewListener(), и тогда, если немного подождать, завершится и tcp листенер, после чего работа будет завершена. Но это лишь предположение. Проблема лишь в том, что самым выгодным решением будет, убрать нахер все те проверки "а домен ли это" (задача не так проста, как кажется на первый взгляд) и просто пытаться выписать с ACME себе сертификаты на переданный адрес. Не получится - значит, берём mkcert. Собственно, так я сделать и хочу - возможно даже, заменив по пути autocert на lego. Но там блоата многовато (автосерту почтение - всё в одну кнопку делается), придётся для начала говно разгребсти ещё. Но выглядит поинтереснее, честно говоря. За киллерфичу, конечно, хотелось бы выдать, да только кому нынче хттпс в вебфреймворке нужен. Каждый первый дебил дальше нжинкса его и не нюхал. Жаль.

Собственно, по поводу хттпс.

Я посидел, покумекал, понял - мирного решения не будет.

Ну, то есть, вот у меня была такая тема, что я мог вешать индигу на несколько портов. Естественно, добавил на один уровень вглубь больше: можно прокидывать свои листенеры. Листенер просто возвращает имплементацию интерфейса net.Listener, и дальше уже индига сама с этим разбирается. Минус - нельзя прокидывать через запрос инфу о том, запрос прилетел по зашифрованному каналу, или нет, а это важно - иначе даже нельзя автоматический редирект на хттпс сделать, помимо как прибегать к HSTS правилам. А это, мягко говоря, не совсем то, чего я ожидаю от проекта.

Поэтому расширяем функционал - теперь можно прокидывать ещё и кастомные хендлеры вместе с листенерами. Под хендлерами подразумевается функция, которая будет отрабатывать каждый раз, как мы имеем новое подключение. Обычно, оно просто тыкает serve.HTTP1(). То есть - ручками зафурычивает хттп движок. Вот где-то на этом этапе я и кладу в объект запроса инфу о том, по защищённому ли каналу был получен запрос. В этом у меня ещё состоялся потенциал добавления хттп2, но о нём попозже.

А вот как это реализовано - ну просто страшная ебака - задействованы фабрики, хуябрики, и господь-упаси-какие-ещё-сущности-из-джавы. Встала проблема - на этом механизме у меня построен хттпс, в гибкости терять нельзя, а привести в порядок - хочется. Решение, кажется, вполне очевидное - вообще убрать из скоупа ответственности net.Listener. Пусть у нас будет просто хендлер - только теперь он ещё и за accept-loop отвечает (accept-loop'ом обычно называют цикл приёма новых подключений). То есть, он у нас теперь суперсолдат - подключения прими, хттп ядро ткни, так ещё и следи за тем, когда тебе скажут остановиться (через *atomic.Bool, кстати; нужно для graceful shutdown). Становится хорошо: код становится проще, избавляемся от довольно ёмких сущностей, оставляя лишь супервизор, который будет следить за тем, чтобы если ошибка произошла в одном хендлере - остановить все остальные. Теперь можно написать хендлер чисто для tcp, а в net.TCPListener есть возможность устанавливать таймаут на accept - это очень хорошо, раньше я оперировал с net.Listener, и должен был проверять низлежащую реализацию на наличие такого метода, что не есть очень приятно. А здесь спокойненько себе. Да и с тлс попроще стало - tls.Listener() просто оборачивает низлежащий листенер. Спокойно могу проинициализировать самостоятельно net.TCPListener для него, и повторить фокус с обычным tcp хендлером. Одним словом - хорошо.

Ниже продолжение

Ебать. Сел переписывать ебанутое и непонятное говно, которое я наворотил с кастомными листенерами в аппликейшене. Вкратце - нужен был хттпс, для хттпс нужно повесить тлс листенер на отдельный сокет. И вот я сделал так, чтобы можно было добавлять свои листенеры, и тогда дальше оно у себя там само разберется с тем, чтобы обрабатывать пакеты с них со всех.

Там такие костыли пошли, что просто ужас. Какие-то фабрики, хендлеры, хуй пойми что вообще. Я-то просто хотел сделать так, чтобы можно было указывать версию тлс в объекте запроса, который мы получили по безопасному каналу.

Заодно и узнал, что, оказывается, чтобы прерывать listener.Accept() по таймауту, не нужно городить горутину, канал и селект с time.After, а достаточно просто навесить на него самый обычный дедлайн.

Совершенная мелочь привела меня в результате к тому, что приходится перелопачивать половину приборной панели. А, кстати, там ещё 5 лет как Deprecated: SSLv3 is cryptographically broken, and is no longer supported by this package. See golang.org/issue/32716.