Преимущества в безопасности и гибкости для масштабирования. Идея не нова (хранение данных на клиенте используя цифровую подпись) и была еще на заре веба. Сейчас просто это красиво упаковали. Незаменимая вещь в децентрализованных системах, а также позволяет авторизовывать ваших пользователей третьей стороной by design.
Отловить никак, только инвалидировать все refresh токены пользователя. Доступ на 10-30 минут смущает, можно снижать время жизни, но всегда есть инструмент прекратить атаку, как я описал выше. Смущает много большее время доступа при использовании стандартного механизма сессий. Иногда это могут быть и годы, что предпочтительнее, так как целесообразно проводить атаку, когда пользователь не пользуется сервисом.
Первое, что хочу сказать — автор молодец, что поднимает такие темы. Этот кейс действительно игнорируют множество разработчиков. Что касается самого способа, то он предназначен больше для случаев, когда надо ходить на большое количество хостов через публичную сеть. Для стандартной схемы с бастион-хостом конечно проще проверить отпечаток самостоятельно один раз и разместить known_hosts файл в репозитории с инструментами управления.
Когда я работал на стройке, была такая фишка как «аккорд» — тебе дают набор задач на текущий день (остаток дня) и как только ты их выполняешь, можешь идти домой. Производительность во время работы по «аккорду» сильно повышалась =)
Потеря соединения это штатная ситуация и всегда такой будет, ее обязаны обрабатывать все сетевые приложения. Техники прозрачного восстановления соединений при разработке сетевых приложений известны еще с 90-х годов. Решение этой задачи (не проблемы) с помощью замены протокола на транспортном уровне является дичайшим оверхедом.
Управлять транспортным средством удаленно в режиме реального времени через не подконтрольную радиосеть мне кажется небезопасным. В условиях нестабильной связи управление должно быть автономным.
Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения. Мало того потом они придут пачкой.
> сильно улучшит консистентность статуса машины online/offline
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.
> Удержание единого соединения при смене ip адресов и сетей.
Ну физически соединение меняется в любом случае, тут мы ничего не экономим. Логически, поддержание сессии при смене соединения обеспечивается авторизацией клиента на прикладном уровне, причем это является требованием безопасности. Следовательно никого выигрыша мы тут тоже не получаем.
Спасибо за информацию! Поделюсь своим мнением насчет этих двух подходов, основанном на собственном опыте. На данный момент у меня сложилось четкое убеждение, что оба этих метода разработки в чистом виде — являются крайностями. Минусы BDUF уже проявили себя со временем и мы их знаем, минусы же Agile еще не так очевидны, так как методология достаточно молода.
Одна из самых острых проблем, которую я встречаю в Agile-проектах, это низкое качество продукта, которое выявляется на всех уровнях реализации: от чертовки запутанных требований, не формализованных требований, отсутствие спецификаций до «черт ногу сломит» программного воплощения и феерического внедрения (привет devops). Основной проблемой качества является не само качество кода, как можно подумать изначально, а высокая информационная энтропия системы. Архитектурно сложившаяся энтропия не может быть устранена в принципе никаким рефакторингом, только заменой архитектуры — что подразумевает реализацию с нуля.
Вторая проблема, на которую стоит обратить внимание — это выжимка разработчиков на полную, психологическая нагрузка и стрессы. Конечна она может быть и при BDUF, но часть звеньев этой проблемы встроены в саму методологию Agile.
Ну критика критикой, надо выдвинуть и свою альтернативу. Собственно ничего нового. Методы методами, практики практиками, но не следует слепо следовать манифестам, а принимать решения на основе реальной задачи, ее объема и сроков. Берем лучшее из любой методы, что подходит для работы над конкретным продуктом. Ключ к качеству — не следует избегать первоначального проектирования, тут без специалиста в этой области не обойтись. Не нужна эпик архитектура всего и вся и всех деталей, тут в самом проектировании подключаем итерационный подход. Необходимы формализованные требования, как минимум на 70%. Если их нет, заказчик не знает чего хочет. Если заказчик не знает чего хочет, он не получит качественный продукт, тут он должен это просто понимать.
Не уверен, что мобильные операторы вообще заинтересованы в удешевлении трафика. Это важно только большим компаниям для их больших бизнесов. По ссылке пример внедрения QUIC в Uber, по итогам которого можно сказать одно — стало лучше. Все. Никакой проблемы не решено, потому как настоящей проблемы то и нет (не знаю зачем им в приложении real time, о котором они упоминают). Улучшили они latency на 30% (которая в реале будет 15%), что это за цифра в мобильных сетях? Ничто, было 200мс, стало 140мс. Этого все равно недостаточно для Real Time. Требуется улучшение на порядок, чтобы об этом можно было серьезно говорить.
Отличный пример как делать не надо:
1. Хайлоад ради хайлоада.
2. Сами придумали проблему и так ее и не решили.
3. Внедрили сомнительное решение на транспортном уровне, получили статистическое увеличение скорости загрузки и колоссальную потерю пропускной способности.
Ну, это официальный термин, используемый организацией Agile Alliance, которая берет свое начало с подписания Agile Manifesto.
С каких пор Agile стал стандартом процесса разработки ПО и может ли он стандартизировать процесс в конкретном реальном бизнесе? То, что шустрые ребята собрали в кучу ряд стандартных подпроцессов и дали им красивые имена не делает эту методу стандартом. Более того в ряде реальных бизнесов и продуктов, Agile не работает в принципе. Каждый реальный бизнес и продукт требует построения своего процесса разработки, основанного на базовых принципах разработки ПО. Вот эти базовые принципы и должен уметь профпригодный разработчик, это не только код писать.
Задача практик заключается в том,… чтобы качество результата не зависело от уровня квалификации конкретного участника команды.
Ну такое возможно, только если работу неквалифицированного сотрудника выполнит кто-то другой.
Не увидел ни одного комментария с дискуссией на тему выдвинутых аргументов, только придирки к манере повествования. Из этого логично сделать вывод, что по настоящему, никто из оппонентов в аппарате КМ не разбирается и автор прав.
По моему сейчас проблема в тормозных сайтах и приложениях, а не в протоколе. Эти спиди и квики никому не нужны кроме гугла — корпоративное лоббирование ради собственных интересов. Очень надеюсь, что у нас не будет никакого HTTP/3 пока мы в нем откровенно не нуждаемся. Если кто-то хочет возразить, приведите живой пример, какую конкретно проблему решает HTTP/3 против HTTP/1.1.
Умиляет меня это терминология — практики. Какая-то корреляция с чем-то духовным, йогой. Давно пора признать, что программирование это не творчество, а ремесло. А эти практики не какие-то там хорошие привычки, а обязанности. Очень странно будет видеть, скажем, автомеханика, у которого хорошая практика затягивать гайки.
Качество библиотек гугла всегда было неплохого качества, не спорю. Но вот что будет дальше большой вопрос. Качество их продуктов падает. Чтобы проверить почту в gmail на современном ПК мне требуется ожидание загрузки в 2-5 секунд, 20МБ! трафика и все это в итоге в тормозном неотзывчивом интерфейсе. В Firefox у меня вообще гугл накрылся медным тазом, не могу никуда залогиниться, на gmail: Циклическое перенаправление на странице
При соединении с mail.google.com произошла ошибка.
Были разные, но в основной массе они, по моему опыту, на выходе дают дорогостоящие в обслуживании решения. Алгоритмизация да, разработка продукта нет. Был даже один с ученой степенью, эта ученая степень защищала его от необходимости дальнейшего обучения. Разгребая за ним его творчество мы потеряли кучу здоровья и денег. Я не утверждаю, что все олимпиадники такие упертые, я утверждаю, что это звание не должно влиять на решение работать с ним или нет.
Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения. Мало того потом они придут пачкой.
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.
> Удержание единого соединения при смене ip адресов и сетей.
Ну физически соединение меняется в любом случае, тут мы ничего не экономим. Логически, поддержание сессии при смене соединения обеспечивается авторизацией клиента на прикладном уровне, причем это является требованием безопасности. Следовательно никого выигрыша мы тут тоже не получаем.
Одна из самых острых проблем, которую я встречаю в Agile-проектах, это низкое качество продукта, которое выявляется на всех уровнях реализации: от чертовки запутанных требований, не формализованных требований, отсутствие спецификаций до «черт ногу сломит» программного воплощения и феерического внедрения (привет devops). Основной проблемой качества является не само качество кода, как можно подумать изначально, а высокая информационная энтропия системы. Архитектурно сложившаяся энтропия не может быть устранена в принципе никаким рефакторингом, только заменой архитектуры — что подразумевает реализацию с нуля.
Вторая проблема, на которую стоит обратить внимание — это выжимка разработчиков на полную, психологическая нагрузка и стрессы. Конечна она может быть и при BDUF, но часть звеньев этой проблемы встроены в саму методологию Agile.
Ну критика критикой, надо выдвинуть и свою альтернативу. Собственно ничего нового. Методы методами, практики практиками, но не следует слепо следовать манифестам, а принимать решения на основе реальной задачи, ее объема и сроков. Берем лучшее из любой методы, что подходит для работы над конкретным продуктом. Ключ к качеству — не следует избегать первоначального проектирования, тут без специалиста в этой области не обойтись. Не нужна эпик архитектура всего и вся и всех деталей, тут в самом проектировании подключаем итерационный подход. Необходимы формализованные требования, как минимум на 70%. Если их нет, заказчик не знает чего хочет. Если заказчик не знает чего хочет, он не получит качественный продукт, тут он должен это просто понимать.
1. Хайлоад ради хайлоада.
2. Сами придумали проблему и так ее и не решили.
3. Внедрили сомнительное решение на транспортном уровне, получили статистическое увеличение скорости загрузки и колоссальную потерю пропускной способности.
С каких пор Agile стал стандартом процесса разработки ПО и может ли он стандартизировать процесс в конкретном реальном бизнесе? То, что шустрые ребята собрали в кучу ряд стандартных подпроцессов и дали им красивые имена не делает эту методу стандартом. Более того в ряде реальных бизнесов и продуктов, Agile не работает в принципе. Каждый реальный бизнес и продукт требует построения своего процесса разработки, основанного на базовых принципах разработки ПО. Вот эти базовые принципы и должен уметь профпригодный разработчик, это не только код писать.
Ну такое возможно, только если работу неквалифицированного сотрудника выполнит кто-то другой.
Циклическое перенаправление на страницеПри соединении с mail.google.com произошла ошибка.