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

"Протокол 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. Сообщение от Жироватт (ok), 07-Июн-22, 08:56	+8 +/–
Welcome to googlenet?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

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

3. Сообщение от pashev.ru (?), 07-Июн-22, 09:03	–3 +/–
> Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках; А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #10, #11, #15

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

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

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

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

11. Сообщение от Брат Анон (ok), 07-Июн-22, 09:31	–1 +/–
Ещё раз: > Потеря пакета ... Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать прочитанное, увиденное и услышанное. Просто пипец какой-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #20

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

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

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

15. Сообщение от timur.davletshin (ok), 07-Июн-22, 09:49	+6 +/–
> А пакет "теряется" сам по себе, проблемы физического канала ни при чём и не влияют на другие потоки 😅 Пакеты теряются по дизайну, именно потеря пакета и является тем, что даёт сигнал отправляющему данные о том, что нужно снизить скорость. Да, есть ECN и есть delay-based алгоритмы управления потоком, но первые спустя столько-то лет до сих пор не включены по умолчанию ни в этих ваших Линуксах (два Linux'а в дефолтной конфигурации не договорятся о ECN), ни в значительной части сетевого оборудования (это вообще стыд и срам, причин не включать просто нет), а вторые по дизайну проигрывают packet-loss алгоритмам и внедрять их надо сразу и везде или городить гибридные алгоритмы, которые будут определять событие конкуренции с loss-based потоком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #217

16. Сообщение от lockywolf (ok), 07-Июн-22, 09:50	+/–
Подождите, его уже уже год как стандартизировали. Что-то тут не то.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

20. Сообщение от timur.davletshin (ok), 07-Июн-22, 10:03	+5 +/–
> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать > прочитанное, увиденное и услышанное. Просто пипец какой-то. Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты теряются всегда и везде, а вынос операции обработки этого события в userspace никак не уменьшает вероятность этого события. Более того, хочу напомнить, что изначально Google толкал BBR, но отказался от него в спецификации, а большинство реальных реализаций используют доступные уже многие годы алгоритмы CUBIC/Reno. Да, я знаю, что Google запилил даже BBRv2 (он всё ещё не релиз) и у себя использует какую-то третью реализацию, отличную от BBRv1, доступного в ядре Linux, и BBRv2, но общей картины это никак не меняет. P.S. Миграция соединения всё же полезная "фича".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #45

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

22. Сообщение от timur.davletshin (ok), 07-Июн-22, 10:11	+8 +/–
> Самое время беспокоиться о миллисекундах соединения, когда сотни файлов качаются несколько > минут. Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке. В устанавливаемых соединениях практически никогда не происходит события достижения лимита физической пропускной способности сети и миллисекундные задержки и накладные расходы на установление параметров соединения, DNS запросы выливаются в неторопливое открытие "глагне" даже на гигабитном канале. P.S. но лично я бы сосредоточился на допиливании HTTP/2 и TCP. Да-да, он, TCP, до сих пор в режиме постоянной доработки и научных статей поток не иссякает на эту тему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27, #31, #43, #92, #139

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

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

25. Сообщение от Аноним (25), 07-Июн-22, 10:32	+/–
Think different. Это не недостатки, а новые возможности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #26, #70

26. Сообщение от timur.davletshin (ok), 07-Июн-22, 10:33	+1 +/–
> Think different. Это не недостатки, а новые возможности.   У thinkdifferent'ов хоть ECN включен в дефолте )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

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

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

29. Сообщение от timur.davletshin (ok), 07-Июн-22, 10:38	+8 +/–
> Расскажи зачем тебе мгновенное открытие глагне? Как это изменит твою жизнь и > как вообще на этом можно заработать? Мгновенно ничего не бывает. Загрузка глагне в несколько секунд — стыд и срам, но это проблема конeчно же на 95% веб-разработчика, а не инженера, разрабатывавшего HTTP/x
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #33

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

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

32. Сообщение от Аноним (32), 07-Июн-22, 11:04	+/–
Больше мониторов богу мониторов!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #40

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

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

35. Сообщение от Тот Самый (?), 07-Июн-22, 11:37	+9 +/–
>Возможность мгновенно установить соединение (0-RTT) Эту технологию Гугл пытался еще в HTTP/2 продавить, несмотря на массовую критику со стороны защитников privacy. Сокращение раундов согласования при установлении соединения достигается за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровня. В этом случае изощренные технологии fingerprinting'а для трекинга юзеров становятся совершенно не нужными - браузер сам говорит серверу: "Я такой-то такой-то. Помнишь меня?". Есть еще большой "плюс" технологии: в отличие от HTTP cookies, идентификатор 0-RTT не подлежит фильтрации. В большинстве браузеров 0-RTT уже реализован, но выключен по умолчанию (кроме Chrome, естественно). Ну а теперь 0-RTT станет частью веб стандарта HTTP/3.0. Критики идут лесом. Ура, товарищи! Как обычно в случае передовых технологий от Гугла, "бойтесь данайцев, дары приносящих"
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62

36. Сообщение от timur.davletshin (ok), 07-Июн-22, 11:49	+12 +/–
> Да нет тут проблемы быстрая загрузка первой страницы никому не нужна. Конечно нет, все оптимизаторы должны идти нафиг. Рапид-девелопмент и быдлокод уже победили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #39

37. Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 12:06	+5 +/–
> Для видеосервисов, таких как YouTube Сначала будем использовать тиски для закручивания гаек, а потом начнём вырезать в губках выемки под шестигранник, чтобы было удобнее. Сначала возьмём неподходящий инструмент, а потом будем его рихтовать под задачу, для которой он изначально не был приспособлен. Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #48, #65, #111

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

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

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

41. Сообщение от Тот Самый (?), 07-Июн-22, 12:32	+3 +/–
>HTTP уже устарел Не устарел, а вконец изгадился (точнее, заcрали) >magnet:?xt=urn: в массы! Пора мигрировать в Gemini. Для начала уговорить OpenNet открыть в Gemini зеркало
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #63, #88

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

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

44. Сообщение от Аноним (200), 07-Июн-22, 12:45	+5 +/–
> прогресс ради прогресса Если бы. В крупных корпорациях нынче прогресс только ради премий манагерам. А выдаются они за выведенные на рынок новые проекты, причём независимо от их качества, удобства и даже прибыльности (достаточно вспомнить "кладбище проектов Google" - а ведь за запуск этих проектов кто-то когда-то тоже получал премии).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

45. Сообщение от Брат Анон (ok), 07-Июн-22, 12:46	–3 +/–
>> Где здесь "пакет теряется"? Не перестаю удивляться способности кожанных мешков коверкать >> прочитанное, увиденное и услышанное. Просто пипец какой-то. > Я советую всё же научиться пользоваться утилитой ss, чтобы понять, что пакеты > теряются всегда и везде Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #49, #51, #59, #91, #98, #142, #183

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

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

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

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

50. Сообщение от n00by (ok), 07-Июн-22, 12:57	+3 +/–
> отсутствие вменяемого механизма противодействия ддос Написали жеж: "Поддержку ... обеспечивает ... Cloudflare". Вроде всё понятно. Хочется поставить смайлик, но не знаю, какой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #168

51. Сообщение от timur.davletshin (ok), 07-Июн-22, 12:59	+/–
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите > русский язык. Пакет не может потерять САМ СЕБЯ. Читай учебник демагога, слабый заход. Да и технически ты тоже ошибаешься. Пакеты сами по себе теряются благодаря RED.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

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

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

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

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

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

57. Сообщение от Аноним (57), 07-Июн-22, 13:33	+/–
tldr; Показалось - бинарщина с реализацией принципа все в одном флаконе и попыткой подмять пока независимой слой TLS и все это в стиле systemd...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71

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

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

61. Сообщение от timur.davletshin (ok), 07-Июн-22, 14:17	+3 +/–
> То есть, после повсеместного внедрения стандарта, придётся переносить реализацию в ядро? > Но Гугл не обязательно этим со всеми поделится. Соль была в том, чтобы иметь реализацию в пользовательском пространстве. Мол, так алгоритм управления потоком 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ообщить модератору
Родитель: #56 Ответы: #225

62. Сообщение от Аноним (62), 07-Июн-22, 14:29	+2 +/–
> за счет сохранения на стороне браузера что-то вроде уникальных cookies, только не для HTTP, а для TLS уровня А как долго он хранится? Так то внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #68, #80

63. Сообщение от Аноним (14), 07-Июн-22, 14:36	+/–
> Для начала уговорить OpenNet открыть в Gemini зеркало А было бы здорово, кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

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

65. Сообщение от Аноним (62), 07-Июн-22, 14:39	+1 +/–
> Сначала будем гнать видео по HTTP, который не для этого придуман, а потом начнём выдумывать новый HTTP, приспособленный для передачи видео. Обычный эволюционный итерационный процесс. Невозможно сразу заранее всё придумать навсегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #77, #102

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

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

68. Сообщение от timur.davletshin (ok), 07-Июн-22, 14:48	+3 +/–
> А как долго он хранится? Так то внутри TCP TLS сессии тоже > есть идентификатор — ключ шифрования называется :-) Он просто не понял в протокол, но разродился речугой, а люди вон даже лайкают... — всё как везде, людям заходят эмоции, а не технические подробности и предложения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #81

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

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

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

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

73. Сообщение от Аноним (14), 07-Июн-22, 15:14	+/–
HTTP/1.1 на опеннете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #94

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

75. Сообщение от Аноним (75), 07-Июн-22, 15:34	+/–
is coming out
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

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

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

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

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

80. Сообщение от Тот Самый (?), 07-Июн-22, 16:04	+/–
>внутри TCP TLS сессии тоже есть идентификатор — ключ шифрования называется :-) Странно, что приходится подробно объяснять :-( Ключ шифрования сессии - одноразовый и коротко живущий, в процессе длинной TLS сессии может несколько раз перегенерироваться. SSL ticket (название еще не устоялось) - долгоживущий идентификатор (по крайней мере 24 часа), используемый между разными TLS сессиями при коннекте к одному и тому-же сайту (в этом и есть фишка 0-RTT). К ключам шифрования сессии отношения не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #96

81. Сообщение от Тот Самый (?), 07-Июн-22, 16:06	–3 +/–
>Он просто не понял в протокол, но разродился речугой Истину глаголишь. Произнеси это еще раз перед зеркалом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #83

82. Сообщение от timur.davletshin (ok), 07-Июн-22, 16:12	+2 +/–
>  Всё это совершенные мелочи по сравнению с проблемами tcp. Ограничения TCP известны и изучены. CUBIC/Reno и все эти SACK, ECN, гибридный старт годами отлажены и отполированы. А придуманный, пускай даже и в Google, BBR оказался переусложнённым и ничем не выдающимся с функциональной стороны. Зато с кучей новых проблем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #164

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

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

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

86. Сообщение от Аноним (86), 07-Июн-22, 16:22	+2 +/–
> внедряли BitTorrent-протокол Ты хотел сказать IPFS?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

87. Сообщение от timur.davletshin (ok), 07-Июн-22, 16:33	+/–
> У тех серьёзных ребят, у которых этот протокол внедрён и которым от > него профит, это всё ведь не юзерспейсом обрабатывается, а специализированным аппаратно-программным > комплексом. Шта?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #162

88. Сообщение от Аноним (128), 07-Июн-22, 16:55	+1 +/–
> Для начала уговорить OpenNet открыть в Gemini зеркало Да сразу Youtube проси, не разменивайся на мелочёвку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #184

89. Сообщение от Аноним (128), 07-Июн-22, 17:04	+3 +/–
> можно было понять ещё тогда Что ж ты не понял и не реализовал? Только не говори, что был занят комментированием новостей на опеннете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #103

90. Сообщение от ip1982 (ok), 07-Июн-22, 17:05	+/–
Только в одном потоке, или во всех случайным образом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #204

91. Сообщение от ip1982 (ok), 07-Июн-22, 17:07	+3 +/–
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ. Брат, языки сложнее чем ты думаешь :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

92. Сообщение от ip1982 (ok), 07-Июн-22, 17:08	+/–
> Именно об этом и стоит беспокоиться. Открой режим отладки в своём браузере и посмотри, сколько соединений открывается для загрузки главной на любимом новостном ресурсе или в социалке. Да, единственное решение - HTTP/3! :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

93. Сообщение от Аноним (128), 07-Июн-22, 17:09	+/–
> ip spoofing Неосиляторы RFC2827 должны быть экскоммуницированы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

94. Сообщение от Аноним (128), 07-Июн-22, 17:10	+/–
Слишком новый и модный. Должен быть gopher.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #260

95. Сообщение от fi (ok), 07-Июн-22, 17:12	+/–
на днях вышел haproxy 2.6 - уже с http3 ))) так что процесс пошел
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #125, #199

96. Сообщение от Аноним (128), 07-Июн-22, 17:21	–2 +/–
> долгоживущий идентификатор (по крайней мере 24 часа) В протоколе стандартизировали то, что сейчас каждый хайлоад костылит у себя самостоятельно — кэширование TLS-сессий. Если твоя цель избежать слежки — иным словами быть анонимным в интернете — начинать надо не с HTTP/3, а с того, что ты логинишься на одни и те же 3½ сайта в одно и то же время со своего домашнего интернета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #101

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

98. Сообщение от Аноним (128), 07-Июн-22, 17:27	+6 +/–
> Еще раз: "теряется" -- буквально "теряет ся" -- "теряет сам себя". Учите русский язык. Пакет не может потерять САМ СЕБЯ. Тебя задорнов покусал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

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

100. Сообщение от Тот Самый (?), 07-Июн-22, 17:38	–3 +/–
>оставлю этот нетехнический выпад без ответа Аккуратно свалил :-) "Он просто не понял в протокол" - это был очень технический и подробно аргументированный выпад. (я уже говорил, что прежде всего надо смотреться в зеркало :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #105

101. Сообщение от Аноним (101), 07-Июн-22, 17:57	+/–
> кэширование TLS-сессий Не знаю, что это значит в реальности, но звучит, как одуршлачивание.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #110

102. Сообщение от Аноним (101), 07-Июн-22, 18:09	+1 +/–
> Обычный эволюционный итерационный процесс. Этих протоколов передачи видео и прочих (реалтайм) данных - хоть пруд пруди. Но почему-то избрали не самый прямой, точнее, самый кривой путь. Значит, это извращение кому-нибудь нужно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

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

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

105. Сообщение от 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ообщить модератору
Родитель: #100 Ответы: #114, #116

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

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

108. Сообщение от Аноним (108), 07-Июн-22, 18:34	+1 +/–
> выносом операции ресэмплинга звука из ядра в pulseaudio. Вообще-то ядерная часть ALSA никогда не умела делать ресэмплинг, этим всегда занималась юзерспейсная библиотека. Ядерная часть могла только переключить DAC в режим воспроизведения другого формата, но это возможно и через pulseaudio (но выключено по умолчанию).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #113

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

110. Сообщение от timur.davletshin (ok), 07-Июн-22, 18:39	+/–
> кэширование TLS-сессий Он не владеет терминологией и смутно знает о том, для чего какой стандарт. Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #131

111. Сообщение от Vlad Violentiy (?), 07-Июн-22, 18:40	+/–
Нука, расскажи как правильно надо передавать видеопоток по сети?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #120, #134

112. Сообщение от timur.davletshin (ok), 07-Июн-22, 18:42	+/–
> А Роскомнадзор его уже заблокировал :D > Не нужон нам этот ваш HTTP/3! Ложь. Единственный стандарт, блокировке которого шла речь, был ESNI. Но он, стандарт, благополучно загнулся/переродился в ECH, который никто толком не поддерживает ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #158

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

114. Сообщение от Тот Самый (?), 07-Июн-22, 19:26	–1 +/–
> 0-rtt в Firefox включен уже не помню сколько лет. Я тоже не помню сколько лет назад я включил в user.js user_pref("security.tls.enable_0rtt_data", false);
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #115

115. Сообщение от timur.davletshin (ok), 07-Июн-22, 19:32	+/–
>> 0-rtt в Firefox включен уже не помню сколько лет. > Я тоже не помню сколько лет назад я включил в user.js > user_pref("security.tls.enable_0rtt_data", false); Зачем, что конкретно ты таким способом пытаешься решить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #118

116. Сообщение от Тот Самый (?), 07-Июн-22, 19:41	+/–
>у тебя каша в голове Опять очень технический выпад. А вся аргументация сводится к "мне в википедию для этого не нужно лезть. Я по памяти её среди ночи расскажу" Ну сколько можно? Перед тем, как выносить о ком-то суждения, посмотри в зеркало и скажи себе: "Я не единственный на Земле знаю TLS1.3 по памяти" (от звездной болезни очень помогает)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #117

117. Сообщение от timur.davletshin (ok), 07-Июн-22, 19:46	+/–
> Опять очень технический выпад. Я тебе предлагаю сформулировать тезис технической терминологией. Всё, что ты родил до сих пор, — это каша из HTTP/2 и привязанного почему-то к нему 0-rtt из TLS 1.3, что банально хронологически неверно, т.к. последний появился даже позже QUIC. Когда ты сформулируешь тезис, возможно мы продолжим разговор об обоснованности твоих фобий касательно трекинга. Там есть момент, который, очевидно, ты не понял или, что вероятнее, прочитал об этом на каком-то medium бложике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #121

118. Сообщение от Тот Самый (?), 07-Июн-22, 19:49	–1 +/–
Надеюсь, что 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ообщить модератору
Родитель: #115 Ответы: #119

119. Сообщение от 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ообщить модератору
Родитель: #118

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

121. Сообщение от Тот Самый (?), 07-Июн-22, 20:13	+/–
>мы продолжим разговор об обоснованности твоих фобий касательно трекинга Не будем. Выше я высказал свое мнение и даже привел ссылку на "medium бложик". По мне - этого достаточно. А теперь я аккуратно сваливаю :-) Тема privicy очень индивидуальна и субъективна. Каждый сам для себя решает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #123

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

123. Сообщение от timur.davletshin (ok), 07-Июн-22, 20:35	+/–
> А теперь я аккуратно сваливаю :-) Я тоже пойду розы почеренкую лучше )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

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

125. Сообщение от microsoft (?), 07-Июн-22, 21:20	+1 +/–
https://github.com/haproxy/haproxy/issues/680 Таки ты врешь. Статус open.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #188

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

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

128. Сообщение от Аноним (128), 07-Июн-22, 22:11	+/–
> А про TCP ты забыл, да? В TCP точно так же теряется и нужно перепосылать. И нет, это будет другой пакет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #173

129. Сообщение от Аноним (128), 07-Июн-22, 22:16	+/–
> поддержка UDP некоторыми сетями Broken by design сети совершенно никого не интересуют. > отсутствие вменяемого механизма противодействия ддос С точки зрения защиты от DDoS, нет разницы между TCP и UDP. Я тебе это говорю как отпахавший over 10 лет на телеком в отделе защиты от DDoS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #143

130. Сообщение от Аноним (128), 07-Июн-22, 22:18	+1 +/–
> Расскажи зачем тебе мгновенное открытие глагне? А вот и ненужнисты подъехали. Тебе не нужно — не пользуйся. Всё просто!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

131. Сообщение от Аноним (128), 07-Июн-22, 22:38	+/–
> Он не владеет терминологией и смутно знает о том, для чего какой стандарт. > Я предположу, что кэшированием TLS он называет PSK из TLS 1.3 %) Нет, кэшированием TLS-сессий я называю… кэширование TLS-сессий. Тебе не приходилось в процессе ОВЛАДЕВАНИЯ терминологией сталкиваться с RFC5077?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #136

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

133. Сообщение от Аноним (128), 07-Июн-22, 23:00	+/–
Я по видео в браузере научился: 1. ремонтировать и обслуживать автомобиль — менять масло, свечи, колёса, бортивать, пользоваться балансировщиком, дебажить проводку 2. водить автомобиль в тех условиях, про которые не учат в автошколе — экстремальные/неблагоприятные погодные явления, выход из заноса, комфортная езда в трафике/по городу, экономичная езда на большие расстояния, буксировка, езда с прицепом 3. парковать автомобиль с минимальными зазорами под любым углом, с прицепом и без 4. завязывать пояс так, чтобы при спраррингах не развязывался 5. разогреваться перед тренировкой и растягиваться после 6. всей базовой дерево- и металлообработке, вручную и с помощью инструмента 7. возводить простые конструкции из деревянного бруса 8. ухаживать за отдельными деревьями и за лесом в целом 9. тушить бытовые пожары подручными средствами 10. водить фуру (13 передач, охренеть) 11. водить трактор и пользоваться навесным оборудованием 12. прицельно стрелять из пистолета, ружья и винтовки Это из того, что вот прямо с ходу в голову пришло. Про бесплатные лекции ведущих универов мира по любым предметам наверное и вовсе не стоит говорить — это, видимо, вовсе для вирусов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #147, #167

134. Сообщение от YetAnotherOnanym (ok), 07-Июн-22, 23:03	+/–
> Нука, расскажи как правильно надо передавать видеопоток по сети? https://www.rfc-editor.org/rfc-index.txt Поиском по текстовому файлу пользоваться умеешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

135. Сообщение от Аноним (128), 07-Июн-22, 23:04	+/–
Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #169, #250

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

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

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

139. Сообщение от suffix (ok), 07-Июн-22, 23:43	+/–
О каком развитии tcp Вы говорите если даже tcp fast_open выпилили из ВСЕХ браузеров ? Ну поддерживает у меня сайт tcp fast_open и я отслеживаю подключения с использованием этой фичи - так вот 2 (ДВА) раза за последний год это случилось. Разумеется могу curl-ом с соответствующими ключами дёргать свой сайт и затем тащиться в Wireshark как быстро у меня повторные соединения происходят (0-RTT early_data  тоже включено разумеется) :)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #152

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

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

142. Сообщение от Аноним (142), 08-Июн-22, 00:32	+/–
>Пакет не может потерять САМ СЕБЯ. Ага, вот деньги (бюджетные) могут терять сами себя, а пакеты, значит, не могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

143. Сообщение от keydon (ok), 08-Июн-22, 01:13	+1 +/–
> С точки зрения защиты от DDoS, нет разницы между TCP и UDP. > Я тебе это говорю как отпахавший over 10 лет на телеком > в отделе защиты от DDoS. В телекоме мб и нет разницы, а в остальных отраслях разные ддосы бывают, не только на исчерпание полосы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #207

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

145. Сообщение от Аноним (175), 08-Июн-22, 01:39	+/–
Смысла шифровать общедоступные видео мало. Шифрование абсолютно ничему не помешает, но съест уйму вычислительных ресурсов и у зрителей и у гугла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #160

146. Сообщение от Ivan_83 (ok), 08-Июн-22, 04:32	+1 +/–
Какие проблемы то? В начале браузеростроители ограничивают количество TCP соединений типа чтобы сервера не перегружать, а потом гуглы от скуки изобретают квик, где типа по одному соединению всё передаётся, просто хитро мультиплексируется. А суть то в том, что они эти самые 100500 TCP соединений упихнули внутрь своего udp, и теперь сравнивают и делают выводы. На практике они конечно добились эффекта, но не за счёт мультиплексирования "каналов" внутри, а за счёт того что срезали все лишнее что им было не нужно и поменяв приоритеты. Те был TCP, потом с помощью TLS его сделали секурным и не сломали ничего. Тут пришёл гугл и сказал что у нас тут шифрование, потому пакеты должны ходить теперь только так, и вот благодаря этому вравниваю размера пакетов у нас профит. И так во всём. Но по сути их работа не добавила ничего нового и не создала новых ценностей. Вот DHT, uTP - добавили и создали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #165, #224

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

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

149. Сообщение от Аноним (148), 08-Июн-22, 06:20	+/–
> т.е. в ... символ CR может применяться только вместе с символом перевода строки (CRLF) о, виндозные \r\n подвезли, красота
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #161, #189, #264

152. Сообщение от timur.davletshin (ok), 08-Июн-22, 06:30	+1 +/–
Какое отношение браузеры имеют к TCP?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #155

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

155. Сообщение от suffix (ok), 08-Июн-22, 06:36	+/–
А, так Вы о сферических конях в вакууме писали - ну тогда понятно. Практическое применение если не интересует, то тогда да - tcp развивается :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #157

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

157. Сообщение от timur.davletshin (ok), 08-Июн-22, 06:47	+1 +/–
> А, так Вы о сферических конях в вакууме писали - ну тогда > понятно. Браузер не реализует никакую часть из TCP, тот же multipath и congestion control активно пилят и оптимизируют. Другой вопрос совершенно в прикладном софте. Про тот же ECN я писал выше, реализовано и отлажено уже чёрт знает сколько лет, действительно полезная вещь, но убедить включить её в роутерах нереально. Microsoft и их страдания по TCP timestamp'ам вторым примером... > Практическое применение если не интересует, то тогда да - tcp развивается :) Ну, например, вкатили всем TCP hybrid start, сколько человек об этом знает и заметило? Однако же очень полезная вещь, которая исправляет один из родовых недостатков TCP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #308

158. Сообщение от Аноним (158), 08-Июн-22, 06:50	+/–
https://ntc.party/t/http-3-quic/1823
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #159

159. Сообщение от timur.davletshin (ok), 08-Июн-22, 06:53	–2 +/–
> https://ntc.party/t/http-3-quic/1823 Простите, а какое отношение к этому имеет РКН? Или теперь всё по логике "Кошка бросила котят - это Путин винован. А пятого, пархатого, спасла Чулпан Хаматова"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

160. Сообщение от www2 (??), 08-Июн-22, 07:21	+/–
>Шифрование абсолютно ничему не помешает Помешает узнать что этот конкретный клиент смотрит это конкретное видео. С шифрованием можно узнать только то, что этот конкретный клиент смотрит какое-то видео.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #174

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

162. Сообщение от onanim (?), 08-Июн-22, 07:38	–2 +/–
какой-нибудь Intel Quick Assist
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #163

163. Сообщение от timur.davletshin (ok), 08-Июн-22, 08:56	+/–
> какой-нибудь Intel Quick Assist Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #269

164. Сообщение от lockywolf (ok), 08-Июн-22, 09:43	–2 +/–
Отлажены, отполированы, но не работают. И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, они всегда будут что-нибудь портить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #166

165. Сообщение от lockywolf (ok), 08-Июн-22, 09:45	+/–
> Какие проблемы то? Проблема в том, что скорость потока зависит от процента потерь пакетов (обратно) экспоненциально (тогда как должна линейно). А в мире есть миллиарды человек, которые сидят на соединениях, у которых 30-40% потерь -- норма жизни. >Вот DHT, uTP - добавили и создали. Они легко детектируются и банятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #297

166. Сообщение от timur.davletshin (ok), 08-Июн-22, 09:48	+1 +/–
> И работать не будут. Пока промежуточные роутеры знают что-нибудь про состояние потока, > они всегда будут что-нибудь портить. Простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? Просто интересуюсь, как вы представляете их работу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #185

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

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

169. Сообщение от YetAnotherOnanym (ok), 08-Июн-22, 11:23	+/–
> Про фаерволл слыхал? Он у тебя «Брандмауэр» называется ещё. В моём зоопарке он по-разному называется. В том числе и "Брандмауэр". И что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #219

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

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

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

173. Сообщение от Ан (??), 08-Июн-22, 12:29	+/–
>> А про TCP ты забыл, да? > В TCP точно так же теряется и нужно перепосылать. И нет, это > будет другой пакет. Это будет тот же payload. И не придуривайся, что ты не понял, о чём речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #206

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

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

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

177. Сообщение от Аноним (177), 08-Июн-22, 13:32	+1 +/–
Зачот!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

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

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

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

181. Сообщение от Аноним (181), 08-Июн-22, 14:33	+/–
> браузерами Почему во множественном числе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #324

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

183. Сообщение от Ся (?), 08-Июн-22, 17:59	–1 +/–
Ругаться - ругать себя? (На деле непереходный глагол со значением взаимности) Обмануться - себя обмануть? (Непереходный глагол со значением страдательности)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #210

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

185. Сообщение от lockywolf (ok), 08-Июн-22, 19:49	–1 +/–
>простите, а какое отношение congestion control и selective acknowledgment имеют к роутерам? > Просто интересуюсь, как вы представляете их работу. Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по дороге с большой вероятностью дропает коннект. Не говоря уже о том, что когда коннект выглядит нетипично на DPI, его приоритизируют ниже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #187

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

187. Сообщение от timur.davletshin (ok), 08-Июн-22, 20:26	+/–
> Если количество пакетов не совпадает с количеством ack'ов, один из NAT'ов по > дороге с большой вероятностью дропает коннект. Мне вот тут интересно стало, а что такое в твоём понимании TCP window scaling? > Не говоря уже о том, что когда коннект выглядит нетипично на DPI, > его приоритизируют ниже. Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще режут на первом же хопе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #190

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

189. Сообщение от мяя (?), 08-Июн-22, 23:30	+1 +/–
Они не "виндозные". > 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, протоколах Интернет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #221, #293

190. Сообщение от lockywolf (ok), 09-Июн-22, 04:08	–1 +/–
> Мне вот тут интересно стало, а что такое в твоём понимании TCP > window scaling? Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится. > Бред сивой кобылы. А приоритет выражается в понижении приоритета где? В изменении > значения DSCP? Так его 4 из 5 провайдеров нижнего уровня вообще > режут на первом же хопе. Детали работы DPI не публикуются. Эмпирически приоритизация очень хорошо заметна. Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #191, #192

191. Сообщение от timur.davletshin (ok), 09-Июн-22, 06:25	+/–
> Какая-то TCP опция, которую файрволы по дороге переписывают так, как им заблагорассудится. Очень глубокое понимание работы протокола. Кстати, именно поэтому кол-во ACK'ов не совпадает с кол-вом пакетов, но на каждый пакет есть ACK! Представть, если бы в потоке в несколько десятков гигабит надо было тут же на каждый пакет отсылать ACK. Интересная бы производительность у протокола тогда была. Вот такая вот, на первый взгляд, противоречивая фигня. Вообще попробуй разобрать любую сессию в Wireshark ради примера. Сейчас многое изменилось со времён оригинального TCP и от учебника и википедии отличается )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #193

192. Сообщение от timur.davletshin (ok), 09-Июн-22, 06:30	+/–
> Детали работы DPI не публикуются. На этом можно было бы и закончить гадать... > Например, RTT на 22 и 443 порты в три раза меньше, чем на все остальные. А вы уверены, что софт, торчащий на тех портах, не генерирует задержку банально, которую вы упорно измеряете? И дело совершенно не в DPI, а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH 😄
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #194

193. Сообщение от timur.davletshin (ok), 09-Июн-22, 06:36	+/–
> которую файрволы по дороге переписывают так, как им заблагорассудится Нет в абсолютно подавляющем большинстве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #195

194. Сообщение от lockywolf (ok), 09-Июн-22, 08:46	–1 +/–
>> Детали работы DPI не публикуются. > На этом можно было бы и закончить гадать... Можете закончить, а мне нужно данные передавать. >> А вы уверены, что софт, торчащий на тех портах, не генерирует задержку > банально, которую вы упорно измеряете? И дело совершенно не в DPI, > а в том, что задержка генерируемая Nginx, закономерно отличается от OpenSSH > 😄 Я уверен, потому что я измерял задержку до RST заблокированных портов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #197

195. Сообщение от lockywolf (ok), 09-Июн-22, 08:49	–1 +/–
>> которую файрволы по дороге переписывают так, как им заблагорассудится > Нет в абсолютно подавляющем большинстве. Sweet summer child. Всё, что можно переписать, переписывается. Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #196

196. Сообщение от timur.davletshin (ok), 09-Июн-22, 09:53	–1 +/–
> Sweet summer child. Всё, что можно переписать, переписывается. А кроме как языком доказать сможешь? Ну, начнём с того же TCP window scaling (раз уж его упомянули). Я просто к чему это говорю, просто эта вещь ломает работу канала. Я даже и бородатый баг с разбором проблемы среди разработчиков ядра могу привести алаверды на доказательство твоего тезиса. > Не переписывается только то, что зашифровано, и именно поэтому quic по-умолчанию зашифрован. Что там кроме payload защифровано, сказочник? Там та же логика управления каналом, что и у TCP, только реализованo поверх UDP. Даже алгоритмы носят имена идентичные — CUBIC/Reno/BBR :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #202

197. Сообщение от timur.davletshin (ok), 09-Июн-22, 09:57	+/–
> Я уверен, потому что я измерял задержку до RST заблокированных портов Жду однострочник, с нетерпением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #198

198. Сообщение от lockywolf (ok), 09-Июн-22, 11:44	+/–
>> Я уверен, потому что я измерял задержку до RST заблокированных портов > Жду однострочник, с нетерпением. Однострочники называются nping и hping3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #201, #259

199. Сообщение от Аноним (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и известно на чём).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

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

201. Сообщение от timur.davletshin (ok), 09-Июн-22, 12:05	+/–
я так и знал 😆
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #203

202. Сообщение от 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ообщить модератору
Родитель: #196 Ответы: #211

203. Сообщение от lockywolf (ok), 09-Июн-22, 12:16	–1 +/–
> я так и знал 😆 И что ты знал, болтун? Какая разница, чем слать пакеты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

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

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

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

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

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

209. Сообщение от Аноним (128), 09-Июн-22, 17:14	+/–
> можно было научиться по книгам или статьями Интернете. Машина не заводится, но ничего, родная, погоди пару дней, я книжку прочитаю, тогда и поедем детей из школы забирать. Ага. > У текста есть огромное преимущество перед видео У текста нет преимуществ перед видео (обратное тоже справедливо, впрочем). Оба полезны, оба нужны и оба используются для обучения. > Есть ещё "нюанс". Этот нюанс называется «соломенное чучело» и является инструментом демагога.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #214

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

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

212. Сообщение от Онаним (?), 09-Июн-22, 20:23	–1 +/–
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, #230

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

214. Сообщение от i (??), 10-Июн-22, 06:56	+/–
помнится когда убунта пошла в массы, инет наводнился статьями - как установить что-то на линукс, и сводился к 1 строке - "апт инсталл что-то", порой включая гайд по установки убунты того же качества. так уж вышло, что человечство генерирует больше дерьма чем чего-то другого, и большенство кроме него не генерируют ничего, толково составленная книжка, как мануал, имеет содержание и не требует почтения от корки до корки, но бывают, и даже часто, совершенно бестолковые книжки, и мануалы и видосики особенно, в стиле мама посмотри я установил убунту или покакал, непонятно. > Машина не заводится, но ничего, родная, погоди пару дней, я книжку прочитаю книжку надо читать заранее, представь себе, не машина, а самолет.. Уважаемые пассажиры, мы падаем, сейчас пилот срочно гуглит что делать, ага..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #218

215. Сообщение от Аноним (-), 10-Июн-22, 16:32	+/–
> будут теряться безвозвратно, да. Их перепошлет сама реализация QUIC. Это лучше чем уповать на кернел. Особенно когда ископаемые из эпохи диалапа думают что окей использовать попытки повтора отсылки пакета с таймаутами измеряемыми в МИНУТАХ, так что на мобильных линках с движущимися абонентами TCP творит жесточайший трэш как только покрытие отлично от идеала, а MS еще и не переубедишь сменить congestion control. Впрочем он и в linux работает так себе, даже BBR и Codel весьма компромиссные штуки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

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

217. Сообщение от Аноним (-), 10-Июн-22, 16:43	+/–
Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки на сеть. Всплеск помех выбивающий пакет в радиолинке или временная потеря сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения к нагрузке на сеть - однако это легко убивает скорость TCP до диалапных величин и даже хуже. А вот такие тупари с вон тем дизайном, не способные понять что мир немного изменился и люди хотят беспроводные сети - очень работе этих сетей вредят. И теперь их слушать никто не будет, плохая работа беспроводных сетей и жалующиеся пользователи всех достали. Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов. Поэтому у юзеров гуглобраузера будет первоклассный юзер экспериенс. А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #233, #234, #235, #236, #237, #238

218. Сообщение от Аноним (128), 10-Июн-22, 16:58	+/–
> так уж вышло, что человечство генерирует больше дерьма чем чего-то другого Откуда вы дерьмо на ютубе берёте-то? Специально ищете? > книжку надо читать заранее, Так уж вышло, что заранее я другую книжку читал, в которой написано было как заработать денег на машину и её техобслуживание, а две одновременно читать я не умею. Пришлось взять на себя оправданный риск. > представь себе, не машина, а самолет.. Зачем представлять? Зашёл к соседу и спросил у него какую книжку он читал, чтобы двигатели у A380 ремонтировать в падении. Он сказал, что название книжки дословно не помнит, но суть сводится к техникам аварийной посадки на разные поверхности. Как это относится к реалиям моей жизни, не потрудишься описать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

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

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

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

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

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

224. Сообщение от Аноним (-), 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 в чем-то похож, но мультиплексированием не занимается и заточен на именно фоновый низкоприоритетный трансфер, даже если надо немного пожертвовать скоростью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

225. Сообщение от Аноним (-), 10-Июн-22, 18:02	+/–
> P.S. вообще на самом деле нынешний CUBIC+HYSTART+SACK+ECN почти богоподобен. На мобильном линке с движущемся транспорте он подобен разве что каре господня, когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации линка. > Да, оно плохо подстраивается под внезапные увеличения в доступной пропуской способности Еще хуже когда это были соты с прорехами в покрытии и движущийся юзер, а этот кал удумал что это перегруз сети и ушел в дикие таймауты измеряемые минутами. > сетей, но я бы решал эту проблему пробросом информации из более низкого уровня. Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово. > интерпретируется как равный ECT0. А городить сложные алгоритмы (BBR - самый > сложный из congestion control'ов) в userspace... — ну такое себе. BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #226, #227, #229, #231, #239

226. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:08	+/–
> BBR таки немного получше работает и такой не от хорошей жизни. Но даже он иногда вытворяет черти что, демоенстрируя издевательскую утилизацию линка. Простите, но его даже не ради этого создавали. Я уже не говорю о том, что он и не может выдавать лучший вариант, т.к. его логика работы состоит в том, что периодически пытаться слать больше, чем лезет, и смотреть, что из этого получается. Дропы — не увеличиваем скорость, пролезло — можно больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #255

227. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:09	+/–
> Ее даже немного пробрасывают вроде, но в целом оно работает дерьмово. Протокол проброса информации в студию! А то пацаны-то не знают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #256

228. Сообщение от Аноним (228), 10-Июн-22, 18:10	–1 +/–
> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе > нюхать интернеты напрямую? При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много. И еще минус железки под нат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #291

229. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:11	+/–
> На мобильном линке с движущемся транспорте он подобен разве что каре господня, > когда ваше терпение поджаривают на медленном огне, глумясь над процентом утилизации > линка. Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации с нижележащего уровня логику определения оптимальной скорости трудно представить кроме той, что уже были реализованы (не только в CUBIC).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #257

230. Сообщение от Аноним (228), 10-Июн-22, 18:12	–1 +/–
> 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, на всякий случай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #240

231. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:13	+/–
> Еще хуже когда это были соты с прорехами в покрытии и движущийся > юзер, а этот кал удумал что это перегруз сети и ушел > в дикие таймауты измеряемые минутами. А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши её техническими терминами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #258

232. Сообщение от Аноним (228), 10-Июн-22, 18:14	+/–
> О да, теперь отслеживать пользователей будет еще проще, на уровне протокола. Что в нем такого для отслеживания чего не было в предыдущих?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

233. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:16	+/–
> Нюанс в том что в беспроводных линках пакеты теряются независимо от нагрузки > на сеть. Нюанс не в этом, что там не пакеты...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #245

234. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:20	+/–
> Всплеск помех выбивающий пакет в радиолинке или временная потеря > сигнала движущимся абонентом попавшим в прореху покрытия не имеет никакого отношения > к нагрузке на сеть - однако это легко убивает скорость TCP > до диалапных величин и даже хуже. Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до диалапных величин из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети; б) если вы не используете Reno, то восстановление произойдёт достаточно быстро. Проблема в том (основная), что бесповодная сеть меняет символьную скорость данных, подстраиваясь под условия, и эта информация никак не коммуницируется на более высокий уровень OSI.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #246

235. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:22	+/–
> А вот такие тупари с вон тем дизайном, не способные понять что > мир немного изменился и люди хотят беспроводные сети - очень работе > этих сетей вредят. Ну напиши congestion control новый, степень защитишь и на работу получше устроишься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #247

236. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:27	+/–
> И теперь их слушать никто не будет, плохая > работа беспроводных сетей и жалующиеся пользователи всех достали. Пользователи и правда в своей массе являются причиной своих же неприятностей. Это такие вот и кидают точки там, где надо тянуть кабель, врубают каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность на максимум и фсё, общий ресурс скушан... а девелоперы дураки )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #253, #295

237. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:31	+/–
> Потому и UDP, чтобы уровень ретрансмита делать без участия вот таких экспертов. Я тебя разочарую, но QUIC в реальной жизни сливает TCP — https://www.fastly.com/blog/measuring-quic-vs-tcp-computatio... И это я ещё не скидываю внутрипротокольную статистику по таким параметрам как jitter, например, где твой QUIC сливает на всех платформах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #248

238. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:36	+/–
> А у вас - это уже ваши проблемы. Если вам нравится прерывающееся видео или сайты грузящиеся > по беспроводке с издевательской скоростью, вы этим "счастьем" и наслаждайтесь. Ну шта, шта ты несёшь? История вообще не про это. Но, если тебя интересует, то данные о том, чем козырял гугл в оригинальной презентации, с данными о QUIC+BBR не пинал только ленивый. В реальной жизни они просто не подтверждались, а BBR просто за счёт агрессивности выигрывал полосу у конкурентов. Кстати, именно поэтому от него и отказались и начали пилить BBRv2, который из беты не вылезает уже пару лет (уточни, просто новостей о нём особых нет), а для себя Google изобрёл какой-то третий алгоритм, который в профильной литературе иногда называют BBRv1.5. Но некоторые вьюноши, начитавшись восторженных статей на medium у таких же, как и они, продолжают "дрочить" после прописывания net.ipv4.tcp_congestion_control=bbr даже не имея возможности провести качественную оценку полученного результата. Но тут проблема психологическая, если им это помогает с ними, проблемами, справляться, то... почему бы и нет )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #249

239. Сообщение от timur.davletshin (ok), 10-Июн-22, 18:43	+/–
> ... подобен разве что каре господня (-ня? -ней?), когда ваше терпение поджаривают на медленном огне, глумясь... Вы чёрта в Господом даже умудрились спутать )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #296

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

241. Сообщение от Онаним (?), 10-Июн-22, 20:10	+/–
Ещё посмотрим как оно себя будет вести, когда это будут заливать старт-пакетами 0-RTT.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #242, #243

242. Сообщение от Онаним (?), 10-Июн-22, 20:12	+/–
(запрашиваешь один коннект, считаешь ключи, заливаешь 10 гиг 0-RTT, профит?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

243. Сообщение от Онаним (?), 10-Июн-22, 20:13	–1 +/–
Ну и 2x-3x хендшейк для амплификации не очень хорошо, но всё же имеется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

244. Сообщение от InuYasha (??), 10-Июн-22, 23:21	+1 +/–
> "Я не виноват, я выполнял приказ"? "А довольно улыбаетесь при этом вы тогда по какой инструкции?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

245. Сообщение от Аноним (-), 11-Июн-22, 00:58	+/–
> Нюанс не в этом, что там не пакеты... Кэп намекает что с точки зрения TCP/IP вообще есть только пакеты и rtt. Да и беспроводные линки так то packet-switched сети в основном. В каких-то случаях это может называться в другом протоколе фреймом и проч, но суть дела не меняет. А раскручивать абстракции до I/Q модуляторов мы все же не будем: TCP/IP это вообще не видно. С его точки зрения - вон то. и это, в какой-нибудь вафле пакеты довольно похожи на обычный эзернет, так то, если на физический уровень забить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233

246. Сообщение от Аноним (-), 11-Июн-22, 01:16	+/–
> Нет, потеря одиночного фрейма и даже нескольких не вызовет падения скорости до > диалапных величин Красивая теория, но своему снифферу я доверяю больше чем какому-то эксперту опеннета с стремным уровнем квалификации. > из-за: а) контроль чётности и коррекция ошибок есть на уровне протокола беспроводной сети; Кэп намекает что для TCPIP результат бинарный: протоколы под ним или выдюжили, или нет. Для TCP пакет или доставлен корректно, или нет. При том тот всплеск "не выдюжили" во первых может быть рандомный. Во вторых не связан с "congestion" и - просто не повод к снижению скорости TCP потока, о великий эксперт! Некоторые, типа CDG и BBR даже пытаются какой-то эвристикой это определять, но получается довольно компромиссно и к тому же это 2-сторонняя игра. Еще можно выпасть на цать секунд из сети если прореха в покрытии. Хэндовер при этом не удается и модем довольно долго ищет сеть, регается в ней, и в целом это может выбить из сети на ...цать секунд. За это время TCP обычно успевает конкретно обидеться на недоставку пакетов и проапгрейдить легкий вылет до доброй минуты полного дауна. И например в реалтайм чатике в чем-то движущемся сие например подбешивает. > б) если вы не используете Reno, то восстановление произойдёт достаточно быстро. То-есть ss кажущий как кернел лихо отсчитывает добрых 60 секунд на перепосыл пакета был моим глюком? Да ладно? :) > Проблема в том (основная), что бесповодная сеть меняет символьную > скорость данных, подстраиваясь под условия, и эта информация никак > не коммуницируется на более высокий уровень OSI. И это тоже. Впрочем вон там packet loss кой-как пытаются классифицировать - всплеск ли это или глобальный аут но честно говоря получилось оверинженернутое УГ которое навороченое но работает не особо хорошо и все-равно дурит временами. А в сабже кстати у гугли есть идея и свой FEC делать - так то можно пролюбить 20% пакетов, починить это FEC - и хотя линк дурил, юзер этого вообще не увидит. А, представляете, FEC можно так то interleave'ить и комбинировать и это сильно улучшает надежность ценой некоторой потери скорости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234

247. Сообщение от Аноним (-), 11-Июн-22, 01:20	+/–
> Ну напиши congestion control новый, степень защитишь и на работу получше устроишься. Да вон сабж уже написали. К тому же его гугл доставит ВСЕМ. И мне и даже тому ламеру с виндой. И вообще, это тот случай когда гугл явно нанял нормальных инженеров а не вебмакак или ретардов "мытакпривыкли, диалап рулит". Сделано с кой-каким пониманием проблематики и относительно осмысленным заруливанием оной. То что у меня сильно лучше получится не факт, а TCP с его congestion трогать я бы вообще лишний раз трогать не стал. Неудобно марафон в ластах бегать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235

248. Сообщение от Аноним (-), 11-Июн-22, 01:24	+/–
> Я тебя разочарую, но QUIC в реальной жизни сливает TCP Мне достаточно того что я в реальной жизни порой вижу как TCP ПОЛНОСТЬЮ ВЫРУБАЕТ ПОТОК ДАННЫХ НА МИНУТУ при довольно скромных отклонениях от идеала, особенно в чем-нибудь движущемся, и этот булшит творится уже цать лет, чего достаточно для искреннего пожелания нехороших вещей всем к этому причастным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

249. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #238 Ответы: #266

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

253. Сообщение от Аноним (-), 11-Июн-22, 01:43	+/–
> Пользователи и правда в своей массе являются причиной своих же неприятностей. Это > такие вот и кидают точки там, где надо тянуть кабель, врубают > каналы 40MHz в диапазоне 2.4GHz и 160MHz в 5GHz, выкручивают мощность > на максимум и фсё, общий ресурс скушан... а девелоперы дураки ))) Ну и как я протяну кабель тому поезду заезжаюшему под мост? Или почему у меня из-за вылета физики на 10 секунд поток данных на уровне TCP долежн потом стоять раком минуту? Потому что это угробище дизайнили гении с весьма абстрактным видением ситуации? Ну а гугл вот может нанять тех кто сделает "как лучше работает для большей части юзеров" вместо этого всего. Это хорошо и правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

255. Сообщение от Аноним (-), 11-Июн-22, 01:53	+/–
> Простите, но его даже не ради этого создавали. А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло. И настало время решений которые смогут нормально работать и в вон тех случаях. О чем и сабж. > его логика работы состоит в том, что периодически пытаться слать больше, > чем лезет, и смотреть, что из этого получается. Дропы — не > увеличиваем скорость, пролезло — можно больше. И все же... 1) BBR иногда начинает иметь довольно странное мнение о доступном бандвизе линка. Вероятно, его тайминги неудачно стыкуются с перетурбациями линка, или типа того, но он может упереться рогом и юзать целые 20-30% бандвиза. Многопоточные качалки получают +1 пойнт... 2) Даже он иногда может уйти в конские таймауты без должного основания. Видимо тоже случается хрень типа того что вот именно в момент перепосылки - соты не оказалось/пакет выпал, и неплохой в целом линк используется... да почти ни на сколько, протокол уходит в туповэйтинг. Если новую конекцию открыть - как из пушки прет, но уже существующая туповэйтит хоть там что. Сказано же, таймер на полчаса и все тут. И потом вы удивляетесь что кто-то хочет это переделать? :) Есть thin linear timeouts еще, но опять же это какая-то эвристика, довольно наркоманская, и работает она тоже весьма малопредсказуемо и криво. А висящая минуту SSH сессия так то тоже бесит, если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #274

256. Сообщение от Аноним (-), 11-Июн-22, 01:58	+/–
> Протокол проброса информации в студию! А то пацаны-то не знают. Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра. И это, у разных протоколов достаточно разные понятия бывают, их все под 1 гребенку насчет проблем физического уровня причесать так то не очень просто. И какого-то устоявшегося механизма "для всех" нет. Более того - какой-нибудь сотовый модем это в стандартном виде вообще не отдает обычно, ну вот нет устоявшегося интерфейса для этого. Если я любопытный то конечно vendor cmd и прочей отладочной статистикой увижу и уровень сигнала в -dBm, и snr, и что там еще, но вот кернель про это все не очень в курсе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227 Ответы: #273

257. Сообщение от Аноним (-), 11-Июн-22, 02:04	+/–
> Проблема в том, что ничего лучшего нет, т.к. при отсутствии проброса информации > с нижележащего уровня логику определения оптимальной скорости трудно представить кроме > той, что уже были реализованы (не только в CUBIC). Я вообще не представляю себе логику определения скорости линка когда я чешу в поезде и SNR и вообще наличие сот плавает в широком пределе и быстро. ИМХО там только быстрый агрессивный адаптив сможет что-то вменяемое делать. В принципе CDG и BBR как я понял пытаются ловить перегруз линка по росту RTT. Но это у них довольно криво получается, лажа все равно иногда выходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #271, #272

258. Сообщение от Аноним (-), 11-Июн-22, 02:09	+/–
> А как ты себе представляешь обработку такой ошибки? Просто пофантазируй и опиши > её техническими терминами. В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет. И в конце концов стремиться надо к чему-то такому. Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких. Но даже он иногда делает фиг знает что, у кернела свои заскоки насчет TCP, а юзерам windows этот BBR вообще не раздашь нифига в их маздайный кернел. Я вообще не знаю умеет ли маздайный кернел в разные алгоритмы congestion control.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #270

259. Сообщение от Аноним (-), 11-Июн-22, 02:12	+/–
> Однострочники называются nping и hping3. Хорошие, кстати, однострочники если хочется потыкать пакеты палочкой в нестандартном виде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

260. Сообщение от Аноним (-), 11-Июн-22, 02:16	+/–
> Слишком новый и модный. Должен быть gopher. Да ладно, может HTTP/0.9 вас устроит? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #300

261. Сообщение от Аноним (-), 11-Июн-22, 02:19	+/–
> HTTP/2, который бинарный и стиле systemd, уже давно работает. TLS так то тоже бинарный. Как впрочем и TCP. А текстовость HTTP1.x в паре с немного разным пониманием теми и этими одного и того же позволяет море лулзов когда атакующий умудряется вклинить что-то лишнее и начинаются эпические приколы типа request smuggling и desync во всех его ипостасях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

262. Сообщение от Аноним (-), 11-Июн-22, 02:22	+/–
> 67 во внешку смысл забанить всегда есть, зачем плодить? Да и себе его забань. Если кто сильно умный, статику настроит, остальные отдохнут от интернета, по крайней мере V4. > 53 - только по индивидуальной просьбе. Именно поэтому на 53 удобно вешать vpn-ы всякие, они так забавно прорубаются через фаеры, наты, гостевые-демо-неоплачено доступы и прочую лабудень :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240 Ответы: #267

264. Сообщение от Аноним (-), 11-Июн-22, 02:25	+/–
> о, виндозные \r\n подвезли, красота Не очень понятно зачем - лишний байт почем зря в протоколе который так то не текстовый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

265. Сообщение от Аноним (-), 11-Июн-22, 02:27	+/–
> Насколько я помню, в текстовых протоколах всегда так было. Но сервер должен > быть терпим к кривым клиентам и требователен к себе, поэтому обычно > от клиентов принимаются и запросы, не совсем соответствующие стандарту. Если почитать новости опеннета, недавние и не очень, можно узнать что жизнь довольно жестко научила многих быть придирчивее к клиентам. Иначе они начинают request smuggling затевать, фронт и бэк начинают видеть мир по разному, а дальше хацкеры делают что хотят...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

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

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

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

269. Сообщение от onanim (?), 11-Июн-22, 18:41	+/–
>> какой-нибудь Intel Quick Assist > Ты действительно полагаешь, что он имеет какое-то отношение к TCP/UDP или HTTP? * какой-нибудь аналог Intel Quick Assist
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

270. Сообщение от timur.davletshin (ok), 11-Июн-22, 19:02	+/–
> В идеале - качаем данные на полной скорости линка пока он есть, на лету адаптируясь к ее изменениям, быстро, реалтаймно. Ну и не качая пока линка нет. Собственно ты словами и описываешь классический алгоритм. Задайся вопросом о том, как алгоритм может знать о скорости линка вслепую, без проброса этой информации снизу. Поверь, там уже далеко ушло от твоего понимания данного вопроса. Почитай потом, например, про проблему медленного старта (это название этапа, если что) и как её пытается решить гибридный старт (а это алгоритм). А дальше, если поймёшь вышеозначенное, уже сам начнёшь читать. > Ну вот "агрессивный" BBR к этому немного ближе ретарднутых уродов типа кубиков всяких. Как думаешь, долго можно оставаться нахалом в очереди? Вот так и BBR будет оставаться агрессивным ровно до тех пор, пока коса его агрессивности не столкнётся с аналогичным потоком BBR. Странно, но реальные тесты BBR показывают, что он - говно. Он обгоняет Cubic процентов на 10% только на длинном пинге c увеличенным дропом. Во всех остальных он безбожно сливает (но, оговорюсь, держит низкий пинг при максимальной для него нагрузке). В локальной сети при пинге 1 мс он проседает процентов на 30%! Можешь с лёгкостью проверить это у себя дома, благо tcp_bbr.ko есть сейчас у всех десктопных Линуксов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #280

271. Сообщение от 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ообщить модератору
Родитель: #257 Ответы: #279

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

273. Сообщение от timur.davletshin (ok), 11-Июн-22, 19:23	+/–
> Не знаю можно ли называть протоколом кучу эвристики и кой-какие сведения от линуксного ядра. Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости физического линка. Делать это никто не хочет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #278

274. Сообщение от timur.davletshin (ok), 11-Июн-22, 19:26	+/–
> А мне похрен. Если протокол не покрывает столь базовый и массовый кейс, его время в том качестве явно вышло. У тебя каша в голове. Протокол - IP, а BBR, на который ты так наяриваешь, это алгоритм управления перегрузками (congestion control), который был реализован для TCP и для UDP/QUIC. Всё. Но вообще, ты будешь жрать то, что тебе дают, ибо мнения тех, кто не понимает такой разницы, даже и мысли не проскакивает, чтобы спросить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #277

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

276. Сообщение от Аноним (-), 12-Июн-22, 00:29	+/–
> Болтун с нулевыми техническими знаниями в вопросе. Извини, не буду утруждать себя ответом. Давно известно что если технические аргументы закончились, можно перейти на личность оппонента. Классика жанра. Заодно надежно выдает эксперта в области.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266

277. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #274 Ответы: #286, #287

278. Сообщение от Аноним (-), 12-Июн-22, 01:02	+/–
> Проброс делается не эвристикой, а просто внесением изменений в протокол IP. Надо > выделить новое поле, которое будет кодировать увеличение или уменьшение символьной скорости > физического линка. Делать это никто не хочет. А смысл этого какой? 1) Беспроводные интерфейсы сейчас довольно адаптивные, за сменой битрейта/модуляции не ржавеет, они могут чуть не попакетно менять, выжимая из линка фактически доступный в этих условиях максимум. Какая ценность значения в хидере? Вафля вообще насколько я помню может указывать конкретный битрейт например пакетам beacons "и пофиг на остальное". То-есть минимум 10 раз в секунду девайс может бросить все, сменить битрейт/модуляцию на потребную для beacon, оформить beacon и заняться дальше передачей данных. Ах да, заподозрить об этом можно просто помониторив статистику вафли или сотового модема. Но видимо это недостойное занятие для гуру. 2) Интернет вообще-то сеть, в которой я вообще-то с дофига систем коммуницирую. Допустим у меня пара десятков программ что-то делают по TCP, UDP, а может и еще чему, ICMP например. И чего в хидере вот конкретно этого данного пакета при таком раскладе писать? Бандвиз же не будет целиком вот этой вот ремоте отдан при таком раскладе. Более того - это еще и от того что будут дальше ремотные системы делать зависит. Может, половина через 5 секунд решат что накоммуницировались и отвалят. А может наоборот мег данных пульнут. Это вообще от них зависит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273

279. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #271 Ответы: #285

280. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #270 Ответы: #284, #288, #289

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

282. Сообщение от Аноним (-), 12-Июн-22, 02:39	+/–
> Ничего что все современные фаерволы имеют в своей основе NAT? Ибо нет > трансляции - нет соединения. Кто-то явно путает stateful firewall и NAT. Более того - в v6 вообще трансляция обычно экзотика. А stateful файрвол забацать вполне можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #325

283. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #267 Ответы: #292

284. Сообщение от timur.davletshin (ok), 12-Июн-22, 04:18	+/–
Ты демонстрируешь полное непонимание вопроса. > Ну вообще-то я на беспроводных линках как раз прицельно поэкспериментировал с разными и пришел к выводу что там мне больше всего нравится BBR. Ты с лёгкостью можешь нагуглить целый ряд академических работ (в том числе и от заинтересованных провайдеров), где твой тезис опровергается. Настолько безграмотную хню пишешь, что мне даже неспортивно открывать букмарки на эту тему. > И знаешь, когда чатик в поезде датыкается на минуту... Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не такой большой, покажи мне этот момент в коде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #305

285. Сообщение от timur.davletshin (ok), 12-Июн-22, 04:27	+/–
> Академики живут где-то в своих кельях, и, кажется, прогуляться с мобилкой или ноутом со сниффером банально не пробовали. В гугле же есть и хипстюки с мобилками, которые могут без обиняков сообщить обитателям келий что получился все-таки булшит. Потрудитесь полистать https://researchbank.swinburne.edu.au/file/1560d7f6-6fa3-4ad... ... теперь понимаешь, что твои тезисы на уровне шариковских?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

286. Сообщение от timur.davletshin (ok), 12-Июн-22, 04:32	+/–
> В UDP/QUIC гугол во первых сможет его рихтовать в цать раз оперативнее. Хоть в каждой версии браузера. Браузер по определению скачивает данные в основном. Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять? > Это можно оперативно раздать всяким юзерам винды и чего там еще, улучшив user experience и для них. Прожать майкрософт до внедрения BBR в ядро NT - малореально. Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему на него не перешли даже в самом HTTP/3?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #302

287. Сообщение от timur.davletshin (ok), 12-Июн-22, 04:34	+/–
> Спасибо Кэп, это подразумевалось. Правда с оговоркой что TCP/IP. Нет, милок, именно IP в данном контексте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277

288. Сообщение от timur.davletshin (ok), 12-Июн-22, 04:37	+/–
> Если любопытно - зазырь что на этот счет Minstrel делает... Я тут внезапно понял, что ты не в курсе, как коррекция ошибок в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #310

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

290. Сообщение от Kuromi (ok), 12-Июн-22, 05:45	+/–
> Софтина называется VLC и есть не только под винду :). А делается > это так: открывается поток (хоть там какой) как обычно, но врубается > еще и транскод/запись а не только вывод на дисплей. И оно > прекрасно складирует поток на винч. На мощном компе можно сразу же > и перекодировать, на маломощном лучше не стоит. Не не не, это был точно не VLC. Будь все так просто я бы запомнил. Та софтина была именно под тыринг RTSP заточена, хотя не исключаю что там могда быть какая нибудь обвязка вокруг опенсорца.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #309

291. Сообщение от Kuromi (ok), 12-Июн-22, 05:48	+/–
>> А кто тебе давал гарантии что при ipv6 твой провайдер даст тебе >> нюхать интернеты напрямую? > При v6 нет никакого смысла душиться жабой с серыми адресами, адресов много. > И еще минус железки под нат. Хех, ну ты смешной, многие провайдеры так привыкли драть по сотке в месяц за выделенный IP, что не откажутся от этого даже если адресов свободных будет больше чем атомов в галактике.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #298

292. Сообщение от Онаним (?), 12-Июн-22, 08:44	+/–
Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных клиентов были выходной точкой, но не отключать же их от DNS).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283 Ответы: #311

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

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

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

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

297. Сообщение от Аноним (128), 12-Июн-22, 18:09	+/–
> Они легко детектируются и банятся Портить вообще довольно просто. На крайний случай можно кабель вырвать вместе с портом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

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

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

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

301. Сообщение от Аноним (128), 12-Июн-22, 18:31	+/–
> на 53 вполне справляется deny для TCP И ты получаешь поломанный ДНС, который вроде обычно работает, но иногда не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #303

302. Сообщение от Аноним (-), 12-Июн-22, 21:33	+/–
> Браузер по определению скачивает данные в основном. В целом - да, но... 1) Чтобы сервер вообше что-то послал - сначала это надо запросить! Путем ОТПРАВКИ запроса. Если мы при этом туповэйтили минуту, сервер вообще не знал что мы от него хотим. Надеюсь, ты в состоянии это понять, великий эксперт? 2) Юзеры так то нынче совсем не прочь аплоадить фоточки и видео нефигового размера, и это кажется не даунлоад. 3) Внезапно сервера будут юзать вообще сразу и по дефолту какую-то сильно менее ретарднутую реализацию чем гребаный кубик и т.п. как в TCP. Так что и тут скорее всего мобильно-беспроводным будет лучше. И кстати либы всего этого будут апдейтить и твикать... явно резвее чем некоторые, особенно типа майкрософта. > Наличие убер-протокола никак не поможет серверу. Надеюсь, ты это в состоянии понять? Спасибо Капитан Очевидность. Нюанс в том что Кэп упустил пару небольших моментов. Без которых все остальное уже не важно. > Ты в курсе, что разработку оригинального BBR бросили? Даже сам Google пользуется > чем-то другим с заметно отличной логикой. Если бы он был так хорош, то почему > на него не перешли даже в самом HTTP/3? Он не "хорош" но "лучше чем другие в этом позорном гадюшнике" при натурных испытаниях в поле. И таки в линуксе он тоже вроде какой-то допатченый и затвиканый. А что там и где "бросили" я не знаю. В линукс кернеле не бросили - иначе он был бы оттуда выпилен как orphaned, вероятно. Все остальное на беспроводке рабоатет еще хуже. Что-то вменяемое может еще разве что CDG, но он временами делает какие-то очень странные вещи. BBR их так то тоже пытался делать но это починили 3-4 релиза назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #312, #320, #321

303. Сообщение от Онаним (?), 12-Июн-22, 21:55	+/–
Бывает такое, yes. Поэтому лучше конечно жёстко полисить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301

304. Сообщение от Аноним (-), 12-Июн-22, 23:26	+/–
> Касательно CDG была защищена докторская пару лет назад с описанием улучшенного алгоритма. Академы пэйперы пишут специфично. Их интересует не то что будет с юзером в поле, а доказательство что они и их тезис - офигенные. Замеры перекошены в эту сторону. Это НЕ ЕСТЬ объективная оценка свойств алгоритма. Иначе wannabe-доктор может степень не получить а это ему не катит. Поэтому в пейперах почти все офигенно. На бумаге. Так что воспринимать академовские тезисы как истину в последней инстанции может только наивный чукотский юноша. Спору нет, бывают и дельные соображения. Но читать академпубликации стоит с изрядным скепсисом. На практике все может оказаться здорово иначе. > По бенчмаркам не офигенный прорыв, но многие недостатки двухрежимного гибридного алгоритма > действительно улучшил ощутимо. Но, опять же, в реальной жизни вкатывание и > отладка их занимает годы. Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния. BBR от таких приколов более-менее пролечили, он все-равно иногда делает хрень но по крайней мере сам очухивается за обозримое время. Особенно обломно в чем-то типа VPN по TCP - CDG его может удушить до дурной скорости, а потом так и будет тупить пока не рестартанешь, но это ж линк роняет, неудобно. Ах конечно академы про такие кейсы небось не думали. Дада, впн надо по удп и проч, вон тому корп фаеру и прокси это еще расскажи. > Напомню, что настраивать надо в первую очередь ту сторону, которая отдаёт данные. Напомню, коммуникации двухсторонние. Чтобы сервер начал что-то отдавать, клиент должен запрос прислать. Иначе кто его там знает что он вообще хотел. В этом месте не совсем тупые персонажи начнут догадываться почему столько внимания числу RTT до начала передачи данных а еще более сообразительные осознают и проблему head of line blocking. > Если ты у себя настроишь свой любимый BBR, то результата для клиентской машины > будет чуть больше нуля. Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #317, #318, #319

305. Сообщение от Аноним (-), 12-Июн-22, 23:34	+/–
> Ты демонстрируешь полное непонимание вопроса. Я демонстрирую то что увидел по факту в снифере и статистике сокетов. И если в энных ситуациях факты выглядят вот так - значит вот так. И какая разница что там в пейперах написано при этом? > Ты с лёгкостью можешь нагуглить целый ряд академических работ (в том числе > и от заинтересованных провайдеров), где твой тезис опровергается. Настолько безграмотную > хню пишешь, что мне даже неспортивно открывать букмарки на эту тему. А это не тезис и не теория. Это констатация того что я в снифере и статистике сокетов вижу. Маленький такой нюансик. > Т.е. ты хочешь сказать, что ты можешь в этот самый момент слать > UDP, а TCP в этот момент молчишь? Просто, исходник tcp.c не > такой большой, покажи мне этот момент в коде. Я хочу сказать что tcp уходит в аццкий timer, типа-борясь с типа-congestion. Которым поезд нырнувший под мост и потерявший на сколько-то секунд линк, очевидно, не является. И вот это поведение выглядит довольно идиотским. ИМХО в сабже его пролечат на корню а такие как ты будут пиндеть про "более агрессивный". А что делать, если только так адаптив к свойствам нестабильного быстро меняющегося линка околореалтаймно получается? Остальные потуги там работают как УГ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #316

306. Сообщение от Аноним (-), 12-Июн-22, 23:45	+/–
Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать. Ну и как-то в среднем по больнице больше всего понравился BBR. CDG лучше дефолтов, но увы, умеет одуревать и необоснованно душить скорость - и что хуже - не очень то вытряхиваясь из этого состояния за обозримое время. Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка? Окей! Пролюбить 70% бандвиза? Надолго? После какой-то редкой но меткой последовательности событий? Не, вот это - не окей, когда оно потом само не очень то и рекаверится. Может даже в теории это быть и не должно, а на практике это таки конкретный факап, нагибающий всю идею.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289 Ответы: #314

307. Сообщение от Аноним (-), 12-Июн-22, 23:48	+/–
> Раб божий, что ты забыл в интернете? Он просто не понял мой тонкий отсыл что TCP поверх беспроводки - это просто срань господня. С BBR немного меньшая срань, но тоже далеко не предел мечтаний.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #296

308. Сообщение от Аноним (-), 12-Июн-22, 23:51	+/–
> Браузер не реализует никакую часть из TCP, тот же multipath и congestion > control активно пилят и оптимизируют. И как, много его уже в допустим винде напилили? А то их так то довольно много и они так то тоже хотят быструю загрузку вебпаг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #315

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

310. Сообщение от Аноним (-), 13-Июн-22, 00:17	+/–
> Я тут внезапно понял, что ты не в курсе, как коррекция ошибок > в беспроводных протоколах работает, и весь твой трёп сводится фактически к этому. Ух, конечно-конечно, о великий гуру. Есть правда маленький нюансик. Я таки накодил пару небольших беспроводных линков. Даже с FEC. Это конечно не предел мечтаний, но придает пикантности твоим предъявам. А если бы ты не был столь глупым то заметил бы еще и что я так то указал две радикально разные ситуации, которые однако обе могут вбить TCP в асфальт. Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #313, #323

311. Сообщение от Аноним (-), 13-Июн-22, 00:21	+1 +/–
> Именно в DNS-запросах пытались протаскивать. Было это лет так 7-8 назад, пришлось > специфичные фильтры навешивать, чтобы заполисить (понятно, что несколько корпоративных > клиентов были выходной точкой, но не отключать же их от DNS). Оно такое даже опенсорсное есть, iodine чтоли, называлось. Работает, но медленно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #322

312. Сообщение от timur.davletshin (ok), 13-Июн-22, 02:51	+/–
> BBR их так то тоже пытался делать но это починили 3-4 релиза назад Там из заметного только механизм pacing rate изменили... Оно никак не поменяло логику алгоритма.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302

313. Сообщение от timur.davletshin (ok), 13-Июн-22, 02:53	+/–
> Коррекция ошибок на ситуации "всплеск помех" и "линк вообще вышибло т.к. поезд заехал под мост" реагирует все же довольно по разному. А на каком уровне OSI происходит коррекция ошибок? > FEC LDPE нормальные люди используют давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

314. Сообщение от timur.davletshin (ok), 13-Июн-22, 03:05	+/–
> Я вообще-то на беспроводках тупо поэкспериментировал и посмотрел что лучше всего будет работать. Люди давно поэкспериментировали в реальных и виртуальных условиях и составили карту, где BBR может выигрывать. Это линки с большим равномерно (упор на это слово) распределённым дропом с пингом выше 100 мс и скоростью физ. интерфейса 200+. В остальных случаях оно или равно Cubic или гораздо хуже его (линки со скоростью меньше 10 мс). > Пролюбить 10% бандвиза если это дает взамен что-то внятное типа уменьшения бесящих полных клинчей линка? Создать "шторм" затупов на 30+ секунд ни один из алгоритмов не может в принципе. Он может перейти в режим slow start (и это будет видно в статистике), но это как начать соединение заново (в плане вычерчивания графика скорости).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #306

315. Сообщение от timur.davletshin (ok), 13-Июн-22, 03:07	+/–
> И как, много его уже в допустим винде напилили? Вообще не в курсе, у меня вокруг разные сорта *nix'ов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308

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

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

318. Сообщение от timur.davletshin (ok), 13-Июн-22, 03:15	+/–
> Ну и вот в реальной жизни реальная имплементация CDG в линуксе умеет делать какую-то хрень и не очень то хочет рекаверится из этого состояния. Есть такая вещь в параметрах модуля backoff_factor (у реализации BSD она иначе зовётся), попробуй её понастраивать. Можешь начать со значения 1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

319. Сообщение от timur.davletshin (ok), 13-Июн-22, 03:19	+/–
> Его в идеале с обоих сторон надо - но в случае TCP это довольно трудно достичь в общем случае. Особенно если 1 из клиентов маздай какой-то. Проблемы масдая не в кубике, а в том, что там отключены tcp timestamp'ы (уточни, так ли это в последних версиях) и джиттер может привести его в состояние повышенного дропа пакетов. Но timestamp'ы и там включаются лёгким движением мыши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

320. Сообщение от 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ообщить модератору
Родитель: #302

321. Сообщение от 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ообщить модератору
Родитель: #302

322. Сообщение от Онаним (?), 13-Июн-22, 09:26	+/–
Ну, мы сами писали на средних курсах :D Под винду правда. А так - возможно оно и было, я особо не изучал, но адреса DNS-серверов китайские. Длинные псевдо-имена в сторону неких доменов, в ответ тоже неразборчивые TXT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311

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

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

325. Сообщение от pofigist (?), 27-Июн-22, 16:58	+/–
Cisco ASA же
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282

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

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