| 1.1, 11111001010 (?), 13:33, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Уже версия 1.4, а я об этой платформе впервые в жизни слышу. Почему о ней мало говорят?
| | |
| |
| 2.3, Антон 19887234 (?), 14:13, 30/11/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
По той же причине, почему операторы в свое время отказались от DPI для ограничения торрентов: магистральные каналы, магистральное оборудование DWDM и пакетной сети стали дешевле, чем DPI.
11 Гбит/с на сервер - это раз в 7 меньше, чем граница экономической целесообразности использования этого решения.
| | |
| |
| 3.4, WE (?), 14:50, 30/11/2023 [^] [^^] [^^^] [ответить]
| +/– |
 Это в каком у вас манямирке операторы отказались от DPI?
Первейшая маркетинговая потребность ограничения полосы для оператора - это пакетирование услуг, потом идёт приоритизация, далее это защита от невалидного трафика и последнее это фильтрация. Плюс есть сопутствующие услуги, типа анализ протоколов и сервисов, что тоже любит маркетинг.
А не слышали вы о таких проектах, потому что колхоз-телекомов всё меньше, и они на б.у. оборудовании сидят.
| | |
| |
| 4.10, Антон 19887234 (?), 16:54, 30/11/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
В том мирке, где живут операторчики типа 3216, 12389, 20485. Имя Ибрагим... тьфу ты. Номерки эти вам о чем-то говорят?
| | |
| |
| |
| Часть нити удалена модератором |
| 6.14, Антон 19887234 (?), 18:26, 30/11/2023 [ответить]
| +/– | |
Чтобы резать полосу DPI не нужОн, дорогуша! Сейчас любое PS Core искаропки по возможностям уделает любой шпдшный BRAS, не считая поделки красноглазиков. Приоритезация важного, деприоритезация тяжелого и т.п. - это все без DPI накручивается. А зачем? А чтобы не убить радиочастотный спектр говнотрафиком. Всё.
А что же ШПД? А на ШПД такой проблемы нет, там провод. Я уже писал выше, что ставить любую железку "в разрыв" и что-то там резать не выгодно, дешевле расширить емкость под этот трафик.
Уссываюсь, друзья мои, когда читают маркетинговые писульки всяких отечественных "производителей" потипа СКАТ или РДП.РУ, которые все еще помнят про Торренты! А тех уже менее 5%, даже в самых богом забытых регионах, где, казалось бы, скорости не должны позволять смотреть онлайн.
И да, ты сделала ошибку, МегаФно в списке замени на полосатых, и получишь большую магистральную тройку РФ)))
| | |
| 6.15, Антон 19887234 (?), 18:30, 30/11/2023 [ответить]
| +/– |
А про b2o что же не вспомнил? Там режут еще смешнее - полисёрами на интерфейсах! А как же DPI, спросишь? А никак полисёр режет идеально 1,2,3,5 гиг, 10,15,20, 80, 100 и более гиг)
| | |
|
| 5.16, Аноним (16), 18:33, 30/11/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ещё бы не говорили! Обычно эти первые в списке подозреваемых, вместе с 4812, 4134 и тому подобными, в случае атак разных скаммеров, скриптикиддисов и прочей шелупони. Особенно клиенты из финтеха их «любят»: просят заблэкхолить ещё до поднятия сессии.
| | |
| |
| 6.36, Антон 19887234 (?), 09:25, 01/12/2023 [^] [^^] [^^^] [ответить]
| –2 +/– |
Китайцы умеют играть в монополию, а наши долб0ебы нет.
Поэтому у них китайский IP-транзит стоит $100 за Мбит/с, а у нас - $0.3.
Три компании договорились и держат планку, не отдают себя задешево: CT, CU, CM.
В РФ три компании не смогли договорится, и просадили стоимость донельзя: ВК, РТ, ТТК.
Кто-то выиграл от этого? Да, антимонопольщики!
| | |
| |
| 7.46, Аноним (16), 20:31, 01/12/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Кастомеры выиграли и все операторы, которые в обход той монополии могут трафик в/из APAC доставить. А учитывая кто с какой стороны забора оказался со всеми этими геополитическими движениями, то похоже, что скоро транзит китай будет продавать только в рф, а рф — только в китай. Такой вот чебуркванмён получается.
| | |
|
|
| 5.30, 1 (??), 23:28, 30/11/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы шутите? У этих операторов DPI на транзитном трафике. Никогда не видели заглушку о заблокированном в РФ сайте от Билайна, при попытке, например, зайти на хост в Казахстане из Европы?
| | |
| |
| 6.33, Антон 19887234 (?), 09:18, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
Разуй глаза и почитай о чем речь. Про блокировки речи нет в принципе, и DPI там крайне ограниченный, к ограничению скорости или перемаркировке QoS отношения не имеющий.
| | |
|
|
|
| 3.5, Аноним (5), 14:57, 30/11/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Но для локалок малых и средних бизнесов может быть актально.
| | |
| |
| 4.27, нах. (?), 21:27, 30/11/2023 [^] [^^] [^^^] [ответить]
| +/– | |
точнее для малых и очень малых. Где не магистральное подключение а сопли из стены и на них wifi роутер на всю эту подвальную лавку. Вот у них и "заикается голосовой чятик если рядом качать видио в 4k"
А у средних все же уже принято иметь свою AS, нормальные подключения к нескольким кормушкам и им тоже проще попросить поднять тариф на следующую ступеньку и не париться (а эта поделка у них попросту лопнет)
| | |
| |
| 5.35, Антон 19887234 (?), 09:21, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ребятушки! Малые и очень малые - это компания из 1-2 человек, где директор=бухгалтер=монтажник=админ. Поставил микротиков кое-как настроенных и собирает копеечку. Никаких проблем с чятиками там не решается, т.к. уровень понимания техники там житейский: пакеты идут как говно в канализации, чтобы устранить узкое место (засор) нужно побольше открыть вкладок в браузере, авось продавит!
| | |
| |
| 6.38, нах. (?), 11:56, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Ну да. Именно для них оно и будет рабочим решением. Ну или для продавана решениев таким вот - как наш анонимный друг и заподозрил, наткнувшись на характерную табличку.
> Никаких проблем с чятиками там не решается, т.к. уровень понимания техники там житейский
кто побогаче - вызывает канализатора, тот ему узкое место и устраняет как умеет. Ну вот например таким образом.
И вроде как даже чятик начинает работать (а видос ну и хрен с ним что тормозит, все равно его монтажнику-бухгалтеру в рабочее время неположено было смотреть)
| | |
|
|
|
|
| 2.17, pofigist (?), 19:16, 30/11/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Потому что QoS принято настраивать на коммутаторах, а это поделие и 1mpps прокачать не сможет.
| | |
| |
| 3.34, Антон 19887234 (?), 09:19, 01/12/2023 [^] [^^] [^^^] [ответить]
| –2 +/– |
QoS принято настраивать везде, где есть компетентные сотрудники.
Если сотрудник (или это Вы и есть) говорит, что у нас нет перегрузок и QoS не нужно настраивать - то выдайте ему трудовую на руки и пенделя под зад.
| | |
| |
| 4.39, нах. (?), 12:02, 01/12/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> QoS принято настраивать везде, где есть компетентные сотрудники.
некомпетентные ты хотел сказать?
qos не имеет смысла на дешевом оборудовании и дохлых каналах - чего ни настраивай, один вред от него (потому что ты на и так узком канале создаешь бутылочные горлышки - ну это в предположении что оно вообще работает как ты думаешь а не как на самом деле)
Если у вас есть перегрузки - расширяйте канал, это по другому не работает и бессмысленный костылепердолинг.
Ну и там вон ниже коллега пограмотнее вам расписал ЧТО на самом деле надо настраивать вместо того что вы понимаете под qos, можете оценить сколько процентов слов вы просто не понимаете, и сколько из оставшихся понятными (примерно 20?) поддерживает ваше оборудование (дайте угадаю - нисколько)
| | |
|
|
|
| 1.6, Аноним (-), 15:22, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
чесно говоря, нам для такого хватало древнего ALTQ с HFSC... Город не миллионник, но всё же.
| | |
| |
| 2.42, нах. (?), 12:38, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
> чесно говоря, нам для такого хватало древнего ALTQ с HFSC... Город не
> миллионник, но всё же.
в 99м году? Ну да, хватало.
| | |
|
| 1.7, Аноним (7), 15:52, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> В проведённом тесте использование LibreQoS позволило снизить задержки при приёме данных со 106 до 9 мс, а при передаче с 517 до 23 мс, ценой снижения скорости непрерывной загрузки с 74 до 25 Mbps и передачи с 29 до 8 Mbps.
Прелестно, прелестно! Платишь, как за оптику, а получаешь адсл...
| | |
| |
| |
| 3.28, нах. (?), 21:29, 30/11/2023 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Еще как различается. Сравнил считай бесплатную опту и медь закопанную в землю (ну и что что при царе горохе, и половина линий сгнила - от этого товарчик только растет в цене!)
| | |
| |
| 4.43, Ананий (?), 12:47, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> и половина линий сгнила
гнило в основном в старых распред. шкафах, которые вполне себе стояли на улице со всеми вытекающими с ржавчиной и окисленными контактами.
решалось бутулкой водки для вечнопьянного монтера
| | |
| |
| 5.44, нах. (?), 14:05, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
ха, в шкафах, кто-то я смотрю любитель легкой жизни.
В канализации под территорией громадного завода не хошь?!
И монтер туда не полезет, он пьянь но не идиот же (я точно знаю, мы вместе бухали). От предыдущего вон - сапоги только нашли. И то летом уже.
С другой стороны, а чего лазить-то, из ста пар еще целых шесть ничего так. И еще десяток...ну для телефонии сойдет.
Есть, есть на свете непреходящие ценности!
А на медь сдать все равно не получится - бомжи пробовали, там если изоляцию просто на костре пытаться сжечь - сгорает к чертям вместе с медью.
| | |
|
|
|
| |
| 3.22, Аноним (16), 20:35, 30/11/2023 [^] [^^] [^^^] [ответить]
| +/– |
Задержки важны постольку поскольку. Куда важднее джиттер, да и тот не всегда. Когда бэкапы льются на другую сторону планеты, мне куда важнее утилизация линка. А вот для видеосвязи, наоборот, нужен минимальный джиттер, даже если rtt высокий (а ниже не сделаешь, физика мешает).
| | |
| |
| 4.49, pofigist (?), 08:32, 05/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
То что джиттер важнее задержек, не отменяет того что задержки важнее потоковой скорости.
Ибо сейчас почти все over https, то есть - tcp, а в нем задержки не позволят утилизировать канал...
| | |
|
|
|
| 1.23, BrainFucker (ok), 20:38, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > повысить надёжность работы ... игр
Этим-то с какой стати? Может ещё о комфорте вейперов в общественных местах позаботиться следует? 🤦
| | |
| |
| 2.51, torvn77 (ok), 18:32, 06/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
 С той что если игра у абонента не пойдёт то он уйдёт к другому провайдеру, при том что монтажные работы при каждом новом подключении включая новый кабель надо выполнять заново
| | |
| |
| |
| 4.54, torvn77 (ok), 12:44, 07/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Провайдеров это не особо волнует, т.к. у всех +/- так же.
Но абоненты будут собираться у тех, у кого +, а не у тех, у кого минус и главное они будут давать рекомендации и звать туда своих знакомых.
И потом, подключение безплатное, то есть если абонент в поисках лучшего слишком быстро отключится то провайдер будет в убытке, так как доход от абонентской платы будет несколько месяцев только покрывать стоимость подключения.
| | |
| |
| 5.55, BrainFucker (ok), 23:19, 07/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> провайдер будет в убытке,
Не будет, игромания это не сильно распространённо явление, тем более для большинства это тупо время убить и пофиг какой там пинг.
| | |
|
|
|
|
| 1.24, Tron is Whistling (?), 20:57, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> 16-ядерным CPU Xeon Gold достаточно для обработки трафика клиентов ISP с пропускной способностью 11 gbit/s
Ну, во-первых, это очень мало.
Во-вторых не указан тип сетевых плат. Если это хотя бы BCM57416 или аналогичные - это не то, что мало, а вообще трындец.
| | |
| 1.25, Tron is Whistling (?), 20:58, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> снизить задержки при приёме данных со 106 до 9 мс, а при передаче с 517 до 23 мс, ценой снижения скорости непрерывной загрузки с 74 до 25 Mbps и передачи с 29 до 8 Mbps
И куда это? На ADSL?
Ну и вообще 106 и 517 - тут имхо надо что-то в другом месте лечить.
| | |
| 1.26, Аноним (26), 21:22, 30/11/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– | |
Новость вызывает у меня бурю эмоций, и я еле-еле сдерживаюсь, чтобы не начать тролить.
Начинаем читать отсюда: https://en.wikipedia.org/wiki/TCP_offload_engine
и главное доходим до Support in Linux.
Пока другие операционные системы (Windows и FreeBSD) активно занимались разработкой собственных решений по оптимизации сетевого Linux ни черта не умел, при чем из принципа. Кстати, в конечном итоге Microsoft сдалась, закрыла свои потуги и адоптировала решения из BSD.
Затем мир перешел на оптические адаптеры по 10, 25 и выше гигабит, и оказалось, что все механизмы Offloading и QoS на самом деле очень нужны, особенно когда дело касается сетевых адаптеров с высокой пропускной способностью. Их нужно правильно готовить с Active Queue Management-ом c LRO/LSO, профилировать Interrupt Moderation, настраивать Receive Side Scaling и с учетом многпроцессорных систем и современных Scalable-процессоров (для режима Sub NUMA Clustering). Всё это существует годами, но в Linux про это мало что знают. А потом вообще пришла RDMA... но тут не в ней дело.
И вот спустя годы Linux оказался без нормального API в ядре для работы со всем этим.
Спасибо Open Fabrics (https://www.openfabrics.org/) за OFED-драйверы
Спасибо DPDK (https://www.dpdk.org/), что и в Linux есть API, но только в юзерспейсе (в этом смысл DPDK)
Результат который мы наблюдаем сейчас:
1. Драйвер Bonding в ядре - это страшный мусор, который нужно удалить. Он не поддерживает вообще ничего
2. LRO, LSO, RSS и Interrupt Moderation есть, но по большей части всё это находится в драйверах
3. Автоматических настроек, профилирования нет. Народ даже ethtool до конца не понимает
4. QoS и AQM на принимающей стороне сетевого стека отсутствует, вместо него есть возможность что-то наваять на **tables.
5. Linux Virtual Switch - мусор из 90-х, который не отвечает современным потребностям
А потом спрашивается, а чего это все коммутаторы проприетарные, даже те, в которых Linux используется... Ну ок, есть Cumulus Linux (желаю удачи его скачать), но он живой пример, как можно сделать проприетарь на базе GPL.
Стыд в том, что настольная версия Windows всё это поддерживает правильно и позволяет себя перенастроить... Шел 2023-й год и в Linux задумались, что у них в сетевом стеке что-то не так. Вся эта беспробудная тупость усугубляется тем, что слишком много людей в Linux верующие фанатики. На этот раз они верят в то, что сетевки Intel - нормальные. Нет! Это адаптеры, в которых сломаны все эти механизмы и в которых каждый год выходит обновление драйвера, выпиливающее что-нибудь, потому что нашли баги. В общем в 2023-ем году вне Mellanox и Chelsio жизни нет. И если в том же Linux максимально пользоваться из драйверами и минимально всем что есть в системе, то оно будет работать.
Дальше эти фантазии про QoS. Я ведь зашел на унылый лендинг LibreQoS (ускорятеля видеоигр через QoS). Я даже видео посмотрел. Было сложно, было стыдно, но я посмотрел! Причем они рассказывают про игры, будто это домашнее решение.
Давайте на минуточку забудем про LibreQoS и ISP-задачи и поговорим, как должен выглядеть современный QoS...
(тем кто в таке гуглите слова сами)
Вот вы включили AQM на стороне сетевого адаптера и роутера. Вы настроили Weghted Random Early Detection (WRED) и Explicit Congestion Notification, который радостно прописался в ваши заголовки IP. Допустим вы настроили DCTCP (Datacenter TCP) как Congestion Control вместо CUBIC и начали уважать ECN для задач управления потоком TCP. Но этого мало, вы должны использовать иерархический QoS для реального разграничения трафика, то есть ваш коммутатор поддерживает Enhanced Transmission Selection (ETS).
У вас нормальный такой коммутатор/роутер, но сетевой адаптер тоже должен всё это уметь (Intel свой забудьте). Например, вы купили NVIDIA/Mellanox и радостно настроили OFED, очереди и QoS, благо для Linux это можно сделать средствами прошивки и драйвера.
И вот он наконец-то у вас появился ваш QoS. Красивый иерархический с дележками на типы трафика и резервацией буфера, с поддержкой Assured Forwwarding (предоставления гарантированной пропускной способности канала). Дальше что?!
DSCP вам удалят при попадании пакетов из вашей сети в сеть провайдера, если только вы не купили L1 через DWDM или L2VPN. А что пройзойдет с QoS, когда провайдер перемаркирует DSCP? Правильно ваш QoS и ваш Congestion Control разуплотняется на субатомные частицы.
А если у вас Datacenter и Storage-сети поверх Ethernet, ваш QoS обязан держать Flow Control на приоритетах 802.1p с использованием Priority Based Flow-controil (PFC) и затем трансформировать их в DSCP в направлении вашей L3-фабрики. Сочетание AQM(WRED)+ETS+ECN+PFC=DCQCN Datacenter Quantized Congestion Notification.
Применение DCQCN позволяет:
- полностью убрать slowstart-образные механизмы и полагаться на PFC, устанавливая соединения со скоростью линка
- не терять пакеты вообще (нет ретрансмитов), потому что у вас ECN сообщает заранее о грядущей перегрузке
- а если источник потока не снизил скорость (Transmission Rate), то за дело возьмётся PFC
Естественно и ваши коммутаторы и ваши сетевые адаптеры поддерживают решения типа PFC Watchdog средствами прошивки, потому что PFC-это peer-to-peer QoS и он может штормить при неверной настройке.
И вот они ваши сетевки наконец-то получили пакеты в буферы. Ура!
Что там за проблема у вас? Снижение задержек на TCP? Обычно люди для таких вещей UDP используют (те же P2P-сети обозначенных в видосе видеоигр), а большинство оффлоадингов типа Large Recieve Offload, он же Receive Segment Coalescing, он же Generic Receive Offload не затрагивает протокол UDP по вполне очевидной причине. В UDP в общем случае нет понятия сессий, и сетевой адаптер не поймет как склеивать UDP пакеты перед отправкой в CPU.
Так что же тогда делает LibreQoS?! И почему пишет про чятики и видеоигры?
То есть какую задачу он решает? Что такое случилось? Предлагает собственную реализацию поллинг из буфера NIC? Собсвенную реализацию RSS? И с каких пор шейпинг помагает задержкам?! Шейпинг их создаёт!!! В этом его суть, он уберает Packet Burst внутрь буфера вместо того чтобы дропнуть или ставить на паузу (PFC) или уведомлять заранее (WRED) огрядущей перегрузке очередей, средствами ECN? Чем они вообще там занимаются?
А давайте посмотрим сюда:
https://libreqos.readthedocs.io/en/latest/docs/Quickstart/networkdesignassumpt
Ох ёж твою медь! Это решение для мамкиного ISP!
Оно не поддерживает MPLS (я не удивлён) и скорее всего VXLAN тоже, причем эти странные личности пишут про OSPF... то есть не eBGP+ECMP, а вот именно OSPF, ну да ладно, это мелочи. Главное что оно сервис в смысле Service Chaining включения, как граничный файрвол, DPI и прочий NAT-перенат. Оно заворачивает на себя декапсулированный трафик. А может задержки снизятся если этой штуки вообще там нет, а вместо этого у вас просто есть QoS на сетевом оборудовании?
Лучше сделать не как бомжи, а распространить Diffserv-домен на всю свою L3-фабрику и сделать правильный мапинг к PCP-приоритетам на L2-границе. Зачем этот костыль, который под капотом решает только одну единственную проблему, проблему убогости ядра Linux и его сетевого стека. И вот после героического решения проблем убогости они на Linux (создание логики очередей поверз eBPF) они создают волшебный QoS, который средствами шейпинга (sic!) снижает задержки. А про уменьшение буферизации за счет установки дополнительного сервера в цепочку на выходе трафика - это прямо анекдот. Ох, что люди только не придумают лишь бы Diffserv не настраивать.
Я к тому что такие решения существуют но они не бесплатные. Тот же SQN QoS, когда теннанты инкапсулируются в VXLAN. Они есть даже как продукты, которые ставятся на Linux, главное только настоящий трафик туда не заворачивать. Оркестрировать и мониторить можно, только не заворачивать трафик, потому что Linux и QoS... ой всё.
Может проще Juniper купить? Или что вам там больше нравится, только нормальное?
P.S. Я такой едкий сегодня, потому что это псевдопродукт, с красивым лендингом, весь такой ускоряющий видеоигры и зумы. А на самом деле - это сервисчейн, который ставит мультифилд-классификаторы и шейпит один трафик в угоду другому, причем так, что создаёт бутылочное горлышко. Я бы понял, если бы это преподносилось как очередной раковый шейпер, который VK сделает быстрее, а Youtube медленнее и привяжет это к тарифной сетке:
https://libreqos.readthedocs.io/en/latest/docs/TechnicalDocs/integrations.html
Ой, так это же оно и есть!
| | |
| |
| 2.48, PnD (??), 12:25, 04/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ну, в общем Вы пожалуй правы.
Но в частности кое-что можно и с linux. Если ограничить хотелки до l2, приоритеты вполне себе разводятся через htb, с очередями pfifo_fast и fq_codel (наследник multiq) по смыслу.
Бондинг как таковой (что LACP что A/S) при такой схемотехнике особых проблем не доставляет.
А вот растегирование vlan в linux, НЯЗ, до сих пор упирается в 1 поток.
В общем, заставить гипервизор пулять полтос (25+25) до ближайшего свитча — вполне реально штатными средствами. Хотя и не бесплатно (особенно в паре с qemu).
Дальше — да, linux — максимум на правах управлялки ASIC'ами в whitebox'е.
| | |
| 2.52, torvn77 (ok), 19:13, 06/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>Linux ни черта не умел, при чем из принципа.
Было вполне оправданное и актуальное сейчас опасение что любое нарушение нейтралитета сети может создать неконкурентные преимущества тем или иным компаниям и дискриминацию остальных компаний не имеющих прямого доступа к телу бмзнесменеджеров провайдера.
>будто это домашнее решение.
Если учесть то, что бутылочное горлышко современных конечных сетей это WiFi то может так оно и есть?
Затормозила вайфайная сетка у гиков вот они и зашевелились.
>Ой, так это же оно и есть!
Значит ещё одна заинтересованная сторона, причём довольно платёжеспособная, хотя для рунета софтварная манипуляция пакетами это плохая новость.
| | |
|
| 1.31, Аноним (31), 04:05, 01/12/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
NetLimiter еще есть. А вообще это не серьезно, эту работу должно выполнять железо.
| | |
| |
| 2.40, нах. (?), 12:04, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– |
> NetLimiter еще есть. А вообще это не серьезно, эту работу должно выполнять
> железо.
а откуда железо узнает - ты видосик из запрещенных сетей в рабочее время смотришь или у тебя конфкол с уважаемыми партнерами из Ирана?
| | |
|
| 1.37, VNV (?), 09:37, 01/12/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как интересно это будет работать в случае нескольких аплинков и ассиметричного трафика?
| | |
| |
| 2.45, нах. (?), 14:07, 01/12/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Как интересно это будет работать в случае нескольких аплинков и ассиметричного трафика?
так же точно как и в случае одного и симметричного.
| | |
|
|
