The OpenNET Project / Index page

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



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

"Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от opennews (ok), 07-Июн-22, 08:56 
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола HTTP/3.0 и опубликовал связанные с ним спецификации под идентификаторами  RFC 9114 (протокол) и RFC 9204 (технология сжатие заголовков QPACK для HTTP/3). Спецификация HTTP/3.0 получила статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний. Одновременно опубликованы обновлённые варианты спецификаций для протоколов HTTP/1.1 (RFC 9112) и HTTP/2.0 (RFC 9113), а также...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57309

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

Оглавление

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


1. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +8 +/
Сообщение от Жироватт (ok), 07-Июн-22, 08:56 
Welcome to googlenet?
Ответить | Правка | Наверх | Cообщить модератору

8. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +58 +/
Сообщение от Брат Анон (ok), 07-Июн-22, 09:28 
С разморозкой. Гугельнет начался с этапа отжатия 50+% браузеров.
Ответить | Правка | Наверх | Cообщить модератору

24. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +4 +/
Сообщение от Аноним (24), 07-Июн-22, 10:27 
С другой стороны лучше бы разрабы браузеров внедряли BitTorrent-протокол, чтобы скомпенсировать.
Ответить | Правка | Наверх | Cообщить модератору

32. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (32), 07-Июн-22, 11:04 
Больше мониторов богу мониторов!
Ответить | Правка | Наверх | Cообщить модератору

40. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (40), 07-Июн-22, 12:25 
VR из каминг, покайтесь.
Ответить | Правка | Наверх | Cообщить модератору

75. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (75), 07-Июн-22, 15:34 
is coming out
Ответить | Правка | Наверх | Cообщить модератору

86. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (86), 07-Июн-22, 16:22 
> внедряли BitTorrent-протокол

Ты хотел сказать IPFS?

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

170. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Bob (??), 08-Июн-22, 11:38 
Он тогда уже закончился, с захватом от 50% рынка...
Начался ещё с покупки YouTube и пихания хрома во все щели: IE, инсталляторы и т.п.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

2. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от pashev.ru (?), 07-Июн-22, 09:00 
Одни статусы, толку нет.
Ответить | Правка | Наверх | Cообщить модератору

9. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от Брат Анон (ok), 07-Июн-22, 09:29 
> В настоящее время поддержка QUIC и HTTP/3.0 уже реализована во всех популярных web-браузерах
> (в Chrome, Firefox и Edge поддержка HTTP/3 включена по умолчанию, а в Safari требует включения
> настройки "Advanced > Experimental Features > HTTP/3").

Правильно. Не читай, сразу пиши.

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

18. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –10 +/
Сообщение от pashev.ru (?), 07-Июн-22, 09:56 
И чо? Зачем оно?
Ответить | Правка | Наверх | Cообщить модератору

95. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от fi (ok), 07-Июн-22, 17:12 
на днях вышел haproxy 2.6 - уже с http3 )))

так что процесс пошел

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

125. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от microsoft (?), 07-Июн-22, 21:20 
https://github.com/haproxy/haproxy/issues/680

Таки ты врешь. Статус open.

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

188. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (188), 08-Июн-22, 20:58 
В доках (https://raw.githubusercontent.com/haproxy/haproxy/v2.6.0/doc...) упоминается поддержка HTTP/3, для включения которой нужно указать h3 в опции alpn.
Ответить | Правка | Наверх | Cообщить модератору

200. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (200), 09-Июн-22, 11:54 
Только она не включится, если не собрать с USE_QUIC и патченым OpenSSL.
Ответить | Правка | Наверх | Cообщить модератору

199. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (200), 09-Июн-22, 11:53 
>  на днях вышел haproxy 2.6 - уже с http3 )))

Есть нюансы https://www.haproxy.com/blog/announcing-haproxy-2-6/#http-3-...
> You’ll need to compile HAProxy with a few new options, including the USE_QUIC flag, and also link to a QUIC-compatible version of OpenSSL

1. Статус пока - tech preview.
2. При сборке по умолчанию выключено.
3. Нужна патченая версия OpenSSL (потому что официальный стабильный релиз OpenSSL вертел все эти QUICи известно на чём).

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

154. "Децентрализация"  +/
Сообщение от Романemail (??), 08-Июн-22, 06:34 
Прощай, роскомблокиратор
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

275. "Децентрализация"  +/
Сообщение от Онаним (?), 11-Июн-22, 20:10 
Чем оно тебя спасёт от блокиратора?
От блокиратора спасёт только ECH, да и то не сразу.
Ответить | Правка | Наверх | Cообщить модератору

3. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –3 +/
Сообщение от pashev.ru (?), 07-Июн-22, 09:03 
> Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;

А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅

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

6. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +6 +/
Сообщение от i (??), 07-Июн-22, 09:22 
пакеты теряются всегда, так уж устроен ip
Ответить | Правка | Наверх | Cообщить модератору

90. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от ip1982 (ok), 07-Июн-22, 17:05 
Только в одном потоке, или во всех случайным образом?

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

204. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от 67 (?), 09-Июн-22, 12:46 
случайно конечно, если поток маленький, то и потерь может не быть, но модемное прошлое даром не прошло
Ответить | Правка | Наверх | Cообщить модератору

122. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Ан (??), 07-Июн-22, 20:34 
А про TCP ты забыл, да? Вот в UDP, который в новом стандарте, будут теряться безвозвратно, да.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

128. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 22:11 
> А про TCP ты забыл, да?

В TCP точно так же теряется и нужно перепосылать. И нет, это будет другой пакет.

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

173. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Ан (??), 08-Июн-22, 12:29 
>> А про TCP ты забыл, да?
> В TCP точно так же теряется и нужно перепосылать. И нет, это
> будет другой пакет.

Это будет тот же payload. И не придуривайся, что ты не понял, о чём речь.


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

206. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 09-Июн-22, 16:54 
Я как раз очень хорошо понимаю о чём идёт речь. Пейлоад, в некоторых случаях, тоже будет другим.
Ответить | Правка | Наверх | Cообщить модератору

205. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от 67 (?), 09-Июн-22, 12:56 
проторол контроля передачи, потери учитывает и логику работы сетевого стека подстраивает, данные он передает гарантированно, или ошибки выдает, но пакеты теряет бай-дизайн.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

215. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 10-Июн-22, 16:32 
> будут теряться безвозвратно, да.

Их перепошлет сама реализация QUIC. Это лучше чем уповать на кернел. Особенно когда ископаемые из эпохи диалапа думают что окей использовать попытки повтора отсылки пакета с таймаутами измеряемыми в МИНУТАХ, так что на мобильных линках с движущимися абонентами TCP творит жесточайший трэш как только покрытие отлично от идеала, а MS еще и не переубедишь сменить congestion control. Впрочем он и в linux работает так себе, даже BBR и Codel весьма компромиссные штуки.

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

10. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от keydon (ok), 07-Июн-22, 09:29 
Там речь про смену маршрутов вроде перехода с LTE на wifi - но мне кажется оно того не стоит.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

11. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Брат Анон (ok), 07-Июн-22, 09:31 
Ещё раз:

> Потеря пакета ...

Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать прочитанное, увиденное и услышанное. Просто пипец какой-то.

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

20. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 10:03 
> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать
> прочитанное, увиденное и услышанное. Просто пипец какой-то.

Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты теряются всегда и везде, а вынос операции обработки этого события в userspace никак не уменьшает вероятность этого события. Более того, хочу напомнить, что изначально Google толкал BBR, но отказался от него в спецификации, а большинство реальных реализаций используют доступные уже многие годы алгоритмы CUBIC/Reno. Да, я знаю, что Google запилил даже BBRv2 (он всё ещё не релиз) и у себя использует какую-то третью реализацию, отличную от BBRv1, доступного в ядре Linux, и BBRv2, но общей картины это никак не меняет.

P.S. Миграция соединения всё же полезная "фича".

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

45. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –3 +/
Сообщение от Брат Анон (ok), 07-Июн-22, 12:46 
>> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать
>> прочитанное, увиденное и услышанное. Просто пипец какой-то.
> Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты
> теряются всегда и везде

Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.


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

49. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от Аноним (49), 07-Июн-22, 12:55 
Пакет потерял сам себя, и не пришёл по адресу, по которому его отправили. Сколько там розг за такое положено? Тут уже не отвертишься, серьёзный прокол. Хорошо, если не казнят.
Ответить | Правка | Наверх | Cообщить модератору

51. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 12:59 
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите
> русский язык. Пакет не может потерять САМ СЕБЯ.

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

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

59. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +15 +/
Сообщение от InuYasha (??), 07-Июн-22, 13:40 
Звенит январская вьюга,
Патч-корды хлещут упруго,
Пакеты мчатся по кругу,
И шумят сервера.
Не видят пакеты друг друга,
Проходят мимо друг друга,
Теряют пакеты друг друга,
А потом не найдут никогда.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

177. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (177), 08-Июн-22, 13:32 
Зачот!
Ответить | Правка | Наверх | Cообщить модератору

91. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от ip1982 (ok), 07-Июн-22, 17:07 
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.

Брат, языки сложнее чем ты думаешь :)

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

98. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +6 +/
Сообщение от Аноним (128), 07-Июн-22, 17:27 
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.

Тебя задорнов покусал?

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

142. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (142), 08-Июн-22, 00:32 
>Пакет не может потерять САМ СЕБЯ.

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

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

183. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Ся (?), 08-Июн-22, 17:59 

Ругаться - ругать себя? (На деле непереходный глагол со значением взаимности)
Обмануться - себя обмануть? (Непереходный глагол со значением страдательности)

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

210. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним 80_уровня (ok), 09-Июн-22, 18:31 
У моего соседа собака кусается!
Ответить | Правка | Наверх | Cообщить модератору

216. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (128), 10-Июн-22, 16:42 
Ну это они как раз любят — за хвост самоё себя пожрать.
Ответить | Правка | Наверх | Cообщить модератору

15. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +6 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 09:49 
> А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅

Пакеты теряются по дизайну, именно потеря пакета и является тем, что даёт сигнал отправляющему данные о том, что нужно снизить скорость. Да, есть ECN и есть delay-based алгоритмы управления потоком, но первые спустя столько-то лет до сих пор не включены по умолчанию ни в этих ваших Линуксах (два Linux'а в дефолтной конфигурации не договорятся о ECN), ни в значительной части сетевого оборудования (это вообще стыд и срам, причин не включать просто нет), а вторые по дизайну проигрывают packet-loss алгоритмам и внедрять их надо сразу и везде или городить гибридные алгоритмы, которые будут определять событие конкуренции с loss-based потоком.

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

217. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 10-Июн-22, 16:43 
Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки на сеть. Всплеск помех выбивающий пакет в радиолинке или временная потеря сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения к нагрузке на сеть - однако это легко убивает скорость TCP до диалапных величин и даже хуже.

А вот такие тупари с вон тем дизайном, не способные понять что мир немного изменился и люди хотят беспроводные сети - очень работе этих сетей вредят. И теперь их слушать никто не будет, плохая работа беспроводных сетей и жалующиеся пользователи всех достали. Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов. Поэтому у юзеров гуглобраузера будет первоклассный юзер экспериенс. А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь.

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

233. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:16 
> Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки
> на сеть.

Нюанс не в этом, что там не пакеты...

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

245. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 00:58 
> Нюанс не в этом, что там не пакеты...

Кэп намекает что с точки зрения TCP/IP вообще есть только пакеты и rtt. Да и беспроводные линки так то packet-switched сети в основном. В каких-то случаях это может называться в другом протоколе фреймом и проч, но суть дела не меняет. А раскручивать абстракции до I/Q модуляторов мы все же не будем: TCP/IP это вообще не видно. С его точки зрения - вон то.

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

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

234. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:20 
> Всплеск помех выбивающий пакет в радиолинке или временная потеря
> сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения
> к нагрузке на сеть - однако это легко убивает скорость TCP
> до диалапных величин и даже хуже.

Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до диалапных величин из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети; б) если вы не используете Reno, то восстановление произойдёт достаточно быстро.

Проблема в том (основная), что бесповодная сеть меняет символьную скорость данных, подстраиваясь под условия, и эта информация никак не коммуницируется на более высокий уровень OSI.

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

246. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:16 
> Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до
> диалапных величин

Красивая теория, но своему снифферу я доверяю больше чем какому-то эксперту опеннета с стремным уровнем квалификации.

> из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети;

Кэп намекает что для TCPIP результат бинарный: протоколы под ним или выдюжили, или нет. Для TCP пакет или доставлен корректно, или нет. При том тот всплеск "не выдюжили" во первых может быть рандомный. Во вторых не связан с "congestion" и - просто не повод к снижению скорости TCP потока, о великий эксперт! Некоторые, типа CDG и BBR даже пытаются какой-то эвристикой это определять, но получается довольно компромиссно и к тому же это 2-сторонняя игра.

Еще можно выпасть на цать секунд из сети если прореха в покрытии. Хэндовер при этом не удается и модем довольно долго ищет сеть, регается в ней, и в целом это может выбить из сети на ...цать секунд. За это время TCP обычно успевает конкретно обидеться на недоставку пакетов и проапгрейдить легкий вылет до доброй минуты полного дауна. И например в реалтайм чатике в чем-то движущемся сие например подбешивает.

> б) если вы не используете Reno, то восстановление произойдёт достаточно быстро.

То-есть ss кажущий как кернел лихо отсчитывает добрых 60 секунд на перепосыл пакета был моим глюком? Да ладно? :)

> Проблема в том (основная), что бесповодная сеть меняет символьную
> скорость данных, подстраиваясь под условия, и эта информация никак
> не коммуницируется на более высокий уровень OSI.

И это тоже. Впрочем вон там packet loss кой-как пытаются классифицировать - всплеск ли это или глобальный аут но честно говоря получилось оверинженернутое УГ которое навороченое но работает не особо хорошо и все-равно дурит временами.

А в сабже кстати у гугли есть идея и свой FEC делать - так то можно пролюбить 20% пакетов, починить это FEC - и хотя линк дурил, юзер этого вообще не увидит. А, представляете, FEC можно так то interleave'ить и комбинировать и это сильно улучшает надежность ценой некоторой потери скорости.

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

235. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:22 
> А вот такие тупари с вон тем дизайном, не способные понять что
> мир немного изменился и люди хотят беспроводные сети - очень работе
> этих сетей вредят.

Ну напиши congestion control новый, степень защитишь и на работу получше устроишься.

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

247. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:20 
> Ну напиши congestion control новый, степень защитишь и на работу получше устроишься.

Да вон сабж уже написали. К тому же его гугл доставит ВСЕМ. И мне и даже тому ламеру с виндой. И вообще, это тот случай когда гугл явно нанял нормальных инженеров а не вебмакак или ретардов "мытакпривыкли, диалап рулит". Сделано с кой-каким пониманием проблематики и относительно осмысленным заруливанием оной. То что у меня сильно лучше получится не факт, а TCP с его congestion трогать я бы вообще лишний раз трогать не стал. Неудобно марафон в ластах бегать.

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

236. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:27 
> И теперь их слушать никто не будет, плохая
> работа беспроводных сетей и жалующиеся пользователи всех достали.

Пользователи и правда в своей массе являются причиной своих же неприятностей. Это такие вот и кидают точки там, где надо тянуть кабель, врубают каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность на максимум и фсё, общий ресурс скушан... а девелоперы дураки )))

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

253. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:43 
> Пользователи и правда в своей массе являются причиной своих же неприятностей. Это
> такие вот и кидают точки там, где надо тянуть кабель, врубают
> каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность
> на максимум и фсё, общий ресурс скушан... а девелоперы дураки )))

Ну и как я протяну кабель тому поезду заезжаюшему под мост? Или почему у меня из-за вылета физики на 10 секунд поток данных на уровне TCP долежн потом стоять раком минуту? Потому что это угробище дизайнили гении с весьма абстрактным видением ситуации? Ну а гугл вот может нанять тех кто сделает "как лучше работает для большей части юзеров" вместо этого всего. Это хорошо и правильно.

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

295. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:02 
Сейчас бы ожидать от пользователя степени по беспроводной передачи данных. Пока на уровне протокола не будет решена проблема совместного использования радиоэфира, ничего не будет. И да, я один из тех, кто включает всё на полную мощность, с максимальной шириной канала. Не досуг мне в рентованном доме кабели тягать, а на соседей похер — им саппорт предложит перезагрузить модем, и он пересядет на другой канал, подальше от меня. Общий ресурс, говоришь? А я по праву сильного отнял себе всё. Что делать будешь?
Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

237. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:31 
> Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов.

Я тебя разочарую, но QUIC в реальной жизни сливает TCP — https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio...

И это я ещё не скидываю внутрипротокольную статистику по таким параметрам как jitter, например, где твой QUIC сливает на всех платформах.

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

248. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:24 
> Я тебя разочарую, но QUIC в реальной жизни сливает TCP

Мне достаточно того что я в реальной жизни порой вижу как TCP ПОЛНОСТЬЮ ВЫРУБАЕТ ПОТОК ДАННЫХ НА МИНУТУ при довольно скромных отклонениях от идеала, особенно в чем-нибудь движущемся, и этот булшит творится уже цать лет, чего достаточно для искреннего пожелания нехороших вещей всем к этому причастным.

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

238. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:36 
> А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся
> по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь.

Ну шта, шта ты несёшь? История вообще не про это. Но, если тебя интересует, то данные о том, чем козырял гугл в оригинальной презентации, с данными о QUIC+BBR не пинал только ленивый. В реальной жизни они просто не подтверждались, а BBR просто за счёт агрессивности выигрывал полосу у конкурентов. Кстати, именно поэтому от него и отказались и начали пилить BBRv2, который из беты не вылезает уже пару лет (уточни, просто новостей о нём особых нет), а для себя Google изобрёл какой-то третий алгоритм, который в профильной литературе иногда называют BBRv1.5.

Но некоторые вьюноши, начитавшись восторженных статей на medium у таких же, как и они, продолжают "дрочить" после прописывания net.ipv4.tcp_congestion_control=bbr даже не имея возможности провести качественную оценку полученного результата. Но тут проблема психологическая, если им это помогает с ними, проблемами, справляться, то... почему бы и нет )))

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

249. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:36 
> жизни они просто не подтверждались, а BBR просто за счёт агрессивности
> выигрывал полосу у конкурентов.

Даже он так то получился компромиссным. А агрессивность хоть немного приводит его в чувство на intermittent connectivity типа беспроводки, особенно в чем-то движущемся, но даже так он таки тоже может основательно тупить если не повезло. В результате мимо пролетает пять сот способных налить тонну трафа, ни в раз не перегруженых, а TCP просто туповэйтил в это время. И спасибо если когда он через минуту вяло пульнет пакетик там сота окажется. А если нет - ну, ой, диалап тогда покажется очень быстрым по сравнению с этим вашим 4G.

Он пытается в классификацию было ли это вспердом линка или реально глобальным перегрузом но например с прорехами покрытия все-равно работает погано. Прикиньте, дыра в покрытии когда какой-нибудь поезд или авто заехал под мост или в тоннель - не перегруз сети!

> Google изобрёл какой-то третий алгоритм, который в профильной литературе иногда называют BBRv1.5.

А таки BBR хоть немного приводит

> Но некоторые вьюноши, начитавшись восторженных статей на medium у таких же, как
> и они, продолжают "дрoчить" после прописывания net.ipv4.tcp_congestion_control=bbr

А еще можно подр@чить на сетевой снифер и посмотреть что реально творится в той или иной ситуации. И если я вижу что линк реально есть но TCP туповэйтит, так что link utilisation стремится пробить плинтус... кхе-кхе... я очень понимаю сабжевые инициативы и почему вон то должно сдохнуть жестокой смертью. Со всеми причастными.

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

Чисто психологически меня подбешивает, особенно в реалтаймном чатике, когда 10-секундный отвал апгрейдится TCP до минуты-другой дауна, а всперды в канале роняют скорость до величин ниже диалапа, и спасибо если оно вообще когда-то разгонится потом. А то может так и остаться, думаете с хрена ли многопоточные качалки появились? Хоть немного компенсирует эту идиотию протокола.

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

266. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 06:50 
Болтун с нулевыми техническими знаниями в вопросе. Извини, не буду утруждать себя ответом.
Ответить | Правка | Наверх | Cообщить модератору

276. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 00:29 
> Болтун с нулевыми техническими знаниями в вопросе. Извини, не буду утруждать себя ответом.

Давно известно что если технические аргументы закончились, можно перейти на личность оппонента. Классика жанра. Заодно надежно выдает эксперта в области.

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

12. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от Аноним (12), 07-Июн-22, 09:36 
Протокол всё равно режут - https://ntc.party/t/http-3-quic/1823/
Ответить | Правка | Наверх | Cообщить модератору

171. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Bob (??), 08-Июн-22, 11:43 
1) в инете всё равно делать нечего без VPN. Только в исключения добавить локалку и свою страну. Psiphon умеет. А прошаренные юзаюи Shadowsocks + базу геосайтов отсюда github.com/v2fly/domain-list-community
2) свой не режут, тот же Mail RU Group и т.п. Даже отчитываются как лучше стало на v3)
Ответить | Правка | Наверх | Cообщить модератору

223. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 10-Июн-22, 17:24 
Кэп намекает что shadowsocks - TCP...
Ответить | Правка | Наверх | Cообщить модератору

13. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от keydon (ok), 07-Июн-22, 09:36 
Неплохо если бы ещё и недостатки указывали: поддержка UDP некоторыми сетями, отсутствие вменяемого механизма противодействия ддос, на текущий момент работает в юзерспейсе, гугол...
Ответить | Правка | Наверх | Cообщить модератору

50. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от n00by (ok), 07-Июн-22, 12:57 
> отсутствие вменяемого механизма противодействия ддос

Написали жеж: "Поддержку ... обеспечивает ... Cloudflare". Вроде всё понятно. Хочется поставить смайлик, но не знаю, какой.

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

168. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +4 +/
Сообщение от Аноним (168), 08-Июн-22, 11:19 
Только не Cloudflare! Пожалуйста! Я уже не в силах решать проблемы, которые у меня возникают с cloudflare. Постоянный баннер: "У Вас нет доступа к этому контенту", "Вы из странной сети" или капча
Просто ненавижу это
Ответить | Правка | Наверх | Cообщить модератору

175. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (175), 08-Июн-22, 13:05 
Соглашусь. От кафлара уж очень много проблем. Что-то другое было бы лучше выбрать.
Ответить | Правка | Наверх | Cообщить модератору

179. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (179), 08-Июн-22, 14:15 
Ну конечно во всем виноваты пистолеты =) Этот облачный флаер просто выживает в условиях идиотизма законодательносго созданного на основе нежелания политиков сходить к семейному психологу :-)))
Ответить | Правка | Наверх | Cообщить модератору

182. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от keydon (ok), 08-Июн-22, 17:05 
> Ну конечно во всем виноваты пистолеты =) Этот облачный флаер просто выживает
> в условиях идиотизма законодательносго созданного на основе нежелания политиков сходить
> к семейному психологу :-)))

"Я не виноват, я выполнял приказ"?

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

244. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от InuYasha (??), 10-Июн-22, 23:21 
> "Я не виноват, я выполнял приказ"?

"А довольно улыбаетесь при этом вы тогда по какой инструкции?"

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

129. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 22:16 
> поддержка UDP некоторыми сетями

Broken by design сети совершенно никого не интересуют.

> отсутствие вменяемого механизма противодействия ддос

С точки зрения защиты от DDoS, нет разницы между TCP и UDP. Я тебе это говорю как отпахавший over 10 лет на телеком в отделе защиты от DDoS.

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

143. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от keydon (ok), 08-Июн-22, 01:13 
> С точки зрения защиты от DDoS, нет разницы между TCP и UDP.
> Я тебе это говорю как отпахавший over 10 лет на телеком
> в отделе защиты от DDoS.

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

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

207. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 09-Июн-22, 16:57 
И даже в этом случае разницы нет, трафик будет точно так же блэкхолиться на границе AS. Ты главное просигналь какой.
Ответить | Правка | Наверх | Cообщить модератору

14. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (14), 07-Июн-22, 09:43 
HTTP/2 хватит всем. А «HTTP/3» он вообще ненастоящий.
Ответить | Правка | Наверх | Cообщить модератору

21. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от Аноним (21), 07-Июн-22, 10:07 
я жду, когда выйдет HTTP/4. Надо продолжать развивать протокол, и как можно чаще. Я за развитие.
Ответить | Правка | Наверх | Cообщить модератору

42. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от Аноним (42), 07-Июн-22, 12:38 
RFC10xyz: "Протокол HTTP/4 определяет использование протокола QDIC (Quick DDCP Internet Connections) в качестве транспорта"
Ответить | Правка | Наверх | Cообщить модератору

66. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (66), 07-Июн-22, 14:41 
Желательно менять протокол каждый месяц.
Ведь каждый хипстер знает: всё новое - лучше!
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

137. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (137), 07-Июн-22, 23:26 
Вместе с браузерами - каждые 3 недели.
Ответить | Правка | Наверх | Cообщить модератору

181. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (181), 08-Июн-22, 14:33 
> браузерами

Почему во множественном числе?

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

324. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от zuzzz (?), 22-Июн-22, 15:28 
Что бы было разнообразие) У каждого браузера свои стандарты и фичи
Ответить | Правка | Наверх | Cообщить модератору

16. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 07-Июн-22, 09:50 
Подождите, его уже уже год как стандартизировали.

Что-то тут не то.

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

17. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +17 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 09:53 
Проблема в том, что пропихивающие QUIC не говорят о его недостатках. Плюс, корявые реализации (попробуйте загрузить большой файл на Youtube из этого вашего FF) и бай-дизайн большая нагрузка на сервера и клиенты из-за выноса задачи реального времени (управление потоком данных) в userspace. Последнее обстоятельство можно сравнить с выносом операции ресэмплинга звука из ядра в pulseaudio. Сколько ора на тему того, что звук икает из-за иссякания буфера при пиковых нагрузках? Второе же с низкой производительностью файловых систем реализованных в пользовательском пространстве (привет, FUSE/NTFS). В HTTP/3 проблемы возникают аналогичные, только пользователю они сразу не заметны. Сервера действительно начинают жрать больше, а jitter в соединениях только растёт.
Ответить | Правка | Наверх | Cообщить модератору

25. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (25), 07-Июн-22, 10:32 
Think different. Это не недостатки, а новые возможности.  
Ответить | Правка | Наверх | Cообщить модератору

26. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 10:33 
> Think different. Это не недостатки, а новые возможности.  

У thinkdifferent'ов хоть ECN включен в дефолте )))

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

70. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (70), 07-Июн-22, 14:50 
Как в анекдоте.
Меня коучи научили, что вместо "проблема" надо говорить "вызов".
Так вот, у меня теперь "вызов" с головой
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

52. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от n00by (ok), 07-Июн-22, 13:00 
На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб. Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на сервере, насколько больше?
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

53. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 13:08 
> На мой дилетантский взгляд сравнение с pulseaudio не вполне корректно. Даёт наглядное
> (точнее - воспринимаемое ухом) представление о проблеме, но скрывает её масштаб.
> Обработка звука это, грубо, всего 1% нагрузки. А QUIC, если на
> сервере, насколько больше?

Дело даже не в кол-ве процессорного времени, которое необходимо потратить на обработку, а в том, что реагировать на потерю пакета из очереди необходимо в очень чётко ограниченный по времени промежуток (и аналогия со звуком тут очень даже актуальна). При выполнении этой задачи в пределах пользовательского пространства кол-во "осечек", выражающихся в опорожнении или переполнении буфера, будет больше.

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

56. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от n00by (ok), 07-Июн-22, 13:29 
То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро? Но Гугл не обязательно этим со всеми поделится.
Ответить | Правка | Наверх | Cообщить модератору

61. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 14:17 
> То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро?
> Но Гугл не обязательно этим со всеми поделится.

Соль была в том, чтобы иметь реализацию в пользовательском пространстве. Мол, так алгоритм управления потоком Google сможет апдейтить просто обновляя Chrome (например). Этим алгоритмом был BBR, который не очень взлетел. Да, у него есть интересные моменты, но нет, например поддержки ECN, и проблемы с честностью (он склонен душить другие соединения). Алгоритм не взлетел, но сама идея вынести всё в userspace осталась. В теории можно перенести в ядро, но это потянет целый ворох ненужного в ядро. Только каких-нибудь подгружаемых сертификатов извне там не хватало. Вон, wireguard тащит всё в ядро, мол, управлять потоком там сподручнее и это ВОООН какой профит даёт, а google тащит аналогичные вещи в userspace и поёт о том, какой профит им это даёт.

В реальности всё проще, изначальная идея вообще для Google не очень актуальная. Им обновить веб-сервер одинаково просто с обновлением tcp_uber_protocol.ko, т.к. только обновление серверного ПО и имеет смысл из-за того, что отправитель управляет потоком, а не принимающая сторона. Мобильный же клиент особо исходящий трафик, критичный по решаемым задачам, не генерирует. Единственная интересная новая вещь - прозрачная миграция трафика между интерфейсами.

P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен. Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности беспроводных сетей, но я бы решал эту проблему пробросом информации из более низкого уровня. Например, расширить концепцию ECN сигналом явно уведомляющим об освобождении полосы. Даже в поле ECN есть неиспользующийся сигнал ECT1, который сейчас интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый сложный из congestion control'ов) в userspace... — ну такое себе.

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

225. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 10-Июн-22, 18:02 
> P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен.

На мобильном линке с движущемся транспорте он подобен разве что каре господня, когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации линка.

> Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности

Еще хуже когда это были соты с прорехами в покрытии и движущийся юзер, а этот кал удумал что это перегруз сети и ушел в дикие таймауты измеряемые минутами.

> сетей, но я бы решал эту проблему пробросом информации из более низкого уровня.

Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово.

> интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый
> сложный из congestion control'ов) в userspace... — ну такое себе.

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

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

226. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:08 
> BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка.

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

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

255. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:53 
> Простите, но его даже не ради этого создавали.

А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло. И настало время решений которые смогут нормально работать и в вон тех случаях. О чем и сабж.

> его логика работы состоит в том, что периодически пытаться слать больше,
> чем лезет, и смотреть, что из этого получается. Дропы — не
> увеличиваем скорость, пролезло — можно больше.

И все же...
1) BBR иногда начинает иметь довольно странное мнение о доступном бандвизе линка. Вероятно, его тайминги неудачно стыкуются с перетурбациями линка, или типа того, но он может упереться рогом и юзать целые 20-30% бандвиза. Многопоточные качалки получают +1 пойнт...

2) Даже он иногда может уйти в конские таймауты без должного основания. Видимо тоже случается хрень типа того что вот именно в момент перепосылки - соты не оказалось/пакет выпал, и неплохой в целом линк используется... да почти ни на сколько, протокол уходит в туповэйтинг. Если новую конекцию открыть - как из пушки прет, но уже существующая туповэйтит хоть там что. Сказано же, таймер на полчаса и все тут. И потом вы удивляетесь что кто-то хочет это переделать? :)

Есть thin linear timeouts еще, но опять же это какая-то эвристика, довольно наркоманская, и работает она тоже весьма малопредсказуемо и криво. А висящая минуту SSH сессия так то тоже бесит, если что.

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

274. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:26 
> А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло.

У тебя каша в голове. Протокол - IP, а BBR, на который ты так наяриваешь, это алгоритм управления перегрузками (congestion control), который был реализован для TCP и для UDP/QUIC. Всё.

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

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

277. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 00:38 
> У тебя каша в голове. Протокол - IP,

Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.

> а BBR, на который  так наяриваешь, это алгоритм управления перегрузками (congestion control),
> который был реализован для TCP и для UDP/QUIC. Всё.

Еще раз спасибо кэп. Только...
1) В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.
2) Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.
2) Вменяемые алгоритмы контроля будут заведомо на обоих сторонах линка. В случае TCP - окажется с той стороны какой-нибудь гадский кубик и проч - и таки нагадит. Это ж в 2 стороны работает и мы может вообще ничего слать не хотели. А то что ремота туповэйтила по таймеру минуту - мы и будем дергаться через минуту, когда они расчехлятся вообще пакет прислать.

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

Вот то что тебя никто не будет спрашивать с твоим уровнем квалификации - я таки уверен. И кстати вот именно тебя я забуду спросить что мне жрать. То что я жру от тебя вообще никак не зависит.

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

286. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:32 
> В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера.

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

> Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально.

Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему на него не перешли даже в самом HTTP/3?

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

302. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 21:33 
> Браузер по определению скачивает данные в основном.

В целом - да, но...
1) Чтобы сервер вообше что-то послал - сначала это надо запросить! Путем ОТПРАВКИ запроса. Если мы при этом туповэйтили минуту, сервер вообще не знал что мы от него хотим. Надеюсь, ты в состоянии это понять, великий эксперт?
2) Юзеры так то нынче совсем не прочь аплоадить фоточки и видео нефигового размера, и это кажется не даунлоад.
3) Внезапно сервера будут юзать вообще сразу и по дефолту какую-то сильно менее ретарднутую реализацию чем гребаный кубик и т.п. как в TCP. Так что и тут скорее всего мобильно-беспроводным будет лучше. И кстати либы всего этого будут апдейтить и твикать... явно резвее чем некоторые, особенно типа майкрософта.

> Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять?

Спасибо Капитан Очевидность. Нюанс в том что Кэп упустил пару небольших моментов. Без которых все остальное уже не важно.

> Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется
> чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему
> на него не перешли даже в самом HTTP/3?

Он не "хорош" но "лучше чем другие в этом позорном гадюшнике" при натурных испытаниях в поле. И таки в линуксе он тоже вроде какой-то допатченый и затвиканый. А что там и где "бросили" я не знаю. В линукс кернеле не бросили - иначе он был бы оттуда выпилен как orphaned, вероятно.

Все остальное на беспроводке рабоатет еще хуже. Что-то вменяемое может еще разве что CDG, но он временами делает какие-то очень странные вещи. BBR их так то тоже пытался делать но это починили 3-4 релиза назад.

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

312. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 02:51 
> BBR их так то тоже пытался делать но это починили 3-4 релиза назад

Там из заметного только механизм pacing rate изменили... Оно никак не поменяло логику алгоритма.

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

320. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:29 
> Путем ОТПРАВКИ запроса.

И сколько там запрос GET занимает? В запросном канале ВСЕ алгоритмы ведут себя одинаково, они даже не уходят ни разу в потолок. Твой BBR не сможет задетектить рост RTT, а классический Cubic/Reno не получит первого дропа. Оговариваюсь про классический, т.к. сейчас везде (в Linux/Android хотя бы) уже гибридный старт, который сделал из Cubic аналог твоего BBR на начальном этапе или этапе slow start... там меряются RTT "паровозиков" из пакетов. Если же у тебя лежит канал, то обработка этого события ведётся по а) непревышению таймаута соединения (который НЕ ЗАВИСИТ от алгоритма congestion control'а; б) алгоритм сбросит тебя в режим slow start и перезапросит выборочно потерянные пакеты, если включен SACK (включен по умолчанию у всех).

Никакого другого варианта просто нет. Ты банально демонстрируешь непонимание того, как работает сетевой стек.

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

321. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:41 
> А что там и где "бросили" я не знаю.

Google его не использует. Он использует некую модифицированную версию (погугли "The Great Internet TCP Congestion Control Census"), отличающуюся заметно от той, что скормили в ядро Linux. Стриминговые сервисы используют Cubic или Reno+RACK, Youtube какую-то модифицированную версию BBR (но не BBRv2), даже на остальных сервисах (не серверах доставки видео) Google использует Cubic.

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

287. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:34 
> Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP.

Нет, милок, именно IP в данном контексте.

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

227. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:09 
> Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово.

Протокол проброса информации в студию! А то пацаны-то не знают.

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

256. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 01:58 
> Протокол проброса информации в студию! А то пацаны-то не знают.

Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра. И это, у разных протоколов достаточно разные понятия бывают, их все под 1 гребенку насчет проблем физического уровня причесать так то не очень просто. И какого-то устоявшегося механизма "для всех" нет. Более того - какой-нибудь сотовый модем это в стандартном виде вообще не отдает обычно, ну вот нет устоявшегося интерфейса для этого. Если я любопытный то конечно vendor cmd и прочей отладочной статистикой увижу и уровень сигнала в -dBm, и snr, и что там еще, но вот кернель про это все не очень в курсе.

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

273. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:23 
> Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра.

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

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

278. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 01:02 
> Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо
> выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости
> физического линка. Делать это никто не хочет.

А смысл этого какой?
1) Беспроводные интерфейсы сейчас довольно адаптивные, за сменой битрейта/модуляции не ржавеет, они могут чуть не попакетно менять, выжимая из линка фактически доступный в этих условиях максимум. Какая ценность значения в хидере? Вафля вообще насколько я помню может указывать конкретный битрейт например пакетам beacons "и пофиг на остальное". То-есть минимум 10 раз в секунду девайс может бросить все, сменить битрейт/модуляцию на потребную для beacon, оформить beacon и заняться дальше передачей данных. Ах да, заподозрить об этом можно просто помониторив статистику вафли или сотового модема. Но видимо это недостойное занятие для гуру.

2) Интернет вообще-то сеть, в которой я вообще-то с дофига систем коммуницирую. Допустим у меня пара десятков программ что-то делают по TCP, UDP, а может и еще чему, ICMP например. И чего в хидере вот конкретно этого данного пакета при таком раскладе писать? Бандвиз же не будет целиком вот этой вот ремоте отдан при таком раскладе. Более того - это еще и от того что будут дальше ремотные системы делать зависит. Может, половина через 5 секунд решат что накоммуницировались и отвалят. А может наоборот мег данных пульнут. Это вообще от них зависит.

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

229. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:11 
> На мобильном линке с движущемся транспорте он подобен разве что каре господня,
> когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации
> линка.

Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации с нижележащего уровня логику определения оптимальной скорости трудно представить кроме той, что уже были реализованы (не только в CUBIC).

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

257. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:04 
> Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации
> с нижележащего уровня логику определения оптимальной скорости трудно представить кроме
> той, что уже были реализованы (не только в CUBIC).

Я вообще не представляю себе логику определения скорости линка когда я чешу в поезде и SNR и вообще наличие сот плавает в широком пределе и быстро. ИМХО там только быстрый агрессивный адаптив сможет что-то вменяемое делать.

В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.

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

271. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:15 
> В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.

Ловить перегруз по росту RTT пытаются уже больше 20 лет и все алгоритмы только на нём (RTT) сливают по своему определению всем остальным по всем параметрам кроме RTT. Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее, за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма гибридного старта (единственный, кроме Cubic, где он есть). Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется в широких пределах (в отличие от BBR), особенно в реализации Linux (родная BSD'шная убога по настройкам и нет гибридного старта). Сломать настройками в CDG мало получится, т.к. в предельном случае ты получишь продвинутый вариант классического Reno со всеми его недостатками. Но по дефолту он больше на low priority алгоритм тянет. Собственно, можешь погуглить, есть академический бенчмарк оценки алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.

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

279. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 01:31 
> Ловить перегруз по росту RTT пытаются уже больше 20 лет и все
> алгоритмы только на нём (RTT) сливают по своему определению всем остальным
> по всем параметрам кроме RTT.

И тем не менее, они демонстрируют хоть какое-то отдаленное подобие минимального адеквата на беспроводных линках. Впрочем т.к. это с одной стороны - а радости то? Будет у ремоты с той стороны кубик, и будет она туповэйтить каждый раз. А нам может вообще слать ничего не хотелось в это время (совершенно типовой паттерн для групчата: нам шлют сильно чаще чем мы).

> Caia (CDG) в своём дефолтном состоянии примерно равен BBR. Но, функциональнее,
> за счёт поддержки ECN (да, Google его не осилил в BBR) и за счёт наличия алгоритма
> гибридного старта (единственный, кроме Cubic, где он есть).

С чисто практической точки зрения, CDG как он есть в ядре линуха, на беспроводных линках периодически вытворяет что-то странное. Заметно чаще чем BBR. В смысле, он порой приобретает странные идеи насчет скоростей с которыми может оперировать и убивает скорость буквально в разы от того что фактически доступно. После чего решительно не желает менять мнение на этот счет, хоть тресни. BBR так тоже в принципе умеет, но впадает в маразм сильно реже и быстрее прочухивается, как правило постепенно приходя в адекват сам за обозримое время.

> Плюс CDG в том, что уровень его агрессивности (он двухрежимный) легко регулируется
> в широких пределах  (в отличие от BBR),

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

> особенно в реализации Linux (родная BSD'шная убога по настройкам и нет
> гибридного старта). Сломать настройками в CDG мало получится, т.к. в
> предельном случае ты получишь продвинутый вариант классического Reno со всеми
> его недостатками. Но по дефолту он больше на low priority алгоритм тянет.

Как по мне - довольно странная идея для дефолтов. Но меня в нем больше всего напрягало очень странное мнение о доступных скоростях временами. Если конекцию спихнуть и новую открыть, будет шустренько. А если не спихнуть, так и будет на 1/3 скорости линка пехать. Мне что, каждый раз ему такую мануальную терапию делать? Да ну нафиг.

> Собственно, можешь погуглить, есть академический бенчмарк оценки
> алгоритмов для задачи низкоприоритетной доставки с низкими задержками. CDG там лидер.

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

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

285. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:27 
> Академики живут где-то в своих кельях, и, кажется, прогуляться с мобилкой или ноутом со сниффером банально не пробовали. В гугле же есть и хипстюки с мобилками, которые могут без обиняков сообщить обитателям келий что получился все-таки булшит.

Потрудитесь полистать https://researchbank.swinburne.edu.au/file/1560d7f6-6fa3-4ad...

... теперь понимаешь, что твои тезисы на уровне шариковских?

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

272. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:18 
Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма. По бенчмаркам не офигенный прорыв, но многие недостатки двухрежимного гибридного алгоритма действительно улучшил ощутимо. Но, опять же, в реальной жизни вкатывание и отладка их занимает годы. Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные. Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины будет чуть больше нуля.
Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

304. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:26 
> Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма.

Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.

Так что воспринимать академовские тезисы как истину в последней инстанции может только наивный чукотский юноша. Спору нет, бывают и дельные соображения. Но читать академпубликации стоит с изрядным скепсисом. На практике все может оказаться здорово иначе.

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

Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния. BBR от таких приколов более-менее пролечили, он все-равно иногда делает хрень но по крайней мере сам очухивается за обозримое время.

Особенно обломно в чем-то типа VPN по TCP - CDG его может удушить до дурной скорости, а потом так и будет тупить пока не рестартанешь, но это ж линк роняет, неудобно. Ах конечно академы про такие кейсы небось не думали. Дада, впн надо по удп и проч, вон тому корп фаеру и прокси это еще расскажи.

> Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные.

Напомню, коммуникации двухсторонние. Чтобы сервер начал что-то отдавать, клиент должен запрос прислать. Иначе кто его там знает что он вообще хотел. В этом месте не совсем тупые персонажи начнут догадываться почему столько внимания числу RTT до начала передачи данных а еще более сообразительные осознают и проблему head of line blocking.

> Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины
> будет чуть больше нуля.

Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.

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

317. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:12 
> Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге.

Чем публикация тестов Google лучше? Оно даже по критериям академичности не прокатывает.

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

318. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:15 
> Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния.

Есть такая вещь в параметрах модуля backoff_factor (у реализации BSD она иначе зовётся), попробуй её понастраивать. Можешь начать со значения 1.

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

319. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:19 
> Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.

Проблемы масдая не в кубике, а в том, что там отключены tcp timestamp'ы (уточни, так ли это в последних версиях) и джиттер может привести его в состояние повышенного дропа пакетов. Но timestamp'ы и там включаются лёгким движением мыши.

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

231. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:13 
> Еще хуже когда это были соты с прорехами в покрытии и движущийся
> юзер, а этот кал удумал что это перегруз сети и ушел
> в дикие таймауты измеряемые минутами.

А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши её техническими терминами.

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

258. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:09 
> А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши
> её техническими терминами.

В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.

И в конце концов стремиться надо к чему-то такому. Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких. Но даже он иногда делает фиг знает что, у кернела свои заскоки насчет TCP, а юзерам windows этот BBR вообще не раздашь нифига в их маздайный кернел. Я вообще не знаю умеет ли маздайный кернел в разные алгоритмы congestion control.

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

270. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 11-Июн-22, 19:02 
> В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет.

Собственно ты словами и описываешь классический алгоритм. Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую, без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания данного вопроса. Почитай потом, например, про проблему медленного старта (это название этапа, если что) и как её пытается решить гибридный старт (а это алгоритм). А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.

> Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких.

Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности не столкнётся с аналогичным потоком BBR. Странно, но реальные тесты BBR показывают, что он - говно. Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом. Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг при максимальной для него нагрузке). В локальной сети при пинге 1 мс он проседает процентов на 30%! Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у всех десктопных Линуксов.

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

280. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 02:09 
> Собственно ты словами и описываешь классический алгоритм.

"В теории, Петька, мы с тобой миллионеры". Классийческий алгоритм в его чистом виде на беспровлдке на вот это вот по реальному поведению не похож вообще. Огибающая фактически доступного бандвиза и то что он там себе мнил - две громадные разницы. Наверное, секрет в том что уйти в сэмплирование состояния раз в минуту - идея паршивая. Особенно - для беспроводки.

> Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую,

Лучший индикатор который я знаю это RTT. Я вижу вполне прямую корреляцию роста RTT c "линк перегружен" на почти всех типах линков. При том это довольно универсальная метрика. Ну вот например вафля. Может декларить 150Мбит рейт, но сделать 3 перепосылки. Или 75, но влупить за 1 раз. Если любопытно - зазырь что на этот счет Minstrel делает, но он там это делает где-то внутрях себя, а у многих других девайсов эти решения вообще фирмвар принимает по одному ему ведомым критериям. И этот фирмвар может и не вывешивать столько сведений наружу. И это, глядя на статистику minstrel'а я даже не знаю что там номинальной символьной скоростью назвать.

И вот кстати его эвристика работает довольно недурно, но вот у него таки есть доступ к весьма детальному статусу его железки. Специфично для его железки. Экспортировать ЭТО в TCP? А счастьем точно не зашибет? :)

> без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания
> данного вопроса.

Мое понимание вон того вопроса можно узреть выше. В отличие от тебя я видел что кажет тот же минстрел в статистике. И как он скорости выбирает. И поэтому напрягаюсь даже просто назвать конкретное число как символьную скорость, чтобы в "хидер вписать" (неизвестно зачем, это же на всю толпу делится малопредсказуемым образом).

> Почитай потом, например, про проблему медленного старта (это название этапа, если
> что) и как её пытается решить гибридный старт (а это алгоритм).
> А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать.

А ты посмотри как вообще современные беспроводные интерфейсы работают и включи мозг на тему того что это сеть - так что я не очень понимаю какое число можно вписать в хидер IP как бандвиз и что оно должно означать.

Не, если ты по проводному эзернету, по одной TCP конекции гонишь данные, ок, там понятно. А если это 20 endpoint'ов на прыгающей как блоха беспроводке, да еще зависит от действий ремотных систем, то чего туда писать и какой смысл это все несет?

> Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR
> будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности
> не столкнётся с аналогичным потоком BBR.

Тем не менее, нахальность обеспечивает ему лучший трекинг "огибающей доступного бандвиза линка". Это довольно быстро фаломорфирующая в беспроводке величина если ты не понял. Варьируется от нуля (сота пропала/линк отпал) до весьма солидных значений в сотни мегабитов и довольно резво.

> Странно, но реальные тесты BBR показывают, что он - говно.

Смотря кто и что тестировал. Кто-то вообще пробовал оттестировать следование алгоритмов огибающей реально доступного бандвиза линка и прикинуть процент утилизации того что было фактически доступно? Это довольно сложно - и я плохо представляю себе как это сделать воспроизводимо.

Понимаешь, когда качается с 1/3 доступной скорости линка или 10-секундный вылет апгрейдится до минутного - мне реально похрен что твои синтетические бенчи рисуют. И победитель для меня тот кто избавит от этого трешака.

> Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом.

Ага, блин, а теперь сядь в поезд и забенчи свой долбаный кубик оттуда на ходу. Он при минимальных прорехах покрытия вообще в тыкву превратится и тыквой и останется, навечно. И вместо "интернета" будет "мучение". Нет, даже не диалапного уровня. Правда как это сделать воспроизводимо я не знаю, с моей стороны это некое "усреднение фактического опыта". После вот таких бенчей ты может быть и осознаешь что мне не нравится в кубиках.

> Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг
> при максимальной для него нагрузке).

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

> В локальной сети при пинге 1 мс он проседает процентов на 30%!

А в беспроводке твой кубик может и на почти бесконечность процентов слить. А сколько процентов записать протоколу почти не качающему данные вообще? :)

> Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у
> всех десктопных Линуксов.

Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR. И знаешь, когда чатик в поезде датыкается на минуту, меня это больше напрягает чем 10 или даже 30% бандвиза в локалке.

Ну и применительно к браузеру - я не думаю что основное применение браузеров это кач файлов с локалки, так что вон те 30% никто не увидит. Зато на беспроводке юзеры будут ощущать себя куда лучше чем сейчас.

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

284. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:18 
Ты демонстрируешь полное непонимание вопроса.

> Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR.

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

> И знаешь, когда чатик в поезде датыкается на минуту...

Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не такой большой, покажи мне этот момент в коде.

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

305. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:34 
> Ты демонстрируешь полное непонимание вопроса.

Я демонстрирую то что увидел по факту в снифере и статистике сокетов. И если в энных ситуациях факты выглядят вот так - значит вот так. И какая разница что там в пейперах написано при этом?

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

А это не тезис и не теория. Это констатация того что я в снифере и статистике сокетов вижу. Маленький такой нюансик.

> Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать
> UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не
> такой большой, покажи мне этот момент в коде.

Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.

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

316. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:10 
> Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.

Простите, давайте ближе к "телу". Про какой такой таймер вы говорите и в каком сниффере. В идеале я бы ждал скрин, но можно просто терминами. Я пойму.

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

288. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:37 
> Если любопытно - зазырь что на этот счет Minstrel делает...

Я тут внезапно понял, что ты не в курсе, как коррекция ошибок в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.

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

310. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 13-Июн-22, 00:17 
> Я тут внезапно понял, что ты не в курсе, как коррекция ошибок
> в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.

Ух, конечно-конечно, о великий гуру. Есть правда маленький нюансик. Я таки накодил пару небольших беспроводных линков. Даже с FEC. Это конечно не предел мечтаний, но придает пикантности твоим предъявам.

А если бы ты не был столь глупым то заметил бы еще и что я так то указал две радикально разные ситуации, которые однако обе могут вбить TCP в асфальт. Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.

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

313. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 02:53 
> Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.

А на каком уровне OSI происходит коррекция ошибок?

> FEC

LDPE нормальные люди используют давно.

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

323. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 16-Июн-22, 14:04 
https://legacy.netdevconf.info/2.1/papers/compare-tcp-highwa... — не читай вывод, смотри на графики. Исследование твоего BBR в дикой природе. Как разница?
Ответить | Правка | Наверх | Cообщить модератору

289. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 12-Июн-22, 04:47 
Ладно, юзай там свой BBR. Я выше уже писал, что есть категория совершенно полоумных, которые включают его на основании малограмотных советов из бложиков в Medium, а потом рассказывают, что у них кол-во таймаутов уменьшилось, скорости выросли и волосы стали гладкими и шелковистыми. Ещё раз напомню, что это из разряда психологии. У меня был один такой коллега, у которого после обновления дистрибутива сервера быстрее начинали, по его признанию, работать. Эффект держался иногда до месяца. Когда в коллективе появился аудиофил, то они нашли друг дружку. Сила самоубеждения творила с ними страшные вещи. Главное, бенчмарки не проводить грамотные 😆
Ответить | Правка | К родителю #280 | Наверх | Cообщить модератору

306. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:45 
Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать. Ну и как-то в среднем по больнице больше всего понравился BBR. CDG лучше дефолтов, но увы, умеет одуревать и необоснованно душить скорость - и что хуже - не очень то вытряхиваясь из этого состояния за обозримое время.

Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка? Окей! Пролюбить 70% бандвиза? Надолго? После какой-то редкой но меткой последовательности событий? Не, вот это - не окей, когда оно потом само не очень то и рекаверится. Может даже в теории это быть и не должно, а на практике это таки конкретный факап, нагибающий всю идею.

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

314. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:05 
> Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать.

Люди давно поэкспериментировали в реальных и виртуальных условиях и составили карту, где BBR может выигрывать. Это линки с большим равномерно (упор на это слово) распределённым дропом с пингом выше 100 мс и скоростью физ. интерфейса 200+. В остальных случаях оно или равно Cubic или гораздо хуже его (линки со скоростью меньше 10 мс).

> Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка?

Создать "шторм" затупов на 30+ секунд ни один из алгоритмов не может в принципе. Он может перейти в режим slow start (и это будет видно в статистике), но это как начать соединение заново (в плане вычерчивания графика скорости).

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

239. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 10-Июн-22, 18:43 
> ... подобен разве что каре господня (-ня? -ней?), когда ваше терпение поджаривают на медленном огне, глумясь...

Вы чёрта в Господом даже умудрились спутать )))

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

296. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:06 
Раб божий, что ты забыл в интернете?
Ответить | Правка | Наверх | Cообщить модератору

307. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:48 
> Раб божий, что ты забыл в интернете?

Он просто не понял мой тонкий отсыл что TCP поверх беспроводки - это просто срань господня. С BBR немного меньшая срань, но тоже далеко не предел мечтаний.

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

72. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 07-Июн-22, 15:05 
Всё это совершенные мелочи по сравнению с проблемами tcp.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

82. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:12 
>  Всё это совершенные мелочи по сравнению с проблемами tcp.

Ограничения TCP известны и изучены. CUBIC/Reno и все эти SACK, ECN, гибридный старт годами отлажены и отполированы. А придуманный, пускай даже и в Google, BBR оказался переусложнённым и ничем не выдающимся с функциональной стороны. Зато с кучей новых проблем...

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

164. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от lockywolf (ok), 08-Июн-22, 09:43 
Отлажены, отполированы, но не работают.

И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, они всегда будут что-нибудь портить.

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

166. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 09:48 
> И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока,
> они всегда будут что-нибудь портить.

Простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? Просто интересуюсь, как вы представляете их работу.

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

185. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 08-Июн-22, 19:49 
>простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам?
> Просто интересуюсь, как вы представляете их работу.

Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по дороге с большой вероятностью дропает коннект.

Не говоря уже о том, что когда коннект выглядит нетипично на DPI, его приоритизируют ниже.

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

187. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 20:26 
> Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по
> дороге с большой вероятностью дропает коннект.

Мне вот тут интересно стало, а что такое в твоём понимании TCP window scaling?

> Не говоря уже о том, что когда коннект выглядит нетипично на DPI,
> его приоритизируют ниже.

Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще режут на первом же хопе.

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

190. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 04:08 
> Мне вот тут интересно стало, а что такое в твоём понимании TCP
> window scaling?

Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.


> Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении
> значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще
> режут на первом же хопе.

Детали работы DPI не публикуются. Эмпирически приоритизация очень хорошо заметна. Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

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

191. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:25 
> Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится.

Очень глубокое понимание работы протокола. Кстати, именно поэтому кол-во ACK'ов не совпадает с кол-вом пакетов, но на каждый пакет есть ACK! Представть, если бы в потоке в несколько десятков гигабит надо было тут же на каждый пакет отсылать ACK. Интересная бы производительность у протокола тогда была. Вот такая вот, на первый взгляд, противоречивая фигня. Вообще попробуй разобрать любую сессию в Wireshark ради примера. Сейчас многое изменилось со времён оригинального TCP и от учебника и википедии отличается )))

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

193. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:36 
> которую файрволы по дороге переписывают так, как им заблагорассудится

Нет в абсолютно подавляющем большинстве.

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

195. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 08:49 
>> которую файрволы по дороге переписывают так, как им заблагорассудится
> Нет в абсолютно подавляющем большинстве.

Sweet summer child. Всё, что можно переписать, переписывается. Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

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

196. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:53 
> Sweet summer child. Всё, что можно переписать, переписывается.

А кроме как языком доказать сможешь? Ну, начнём с того же TCP window scaling (раз уж его упомянули). Я просто к чему это говорю, просто эта вещь ломает работу канала. Я даже и бородатый баг с разбором проблемы среди разработчиков ядра могу привести алаверды на доказательство твоего тезиса.

> Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.

Что там кроме payload защифровано, сказочник? Там та же логика управления каналом, что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят имена идентичные — CUBIC/Reno/BBR :)

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

202. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 09-Июн-22, 12:15 
> Что там кроме payload защифровано, сказочник? Там та же логика управления каналом,
> что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят
> имена идентичные — CUBIC/Reno/BBR :)

21.1.1.4.  Parameter Negotiation

   The entire handshake is cryptographically protected, with the Initial
   packets being encrypted with per-version keys and the Handshake and
   later packets being encrypted with keys derived from the TLS key
   exchange.  Further, parameter negotiation is folded into the TLS
   transcript and thus provides the same integrity guarantees as
   ordinary TLS negotiation.  An attacker can observe the client's
   transport parameters (as long as it knows the version-specific salt)
   but cannot observe the server's transport parameters and cannot
   influence parameter negotiation.

   Connection IDs are unencrypted but integrity protected in all
   packets.

   This version of QUIC does not incorporate a version negotiation
   mechanism; implementations of incompatible versions will simply fail
   to establish a connection.


https://datatracker.ietf.org/doc/rfc9000/

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

211. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 20:03 
На этом разговор и закончим, мне всё ясно.
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

192. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 06:30 
> Детали работы DPI не публикуются.

На этом можно было бы и закончить гадать...

> Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.

А вы уверены, что софт, торчащий на тех портах, не генерирует задержку банально, которую вы упорно измеряете? И дело совершенно не в DPI, а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH 😄

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

194. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 08:46 
>> Детали работы DPI не публикуются.
> На этом можно было бы и закончить гадать...

Можете закончить, а мне нужно данные передавать.


>> А вы уверены, что софт, торчащий на тех портах, не генерирует задержку
> банально, которую вы упорно измеряете? И дело совершенно не в DPI,
> а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH
> 😄

Я уверен, потому что я измерял задержку до RST заблокированных портов


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

197. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 09:57 
> Я уверен, потому что я измерял задержку до RST заблокированных портов

Жду однострочник, с нетерпением.

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

198. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 09-Июн-22, 11:44 
>> Я уверен, потому что я измерял задержку до RST заблокированных портов
> Жду однострочник, с нетерпением.

Однострочники называются nping и hping3.

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

201. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 09-Июн-22, 12:05 
я так и знал 😆
Ответить | Правка | Наверх | Cообщить модератору

203. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от lockywolf (ok), 09-Июн-22, 12:16 
> я так и знал 😆

И что ты знал, болтун? Какая разница, чем слать пакеты?

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

259. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:12 
> Однострочники называются nping и hping3.

Хорошие, кстати, однострочники если хочется потыкать пакеты палочкой в нестандартном виде.

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

146. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Ivan_83 (ok), 08-Июн-22, 04:32 
Какие проблемы то?
В начале браузеростроители ограничивают количество TCP соединений типа чтобы сервера не перегружать, а потом гуглы от скуки изобретают квик, где типа по одному соединению всё передаётся, просто хитро мультиплексируется.
А суть то в том, что они эти самые 100500 TCP соединений упихнули внутрь своего udp, и теперь сравнивают и делают выводы.

На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов" внутри, а за счёт того что срезали все лишнее что им было не нужно и поменяв приоритеты.

Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего.
Тут пришёл гугл и сказал что у нас тут шифрование, потому пакеты должны ходить теперь только так, и вот благодаря этому вравниваю размера пакетов у нас профит.

И так во всём.

Но по сути их работа не добавила ничего нового и не создала новых ценностей.
Вот DHT, uTP - добавили и создали.

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

165. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от lockywolf (ok), 08-Июн-22, 09:45 
> Какие проблемы то?

Проблема в том, что скорость потока зависит от процента потерь пакетов (обратно) экспоненциально (тогда как должна линейно). А в мире есть миллиарды человек, которые сидят на соединениях, у которых 30-40% потерь -- норма жизни.

>Вот DHT, uTP - добавили и создали.

Они легко детектируются и банятся.

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

297. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:09 
> Они легко детектируются и банятся

Портить вообще довольно просто. На крайний случай можно кабель вырвать вместе с портом.

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

224. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 10-Июн-22, 17:32 
> А суть то в том, что они эти самые 100500 TCP соединений
> упихнули внутрь своего udp, и теперь сравнивают и делают выводы.

Ну так это...
- Пайплайнинг в тупом его виде HTTP/1.x жестко клевал по head of line blocking.
- Сетап новых соединений для уменьшения того эффекта может занять ощутимое время.

В целом вебпага грузилась как уг и приходилось делать костыли типа впихивания всех ассетов в 1 файл ради скорости.

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

И еще убрав из процесса горе прожектеров с их congestion control непригодным для беспроводки.

> Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего.

Но roundtrip'ов добавили - так что вон то еще усугубилось. Оно наверное круто в датацентре с пингом до сервака менее 1мс, а если в поле с мобилкой с пингом 150 мс?!

> Но по сути их работа не добавила ничего нового и не создала новых ценностей.

Кроме того что это сможет наконец нормально работать по беспроводке.

> Вот DHT, uTP - добавили и создали.

Они так то о другом. Хотя uTP в чем-то похож, но мультиплексированием не занимается и заточен на именно фоновый низкоприоритетный трансфер, даже если надо немного пожертвовать скоростью.

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

78. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (75), 07-Июн-22, 15:40 
У тех серьёзных ребят, у которых этот протокол внедрён и которым от него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным комплексом.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

87. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:33 
> У тех серьёзных ребят, у которых этот протокол внедрён и которым от
> него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным
> комплексом.

Шта?


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

162. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от onanim (?), 08-Июн-22, 07:38 
какой-нибудь Intel Quick Assist
Ответить | Правка | Наверх | Cообщить модератору

163. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 08:56 
> какой-нибудь Intel Quick Assist

Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?

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

269. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от onanim (?), 11-Июн-22, 18:41 
>> какой-нибудь Intel Quick Assist
> Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?

* какой-нибудь аналог Intel Quick Assist

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

108. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (108), 07-Июн-22, 18:34 
> выносом операции ресэмплинга звука из ядра в pulseaudio.

Вообще-то ядерная часть ALSA никогда не умела делать ресэмплинг, этим всегда занималась юзерспейсная библиотека. Ядерная часть могла только переключить DAC в режим воспроизведения другого формата, но это возможно и через pulseaudio (но выключено по умолчанию).

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

113. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 19:03 
Спасибо за поправку. Tы прав, это делала libalsa.
Ответить | Правка | Наверх | Cообщить модератору

19. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от pashev.ru (?), 07-Июн-22, 09:58 
Самое время беспокоиться о миллисекундах соединения, когда сотни файлов качаются несколько минут.
Ответить | Правка | Наверх | Cообщить модератору

22. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +8 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 10:11 
> Самое время беспокоиться о миллисекундах соединения, когда сотни файлов качаются несколько
> минут.

Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке. В устанавливаемых соединениях практически никогда не происходит события достижения лимита физической пропускной способности сети и миллисекундные задержки и накладные расходы на установление параметров соединения, DNS запросы выливаются в неторопливое открытие "глагне" даже на гигабитном канале.

P.S. но лично я бы сосредоточился на допиливании HTTP/2 и TCP. Да-да, он, TCP, до сих пор в режиме постоянной доработки и научных статей поток не иссякает на эту тему.

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

27. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –5 +/
Сообщение от Аноним (25), 07-Июн-22, 10:34 
Расскажи зачем тебе мгновенное открытие глагне? Как это изменит твою жизнь и как вообще на этом можно заработать?
Ответить | Правка | Наверх | Cообщить модератору

29. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +8 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 10:38 
> Расскажи зачем тебе мгновенное открытие глагне? Как это изменит твою жизнь и
> как вообще на этом можно заработать?

Мгновенно ничего не бывает. Загрузка глагне в несколько секунд — стыд и срам, но это проблема конeчно же на 95% веб-разработчика, а не инженера, разрабатывавшего HTTP/x

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

33. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –4 +/
Сообщение от Аноним (25), 07-Июн-22, 11:35 
Да нет тут проблемы быстрая загрузка первой страницы никому не нужна.  
Ответить | Правка | Наверх | Cообщить модератору

36. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +12 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 11:49 
> Да нет тут проблемы быстрая загрузка первой страницы никому не нужна.

Конечно нет, все оптимизаторы должны идти нафиг. Рапид-девелопмент и быдлокод уже победили.

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

39. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от Аноним (40), 07-Июн-22, 12:25 
Ты так говоришь как будто это что-то плохое. Пипл то хавает, всё остальное это преждевременная оптимизация.  
Ответить | Правка | Наверх | Cообщить модератору

46. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (200), 07-Июн-22, 12:47 
Вы бы знали, что пипл хавает в Африке, за отсутствием нормальной еды...
А пользователи бразуеров разве чем-то хуже в плане адаптируемости к низкокачественным кормам?
Ответить | Правка | Наверх | Cообщить модератору

67. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (67), 07-Июн-22, 14:47 
Им норм гуманитарка заходит в виде SPA. И им вот прям вот совсем пофиг что первоначальная загрузка SPA занимает несколько секунд в виде js css блоба размером на несколько мегов. Зато потом все быстро и без переходов загружается. В отличии от того же серверного рендера, который и тормозной и ресурсы сервера кушает почем зря.  
Ответить | Правка | Наверх | Cообщить модератору

130. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (128), 07-Июн-22, 22:18 
> Расскажи зачем тебе мгновенное открытие глагне?

А вот и ненужнисты подъехали. Тебе не нужно — не пользуйся. Всё просто!

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

31. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (12), 07-Июн-22, 11:01 
Просто дали троллям задание оправдать блокировку протокола , а знаний на это у них не хватает . Потому и получается лекция из "Карнавальной ночи" , спор с ними - пустая трата времени .
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

34. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (25), 07-Июн-22, 11:36 
Гугель все правильно делает медленно спускается и покрывает всё стадо.  
Ответить | Правка | Наверх | Cообщить модератору

43. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Гость (??), 07-Июн-22, 12:41 
Это только из-за того что все разбросано по разным серверам-ip-доменам даже когда в этом нет нужды, технически достаточно одного DNS запроса и одного HTTP/2 соединения.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

92. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от ip1982 (ok), 07-Июн-22, 17:08 
> Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке.

Да, единственное решение - HTTP/3! :D

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

139. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от suffix (ok), 07-Июн-22, 23:43 
О каком развитии tcp Вы говорите если даже tcp fast_open выпилили из ВСЕХ браузеров ?

Ну поддерживает у меня сайт tcp fast_open и я отслеживаю подключения с использованием этой фичи - так вот 2 (ДВА) раза за последний год это случилось.

Разумеется могу curl-ом с соответствующими ключами дёргать свой сайт и затем тащиться в Wireshark как быстро у меня повторные соединения происходят (0-RTT early_data  тоже включено разумеется) :)))

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

152. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 06:30 
Какое отношение браузеры имеют к TCP?
Ответить | Правка | Наверх | Cообщить модератору

155. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от suffix (ok), 08-Июн-22, 06:36 
А, так Вы о сферических конях в вакууме писали - ну тогда понятно.

Практическое применение если не интересует, то тогда да - tcp развивается :)

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

157. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 06:47 
> А, так Вы о сферических конях в вакууме писали - ну тогда
> понятно.

Браузер не реализует никакую часть из TCP, тот же multipath и congestion control активно пилят и оптимизируют. Другой вопрос совершенно в прикладном софте. Про тот же ECN я писал выше, реализовано и отлажено уже чёрт знает сколько лет, действительно полезная вещь, но убедить включить её в роутерах нереально. Microsoft и их страдания по TCP timestamp'ам вторым примером...

> Практическое применение если не интересует, то тогда да - tcp развивается :)

Ну, например, вкатили всем TCP hybrid start, сколько человек об этом знает и заметило? Однако же очень полезная вещь, которая исправляет один из родовых недостатков TCP.

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

308. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:51 
> Браузер не реализует никакую часть из TCP, тот же multipath и congestion
> control активно пилят и оптимизируют.

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

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

315. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 13-Июн-22, 03:07 
> И как, много его уже в допустим винде напилили?

Вообще не в курсе, у меня вокруг разные сорта *nix'ов.

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

23. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (23), 07-Июн-22, 10:14 
Сразу на HTTP 102 буду обновляться.
Ответить | Правка | Наверх | Cообщить модератору

64. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (42), 07-Июн-22, 14:36 
Правильна, нэ тарапися.
Ответить | Правка | Наверх | Cообщить модератору

28. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (24), 07-Июн-22, 10:34 
HTTP уже устарел. magnet:?xt=urn: в массы!
Ответить | Правка | Наверх | Cообщить модератору

41. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от Тот Самый (?), 07-Июн-22, 12:32 
>HTTP уже устарел

Не устарел, а вконец изгадился (точнее, заcрали)

>magnet:?xt=urn: в массы!

Пора мигрировать в Gemini. Для начала уговорить OpenNet открыть в Gemini зеркало

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

63. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (14), 07-Июн-22, 14:36 
> Для начала уговорить OpenNet открыть в Gemini зеркало

А было бы здорово, кстати.

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

88. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (128), 07-Июн-22, 16:55 
> Для начала уговорить OpenNet открыть в Gemini зеркало

Да сразу Youtube проси, не разменивайся на мелочёвку.

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

184. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (184), 08-Июн-22, 19:42 
Открой для себя peertube и другие альтернативы. Там и ненужного поменьше.
Ответить | Правка | Наверх | Cообщить модератору

30. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от Аноним (30), 07-Июн-22, 10:49 
"Фатальный недостаток" TCP уже много лет не даёт покоя этим людям...
Попугаи на картинках в презентации порадовали - 300ms на инициализацию TLS соединения поверх TCP, ага...
Ответить | Правка | Наверх | Cообщить модератору

138. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (137), 07-Июн-22, 23:31 
Подозрительно круглые цифры наводят на мысль...
Ответить | Правка | Наверх | Cообщить модератору

35. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +9 +/
Сообщение от Тот Самый (?), 07-Июн-22, 11:37 
>Возможность мгновенно установить соединение (0-RTT)

Эту технологию Гугл пытался еще в HTTP/2 продавить, несмотря на массовую критику со стороны защитников privacy. Сокращение раундов согласования при установлении соединения достигается за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровня. В этом случае изощренные технологии fingerprinting'а для трекинга юзеров становятся совершенно не нужными - браузер сам говорит серверу: "Я такой-то такой-то. Помнишь меня?". Есть еще большой "плюс" технологии: в отличие от HTTP cookies, идентификатор 0-RTT не подлежит фильтрации.

В большинстве браузеров 0-RTT уже реализован, но выключен по умолчанию (кроме Chrome, естественно). Ну а теперь 0-RTT станет частью веб стандарта HTTP/3.0. Критики идут лесом. Ура, товарищи!

Как обычно в случае передовых технологий от Гугла, "бойтесь данайцев, дары приносящих"

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

62. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (62), 07-Июн-22, 14:29 
> за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровня

А как долго он хранится? Так то внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-)

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

68. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 14:48 
> А как долго он хранится? Так то внутри TCP TLS сессии тоже
> есть идентификатор — ключ шифрования называется :-)

Он просто не понял в протокол, но разродился речугой, а люди вон даже лайкают... — всё как везде, людям заходят эмоции, а не технические подробности и предложения.

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

81. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –3 +/
Сообщение от Тот Самый (?), 07-Июн-22, 16:06 
>Он просто не понял в протокол, но разродился речугой

Истину глаголишь.
Произнеси это еще раз перед зеркалом.

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

83. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 16:14 
😃 я оставлю этот нетехнический выпад без ответа.
Ответить | Правка | Наверх | Cообщить модератору

100. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –3 +/
Сообщение от Тот Самый (?), 07-Июн-22, 17:38 
>оставлю этот нетехнический выпад без ответа

Аккуратно свалил :-)
"Он просто не понял в протокол" - это был очень технический и подробно аргументированный выпад.
(я уже говорил, что прежде всего надо смотреться в зеркало :-)

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

105. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 18:26 
> Аккуратно свалил :-)

Почитай выше, я везде использую официальную терминологию. А ты используешь какие-то "SSL ticket". Я уже не говорю о том, что у тебя каша в голове. HTTP/2 не предполагает обязательного шифрования, а 0-rtt есть в HTTP/3 и в TLS 1.3...

Разбирать процедуру TLS 1.3 пошагово? Просто мне в википедию для этого не нужно лезть. Я по памяти её среди ночи расскажу.

P.S. 0-rtt в Firefox включен уже не помню сколько лет.

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

114. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Тот Самый (?), 07-Июн-22, 19:26 
> 0-rtt в Firefox включен уже не помню сколько лет.

Я тоже не помню сколько лет назад я включил в user.js
user_pref("security.tls.enable_0rtt_data", false);

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

115. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 19:32 
>> 0-rtt в Firefox включен уже не помню сколько лет.
> Я тоже не помню сколько лет назад я включил в user.js
> user_pref("security.tls.enable_0rtt_data", false);

Зачем, что конкретно ты таким способом пытаешься решить?

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

118. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Тот Самый (?), 07-Июн-22, 19:49 
Надеюсь, что TorProject для тебя авторитетный источник и ты не считаешь, что у них "каша в голове"

https://gitlab.torproject.org/legacy/trac/-/issues/32364
Disable 0-RTT protocol in browser. It is a major tracking vector.
security.tls.enable_0rtt_data in about:config. Also disable in other places.

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

119. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 19:55 
Нет, это не самый авторитетный источник для меня. Далеко не самый. Давай, я тебе немного помогу с аргументацией: http://elpub.bib.uni-wuppertal.de/servlets/DerivateServlet/D...

Раз уж ты не можешь сформулировать толково мысль, то я тебе укажу на очевидную ошибку в первом твоём заявлении "Эту технологию Гугл пытался еще в HTTP/2 продавить, несмотря на массовую критику со стороны защитников privacy". Это ошибочно хронологически (порядок появления стандартов HTTP/2, HTTP/3 и TLS1.3 глянь) и технически.

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

116. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Тот Самый (?), 07-Июн-22, 19:41 
>у тебя каша в голове

Опять очень технический выпад. А вся аргументация сводится к "мне в википедию для этого не нужно лезть. Я по памяти её среди ночи расскажу"

Ну сколько можно?
Перед тем, как выносить о ком-то суждения, посмотри в зеркало и скажи себе: "Я не единственный на Земле знаю TLS1.3 по памяти" (от звездной болезни очень помогает)

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

117. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 19:46 
> Опять очень технический выпад.

Я тебе предлагаю сформулировать тезис технической терминологией. Всё, что ты родил до сих пор, — это каша из HTTP/2 и привязанного почему-то к нему 0-rtt из TLS 1.3, что банально хронологически неверно, т.к. последний появился даже позже QUIC. Когда ты сформулируешь тезис, возможно мы продолжим разговор об обоснованности твоих фобий касательно трекинга. Там есть момент, который, очевидно, ты не понял или, что вероятнее, прочитал об этом на каком-то medium бложике.

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

121. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Тот Самый (?), 07-Июн-22, 20:13 
>мы продолжим разговор об обоснованности твоих фобий касательно трекинга

Не будем.
Выше я высказал свое мнение и даже привел ссылку на "medium бложик". По мне - этого достаточно.
А теперь я аккуратно сваливаю :-)
Тема privicy очень индивидуальна и субъективна. Каждый сам для себя решает.

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

123. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 20:35 
> А теперь я аккуратно сваливаю :-)

Я тоже пойду розы почеренкую лучше )))

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

80. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Тот Самый (?), 07-Июн-22, 16:04 
>внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-)

Странно, что приходится подробно объяснять :-(
Ключ шифрования сессии - одноразовый и коротко живущий, в процессе длинной TLS сессии может несколько раз перегенерироваться.
SSL ticket (название еще не устоялось) - долгоживущий идентификатор (по крайней мере 24 часа), используемый между разными TLS сессиями при коннекте к одному и тому-же сайту (в этом и есть фишка 0-RTT). К ключам шифрования сессии отношения не имеет.

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

96. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от Аноним (128), 07-Июн-22, 17:21 
> долгоживущий идентификатор (по крайней мере 24 часа)

В протоколе стандартизировали то, что сейчас каждый хайлоад костылит у себя самостоятельно — кэширование TLS-сессий. Если твоя цель избежать слежки — иным словами быть анонимным в интернете — начинать надо не с HTTP/3, а с того, что ты логинишься на одни и те же 3½ сайта в одно и то же время со своего домашнего интернета.

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

101. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (101), 07-Июн-22, 17:57 
> кэширование TLS-сессий

Не знаю, что это значит в реальности, но звучит, как одуршлачивание.

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

110. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 18:39 
> кэширование TLS-сессий

Он не владеет терминологией и смутно знает о том, для чего какой стандарт. Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %)

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

131. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 22:38 
> Он не владеет терминологией и смутно знает о том, для чего какой стандарт.
> Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %)

Нет, кэшированием TLS-сессий я называю… кэширование TLS-сессий. Тебе не приходилось в процессе ОВЛАДЕВАНИЯ терминологией сталкиваться с RFC5077?

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

136. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 23:06 
А теперь попробуй натянуть свой тезис на вышесказанное и я поржу на кульбиты этой логики )))
Ответить | Правка | Наверх | Cообщить модератору

37. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 12:06 
> Для видеосервисов, таких как YouTube

Сначала будем использовать тиски для закручивания гаек, а потом начнём вырезать в губках выемки под шестигранник, чтобы было удобнее. Сначала возьмём неподходящий инструмент, а потом будем его рихтовать под задачу, для которой он изначально не был приспособлен. Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео.

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

38. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +4 +/
Сообщение от Попандопала (?), 07-Июн-22, 12:19 
Ага, яркий пример айтишизы. Все время должен быть прогресс ради прогресса. Здорово че.D
Ответить | Правка | Наверх | Cообщить модератору

44. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +5 +/
Сообщение от Аноним (200), 07-Июн-22, 12:45 
> прогресс ради прогресса

Если бы.
В крупных корпорациях нынче прогресс только ради премий манагерам. А выдаются они за выведенные на рынок новые проекты, причём независимо от их качества, удобства и даже прибыльности (достаточно вспомнить "кладбище проектов Google" - а ведь за запуск этих проектов кто-то когда-то тоже получал премии).

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

48. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Гость (??), 07-Июн-22, 12:49 
Ютуб давным давно готов избавится от "неподходящих инструментов", останавливают юзеры, использующие всякое старье, сколько шуму было когда перестали отдавать видео по http без шифрования.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

76. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 15:34 
Где ж он "избавляется"? HTTP был придуман для передачи документов, которые необходимо доставить без искажений (отсюда использование TCP), тогда как для передачи видео потеря кадра некритична (кроме случаев, когда видео надо передать и сохранить, но Ютуб с сохранением видео, как известно, очень не дружит). Вместо того, чтобы просто уйти от HTTP при передаче видео, Гугл превращает HTTP в уродливого тянитолкая, используемого сразу для двух принципиально разных задач.
Ответить | Правка | Наверх | Cообщить модератору

144. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Kuromi (ok), 08-Июн-22, 01:34 
Честно говоря зная Гугл я больше удивлен тому что они до сих пор не шифруют все видео с помощью EME. Тут кончено возможно что кто-то начнет возмущаться, но авторам быстро объянят что это "чтобы плагиаторы не могли тырить ваши драгоценные вертикальные видосы с телефона" и все успокоятся. Ну может максимум оставят где-то в глубине настроечку "да, я лошара и хочу чтобы кто угодно мог украть моё видео", откkючающую EME.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

145. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (175), 08-Июн-22, 01:39 
Смысла шифровать общедоступные видео мало. Шифрование абсолютно ничему не помешает, но съест уйму вычислительных ресурсов и у зрителей и у гугла.


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

160. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от www2 (??), 08-Июн-22, 07:21 
>Шифрование абсолютно ничему не помешает

Помешает узнать что этот конкретный клиент смотрит это конкретное видео. С шифрованием можно узнать только то, что этот конкретный клиент смотрит какое-то видео.

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

174. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (175), 08-Июн-22, 13:00 
Kuromi, говорил про EME и пиратство. Мой ответ был именно в этом контексте.
Ответить | Правка | Наверх | Cообщить модератору

65. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (62), 07-Июн-22, 14:39 
> Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео.

Обычный эволюционный итерационный процесс. Невозможно сразу заранее всё придумать навсегда.

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

77. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 15:37 
Вообще-то, то, что оно должно быть на основе UDP, можно было понять ещё тогда (а значит, HTTP, который работает поверх TCP, уже однозначно не подходит).
Ответить | Правка | Наверх | Cообщить модератору

89. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +3 +/
Сообщение от Аноним (128), 07-Июн-22, 17:04 
> можно было понять ещё тогда

Что ж ты не понял и не реализовал? Только не говори, что был занят комментированием новостей на опеннете.

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

103. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 18:18 
Вот ещё я такой гадостью занимался бы.
Мне и сейчас хочется убивать долбодятлов, которые выкладывают ролик "как вскрыть корпус ноутбука" с музончиком и приглашениями подписываться, вместо краткой инструкции, которую можно пробежать глазами за несколько секунд.
Видео в браузере - это мерзость для одноклеточных.
Ответить | Правка | Наверх | Cообщить модератору

133. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 23:00 
Я по видео в браузере научился:

1. ремонтировать и обслуживать автомобиль — менять масло, свечи, колёса, бортивать, пользоваться балансировщиком, дебажить проводку
2. водить автомобиль в тех условиях, про которые не учат в автошколе — экстремальные/неблагоприятные погодные явления, выход из заноса, комфортная езда в трафике/по городу, экономичная езда на большие расстояния, буксировка, езда с прицепом
3. парковать автомобиль с минимальными зазорами под любым углом, с прицепом и без
4. завязывать пояс так, чтобы при спраррингах не развязывался
5. разогреваться перед тренировкой и растягиваться после
6. всей базовой дерево- и металлообработке, вручную и с помощью инструмента
7. возводить простые конструкции из деревянного бруса
8. ухаживать за отдельными деревьями и за лесом в целом
9. тушить бытовые пожары подручными средствами
10. водить фуру (13 передач, охренеть)
11. водить трактор и пользоваться навесным оборудованием
12. прицельно стрелять из пистолета, ружья и винтовки

Это из того, что вот прямо с ходу в голову пришло. Про бесплатные лекции ведущих универов мира по любым предметам наверное и вовсе не стоит говорить — это, видимо, вовсе для вирусов.

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

147. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (147), 08-Июн-22, 04:50 
13. летать на боевом вертолёте.
14. летать на боевом истребителе и выходить победителем в бою.
15. летать на космическом корабле с варп-двигателем.
16. выучил несколько инопланетных языков.
Ответить | Правка | Наверх | Cообщить модератору

208. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 09-Июн-22, 17:04 
Тут ты меня с голосами в твоей голове перепутал.
Ответить | Правка | Наверх | Cообщить модератору

167. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от YetAnotherOnanym (ok), 08-Июн-22, 11:18 
Это, конечно, очень хорошо, рад за тебя, но всему этому можно было научиться по книгам или статьями Интернете.
У текста есть огромное преимущество перед видео - в видео ты в каждое определённое мгновенье получаешь только ту информацию, которая в данный момент отображена в кадре, тогда как имея перед глазами текст, ты можешь найти нужное место, не дожидаясь, пока диктор дочитает до него (отмазки про слайдбар не катят, искать нужный момент ползунком - это то ещё удовольствие).
Есть ещё "нюанс". Выкладывать обучающее видео - это для тех, кто формулирует свои мысли на уровне "вот эту штуку надо вставить вот сюда и провернуть до щелчка (опосля чего по два раза дергануть за пимпочки)". Такое непростительно ни преподу "ведущего универа", ни автомеханику из сервиса в арендованном гараже. А если есть внятный текст - почему они его не публикуют, а вынуждают тратить время на просмотр видео?
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

209. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 09-Июн-22, 17:14 
> можно было научиться по книгам или статьями Интернете.

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

> У текста есть огромное преимущество перед видео

У текста нет преимуществ перед видео (обратное тоже справедливо, впрочем). Оба полезны, оба нужны и оба используются для обучения.

> Есть ещё "нюанс".

Этот нюанс называется «соломенное чучело» и является инструментом демагога.

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

214. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от i (??), 10-Июн-22, 06:56 
помнится когда убунта пошла в массы, инет наводнился статьями - как установить что-то на линукс, и сводился к 1 строке - "апт инсталл что-то", порой включая гайд по установки убунты того же качества.

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

> Машина не заводится, но ничего, родная, погоди пару дней, я книжку прочитаю

книжку надо читать заранее, представь себе, не машина, а самолет..

Уважаемые пассажиры, мы падаем, сейчас пилот срочно гуглит что делать, ага..

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

218. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 10-Июн-22, 16:58 
> так уж вышло, что человечство генерирует больше дерьма чем чего-то другого

Откуда вы дерьмо на ютубе берёте-то? Специально ищете?

> книжку надо читать заранее,

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

> представь себе, не машина, а самолет..

Зачем представлять? Зашёл к соседу и спросил у него какую книжку он читал, чтобы двигатели у A380 ремонтировать в падении. Он сказал, что название книжки дословно не помнит, но суть сводится к техникам аварийной посадки на разные поверхности. Как это относится к реалиям моей жизни, не потрудишься описать?

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

102. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (101), 07-Июн-22, 18:09 
> Обычный эволюционный итерационный процесс.

Этих протоколов передачи видео и прочих (реалтайм) данных - хоть пруд пруди. Но почему-то избрали не самый прямой, точнее, самый кривой путь. Значит, это извращение кому-нибудь нужно?

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

111. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Vlad Violentiyemail (?), 07-Июн-22, 18:40 
Нука, расскажи как правильно надо передавать видеопоток по сети?
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

120. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (120), 07-Июн-22, 19:55 
Adobe Flash умел передавать правильно. В HTML5 все увы, разучились.
Ответить | Правка | Наверх | Cообщить модератору

141. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Kuromi (ok), 08-Июн-22, 00:22 
RTSP? Ну так его пользовали чтобы файлики с видео тырить было сложнее.
Вон помню когда Ютуб переходил на HTML5 Video, Рутуб (ага!) переходил на RTSP. Первым заметили это сервисы "скачать ролик с Рутуба". Скачка работать перестала, так же как и всяческие плагины для перехвата, а сайтики для скачки через месяцок позакрывались.
Была там одна софтина вод Виндовс, котоаря таки могла, но заморчоенный больно процесс был.
Ответить | Правка | Наверх | Cообщить модератору

281. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 02:37 
Софтина называется VLC и есть не только под винду :). А делается это так: открывается поток (хоть там какой) как обычно, но врубается еще и транскод/запись а не только вывод на дисплей. И оно прекрасно складирует поток на винч. На мощном компе можно сразу же и перекодировать, на маломощном лучше не стоит.
Ответить | Правка | Наверх | Cообщить модератору

290. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Kuromi (ok), 12-Июн-22, 05:45 
> Софтина называется VLC и есть не только под винду :). А делается
> это так: открывается поток (хоть там какой) как обычно, но врубается
> еще и транскод/запись а не только вывод на дисплей. И оно
> прекрасно складирует поток на винч. На мощном компе можно сразу же
> и перекодировать, на маломощном лучше не стоит.

Не не не, это был точно не VLC. Будь все так просто я бы запомнил. Та софтина была именно под тыринг RTSP заточена, хотя не исключаю что там могда быть какая нибудь обвязка вокруг опенсорца.

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

309. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 23:53 
В любом случае VLC-ом это тоже тырится, собственно половина его юзежа это запись поточного видео, по довольно разным протоколам.
Ответить | Правка | Наверх | Cообщить модератору

134. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 23:03 
> Нука, расскажи как правильно надо передавать видеопоток по сети?

https://www.rfc-editor.org/rfc-index.txt
Поиском по текстовому файлу пользоваться умеешь?

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

47. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +2 +/
Сообщение от Robin Hood (?), 07-Июн-22, 12:49 
Абсолютное ненужно, ровно как и ipv6 и http/2.0
Ответить | Правка | Наверх | Cообщить модератору

97. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (128), 07-Июн-22, 17:23 
Расскажи, каково это — сидеть в локалочке за натом всю жизнь и никогда даже не понюхать настоящий интернет?
Ответить | Правка | Наверх | Cообщить модератору

107. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +4 +/
Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 18:32 
Очень удобно, особенно когда NAT избавляет от необходимости нюхать чьи-то пуки.
Ответить | Правка | Наверх | Cообщить модератору

135. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 23:04 
Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё.
Ответить | Правка | Наверх | Cообщить модератору

169. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от YetAnotherOnanym (ok), 08-Июн-22, 11:23 
> Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё.

В моём зоопарке он по-разному называется. В том числе и "Брандмауэр". И что?

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

219. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 10-Июн-22, 17:01 
Ничего. Научись им пользоваться и не рассказывай глупости про НАТ.
Ответить | Правка | Наверх | Cообщить модератору

268. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от pofigist (?), 11-Июн-22, 10:20 
Ничего что все современные фаерволы имеют в своей основе NAT? Ибо нет трансляции - нет соединения.
Ответить | Правка | Наверх | Cообщить модератору

282. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 02:39 
> Ничего что все современные фаерволы имеют в своей основе NAT? Ибо нет
> трансляции - нет соединения.

Кто-то явно путает stateful firewall и NAT. Более того - в v6 вообще трансляция обычно экзотика. А stateful файрвол забацать вполне можно.

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

325. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от pofigist (?), 27-Июн-22, 16:58 
Cisco ASA же
Ответить | Правка | Наверх | Cообщить модератору

250. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Robin Hood (?), 11-Июн-22, 01:40 
Кто сказал что английское слово файерволл лучше немецкого брандмауэр?
Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

176. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от microsoft (?), 08-Июн-22, 13:28 
А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе нюхать интернеты напрямую?
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

228. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (228), 10-Июн-22, 18:10 
> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе
> нюхать интернеты напрямую?

При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много. И еще минус железки под нат.

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

291. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Kuromi (ok), 12-Июн-22, 05:48 
>> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе
>> нюхать интернеты напрямую?
> При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много.
> И еще минус железки под нат.

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

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

298. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:21 
Мой провайдер даёт один публичный IPv4 и /60 IPv6 в базе для домашних пользователей. На мобиле v4 через НАТ и публичный /64 v6. Но у нас тут регулятор регулярно регулирует провайдеров и жалобы клиентов разбирает.
Ответить | Правка | Наверх | Cообщить модератору

299. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:23 
Государственный регулятор.
Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

186. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (184), 08-Июн-22, 19:52 
Тепло и лампово. Нет, тебя не пустим, сиди в своём, настоящем (tm).
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

213. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 09-Июн-22, 20:25 
А в чём проблема-то?
Без этого счастья всё прекрасно работает.
Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

220. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (128), 10-Июн-22, 17:07 
Ну если только на одноклассники ходить, то действительно всё работает — для этого и доступ в интернет не нужен, можно хоть через провайдерский прокси туда попасть. Но я с локалками ещё в 200х наигрался.
Ответить | Правка | Наверх | Cообщить модератору

54. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от TomasGl (?), 07-Июн-22, 13:10 
Если для отправки данных не нужно получать ответ, получается новый способ DoS атаки. Раньше в icmp и syn подменяли адреса отправителя, а теперь и в http flood можно (ip spoofing)
Ответить | Правка | Наверх | Cообщить модератору

55. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от TomasGl (?), 07-Июн-22, 13:10 
Да начнутся DDoS с локалхостов и рандомных ip!
Ответить | Правка | Наверх | Cообщить модератору

93. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 17:09 
> ip spoofing

Неосиляторы RFC2827 должны быть экскоммуницированы.

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

57. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (57), 07-Июн-22, 13:33 
tldr;

Показалось - бинарщина с реализацией принципа все в одном флаконе и попыткой подмять пока независимой слой TLS и все это в стиле systemd...

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

71. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (181), 07-Июн-22, 14:59 
HTTP/2, который бинарный и стиле systemd, уже давно работает.
Скорее всего, через него вы комментарий и отправили.
Ответить | Правка | Наверх | Cообщить модератору

73. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (14), 07-Июн-22, 15:14 
HTTP/1.1 на опеннете.
Ответить | Правка | Наверх | Cообщить модератору

94. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 07-Июн-22, 17:10 
Слишком новый и модный. Должен быть gopher.
Ответить | Правка | Наверх | Cообщить модератору

260. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:16 
> Слишком новый и модный. Должен быть gopher.

Да ладно, может HTTP/0.9 вас устроит? :)

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

300. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:24 
Нет! Только гофер. А комменты по UUCP.
Ответить | Правка | Наверх | Cообщить модератору

261. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:19 
> HTTP/2, который бинарный и стиле systemd, уже давно работает.

TLS так то тоже бинарный. Как впрочем и TCP.

А текстовость HTTP1.x в паре с немного разным пониманием теми и этими одного и того же позволяет море лулзов когда атакующий умудряется вклинить что-то лишнее и начинаются эпические приколы типа request smuggling и desync во всех его ипостасях.

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

60. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (60), 07-Июн-22, 13:55 
> Заметный прирост производительности и пропускной способности по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.

Кэп_mode: оно для этого. А остальные просто безвольно подтянутся.

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

69. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (67), 07-Июн-22, 14:48 
На ведь правда заключается что по хорошему надо жестко внедрять что-то на вроде ZeroNet но ведь все понимают что такого не будет и мы будем сидеть на внедренных хттп/3
Ответить | Правка | Наверх | Cообщить модератору

74. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от ананоша (?), 07-Июн-22, 15:17 
Только вчера пытался настроить для одного дела, проблем еще хватает. Что сказать, если даже curl юзающий cloudflare-овскую либу quiche не может к этому самому cf законнектиться через --http3 флаг)
Ответить | Правка | Наверх | Cообщить модератору

79. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (79), 07-Июн-22, 16:00 
И все это ради того чтобы снизить нагрузку на канал тытрупа на 1%. По крайней мере раньше такие "успехи" были от потенциального пропихивания тормозвик.
Ответить | Правка | Наверх | Cообщить модератору

84. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (84), 07-Июн-22, 16:17 
Кто тыкал, подскажите как браузер узнаёт что надо юзать UDP вместо TCP?
Ответить | Правка | Наверх | Cообщить модератору

109. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Гость (??), 07-Июн-22, 18:35 
DNS type 65 для этого изобрели чтобы браузер сразу знал как куда!
Ответить | Правка | Наверх | Cообщить модератору

127. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноня (?), 07-Июн-22, 22:10 
Браузер сначала пробует HTTP/2, сервер ему возвращает поддержку HTTP/3 через заголовок Alt-svc, далее браузер может подключаться по H/3
Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

85. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (85), 07-Июн-22, 16:19 
О да, теперь отслеживать пользователей будет еще проще, на уровне протокола. "Мы еще многого не знаем про вас" (c) Кто-то из топ-менеджеров Microsoft
Ответить | Правка | Наверх | Cообщить модератору

232. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (228), 10-Июн-22, 18:14 
> О да, теперь отслеживать пользователей будет еще проще, на уровне протокола.

Что в нем такого для отслеживания чего не было в предыдущих?

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

99. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (99), 07-Июн-22, 17:37 
А Роскомнадзор его уже заблокировал :D
Не нужон нам этот ваш HTTP/3!
Ответить | Правка | Наверх | Cообщить модератору

112. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от timur.davletshin (ok), 07-Июн-22, 18:42 
> А Роскомнадзор его уже заблокировал :D
> Не нужон нам этот ваш HTTP/3!

Ложь. Единственный стандарт, блокировке которого шла речь, был ESNI. Но он, стандарт, благополучно загнулся/переродился в ECH, который никто толком не поддерживает ещё.

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

158. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (158), 08-Июн-22, 06:50 
https://ntc.party/t/http-3-quic/1823
Ответить | Правка | Наверх | Cообщить модератору

159. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –2 +/
Сообщение от timur.davletshin (ok), 08-Июн-22, 06:53 
> https://ntc.party/t/http-3-quic/1823

Простите, а какое отношение к этому имеет РКН? Или теперь всё по логике "Кошка бросила котят - это Путин винован. А пятого, пархатого, спасла Чулпан Хаматова"?

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

104. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от None (??), 07-Июн-22, 18:20 
В смысле, можно отправить 1 пакет с запросом, и в ответ на адрес, указанный в заголовке UDP пакета прилетит пара мегабайт <s>свопа</s> отборнейшего js кода? Ух, тема!
Ответить | Правка | Наверх | Cообщить модератору

106. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (106), 07-Июн-22, 18:27 
Что плохого для поливитамина? Запросы посылает пользователь, вот, пусть и радуется внезапно навалившейся халяве.
Ответить | Правка | Наверх | Cообщить модератору

178. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от microsoft (?), 08-Июн-22, 13:36 
Действительно. Ему сразу поток с порно льют, а он еще и не доволен.
Ответить | Правка | Наверх | Cообщить модератору

124. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Kuromi (ok), 07-Июн-22, 20:50 
Ну чтож, вне зависимости от того хороший протокол или плохой очевидно следующее - "внедреж" его займет уйму времени. HTTP2 только последние пару лет стало более-менее мейнстримом, и то, естественно, не везде. HTTP3 на данный момент можно заметить только на Ютубе и еще пару мест проскакивало (Для ФФ есть аддон показывающий версию протокола в строке адреса, удобно) где это явно был просто эксперимент.
Ответить | Правка | Наверх | Cообщить модератору

126. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 07-Июн-22, 21:45 
Реализована в Edge. Я правильно понимаю что реализована в Edge это значит не удалена из Edge?
Ответить | Правка | Наверх | Cообщить модератору

132. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (132), 07-Июн-22, 22:58 
Теперь надеюсь тормоза из nginx его реализуют, наконец. Жду не дождусь выключить поддержку http1 и 2.
Ответить | Правка | Наверх | Cообщить модератору

140. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от cloudchief (ok), 08-Июн-22, 00:21 
Нифига себе я пива попил - только 1.1 и тут на тебе - 3.0 - вот тебе и куик в лицо)
Ответить | Правка | Наверх | Cообщить модератору

148. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (148), 08-Июн-22, 06:17 
как выключить в ff?
Ответить | Правка | Наверх | Cообщить модератору

156. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (148), 08-Июн-22, 06:39 
http2.enabled->false
http3.enabled->false
Ответить | Правка | Наверх | Cообщить модератору

149. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (148), 08-Июн-22, 06:20 
> т.е. в ... символ CR может применяться только вместе с символом перевода строки (CRLF)

о, виндозные \r\n подвезли, красота

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

161. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от www2 (??), 08-Июн-22, 07:25 
Насколько я помню, в текстовых протоколах всегда так было. Но сервер должен быть терпим к кривым клиентам и требователен к себе, поэтому обычно от клиентов принимаются и запросы, не совсем соответствующие стандарту.
Ответить | Правка | Наверх | Cообщить модератору

172. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Гедеван (?), 08-Июн-22, 12:25 
Вот потому, что вы говорите то, что не думаете, и думаете то, что не думаете, вот в клетках и сидите. И вообще, весь этот горький катаклизм, который я тут наблюдаю. И Владимир Николаевич тоже.
Ответить | Правка | Наверх | Cообщить модератору

265. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:27 
> Насколько я помню, в текстовых протоколах всегда так было. Но сервер должен
> быть терпим к кривым клиентам и требователен к себе, поэтому обычно
> от клиентов принимаются и запросы, не совсем соответствующие стандарту.

Если почитать новости опеннета, недавние и не очень, можно узнать что жизнь довольно жестко научила многих быть придирчивее к клиентам. Иначе они начинают request smuggling затевать, фронт и бэк начинают видеть мир по разному, а дальше хацкеры делают что хотят...

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

189. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от мяя (?), 08-Июн-22, 23:30 
Они не "виндозные".
> LF (ASCII 0x0A) используется в Multics, UNIX, UNIX-подобных операционных системах (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD и др.), BeOS, Amiga UNIX, RISC OS и других;
> CR (ASCII 0x0D) используется в 8-битовых машинах Commodore, машинах TRS-80, Apple II, системах Mac OS до версии 9 и OS-9;
> CR+LF (ASCII 0x0D 0x0A) используется в DEC RT-11 и большинстве других ранних не-UNIX- и не-IBM-систем, а также в CP/M, MP/M (англ.), MS-DOS, OS/2, Microsoft Windows, Symbian OS, протоколах Интернет.
Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

221. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (128), 10-Июн-22, 17:11 
Тише, не разрушай Легенду О Настоящем Юниксе™ И Его Юниксвее™. А то может оказаться, что его никогда и не было, и всё это легенды да шуточки из Bell Labs.
Ответить | Правка | Наверх | Cообщить модератору

293. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 12-Июн-22, 08:47 
Использовать два байта в качестве разделителя для потоковых протоколов мог додуматься только настоящий академик.
Я хз, кто это выдумал, но это создаёт просто офигительный оверхед при разборе, на самом-то деле. Поэтому да, большинство разбирало по \n, а \r тупо отрезало, что и породило фигову тучу проблем.
Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

264. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:25 
> о, виндозные \r\n подвезли, красота

Не очень понятно зачем - лишний байт почем зря в протоколе который так то не текстовый.

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

180. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (179), 08-Июн-22, 14:17 
В целом как в мемчике ну решили какие-то проблемы, а фундаментально проблемы блокировок, вражды и прочие социокультурные проблемы все равно больше и страшнее чем задержка открытыия сайта в 1.5 миллисекунды
Ответить | Правка | Наверх | Cообщить модератору

294. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 12-Июн-22, 08:49 
Это для тебя задержка открытия сайта в 1.5 миллисекунды - не проблема.
А для макак, которые в сайт напихали пару сотен JS и CSS по две строчки в каждом, 1.5 миллисекунды умножаются на эту пару сотен, и превращаются уже в доли секунды, если не секунды.
Ответить | Правка | Наверх | Cообщить модератору

212. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Онаним (?), 09-Июн-22, 20:23 
deny udp any any eq 80
deny udp any eq 80 any
deny udp any any eq 443
deny udp any eq 443 any
permit ip any any
Ответить | Правка | Наверх | Cообщить модератору

222. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (128), 10-Июн-22, 17:13 
Ты заодно ICMP забыл запретить, клоун.
Ответить | Правка | Наверх | Cообщить модератору

230. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (228), 10-Июн-22, 18:12 
> deny udp any any eq 80
> deny udp any eq 80 any
> deny udp any any eq 443
> deny udp any eq 443 any
> permit ip any any

Лучше 67 забань. И 53, на всякий случай.

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

240. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 10-Июн-22, 20:07 
67 во внешку смысл забанить всегда есть, зачем плодить?
53 - только по индивидуальной просьбе.
Ответить | Правка | Наверх | Cообщить модератору

262. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 11-Июн-22, 02:22 
> 67 во внешку смысл забанить всегда есть, зачем плодить?

Да и себе его забань. Если кто сильно умный, статику настроит, остальные отдохнут от интернета, по крайней мере V4.

> 53 - только по индивидуальной просьбе.

Именно поэтому на 53 удобно вешать vpn-ы всякие, они так забавно прорубаются через фаеры, наты, гостевые-демо-неоплачено доступы и прочую лабудень :)

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

267. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 11-Июн-22, 08:43 
Китайцы вообще через DNS-серверы VPN'ы гоняли одно время. Потом как-то утихло.
А с любителями VPN'ов на 53 вполне справляется deny для TCP и жёсткий полисинг (rate limit) по UDP, DNS-то много не надо.
Ответить | Правка | Наверх | Cообщить модератору

283. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (-), 12-Июн-22, 02:51 
> Китайцы вообще через DNS-серверы VPN'ы гоняли одно время. Потом как-то утихло.

Если через порт 53 UDPшный впн то это недурно работает, половина растяпоадминов даже в платном/демо доступе напрочь не парится блокировкой. Хомяки строятся, те кто поумнее без мыла пролезают. Fair enough :P.

А если в именно DNS запросах тунелять - так делают, но это очень тормозно и практикуется только в самом крайнем случае, когда все остальные опции исчерпались. А китайцы из-за мерзкого файрвола научились в очень крутые и продвинутые сетевые тулсы, намного круче любых других технологий. Думаю они просто придумали более 9000 способов делать это лучше.

> А с любителями VPN'ов на 53 вполне справляется deny для TCP

VPN так то и UDPшный бывает. Зачем TCP на 53? Наоборот, UDP, чтобы на DNS больше смахивало.

> и жёсткий полисинг (rate limit) по UDP, DNS-то много не надо.

Это уже отдельно настраивать надо, сколько админов заморачивается? Не, если вы охренеете и плотно подсядете на неделю к ним и будете торенты лить, админы, конечно, с горя заморочатся как вас оттуда убрать. И даже тупой сможет в -j DROP <проблемный хост> или что там у него, если приперло. А если не приперло... то довольно часто таки работает.

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

292. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 12-Июн-22, 08:44 
Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных клиентов были выходной точкой, но не отключать же их от DNS).
Ответить | Правка | Наверх | Cообщить модератору

311. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (-), 13-Июн-22, 00:21 
> Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось
> специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных
> клиентов были выходной точкой, но не отключать же их от DNS).

Оно такое даже опенсорсное есть, iodine чтоли, называлось. Работает, но медленно.

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

322. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 13-Июн-22, 09:26 
Ну, мы сами писали на средних курсах :D Под винду правда.
А так - возможно оно и было, я особо не изучал, но адреса DNS-серверов китайские. Длинные псевдо-имена в сторону неких доменов, в ответ тоже неразборчивые TXT.
Ответить | Правка | Наверх | Cообщить модератору

301. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Аноним (128), 12-Июн-22, 18:31 
> на 53 вполне справляется deny для TCP

И ты получаешь поломанный ДНС, который вроде обычно работает, но иногда не работает.

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

303. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 12-Июн-22, 21:55 
Бывает такое, yes. Поэтому лучше конечно жёстко полисить.
Ответить | Правка | Наверх | Cообщить модератору

241. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 10-Июн-22, 20:10 
Ещё посмотрим как оно себя будет вести, когда это будут заливать старт-пакетами 0-RTT.
Ответить | Правка | Наверх | Cообщить модератору

242. "Протокол HTTP/3.0 получил статус предложенного стандарта"  +/
Сообщение от Онаним (?), 10-Июн-22, 20:12 
(запрашиваешь один коннект, считаешь ключи, заливаешь 10 гиг 0-RTT, профит?)
Ответить | Правка | Наверх | Cообщить модератору

243. "Протокол HTTP/3.0 получил статус предложенного стандарта"  –1 +/
Сообщение от Онаним (?), 10-Июн-22, 20:13 
Ну и 2x-3x хендшейк для амплификации не очень хорошо, но всё же имеется.
Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

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

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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