Координационный центр CERT (компьютерная группа реагирования на чрезвычайные ситуации), опубликовал предупреждение о серии уязвимостей в реализациях различных прикладных протоколов, использующих в качестве транспорта протокол UDP. Уязвимости могут использоваться для организации отказа в обслуживании из-за возможности зацикливания обмена пакетами между двумя хостами. Например, атакующие могут добиться исчерпания доступной пропускной способности сети, блокирования работы сетевых сервисов (например, через создание высокой нагрузки и превышение ограничения интенсивности запросов) и реализации усилителей трафика для DDoS-атак...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60814
>>23 тысячи уязвимых TFTP-серверовПодскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу?
обновить циску провайдера
Ты не поверишь, но чего только не вывешивают наружу :-)
> Ты не поверишь, но чего только не вывешивают наружу :-)Ну да, знаю, какой-нить монстрософт на принтеры в офезе вполне может белых IP наляпать... Но всё же :).
у ipv6 белые и пушистые. Не только лишь все вспоминают прикрыть их фаерволом.
> у ipv6 белые и пушистые. Не только лишь все вспоминают прикрыть их
> фаерволом.Подскажите, а TFTP работает по IPv6? :) (мой домашний чисто по IPv4 пашет, про второй вариант я как-то и не думал :) )
конечно пашет, кто же ему запретит?
Не для нужд, а в силу "раз-раз-и-поехали-в-продакшн", может кажется любой сервер/протокол вывешен наружу оказаться.
Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в девайс.
> Какие-нибудь Микротыки додумаются, чтобы прошивки обновлять через иент сразу в девайс.e-boot в натуральную величину, ага...
Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп не грузится и под рукой нет ничего кроме инета, то почему бы и нет
> Вообще есть сервис загрузки ОС через PXE сразу из интернета, если комп
> не грузится и под рукой нет ничего кроме инета, то почему
> бы и нетТакое есть у Apple с их Internet Recovery. Но там вроде бы не tftp, посложнее. А вы какой сервис имели ввиду, можно ссылку?
Ну вот у меня был лет шесть, если не семь, публичный PXE/IPXE эндпоинт для загрузки по сети в популярные линуксы. На пике под сотню клиентов в неделю обслуживал. А потом набежали какие-то боты из ЮВА, стали выжирать полосу и всем портить праздник. Сперва боролся, но по итогу надоела эта возня и я его от интернета отрубил.
ОО аноним, вы ещё не видели, как они питание и интернет проводят - сразу бы поняли, что нужно фейс контроль (баним по IP)
Для остальных есть EFI HTTP Boot, где поддерживается HTTPShttps://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot
Довольно глупый вопрос. Для "вывешивания наружу" не нужно прикладывать сил, в отличие от закрытия. Вопрос зачем его закрывать.
> Подскажите, с целью повышения уровня образованности. А для каких нужд может понадобиться вывешивать TFTP наружу?Потому как это простой способ сделать работу. Без оверинженеринга, недушно достичь иллюзии. На недолгое время.
Поэтому впн по UDP уже примерно неделю, как не работает?
Нет, не поэтому
А почему? Чем VPN-то помешал?
обеспечивает доступ к противоправной информации..
Работает.
Потому что не нужно использовать протокол не предназначенный для этих целей.
Есть TCP и используйте его для транспорта данных по типа клиент/сервер, а UDP оставьте для медиа/игро-контента "в одну сторону".
А то придумали уже HTTP на UDP переводить, из-за мнимых 0.01% прироста производительности.
Будто никто не помнит проблем с uTorrent-ом, когда они решили гонять торренты по UDP..
там не с uTorrentom проблемы были. а кое-с-чем другим. провайдеры халтурно шейпили юзерский трафик.
Нет, uTP при высокой загрузке сети начал швырять еще более мелкими пакетами, перегружая оборудование провайдеров аццким PPS.
TCP крайне уязвим к потерям пакетов. Это называется Head of Line blocking.UDP этому не подвержен, потому что не соблюдает порядок приёма пакетов.
Поэтому там не мнимые 0.01 прироста, а прирост на порядки, если ваш протокол уровня приложения умеет не ждать переотправки каждого очередного пакета, а либо собирать их в буфер и запрашивать ретрансмит только потерянных, либо просто игнорировать (например, когда это телефонный звонок).
Если у вас теряются пакеты, это не вина протокола, а линии связи.
Вот так смузихлебы захватили весь мир. Может ещё в джаваскрипт и в браузер закниуть всю логику работы юдп и тцп.
ДНС и другие вещи уже забили гвоздями.
Вина линии связи, но ответственность перез клиентом -- ваша.В идеальном мире, конечно, пакет, потерянный БС будет ей же и ретрансмитнут. Но тогда возникнет коллизия, когда пакеты "правильных" клиентов ретрансмитятся быстрее и в большем количестве. Вы же этого не хотите?
Значит ретрансмитить будем end-to-end.
А если e2e, то всё равно ваша машина (которая крайне мало знает о состоянии канала) будет заниматься контролем потока, этого не избежать.
А поскольку большинство программистов заниматься контролем потока не хотят (да и не умеют), и трудно за это их винить, у нас появился system-level TCP. Что, вообще говоря, нонсенс, потому что требования всех приложений разные.
Какая коллизия? про окна в тцп никто не читал и фрагментацию/дефрагментацию.
С таким подходом приложение всё должно делать. А так то, что в ОС работает - оно же неправильно работает.
А у вас есть возможность влиять на линии связи, особенно, если это не ваша последняя миля?
Линии связи имеют конечную пропускную способность. Кроме того, случаются ошибки. Поэтому потери пакетов на TCP/IP сетях в общем случае - это норма, а не исключение. Подробнее vk.com/tcpipquality
Ну да, как правило, в локальном периметре потеря пакетов наблюдается раз в сутки (в основном из-за электрики). А интернет - это куда более многогранная вещь, но и там потери минимальны, а причиной тому - древние технологии или кривые ручки. Поэтому строить поверх удп можно, но выглядит странно, т.к. при низких задержках и высоких потерях проблемы явно нужно решать, а не заметать под ковер
> Если у вас теряются пакеты, это не вина протокола, а линии связи.Линии связи объективно неидеальны и теряют пакеты, и ничего ты с этим не сделаешь.
погоди, не мешай ему жить в мире сферических коней в вакууме
> Если у вас теряются пакеты, это не вина протокола, а линии связи.Расскажи эту мантру беспроводным сетевым технологиям, чудило. Там потери пакетов или всплески латенси совершенно штатное состояние дел. Не свидетельствующее о проблеме.
Зато когда TCP одупляет полчаса по причине "поезд проскочил тоннель" - да, это очень круто. Чтобы от него избавиться везде где можно и нельзя.
Проблема беспроводных систем не должно нарушать логику тцп. Оно совсем не про то. Оно про упорядоченную отправку пакетов адресату. Т.е. поток (stream). А вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий. Зато задержки низкие говорят они. Так они в нормальных условиях и на тцп низкие, если нет потерь пакетов.
> Проблема беспроводных систем не должно нарушать логику тцп.Кому нужна эта логика, нужно чтобы работало.
> вместо этого лепят неупорядоченный юдп и пытаются собирать эти пакеты в буфере там всяких браузеров и всяких поделий.
Чем это хуже, чем собирать в буфере всяких ядер и всяких сетевых стеков? Или ты думаешь, в тцп пакеты магическим образом приходят в том же порядке, в котором отправлены были?
Это не магия, это то чем занимается tcp/ip стек ядра. А тут смузихлебы предлагают это всё отбросить и делать свои поделия в приложениях.
Им же нужно юдп гонять для хттп. Задержки низкие говорят они. Днс надо заворачивать в хттп, безопасно говорят они. И вообще всё надо завернуть в хттп и json, так удобней читать говорят они.
> Если у вас теряются пакеты, это не вина протокола, а линии связи.Покажешь как данные без потерь передавать или кроме 127.0.0.1 в жизни никуда не коннектился?
> Если у вас теряются пакетыНе обязательно прям потеря. Может быть и просто "переупорядочивание" пакетов и периодические небольшие "затыки" (даже и без потерь). А в итоге tcp то плохо разгоняется, то слишком быстро разгоняется, то начинает непонятно чего ждать (а переспросить стесняется).
> вина... линии связи.
Там ещё и embedded бывает, у которого просто буферы маленькие, а обмен очень интенсивный. И в итоге потери/затыки ловятся даже при прямом подключении комп-железка.
В принципе, подобные проблемы возникают даже на ПК (faq по настройке txqueue len). На одном компе старый realtek умеет только 256 пакетов в буфер, а другой комп через tplink отправляет по 1000 пакетов. Процессор на приёмной стороне в C6 (там вообще тактирование ядра выключено - PLL off) м проснётся только через 100+мс. за это время можно очень много чего передать... в никуда. Естественно что-то потеряется.
Даже если C6 не нравится - приоритет прерываний от видеокарты обычно выше, чем приоритет прерываний от сетевухи. Пока иксы ждут/обрабатывают очередной vsync (16 мс при 60Hz), буфер сетевухи успевает пару раз переполнится (если вдруг пойдёт куча мелких пакетов).В общем, реальность - это штука сложная... и добиться чтобы "без потерь" бывает тяжеловато.
И чем в этой ситуации вам поможет обработка в приложении? Будет затык ещё на контекст свиче, а дальше что?
> Будет затык ещё на контекст свиче, а дальше что?Дальше может быть переполнение приёмного буфера и потеря пакета. Когда-то случится ретрансмит. В случае 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. А возможно и из-за чего-то ещё...
Ой видите ли гугол решил, значит это правильно. Ждут не потому что тцп, а потому что ключи ssl надо передать, установить сессию и т.д.
И всё идет к тому, что грубо ломают модель OSI.
линии связи будут дырявые это можно только принять. помехи и точки отказа с ростом сети только чаще встречаются. поэтому приходится переходить на протоколы менее чуствительные к качеству линии связи.
Отбрасывание пакетов - фундаментальный механизм и вообще modus operandi TCP. Congestion control потому что.
БРЕД.
Это как раз таки TCP максимально точный в передаче о чём куча статей от профессионалов написано и я их читал, а UDP как раз-таки с потерями идёт by design.
Вы путаете. Протокол не уяввим, а congestion algorithm, который за это отвечает, обычно спроектирован в 80х годах и никто не парился особо.
Гугл сделал новый, но до сих пор никто на него не перешел, типа " и так сойдет".
Поэтому им пришлось использовать UDP вроде как временно. Но, похоже, мир настолько консервативный, что придется его оставить надолго
Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага. Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли. Вы всё равно навесите поверх свою реализацию, только при этом проиграете на том, что не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.
>Про то, что TCP уже давным давно посылает не по одному пакету и ждёт ACK, а шлёт сразу целую кучу пронумерованных пакетов и ждёт на каждый из них отдельно ACK, сдвигая постепенно окно, конечно же говорить никто не будет, ага.Можем и сказать, и это хорошая штука, но мера "половинчатая". То есть, это позволяет не зависеть от последовательности p-a-p-a-p-a, но всё равно не позволяет получать p-пакеты не по-порядку, потом запрашивая пропавшие.
>Только не надо утверждать при этом, что HTTP всё равно летать по UDP быстрее будет - вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли.
Неправда ваша. Во-первых, не всё, что мы делаем, это HTTP. Во-вторых, см цитату выше. Сейчас уже никто не рендерит страницу "сверху вниз", страница получается целиком, потом рендерится. В этом смысле порядок сообщений вам не очень-то нужен. Вам нужно получить страницу целиком.
Это не значит, что порядок сообщений _никогда_ не нужен.
> не сможете контролировать наполнение канала связи, т.к. UDP просто не способен это делать.TCP строго говоря тоже не способен. Он "аккуратно" разгоняется, чтобы не превысить лимиты. А контроль наполнения идёт по обратной связи - получению ACK (частично можно и по icmp). Если не видно ACK - значит где-то что-то переполнилось и потерялось. Если ACK приходят быстро и в большом количестве - можно уверенно разгоняться дальше.
Улучшить это можно, но нужно знать особенности канала связи (хотя бы скорость, время пинга и примерный процент потерь). Универсальным алгоритмом, который работает неизвестно с каким каналом связи это тяжело сделать.
Ну и тут правльно заметили - большинство алгоритмов проектировалось для сетей 80-х и 90-х... С тех пор много чего поменялось. Новые алгоритмы есть, но их надо вручную втыкать и этим вообще единицы занимаются.
А ещё есть ECN...
Можно там всё при желании.
> 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 готовили к включению в дефолте.
> Можно там всё при желании.
>> 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, если оно настроено в ОС, то будет работать для всех.
Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений. И с точки зрения приложения ни TCP ни UDP часто не подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге спор а что же лучше перерастает в холивары.SEQPACKET часто будет лучше, но он слабо распространён и не имеет "правильного и однозначного" решения (это так важно, что прям пипец как важно! НЕ МОЖЕТ СУЩЕСТВОВАТЬ корректной реализации SEQPACKET, которая подойдёт всем; остаются перекосы либо в сторону TCP, либо в сторону UDP, а как сделать правильно - непонятно...).
Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP), или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос.
> Про application level правильное замечание. Все эти протоколы нужны для обслуживания приложений.
> И с точки зрения приложения ни TCP ни UDP часто не
> подходят. SCTP/DSCP почаще подходит, но тоже не всегда... И в итоге
> спор а что же лучше перерастает в холивары.Ну хз что там подходит, что нет. Понятно, что чем ждать стандартизации и распространения во всех ОС/железках очередных фишек TCP, проще с точки зрения разрабов приложения нагородить быстро своё поверх UDP. Но, imho, правильнее было бы иметь всё таки по итогу какой-то более-менее стандартизированный набор расширений для TCP или UDP для online игр, видеовещания и т.п., которые бы со временем поддержали все на уровне ОС/железа. А разрабам надо было только выставить верные флаги в вызове socket(), что бы получить требуемый сервис. И не городить всякое.
> Поэтому разработчикам приложений приходится выбирать - разбирать пакеты в потоке (TCP),
> или нумеровать пакеты UDP и делать досылку (и еще правильно разбить/нарезать
> пакеты, т.к. размер датаграммы ограничен). Вот собственно и весь вопрос.Так и живём.
> вам всё равно понадобятся ВСЕ данные в том порядке, в каком они пришли.Нет, если используется multiplexing потоков внутри этого одного соединения. Следует из высказывания выше про Head of Line Blocking. А QUIC это делает, только не знаю на каком уровне это задействовано в браузерах.
Если у тебя работает SACK и протокол приложения не умеет работать с потерей части инфы (например http-запрос против видеовещания), то разницы быть заметной не должно между udp и tcp. Один хрен, что там, что там надо ждать дополучения опоздавших перед началом обработки.Плюс, tcp в отличии от udp имеет window и всякие congestion control алгоритмы, что позволяет не добивать канал, когда он уже и так забит. udp же, если не реализовывать это в приложении, этого не умеет. Если реализовывать, то какой смысл? В итоге получится tcp в userspace.
TCP в сообщения заданного размера не может. Тогда уж SCTP. Может и в поток, и в дейтаграммы.
SCTP был бы неплох, если бы не требовал замены полинтернета. Ибо железки его на L4 не умеют.
Ты что бобо?
Для игро контента.
Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов.
UDP в целом это как сжатие с потерями. Где-то что-то заглючит.
> Ты зайди в CSGO и поной с тикрейта из-за того что UDP это НЕНАДЁЖНОЕ доставко пакетов.
> UDP в целом это как сжатие с потерями. Где-то что-то заглючит.Расскажи это какому-нибудь QUIC ака HTTP/3. Тебе не приходило в голову что из ненадежного слоя всегда можно сделать - надежный? Переотправкой пакетов как раз.
А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачи. За это TCP и выпадает постепенно из фавора. Если в Linux еще появились алгоритмы которые сносно живут и с таким, то в какой-нибудь винде оно будет так как сделает какой-нибудь майкрософт своими криворукими индусами, и фиг оспоришь.
> А вот отказаться от медвежьих услуг TCP в вопросах congestion control - роняющим скорость и латенси конекции в плинтус при минимальной потере пакетов или задержке (типичных для беспроводки) - удачиАга, если не контролировать наполнение канала, то и никаких проблем с ронянием скорости не будет, верим. Может проблема в том, что ваша система настроена через одно место и можно было бы выбрать алгоритм congestion control более подходящий для вашей сети? Спойлер: они есть, и много, и в том числе для минимальных задержек, и их тоже больше чем один.
> Ага, если не контролировать наполнение канала, то и никаких проблем с ронянием
> скорости не будет, верим. Может проблема в том, что ваша система
> настроена через одно место и можно было бы выбрать алгоритм congestion
> control более подходящий для вашей сети? Спойлер: они есть, и много,Вот и сделай ЗБС. Всем хомячкам с андроидом. Чо-чо, всего пару миллиардов окучать? Во, приступай. И еще эвон сколько юзеров винды, удачи в настройке.
А, да, если ютуб-плеер не может послать запрос на чанк видео со своей стороны - потому что у винды хзкакая там логика туповэйтинга - окей, а сервер чанков не телепат, и даже если нарулит со своей стороны более другой congestion - то это ему не поможет. Ибо какой чанк захочет юзер он заранее не знает. А в винде - см. про майкрософт и индусов.
они перешли на UDP из-за того, что народ congestion algo не могут поменять по-умолчанию, тормозят.
фактически это TCP по UDP с нормальным congestion algorithm
И дает он не всегда 0.01%, а в зависимости от условий. Если ваш провайдер жадный и у него внешний канал до 100% доходит, то там он вообще незаменим будет. (А такие провайдеры есть, например Центртелеком в Сочи).
> Потому что не нужно использовать протокол не предназначенный для этих целейНет никаких предназначений протоколов, вы это придумали в силу неграмотности. UDP от TCP отличается не дуплексностью и не клиент-серверностью, а упорядочиванием пакетов и ретраями. Там где последние не нужны или там где в TCP они работают не подходязим под задачу образом будет использоваться UDP, и вас не спросят.
протокол предназначения..Выяснить, не на Скеллиге ли пакеты
Выяснить, не в Велене ли пакеты
Выяснить, не в Новиграде ли пакеты
> Потому что не нужно использовать протокол не предназначенный для этих целей.В RFC 768 во введении чётко указано для чего нужен UDP. Прочитай, там всего пять предложений, много времени не займёт. После этого можешь начинать объяснять, что не так с HTTP по UDP.
Фаерволлы настраивать в 21 веке не принято, что и говорить.
>>UDP
>>вернёт ответЧто за бред я сейчас прочитал? UPD протокол в принципе не подразумевает ответов.
UDP не подразамевает, а сервис совсем даже требует (например DNS).
не совсем относится к данному случаю, но вообще UDP в 99% случаев имеет статусный ответ, просто он приходит по ICMP. Повторная отправка на непрослушиваемый порт вернет отправителю ошибку в linux. Это интересная системная специфика, описана в man 7 udp.
Пожалуйста почитайте и попытайтесь понять статью прежде чем комментировать.
Скорее всего вы со своим ответом мимо кассы. Человек формально рассуждает (в доказательном ИТ так),
что протокол UDP сам по себе не отвечает, а отвечают багованные сервисы.На бытовом уровне все понятно, но любой формальный ревью тех. документации статья не пройдет.
Я бы предложил всем вам и топикстартеру быть более лояльными, но понимаю, что бесполезно.
Новость не читаем? Речь о *прикладных* протоколах поверх UDP.
Не надо путать "ответные пакеты" и подтверждающие пакеты (ACT).
ACK*
Друзья, пришлите бригаду разъяснительную по вот этому моменту в рфц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.
Как же так - дропать трафик, который не из твоей сетки. Если хост на периметре, у него весь трафик извне. Что имеется в виду?
Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт трафик с адресов, которые не выделены провайдером для этого клиента, то такой трафик дропать.
> Здесь "their" относится к ISP. Т.е. если от клиента (к провайдеру) идёт
> трафик с адресов, которые не выделены провайдером для этого клиента, то
> такой трафик дропать.отлично, логично. Тут получается как бы вопрос сетевого этикета. "Социальный рейтинг" клиентов вести, кто чаще косячит - тому выговор
Не надо изобретать никакого социального рейтинга и выговоров. Учёт трафика для биллинга надо делать до фильрации. Если клиенту хочется посылать какую-то хрень, пусть шлёт. Я-то со своей стороны и алерт отправлю, и даже может быть какую-то часть счёта прощу в случае серьёзных проблем или взлома у клиента, но пока не изобретут роутеры с неограниченной пропускную способностью, иначе не имеет смысла делать.
Это значит что ты как isp знаешь какие адреса ты выделил клиенту. И если от клиента идёт трафик с исходящими адресами не из диапазона данного клиента, то надо бы этот трафик дропать. Более того, говорится что делать это нужно на стыке твоей сети с клиентской
RFC не стандарт, поэтому идёт лесом.
> Это значит что ты как isp знаешь какие адреса ты выделил клиенту.
> И если от клиента идёт трафик с исходящими адресами не из
> диапазона данного клиента, то надо бы этот трафик дропать. Более того,
> говорится что делать это нужно на стыке твоей сети с клиентскойДа, разобрались, благодарю, это направление исходящего трафика обозначено.
Про RFC 3704 Стандартная рекомендация уже лет тридцать:Правило: any мойсервер протокол
Должно быть заменено на:
(Всё кроме моей сети) мойсервер протоколКак раз во избежании атак такого типа
а толку?
пока не будет наказания за халатное отношение, так и будем все участвовать в ддосах.
Сама виновата, не надела бы короткую юбку — не изначиловали бы.
Quote of the day есть и поверх TCP
Зачем дуплекс для одной строки текстовой?
UDP здесь - верный выбор.