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

Атака на протоколы на основе 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]

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

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

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