Думаю, что если сайт ловит даже по TLS Fingerprint, то поведение тупых скачивалок должен засекать мгновенно.
HTTP достаточно сложный протокол, чтобы его на коленке сделать и это не очень сильно отличалось от поведения браузера. Тот же keep-alive уже большая боль.
Сгенерировать куркод на условный bit.ly, который делает редирект на госуслуги, заодно меньше будет. Если сервис позволяет, то можно менять финальную ссылку, так что тату менять не придётся.
Отрицание с Any - это мина замедленного действия. На подобном запросе разваливался MySQL, Postgre в зависимости от фазы луны, оптимизатор MSSQL обычно догадывается до LEFT JOIN, но видно не всегда.
Вообще, если есть возможность и нужна скорость - то пробовать именно классические джойны, всё-таки на этой логике базы гораздо лучше работают.
Ну и иногда стоит играться с First/Single - в зависимости от ORM и базы данных могут весьма разные результаты получаться.
Программный интерфейс в виде приложения для смартфона с картой по этому NFC пообщается и код покажет.
Т.е. для подтверждения действия с телефона, нужно использовать приложение на телефоне? А давайте просто будем посылать SMS/Push'и на этот телефон и не напрягать пользователя отдельным приложением. Упс... кажется я где-то видел.
Онлайн-платежи (кроме супер доверенных марчантов вроде Amazon, Uber и т.п.) тоже нужно подтверждать через кардридер. (MasterCard 3d-secure).
Позанудствую, но 3D Secure просит не банк, а продавец. Т.е. Amazon не просит не потому что он такой доверенный весь из себя, а потому что он для удобства клиентов готов сам нести риски фрода. Остальным - гораздо проще (и дешевле) заюзать 3D Secure.
Как-то звонил провайдеру с проблемой, а т.к. чтобы прорваться через первую линию службы поддержки надо сказать код ошибки PPPoE, говорил всегда какой-нибудь левый, чтобы скрипт сломался. В итоге добрался до какого-то крутого дядьки, который мне звонил на личный номер со статусом — я тут мимо прохожу, давай зайду, никогда такой проблемы не видел.
Проблема оказалась в пережатом столом проводе, что давало линк, но и ничего больше.
Ведь заполненность в 100% бывает только в одном случае - мест на всех не хватило, и куча народа, условно говоря, осталась на вокзале. Т.е. полетела самолетом, поехала автомобилем или отказалась от поездки вообще. Что означает для РЖД упущенную прибыль.
Позанудствую. Для некоторых направлений заполненность может сильно варьироваться от дня недели, времени суток или самого направления. Т.е. возьмём условный поезд Москва-Нью Васюки. В пятницу вечером все ломятся из Москвы, заполненность 100%, назад - полупустой поезд. В понедельник с утра - всё наоборот. На неделе - обычная средняя загрузка. Из решений тут только тасовать количество вагонов, но с учётом того, что покупается конкретное место в конкретном вагоне — это весьма мутная логистическая задача.
Так что иметь возможность запихать больше пассажиров в вагон — идея для РЖД вполне здравая, т.к. позволит заработать больше в пиковых ситуациях.
Так говорить можно. Но если у кого-то не совпадает — значит что-то нечисто. Т.е. если организатор сказал лажу — это проблемы организатора. Все будут считать что прослушивают или организатора или его, а после обсуждения - выяснят, что прослушивают организатора.
Да, есть. SvcHostSplitThresholdInKB, если что, это сделано для надёжности (один падающий сервис не будет за собой все связанные тащить) и прозрачности (явно видно, кто плохо себя ведёт). Ну и в технических моментах тоже лучше. Побочка: жрёт гораздо больше памяти.
Если что, они ещё добавли Per-user service, т.е. сервисы, создающиеся спеацильно для пользователя, что тоже добавляет процессов и отжирает память.
Я так понял, что из-за того, что в будущем у вас будут проблемы (вас заставят прогнуться и вставлять рекламу), вам надо сделать платную версию, и жить от денег пользователей.
Это моя попытка осмыслить комментарий merhalak, а не мнение.
В своё время у Тинькова в приложении (в банке?) был баг с часовыми поясами. Был в стране, где время +1 от Москвы и в приложении все операции показывались только через час после совершения.
не верю :-) даже на самом китайском андроиде есть IKEv2 или какой-нибудь IPsec. Проверьте, пожалуйста, еще раз
Не буду делать скриншот, но есть:
PPTP, L2TP, L2TP/IPSec PSK, L2TP/IPSec RSA, IPSec XAuth PSK, IPSec XAuth RSA, IPSec Hybrid RSA.
Именно IKEv2 нету. Пользуюсь как раз «каким-нить» IPSec
Ну, автор статьи тоже радует :) А если в такой туннель завернуть ICMP, то и мониторинг внешних ресурсов также будет стабильнее. Давайте заменим один протокол другим, чтобы было стабильнее. А может сразу тогда использовать другой?
В общем, у автора свое видение проблемы, а тесты у него уж очень прямолинейные.
Он концептуально не может некоторые вещи сделать. Представьте разговор по условному Скайпу. Потерялся пакет — ну и фиг с ним, собеседник чуть хрюкнул, а тут поставится всё на паузу, пока повторный не придёт. Т.е. все ситуации, где UDP вводят ради скорости, ценой допустимых потерь — начинают вести себя плохо.
Тут можно ещё добавить, что в одном TCP-потоке множество соединений и страдать будут все.
А вот если реально плохая связь, то там может очень сильно всё нарастать (ретрансмиты внутри и снаружи туннеля).
Но вот то, что снаружи это фактически HTTPS (хотя и с неестественным профилем трафика) — это огромный плюс. Ну и второй плюс, что из-за этого, это самый стабильный VPN, пролезающий через любые наты.
А с HTTP3, боюсь, что к тому времени в России просто запретят UDP, как нежелательный протокол :)
Отвечу про SSTP. У него главный недостаток — TCP. Для туннелей это очень неправильно. HOL, потери пакетов и всё такое. В целом жить можно, но если связь не очень хорошая, то начинают сильно эскалироваться проблемы. Ну и накладные расходы из-за этого выше.
В кафешках попадаются часто. Настроены n-лет назад, работают и их не трогают.
Думаю, что если сайт ловит даже по TLS Fingerprint, то поведение тупых скачивалок должен засекать мгновенно.
HTTP достаточно сложный протокол, чтобы его на коленке сделать и это не очень сильно отличалось от поведения браузера. Тот же keep-alive уже большая боль.
Видеокарты могут кушать много. Плюс есть неиспользуемые линии в БП, которые идут в общую мощность, но по факту мёртвым грузом висят.
А дальше, как я понимаю - маркетинг и надёжность, чтобы БП не работал на пределе характеристик.
Но я тоже окончательно не понимаю такой разницы между реальным потреблением и мощностью БП (а с результами@aik,я согласен, сам когда-то мерял).
Сгенерировать куркод на условный bit.ly, который делает редирект на госуслуги, заодно меньше будет. Если сервис позволяет, то можно менять финальную ссылку, так что тату менять не придётся.
Отрицание с Any - это мина замедленного действия. На подобном запросе разваливался MySQL, Postgre в зависимости от фазы луны, оптимизатор MSSQL обычно догадывается до LEFT JOIN, но видно не всегда.
Вообще, если есть возможность и нужна скорость - то пробовать именно классические джойны, всё-таки на этой логике базы гораздо лучше работают.
Ну и иногда стоит играться с First/Single - в зависимости от ORM и базы данных могут весьма разные результаты получаться.
Т.е. для подтверждения действия с телефона, нужно использовать приложение на телефоне? А давайте просто будем посылать SMS/Push'и на этот телефон и не напрягать пользователя отдельным приложением. Упс... кажется я где-то видел.
Позанудствую, но 3D Secure просит не банк, а продавец. Т.е. Amazon не просит не потому что он такой доверенный весь из себя, а потому что он для удобства клиентов готов сам нести риски фрода. Остальным - гораздо проще (и дешевле) заюзать 3D Secure.
Как-то звонил провайдеру с проблемой, а т.к. чтобы прорваться через первую линию службы поддержки надо сказать код ошибки PPPoE, говорил всегда какой-нибудь левый, чтобы скрипт сломался. В итоге добрался до какого-то крутого дядьки, который мне звонил на личный номер со статусом — я тут мимо прохожу, давай зайду, никогда такой проблемы не видел.
Проблема оказалась в пережатом столом проводе, что давало линк, но и ничего больше.
Позанудствую. Для некоторых направлений заполненность может сильно варьироваться от дня недели, времени суток или самого направления. Т.е. возьмём условный поезд Москва-Нью Васюки. В пятницу вечером все ломятся из Москвы, заполненность 100%, назад - полупустой поезд. В понедельник с утра - всё наоборот. На неделе - обычная средняя загрузка. Из решений тут только тасовать количество вагонов, но с учётом того, что покупается конкретное место в конкретном вагоне — это весьма мутная логистическая задача.
Так что иметь возможность запихать больше пассажиров в вагон — идея для РЖД вполне здравая, т.к. позволит заработать больше в пиковых ситуациях.
Так говорить можно. Но если у кого-то не совпадает — значит что-то нечисто. Т.е. если организатор сказал лажу — это проблемы организатора. Все будут считать что прослушивают или организатора или его, а после обсуждения - выяснят, что прослушивают организатора.
Если что, они ещё добавли Per-user service, т.е. сервисы, создающиеся спеацильно для пользователя, что тоже добавляет процессов и отжирает память.
Это моя попытка осмыслить комментарий merhalak, а не мнение.
Не буду делать скриншот, но есть:
PPTP, L2TP, L2TP/IPSec PSK, L2TP/IPSec RSA, IPSec XAuth PSK, IPSec XAuth RSA, IPSec Hybrid RSA.
Именно IKEv2 нету. Пользуюсь как раз «каким-нить» IPSec
В общем, у автора свое видение проблемы, а тесты у него уж очень прямолинейные.
Тут можно ещё добавить, что в одном TCP-потоке множество соединений и страдать будут все.
А вот если реально плохая связь, то там может очень сильно всё нарастать (ретрансмиты внутри и снаружи туннеля).
Но вот то, что снаружи это фактически HTTPS (хотя и с неестественным профилем трафика) — это огромный плюс. Ну и второй плюс, что из-за этого, это самый стабильный VPN, пролезающий через любые наты.
А с HTTP3, боюсь, что к тому времени в России просто запретят UDP, как нежелательный протокол :)
На моём андроиде, кстати, его из коробки нет.