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.