Comments 114
Уже есть WebAssembly.
Формально — нет, но под него есть QT...
Помню… вот поэтому и страшно.
На современных процессорах эти апплеты могли бы работать совсем по другому. Возьмем и представим современный Intellij Idea и его гипотетический аналог на JS.
Спрингу может там не место, но камон, джава была бы там не так плоха, как вы описываете.
Давайте сделайте нечто подобное как-то иначе, а мы посмотрим.
https://sandspiel.club/
вроде не шибко страшно. плюс отсутcтвие gc пока не прочит java в браузере.
Ну вон MS это не остановило, они завезли свой GC (вместе с остальным дотнетом): https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
Так это proof of concept. Есть еще скомпиленные в wasm CPython (см. Pyodide), который тоже с каким-то там управлением памятью. Поэтому и написал пока не прочит. Когда-нибудь найдется извращенец.
То есть вы уже можете представить куда можно попытаться применить этого монстра?
А так там пытаются заимплементить Flash на Rust который потом будет поверх canvas рендерить. Учитывая, что EcmaScript обычно живет с гц, то и там что-то почти наверняка есть похожее.
Это ненадолго.
Выкинуть-то надо, да только не бросать старых клиентов, вот что важно.
А то взял тут старый телефон, к которому обновлений не было уже годы, попробовал на имеющемся там браузере зайти на Яндекс — ой, сказал браузер, сервер не умеет то шифрование, которое умею я (на деле было-то всё наоборот, но важно, что они не договорились; при этом обновлений для телефона не было и не предвиделось от слова совсем).
Не то чтобы я сильно "за" тащить легаси и поддерживать всё и вся бесконечно. Однако говорить юзерам "меняй устройство, а то нам день легамюси тащить"… Может, тогда эти устройства ещё и купить им, а то геморрой индустрия привносит, юзер как бы не виноват.
Ну можно еще взять ие6 и долго возмущаться, что интернет не хочет поддерживать ие6.
Я вон хотел свой старый IBM ThinkPad (2005 года) под домашнюю автоматизацию заюзать. Даже Linux поставил не с первой попытки. Оказалось, что последние дистрибутивы без поддержки 64битного режима не работают. Потом померял энергопотребление и решил, что выгоднее использовать более свежее старье (или, возможно, одноплатник с минимальным энергопотреблением и приличной производительностью).
А вот смартфонов старых вполне рабочих навалом. И для каких-то узкоспециализированных задач я бы их вполне использовал.
К примеру, взял HTC One, визуально нормальный смартфон, вполне себе работает, показывает. Но, к примеру, Google Assistent на нем уже не завелся толком. Есть смартфоны, куда Youtube Music не встает! А я хотел как раз в комнате его кинуть просто для голосового управления.
А уж как я с iPad2 прокололся в отпуске в связи с тем, что куча программ уже не работает на iOS ниже 10, которая на этот iPad не устанавливается… Такой подставы не ожидал от них.
А где был IE6, давайте вспомним? В WinXp? Так на неё устанавливается Firefix 52 ESR, а это 2017 год. Смотрите, 15 лет разницы, железо 2002 года уже скорее всего сдохло — а теперь сравним, сколько этому телефону, на который установить новее уже почему-то вдруг нельзя?..
Да хоть прямо сейчас. Только одна проблема — куда деть миллионы обезь фронтендеров, которые ничего больше не умеют?
А если серьёзно и без экстремизма, то нежелание учиться, на самом деле — проблема того, кто не хочет — всегда так было и всегда так будет.
Раньше их выкашивал естественный отбор, теперь рыночная экономика удерживает их на нижних ступенях социальной лестницы, в будущем появится ещё что-нибудь
Уже лет 10 как есть webgl, где есть полная свобода и максимальная производительность. Только никто не хочет этим заниматься потому это максимально низкий уровень графического стека — там даже рендер текста нужно делать самому (разбивая текст на глифы а глифы на кривые безье и т.д не говоря уже про поддержку юникода и всех этих сложностей с многоязычным вводом). Но с другой стороны для некоторых кейсов как например редактор кода где многоязычность не нужна и есть только английский моноширинный шрифт задача уже упрощается. Вот тут человек для редактора кода заменил весь этот стек (html/css/svg/2d-canvas) на webgl — https://makepad.github.io/makepad — написал свой рендер текста, рендер прямоугольников и других ui-примитивов, написал алгоритм лейаута подобно флексбоксам и теперь уже пишет высокоуровневые компоненты, логику, фичи и постоянно пишет в твиттере (https://twitter.com/rikarends) как все стало намного удобнее и на порядок быстрее чем с html/css
WebGL как бы маловато для UI-тулкита. Контрольчики отрисовать не проблема, веселье начинается на тексте и его вводе. Причём у браузеров нет вообще никаких API для интеграции с системой ввода текста. Совсем. Можно более-менее работать только с европейскими локалями, где всё работает на раскладках клавиатуры.
Но тем не менее — это круто, это огромная работа с весьма сомнительной полезностью сейчас, но немного раздвигающая границы того, что можно будет делать потом. (и да, я знаю про миллион портированных через emscripten приложений, но ведь это не порт, это концептуально такая разработка).
Зачем с нуля, если это уже много раз сделано? Просто портировать существующие тулкиты.
Ну вы же не можете любой виджет по id достать и что-то с ним сделать
из коробки не могу. надстройку сделал — все могу. фрагмент:
Map<dynamic, UpdateState> _stateMap = {};
void registerState(UpdateState state){ _stateMap[state.widget.data] = state;}
void unregisterState(UpdateState state){
for(var kv in _stateMap.entries)
if (kv.value == state)
{
_stateMap.remove(kv.key);
break;
}
}abstract class UpdateWidget extends StatefulWidget with SizeInfo{
UpdateWidget(this.data);
final dynamic data;
String get name{ return data['name'];}
}
abstract class UpdateState<T extends UpdateWidget> extends State<T>{
String get name{ return widget.data['name'];}
void updateData(dynamic data)
{
setState(() => data.forEach((k,v) => widget.data[k] = v));
}
@override
void initState() {
registerState(this);
super.initState();
}
@override
void dispose(){
unregisterState(this);
super.dispose();
}
@override
void didUpdateWidget (covariant T oldWidget){
super.didUpdateWidget(oldWidget);
unregisterState(this);
registerState(this);
}
}Все эту с прокидыванием через провайдеры, GlobalStates,… не использую, ибо с ней все становится мутно для меня.
И как всегда, про SCTP эти велосипедисты не подумали.
Гугл в принципе очень хочет превратить браузер в мега-операционку, они уже пилят стандарт USB-драйвера, драйвера серийных портов и распознавания лиц на видео.
Кстати, QUIC откроет UDP-протокол самим сайтам, чтобы трафика стало ещё больше. Бегите обновлять мобильные, трёх гигабайт оперативки уже скоро будет мало.
У меня дежавю. Такое уже было при запуске uTP! Отрицание, гнев, ....., принятие.
Будет весело, если эти системы накроются медным тазом. (а, в идеале, будут накрываться раз в 5 лет из-за какого-нибудь нового стандарта, например IPv6 everywhere coming soon )
Или у нас все новые интернет технологии запретят?)
Скорее всего все запретят, по другим областям видно
И сайты/браузеры просто будут откатываться на старый добрый способ.
Причем, насколько я понял из статьи, пользователи визуально врядли заметят замедление. Выигрыш в скорости копеечный.
А что HTTPS сейчас как то инспектируется кроме SNI? Ну про MITM через анальное внедрение доверенных сертификатов сотрудникам я не говорю, тут полная свобода.
Таких, что разрешают бесконтрольный доступ в Интерент крайне мало. А без проверки HTTPS он фактически бесконтрольный.
Есть такие, кто удовлетворяется проверкой сертифкатов. Типа «заправшиваемый сайт вернул сертифкат *.facebook.com, социальные сети разрешы, значит на разрешенный сайт идешь, проходи».
И очень много делающих полный MITM, благо сертифкат распространить на корпоративные компы не проблема.
С QUIC такой возможности не вижу, проще заблокировать его.
Ну сертификаты, допустим, уже нельзя прочитать из TLS 1.3 сессии, обмен теперь зашифрован. Только повторяя соединение параллельно на тот же IP и с тем же SNI. Это если нет eSNI, с ним — уже увы.
С QUIC такой возможности не вижу, проще заблокировать его.
Не вижу принципиальной разницы MITMить QUIC или TLS. Как выйдет стандарт — появятся и инструменты.
А она есть. В случае с HTTP прокси были частью стандарта изначально. А в случае с QUIC?
Причем тут прокси?
HTTPS MITM-ится перехватом TCP соединения, заворачиванием его на какой-нибудь Squid, генерацией там фейкового сертификата и оттуда уже строится второе соединение на целевой хост от имени клиента.
Никакой "прокси из стандарта" не участвует, клиент не видит разницы.
При том, что протокол был построен так, что запрос на прокси и на конечный сервер почти не отличаются. Поэтому перехватить TCP-соединение — легко, хотя в корпоративной среде для plain HTTP лучше было прописать как прокси, чтоб браузер учитывал это.
А тут у вас ни TCP, ни TLS, для начала, а потом роуминг еще.
Так оно же много кому выгодно. В первую очередь мобильным оператором.
Короткое восстановление сессий в нерегулярных мобильных сетях в первую очередь. Чуть меньше трафика который уходит на все эти хэндшейки -> снижение пинга в сети -> повышение плотности трафика в сети -> удешевление трафика. Тут же на хабре была статья от какой-то кампании(кажется эта), про внедрение quic в мобильное приложение.
Подразумевалось удешевление трафика для оператора, то бишь ему придется меньше тратиться. Думаю любой бизнес порадуется сократившимся расходам при неизменном доходе.
Уменьшение задержек/таймаута — вполне себе способ несколько нивелировать регуляторный ахтунг, например. При повсеместном распространении, конечно же.
habr.com/ru/company/oleg-bunin/blog/461829
А общее время реакции приложения состоит как из тормозов приложения, так и из тормозов сетевого стека. И если первое легко фиксится, а у нормальных программистов и не появляется — то второе забито гвоздями в железо маршрутизаторов. И Гугл молодцы что своей силой вытащат всю протокольную логику из их прошивок в user-space где она понемногу может развиваться. Кроме них на такое способны немногие.
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.
> Удержание единого соединения при смене ip адресов и сетей.
Ну физически соединение меняется в любом случае, тут мы ничего не экономим. Логически, поддержание сессии при смене соединения обеспечивается авторизацией клиента на прикладном уровне, причем это является требованием безопасности. Следовательно никого выигрыша мы тут тоже не получаем.
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.
Реальный пример, который вижу часто. Стоит машина на парковке и блокирует другую. Ее начинают двигать мобильным телефоном, в какой-то момент машина переезжает из зоны wifi и начинает переподключаться по LTE в этот момент она останавливается на пару секунд, тк сервер думает, что она offline и перестает слать команды. Что очень неприятный опыт. Это можно улучшить текущими технологиями, сильно усложнив логику всего.
Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения. Мало того потом они придут пачкой.
Управлять транспортным средством удаленно в режиме реального времени через не подконтрольную радиосеть мне кажется небезопасным
Это будет реализовано почти всеми автомобильными компаниями в ближайшие 5 лет, даже на недорогих моделях. Нужно понимать, что это происходит на очень небольшой скорости в зоне видимости и машина не наедет на препатствие, тк есть куча различных сенсоров, которые это заблокируют. При потере соединения она очевидно останавливается. Это не self-driving, а просто remote-управление на парковке, в гараже и тд. Так же очень удобно так загонять/выгонять машину в/из гараж, где тесно.
Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения
Я на самом деле не до конца знаю как работает QUIC, но тк это UDP и некоторый handshake уже состоялся, я бы ожидал отсутствия процесса непосредственного переподключения как это в TCP. А переключение возможно будет происходить очень шустро, но это мои ожидания, на практике может быть не так. Так же этот протокол должен в принципе лучше работать с плохой сетью, тк он был задизайнен работать в сотовых сетях, в отличие от TCP, который проектировался работать по шнуру.
Я не являюсь высококомпетентным специалистом в области дистанционного управления автомобилями, но что-то мне подсказывает, что управление там реализовано совсем не по HTTP1/2/3, в противном случае мне будет страшно его использовать. Соответственно, любой прогресс в web-протоколах не должен повлиять на приведённый пример.
Ну, в моём представлении, системы управления транспортом, всё же должны работать в реальном времени, на операционных системах реального времени, в то время как протоколы семейства http подразумевают не только асинхронность (особенно третье поколение), но и непредсказуемость задержек. Возможно, я просто чуть старомоден — автомобильное образование получал ещё в прошлом веке, когда многие взгляды и на ИТ, и на автоматизацию вообще, сильно отличались от сегодняшних.
Внутри в микроконтроллерах различные компоненты, наверняка на особых ОС и там особые протоколы используются. Но даже тут задержки могут быть очень разными. Особенно, если это ДВС, который ну очень медленный в плане реакции за событие.
Я думаю это очень затрудтительно будет сделать, тк разные мобильные провайдеры в разных странах очень по разному работают. Очень у немногих будет что-то работать на уровне ниже. Самые плохие в Китае, у них там вообще все плохо в плане надежности и скорости сети в принципе в стране. Они могут в любой момент начать блокировать какой-то не такой трафик, особенно такой необычный.
IP-ки по любому будут меняться и я не думаю, что провайдер даст управлять маршрутизацией. VPN странное решение, он врядли будет хорошо работать хотя бы при сотнях тысячах машин в одной сети.
С точки зрения цензора, зашифрованный HTTP/3 поверх UDP тоже не буде выглядеть обычно, и мало чем будет отличаться от, например, OpenVPN через UDP. Проблему блокировок можно попытаться решить административно, а не технически — это будет сильно надёжнее, ведь завтра цензор может изменить алгоритмы, и придётся всё переделывать.
Аргумент про VPN и сотни тысяч машин в одной сети не понял — какие проблемы ожидаются, и почему это решение странное? Почему те же проблемы не возникают в сетях тех же мобильных операторов без VPN?
Данные передаются в текстовом виде, а значит передача картинок, видео и прочей нетекстовой информации неэффективна.Тут видимо стоит сделать уточнение, что бинарные данные переводятся в текст только при отправке с клиента на сервер, например POST-е формы.
В остальных случаях (которых большинство) бинарные данные идут как есть, а текстовые только заголовки.
multipart/form-data, а это большинство (все?) варианты отправки файлов, то бинарные данные остаются бинарными.
Нужно так же как-то резать «данные» на пакеты определённого размера (ведь буфер сетевой Ethernet карты не бесконечен). Метить эти пакеты (порядковый номер в потоке). Поднимать флаг установки нового соединения\сеанса связи. Считать контрольную сумму пакета.
Тоесть получается всё то что сейчас делает аппаратная часть TCP переложить на хост процессор. Конечно реализация аппаратной части UDP намного проще.
В связи с этим такой вопрос, как вы думаете не связано ли это «движение» с заблаговременной подготовкой ко встрече 5G ???
Тоесть это всё начинают проектировать не для проводного Etherneta ???
Поэтому на первый взгляд всё кажется немного бестолковым ?!
Ведь в радиосреде практически все пакеты данных по своей сути UDP. Причём до определённой меры, широковещательные пакеты UDP. На радио тракте бессмысленно существование аппаратуры TCP. То что есть сейчас это появилось как радиоэкспадеры для обычных проводных сетей.
А в сенсорных мэш радиосетях ничего близкого под TCP нет. Там везде по сути UDP.
Ну и с учётом того что активно всех сгоняют в «облака». «Облака» сгонят в одну «тучу» (дата центр\центры), наподобие как Гугл или Фейсбук.
И все будут «говорить» с этой тучей через массивы антенн 5 G посредством своих гаджетов.
А провода будут постепенно везде скручивать. И всех убеждать что мол крайне не модно по проводам в соц.сетях сидеть.
Если я правильно понял вашу статью, всё что предлагают «товарищи» это как бы делать всё то что делает TCP, только программным способом.
Не совсем. QUIC ещё должен решить проблему «head-of-line blocking» и предоставить лёгкий способ поддержания соединения при изменении IP-адреса клиента.
В связи с этим такой вопрос, как вы думаете не связано ли это «движение» с заблаговременной подготовкой ко встрече 5G ???
Не думаю, что у меня достаточно компетенций, чтобы уверенно отвечать на этот вопрос. Могу только сказать, что тесты производительности для gQUIC в случае работы через смартфон по мобильной сети, показывают, что gQUIC в этом случае имеет меньший отрыв от TCP, чем при использовании десктопного компьютера и кабельного интернета. Да, тут больше важна производительность смартфона, но всё-равно, думаю, что развитие мобильных сетей в меньшей степени оказывает влияние на развитие QUIC, чем упоротость создателей и желание решить указанные выше проблемы :)
HTTP/3: разрушение основ и дивный новый мир