Мережеве

[kondybas]

Колись давно, ще у дитинстві, довелося мені інтернетизувати місцевий університет. Життє тоді було важке, цілий рік ходили у валянках, їли тільки сало та картоплю, а на локальну мережу з 600+ машин аплінк був всього 192 кбіт через зелакси 2 мегабіта через паргейни.

Звісно, й інтернет тоді був не такий, як оце зараз, ютуби, нетфлікси, торенти, вот ето вот всьо. Тоді всьо було суцільно-чавунне: регет, eD2k і так далі. Одне кіно тиждень зкачували. І потім всі дивилися його по черзі. А оскільки дисципліни в піпла не було ніякої, то одразу з'ясувалося, що хтось міг в одне рило вижерти увесь канал, критично необхідний для учбового процесу. Тому виникла задача регуляції трафіку.

Я перепробував тоді масу тулзів, масу методик та масу софта. І все воно було або криве, або неповне, або незручне. І увесь час в мене свербіло в голові, що я десь щось на цю тему бачив. Аж допоки я з якоїсь нагоди не читав (вкотре) ман IPFW, і не дійшов до DUMMYNET QUEUE. І тут мене зненацька пробило.

ipfw add 7000 queue 100 mask src-ip 255.255.255.255 from ${LAN} to not ${LAN} in via ${LAN_interface}
ipfw add 7100 queue 101 mask dst-ip 255.255.255.255 from any to ${LAN} out via ${LAN_interface}

Фокус в тім, що даммінетівська черга queue при використанні маски перетворюється на мультиплексор, на вході якого автоматично створюються т.зв. динамічні черги (для кожного локального ІР своя), а на вихід пакети від різних клієнтів пропускаються по одному за раз з кожної клієнтської динамічної черги. Грубо кажучи, усе виглядає приблизно отак:

  LAN   --->   WAN
  ----------------
   AAAAA > |
     BBB > | 
CCCCCCCC > | > Z..DCBAZ..DAZ.DC.CAZAZC..
    DDDD > |
  . . . .  |
      ZZ > |

де A, B, C, D .. Z - це пакети окремих клієнтів.

Це на вихід. А на вході стоїть такий самий мультиплексор, тільки розвернутий на 180oC. Ключовим в роботі всієї ботви є те, що кожна динамічна черга має наперед задану довжину, і коли динамічна черга заповнюється на 75%, спрацьовує TCP congestion control protocol - відправнику шлеться повідомлення: пригальмуй. Той зменшує темп відправки пакетів удвоє, якщо знов прийде команда - іще раз удвоє, і так аж доти, допоки заповнення динамічної черги не опуститься нижче 75%. Так відбувається трафік-шейпінг для окремого клієнта.

З іншого боку, якщо в нас глуха ніч, нікого нема і лиш один комп, всупереч правилам ТБ роботи з електрообладнанням, залишений включеним, аби викачать якийсь серіал, то цей клієнтський ІР буде юзати увесь аплінк монопольно, всі 2 мегабіти. А якщо хтось іще засидівся і тицьнув в лінк на сторінку, то поки сторінка грузиться, він буде ділити аплінк з качалкою в пропорції 50/50. Якщо ходити по сторінках буде десяток людей, то в моменти одночасного зкачування вони будуть отримувати по 1/10 полоси аплінку кожен. А оскільки чисто статистично лише мізерна доля клієнтів одночасно тицяють у лінки, не більше, ніж 2-3% від тих 600, що є в локальній мережі, то в нас кожен клієнт буде в середньому використовувати не менше 1/30 від товщини аплінку.

А на практиці до мене через кілька днів прийшла пара просунутих прєподів із питанням, чи не збільшили нам, бува, аплінк, бо працювати стало не просто швидше, а фантастично швидко. Ну, наскільки це можливо для 2 мегабіт, звісно. Окремо зауважу, що проблема "качальщиків", які, здається, збиралися викачати увесь тодішній інтернет "шоб було", вирішилася сама собою. На них стало наплювати.

І це все - двома строчками в конфігу IPFW.

Comments

[tiresome_cat]

Цікаво.

[kondybas]

Цікаво тут те, що це можна реалізувати апаратно. Просто коробочка з входом та виходом, яка втикається між локальною мережею та шлюзом у світ. Православізатор трафіку. Gentle shaper.

[ukurainajin]

Мало що зрозуміло, але дуже цікаво!
З того, що я зрозумів, тут використано щось, що забезпечує рівний розподілений доступ, і ніхто просто не чекає, доки сусіди звільнять лінію. Я правильно зрозумів?

[kondybas]

Саме так. На відміну від поведінки базового мережевого стеку, схема із двома зустрічно-направленими мультиплексорами гарантує, що кожен пакет кожного юзера отримає рівну долю каналу під час передачі.

Більше того, там є можливість встановлювати класи обслуговування. Тобто, бухгалтерський клієнт-банк іде з супер-пріоритетом, відпихаючи вбік будь-який інший трафік. Звичайний бровз іде з середнім пріоритетом. А для всяких р2р-качалок я виділив діапазон портів 64000-65000, і вони вдень повзали по дну, підбираючи крихти, які нікому не дісталися, а вночі утилізуючи канал на 100%

[ukurainajin]

Це конструктивна побічка цієї технології, що дозволило «справедливо» задовольняти всіх, чи воно для того й було задумано?

[kondybas]

Не знаю, чи воно було так задумано відпочатку, але на той час було багато сторонніх софтів, які робили приблизно те саме. Один з них - AltQ - я багато тестив, і так і не зміг отримати бажане. А рішення знайшлося у штатних засобах, що йшли у комплекті.

Абсолютно впевнений, що щось подібне стоїть і в інтернет-провайдерів, і це саме те, що дозволяє їм продавати сотням тисяч клієнтів стомегабітні канали кожному, маючи зовсім не петабітні аплінки. Але на рівні споживацького заліза я тільки в роутер-ос мікротіків бачив можливість вішати мультиплексори з динамічними чергами на інтерфейси. Підозрюю, що це недарма :)

[ukurainajin]

Усюди ілюзія…

[kondybas]

Це не ілюзія, це практичні наслідки теорії масового обслуговування :)

І, між іншим, ви завжди можете отримати свої сто мегабіт, які ви оплачуєте. Тільки вам це швидко набридне, і ви перейдете на звичний режим у 100-200 кбіт/сек в середньому за добу.

[iamjaph]

Цікаво, зараз ще ви використовуєте FreeBSD? І чому?

[kondybas]

Ну, я тримаю декілька віртуалок у вмварі із свіжою фрею. Мені подобається можливість компілювати софт під свої потреби з власними опціями чи специфічними лібами в статиці. Фря якось зручніша і логічніша, хоча це може бути просто давня звичка. В лінуху мені некомфортно, а тренд останніх років на відхід від unix-way в бік моноліту systemd - це просто гидко. Тобто, я розумію, чому це відбувається - задля мінімізації людського фактору при конфігуруванні систем, але чисто концептуально це суперечить базовій ідеї. Що поробиш, софт іде туди, де гроші, а не туди, де вишуканість.

[iamjaph]

Дякую за відповідь.
А я вже 21 рік як десктоп її використовую для розробки програм, які потім на linux працюють. :-)

[sir_dog]

О, пам'ятаю, старі добрі 00-ві! Працював тоді в провайдерській конторі, яка надавала корпоративні канали + інтернет домашнім користувачам через виділені лінії та dial-up. Якраз за тих часів, коли діалап став масово щезати, а виділенки водночас стали для рядового користувача чимось екзотичним і геть нікому не потрібним. Для корпотаривних клієнтів усе гналось через купку цисок, на які за такої нагоди ЦО розкошелився, а от інтернет розподілявся у старий добрий дідівський спосіб - фряха з IPFW, декому через NAT, декому з реальником. В якийсь момент NAT став тупити просто неймовірно, при цьому ще й навантажуючи проц як остання падлюка. Я тоді обгуглився, що ж це може бути, поназбирав усяких різних дампів, залучив старого товариша з універу, що в програмуванні ядра знався краще за мене. Усе полікувалось тюнингом параметру DYN_BUCKETS - вже не пам'ятаю нюансів, але для там начебто для NAT створювалась певна кількість бакетів, щось типу потоків для обробки, і якщо їх було замало то в кожному накопичувалась черга пакетів, зростали колізії і вся ця байда починала сама на собі зауиклюватись. Збільшили кількість бакетів - і все полетіло як пташечка у далеке піднебесся, швидко й гарно. Через деякий час після цього у мене була шабашка на одній конторі зробити розподіл трафіку, де частина внутрішніх клієнтів ходила через NAT, частина з реальниками з викупленої підмережі, я усе налаштував через PF NAT, з ним подібних проблем не виникало.

[kondybas]

"..Усе полікувалось тюнингом параметру DYN_BUCKETS.."

Гиги. Знайома трабла. Між іншим, оскільки kernel NAT реалізовано через той самий DUMMYNET, і той самий параметр впливає й на динамічні черги, мені довелося перезбирати ядро зо три рази, поки все запрацювало, як слід :)

Усе-таки, FreeBSD - видатна система, хоч і не така популярна, як лінух. Я, власне, кілька років заробляв тим, що робив на FreeBSD "корпоративні шлюзи" з усіляким корисним функціоналом. Але з ростом ширини каналів попит на це діло помалу зник. Але, як то кажуть, руки ще пам'ятають :)