forum.opennet.ru

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

Оглавление

Атака на протоколы на основе UDP, приводящая к зацикливанию обмена пакетами, opennews (ok), 20-Мрт-24, (0) [смотреть все]

Подскажите, с целью повышения уровня образованности А для каких нужд может пона, ryoken (ok), 10:23 , 20-Мрт-24, (1) +3 //

обновить циску провайдера, Аноним (3), 10:29 , 20-Мрт-24, (3) +4
Ты не поверишь, но чего только не вывешивают наружу - , Аноним (4), 10:29 , 20-Мрт-24, (4) +8 //

Ну да, знаю, какой-нить монстрософт на принтеры в офезе вполне может белых IP на, ryoken (ok), 10:59 , 20-Мрт-24, (17) //

у ipv6 белые и пушистые Не только лишь все вспоминают прикрыть их фаерволом , DeerFriend (?), 15:37 , 20-Мрт-24, (44)

Подскажите, а TFTP работает по IPv6 мой домашний чисто по IPv4 пашет, про в, ryoken (ok), 15:49 , 20-Мрт-24, (46)

конечно пашет, кто же ему запретит , DeerFriend (?), 20:16 , 20-Мрт-24, (61) +1

Не для нужд, а в силу раз-раз-и-поехали-в-продакшн , может кажется любой сервер, Аноним (6), 10:33 , 20-Мрт-24, (6) +1
Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в д, Аноним (9), 10:39 , 20-Мрт-24, (9) +1 //

e-boot в натуральную величину, ага , ryoken (ok), 11:00 , 20-Мрт-24, (18) +3

Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп не грузит, Аноним (31), 12:43 , 20-Мрт-24, (31) +1 //

Такое есть у Apple с их Internet Recovery Но там вроде бы не tftp, посложнее А, ryoken (ok), 12:49 , 20-Мрт-24, (33) //

Ну вот у меня был лет шесть, если не семь, публичный PXE IPXE эндпоинт для загру, Аноним (52), 18:26 , 20-Мрт-24, (52)

ОО аноним, вы ещё не видели, как они питание и интернет проводят - сразу бы поня, tty0 (?), 15:36 , 21-Мрт-24, (87)

Для остальных есть EFI HTTP Boot, где поддерживается HTTPShttps github com tia, Аноним (70), 01:56 , 21-Мрт-24, (70)

Довольно глупый вопрос Для вывешивания наружу не нужно прикладывать сил, в от, Аноним (62), 20:54 , 20-Мрт-24, (62)
Потому как это простой способ сделать работу Без оверинженеринга, недушно дости, Аноним (95), 04:27 , 23-Мрт-24, (95)

Поэтому впн по UDP уже примерно неделю, как не работает , Аноним (2), 10:28 , 20-Мрт-24, (2) –3 //

Нет, не поэтому, Vik (??), 10:32 , 20-Мрт-24, (5) +1 //

А почему Чем VPN-то помешал , Аноним (52), 18:27 , 20-Мрт-24, (53) –1 //

обеспечивает доступ к противоправной информации , Я (??), 13:52 , 22-Мрт-24, (92)

Работает , Аноним (62), 20:54 , 20-Мрт-24, (63)

Потому что не нужно использовать протокол не предназначенный для этих целей Есть, ОноНим (?), 10:46 , 20-Мрт-24, (15) –2 //

там не с uTorrentom проблемы были а кое-с-чем другим провайдеры халтурно шейпи, glad_valakas (-), 11:04 , 20-Мрт-24, (19) +1 //

Нет, uTP при высокой загрузке сети начал швырять еще более мелкими пакетами, пер, Электрон (-), 06:55 , 23-Мрт-24, (96)

TCP крайне уязвим к потерям пакетов Это называется Head of Line blocking UDP эт, Аноним (20), 11:09 , 20-Мрт-24, (20) +2 //

Если у вас теряются пакеты, это не вина протокола, а линии связи Вот так смузих, Аноним (21), 11:19 , 20-Мрт-24, (21) –7 //

Вина линии связи, но ответственность перез клиентом -- ваша В идеальном мире, ко, Аноним (23), 11:28 , 20-Мрт-24, (23) +2

Какая коллизия про окна в тцп никто не читал и фрагментацию дефрагментацию С т, Аноним (21), 16:42 , 20-Мрт-24, (48)

А у вас есть возможность влиять на линии связи, особенно, если это не ваша после, Аноним (9), 11:29 , 20-Мрт-24, (24)
Линии связи имеют конечную пропускную способность Кроме того, случаются ошибки , CAE (ok), 11:48 , 20-Мрт-24, (27)

Ну да, как правило, в локальном периметре потеря пакетов наблюдается раз в сутки, tty0 (?), 15:44 , 21-Мрт-24, (88)

Линии связи объективно неидеальны и теряют пакеты, и ничего ты с этим не сделаеш, Аноним (37), 14:45 , 20-Мрт-24, (37) +1

погоди, не мешай ему жить в мире сферических коней в вакууме , namenotfound (?), 15:37 , 20-Мрт-24, (45)

Расскажи эту мантру беспроводным сетевым технологиям, чудило Там потери пакетов, Аноним (-), 15:22 , 20-Мрт-24, (41) +1

Проблема беспроводных систем не должно нарушать логику тцп Оно совсем не про то, Аноним (21), 16:46 , 20-Мрт-24, (49)

Кому нужна эта логика, нужно чтобы работало Чем это хуже, чем собирать в буфере , Аноним (-), 17:34 , 20-Мрт-24, (51)

Это не магия, это то чем занимается tcp ip стек ядра А тут смузихлебы предлагаю, Аноним (66), 22:16 , 20-Мрт-24, (66) +2

Покажешь как данные без потерь передавать или кроме 127 0 0 1 в жизни никуда не , Аноним (52), 18:30 , 20-Мрт-24, (54)
Не обязательно прям потеря Может быть и просто переупорядочивание пакетов и п, Аноним (65), 21:04 , 20-Мрт-24, (65)

И чем в этой ситуации вам поможет обработка в приложении Будет затык ещё на кон, Аноним (66), 22:25 , 20-Мрт-24, (67)

Дальше может быть переполнение приёмного буфера и потеря пакета Когда-то случит, Аноним (65), 23:38 , 20-Мрт-24, (68)

Ой видите ли гугол решил, значит это правильно Ждут не потому что тцп, а потому, Аноним (21), 08:37 , 21-Мрт-24, (75)

линии связи будут дырявые это можно только принять помехи и точки отказа с рост, Я (??), 13:54 , 22-Мрт-24, (93)
Отбрасывание пакетов - фундаментальный механизм и вообще modus operandi TCP Con, Электрон (-), 07:02 , 23-Мрт-24, (98)

БРЕД Это как раз таки TCP максимально точный в передаче о чём куча статей от про, robot228 (?), 11:48 , 20-Мрт-24, (28) –1
Вы путаете Протокол не уяввим, а congestion algorithm, который за это отвечает,, Всем Анонимам Аноним (?), 19:28 , 20-Мрт-24, (57)
Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт, Аноним (71), 03:57 , 21-Мрт-24, (71) +1 //

Можем и сказать, и это хорошая штука, но мера половинчатая То есть, это позво, Аноним (23), 06:29 , 21-Мрт-24, (73)
TCP строго говоря тоже не способен Он аккуратно разгоняется, чтобы не превыси, Аноним (82), 13:15 , 21-Мрт-24, (82)

А ещё есть ECN , _oleg_ (ok), 13:24 , 21-Мрт-24, (84)

Можно там всё при желании Вопрос поддержки лучше не поднимать Просто если звё, Аноним (82), 14:41 , 21-Мрт-24, (85)

ECN в UDP это круто, но, если я правильно понял, тут нужна поддержка именно на у, _oleg_ (ok), 15:22 , 21-Мрт-24, (86)

Про application level правильное замечание Все эти протоколы нужны для обслужив, Аноним (82), 16:43 , 21-Мрт-24, (89)

Ну хз что там подходит, что нет Понятно, что чем ждать стандартизации и распрос, _oleg_ (ok), 16:58 , 21-Мрт-24, (90)

Нет, если используется multiplexing потоков внутри этого одного соединения След, Электрон (-), 06:59 , 23-Мрт-24, (97)

Если у тебя работает SACK и протокол приложения не умеет работать с потерей част, _oleg_ (ok), 13:20 , 21-Мрт-24, (83)

TCP в сообщения заданного размера не может Тогда уж SCTP Может и в поток, и в , Аноним (9), 11:26 , 20-Мрт-24, (22) +1 //

SCTP был бы неплох, если бы не требовал замены полинтернета Ибо железки его на , Аноним (37), 10:53 , 21-Мрт-24, (76)

Ты что бобо Для игро контента Ты зайди в CSGO и поной с тикрейта из-за того что , robot228 (?), 11:47 , 20-Мрт-24, (26) –1 //

Расскажи это какому-нибудь QUIC ака HTTP 3 Тебе не приходило в голову что из не, Аноним (-), 15:32 , 20-Мрт-24, (43) //

Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием с, Аноним (71), 04:00 , 21-Мрт-24, (72)

Вот и сделай ЗБС Всем хомячкам с андроидом Чо-чо, всего пару миллиардов окучат, Аноним (-), 01:09 , 22-Мрт-24, (91)

они перешли на UDP из-за того, что народ congestion algo не могут поменять по-ум, Всем Анонимам Аноним (?), 19:31 , 20-Мрт-24, (58)
Нет никаких предназначений протоколов, вы это придумали в силу неграмотности UD, Аноним (62), 20:58 , 20-Мрт-24, (64) +1 //

протокол предназначения Выяснить, не на Скеллиге ли пакетыВыяснить, не в Велен, Я (??), 14:01 , 22-Мрт-24, (94)

В RFC 768 во введении чётко указано для чего нужен UDP Прочитай, там всего пять, Аноним (52), 23:58 , 20-Мрт-24, (69) +1

Фаерволлы настраивать в 21 веке не принято, что и говорить , Аноним (25), 11:31 , 20-Мрт-24, (25) +3
Что за бред я сейчас прочитал UPD протокол в принципе не подразумевает ответов , ИмяХ (ok), 12:25 , 20-Мрт-24, (29) +2 //

UDP не подразамевает, а сервис совсем даже требует например DNS , 1 (??), 12:47 , 20-Мрт-24, (32) +5
не совсем относится к данному случаю, но вообще UDP в 99 случаев имеет статусны, Big Robert TheTables (?), 13:18 , 20-Мрт-24, (35)
Пожалуйста почитайте и попытайтесь понять статью прежде чем комментировать , Аноним (38), 14:45 , 20-Мрт-24, (38) +1 //

Скорее всего вы со своим ответом мимо кассы Человек формально рассуждает в док, Аноним (79), 12:27 , 21-Мрт-24, (79) +1

Новость не читаем Речь о прикладных протоколах поверх UDP , Аноним (37), 14:47 , 20-Мрт-24, (39)
Не надо путать ответные пакеты и подтверждающие пакеты ACT , Sem (??), 19:33 , 20-Мрт-24, (59) //

ACK , Sem (??), 19:33 , 20-Мрт-24, (60)

Друзья, пришлите бригаду разъяснительную по вот этому моменту в рфц3704 RFC 2, Big Robert TheTables (?), 13:08 , 20-Мрт-24, (34) //

Здесь their относится к ISP Т е если от клиента к провайдеру идёт трафик с, Аноним (37), 14:53 , 20-Мрт-24, (40) //

отлично, логично Тут получается как бы вопрос сетевого этикета Социальный рей, Big Robert TheTables (?), 11:46 , 21-Мрт-24, (77) //

Не надо изобретать никакого социального рейтинга и выговоров Учёт трафика для б, Аноним (52), 00:40 , 24-Мрт-24, (99)

Это значит что ты как isp знаешь какие адреса ты выделил клиенту И если от клие, Фняк (?), 16:41 , 20-Мрт-24, (47) //

RFC не стандарт, поэтому идёт лесом , Аноним (21), 16:49 , 20-Мрт-24, (50) –3
Да, разобрались, благодарю, это направление исходящего трафика обозначено , Big Robert TheTables (?), 11:47 , 21-Мрт-24, (78)

Про RFC 3704 Стандартная рекомендация уже лет тридцать Правило any мойсервер пр, Аноним (36), 14:19 , 20-Мрт-24, (36) +1 //

а толку , Аноним (55), 18:31 , 20-Мрт-24, (55) //

пока не будет наказания за халатное отношение, так и будем все участвовать в ддо, Аноним (55), 18:34 , 20-Мрт-24, (56) //

Сама виновата, не надела бы короткую юбку 8212 не изначиловали бы , Аноним (52), 00:42 , 24-Мрт-24, (100)

Quote of the day есть и поверх TCP, qweo (?), 06:30 , 21-Мрт-24, (74) //

Зачем дуплекс для одной строки текстовой UDP здесь - верный выбор , Аноним (79), 12:31 , 21-Мрт-24, (80)

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

20. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +2 +/–

Сообщение от Аноним (20), 20-Мрт-24, 11:09

TCP крайне уязвим к потерям пакетов. Это называется Head of Line blocking.
UDP этому не подвержен, потому что не соблюдает порядок приёма пакетов.
Поэтому там не мнимые 0.01 прироста, а прирост на порядки, если ваш протокол уровня приложения умеет не ждать переотправки каждого очередного пакета, а либо собирать их в буфер и запрашивать ретрансмит только потерянных, либо просто игнорировать (например, когда это телефонный звонок).

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

21. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." –7 +/–

Сообщение от Аноним (21), 20-Мрт-24, 11:19

Если у вас теряются пакеты, это не вина протокола, а линии связи.
Вот так смузихлебы захватили весь мир. Может ещё в джаваскрипт и в браузер закниуть всю логику работы юдп и тцп.
ДНС и другие вещи уже забили гвоздями.

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

23. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +2 +/–

Сообщение от Аноним (23), 20-Мрт-24, 11:28

Вина линии связи, но ответственность перез клиентом -- ваша.
В идеальном мире, конечно, пакет, потерянный БС будет ей же и ретрансмитнут. Но тогда возникнет коллизия, когда пакеты "правильных" клиентов ретрансмитятся быстрее и в большем количестве. Вы же этого не хотите?
Значит ретрансмитить будем end-to-end.
А если e2e, то всё равно ваша машина (которая крайне мало знает о состоянии канала) будет заниматься контролем потока, этого не избежать.
А поскольку большинство программистов заниматься контролем потока не хотят (да и не умеют), и трудно за это их винить, у нас появился system-level TCP. Что, вообще говоря, нонсенс, потому что требования всех приложений разные.

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

48. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (21), 20-Мрт-24, 16:42

Какая коллизия? про окна в тцп никто не читал и фрагментацию/дефрагментацию.
С таким подходом приложение всё должно делать. А так то, что в ОС работает - оно же неправильно работает.

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

24. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (9), 20-Мрт-24, 11:29

А у вас есть возможность влиять на линии связи, особенно, если это не ваша последняя миля?

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

27. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от CAE (ok), 20-Мрт-24, 11:48

Линии связи имеют конечную пропускную способность. Кроме того, случаются ошибки. Поэтому потери пакетов на TCP/IP сетях в общем случае - это норма, а не исключение. Подробнее vk.com/tcpipquality

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

88. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от tty0 (?), 21-Мрт-24, 15:44

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

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

37. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +1 +/–

Сообщение от Аноним (37), 20-Мрт-24, 14:45

> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Линии связи объективно неидеальны и теряют пакеты, и ничего ты с этим не сделаешь.

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

45. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от namenotfound (?), 20-Мрт-24, 15:37

погоди, не мешай ему жить в мире сферических коней в вакууме

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

41. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +1 +/–

Сообщение от Аноним (-), 20-Мрт-24, 15:22

> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Расскажи эту мантру беспроводным сетевым технологиям, чудило. Там потери пакетов или всплески латенси совершенно штатное состояние дел. Не свидетельствующее о проблеме.
Зато когда TCP одупляет полчаса по причине "поезд проскочил тоннель" - да, это очень круто. Чтобы от него избавиться везде где можно и нельзя.

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

49. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (21), 20-Мрт-24, 16:46

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

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

51. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (-), 20-Мрт-24, 17:34

> Проблема беспроводных систем не должно нарушать логику тцп.
Кому нужна эта логика, нужно чтобы работало.
> вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий.
Чем это хуже, чем собирать в буфере всяких ядер и всяких сетевых стеков? Или ты думаешь, в тцп пакеты магическим образом приходят в том же порядке, в котором отправлены были?

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

66. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +2 +/–

Сообщение от Аноним (66), 20-Мрт-24, 22:16

Это не магия, это то чем занимается tcp/ip стек ядра. А тут смузихлебы предлагают это всё отбросить и делать свои поделия в приложениях.
Им же нужно юдп гонять для хттп. Задержки низкие говорят они. Днс надо заворачивать в хттп, безопасно говорят они. И вообще всё надо завернуть в хттп и json, так удобней читать говорят они.

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

54. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (52), 20-Мрт-24, 18:30

> Если у вас теряются пакеты, это не вина протокола, а линии связи.
Покажешь как данные без потерь передавать или кроме 127.0.0.1 в жизни никуда не коннектился?

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

65. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (65), 20-Мрт-24, 21:04

> Если у вас теряются пакеты
Не обязательно прям потеря. Может быть и просто "переупорядочивание" пакетов и периодические небольшие "затыки" (даже и без потерь). А в итоге tcp то плохо разгоняется, то слишком быстро разгоняется, то начинает непонятно чего ждать (а переспросить стесняется).
> вина... линии связи.
Там ещё и embedded бывает, у которого просто буферы маленькие, а обмен очень интенсивный. И в итоге потери/затыки ловятся даже при прямом подключении комп-железка.
В принципе, подобные проблемы возникают даже на ПК (faq по настройке txqueue len). На одном компе старый realtek умеет только 256 пакетов в буфер, а другой комп через tplink отправляет по 1000 пакетов. Процессор на приёмной стороне в C6 (там вообще тактирование ядра выключено - PLL off) м проснётся только через 100+мс. за это время можно очень много чего передать... в никуда. Естественно что-то потеряется.
Даже если C6 не нравится - приоритет прерываний от видеокарты обычно выше, чем приоритет прерываний от сетевухи. Пока иксы ждут/обрабатывают очередной vsync (16 мс при 60Hz), буфер сетевухи успевает пару раз переполнится (если вдруг пойдёт куча мелких пакетов).
В общем, реальность - это штука сложная... и добиться чтобы "без потерь" бывает тяжеловато.

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

67. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (66), 20-Мрт-24, 22:25

И чем в этой ситуации вам поможет обработка в приложении? Будет затык ещё на контекст свиче, а дальше что?

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

68. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (65), 20-Мрт-24, 23:38

> Будет затык ещё на контекст свиче, а дальше что?
Дальше может быть переполнение приёмного буфера и потеря пакета. Когда-то случится ретрансмит. В случае TCP может быть неконтролируемый "затык" на время около нескольких секунд (до 5, а иногда и до 30 секунд). Уменьшить его можно, но обычно общесистемно (где-то в недрах sysctl в случае linux) и много где это сделает хуже (при работе с какими-нибудь медленными каналами типа gprs).
В принципе, если будет какой-нибудь ioctl/fcntl для повторной попытки отправки/настройки таймаутов tcp и прочего - многих это устроит.
В случае udp пакет можно передать в любое время. В tcp - следующий пакет не передастся до тех пор, пока не "пропихнётся" предыдущий пакет. А когда "пропихнётся" предыдущий потерянный пакет - решает TCP-стек/операционка. В udp будет "пропихиваться" когда отправляешь (конечно может и вообще всё udp потерять, но на практике теряется небольшой процент). Для задач типа передачи звука в реальном времени udp выходит лучше. Если бы tcp позволял как-то из userspace контролировать попытки повторной отправки - он бы тоже подошёл и для передачи звука в real-time.
Гугол решил, что и для ютюбчика вариант с udp лучше (потому как ждать по 30 секунд раскукоживания tcp - ну это жесть в современном мире). Вообще затыки на ютюбе стали как-то шустрее проходить, возможно, что и из-за http2/quic/spdy. А возможно и из-за чего-то ещё...

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

75. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (21), 21-Мрт-24, 08:37

Ой видите ли гугол решил, значит это правильно. Ждут не потому что тцп, а потому что ключи ssl надо передать, установить сессию и т.д.
И всё идет к тому, что грубо ломают модель OSI.

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

93. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Я (??), 22-Мрт-24, 13:54

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

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

98. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Электрон (-), 23-Мрт-24, 07:02

Отбрасывание пакетов - фундаментальный механизм и вообще modus operandi TCP. Congestion control потому что.

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

28. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." –1 +/–

Сообщение от robot228 (?), 20-Мрт-24, 11:48

БРЕД.
Это как раз таки TCP максимально точный в передаче о чём куча статей от профессионалов написано и я их читал, а UDP как раз-таки с потерями идёт by design.

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

57. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Всем Анонимам Аноним (?), 20-Мрт-24, 19:28

Вы путаете. Протокол не уяввим, а congestion algorithm, который за это отвечает, обычно спроектирован в 80х годах и никто не парился особо.
Гугл сделал новый, но до сих пор никто на него не перешел, типа " и так сойдет".
Поэтому им пришлось использовать UDP вроде как временно. Но, похоже, мир настолько консервативный, что придется его оставить надолго

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

71. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +1 +/–

Сообщение от Аноним (71), 21-Мрт-24, 03:57

Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага. Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли. Вы всё равно навесите поверх свою реализацию, только при этом проиграете на том, что не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.

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

73. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (23), 21-Мрт-24, 06:29

>Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага.
Можем и сказать, и это хорошая штука, но мера "половинчатая". То есть, это позволяет не зависеть от последовательности p-a-p-a-p-a, но всё равно не позволяет получать p-пакеты не по-порядку, потом запрашивая пропавшие.
>Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли.
Неправда ваша. Во-первых, не всё, что мы делаем, это HTTP. Во-вторых, см цитату выше. Сейчас уже никто не рендерит страницу "сверху вниз", страница получается целиком, потом рендерится. В этом смысле порядок сообщений вам не очень-то нужен. Вам нужно получить страницу целиком.
Это не значит, что порядок сообщений _никогда_ не нужен.

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

82. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (82), 21-Мрт-24, 13:15

> не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.
TCP строго говоря тоже не способен. Он "аккуратно" разгоняется, чтобы не превысить лимиты. А контроль наполнения идёт по обратной связи - получению ACK (частично можно и по icmp). Если не видно ACK - значит где-то что-то переполнилось и потерялось. Если ACK приходят быстро и в большом количестве - можно уверенно разгоняться дальше.
Улучшить это можно, но нужно знать особенности канала связи (хотя бы скорость, время пинга и примерный процент потерь). Универсальным алгоритмом, который работает неизвестно с каким каналом связи это тяжело сделать.
Ну и тут правльно заметили - большинство алгоритмов проектировалось для сетей 80-х и 90-х... С тех пор много чего поменялось. Новые алгоритмы есть, но их надо вручную втыкать и этим вообще единицы занимаются.

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

84. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от _oleg_ (ok), 21-Мрт-24, 13:24

А ещё есть ECN...

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

85. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (82), 21-Мрт-24, 14:41

Можно там всё при желании.
> It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control.
Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то про ECN никто никогда и не узнает. Даже в tcp лет 15 ecn готовили к включению в дефолте.

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

86. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от _oleg_ (ok), 21-Мрт-24, 15:22

> Можно там всё при желании.
>> It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control.
> Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то
> про ECN никто никогда и не узнает. Даже в tcp лет
> 15 ecn готовили к включению в дефолте.
ECN в UDP это круто, но, если я правильно понял, тут нужна поддержка именно на уровне приложения, в любом случае (даже когда датут этим порулить с этого уровня). В то время, когда с tcp, если оно настроено в ОС, то будет работать для всех.

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

89. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Аноним (82), 21-Мрт-24, 16:43

Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений. И с точки зрения приложения ни TCP ни UDP часто не подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге спор а что же лучше перерастает в холивары.
SEQPACKET часто будет лучше, но он слабо распространён и не имеет "правильного и однозначного" решения (это так важно, что прям пипец как важно! НЕ МОЖЕТ СУЩЕСТВОВАТЬ корректной реализации SEQPACKET, которая подойдёт всем; остаются перекосы либо в сторону TCP, либо в сторону UDP, а как сделать правильно - непонятно...).
Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP), или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос.

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

90. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от _oleg_ (ok), 21-Мрт-24, 16:58

> Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений.
> И с точки зрения приложения ни TCP ни UDP часто не
> подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге
> спор а что же лучше перерастает в холивары.
Ну хз что там подходит, что нет. Понятно, что чем ждать стандартизации и распространения во всех ОС/железках очередных фишек TCP, проще с точки зрения разрабов приложения нагородить быстро своё поверх UDP. Но, imho, правильнее было бы иметь всё таки по итогу какой-то более-менее стандартизированный набор расширений для TCP или UDP для online игр, видеовещания и т.п., которые бы со временем поддержали все на уровне ОС/железа. А разрабам надо было только выставить верные флаги в вызове socket(), что бы получить требуемый сервис. И не городить всякое.

> Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP),
> или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать
> пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос.
Так и живём.

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

97. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от Электрон (-), 23-Мрт-24, 06:59

> вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли.
Нет, если используется multiplexing потоков внутри этого одного соединения. Следует из высказывания выше про Head of Line Blocking. А QUIC это делает, только не знаю на каком уровне это задействовано в браузерах.

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

83. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..." +/–

Сообщение от _oleg_ (ok), 21-Мрт-24, 13:20

Если у тебя работает SACK и протокол приложения не умеет работать с потерей части инфы (например http-запрос против видеовещания), то разницы быть заметной не должно между udp и tcp. Один хрен, что там, что там надо ждать дополучения опоздавших перед началом обработки.
Плюс, tcp в отличии от udp имеет window и всякие congestion control алгоритмы, что позволяет не добивать канал, когда он уже и так забит. udp же, если не реализовывать это в приложении, этого не умеет. Если реализовывать, то какой смысл? В итоге получится tcp в userspace.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	20. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+2 +/–
	Сообщение от Аноним (20), 20-Мрт-24, 11:09
	TCP крайне уязвим к потерям пакетов. Это называется Head of Line blocking. UDP этому не подвержен, потому что не соблюдает порядок приёма пакетов. Поэтому там не мнимые 0.01 прироста, а прирост на порядки, если ваш протокол уровня приложения умеет не ждать переотправки каждого очередного пакета, а либо собирать их в буфер и запрашивать ретрансмит только потерянных, либо просто игнорировать (например, когда это телефонный звонок).
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	21. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	–7 +/–
	Сообщение от Аноним (21), 20-Мрт-24, 11:19
	Если у вас теряются пакеты, это не вина протокола, а линии связи. Вот так смузихлебы захватили весь мир. Может ещё в джаваскрипт и в браузер закниуть всю логику работы юдп и тцп. ДНС и другие вещи уже забили гвоздями.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+2 +/–
	Сообщение от Аноним (23), 20-Мрт-24, 11:28
	Вина линии связи, но ответственность перез клиентом -- ваша. В идеальном мире, конечно, пакет, потерянный БС будет ей же и ретрансмитнут. Но тогда возникнет коллизия, когда пакеты "правильных" клиентов ретрансмитятся быстрее и в большем количестве. Вы же этого не хотите? Значит ретрансмитить будем end-to-end. А если e2e, то всё равно ваша машина (которая крайне мало знает о состоянии канала) будет заниматься контролем потока, этого не избежать. А поскольку большинство программистов заниматься контролем потока не хотят (да и не умеют), и трудно за это их винить, у нас появился system-level TCP. Что, вообще говоря, нонсенс, потому что требования всех приложений разные.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (21), 20-Мрт-24, 16:42
	Какая коллизия? про окна в тцп никто не читал и фрагментацию/дефрагментацию. С таким подходом приложение всё должно делать. А так то, что в ОС работает - оно же неправильно работает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (9), 20-Мрт-24, 11:29
	А у вас есть возможность влиять на линии связи, особенно, если это не ваша последняя миля?
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	27. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от CAE (ok), 20-Мрт-24, 11:48
	Линии связи имеют конечную пропускную способность. Кроме того, случаются ошибки. Поэтому потери пакетов на TCP/IP сетях в общем случае - это норма, а не исключение. Подробнее vk.com/tcpipquality
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	88. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от tty0 (?), 21-Мрт-24, 15:44
	Ну да, как правило, в локальном периметре потеря пакетов наблюдается раз в сутки (в основном из-за электрики). А интернет - это куда более многогранная вещь, но и там потери минимальны, а причиной тому - древние технологии или кривые ручки. Поэтому строить поверх удп можно, но выглядит странно, т.к. при низких задержках и высоких потерях проблемы явно нужно решать, а не заметать под ковер
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (37), 20-Мрт-24, 14:45
	> Если у вас теряются пакеты, это не вина протокола, а линии связи. Линии связи объективно неидеальны и теряют пакеты, и ничего ты с этим не сделаешь.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	45. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от namenotfound (?), 20-Мрт-24, 15:37
	погоди, не мешай ему жить в мире сферических коней в вакууме
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (-), 20-Мрт-24, 15:22
	> Если у вас теряются пакеты, это не вина протокола, а линии связи. Расскажи эту мантру беспроводным сетевым технологиям, чудило. Там потери пакетов или всплески латенси совершенно штатное состояние дел. Не свидетельствующее о проблеме. Зато когда TCP одупляет полчаса по причине "поезд проскочил тоннель" - да, это очень круто. Чтобы от него избавиться везде где можно и нельзя.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	49. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (21), 20-Мрт-24, 16:46
	Проблема беспроводных систем не должно нарушать логику тцп. Оно совсем не про то. Оно про упорядоченную отправку пакетов адресату. Т.е. поток (stream). А вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий. Зато задержки низкие говорят они. Так они в нормальных условиях и на тцп низкие, если нет потерь пакетов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (-), 20-Мрт-24, 17:34
	> Проблема беспроводных систем не должно нарушать логику тцп. Кому нужна эта логика, нужно чтобы работало. > вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий. Чем это хуже, чем собирать в буфере всяких ядер и всяких сетевых стеков? Или ты думаешь, в тцп пакеты магическим образом приходят в том же порядке, в котором отправлены были?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+2 +/–
	Сообщение от Аноним (66), 20-Мрт-24, 22:16
	Это не магия, это то чем занимается tcp/ip стек ядра. А тут смузихлебы предлагают это всё отбросить и делать свои поделия в приложениях. Им же нужно юдп гонять для хттп. Задержки низкие говорят они. Днс надо заворачивать в хттп, безопасно говорят они. И вообще всё надо завернуть в хттп и json, так удобней читать говорят они.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (52), 20-Мрт-24, 18:30
	> Если у вас теряются пакеты, это не вина протокола, а линии связи. Покажешь как данные без потерь передавать или кроме 127.0.0.1 в жизни никуда не коннектился?
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	65. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (65), 20-Мрт-24, 21:04
	> Если у вас теряются пакеты Не обязательно прям потеря. Может быть и просто "переупорядочивание" пакетов и периодические небольшие "затыки" (даже и без потерь). А в итоге tcp то плохо разгоняется, то слишком быстро разгоняется, то начинает непонятно чего ждать (а переспросить стесняется). > вина... линии связи. Там ещё и embedded бывает, у которого просто буферы маленькие, а обмен очень интенсивный. И в итоге потери/затыки ловятся даже при прямом подключении комп-железка. В принципе, подобные проблемы возникают даже на ПК (faq по настройке txqueue len). На одном компе старый realtek умеет только 256 пакетов в буфер, а другой комп через tplink отправляет по 1000 пакетов. Процессор на приёмной стороне в C6 (там вообще тактирование ядра выключено - PLL off) м проснётся только через 100+мс. за это время можно очень много чего передать... в никуда. Естественно что-то потеряется. Даже если C6 не нравится - приоритет прерываний от видеокарты обычно выше, чем приоритет прерываний от сетевухи. Пока иксы ждут/обрабатывают очередной vsync (16 мс при 60Hz), буфер сетевухи успевает пару раз переполнится (если вдруг пойдёт куча мелких пакетов). В общем, реальность - это штука сложная... и добиться чтобы "без потерь" бывает тяжеловато.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	67. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (66), 20-Мрт-24, 22:25
	И чем в этой ситуации вам поможет обработка в приложении? Будет затык ещё на контекст свиче, а дальше что?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (65), 20-Мрт-24, 23:38
	> Будет затык ещё на контекст свиче, а дальше что? Дальше может быть переполнение приёмного буфера и потеря пакета. Когда-то случится ретрансмит. В случае TCP может быть неконтролируемый "затык" на время около нескольких секунд (до 5, а иногда и до 30 секунд). Уменьшить его можно, но обычно общесистемно (где-то в недрах sysctl в случае linux) и много где это сделает хуже (при работе с какими-нибудь медленными каналами типа gprs). В принципе, если будет какой-нибудь ioctl/fcntl для повторной попытки отправки/настройки таймаутов tcp и прочего - многих это устроит. В случае udp пакет можно передать в любое время. В tcp - следующий пакет не передастся до тех пор, пока не "пропихнётся" предыдущий пакет. А когда "пропихнётся" предыдущий потерянный пакет - решает TCP-стек/операционка. В udp будет "пропихиваться" когда отправляешь (конечно может и вообще всё udp потерять, но на практике теряется небольшой процент). Для задач типа передачи звука в реальном времени udp выходит лучше. Если бы tcp позволял как-то из userspace контролировать попытки повторной отправки - он бы тоже подошёл и для передачи звука в real-time. Гугол решил, что и для ютюбчика вариант с udp лучше (потому как ждать по 30 секунд раскукоживания tcp - ну это жесть в современном мире). Вообще затыки на ютюбе стали как-то шустрее проходить, возможно, что и из-за http2/quic/spdy. А возможно и из-за чего-то ещё...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (21), 21-Мрт-24, 08:37
	Ой видите ли гугол решил, значит это правильно. Ждут не потому что тцп, а потому что ключи ssl надо передать, установить сессию и т.д. И всё идет к тому, что грубо ломают модель OSI.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Я (??), 22-Мрт-24, 13:54
	линии связи будут дырявые это можно только принять. помехи и точки отказа с ростом сети только чаще встречаются. поэтому приходится переходить на протоколы менее чуствительные к качеству линии связи.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	98. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Электрон (-), 23-Мрт-24, 07:02
	Отбрасывание пакетов - фундаментальный механизм и вообще modus operandi TCP. Congestion control потому что.
	Ответить \| Правка \| К родителю #21 \| Наверх \| Cообщить модератору


	28. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	–1 +/–
	Сообщение от robot228 (?), 20-Мрт-24, 11:48
	БРЕД. Это как раз таки TCP максимально точный в передаче о чём куча статей от профессионалов написано и я их читал, а UDP как раз-таки с потерями идёт by design.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	57. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 20-Мрт-24, 19:28
	Вы путаете. Протокол не уяввим, а congestion algorithm, который за это отвечает, обычно спроектирован в 80х годах и никто не парился особо. Гугл сделал новый, но до сих пор никто на него не перешел, типа " и так сойдет". Поэтому им пришлось использовать UDP вроде как временно. Но, похоже, мир настолько консервативный, что придется его оставить надолго
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	71. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (71), 21-Мрт-24, 03:57
	Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага. Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли. Вы всё равно навесите поверх свою реализацию, только при этом проиграете на том, что не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	73. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (23), 21-Мрт-24, 06:29
	>Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага. Можем и сказать, и это хорошая штука, но мера "половинчатая". То есть, это позволяет не зависеть от последовательности p-a-p-a-p-a, но всё равно не позволяет получать p-пакеты не по-порядку, потом запрашивая пропавшие. >Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли. Неправда ваша. Во-первых, не всё, что мы делаем, это HTTP. Во-вторых, см цитату выше. Сейчас уже никто не рендерит страницу "сверху вниз", страница получается целиком, потом рендерится. В этом смысле порядок сообщений вам не очень-то нужен. Вам нужно получить страницу целиком. Это не значит, что порядок сообщений _никогда_ не нужен.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (82), 21-Мрт-24, 13:15
	> не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать. TCP строго говоря тоже не способен. Он "аккуратно" разгоняется, чтобы не превысить лимиты. А контроль наполнения идёт по обратной связи - получению ACK (частично можно и по icmp). Если не видно ACK - значит где-то что-то переполнилось и потерялось. Если ACK приходят быстро и в большом количестве - можно уверенно разгоняться дальше. Улучшить это можно, но нужно знать особенности канала связи (хотя бы скорость, время пинга и примерный процент потерь). Универсальным алгоритмом, который работает неизвестно с каким каналом связи это тяжело сделать. Ну и тут правльно заметили - большинство алгоритмов проектировалось для сетей 80-х и 90-х... С тех пор много чего поменялось. Новые алгоритмы есть, но их надо вручную втыкать и этим вообще единицы занимаются.
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	84. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от _oleg_ (ok), 21-Мрт-24, 13:24
	А ещё есть ECN...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (82), 21-Мрт-24, 14:41
	Можно там всё при желании. > It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control. Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то про ECN никто никогда и не узнает. Даже в tcp лет 15 ecn готовили к включению в дефолте.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от _oleg_ (ok), 21-Мрт-24, 15:22
	> Можно там всё при желании. >> It is possible to use ECN with protocols layered above UDP. More recent UDP based protocols such as QUIC are using ECN for congestion control. > Вопрос поддержки лучше не поднимать ;) Просто если звёзды сложились неправильно, то > про ECN никто никогда и не узнает. Даже в tcp лет > 15 ecn готовили к включению в дефолте. ECN в UDP это круто, но, если я правильно понял, тут нужна поддержка именно на уровне приложения, в любом случае (даже когда датут этим порулить с этого уровня). В то время, когда с tcp, если оно настроено в ОС, то будет работать для всех.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (82), 21-Мрт-24, 16:43
	Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений. И с точки зрения приложения ни TCP ни UDP часто не подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге спор а что же лучше перерастает в холивары. SEQPACKET часто будет лучше, но он слабо распространён и не имеет "правильного и однозначного" решения (это так важно, что прям пипец как важно! НЕ МОЖЕТ СУЩЕСТВОВАТЬ корректной реализации SEQPACKET, которая подойдёт всем; остаются перекосы либо в сторону TCP, либо в сторону UDP, а как сделать правильно - непонятно...). Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP), или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от _oleg_ (ok), 21-Мрт-24, 16:58
	> Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений. > И с точки зрения приложения ни TCP ни UDP часто не > подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге > спор а что же лучше перерастает в холивары. Ну хз что там подходит, что нет. Понятно, что чем ждать стандартизации и распространения во всех ОС/железках очередных фишек TCP, проще с точки зрения разрабов приложения нагородить быстро своё поверх UDP. Но, imho, правильнее было бы иметь всё таки по итогу какой-то более-менее стандартизированный набор расширений для TCP или UDP для online игр, видеовещания и т.п., которые бы со временем поддержали все на уровне ОС/железа. А разрабам надо было только выставить верные флаги в вызове socket(), что бы получить требуемый сервис. И не городить всякое. > Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP), > или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать > пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос. Так и живём.
	Ответить \| Правка \| Наверх \| Cообщить модератору