The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ночных и бета сборках Firefox включена по умолчанию поддержка HTTP/3 , opennews (ok), 21-Мрт-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


94. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –2 +/–
Сообщение от Ilya Indigo (ok), 21-Мрт-21, 15:25 
> WebSockets. Очевидно, нужная вещь. Работающая. Полезная.

Никогда не понимал, зачем использовать это трудно-реализуемое дерьмо, если есть простой и нативный (для HTTP протокола), SSE, который в тандеме с redis отлично работает!?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

98. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Урри (ok), 21-Мрт-21, 15:41 
Не знал о таком.
Ответить | Правка | Наверх | Cообщить модератору

107. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +2 +/–
Сообщение от Ilya Indigo (ok), 21-Мрт-21, 16:48 
> Не знал о таком.

https://developer.mozilla.org/ru/docs/Web/API/Server-sent_ev...
Не удивительно. Google так любит кукарекать о своих монструозных и ненужных поделках, таких как websockets, AngularJS, docker, kubernates и прочих или вообще ненужных или нужных только узкому круку специалистов, занимающимися облаками, но они про них кукарекают молодым специалистам, но ни слова не говорят о самые обычном и нативном, таком как SSE, redis, systemd (capibilities).

Год назад передавал свой web-проект молодому разработчику, который нишиша не знает о linux, о том как настраивать nginx и php-fpm, уже молчу про то чтобы создавать и настраивать systemd-юниты, но он знает про docker и как устанавливать nginx и php из докера!
На вопрос, на хрена тебе сдался докер!? Он отвечает, что это удобно надёжно и безопасно...
На мой комментарий о том, что всё что делает докер можно сделать и использую capibillities в systemd, и это будет и удобнее и надёжнее, он говорит про них он не знает для него это слишком сложно, меня учили так и мне сказали что это надёжно и безопасно...
И как я и ожидал, у него хорошенько подгорело, когда он узнал что в проекте используется ещё и redis...
Ведь для redis нужен отдельный контейнер и настроить взаимодействие между этими контейнерами выставив привелегии и общие файлы... И самое умное что он сделал это спросил, а нельзя ли УБРАТЬ redis из проекта. XD XD XD
В общем такие гугловые специалисты растут....

Ответить | Правка | Наверх | Cообщить модератору

118. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +1 +/–
Сообщение от Урри (ok), 21-Мрт-21, 17:39 
Ну тот проект я уже давно сдал, а за информацию спасибо. Почитаю и если придут с похожей задачей возможно попробую предложить.
Ответить | Правка | Наверх | Cообщить модератору

143. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –1 +/–
Сообщение от Аноним (-), 21-Мрт-21, 20:04 
Да ладно тебе, вебсокеты не монструозные. Там конечно есть скелеты в шкафу, но вообще простой дровяной протокол, его даже мелкий lwan себе запилил. И таки оно именно нормальный поток, с произвольными данными, более потребный для околореатлаймных коммуникаций типа чатика или апдейтов статусов/переменных. А не какой там HTTP на костылях. Хоть вебмакаки и навебмакачили, конечно, малость.

HTTP сам по себе сильно монструознее - и имеет множество бестолковостей. В том числе очень вредных. Например желающие могут загуглить про slowloris и чего вообще можно делать с HTTP даюы нагнуть вам сервер. Ну вот например размер хидеров никак особо не лимитирован, и если саботер будет их слать в час по чайной ложке, большая часть серваков вообще конекцию не закроет и будет жрать ресурсы на обслуживание слоупока условно-вечно. Если слоупок был вредителем и наплодит таких конекций - довольно скоро сервер утрачивает способность обслуживать легитимных юзеров. Самому слоупоку атака обходится не сильно дорого по ресурсам, у него контекст может быть сильно меньше.

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

155. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Ilya Indigo (ok), 21-Мрт-21, 20:24 
Что за дичь Вы несёте!?
Зассанный казачёк от Гугл или просто идиот?
Slowloris и прочие атаки возможны только на коряво настроенном сервере.
На нормальном сервере (последний nginx с дефолтными настройками) таймауты и прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в логах этот вредитель быстро будет замечен и забанен.
WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо легче и эффективнее организовать.
Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг!
Ответить | Правка | Наверх | Cообщить модератору

168. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Аноним (-), 21-Мрт-21, 22:12 
> Зассанный казачёк от Гугл или просто идиот?

Тот кто поигрался с HTTP, ws и издевательствами над ними на низком уровне, а также и потестивший всякие странные приколы. Пойдет? :)

> Slowloris и прочие атаки возможны только на коряво настроенном сервере.

ЧСХ на момент его появления такими были чуть более чем все. А наименее корявым - IIS (фэйспалм!)

Кроме того - вот именно хорошего фикса slowloris'а не существует в природе. Попытка фикса либо будет гасить юзеров на медленных и перегруженных каналах, либо у слоупока дочерта времени слоупочить, занимая на себя ресурсы.

> На нормальном сервере (последний nginx с дефолтными настройками) таймауты и
> прочие ограничения такого сделать просто не дадут, а если кто-то попытается, то в
> логах этот вредитель быстро будет замечен и забанен.

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

> WebSockets монструозен, по сравнению с SSE, на котором и чатики и всё
> остальное, включая обновления страницы в реальном времени без перезагрузки, можно гораздо
> легче и эффективнее организовать.

Я не знаю кому там и что "легче" но выглядит это как попытка натянуть сову на глобус. А ws таки может быть совершенно отдельный канал, не имеющий ничерта общего с HTTP и его протоколом после его подъема, по поводу чего там может гулять эффективный task-specific протокол, вообще никак не завязаный на HTTP и ближе всего это, натурально, к сетевому сокету. И я не вижу ничерта сложного с подъемом ws, это и в js делается парой строк, да и на стороне сервера не сильно сложнее. В lwan examples этого есть и назвать все это сложным - глум над здравым смыслом.

> Шли бы Вы со своим Иваном и прочими гулоботами отсюда нафиг!

Каким еще иваном? И вообще, я к гуглу прохладно отношусь, что не мешает считать вебсокет довольно удобным и простым для периодического апдейта каких-то данных или околореалтаймных штук типа чатиков. А кучка легаси и вебмакакинга в протоколе - ну да, но тупняков и в HTTP есть. Черт, мы даже не знаем размер хидеров заранее, как минимум в HTTP/1.x точно. И поэтому даже не можем сразу отлупить заведомо офигевшего клиента (типа slowloris'а) - только дурацкой эмпирикой выезжать, которая неуниверсальна и косит легитимных юзерей под шумок, виноватых тем что в каком-нибудь поезде ехали и линк тупил.

Ответить | Правка | Наверх | Cообщить модератору

223. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  –1 +/–
Сообщение от Додо (?), 22-Мрт-21, 11:56 
Потому что SSE односторонний - с сервера к клиенту. Для отправки данных от клиента к серверу придется использовать HTTP запросы и как-то отправлять ответ через SSE.
Вебсокеты - двухсторонние. Можно получать данные от клиента, можно отправлять данные клиенту. Обработку данных можно производить в рамках одного класса.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

233. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Ilya Indigo (ok), 22-Мрт-21, 14:05 
> Потому что SSE односторонний - с сервера к клиенту.

Ещё один гуглобот...
Потому что через HTTP есть дофига способов отправить сообщение от клиента к серверу, в отличие от WebSockets, который НЕ может работать через HTTP, и он ВЫНУЖДЕН реализовать канал от клиента к серверу, который в случае с SSE просто не нужен, так данные в обе стороны проходят через HTTP в рамках одного класса!
И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...

Ответить | Правка | Наверх | Cообщить модератору

240. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Додо (?), 22-Мрт-21, 18:42 
> Ещё один гуглобот...

Попрошу без перехода на личности. Называть всех, кто не согласен с вашим мнением, ботами - это признак дурного тона и некомпетентности.

> Потому что через HTTP есть дофига способов отправить сообщение от клиента к
> серверу, в отличие от WebSockets, который НЕ может работать через HTTP,
> и он ВЫНУЖДЕН реализовать канал от клиента к серверу, который в
> случае с SSE просто не нужен, так данные в обе стороны
> проходят через HTTP в рамках одного класса!

С использованием HTTP можно отправить данные от клиента к серверу:
1. в пути запроса, через query-переменные;
2. в заголовках запроса;
3. в теле запроса (при использовании методов POST, PUT, PATCH).
Это не "дофига способов", это только три. Если отправлять сообщения при помощи SSE, от сервера к клиенту, то можно указать только event и тело.
В Websocket можно указать только тело сообщения. При запросе апгрейда соединения - еще query параметры и заголовки (хоть передачу заголовков мало кто поддерживает).
В конечном счете все сводится к тому, что практически всегда данные передаются в теле запроса, в том или ином сериализованном виде. И с этой точки зрения нет никакой разницы, что использовать.
Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные данные, у него используется \n\n как разделитель сообщений.

> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...

И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит.
Если смотреть на данные https://caniuse.com/ , то поддержка Websocket в Chrome появилась с версии 4, SSE с версии 6. Не такой уж большой разрыв.
Кстати, там же можно заметить, что в Firefox Websocket появился в версии 4, а SSE в версии 6 (такое вот совпадение) - что, Mozilla в далеком 2011 году тоже продалась Google, раз реализовала Websocket раньше SSE? :)

Ответить | Правка | Наверх | Cообщить модератору

241. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Ilya Indigo (ok), 22-Мрт-21, 19:09 
> Это не "дофига способов", это только три.

А этого мало, или мы за неимением аргументов переходим к придиркам к словам?

> В конечном счете все сводится к тому, что практически всегда данные передаются
> в теле запроса, в том или ином сериализованном виде.
> этой точки зрения нет никакой разницы, что использовать.

То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а вовсе не преимущество над SSE.

> Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные
> данные, у него используется \n\n как разделитель сообщений.

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

>> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
> И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит.

Не важно кто входит в группу, важно кто пиарит или каким-то образом поддерживает этот пиар.

docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо или косвенно, именно он!

Ответить | Правка | Наверх | Cообщить модератору

254. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/–
Сообщение от Додо (?), 23-Мрт-21, 11:47 
>> Это не "дофига способов", это только три.
> А этого мало, или мы за неимением аргументов переходим к придиркам к
> словам?

Это не "дофига", это "несколько". И как раз ваш вопрос является придиркой.
Аналогично можно передавать данные в query-параметрах и заголовках при осуществлении соединения по SSE или при апгрейде соединения в Websocket. Разница только в том, что для SSE и Websocket в них можно передать данные лишь в самом начале, а в HTTP-запросах - в каждом запросе.

>> В конечном счете все сводится к тому, что практически всегда данные передаются
>> в теле запроса, в том или ином сериализованном виде.
>> этой точки зрения нет никакой разницы, что использовать.
> То есть Вы признаёте что двунаправленность WebSockets это просто маркетинговый пиар, а
> вовсе не преимущество над SSE.

Большой минус HTTP-запросов - необходимость открывать новые соединения (постоянно для HTTP 1, периодически дли HTTP 2/3).
В случае SSE при использовании HTTP 1 мы имеем 1+n соединений (1 соединение для SSE, n соединений для отправки HTTP запросов).
В случае Websocket мы имеем 1 соединение в любом случае, так как через него можно и отправлять, и получать данные.

>> Кстати, у SSE есть большой, жирный минус: через него нельзя передавать бинарные
>> данные, у него используется \n\n как разделитель сообщений.
> Необходимость передачи бинарных данные у меня и не возникала, но решается элементарно
> с base64.

base64 раздувает данные на треть. 4096 байт в base64 будут 5464 байт.
SSE не дает отправлять сырые текстовые сообщения, по причине того же разделителя. Нужно обязательно как-то сериализовать данные, чтобы не дай боже в теле не было \n\n.

Итого мы имеем...
SSE:
+ более нативное поведение для протокола (легко реализуется);
- обязательная сериализация данных (ограничение протокола);
- невозможность передачи бинарных сообщений (ограничение протокола);
- односторонний канал связи (ограничение протокола, требует дополнительных запросов для отправки данных).
Websocket:
+ двухсторонний канал связи (отправка и получение данных внутри одного соединения);
+ возможность передачи любых сообщений в любом виде (в том числе бинарных);
- отдельный протокол, требующий особой поддержки и апгрейда соединения (сложность реализации, плохо продуманный handshake).
Казалось бы, зачем нужен Websocket, если у SSE "дофига" плюсов (целый один)?

>>> И этот вынужденный костыль, маркетолухи гугла раскручивают как мегафичу...
>> И SSE, и Websocket были разработаны в рамках группы WHATWG. В нее как бы не только Google входит.
> Не важно кто входит в группу, важно кто пиарит или каким-то образом
> поддерживает этот пиар.
> docker и kubernates тоже не один гугл разрабатывает, но вкладывается пиар, прямо
> или косвенно, именно он!

SSE разработан для отправки сообщений с сервера.
Websocket разработан как аналог TCP соединения в JS (с ограничениями), изначально даже назывался TCPConnection.
Это _разные_ технологии, и из этих двоих Websocket более функционален. Его даже пиарить не нужно, он банально более удобен в использовании. В Websocket можно легко инкапсулировать другие протоколы, типа STOMP.

А насчет пиара... Вон, Microsoft в последнее время пиарит Linux. Что теперь, отказываться от Linux и переходить на FreeBSD? Oh, wait, его же Sony пиарит, используя в своих консолях...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру