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

"Атака на протоколы на основе UDP, приводящая к зацикливанию обмена пакетами"	+/–
Сообщение от opennews (ok), 20-Мрт-24, 10:23
Координационный центр CERT (компьютерная группа реагирования на чрезвычайные ситуации), опубликовал предупреждение о серии уязвимостей в реализациях различных прикладных протоколов, использующих в качестве транспорта протокол UDP. Уязвимости могут использоваться для организации отказа в обслуживании  из-за возможности зацикливания обмена пакетами между двумя хостами. Например, атакующие могут добиться исчерпания доступной пропускной способности сети, блокирования работы сетевых сервисов (например, через создание высокой нагрузки и превышение ограничения интенсивности запросов) и реализации усилителей трафика для DDoS-атак... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60814
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+3 +/–
Сообщение от ryoken (ok), 20-Мрт-24, 10:23
>>23 тысячи уязвимых TFTP-серверов Подскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+4 +/–
	Сообщение от Аноним (3), 20-Мрт-24, 10:29
	обновить циску провайдера
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+8 +/–
	Сообщение от Аноним (4), 20-Мрт-24, 10:29
	Ты не поверишь, но чего только не вывешивают наружу :-)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	17. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от ryoken (ok), 20-Мрт-24, 10:59
	> Ты не поверишь, но чего только не вывешивают наружу :-) Ну да, знаю, какой-нить монстрософт на принтеры в офезе вполне может белых IP наляпать... Но всё же :).
	Ответить | Правка | Наверх | Cообщить модератору

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

	46. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от ryoken (ok), 20-Мрт-24, 15:49
	> у ipv6 белые и пушистые. Не только лишь все вспоминают прикрыть их > фаерволом. Подскажите, а TFTP работает по IPv6? :) (мой домашний чисто по IPv4 пашет, про второй вариант я как-то и не думал :) )
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	18. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+3 +/–
	Сообщение от ryoken (ok), 20-Мрт-24, 11:00
	> Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в девайс. e-boot в натуральную величину, ага...
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (31), 20-Мрт-24, 12:43
	Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп не грузится и под рукой нет ничего кроме инета, то почему бы и нет
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	33. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от ryoken (ok), 20-Мрт-24, 12:49
	> Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп > не грузится и под рукой нет ничего кроме инета, то почему > бы и нет Такое есть у Apple с их Internet Recovery. Но там вроде бы не tftp, посложнее. А вы какой сервис имели ввиду, можно ссылку?
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (52), 20-Мрт-24, 18:26
	Ну вот у меня был лет шесть, если не семь, публичный PXE/IPXE эндпоинт для загрузки по сети в популярные линуксы. На пике под сотню клиентов в неделю обслуживал. А потом набежали какие-то боты из ЮВА, стали выжирать полосу и всем портить праздник. Сперва боролся, но по итогу надоела эта возня и я его от интернета отрубил.
	Ответить | Правка | Наверх | Cообщить модератору

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

	70. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (70), 21-Мрт-24, 01:56
	Для остальных есть EFI HTTP Boot, где поддерживается HTTPS https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	62. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (62), 20-Мрт-24, 20:54
	Довольно глупый вопрос. Для "вывешивания наружу" не нужно прикладывать сил, в отличие от закрытия. Вопрос зачем его закрывать.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	95. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (95), 23-Мрт-24, 04:27
	> Подскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу? Потому как это простой способ сделать работу. Без оверинженеринга, недушно достичь иллюзии. На недолгое время.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

	5. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Vik (??), 20-Мрт-24, 10:32
	Нет, не поэтому
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	–1 +/–
	Сообщение от Аноним (52), 20-Мрт-24, 18:27
	А почему? Чем VPN-то помешал?
	Ответить | Правка | Наверх | Cообщить модератору

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

	63. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (62), 20-Мрт-24, 20:54
	Работает.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

15. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	–2 +/–
Сообщение от ОноНим (?), 20-Мрт-24, 10:46
Потому что не нужно использовать протокол не предназначенный для этих целей. Есть TCP и используйте его для транспорта данных по типа клиент/сервер, а UDP оставьте для медиа/игро-контента "в одну сторону". А то придумали уже HTTP на UDP переводить, из-за мнимых 0.01% прироста производительности. Будто никто не помнит проблем с uTorrent-ом, когда они решили гонять торренты по UDP..
Ответить | Правка | Наверх | Cообщить модератору

	19. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от glad_valakas (-), 20-Мрт-24, 11:04
	там не с uTorrentom проблемы были. а кое-с-чем другим. провайдеры халтурно шейпили юзерский трафик.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Электрон (-), 23-Мрт-24, 06:55
	Нет, uTP при высокой загрузке сети начал швырять еще более мелкими пакетами, перегружая оборудование провайдеров аццким PPS.
	Ответить | Правка | Наверх | Cообщить модератору

	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ообщить модератору

	22. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (9), 20-Мрт-24, 11:26
	TCP в сообщения заданного размера не может. Тогда уж SCTP. Может и в поток, и в дейтаграммы.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	76. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (37), 21-Мрт-24, 10:53
	SCTP был бы неплох, если бы не требовал замены полинтернета. Ибо железки его на L4 не умеют.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	–1 +/–
	Сообщение от robot228 (?), 20-Мрт-24, 11:47
	Ты что бобо? Для игро контента. Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов. UDP в целом это как сжатие с потерями. Где-то что-то заглючит.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	43. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (-), 20-Мрт-24, 15:32
	> Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов. > UDP в целом это как сжатие с потерями. Где-то что-то заглючит. Расскажи это какому-нибудь QUIC ака HTTP/3. Тебе не приходило в голову что из ненадежного слоя всегда можно сделать - надежный? Переотправкой пакетов как раз. А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачи. За это TCP и выпадает постепенно из фавора. Если в Linux еще появились алгоритмы которые сносно живут и с таким, то в какой-нибудь винде оно будет так как сделает какой-нибудь майкрософт своими криворукими индусами, и фиг оспоришь.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (71), 21-Мрт-24, 04:00
	> А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачи Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием скорости не будет, верим. Может проблема в том, что ваша система настроена через одно место и можно было бы выбрать алгоритм congestion control более подходящий для вашей сети? Спойлер: они есть, и много, и в том числе для минимальных задержек, и их тоже больше чем один.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Аноним (-), 22-Мрт-24, 01:09
	> Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием > скорости не будет, верим. Может проблема в том, что ваша система > настроена через одно место и можно было бы выбрать алгоритм congestion > control более подходящий для вашей сети? Спойлер: они есть, и много, Вот и сделай ЗБС. Всем хомячкам с андроидом. Чо-чо, всего пару миллиардов окучать? Во, приступай. И еще эвон сколько юзеров винды, удачи в настройке. А, да, если ютуб-плеер не может послать запрос на чанк видео со своей стороны - потому что у винды хзкакая там логика туповэйтинга - окей, а сервер чанков не телепат, и даже если нарулит со своей стороны более другой congestion - то это ему не поможет. Ибо какой чанк захочет юзер он заранее не знает. А в винде - см. про майкрософт и индусов.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 20-Мрт-24, 19:31
	они перешли на UDP из-за того, что народ congestion algo не могут поменять по-умолчанию, тормозят. фактически это TCP по UDP с нормальным congestion algorithm И дает он не всегда 0.01%, а в зависимости от условий. Если ваш провайдер жадный и у него внешний канал до 100% доходит, то там он вообще незаменим будет. (А такие провайдеры есть, например Центртелеком в Сочи).
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

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

	94. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+/–
	Сообщение от Я (??), 22-Мрт-24, 14:01
	протокол предназначения.. Выяснить, не на Скеллиге ли пакеты Выяснить, не в Велене ли пакеты Выяснить, не в Новиграде ли пакеты
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+1 +/–
	Сообщение от Аноним (52), 20-Мрт-24, 23:58
	> Потому что не нужно использовать протокол не предназначенный для этих целей. В RFC 768 во введении чётко указано для чего нужен UDP. Прочитай, там всего пять предложений, много времени не займёт. После этого можешь начинать объяснять, что не так с HTTP по UDP.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

25. "Атака на протоколы на основе UDP, приводящая к зацикливанию ..."	+3 +/–
Сообщение от Аноним (25), 20-Мрт-24, 11:31
Фаерволлы настраивать в 21 веке не принято, что и говорить.
Ответить | Правка | Наверх | Cообщить модератору

29. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+2 +/–
Сообщение от ИмяХ (ok), 20-Мрт-24, 12:25
>>UDP >>вернёт ответ Что за бред я сейчас прочитал? UPD протокол в принципе не подразумевает ответов.
Ответить | Правка | Наверх | Cообщить модератору

	32. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+5 +/–
	Сообщение от 1 (??), 20-Мрт-24, 12:47
	UDP не подразамевает, а сервис совсем даже требует (например DNS).
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Big Robert TheTables (?), 20-Мрт-24, 13:18
	не совсем относится к данному случаю, но вообще UDP в 99% случаев имеет статусный ответ, просто он приходит по ICMP. Повторная отправка на непрослушиваемый порт вернет отправителю ошибку в linux. Это интересная системная специфика, описана в man 7 udp.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	38. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+1 +/–
	Сообщение от Аноним (38), 20-Мрт-24, 14:45
	Пожалуйста почитайте и попытайтесь понять статью прежде чем комментировать.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	79. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+1 +/–
	Сообщение от Аноним (79), 21-Мрт-24, 12:27
	Скорее всего вы со своим ответом мимо кассы. Человек формально рассуждает (в доказательном ИТ так), что протокол UDP сам по себе не отвечает, а отвечают багованные сервисы. На бытовом уровне все понятно, но любой формальный ревью тех. документации статья не пройдет. Я бы предложил всем вам и топикстартеру быть более лояльными, но понимаю, что бесполезно.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (37), 20-Мрт-24, 14:47
	Новость не читаем? Речь о *прикладных* протоколах поверх UDP.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

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

	60. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Sem (??), 20-Мрт-24, 19:33
	ACK*
	Ответить | Правка | Наверх | Cообщить модератору

34. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
Сообщение от Big Robert TheTables (?), 20-Мрт-24, 13:08
Друзья, пришлите бригаду разъяснительную по вот этому моменту в рфц3704:    RFC 2827 recommends that ISPs police their customers' traffic by    dropping traffic entering their networks that is coming from a source    address not legitimately in use by the customer network. Как же так - дропать трафик, который не из твоей сетки. Если хост на периметре, у него весь трафик извне. Что имеется в виду?
Ответить | Правка | Наверх | Cообщить модератору

	40. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (37), 20-Мрт-24, 14:53
	Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт трафик с адресов, которые не выделены провайдером для этого клиента, то такой трафик дропать.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Big Robert TheTables (?), 21-Мрт-24, 11:46
	> Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт > трафик с адресов, которые не выделены провайдером для этого клиента, то > такой трафик дропать. отлично, логично. Тут получается как бы вопрос сетевого этикета. "Социальный рейтинг" клиентов вести, кто чаще косячит - тому выговор
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (52), 24-Мрт-24, 00:40
	Не надо изобретать никакого социального рейтинга и выговоров. Учёт трафика для биллинга надо делать до фильрации. Если клиенту хочется посылать какую-то хрень, пусть шлёт. Я-то со своей стороны и алерт отправлю, и даже может быть какую-то часть счёта прощу в случае серьёзных проблем или взлома у клиента, но пока не изобретут роутеры с неограниченной пропускную способностью, иначе не имеет смысла делать.
	Ответить | Правка | Наверх | Cообщить модератору

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

	50. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	–3 +/–
	Сообщение от Аноним (21), 20-Мрт-24, 16:49
	RFC не стандарт, поэтому идёт лесом.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Big Robert TheTables (?), 21-Мрт-24, 11:47
	> Это значит что ты как isp знаешь какие адреса ты выделил клиенту. > И если от клиента идёт трафик с исходящими адресами не из > диапазона данного клиента, то надо бы этот трафик дропать. Более того, > говорится что делать это нужно на стыке твоей сети с клиентской Да, разобрались, благодарю, это направление исходящего трафика обозначено.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

36. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+1 +/–
Сообщение от Аноним (36), 20-Мрт-24, 14:19
Про RFC 3704 Стандартная рекомендация уже лет тридцать: Правило: any мойсервер протокол Должно быть заменено на: (Всё кроме моей сети) мойсервер протокол Как раз во избежании атак такого типа
Ответить | Правка | Наверх | Cообщить модератору

	55. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (55), 20-Мрт-24, 18:31
	а толку?
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (55), 20-Мрт-24, 18:34
	пока не будет наказания за халатное отношение, так и будем все участвовать в ддосах.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (52), 24-Мрт-24, 00:42
	Сама виновата, не надела бы короткую юбку — не изначиловали бы.
	Ответить | Правка | Наверх | Cообщить модератору

74. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
Сообщение от qweo (?), 21-Мрт-24, 06:30
Quote of the day есть и поверх TCP
Ответить | Правка | Наверх | Cообщить модератору

	80. "Атака на некоторые протоколы на основе UDP, приводящая к зац..."	+/–
	Сообщение от Аноним (79), 21-Мрт-24, 12:31
	Зачем дуплекс для одной строки текстовой? UDP здесь - верный выбор.
	Ответить | Правка | Наверх | Cообщить модератору

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

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