по корнер-кейсам согласен, лимита на размер письма и таймаута на чтение в текущей версии нет, raw_bytes растёт неограниченно пока не придёт терминатор. это реальная дыра, поправлю.
по imap idle не соглашусь. там нужно хранить логин и пароль пользователя от его почты, это принципиально другой уровень риска и ответственности, чем форвардинг на служебный адрес, где я вообще не вижу и не храню чужие credentials. плюс это отдельное живое соединение на каждого юзера к чужому imap-серверу, с чужими лимитами и обрывами, у меня таких юзеров сотни.
по готовому exim в докере тоже не соглашусь. очередь, ретраи, dkim, spf, конфиги под виртуальные домены, systemd-юниты, логротейт, это тоже зоопарк функциональности со своими корнер-кейсами, просто чужими. для задачи "принять письмо на известный адрес и переслать его конкретному юзеру" это избыточно.
про то что человек всё равно бутылочное горлышко, тут отчасти согласен, это уже вопрос приоритетов а не архитектуры. но даже если финальный ответ фрилансера займёт минуты, скорость самого уведомления имеет смысл сама по себе, кто увидел заказ на минуту раньше конкурента, у того выше шанс успеть откликнуться первым.
насчёт окон и hol, тут по делу, per-stream окно я не учёл, а hol на уровне tcp и правда никак не лечится склейкой файлов, раз всё идёт через одно соединение. если честно, объяснял это тогда интуицией, а не разбором механизма, и явных доказательств что склейка что-то ускорила у меня нет, кроме сокращения числа отдельных http-запросов. cdn был единственным подтверждённым фиксом, и он закрыл проблему полностью сам по себе. надо было в статье сразу так и написать, а не пытаться подкрепить довесок теорией которая не выдерживает проверки. поправил блок в статье, спасибо
про clienthello - тут да, обычные девтулзы этого не покажут. смотрели через chrome://net-internals на компе у одного из юзеров, там видно что рвётся именно на этапе рукопожатия.
про склейку бандла - справедливое замечание. cdn там и правда основной фикс, он закрыл проблему с каналом полностью, а склейка бандла это уже была доп подстраховка сверху, не более того. решение принято в 2 ночи, без замеров до/после именно на cdn, чисто чтобы убрать лишнюю точку отказа раз уж всё равно копался в сети. если бы это был единственный фикс без cdn, я бы сначала померил. по мере роста проекта вернём нормальный vendor-chunking, но пока для моего масштаба (нечастые деплои, небольшое приложение) склейка себя оправдывает.
про ech в tls 1.3 - на сервере его не включали, но провайдеры у нас его реально режут наглухо. вполне вероятно что у части юзеров браузер пытался подтянуть ech и соединение тупо падало на clienthello.
про http2 согласен, я там уже обновил и переписал этот блок в статье. при http2 соединение одно и мультиплексирование работает. проблема была именно в качестве самого канала до зарубежного ип. при потере пакетов на плохом канале проявляется head-of-line blocking и пачка стримов начинает отваливаться по таймаутам. плюс внешняя зависимость telegram.org зависала сама по себе.
переезд на московские ноды selectel cdn как раз и закрыл проблему с каналом. а склейка бандла была уже вторичной историей чтобы убрать лишние rtt.
по корнер-кейсам согласен, лимита на размер письма и таймаута на чтение в текущей версии нет, raw_bytes растёт неограниченно пока не придёт терминатор. это реальная дыра, поправлю.
по imap idle не соглашусь. там нужно хранить логин и пароль пользователя от его почты, это принципиально другой уровень риска и ответственности, чем форвардинг на служебный адрес, где я вообще не вижу и не храню чужие credentials. плюс это отдельное живое соединение на каждого юзера к чужому imap-серверу, с чужими лимитами и обрывами, у меня таких юзеров сотни.
по готовому exim в докере тоже не соглашусь. очередь, ретраи, dkim, spf, конфиги под виртуальные домены, systemd-юниты, логротейт, это тоже зоопарк функциональности со своими корнер-кейсами, просто чужими. для задачи "принять письмо на известный адрес и переслать его конкретному юзеру" это избыточно.
про то что человек всё равно бутылочное горлышко, тут отчасти согласен, это уже вопрос приоритетов а не архитектуры. но даже если финальный ответ фрилансера займёт минуты, скорость самого уведомления имеет смысл сама по себе, кто увидел заказ на минуту раньше конкурента, у того выше шанс успеть откликнуться первым.
насчёт окон и hol, тут по делу, per-stream окно я не учёл, а hol на уровне tcp и правда никак не лечится склейкой файлов, раз всё идёт через одно соединение. если честно, объяснял это тогда интуицией, а не разбором механизма, и явных доказательств что склейка что-то ускорила у меня нет, кроме сокращения числа отдельных http-запросов. cdn был единственным подтверждённым фиксом, и он закрыл проблему полностью сам по себе. надо было в статье сразу так и написать, а не пытаться подкрепить довесок теорией которая не выдерживает проверки. поправил блок в статье, спасибо
про clienthello - тут да, обычные девтулзы этого не покажут. смотрели через chrome://net-internals на компе у одного из юзеров, там видно что рвётся именно на этапе рукопожатия.
про склейку бандла - справедливое замечание. cdn там и правда основной фикс, он закрыл проблему с каналом полностью, а склейка бандла это уже была доп подстраховка сверху, не более того. решение принято в 2 ночи, без замеров до/после именно на cdn, чисто чтобы убрать лишнюю точку отказа раз уж всё равно копался в сети. если бы это был единственный фикс без cdn, я бы сначала померил. по мере роста проекта вернём нормальный vendor-chunking, но пока для моего масштаба (нечастые деплои, небольшое приложение) склейка себя оправдывает.
про ech в tls 1.3 - на сервере его не включали, но провайдеры у нас его реально режут наглухо. вполне вероятно что у части юзеров браузер пытался подтянуть ech и соединение тупо падало на clienthello.
про http2 согласен, я там уже обновил и переписал этот блок в статье. при http2 соединение одно и мультиплексирование работает. проблема была именно в качестве самого канала до зарубежного ип. при потере пакетов на плохом канале проявляется head-of-line blocking и пачка стримов начинает отваливаться по таймаутам. плюс внешняя зависимость telegram.org зависала сама по себе.
переезд на московские ноды selectel cdn как раз и закрыл проблему с каналом. а склейка бандла была уже вторичной историей чтобы убрать лишние rtt.