Обмеження швидкості вхідного трафіку

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

Чи існує якийсь зв’язок між повільним запуском TCP та обмеженням швидкості вхідного трафіку? Чи можливо за допомогою методів, описаних у повільному старті, штучно обмежувати швидкість відправлення відправника?

В якості додаткової уваги слід зазначити, що сервер, на якому я хотів би здійснити формування трафіку, встановлює саме з'єднання PPPoE і виконує функцію маршрутизатора для решти мережі.

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

Менеджери завантажень, швидше за все, працюють так, як це пояснено у " дрібниці" .

Процес, що використовує BSD-розетки, може виконувати власне обмеження швидкості. Для обмеження вгорі, програма може це зробити, просто обмеживши швидкість передачі даних, що записуються в сокет. Аналогічно, для обмеження вниз за допомогою програми програма може обмежувати швидкість зчитування даних, що зчитуються з сокета. Однак причина, чому це працює, не відразу очевидна. Коли програма нехтує читанням деяких даних із сокета, його буфери прийому заповнюються. Це, в свою чергу, призведе до отримання TCP, що рекламує менший вікно приймача (rwnd), створюючи зворотний тиск на базовому TCP-з'єднанні, тим самим обмежуючи його потік даних. Врешті-решт цей ефект "скорочення" досягає обмеження швидкості в кінці. Залежно від буферизації у всіх шарах мережевого стеку, цей ефект може зайняти деякий час для розповсюдження.

Якщо вам періодично потрібно обмежити ставку на одну програму в системі UNIX, просте рішення - це тонка річ . Справжнє формування трафіку, як ви виконували б на шлюзі, можна зробити за допомогою tc. Це задокументовано у розділі 9. Дисципліни черги для керування пропускною здатністю Linux Advanced Advanced Routing & Control HOWTO.

У випадку з модемом 56 к порівняно з лінією DSl 4 Мбіт / с, зазвичай немає форми, що робить різницю швидкості, це лише різниця у швидкості зв'язку.

Причина, чому важко формувати вхідний трафік, полягає в тому, що в середовищі передачі немає буфера. Ви або приймаєте вхідні біти, або вони втрачаються. Для того, щоб трафік збирався залишити інтерфейс, ви можете буферувати і замовляти пакети скільки завгодно (або, принаймні, до наявної буферної пам'яті в пристрої).

Для протоколів, які мають шар поверх TCP (я не знаю, чи це стосується торрентів), це було б простим питанням крокуючих запитів на отримання додаткових даних. В іншому випадку програмі потрібно буде зв’язатися з ОС, щоб затримати ACKing пакетів. Більшість протоколів на базі UDP, за необхідності, мають ACK / повторно відправляти логіку в специфічному для додатку протоколі, тому в цей момент вона межує з тривіальним темпом.

Одним із можливих маршрутів було б формувати трафік з Інтернету на стороні локальної мережі маршрутизатора DSL, оскільки в цей момент ви будете формувати порт виходу.

Я не можу відповісти, чому ви не знайшли жодного рішення, яке дозволяло б формувати вхідні дані (і не знаю жодної вершини моєї голови), але щодо того, як відправник знає, як швидко приймач може отримувати дані:

Основна конструкція TCP / IP полягає в тому, що для кожного пакета, який джерело надсилає до пункту призначення, воно повинно чекати, коли пункт призначення відповість назад (з ACKпакетом), кажучи, що він отримав пакет.

Отже, якщо у вас є відправник 4 Мбіт / с і приймач 56 Кбіт / с, то відправник повинен сидіти і чекати між відправленням пакетів, щоб одержувач відповів на кожен пакет (Існують деякі технічні деталі, щоб зменшити цей накладний обсяг, але припущення все-таки є абстрактним рівень).

Отже, що станеться, якщо відправник вже надсилає 56Kbps даних, а потім намагається надіслати трохи більше?

Пакет втрачається. (Ну, потенційно черга в буфері комутатора, але коли це заповнюється, пакет втрачається). Оскільки пакет загубився, одержувач ніколи його не отримує, і тому ніколи не надсилає ACKпакет. Оскільки відправник ніколи не отримує цей ACKпакет (оскільки він ніколи не надсилався, але також він може бути загублений або може виникнути порушення мережі), відправник зобов'язаний повторно відправити додатковий пакет. Він сидить і намагається повторно відправити пакет, поки він не пройде і ACKвідповідь не повернеться до нього.

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

Це можна зробити за допомогою інтерфейсу ifb.

За допомогою інтерфейсу ifb ви можете спрямовувати вхідний потік eth0 (або будь-якого іншого) до виходу в ifb0 (наприклад), і застосовувати там правила обмеження.

Перевірте цю URL-адресу Фонду Linux: http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

І це сценарії, які обмежують пропускну здатність вхідних та вихідних повідомлень: https://github.com/rfrail3/misc/blob/master/tc/traffic-control.sh

Перевірте чудеса: http://lartc.org/wondershaper/

Щодо вхідного трафіку:

This is slightly trickier as we can't really influence how fast the internet
ships us data. We can however drop packets that are coming in too fast,
which causes TCP/IP to slow down to just the rate we want. Because we don't
want to drop traffic unnecessarily, we configure a 'burst' size we allow at
higher speed.

Now, once we have done this, we have eliminated the downstream queue totally
(except for short bursts), and gain the ability to manage the upstream queue
with all the power Linux offers.

використовувати UFW (Нескладні протипожежні стіни) http://ubuntuforums.org/showthread.php?t=1260812

Цей потік показує простий приклад, що за замовчуванням до IP-адрес із 6 зверненнями протягом 30 секунд відмовлено:

sudo ufw limit ssh/tcp

Також більш "розширена" команда із заданими значеннями часу та кількості звернень

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP