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

Атака на протоколы на основе 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) 1,2,15,25,29,34,36,74

Сообщения

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

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

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

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