Dodo Pizza Engineering corporate blog
Network technologies
IT Standards
Comments 111
+4
Интересно когда же взоры людей привлечет сам стэк HTML+CSS+JS. И придумают(возбмут что нибудь готовое типа PDF и нзовут новым именем) что нибудь новое, что не будет в итоге жрать столько памяти/процессора, и тянуть такое количество костылей.
+29
Вебасембли сделает все хуже… Люди начнут писать фронтенд на джаве со спрингом…
+3
Справедливости ради стоит вспомнить, что давали(возможность) эти апплеты в соотношении производительности процессоров тех лет.

На современных процессорах эти апплеты могли бы работать совсем по другому. Возьмем и представим современный Intellij Idea и его гипотетический аналог на JS.

Спрингу может там не место, но камон, джава была бы там не так плоха, как вы описываете.

Давайте сделайте нечто подобное как-то иначе, а мы посмотрим.
0

Так это proof of concept. Есть еще скомпиленные в wasm CPython (см. Pyodide), который тоже с каким-то там управлением памятью. Поэтому и написал пока не прочит. Когда-нибудь найдется извращенец.

0
Ну Blazor WebAssembly-то не proof of concept, а вполне рабочая бета. В .Net Core 3.1 уже релизная версия войдет.
0

То есть вы уже можете представить куда можно попытаться применить этого монстра?

+1
Не только я, уже не одна статья была на Хабре, вот например: habr.com/ru/post/468019. Да и не такой уж он и монстр — пара-тройка мегабайт загрузки не так много по современным меркам, и эти размеры обещают еще уменьшить. Лично я как C#-разработчик буду только рад, если и фронтенд, и бэкенд можно будет писать на одном и том же шарпе.
+1

А так там пытаются заимплементить Flash на Rust который потом будет поверх canvas рендерить. Учитывая, что EcmaScript обычно живет с гц, то и там что-то почти наверняка есть похожее.

0
Память и процессор пока ещё дешевеют. Скорее нужно решение, которое ещё дешевле для разработчика будет масштабироваться по увеличивающемуся количеству CPU ядер.
0
Довольно авторитетный дядька говорит, что ещё лет 30 будет так же, как сейчас. Не знаю, на сколько он прав.
0

Даже он это утверждает "с оговорками". Пока что (например в Википедии есть цитат) остальные склоняются к тому, что закон Мура встанет примерно в середине следующего десятилетия.

+1
Надо просто выкинуть нафиг все легаси из браузера… да больно… зато станет лучше потом.
0

Выкинуть-то надо, да только не бросать старых клиентов, вот что важно.


А то взял тут старый телефон, к которому обновлений не было уже годы, попробовал на имеющемся там браузере зайти на Яндекс — ой, сказал браузер, сервер не умеет то шифрование, которое умею я (на деле было-то всё наоборот, но важно, что они не договорились; при этом обновлений для телефона не было и не предвиделось от слова совсем).


Не то чтобы я сильно "за" тащить легаси и поддерживать всё и вся бесконечно. Однако говорить юзерам "меняй устройство, а то нам день легамюси тащить"… Может, тогда эти устройства ещё и купить им, а то геморрой индустрия привносит, юзер как бы не виноват.

-2

Ну можно еще взять ие6 и долго возмущаться, что интернет не хочет поддерживать ие6.

0
ПК, где IE6 — последний работающий браузер, и невозможно установить никакой поновее, да так, чтобы на нем кто-то реально хотел на нем работать — редкость, мне кажется.
Я вон хотел свой старый IBM ThinkPad (2005 года) под домашнюю автоматизацию заюзать. Даже Linux поставил не с первой попытки. Оказалось, что последние дистрибутивы без поддержки 64битного режима не работают. Потом померял энергопотребление и решил, что выгоднее использовать более свежее старье (или, возможно, одноплатник с минимальным энергопотреблением и приличной производительностью).

А вот смартфонов старых вполне рабочих навалом. И для каких-то узкоспециализированных задач я бы их вполне использовал.
К примеру, взял HTC One, визуально нормальный смартфон, вполне себе работает, показывает. Но, к примеру, Google Assistent на нем уже не завелся толком. Есть смартфоны, куда Youtube Music не встает! А я хотел как раз в комнате его кинуть просто для голосового управления.

А уж как я с iPad2 прокололся в отпуске в связи с тем, что куча программ уже не работает на iOS ниже 10, которая на этот iPad не устанавливается… Такой подставы не ожидал от них.
0

А где был IE6, давайте вспомним? В WinXp? Так на неё устанавливается Firefix 52 ESR, а это 2017 год. Смотрите, 15 лет разницы, железо 2002 года уже скорее всего сдохло — а теперь сравним, сколько этому телефону, на который установить новее уже почему-то вдруг нельзя?..

+15
Пожалуйста, не надо. Хоть тут нет зоопарка — каким бы не был сайт, на фронте всегда HTML и CSS. Да, с легаси костылями, да, с вендорными префиксами, но всё же. А вопрос тормозов и жрущей памяти обычно надо задавать фронтендерам, а не разработчикам спецификации HTML и CSS.
+1

Ванильная императивщина и innerHTML фантастически быстры, но считается дурным тоном, а RX с виртуальным Домом это модно, но далеко небесплатно.

0

Да хоть прямо сейчас. Только одна проблема — куда деть миллионы обезь фронтендеров, которые ничего больше не умеют?

+2
Маск там в США Старшипы строит, про колонизацию Марса что-то рассказывал…
+1

Предлагаете удобрить ими почву Красной Планеты, дабы сделать её плодородной? Хитро!

0
В дворники тех, кто учиться не хочет :)
А если серьёзно и без экстремизма, то нежелание учиться, на самом деле — проблема того, кто не хочет — всегда так было и всегда так будет.
Раньше их выкашивал естественный отбор, теперь рыночная экономика удерживает их на нижних ступенях социальной лестницы, в будущем появится ещё что-нибудь
0

А нежелание прививаться проблема тех, кто не хочет прививаться, да-да...

+16

Уже лет 10 как есть webgl, где есть полная свобода и максимальная производительность. Только никто не хочет этим заниматься потому это максимально низкий уровень графического стека — там даже рендер текста нужно делать самому (разбивая текст на глифы а глифы на кривые безье и т.д не говоря уже про поддержку юникода и всех этих сложностей с многоязычным вводом). Но с другой стороны для некоторых кейсов как например редактор кода где многоязычность не нужна и есть только английский моноширинный шрифт задача уже упрощается. Вот тут человек для редактора кода заменил весь этот стек (html/css/svg/2d-canvas) на webgl — https://makepad.github.io/makepad — написал свой рендер текста, рендер прямоугольников и других ui-примитивов, написал алгоритм лейаута подобно флексбоксам и теперь уже пишет высокоуровневые компоненты, логику, фичи и постоянно пишет в твиттере (https://twitter.com/rikarends) как все стало намного удобнее и на порядок быстрее чем с html/css

0

WebGL как бы маловато для UI-тулкита. Контрольчики отрисовать не проблема, веселье начинается на тексте и его вводе. Причём у браузеров нет вообще никаких API для интеграции с системой ввода текста. Совсем. Можно более-менее работать только с европейскими локалями, где всё работает на раскладках клавиатуры.

+1
Да там еще миллион и один нюанс — начиная от того, как оно все будет работать с какими-нибудь скринридерами или полезными расширениями браузера (никак) и заканчивая суровой механической необходимостью пробрасывать туда и обратно вообще все, потому что API сурово изолирован (посмотрите на github.com/makepad/makepad/blob/master/render/src/cx_webgl.js это).

Но тем не менее — это круто, это огромная работа с весьма сомнительной полезностью сейчас, но немного раздвигающая границы того, что можно будет делать потом. (и да, я знаю про миллион портированных через emscripten приложений, но ведь это не порт, это концептуально такая разработка).
0

Зачем с нуля, если это уже много раз сделано? Просто портировать существующие тулкиты.

+1
как все стало намного удобнее и на порядок быстрее чем с html/css

Вот только у меня на стабильном хроме и последней винде это выглядит близко к нечитаемому из-за очень странного рендеринга шрифтов, как будто картинку скукожили до 1024x768 и растянули обратно.


Аналогичную картинку я наблюдал при использовании низкого разрешения в играх, которые компьютер не тянул.

+2
Меня больше интересует когда люди перестанут втаскивать приложения в HTML+CSS. Он делался совсем для другого. То как он сейчас используется совместно с JS делает меня грустной пандой.
0

Как только появится замена, за которой будет стоять большая корпорация.

+1

Необязательно именно корпорация. Но кто-то должен оплатить банкет, да...

0

Flutter это и есть полностью новый стек. Только неудобен по причине принудительной декларативщины и слегка глючен.

0

Ну вы же не можете любой виджет по id достать и что-то с ним сделать, нету там querySelector, хотя всем хочется. Тот же Provider.of это частичный откат к императивщина, хоть и а рамках предков.

0
Ну вы же не можете любой виджет по 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;
    }
}
0
Согласен, хотя они во всех методичках кричат что так нельзя, может боятся, что если все будут писать императивно — продукт не покажет сказочной производительности, которую нам обещают? Собственно, получим ту проблему, которую побеждал React — непредсказуемые обновления больших кусков DOM. Хотя непонятно, такая ли уж это проблема сегодня, когда даже в web-компонентах считается незазорным использовать innerHTML.
+1
Мне пофиг на то что там думают. в моей схеме я обновляю именно те виджеты/области, которые должны обновится и автоматом. для этого написал два класса сверху и все мои виждеты/состояния наследуются от них и все становится прозрачно и доступно.
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,… не использую, ибо с ней все становится мутно для меня.
0
Нормальный подход. Только поддерево вашего зарегистрированного стейта будет обновляться целиком, а Provider (он же по сути InheritedWidget) ведет внутренний реестр зависимостей, и может обновить только корень поддерева (ваш стейт), и какой-нибудь дальний лист, все остальное оставляя нетронутым. Особенно актуально, если у вас один StatefullWidget вложен в другой. Хотя, в случае вложенных стейтфулов я не уверен, сам не тестировал.
0
Нет. внутренние оптимизации Flutter продолжают работать. команда на отрисовку(обновление) приводит к пересчету кодопредствления в build. обновляется графика только там (в тех частях) где код перестал совпадать с пред. состоянием от build.
0
был уже и flash и поделие мс silverlight или как то так… и все это не взошло. Хотя флэш был местами хорош, но не сильно безопасен.
0
Оно и не жрет столько памяти. Жрут избыточные, перегруженные решения с жирным слоем абстракций и неэффективным кодом, нередко с утечками памяти, потому что бизнесу, как всегда, хочется быстро, дешево и сеньйоров по три копейки за пучок. Насколько эффективный код может написать человек с 1-3 мя годами опыта в вебе и исключительно на Англулярах*, а время потраченного на само программирование еще меньше? А именно таких львиная доля во фронте. Работодателям мало интересен вопрос потребления ресурсов, если это не мешает воспользоватся их продуктом и заработать денег.
+1
А с какой версии Windows/MacOS/Android/iOS SCTP поддерживается из коробки?
+2

Он требует режима администратора, т.к. сырыми сокетами управляет. Это может стать трудностью.

+1

Уже разбирали в одном из летних постов по теме. Недостоверная информация там местами.

+1
Вот то, что браузер теперь передаёт ваш ID даже между IPшниками (в HTTP/2 он может только сохранять соединение между сессиями) и то, что браузер захватывает ещё и сетевой драйвер вместо операционной системы — это адская смесь. Ещё и увеличение нагрузки на процессор в три раза как подарок.

Гугл в принципе очень хочет превратить браузер в мега-операционку, они уже пилят стандарт USB-драйвера, драйвера серийных портов и распознавания лиц на видео.

Кстати, QUIC откроет UDP-протокол самим сайтам, чтобы трафика стало ещё больше. Бегите обновлять мобильные, трёх гигабайт оперативки уже скоро будет мало.
+1
Спасибо, теперь я смогу ответить, на кой чёрт мне нужно 8 гигов оперативки в мобильнике и 32 на домашнем компьютере, если я не кручу там тяжёлые БД. /irony
0
> Все эти проблемы связаны с тем, что UDP раньше не использовался для передачи интернет-контента, и производители железок не могли предвидеть, что такое когда-то случится.

У меня дежавю. Такое уже было при запуске uTP! Отрицание, гнев, ....., принятие.
0

UDP используется в SRT для передачи видео через Интернет уже несколько лет как.

0

Ну, uTP в своё время укладывал провайдерские роутеры на лопатки, именно это я и имел в виду.
SRT вряд ли таким похвастается :)

0
Ну, uTP в своё время укладывал провайдерские роутеры на лопатки, именно это я и имел в виду.

Насколько я помню, проблема была в кривизне самого uTP, когда он видя плохую скорость передачи или там потери, начинал дробить пакеты, и уже с их большим числом не справлялось старое оборудование.
0
> не справлялось старое оборудование.

Спасибо, что повторили мой тезис.
0
Интересно, насколько хорошо будет работать провайдерское оборудования для блокировки с QUIC?
Будет весело, если эти системы накроются медным тазом. (а, в идеале, будут накрываться раз в 5 лет из-за какого-нибудь нового стандарта, например IPv6 everywhere coming soon )
Или у нас все новые интернет технологии запретят?)
0

Скорее всего все запретят, по другим областям видно

+1
В компаниях наверняка QUIC будет тупо блокироваться. Ибо фаерволы и прочие решения фиг его проинспектируют.
И сайты/браузеры просто будут откатываться на старый добрый способ.
Причем, насколько я понял из статьи, пользователи визуально врядли заметят замедление. Выигрыш в скорости копеечный.
0

А что HTTPS сейчас как то инспектируется кроме SNI? Ну про MITM через анальное внедрение доверенных сертификатов сотрудникам я не говорю, тут полная свобода.

0
Да, я про корпоратов.
Таких, что разрешают бесконтрольный доступ в Интерент крайне мало. А без проверки HTTPS он фактически бесконтрольный.
Есть такие, кто удовлетворяется проверкой сертифкатов. Типа «заправшиваемый сайт вернул сертифкат *.facebook.com, социальные сети разрешы, значит на разрешенный сайт идешь, проходи».
И очень много делающих полный MITM, благо сертифкат распространить на корпоративные компы не проблема.
С QUIC такой возможности не вижу, проще заблокировать его.
0

Ну сертификаты, допустим, уже нельзя прочитать из TLS 1.3 сессии, обмен теперь зашифрован. Только повторяя соединение параллельно на тот же IP и с тем же SNI. Это если нет eSNI, с ним — уже увы.


С QUIC такой возможности не вижу, проще заблокировать его.

Не вижу принципиальной разницы MITMить QUIC или TLS. Как выйдет стандарт — появятся и инструменты.

0

А она есть. В случае с HTTP прокси были частью стандарта изначально. А в случае с QUIC?

0

Причем тут прокси?


HTTPS MITM-ится перехватом TCP соединения, заворачиванием его на какой-нибудь Squid, генерацией там фейкового сертификата и оттуда уже строится второе соединение на целевой хост от имени клиента.


Никакой "прокси из стандарта" не участвует, клиент не видит разницы.

0

При том, что протокол был построен так, что запрос на прокси и на конечный сервер почти не отличаются. Поэтому перехватить TCP-соединение — легко, хотя в корпоративной среде для plain HTTP лучше было прописать как прокси, чтоб браузер учитывал это.


А тут у вас ни TCP, ни TLS, для начала, а потом роуминг еще.

0

Ну так это вопрос инструментов. Само собой под новый протокол нужны новые диссекторы.


Но семантика HTTP, насколько я вижу, внутри третьей версии не поменялась никак относительно второй, поэтому нужно просто разобрать внешние слои а внутри всё останется как и раньше.

0
Недавно была статья от сисадмина, который тупо зарезал весь QUIC-трафик на файерволе, поскольку его железяка не могла отличить этот трафик от UDP-флуда.
+3
По моему сейчас проблема в тормозных сайтах и приложениях, а не в протоколе. Эти спиди и квики никому не нужны кроме гугла — корпоративное лоббирование ради собственных интересов. Очень надеюсь, что у нас не будет никакого HTTP/3 пока мы в нем откровенно не нуждаемся. Если кто-то хочет возразить, приведите живой пример, какую конкретно проблему решает HTTP/3 против HTTP/1.1.
-1

Так оно же много кому выгодно. В первую очередь мобильным оператором.

0
Каким боком? Приведите, пожалуйста, конкретный пример в чем выгодно.
0

Короткое восстановление сессий в нерегулярных мобильных сетях в первую очередь. Чуть меньше трафика который уходит на все эти хэндшейки -> снижение пинга в сети -> повышение плотности трафика в сети -> удешевление трафика. Тут же на хабре была статья от какой-то кампании(кажется эта), про внедрение quic в мобильное приложение.

0
Не уверен, что мобильные операторы вообще заинтересованы в удешевлении трафика. Это важно только большим компаниям для их больших бизнесов. По ссылке пример внедрения QUIC в Uber, по итогам которого можно сказать одно — стало лучше. Все. Никакой проблемы не решено, потому как настоящей проблемы то и нет (не знаю зачем им в приложении real time, о котором они упоминают). Улучшили они latency на 30% (которая в реале будет 15%), что это за цифра в мобильных сетях? Ничто, было 200мс, стало 140мс. Этого все равно недостаточно для Real Time. Требуется улучшение на порядок, чтобы об этом можно было серьезно говорить.
0

Подразумевалось удешевление трафика для оператора, то бишь ему придется меньше тратиться. Думаю любой бизнес порадуется сократившимся расходам при неизменном доходе.
Уменьшение задержек/таймаута — вполне себе способ несколько нивелировать регуляторный ахтунг, например. При повсеместном распространении, конечно же.

+3
Отличный пример как делать не надо:
1. Хайлоад ради хайлоада.
2. Сами придумали проблему и так ее и не решили.
3. Внедрили сомнительное решение на транспортном уровне, получили статистическое увеличение скорости загрузки и колоссальную потерю пропускной способности.
-1
Проблемы только у вас в голове.

А общее время реакции приложения состоит как из тормозов приложения, так и из тормозов сетевого стека. И если первое легко фиксится, а у нормальных программистов и не появляется — то второе забито гвоздями в железо маршрутизаторов. И Гугл молодцы что своей силой вытащат всю протокольную логику из их прошивок в user-space где она понемногу может развиваться. Кроме них на такое способны немногие.
0

Не молодцы, а наоборот, диверсия. У них не тот уровень компетенции, чтобы диктовать нижнему уровню. И так и выходит — огромное количество усилий с довольно скромным выхлопом.

+1
Удержание единого соединения при смене ip адресов и сетей. Когда едет, например, машина на скорости 80 миль/ч и частенько переезжает из сети в сеть, то иногда WiFi ловит. То иметь по сути одно соединение без постоянных реконнектов и миганий прям сильно улучшит консистентность статуса машины online/offline.
0
> сильно улучшит консистентность статуса машины online/offline
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.

> Удержание единого соединения при смене ip адресов и сетей.
Ну физически соединение меняется в любом случае, тут мы ничего не экономим. Логически, поддержание сессии при смене соединения обеспечивается авторизацией клиента на прикладном уровне, причем это является требованием безопасности. Следовательно никого выигрыша мы тут тоже не получаем.
+1
Где, в сферическом коне? Приведите реальный пример, где это имеет критическое значение.

Реальный пример, который вижу часто. Стоит машина на парковке и блокирует другую. Ее начинают двигать мобильным телефоном, в какой-то момент машина переезжает из зоны wifi и начинает переподключаться по LTE в этот момент она останавливается на пару секунд, тк сервер думает, что она offline и перестает слать команды. Что очень неприятный опыт. Это можно улучшить текущими технологиями, сильно усложнив логику всего.
+1
Управлять транспортным средством удаленно в режиме реального времени через не подконтрольную радиосеть мне кажется небезопасным. В условиях нестабильной связи управление должно быть автономным.

Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения. Мало того потом они придут пачкой.
0
Управлять транспортным средством удаленно в режиме реального времени через не подконтрольную радиосеть мне кажется небезопасным

Это будет реализовано почти всеми автомобильными компаниями в ближайшие 5 лет, даже на недорогих моделях. Нужно понимать, что это происходит на очень небольшой скорости в зоне видимости и машина не наедет на препатствие, тк есть куча различных сенсоров, которые это заблокируют. При потере соединения она очевидно останавливается. Это не self-driving, а просто remote-управление на парковке, в гараже и тд. Так же очень удобно так загонять/выгонять машину в/из гараж, где тесно.

Тем не менее, процесс переключения никуда не девается, сервер будет продолжать слать команды, но они не будут доходить во время переключения

Я на самом деле не до конца знаю как работает QUIC, но тк это UDP и некоторый handshake уже состоялся, я бы ожидал отсутствия процесса непосредственного переподключения как это в TCP. А переключение возможно будет происходить очень шустро, но это мои ожидания, на практике может быть не так. Так же этот протокол должен в принципе лучше работать с плохой сетью, тк он был задизайнен работать в сотовых сетях, в отличие от TCP, который проектировался работать по шнуру.
0

Я не являюсь высококомпетентным специалистом в области дистанционного управления автомобилями, но что-то мне подсказывает, что управление там реализовано совсем не по HTTP1/2/3, в противном случае мне будет страшно его использовать. Соответственно, любой прогресс в web-протоколах не должен повлиять на приведённый пример.

0
А что не так с HTTP 1/2/3? Чем это хуже/лучше/опаснее чем что-то иное? Я, конечно, не знаю какой автопроизводител как именно это реализовывает, но я не вижу ничего в этом такого особого.
0

Ну, в моём представлении, системы управления транспортом, всё же должны работать в реальном времени, на операционных системах реального времени, в то время как протоколы семейства http подразумевают не только асинхронность (особенно третье поколение), но и непредсказуемость задержек. Возможно, я просто чуть старомоден — автомобильное образование получал ещё в прошлом веке, когда многие взгляды и на ИТ, и на автоматизацию вообще, сильно отличались от сегодняшних.

0
Этот запрос же приходит извне. Его может и обрабатывать система в реальном времени. Непредсказуемость задержек всегда будет из-за беспроводной сети до машины и протокол или ОС не особо поможет тут как я дуиаю. И нужно понимать, что это высокоуровневый запрос, вида «тормози до остоновки» или «ускоряйся до скорости X» от мобильного приложения. Можно, наверное, иметь формат запроса с дедлайном и как-то синхронизировать часы. Но это можно уложить в любой протокол.
Внутри в микроконтроллерах различные компоненты, наверняка на особых ОС и там особые протоколы используются. Но даже тут задержки могут быть очень разными. Особенно, если это ДВС, который ну очень медленный в плане реакции за событие.
+1
Потеря соединения это штатная ситуация и всегда такой будет, ее обязаны обрабатывать все сетевые приложения. Техники прозрачного восстановления соединений при разработке сетевых приложений известны еще с 90-х годов. Решение этой задачи (не проблемы) с помощью замены протокола на транспортном уровне является дичайшим оверхедом.
+2
Данные передаются в текстовом виде, а значит передача картинок, видео и прочей нетекстовой информации неэффективна.
Тут видимо стоит сделать уточнение, что бинарные данные переводятся в текст только при отправке с клиента на сервер, например POST-е формы.
В остальных случаях (которых большинство) бинарные данные идут как есть, а текстовые только заголовки.
+1
Я не понимаю ни фразу из статьи ни то что вы пишете. У вас есть какой-то пруфлинк для «бинарные данные переводятся в текст только при отправке с клиента на сервер, например POST-е формы»?
+1
По-моему и это не верно. Когда клиент кодирует данные в multipart/form-data, а это большинство (все?) варианты отправки файлов, то бинарные данные остаются бинарными.
0
Конечно, в зависимости от Content-Type. Вероятно изначально речь должна была идти только о заголовках протокола.
0
Здравствуйте Юрий. Статья конечно интересная. Если я правильно понял вашу статью, всё что предлагают «товарищи» это как бы делать всё то что делает TCP, только программным способом.
Нужно так же как-то резать «данные» на пакеты определённого размера (ведь буфер сетевой Ethernet карты не бесконечен). Метить эти пакеты (порядковый номер в потоке). Поднимать флаг установки нового соединения\сеанса связи. Считать контрольную сумму пакета.
Тоесть получается всё то что сейчас делает аппаратная часть TCP переложить на хост процессор. Конечно реализация аппаратной части UDP намного проще.

В связи с этим такой вопрос, как вы думаете не связано ли это «движение» с заблаговременной подготовкой ко встрече 5G ???
Тоесть это всё начинают проектировать не для проводного Etherneta ???
Поэтому на первый взгляд всё кажется немного бестолковым ?!
Ведь в радиосреде практически все пакеты данных по своей сути UDP. Причём до определённой меры, широковещательные пакеты UDP. На радио тракте бессмысленно существование аппаратуры TCP. То что есть сейчас это появилось как радиоэкспадеры для обычных проводных сетей.
А в сенсорных мэш радиосетях ничего близкого под TCP нет. Там везде по сути UDP.
Ну и с учётом того что активно всех сгоняют в «облака». «Облака» сгонят в одну «тучу» (дата центр\центры), наподобие как Гугл или Фейсбук.
И все будут «говорить» с этой тучей через массивы антенн 5 G посредством своих гаджетов.
А провода будут постепенно везде скручивать. И всех убеждать что мол крайне не модно по проводам в соц.сетях сидеть.

0
Если я правильно понял вашу статью, всё что предлагают «товарищи» это как бы делать всё то что делает TCP, только программным способом.

Не совсем. QUIC ещё должен решить проблему «head-of-line blocking» и предоставить лёгкий способ поддержания соединения при изменении IP-адреса клиента.

В связи с этим такой вопрос, как вы думаете не связано ли это «движение» с заблаговременной подготовкой ко встрече 5G ???


Не думаю, что у меня достаточно компетенций, чтобы уверенно отвечать на этот вопрос. Могу только сказать, что тесты производительности для gQUIC в случае работы через смартфон по мобильной сети, показывают, что gQUIC в этом случае имеет меньший отрыв от  TCP, чем при использовании десктопного компьютера и кабельного интернета. Да, тут больше важна производительность смартфона, но всё-равно, думаю, что развитие мобильных сетей в меньшей степени оказывает влияние на развитие QUIC, чем упоротость создателей и желание решить указанные выше проблемы :)
Only those users with full accounts are able to leave comments., please.