А ещё есть важная вещь которую кажется никто не упомянул об ООП. О том что автор этого самого ООП - Алан Кей предполагал совершенно другое. А то что сделал с++ это максимальное извращение и изнасилование первоначальных принципов ООП. Вот то что сейчас называют акторной моделью ближе всего к оригинальному ООП.
Тотже эрланг где нет ни объектов ни классов больше ООП(в понимании Алана Кея) чем плюсы или джава.
Всегда не нравился "чистный код", но вот назвать автора книги говнокодером у меня бы смелости не хватило.
То что в посте называется ФП на самом деле не особо функциональное программирование. Это скорее комбинация процедурного с использованием ФП. Популярно в go, в целом хорогий подход.
Если вам не хватает 8 килобайт для поисковых параметров, то это повод задуматься о том что у вас что-то серьёзно не так с архитектурой.
Честно говоря этот query это вредительство какое-то. Если это повсеместно внедрят, то:
1) Куча инфраструктуры заточеная только под классические http запросы сломается. От балансировщиков до библиотек для вывода логов
2) В первое время будут дыры в веб-серверах из-за кривой реализации 3) Нельзя просто скопировать URL и отправить другу 4) Усложняется создание "глубоких ссылок" (deep linking) 4) Кнопки вперед/назад в браузере будут работать некорректно. 5) Нельзя сохранить закладку с параметрами поиска без перепиливания всех механизмом закладок.
И это только что пришло первым в голову. Я конечно привык что веб со временем становится только хуже, но тут ребята прям на уровне стандартов "стараются"
UPD: а для сложных запросов из js уже был GraphQL и прочие.
Ну если у вас есть wireguard и хочется чтобы только заблокированное шло через него, то попробуйте: https://github.com/Jipok/dnsr Не особо костыльное. Делал чтобы было проще для юзера. Работает и не требует внимания уже пару месяцев.
Итого: первое соединение либо разрывается из-за несовпадения адресов, вызванных внезапной сменой маршрута, либо «зависает», по аналогичной причине. Последующие соединения (если IP-адрес тот же) будут устанавливаться успешно. Если у домена несколько адресов, аналогичные проблемы будут для каждого адреса.
...
Техническое решение этой проблемы однозначно осуществимо, но мне неизвестны ни готовые программы, ни даже наработки в эту сторону. Одна из тех проблем, где нужно просто взять и сделать ПО, но из года в год никто не делает.
К сожалению, я не видел вашего поста и пытался реализовать сам. Пришлось повозиться с отправкой RST, но зато я уяснил бесперспективность этого пути. Кажется что у ядра нет никаких механизмов "переиграть" соединение отданное в userspace. Но даже если с помощью ebpf или какого-нибудь модуля ядра получится красиво объединить/редиректнуть соединение, то не стоит забывать про сервер. Каждый запрос к заблоченному сайту будет каждый раз слать tcp-handshake, который хоть как надо отправить как есть. И моё кратковременное тестирование показало, что помимо того что браузер "ломается" от разрывов соединений, я стал очень часто видеть капчу по причине "Ваше запросы похоже на автоматические..."
Ну и программы могут использовать какой-нибудь свой протокол(или вообще любой помимо https). И запросы пойдут напрямую.
А если добавлять после первого подключения ip в таблицу маршрутизации чтобы система сама все запросы к этому ip проксировала, то какой смысл возиться с сетевым стеком, если можно поднять днс-сервер/прокси который также будет применять правила маршрутиризации? И ведь в этом случае будут работать любые другие протоколы. И UDP тоже.
Ну в теории. Я сейчас для себя использую вариант с чтением ответов от днс-сервера с помощью nfqueue. Все сайты работают отлично, роутер как будто вообще не ощутил нагрузки. Но вот в дискорде связь не работает. И я не пойму почему, а навыков в wireshark не хватает чтобы разобраться. Есть идеи?
Была ещё идея объединить прокси(который в master) с добавлением правил ip route. Сделать так, чтобы на прокси в userspace слались только первые соединения к новому для этой сессии ip. Прокси добавит нужное правило маршрутизации, ну а текущее соединение отработает в ручном режиме, ну с splice. Но тогда в таблицу маршрутизации придётся добавлять вообще все подярд ip и я не знаю как это скажется на системе.
И профит по сравнению с днс-прокси будет только если у клиента какой-нибудь не отключаемый dns over tls. Зато потеряется проксирование http/3 трафика, ибо у того sni не прочитать.
А ещё ведь из подобного массового неверного понимания есть REST API. С этим термином поступили ещё жёстче даже чем с ООП.
А ещё есть важная вещь которую кажется никто не упомянул об ООП. О том что автор этого самого ООП - Алан Кей предполагал совершенно другое. А то что сделал с++ это максимальное извращение и изнасилование первоначальных принципов ООП. Вот то что сейчас называют акторной моделью ближе всего к оригинальному ООП.
Тотже эрланг где нет ни объектов ни классов больше ООП(в понимании Алана Кея) чем плюсы или джава.
Ничего себе хабросуицид!
Всегда не нравился "чистный код", но вот назвать автора книги говнокодером у меня бы смелости не хватило.
То что в посте называется ФП на самом деле не особо функциональное программирование. Это скорее комбинация процедурного с использованием ФП. Популярно в go, в целом хорогий подход.
Распространённое заболевание среди java разработчиков.
Есть даже шедевр на эту тему: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Откуда 4? Там же 8 вроде по дефолту.
Но вообще ограничения веб сервера не имеет смысла рассматривать. Их же можно легко поднять.
Как получение связано с отправкой? Получать можно хоть несколько
десятков тысяч строкгигабайт.8000 символов это лимит на url. И то я по памяти сказал. Щас погуглил и нашёл такую инфу на момент сентября 2023го:
Chrome >64kAndroid >64kFirefox >300kSafari >64kИ 32 килобайта у cloudflare. Так что можно считать 32 килобайта безопасным.
Но вы ведь понимаете как оно на самом деле будет?
Если вам не хватает 8 килобайт для поисковых параметров, то это повод задуматься о том что у вас что-то серьёзно не так с архитектурой.
Честно говоря этот query это вредительство какое-то. Если это повсеместно внедрят, то:
1) Куча инфраструктуры заточеная только под классические http запросы сломается. От балансировщиков до библиотек для вывода логов
2) В первое время будут дыры в веб-серверах из-за кривой реализации
3) Нельзя просто скопировать URL и отправить другу
4) Усложняется создание "глубоких ссылок" (deep linking)
4) Кнопки вперед/назад в браузере будут работать некорректно.
5) Нельзя сохранить закладку с параметрами поиска без перепиливания всех механизмом закладок.
И это только что пришло первым в голову. Я конечно привык что веб со временем становится только хуже, но тут ребята прям на уровне стандартов "стараются"
UPD: а для сложных запросов из js уже был GraphQL и прочие.
роскомтеррор*
Будут отслеживать конкретные подключения чтобы найти частные vpn/прокси сервера?
Ну если у вас есть wireguard и хочется чтобы только заблокированное шло через него, то попробуйте:
https://github.com/Jipok/dnsr
Не особо костыльное. Делал чтобы было проще для юзера. Работает и не требует внимания уже пару месяцев.
Удивительно. Гугл свою хромуюось наоборот немножечко офлайн делает:
https://www.opennet.ru/opennews/art.shtml?num=62254
Их то за что?
Помню что вроде с джойреактора. Но вроде автор забросил своё творчество. Не подскажете как его зовут?
И обязательно ли ставить linux? Это же по идеи оверхед большой.
А подскажите, как оно по производительности в сравнении с минипеками на intel n100?
Что скажете о Sipeed LicheeRV и прочие одноплатники с SG2002?
Вайтлист через два года?
У меня кинопоиск иногда отваливался из-за того что
im0-tub-com.yandex.netв списке.К сожалению, я не видел вашего поста и пытался реализовать сам. Пришлось повозиться с отправкой RST, но зато я уяснил бесперспективность этого пути. Кажется что у ядра нет никаких механизмов "переиграть" соединение отданное в userspace. Но даже если с помощью ebpf или какого-нибудь модуля ядра получится красиво объединить/редиректнуть соединение, то не стоит забывать про сервер. Каждый запрос к заблоченному сайту будет каждый раз слать tcp-handshake, который хоть как надо отправить как есть. И моё кратковременное тестирование показало, что помимо того что браузер "ломается" от разрывов соединений, я стал очень часто видеть капчу по причине "Ваше запросы похоже на автоматические..."
Ну и программы могут использовать какой-нибудь свой протокол(или вообще любой помимо https). И запросы пойдут напрямую.
А если добавлять после первого подключения ip в таблицу маршрутизации чтобы система сама все запросы к этому ip проксировала, то какой смысл возиться с сетевым стеком, если можно поднять днс-сервер/прокси который также будет применять правила маршрутиризации? И ведь в этом случае будут работать любые другие протоколы. И UDP тоже.
Ну в теории. Я сейчас для себя использую вариант с чтением ответов от днс-сервера с помощью nfqueue. Все сайты работают отлично, роутер как будто вообще не ощутил нагрузки. Но вот в дискорде связь не работает. И я не пойму почему, а навыков в wireshark не хватает чтобы разобраться. Есть идеи?
Была ещё идея объединить прокси(который в master) с добавлением правил ip route. Сделать так, чтобы на прокси в userspace слались только первые соединения к новому для этой сессии ip. Прокси добавит нужное правило маршрутизации, ну а текущее соединение отработает в ручном режиме, ну с splice. Но тогда в таблицу маршрутизации придётся добавлять вообще все подярд ip и я не знаю как это скажется на системе.
И профит по сравнению с днс-прокси будет только если у клиента какой-нибудь не отключаемый dns over tls. Зато потеряется проксирование http/3 трафика, ибо у того sni не прочитать.