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

"Опубликована библиотека nghttp3 1.0 с реализацией протокола HTTP/3 "	+/–
Сообщение от opennews (ok), 22-Окт-23, 10:23
Доступен первый стабильный релиз проекта nghttp3, развивающего библиотеку на языке Си с реализацией протокола HTTP/3. Развиваемый тем же проектом вариант библиотеки для протокола  HTTP/2 используется в качестве основы модуля mod_http2, входящего в  состав http-сервера Apache. Наработки проекта также задействованы в утилите Curl. Код библиотеки распространяется под лицензией MIT... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59973
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от timur.davletshin (ok), 22-Окт-23, 10:23	+/–
А управление потоком там Cubic по дефолту или что?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

3. Сообщение от Аноним (3), 22-Окт-23, 10:51	+1 +/–
можно без шифрования юзать? для клиента будет проигрышь в скорости, а для сервера - выигрыш?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #22

4. Сообщение от Sw00p aka Jerom (?), 22-Окт-23, 11:14	+5 +/–
все "новое" почему-то "поверх", а не  "в корне"
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #12

5. Сообщение от Аноньимъ (ok), 22-Окт-23, 11:27	–2 +/–
Нельзя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от ИмяХ (?), 22-Окт-23, 11:29	–3 +/–
>>на языке Си Ждём новостей про очередную уязвимость, вызванную обращением к уже освобождённой памяти и позволяющую удалённо по сети выполнить произвольный код с рут-правами.
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от beck (??), 22-Окт-23, 12:06	+9 +/–
А почему не написано на безопастном Rust?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #14, #19, #20, #32, #79

9. Сообщение от Аноним (9), 22-Окт-23, 12:18	+/–
> А почему не написано на безопастном Rust? Хоть на брейнфаке пиши, я разрешаю :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от kusb (?), 22-Окт-23, 12:31	+1 +/–
Вот обычный http прост и это как раз вполне реально!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13, #24

11. Сообщение от Аноним (11), 22-Окт-23, 12:37	+/–
Потому что всё происходит из единого корня - Адам Коммон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #29

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

13. Сообщение от Хру (?), 22-Окт-23, 13:42	+/–
Да я бы не сказал, что multipart это прям просто-просто. Особенно если писать не на коленке а для прода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

14. Сообщение от НяшМяш (ok), 22-Окт-23, 13:46	–2 +/–
Есть, хоть и не завершена, но говорят, что вроде работает: https://crates.io/crates/h3/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #25, #70

15. Сообщение от Аноним (15), 22-Окт-23, 14:01	–3 +/–
Всё равно все будут использовать libcurl. Она и 1, и 2, и 3 поддерживает, и до кучи других протоколов, и прокси, и имеет всем знакомый и уже обёрнутый для всех языков API. Любая библиотека, желающая конкурировать с libcurl, должна уметь предоставлять совместимый с ней API, и при этом иметь весомые преимущества перед ней.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

16. Сообщение от Аноним (16), 22-Окт-23, 14:06	+4 +/–
ну у этой есть весомые преимущества -- через нее работает libcurl
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

18. Сообщение от OpenEcho (?), 22-Окт-23, 14:40	–1 +/–
> Синтетическая теория эволюции гласит, что все ныне живущие организмы имеют ровно одного общего предка. Ну то оно и видно, - только родственники и могут весь мир поджечь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

19. Сообщение от OpenEcho (?), 22-Окт-23, 14:50	–1 +/–
> А почему не написано на безопастном Rust? Наверное потому что не у всех складывается одолеть помесь брэйнфака с ЖС
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #21, #39

20. Сообщение от Аноним (21), 22-Окт-23, 14:57	+2 +/–
> А почему не написано на безопастном Rust? Потому что его авторам плевать на безопасность. Дареному коню в зубы не смотрят... Вот реализация на Rust, провереная Амазоном в бою: https://github.com/cloudflare/quiche Также работает бэкендом для curl, поэтому смысл в сабже есть только для других некомпетентных бракоделов, которые все делают спустя рукава и кладут болт на здравый рассудок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #33

21. Сообщение от Аноним (21), 22-Окт-23, 14:58	+2 +/–
> Наверное потому что не у всех складывается одолеть помесь брэйнфака с ЖС Поэтому именно таким кадрам нужно доверять написание критически важных библиотек, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #26

22. Сообщение от Zulu (?), 22-Окт-23, 15:09	+2 +/–
Нет. SSL неотъемлимая часть http/3 спецификации
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #27, #75

23. Сообщение от Zulu (?), 22-Окт-23, 15:09	–1 +/–
Есть там и маленький патчик от меня. Мелочь, а приятно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #71

24. Сообщение от Аноним (-), 22-Окт-23, 15:27	+/–
> Вот обычный http прост и это как раз вполне реально! На память об этом у нас полно прикольных атак типа request smuggling. Когда все типа-реально, но вот фронт и бэк нестандартно скроеный хидер понялся немного по разному, так что вот мы тут админу к его запросу левак подшили - и сервер от лица админа все сам и сделал - под дружный гогот атакующих. Что может быть стебнее чем админ забаненый своим же сервером, например?! :) Так что просто да не совсем. Особенно если пайплайнинг какой удумать (конектиться на вообще каждый мелкий запросик оверхеда очень уж дофига и создает траблы по иным линиям) и деление на фронт и бэк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 22-Окт-23, 15:29	+1 +/–
> Есть, хоть и не завершена, но говорят, что вроде работает: https://crates.io/crates/h3/ А вот еще один адепт хруста который даже не пробовал устриц - но мнение имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #85

26. Сообщение от OpenEcho (?), 22-Окт-23, 15:32	–3 +/–
>> Наверное потому что не у всех складывается одолеть помесь брэйнфака с ЖС > Поэтому именно таким кадрам нужно доверять написание критически важных библиотек, да? Проблема не языках, - вообще! А в банальном (как ни странно, но даже людям работающим с логикой - это не доходит) понимании, что для каждой работы - есть свой инструмент. Все что выше ЦПУ опкодов, - это просто абстракции, чтоб позволить любой обезьяне понять кодинг, когда кодеров становится много и они начинают делать ошибки, критические, то руководство партии дает им в лапы инструмент, который помогает не делать глупости, но обезяны на то и обезьяны, чтоб наити дыру в любой безопастности, поэтому языки не могут быть опасными или безопасными, есть просто языки с защитой от дурака (ну это они так думают, что безопасные) а есть без. Проблема то в том, что даже на безопасном языке, рано или поздно обезьяна (особенно с понтами) найдет способ напортачить (привет unsafe). Вон в Го, удобный, хороший defer придумали, и что? Даже его забывают ставить... Если поощряется кодить - "как письмо писать, - быстро", то никакой "безопасный" язык не поможет, если **логика** - внимательно не продумана
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #28, #30

27. Сообщение от Аноним (27), 22-Окт-23, 15:48	–3 +/–
> спецификации Ну так никто не же не принуждает следовать ей для внутреннего пользования. Емнип, это действительно неотъемлемая часть спецификации, но технически оно не то чтобы слишком сильно гвоздями прибито.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #52

28. Сообщение от Аноним (21), 22-Окт-23, 16:06	+1 +/–
> для каждой работы - есть свой инструмент. Да, очевидно, С - как раз свой инструмент для критически важных сетевых библиотек. CVE текут рекой десятки лет, а вы все ничему, блждат, не научитесь... Воюйте дальше против Раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #36, #42

29. Сообщение от Sw00p aka Jerom (?), 22-Окт-23, 16:15	+/–
> Потому что всё происходит из единого корня - Адам Коммон. лол, кек, а че не Ивана?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

30. Сообщение от Советский инженер (ok), 22-Окт-23, 16:22	–1 +/–
>Проблема не языках, - вообще! >Если поощряется кодить - "как письмо писать, - быстро" Если ты тут не видтишь противоречия, то да, проблема в тебе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #47

31. Сообщение от Аноним (25), 22-Окт-23, 16:42	+2 +/–
> Есть там и маленький патчик от меня. Мелочь, а приятно. Спасибо вам, сэр!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

32. Сообщение от Аноним (32), 22-Окт-23, 16:47	+2 +/–
Потому, что на Расте уже написано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

33. Сообщение от Аноним (25), 22-Окт-23, 16:55	–3 +/–
> есть только для других некомпетентных бракоделов, которые все делают > спустя рукава и кладут болт > на здравый рассудок. Ну вот ты и используй какое-то куищще от клаудспайвари. А как по мне - чтобы иметь дело с клаудспайварью надо именно потерять рассудок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

36. Сообщение от Аноним (36), 22-Окт-23, 17:41	–2 +/–
Дак в расте все те же самые дыры. Раст ведь это не настоящий ЯП, он транслируется в llvm-представление, которое затем уже компилится в ассемблер, а далее - в опкоды. И вот этот LLVM написан на небезопасном дырявом C++ и весь код на расте собирается этим кривым дырявым LLVM, во время сборки добавляются переполнения, выходы за границы, use-after-free и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #40, #56

37. Сообщение от анонист (?), 22-Окт-23, 17:44	–1 +/–
большие проекты на сишке это ад; раст реально тема, проигрался тут в playground, очень приятно удивлен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #119

39. Сообщение от анонист (?), 22-Окт-23, 17:47	+/–
ты хотя бы зайди на официальный сайт раста да посмотри на него прежде чем ерунду писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #45

40. Сообщение от анонист (?), 22-Окт-23, 17:49	–2 +/–
поэтому настоящие советские программисты с профильным инженерным образованием считают ассемблер непозволительной роскошью — они вручную намагничивают участки жёсткого диска
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #146

41. Сообщение от Аноним (-), 22-Окт-23, 18:01	–1 +/–
> А управление потоком там Cubic по дефолту или что? Боже упаси от этого куска фекалий мамонта. Это половина причин по которым оно вообще существует. Если в линух еще можно протолкать более вменяемые планировщики типа bbr, делающие что-то более разумное на беспроводке - то вот в винду это прожать даже гуглу было слабо. И это проблема. Потому что TCP на lossy, нестабильном или intermittent линке (например в едущем транспорте) - это полная задница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #49, #120

42. Сообщение от OpenEcho (?), 22-Окт-23, 18:06	–1 +/–
> CVE текут рекой десятки лет, > а вы все ничему, блждат, не научитесь... Воюйте дальше против Раста. Можно мне показать хоть один мой пост где я воевал против раста? Семантика языка, да, мне лично не нравится, слишком много перловских/брайнфаковских значков. Усложнение никогда не было в пользу, а вот все гениальное - обычно простое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #44

44. Сообщение от Аноним (21), 22-Окт-23, 18:21	+2 +/–
> Усложнение никогда не было в пользу, а вот все гениальное - обычно простое Да, да... Достаточно попросить сишника сложить две строки - и наслаждаться цирком, где он в портянке строк эдак на 3-6 "гениально просто" на каждый чих дергает strlen (производительность, ага), сношается с malloc и вылазит за пределы буфера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48, #50

45. Сообщение от OpenEcho (?), 22-Окт-23, 18:27	–1 +/–
> ты хотя бы зайди на официальный сайт раста да посмотри на него прежде чем ерунду писать. ерунда - это обилие значков :: [] <> которая больше похоже на опкоды чем на понятный человеческий язык. Я еще промолчу про не закрыте апострофи, которые десятилетиями всегда должны были идти в стэйт машине парами. Это правда читаемо для нормального человека?      let debilko.iter().map(|z|z*4).collect::<Vec<_>>() Попробуй не програмировать на этом годик и удивись через год - "а что это ?" Лет 40 назад это было очень "круто" у C-шиков понаписать подобную хрень типа      int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hello, world!\\ n",'/'/'/'));}read(j,i,p)void*i;{write(j/p+p,i---j,(int)i/(int)i);} и чувствовать как они круты, теперь же это - просто ржавый язык, но с тем же подвохом - тяжесть и стоимость сопроводиловки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #54, #58, #60, #78, #82, #147

47. Сообщение от OpenEcho (?), 22-Окт-23, 18:31	+/–
>>Проблема не языках, - вообще! >>Если поощряется кодить - "как письмо писать, - быстро" > Если ты тут не видтишь противоречия, то да, проблема в тебе. А можно как  Советский инженер  - бывшему sоветскому инженеру обьяснить, а в чем противоречие? (Я понимаю, что иногда быстро пишу и смысл теряется, но не воткну - где же здесь моя проблема?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #77

48. Сообщение от OpenEcho (?), 22-Окт-23, 18:34	–2 +/–
> Да, да... Достаточно попросить сишника сложить две строки - и наслаждаться цирком, > где он в портянке строк эдак на 3-6 "гениально просто" на > каждый чих дергает strlen (производительность, ага), сношается с malloc и вылазит > за пределы буфера. Причем здесь сишники и ржавые??? Ты уверен что по русски понимаешь что написанно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

49. Сообщение от timur.davletshin (ok), 22-Окт-23, 18:36	+3 +/–
Вы только по воскресеньям обдолбанный или всегда? В подавляющем большинстве реализаций Quic используется Cubic. А от BBR давно отказался даже Google (в Chrome тоже Cubic, в Mozilla Cubic). BBRv1 коряв, не дружит с ECN, катастрофически проседает на WiFi из-за того, что pacing мешает агрегации MTU, и только Анонимусы всё ещё его педалируют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #51

50. Сообщение от Аноним (50), 22-Окт-23, 18:48	–5 +/–
сложение - это операция над числами. любой язык который складывает строки - помойка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

51. Сообщение от Аноним (-), 22-Окт-23, 18:57	–2 +/–
> Вы только по воскресеньям обдолбанный или всегда? В подавляющем большинстве реализаций > Quic используется Cubic. А от BBR давно отказался даже Google (в > Chrome тоже Cubic, в Mozilla Cubic). BBRv1 коряв, не дружит с > ECN, катастрофически проседает на WiFi из-за того, что pacing мешает агрегации > MTU, и только Анонимусы всё ещё его педалируют. Гугол в mainline ядра уже давно запушил нечто, что уже точно не v1 в его изначальном виде. И в либах от гугли что угодно но не кубик в чистом виде. А ваш кубик в его изначальном варианте - и как он в ядре только на помойку вынести. Он на wi-fi при малейшей потере пакетов падает до диалапной скорости. И на мобильных линках - тоже. А если это на ходу, когда соты то видно то нет - там вообще скорость начинает в байтах в час измеряться. С утилизацией канала в 1% уже за спасибо. Гугл bbr не от хорошей жизни сделал, и если отпустить ручник, его патчили и в ядре, и сам гугл переделывал его у себя. И если гугл "отказался" от него - то как он тогда сделал v2 и v3?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #63, #66

52. Сообщение от Аноньимъ (ok), 22-Окт-23, 18:57	+/–
Для внутреннего использования оно нафиг не надо. А http3 без quick - это внезапно http2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #55

54. Сообщение от Аноним (55), 22-Окт-23, 19:16	–1 +/–
> Это правда читаемо для нормального человека? > let debilko.iter().map(|z|z*4).collect::<Vec<_>>() Даже не знаю где вы такое видели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

55. Сообщение от Аноним (55), 22-Окт-23, 19:25	–1 +/–
А ассемблер без event loop это внезапно просто ассемблер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #57

56. Сообщение от Аноним (21), 22-Окт-23, 19:27	+3 +/–
> во время сборки добавляются переполнения, выходы за границы, use-after-free и т.д. Пришло время офигительных историй...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #81

57. Сообщение от Аноньимъ (ok), 22-Окт-23, 19:28	+/–
> А ассемблер без event loop это внезапно просто ассемблер. Сумасшедший без сумасшедшего дома внезапно просто сумасшедший.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #145

58. Сообщение от Sw00p aka Jerom (?), 22-Окт-23, 19:30	+1 +/–
>больше похоже на опкоды рядом даже не лежали :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

60. Сообщение от Аноним (21), 22-Окт-23, 19:39	+1 +/–
> ерунда - это обилие значков :: [] <> которая больше похоже на опкоды чем на понятный человеческий язык. Так может есть некая причина, зачем все эти знаки добавили? Или у вас традиционное "не понял я, но  дураки при этом все остальные".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #62

62. Сообщение от scriptkiddis (?), 22-Окт-23, 21:16	–1 +/–
Но и ты нам тоже не обьяснишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

63. Сообщение от timur.davletshin (ok), 22-Окт-23, 21:29	+/–
Как быстро ты порвался. В ядре BBRv1, который НИ ОДНОЙ фичей не был расширен с начального релиза. А ненавистный Cubic, например, тем же гибридным стартом обзавёлся. BBRv2 не выпущен и скорее всего не будет даже (ткни меня в репу с BBRv3). В Quic именно что Cubic везде, притом, местами урезанный (кровь и слёзы). Мало того, Quic сливает везде TCP с тем же алгоритмом (управлять из user space трафиком накладнее). Про то, что Cubic скатывается до процентов в условиях WiFi - ЛПП. Наоборот это BBR сливает. Если мозгов не хватает самому потестировать (в драйвере Atheros есть удобная статистика по кол-ву агрегированных MTU), то можешь поискать бенчмарки. ПыСы: по бенчмаркам (и не только моим) на вафле (из того, что есть в стоке) вообще неожиданно лучше всех в категории "золотая середина между задержкой, скоростью и дропом" показывает себя старый Yeah.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #64

64. Сообщение от Аноним (-), 22-Окт-23, 21:41	–1 +/–
> It relies on an underlying QUIC stack for flow control and connection management. Нате вам на двоих, эксперты! И реализаций QUIC - уже более одной. Вы за все говорите или за какую-то конкретную? Если да - какую именно? Урл сорца? И при чем тут какие-то статистики каких-то атеросов вообще?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #65

65. Сообщение от timur.davletshin (ok), 22-Окт-23, 21:50	+1 +/–
Chrome, neqo (Firefox), nginx. Человек упомянул про беспроводные сети. Проблема в том, что это именно то место, где BBR сливает. Суть проблемы в моём первом посте - pacing ухудшает процент агрегированных MTU (MTU в беспроводных сетях больше, поэтому надо бы объединять Ethernet MTU ~1500).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #96, #123

66. Сообщение от Аноньимъ (ok), 22-Окт-23, 22:56	+2 +/–
> Он на wi-fi при малейшей потере пакетов Если у вас потеря пакетов идёт, на вайфай, то каналу связи полная Ж пришла. Никакие чудо алгоритмы транспортного уровня это никак не вылечат. Вам нужно ждать подтверждение доставки покета, и нужно перепосылать всё что не дошло. И подверждение тоже может не дойти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #68, #100, #121

68. Сообщение от timur.davletshin (ok), 22-Окт-23, 23:12	+/–
Справедливо, т.к. контроль целостности и retransmit есть в WiFi, но дроп это не лечит. Описываемый вами же сценарий тоже маловероятен, т.к. сейчас есть SACK почти у всех и подтверждения и перепосылки стали "дешевле", чем без оного расширения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

70. Сообщение от Вы забыли заполнить поле Name (?), 22-Окт-23, 23:59	+/–
> вроде работает Немножко беременна
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

71. Сообщение от Вы забыли заполнить поле Name (?), 23-Окт-23, 00:00	–1 +/–
readme поправил небось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #73

73. Сообщение от Zulu (?), 23-Окт-23, 01:02	+/–
> readme поправил небось? Нет, но не сильно круче. Потому и написал "маленький". Прекрати портить мне минуту славы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

74. Сообщение от Skullnet (ok), 23-Окт-23, 02:59	+/–
Не понимаю где этот HTTP/3 вообще юзается. https://cloudflare-quic.com/ Тут показывает, что юзает HTTP/2 даже с включенным HTTP/3 в браузере.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #87

75. Сообщение от Skullnet (ok), 23-Окт-23, 03:23	+/–
Плохо, потому что если использовать этот протокол поверх Tor/I2P или др. то получается оверхед по шифрованию, потому что сеть и так уже шифруется этими протоколами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #89

77. Сообщение от Советский инженер (ok), 23-Окт-23, 09:17	+/–
а что так трудно понять что язык как раз то и поощпяет к разным стилям и способам программтрования (кодирования) ? И это какбы поняли довольно давно. И даже наизобретали кучу языков, в том числе под конкретные задачи. Таже Ada или Erlang. да в принципе любой язык дизайнился с какой-то целью для решения определенного круга задач.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #93

78. Сообщение от Советский инженер (ok), 23-Окт-23, 09:19	+/–
>ерунда - это обилие значков :: [] <> которая больше похоже на опкоды чем на понятный человеческий язык. Cobol & PL/1 давно изобрели, но что-то как-то они не сильно популярны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #94

79. Сообщение от Bob (??), 23-Окт-23, 09:34	–1 +/–
Потом освоят $ и перепишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

80. Сообщение от Аноним (135), 23-Окт-23, 09:40	+/–
Пообновляй страницу без Shift. У меня не с первого раза грузит по quic. Но раза с третьего грузит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #90

81. Сообщение от Аноним (81), 23-Окт-23, 10:09	+2 +/–
Опеннет-специалисты (тм), чо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

82. Сообщение от Аноним (81), 23-Окт-23, 10:28	+/–
> ерунда - это обилие значков :: [] <> которая больше похоже на опкоды Выучить конкретно синтаксис - задача от силы на неделю для любого системного программиста. И я даже не про раст, а про почти любой ЯП. Если ты не способен на это, то ты или и не программист вовсе (а "комментатор опеннета по всем вопросам" (тм)), или пишешь такой трэш-код, который стыдно показать кому-либо (и совершенно не важно, на каком ЯП ты это пишешь). > чем на понятный человеческий язык ЯПы, которые выглядят как "понятный человеческий язык" существуют. И придуманы они не вчера - идея-то на поверхности. Вот только сколько из них актуальных и популярных-то? Это пока ты слюнявый и пишешь своё первый Helloworld, тебе важно чтобы были "понятные человеческие" "goto" и "label", но опытным программерам уже важнее краткость и лаконичность, отсюда в системных ЯПах появляются всякие хитрые символы, двоеточия, кавычки и т.п. Подытоживаю: ЯПы с "обилием значков" уделали в системном программировании ЯПы с "понятным человеческим языком". И под тебя, немощного, неспособного запомнить даже синтаксис (я уж не говорю, про реальное программирование), подстраиваться не будут. Ни раст, ни шишечки (сишечки). Deal with it
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #83

83. Сообщение от Sw00p aka Jerom (?), 23-Окт-23, 10:47	+/–
>ЯПы с "обилием значков" уделали лол, кек, ну вот асм как видно уделал всех, опкодов интел архитектуры свыше 1к, да прибудет с вами сила.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

84. Сообщение от Страдивариус (?), 23-Окт-23, 11:15	–1 +/–
Это что теперь? Если я пишу клиента, то мне нужно уметь ходить через HTTP/1.1, HTTP/2 и HTTP/3 и для всех этих кейсов нужно использовать три разных библиотеки? Прелестно, например!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #88

85. Сообщение от НяшМяш (ok), 23-Окт-23, 12:11	+/–
А онаним хотя бы сяшечный http3 уже попробовал, или тоже лишь бы экспертом побыть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

87. Сообщение от Zulu (?), 23-Окт-23, 12:42	+1 +/–
При первом обращении всегда идет http/1.1 (если нет prior knowledge, это отдельная история). В http/1.1 ответе может идти upgrade на http/2 и alt-svc на http/3. Если идут оба, то следующий реквест в той же коннекшне пойдет через http/2, а после ее обрыва уже на http/3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

88. Сообщение от Zulu (?), 23-Окт-23, 12:44	+/–
Можешь поддерживать только один из протоколов (http/1.1), потому как http/2 и http/3 не замещают его полностью. Ну или libcurl и не морочить мозг. Но вообще выкрик дурной. "Я пишу ОС, что мне теперь, поддерживать все железо в мире?" Ну не поддерживай, я разрешаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #91

89. Сообщение от Zulu (?), 23-Окт-23, 12:46	+/–
Использовать Тор и жаловаться на оверхед странно. Оверхед это его второе имя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

90. Сообщение от Skullnet (ok), 23-Окт-23, 13:25	+/–
Я уже всё перепробовал. Вообще результата ноль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

91. Сообщение от Страдивариус (?), 23-Окт-23, 14:12	+/–
> Можешь поддерживать только один из протоколов (http/1.1), потому как http/2 и http/3 > не замещают его полностью. > Ну или libcurl и не морочить мозг. > Но вообще выкрик дурной. "Я пишу ОС, что мне теперь, поддерживать все > железо в мире?" Ну не поддерживай, я разрешаю. libcurl - это довольно упоротая либа, которая многие вещи прячет в себя и не даёт возможности их тонкого контроля. И интерфейс у неё довольно мерзкий. Плюс ко всему, этот комбаин включает в себя миллион других не нужных мне протоколов. В идеале нужна одна библиотека только для http всех версий. В том числе нужна она для того, чтобы очередная версия HTTP получала поддержку в приложении, которое использует эту либу, нахаляву, а не дописыванием поддержки http/4, /5 и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #143

93. Сообщение от OpenEcho (?), 23-Окт-23, 17:57	+/–
> а что так трудно понять что язык как раз то и поощпяет > к разным стилям и способам программтрования (кодирования) ? > И это какбы поняли довольно давно. И даже наизобретали кучу языков, в > том числе под конкретные задачи. > Таже Ada или Erlang. да в принципе любой язык дизайнился с какой-то > целью для решения определенного круга задач. А противоречие то здесь при чем и я ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #95, #97

94. Сообщение от OpenEcho (?), 23-Окт-23, 18:00	+/–
> Cobol & PL/1 давно изобрели, но что-то как-то они не сильно популярны. Это Cobol то не популярен ??? А что-ж тогда после стольких десятилетий навалом вакансий?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #98

95. Сообщение от Советский инженер (ok), 23-Окт-23, 18:05	+/–
>> а что так трудно понять что язык как раз то и поощпяет >> к разным стилям и способам программтрования (кодирования) ? >> И это какбы поняли довольно давно. И даже наизобретали кучу языков, в >> том числе под конкретные задачи. >> Таже Ada или Erlang. да в принципе любой язык дизайнился с какой-то >> целью для решения определенного круга задач. > А противоречие то здесь при чем и я ? Я вот правильно понимаю, что ты тут делаеш морду кирпичем, и никак не хочешь признать что язык то как раз-то и очень причем на стиль кодирования. и ты же парой сообщений ниже возмущаешся обилием спец символов в некоемом языке и что  это как-то мешает при программировании?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

96. Сообщение от Аноним (-), 23-Окт-23, 18:06	+/–
> Chrome, neqo (Firefox), nginx. А это все точно к либе nghttp можно интерфейсить как "реализацию quick"? Или тут как обычно на опеннете - лишь бы блеснуть, не важно чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #99

97. Сообщение от Советский инженер (ok), 23-Окт-23, 18:07	+/–
>Проблема не языках, - вообще! >Попробуй не програмировать на этом годик и удивись через год - "а что это ?" снова никаких противаречий?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

98. Сообщение от Советский инженер (ok), 23-Окт-23, 18:09	+/–
а "навалом" это сколько в процентах? а ты лично хоть одного живого программитса на коболе знаеш?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

99. Сообщение от timur.davletshin (ok), 23-Окт-23, 18:40	+/–
> А это все точно к либе nghttp можно интерфейсить как "реализацию quick"? > Или тут как обычно на опеннете - лишь бы блеснуть, не > важно чем? Оно обязано мочь работать с ними, ибо нафиг бы такой Quic кому нужен был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #101

100. Сообщение от Аноним (101), 23-Окт-23, 18:40	+1 +/–
> Если у вас потеря пакетов идёт, на вайфай, то каналу связи полная Ж пришла. Радио - нестабильная среда по определению. Особенно если это все не в пустыне, верхом на роутере. Особенно если еще и двигаться или вертеть гаджет в пространстве. Там столько факторов что уповать на стабильность этого может оптимист или дилетант. А в мобильном интернете при езде соты появляются и пропадают с изрядной скоростью, уровень сигнала дико прыгает, есть зоны с отсутствующим покрытием, всякие мосты, тоннели, низины. В свете этого хотелось бы увидеть пруф что кто-то и правда додумался до кубика в чистом виде в QUIC. > Никакие чудо алгоритмы транспортного уровня это никак не вылечат. FEC эти чудо-алгоритмы называются. Это даже работает. До известного предела, конечно. Этот предел можно расширять, достаточно произвольно, накидывая больше избыточности. Дубовый пример: если слать каждый пакет 3 раза, даже если 1-2 пакета изредка выпадет - ну и что? То что это оверхед создает - другой вопрос. В более продвинутом FEC оверхеда меньше. > И подверждение тоже может не дойти. В случае FEC с этим даже можно жить. Если зайти на гитхаб и спросить что-то типа FEC VPN можно найти довольно странные штуки для работы по бельевым веревкам, в основном китайские, они там GFW красиво дурят. Заодно - вот - разработав довольно продвинутые протоколы. Multi-path + FEC это немного повыше уровня технологий к которому вы привыкли. А так можно было. Гугол тоже может в нормальных инженеров поэтому в QUIC была как минимум опция FEC. Стала ли она часть стандарта или это WIP до сих пор - хз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #105, #106, #107, #108, #136

101. Сообщение от Аноним (101), 23-Окт-23, 18:42	+/–
> Оно обязано мочь работать с ними, ибо нафиг бы такой Quic кому нужен был. "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так что пруфы на сорцы где вот именно эти с именно вон тем и где там именно кубик. Хочется на это лично профтыкать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #102, #104

102. Сообщение от timur.davletshin (ok), 23-Окт-23, 18:45	+/–
> "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так > что пруфы на сорцы где вот именно эти с именно вон > тем и где там именно кубик. Хочется на это лично профтыкать. https://github.com/mozilla/neqo/tree/main/neqo-transport/src/cc - нужно ещё? Поищи там гибридный старт в исходниках. Графиков накинуть, что такое гибридный старт и зачем он нужен?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #137

104. Сообщение от timur.davletshin (ok), 23-Окт-23, 19:10	+1 +/–
> "Обязано работать" вообще ничего не говорит о шедулинге пакетов и алгоритмах. Так > что пруфы на сорцы где вот именно эти с именно вон > тем и где там именно кубик. Хочется на это лично профтыкать. Сводные данные можешь поискать по "Same Standards, Different Decisions: A Study of QUIC and HTTP/3 Implementation Diversity".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

105. Сообщение от Аноньимъ (ok), 23-Окт-23, 19:34	–1 +/–
Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на границу выходите, и всё  разваливается. Но вайфай и не для того вообще... Тут кажется был раньше человек которые эти вайфаи для пром применения настраивал, от стадионов до совсем извращённой ерундой в промышленности. Мобильные сети да, в них всякая жесть бывает. Но я бы больше с ней работал через разработку приложений устойчивых к дисконекту, чем пытаясь изобрести особый стриминговый протокол устойчивый к такой жести. Переключение между сотами у вас всерано не каждую секунду происходит. > А так можно было. И это прекрасно. > Гугол тоже может в нормальных инженеров Последнее время не очень. > Радио - нестабильная среда по определению. Особенно если это все не в пустыне, верхом на роутере. Особенно если еще и двигаться или вертеть гаджет в пространстве. Там столько факторов что уповать на стабильность этого может оптимист или дилетант. Стабильность обеспечивают протоколы ниже сетевого. Потеря пакета на сетевом уровне это ситуация, в идеальном мире, всегда нештатная, независимо от среды. Хотя конечно бывают нюансы. А как вообще управление пропускной способностью происходит? По хорошему роутер должен сообщать источникам пакетов о том что у него затык, да и свитч должен, хотя к нему спроса меньше, ну не может такого быть чтобы не было такого механизма?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #109, #110, #111, #112, #139

106. Сообщение от timur.davletshin (ok), 23-Окт-23, 19:54	+1 +/–
> FEC эти чудо-алгоритмы называются. Это даже работает. Если бы ты сказал LDPC, то этот тезис можно было бы принять. Он чуть лучший результат даёт. А так ты просто в роли кэпа выступил. Дальше по тексту ты хвастаешь отсутствием понимания того, как работает коррекция ошибок и вообще, на скольки уровнях она есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #140

107. Сообщение от timur.davletshin (ok), 23-Окт-23, 19:57	+1 +/–
> Multi-path + FEC это немного повыше уровня технологий к которому вы привыкли. А где вы к этому привыкли? Я прямо хочу услышать у пана про организацию управления потоком и используемый алгоритм. Давай! Это вопрос с подвохом, сразу говорю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

108. Сообщение от timur.davletshin (ok), 23-Окт-23, 20:02	+1 +/–
> В свете этого хотелось бы увидеть пруф что кто-то и правда додумался до кубика > в чистом виде в QUIC. Ничем незамутнённый Cubic без гибридного старта. Или тебе сорцев недостаточно? Напомню, что сейчас в ядро вроде как пакет улучшений его от Cf собираются принять. А в Quic никакого нет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #141

109. Сообщение от timur.davletshin (ok), 23-Окт-23, 20:16	+1 +/–
> А как вообще управление пропускной способностью происходит? По хорошему роутер должен сообщать > источникам пакетов о том что у него затык, да и свитч > должен, хотя к нему спроса меньше, ну не может такого быть > чтобы не было такого механизма? Управляет потоком тот, кто посылает данные. Есть три подхода - по потерям, по задержкам и по ECN. Посылающий не знает пропускной способности полосы и шлёт (я тут упрощаю, т.к. механизмы SACK и контроль последовательности по TS чуток изменили, улучшили ситуацию)... и шлёт пакетов заведомо больше, чем может линия принять. Определённый алгоритм (по определённой кривой) увеличивает кол-во посылаемых данных (CWND - серия пакетов, на которые приходит один ACK, подтверждающий получение), пока не получится первый дроп. Тут мы делаем оговорку о том, кто делает этот дроп. Т.к. кабель обычно ничего не теряет. Дропает пакеты промежуточное сетевое устройство (может быть роутером). Как только у него переполняется буфер приёма пакетов, он начинает дропать вновь прибывающие. Это random early detection (RED). Есть разные алгоритмы того, что дропать, но смысл в том, что что-то должно быть убрано, чтобы освободить буфер. Возвращаемся к посылающему пакеты. Как только посылающий не получает подтверждения пакета, то он должен его вновь послать и, заодно, уменьшить кол-во посылаемых данных, т.к. сеть не готова принять такое их кол-во. Потом он вновь начинает посылать их больше, пытаясь понять, вдруг пропускная способность увеличилась (например, закрылись конкурирующие потоки). Поэтому в классике график отдельного соединения выглядит как "пила" в пике которых происходят дропы. Дропы - это обязательный элемент такого алгоритма. Cubic является его улучшенной реализацией (кубик он из-за кубической кривой, по которой увеличивается кол-во передаваемых пакетов)...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #113

110. Сообщение от timur.davletshin (ok), 23-Окт-23, 20:39	+1 +/–
Есть ещё управление по задержкам. Идея такая, что посылающий пакеты должен каким-то хитрым способом определить стандартную RTT для соединения и увеличивать CWND до тех пор, пока она, эта задержка, из-за заполнения буферов на промежуточных устройствах не начнёт увеличиваться. Некий предел превышен - уменьшаем кол-во посылаемых данных и так далее по кругу. Всё то же самое, только без дропов. Для определения стандартной RTT используются разной степени продвинутости low-pass фильтры для отсеивания случайного "шума". Всё бы ничего, но в момент, когда первый алгоритм такой был уже придуман, было уже управление потоком по дропам (я забыл сказать, что вообще управление потоком вообще не сразу появилось, первые интернеты были вообще без управления потоком в современном понимании). А управление по дропам более агрессивное и ВСЕГДА побеждает алгоритм по задержкам. Один алгоритм душит другой до почти полного зависания проигравшего. Примите, распишитесь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

111. Сообщение от timur.davletshin (ok), 23-Окт-23, 20:45	+1 +/–
... поэтому придумали гибридные и двухрежимные алгоритмы. Одни пытаются совместить два сигнала, другие (гибридные) изначально работают в режиме по задержкам, но как только определяют, что есть конкурирующий агрессивный алгоритм, то переключаются в агрессивный режим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #118

112. Сообщение от timur.davletshin (ok), 23-Окт-23, 20:50	+1 +/–
... есть ещё ECN (явное уведомление о перегрузке). Это поле в пакете IP, которое может передавать два сигнала (на самом деле три, но третий условно принимается равным второму, хотя есть давняя идея заюзать его для более полезных вещей) - флаг поддержки ECN и флаг перегрузки. Логика работы такая, что промежуточное устройство, когда у него буфер переполнен выше некоторого порогового значения, вместо дропа пакетов, выставляет флаг, сигнализирующий о перегрузке, и обычно переправляет пакет далее. Отправляющая сторона, получив такой сигнал, обязана уменьшить CWND. В идеале ECN должен мочь работать с любыми другими алгоритмами и это был бы идеальный вариант, который с одной стороны не теряет пакеты, а с другой стороны обеспечивает разумную задержку, а не конскую, какая является чертой алгоритмов, использующих потерю пакетов в кач-ве сигнала о перегрузке. На практике не все так радужно. Хотя ECN уже много лет, новый BBR не умеет в ECN и воспринимает их как обычные пакеты без сигнала о перегрузке. Финиш с этим бобиком. Второй косяк уже линуксовый. Линукс умеет в ECN туеву кучу лет, но до сих пор по дефолту это работает только в одну сторону. Т.е. никак, т.к. поддержка должна быть с двух сторон. Даже Apple на всех своих устройствах уже давно включила ECN.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #114

113. Сообщение от Аноньимъ (ok), 23-Окт-23, 20:59	+/–
Спасибо! Как я и думал... А попыток таки протоколов в которых сетевые узлы могли бы объясняться не было?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #115

114. Сообщение от Аноньимъ (ok), 23-Окт-23, 21:06	+1 +/–
Вот. Оно! Насколько оно распространено вообще? По идее, обязать всех это соблюдать, а тех кто не соблюдает резать агрессивно дропами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #116, #117

115. Сообщение от timur.davletshin (ok), 23-Окт-23, 21:10	+1 +/–
> Спасибо! Как я и думал... > А попыток таки протоколов в которых сетевые узлы могли бы объясняться не > было? Читай ниже про ECN.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

116. Сообщение от timur.davletshin (ok), 23-Окт-23, 21:15	+1 +/–
> Вот. Оно! > Насколько оно распространено вообще? Зайди в консоль, сделай netstat -s где-то в самом низу есть статистика. InNoECTPkts - это кол-во пакетов от соединений, где нет поддержки ECN (напомню, что обе стороны должны её иметь), InECT0Pkts и InECT1Pkts - это кол-во пакетов соединений, где есть поддержка ECN (это тот сигнал, которых на самом деле два). InCEPkts - это кол-во пакетов, в которых было выставлен флаг, что соединение перегружено. Обычно их меньше всего. Процент можешь посчитать поделив сумму InECT0Pkts и InECT1Pkts на InNoECTPkts. У меня около 30 процентов. > По идее, обязать всех это соблюдать, а тех кто не соблюдает резать > агрессивно дропами... Обязать ничего никого нельзя. Есть куча legacy устройств, где поддержки никогда не будет. Просто они будут слать данные дальше, до первого дропа. Что соответсвует той логике, о которой ты и говорил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

117. Сообщение от timur.davletshin (ok), 23-Окт-23, 21:25	+/–
> Вот. Оно! > Насколько оно распространено вообще? > По идее, обязать всех это соблюдать, а тех кто не соблюдает резать > агрессивно дропами... Суть разборок с Quic в том, что на самом деле Quic является обычным UDP. UDP не умеет на уровне ядра ни в состояние соединения (т.е. не бывает "установленного" UDP соединения), ни в управление потоком (алгоритм управления потоком реализован в TCP на уровне ядра). Поэтому Quic реализует в простанстве пользователя свой алгоритм управления потоком, как ему хочется. А т.к. управляет этим отсылающая данные сторона, то условный Google или Cf могут менять эти алгоритмы даже ничего не отдавая в ядро Linux (серверная сторона у них закрытая). Изначально Quic проектировался под алгоритм BBR (гибридный первого рода, совмещает оба сигнала для определения перегрузки и периодически пытается слать больше, для определения освободившейся полосы пропускания). Но потом, что-то пошло не так в полевых испытаниях, когда алгоритм был включен в ядро Линукс. Алгоритм оказался излишне агрессивным даже по отношению к базирующимся на дропе Cubic и Reno (был дефолтом до Cubic, те же яйца, менее агрессивная кривая). Вопреки утверждениям Анонима, сабж давно не в тренде. Его убрали из дефолтов. Google запилил на Github BBRv2 c исправлениями нареканий. Разработка вроде как в фазе где-то между альфой и бетой. Но на таком этапе она уже года три и конца этому не видно. Но самый эпичный трабл Quic даже не в том, что убрали упоминание BBR из стандарта, а в том, что алгоритм управления потоком - это алгоритм с фиксированным временем на отклик. Т.е. по факту это алгоритм реального времени, который меряет каждый раз пакетики, буферы, сигналы по много-много-много раз в секунду. А в пространстве пользователя этот алгоритм вынужден теперь конкурировать с обычными пользовательскими приложениями и затупы в десятки и даже сотни миллисекунд там являются нормальным делом. Это примерно как с Wireguard переходить назад на OpenVPN. Но у здешних гореанонимов логика дальше собственного носа не работает. Переход на внутриядерное управление в случае с VPN это большой шаг вперёд... но и переход на управление в пространстве пользователя тоже может быть большим шагом вперёд, если это предлагает уважаемая всеми мегакорпорация... ЗЫ, не надо думать, что Quic является мегановой идеей. Используемый в Bittorrent протокол uTP является тем же самым - это UDP + кастомизированный алгоритм управления потоком. Только там используется LEDBAT - относительно неагрессивный алгоритм, который уступает дефолтным (Reno и Cubic) бОльшую часть полосы. У них это не с первого раза получилось, но Аноним этого не помнит. Провайдеры отвалили порядочную кучу кирпичей после первого релиза оного и всячески пытались душить uTP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #122

118. Сообщение от timur.davletshin (ok), 23-Окт-23, 22:01	+/–
> ... другие (гибридные) Я тут ошибся. Такие алгоритмы называются двухрежимными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

119. Сообщение от Вы забыли заполнить поле Name (?), 23-Окт-23, 22:09	+/–
> большие проекты > проигрался тут в playground, очень приятно удивлен. > большие > playground Большие проекты надо сравнивать с большими.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

120. Сообщение от Ivan_83 (ok), 23-Окт-23, 22:12	+/–
CUBIC - фигня, он работает не плохо и не хорошо. Гораздо интереснее hybla и htcp тоже не плох. BBR - не уверен что хорошо работает. На фре RACK отлично работает, и его же вариант выбрал интел и гугол чтобы пихать в свои сетевухи, новость тут недавно была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #126, #127

121. Сообщение от Ivan_83 (ok), 23-Окт-23, 22:17	+/–
Не важно где именно идёт потеря пакетов. Кроме потери пакетов бывает ещё и RTT (пинг) большой. В обоих случаях в линухе hybla отлично справляется и выжимает из канала максимум. Аналогично RACK+htcp во фре. Я в своё время наигрался с этим гоняя IPTV потоки через 5 часовых поясов, и там даже без WiFi сегментов хватало и потерь и проблем из за задержек. Стабильно смотрибельный результат давало только то что описано выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #125

122. Сообщение от Ivan_83 (ok), 23-Окт-23, 22:21	+1 +/–
> А т.к. управляет этим отсылающая данные сторона, то условный Google или Cf могут менять эти алгоритмы даже ничего не отдавая в ядро Linux (серверная сторона у них закрытая). Ну тут такое себе :) В том смысле что нетфликсу с фрёй не пришлось городить юзерспейс чтобы не делится ядерными патчами :) Про uTP - да, забавно тогда было :) Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :)))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #128, #148

123. Сообщение от Ivan_83 (ok), 23-Окт-23, 22:24	+/–
Надо на jumbo frame переходить, но чувствую это ещё сложнее чем с IPv6. Хотя по идее всё новое оборудование это уже умеет и максимум нужно просто галочкой включить или не выключать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #124, #138

124. Сообщение от timur.davletshin (ok), 23-Окт-23, 22:44	+/–
> Надо на jumbo frame переходить Аха, сколько копий сломали о то, как приоритеты пакетов IP агрегировать в беспроводные MTU и прочие нюансы... а тут 9000 MTU подвезли, который сильно больше самого большого беспроводного MTU )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #129

125. Сообщение от timur.davletshin (ok), 23-Окт-23, 22:49	+/–
> В обоих случаях в линухе hybla отлично справляется и выжимает из канала > максимум. Не могу подтвердить, что его можно в кач-ве алгоритма общего применения использовать. Он, как BBRv1, применим для каналов в RTT больше 50 мс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #130

126. Сообщение от timur.davletshin (ok), 23-Окт-23, 22:54	+/–
> CUBIC - фигня, он работает не плохо и не хорошо. Тут дело не впроизводительности даже. Первый критерий - агрессивность в самом простом случае - LAN. Запускаешь один поток Cubic в простейшем сценарии кабель-тупой свитч-кабель + дефолтный fq-codel на обоих концах. RTT < 2 мс. Запускаешь параллельно SSH и делаешь выхлоп какого-нибудь сислога. Ну как, интерактивно живётся? Дальше - больше. Параллельные потоки тестируешь. Не забыть с отложенным запуском. Конкуренцию со стандартными Reno, Cubic и пр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #132

127. Сообщение от timur.davletshin (ok), 23-Окт-23, 23:00	+/–
> CUBIC - фигня, он работает не плохо и не хорошо. > Гораздо интереснее hybla и htcp тоже не плох. > BBR - не уверен что хорошо работает. > На фре RACK отлично работает, и его же вариант выбрал интел и > гугол чтобы пихать в свои сетевухи, новость тут недавно была. В принципе, если узкое место в WAN, а на роутере AQM + ECN, то любой алгоритм, не игнорирующий ECN, пойдёт (можно даже без ECN). Беда в том, что внутри LAN трафик тоже гоняют и иногда немалый. И это не вещание, пускай хоть 8к, с относительно стабильным битрейтом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

128. Сообщение от timur.davletshin (ok), 23-Окт-23, 23:06	+/–
> Про uTP - да, забавно тогда было :) > Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :))))) Ага, those were the days )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

129. Сообщение от Ivan_83 (ok), 23-Окт-23, 23:36	+/–
Jumbo это всё что больше 1536 или как то так :) В принципе вифи может лимитировать пакеты размером своего MTU, при согласовании того же TCP это легко подобрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #131, #135

130. Сообщение от Ivan_83 (ok), 23-Окт-23, 23:38	+/–
htcp работает на больших RTT чуть хуже hybla. С hybla вроде нет проблем в локалках, по крайней мере на гиговых линках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #133

131. Сообщение от timur.davletshin (ok), 23-Окт-23, 23:44	+/–
Там ещё мини-джамбо был. Позволяет на PPP делать 1500 MTU. Его много кто умеет на самом деле. Я просто подозреваю, что провайдеры даже об этом не очень подозревают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

132. Сообщение от Ivan_83 (ok), 23-Окт-23, 23:46	+/–
У кого что болит :) В RACK даже наоборот вроде выключал какую то фичу для учёта соседних соединений, ибо просто не нужно. У меня не было никогда большого трафика в локалке и необходимости что то докручивать чтобы интерактивность не страдала, всегда была проблема как отдать контент через линки с потерями или потери+RTT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #134

133. Сообщение от timur.davletshin (ok), 23-Окт-23, 23:47	+/–
> htcp работает на больших RTT чуть хуже hybla. > С hybla вроде нет проблем в локалках, по крайней мере на гиговых > линках. Про htcp ничего не могу сказать, т.к. не гонял в разных сценариях. А вообще поищи, был пару лет назад обширный census используемых алгоритмов в интернетах. Там есть много интересного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

134. Сообщение от timur.davletshin (ok), 23-Окт-23, 23:52	+/–
> У кого что болит :) > В RACK даже наоборот вроде выключал какую то фичу для учёта соседних > соединений, ибо просто не нужно. > У меня не было никогда большого трафика в локалке и необходимости что > то докручивать чтобы интерактивность не страдала, всегда была проблема как отдать > контент через линки с потерями или потери+RTT. Я говорил лишь про общий случай, про менее агрессивную относительно Cubic альтернативу. Я понимаю, что Reno и Cubic там по историческим причинам, но это не значит, что достойных альтернатив нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

135. Сообщение от Аноним (135), 24-Окт-23, 03:54	+/–
Так передача же не одним TCP ограничивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

136. Сообщение от Аноним (135), 24-Окт-23, 03:58	+/–
FEC вас не спасёт, потому что пропускную способность нельзя взять из вакуума. Если у вас потери не из-за помех вайвая, а из-за перегрузки роутера, то вы своим FEC ему настоящий ddos устройте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #142

137. Сообщение от Аноним (-), 25-Окт-23, 18:36	+/–
> https://github.com/mozilla/neqo/tree/main/neqo-transport/src/cc - нужно ещё? > Поищи там гибридный старт в исходниках. Графиков накинуть, что такое гибридный старт > и зачем он нужен? Как вот это все относится к ВОН ТОЙ либе? Она подразумевает, что вы принесете свою реалищацию QUIC под нее. Эта либа вообще умеет вон тот код использовать как underlying transport, интерфейсясь к нему? Чтобы весь этот спич стоил байтов на него? Если да - пруф в сорце сабжевой либы, с точностью до file:line? Дело в том что вопрос flow control, соответственно, вообще делегирован тому компоненту который QUIC уровнем ниже для сабжа обеспечивает - и в него - соответственно - не входит вообще. Ну вот такая вот экспертиза уровня опеннет получается, особено если хотя-бы ридми и сорц либы еще и немного колупнуть, вместо того чтобы верить "экспертам" надувающим щеки с умным видом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

138. Сообщение от Аноним (-), 25-Окт-23, 18:40	+/–
> Надо на jumbo frame переходить, но чувствую это ещё сложнее чем с IPv6. Даже используя MTU = 1500 в интернете можно покушать много интересных вещей. Из-за энкапсуляции, тоннелей, и вот этого всего. И вот юзает юзерь PPPoE какой, ему несколько байтов на хидеры - тынц. А пакет на 1500 байтов к нему соответственно - вообще никак. И начинаются чудеса, когда интернет вот тут ну не то что совсем не работает - но некоторые сайты, думавшие примерно так же, толи не грузятся, толи грузятся по килобайту в час, а все потому что oversized пакеты по пути кто-то убивает. > Хотя по идее всё новое оборудование это уже умеет и максимум нужно > просто галочкой включить или не выключать. Когда в цепочке из кучи этого оорудования попадется 1 не умеющий так вредитель - будет воооон то. И саппорт гениуса умрет жестокой смертью под напором злых хомячков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

139. Сообщение от Аноним (-), 25-Окт-23, 19:15	+/–
> Вайфай в зоне покрытия работает нормально, ад начинается только когда вы на > границу выходите, и всё  разваливается. Но вайфай и не для того вообще... А эти речи выдают дилетанта. Который про интерференцию, поляризацию, отраженку, и прочие глупости типа SNR не слышал, и даже просто врубить нормальный показометр, хотя бы уровня "iw dev wlan0 station dump" в цикле - явно не допер. В атерос дебаге есть и поинтереснее если знать на что смотреть, но для начальной оценки хватит и вон того. Про то чтобы попытаться закартировать как поле выглядит, и тем более что случается если еще и вертеть гаджет или двигаться с ним - речь, видимо, совсем не шла. Иначе вы бы побоялись выдавать такие заявления. Потому что уровень сигнала может измениться в десятки раз от перемещения на считанные сантиметры, длина волны у вафли такая. С соответствующим улучшением или ухучшением линка. А учитывая что руки юзера не особо прозрачные и параметры антенны гаджета сбивают, даже просто перехватить гаджет в руках может радикально изменить всю картину. Представляете, руки могут например резонансную частоту антенны увести хзкуда - ну а как работает антенна резонирующая на частоте отличной от рабочей? Правильно - крайне голимо. Это довольно странно для человека знающего про статистику атероса. Видимо, прочли ридмишку от такого же эксперта в интернете, уперлись рогом в 1 параметр и айда в интернете бред форсить. А почитать теорию коммуникаций, азы RF и проч - да, блин, это не ридмишка на 10 минут... А зона покрытия - это такое весьма эфемерное и абстрактное. Ну то-есть можно задать максимум таймаута соответствующий энному расстоянию от AP, и все что сильно дальше будет отпадать по таймаутам. Но выбор между хреновым линком и никаким - такое себе, так что это редко вклчают. А в типовой хате можно найти мемало мертвых зон и неудачных локаций, где когда я сижу на диване вот так, путь от меня до роутера для сигнала - метр бетона. И никакая магия через метр бетона 2.4 и тем более 5 гигагерц не протолкнет. В лучшем случае немного пересесть, или может отраженка какая поймается другой антенной, если она есть, что для мелкого гаджета совсем не факт, но... всегда есть риск что вот тут линк просто возьмет и просто просядет в хлам. А потом отплющится. > Тут кажется был раньше человек которые эти вайфаи для пром применения настраивал, > от стадионов до совсем извращённой ерундой в промышленности. У вас дома этого человека явно не было - и его оборудования тоже. И инфраструктуры под вот это все, с именно эн грамотно размещенных в правильных местах точек - у вас тоже нет. И в планирование радиоканалов вы точно не вхожи. Иначе зассали бы вон то выдавать, понимая что стадион и дом это 2 довольно больише разницы. Вон то подразумевает и правда сервировку ограниченного сегмента, бэкбон, а также нехилое изучение того что получилось оперируя -dBm и числом клиентов которые туда или сюда цепляются. В вафле так то даже есть технологии для роуминга клиентов на соседнюю точку доступа с тем же SSID. Но вы врядли этим всем пользуетесь, это специфичного сетапа требует. И не все клиенты и точки это умеют и тем более на 100% интероперабельны. > Мобильные сети да, в них всякая жесть бывает. Но я бы больше > с ней работал через разработку приложений устойчивых к дисконекту, Как вы это себе представляете для допустим видео с ютуба? Поток либо идет, либо нет. И если канал используется на единицы процентов по причине "TCP тупит" вот у гугла и возникает желание улучшить это состояние дел. А пропатчить TCP в винде они совсем отчаялись. В результате море претензий к их хостингу на ровном месте, им это не надо - так что вот вам UDP, где гугл сделает так как сочтет нужным для себя. На спрашивая вас и майкрософт вообще. > чем пытаясь изобрести особый стриминговый протокол устойчивый к такой жести. Народ едущий в транспорте совсем не прочь посмотреть вон тот клип. Предлагается им рассказать что это работать не должно, пусть TCP тупит во имя луны? Это не путь гугла, там могут и нанять нормальных инженеров. Оттуда же и респин дизайна bbr когда он пытается детектировать подобные вещи и не считать это за вот именно перегруз. Остуствие соты - это не перегруз сети. Это мертвая зона покрытия, временная потеря линка и проч. > Переключение между сотами у вас всерано не каждую секунду происходит. В быстро едущем транспорте может быть нечто довольно близкое к этому. Если попалась мертвая зона где сигнала нет - то чего? Хоть тресни но ничего не пошлешь и не примешь. И если TCP начинает брыкаться на это таймаутами по минуте - возникает спрос на то чтобы его уйти, раз это фиксу не подлежит. >> Гугол тоже может в нормальных инженеров > Последнее время не очень. И все же остатки былой роскоши - есть. И они выдают более разумные спичи чем вот тут попалось. > Стабильность обеспечивают протоколы ниже сетевого. Если демодуляция при энном соотношении синал-шум лажается, никакие протоколы с этим таки ничего сделать не могут. А вон там в низине - сигнала можно считать что совсем нет. Потому что радиоволны на тех частотах летают более-менее по прямой, как свет, через некоторые препятствия они проходят - но ослабляясь, и вот именно земля, особенно мокрая, к таким препятствиям не относится. И на этот эффект даже дома можно нарваться, там все "планирование" сводится к относительно удачному размещению роутера в не очень глупом месте. А уж на улице с рельефом "уж какой есть" - даже профессионалам много головной боли с дырами в покрытии. А если еще и ехать, там еще вопрос как алгоритмы БС и конкретной мобилы дружить будут. Что угодно может быть. > Потеря пакета на сетевом уровне это ситуация, в идеальном мире, всегда нештатная, > независимо от среды. Хотя конечно бывают нюансы. Если некто вон там на авто в тоннель заскочил - ну и где он сигнал возьмет? Не пробивают радиоволны почтенные слои земли. А ставить соты и излучающие кабели под каждую плевую трубу и мост - никаких денег не хватит. > А как вообще управление пропускной способностью происходит? По хорошему роутер >  должен сообщать источникам пакетов о том что у него затык, да и свитч > должен, хотя к нему спроса меньше, ну не может такого быть > чтобы не было такого механизма? А вот этим всем как раз congestion control и занимается, и там с этим тот еще разброд и шатания. В TCP есть ECN но это как я понимаю не решает проблему полностью. Роутер не знает что через секунду линк станет ЗБС например. А если TCP уже ушел в таймауты по 60 секунд - ну и кто б его знает что там через 60 секунд случится. Ютуб с горя отращивает ломовой буфер, пытаясь в некий адаптив на уровне вообще - плеера. Каналам похуже - поток потоньще, дроп буфера - уйдем ан 360p тощий, вероятнее что пролезет. Встряло? Откроем новый конект чтоб не ждать минуту. У них очень крутой, комплексный антилаг и адаптив + оптимизация потока по жирноте VP9/AV1. И никто ничего сравнимого не смог. Поэтому и икают в разы больше - и не могут всерьез конкурировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #144

140. Сообщение от Аноним (140), 25-Окт-23, 19:31	+/–
>> FEC эти чудо-алгоритмы называются. Это даже работает. > Если бы ты сказал LDPC, то этот тезис можно было бы принять. > Он чуть лучший результат даёт. FEC это более generic название идеи. И если кто не знал их можно комбинировать. На самых разных уровнях. Наличие или отсутствие LDPC на канальном уровне никак не мешает послать чуть больше пакетов, и если парочка пролюбилась - и черт с ними, обойдемся без перезапроса сегмента потому что FEC выдюжил. Так в принципе можно попытаться переживать уже достаточно большие выпавшие блоки, ценой роста латенси потока - это же interleaving и кодирование большого сегмента, чтобы большой выпавший блок можно было развалить на N маленьких выпадений (deinterleave) и пофиксить алгоритмом FEC. Ну вот у гугли была идея FEC к quic приделать. А китайцы на гитхабе даже и реализовали и даже покруче, сделав весьма забавный софт, "ускоритель интернета". Оказывается, это не шутка. Чудо-впн может пилить поток данных на несколько каналов, а заодно - врезать избыточность, и агрегировать на вон том сервере все потоки. Так даже канал с цать % потерь пакетов пережить можно, и TCP вот как раз и не заметит ничего, покуда FEC справляется с потерями на другом уровне. Это сильно покруче LDPC в пакетах, на совсем другом уровне и даже может использовать N интернет каналов как один более жирный и надежный. > А так ты просто в роли кэпа выступил. Дальше по тексту ты хвастаешь отсутствием > понимания того, как работает коррекция ошибок и вообще, на скольки уровнях она есть. ...кроме маленького момента: я себе беспроводных линков запилил. С вот именно FEC :). И вот тут я уже могу порассуждать за BER, PER и проч. Но вам то виднее, эксперты мирового класса. Да, это небольшие линки для внутренних нужд. Но теория на них вся та же что и на остальных, куда они денутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

141. Сообщение от Аноним (140), 25-Окт-23, 19:36	+/–
> Ничем незамутнённый Cubic без гибридного старта. Или тебе сорцев недостаточно? Напомню, > что сейчас в ядро вроде как пакет улучшений его от Cf > собираются принять. А в Quic никакого нет... Сорцев, блин, чего?! Я посмотрел сорц сабжевой либы. А там и сказано что flow control это прерогатива реализации QUIC под этой либой. Которую вы предоставите. Вы утверждаете что вон те сорцы молиллы могут быть для вот этой либы реализацией QUIC которую она сможет юзать? Или чего? И вот получается что мы тут как раки обсуждаем то чего в этой либе ... вообще нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

142. Сообщение от Аноним (140), 25-Окт-23, 19:38	+/–
> FEC вас не спасёт, потому что пропускную способность нельзя взять из вакуума. > Если у вас потери не из-за помех вайвая, а из-за перегрузки > роутера, то вы своим FEC ему настоящий ddos устройте. Как у вас все просто и универсально то. А я думал что проблемы RF каналов крайне разнообразны и многогранны... да, в каких-то случаях оверхед от FEC не есть айс. А в каких-то - то что доктор прописал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

143. Сообщение от Аноним (143), 25-Окт-23, 21:28	+/–
> libcurl - это довольно упоротая либа, которая многие вещи прячет в себя > и не даёт возможности их тонкого контроля. И интерфейс у неё > довольно мерзкий. Плюс ко всему, этот комбаин включает в себя миллион > других не нужных мне протоколов. Вот кстати не скажите. На удивление libcurl можно как по простому и высокоуровнево юзать - так и более продвинуто. Если оно было надо. А если нет - оно "просто скачает файл". Что чаще всего и было нужно. В этом смысле апи libcurl весьма разумное. И избавляет от сотен микроменеджмента, чреватого более 9000 ошибок, прострелов пяток при реакции на это все, и если вы не супер-эксперт по сетевым протоколам, вы вообще столько счастья и не хотели. > В идеале нужна одна библиотека только для http всех версий. В том > числе нужна она для того, чтобы очередная версия HTTP получала поддержку > в приложении, которое использует эту либу, нахаляву, а не дописыванием поддержки > http/4, /5 и т.д. Libсurl пошел чуть дальше чем только это. И чего? Зато может "по простому скачать файл с урл". Что чаще всего всем и надо. А низкоуровневый контроль если я хотел список какой-то байды на 10 кил с сервера скачать - ну, ок, круто, и зачем это там?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

144. Сообщение от Аноньимъ (ok), 26-Окт-23, 15:19	+/–
Нет, пользоваться вайфаем в яме, под водой, или в свинцовом бункере, я запретить никому не могу. Переотражения и прочая дичь это всё интересно, но с этим не канальный уровень борется. Мой тезис довольно простой, если у вас на вайфае пошла значительная потеря пакетов то каналу хана, и скорость передачи данных физически ниже плинтуса, и никаким чудесным тюнингом TCP это не исправить. Поправьте меня если я не прав. > Если демодуляция при энном соотношении синал-шум лажается, никакие протоколы с этим таки ничего сделать не могут. А вон там в низине - сигнала можно считать что совсем нет. Ну вот и я о том-же. > И если TCP начинает брыкаться на это таймаутами по минуте - возникает спрос на то чтобы его уйти, раз это фиксу не подлежит. Это вроде на уровне приложения настраивается при создании соединения, не? Если данные не проходят, то они не походят, канал мёртвый, хоть у вас TCP хоть что угодно другое, физически связи нет. Для стриминга видео да UDP лучше подходит, вопросов нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #149

145. Сообщение от rvs2016 (ok), 28-Окт-23, 03:18	+/–
>>> А http3 без quick - это внезапно http2. >> А ассемблер без event loop это внезапно просто ассемблер. > Сумасшедший без сумасшедшего дома внезапно просто сумасшедший Самурай без меча подобен самураю с мечом, но только без меча!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

146. Сообщение от rvs2016 (ok), 28-Окт-23, 03:21	+/–
> они вручную намагничивают участки жёсткого диска Какого ещё диска? Какое намагничивание? Они лезвиями вырезают дырки в перфокартах, чтобы получить правильные байтики в них!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

147. Сообщение от rvs2016 (ok), 28-Окт-23, 03:27	+/–
> ерунда - это обилие значков :: [] <> ... > Это правда читаемо для нормального человека? > >     let debilko.iter().map(|z|z*4).collect::<Vec<_>>() > > Попробуй не програмировать на этом годик и удивись через год - "а что это ?" > > Лет 40 назад это было очень "круто" у C-шиков понаписать подобную хрень типа >      int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hello, world!\\n",'/'/'/'));}read(j,i,p)void*i;{write(j/p+p,i---j,(int)i/(int)i);} > > и чувствовать как они круты Так об этом же писали ещё лет 25 назад в "Шутке создателей Си и Юникс": Затем Деннис и Брайан разработали по-настоящему извращенный диалект Паскаля, назвав его "A". Когда мы обнаружили, что другие действительно пытаются писать программы на A, мы быстро добавили еще парочку хитрых примочек, создав B, BCPL, и, наконец, Си. Мы остановились, добившись успешной компиляции следующего: for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); Мы не могли даже представить, что современные программисты будут пытаться использовать язык, допускающий подобный оператор! Мы даже собирались продать все это Советам, чтобы отбросить развитие их компьютерного дела на 20 лет назад. Представьте наше удивление, когда AT&T, а также другие американские корпорации начали пытаться использовать UNIX и Си! Более 20 лет ушло на то, чтобы приобрести достаточный опыт для создания хоть немного полезных приложений с использованием этой технологической пародии 60-х.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

148. Сообщение от _oleg_ (ok), 10-Ноя-23, 14:36	+/–
> Про uTP - да, забавно тогда было :) > Некоторые провайдеры вдруг узнали что UDP тоже надо шейпить :))))) А дело не в том, что его не шейпили. А в том, что uTP первой версии было агрессивное говно и просто забивало канал. Оно не реагировало на дропы и задержки - есть задержки и дропы, значит херачим ещё больше! Тут бесполезно шейпить. Блочить сразу нахер и делов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

149. Сообщение от _oleg_ (ok), 10-Ноя-23, 14:48	+/–
> Для стриминга видео да UDP лучше подходит, вопросов нет. Расскажите это RTMP и HLS :-).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

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

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