16 Мбит / с доступно через моего кабельного интернет-провайдера. Когда FileZilla используется для загрузки фильма или телешоу по FTP, используется все 16 Мбит / с полосы пропускания. Это ожидаемое и желаемое поведение.

Проблема в том, что другие сетевые приложения, которые работают параллельно с загрузкой, остаются практически с нулевой пропускной способностью. Независимо от того, является ли это вторичное приложение браузером на том же компьютере, подключенным к Ethernet AppleTV в той же сети или гостем, осуществляющим беспроводную навигацию на своем ноутбуке, практически отсутствует пропускная способность во время загрузки FileZilla.

То, что я ожидал (возможно, наивно), произойдет:

(1) Если AppleTV требует 2 Мбит / с для своей работы, он получит 2 Мбит / с, а загрузка FileZilla будет снижена до 14 Мбит / с.

(2) Если десять человек войдут в мой дом и все начнут скачивать из Интернета, у каждого из них будет доступ к скорости 1,6 Мбит / с (16 Мбит / с, разделенная на 10 человек).

Но это не то, что происходит вообще. Загрузка FileZilla каким-то образом потребляет всю внешнюю пропускную способность, доступную для сети.

Разве мой маршрутизатор LinkSys E1000 не должен предоставлять каждому исходящему соединению TCP/IP свою долю пропускной способности? Я дважды проверил настройки маршрутизатора и функциональность QOS отключена.

** Я понимаю, что могу искусственно ограничить использование пропускной способности FileZilla в настройках пользователя, но это не то, что я хочу. Если FileZilla - единственное приложение, работающее в сети, оно действительно должно иметь доступ ко всем 16 Мбит / с. Такое ощущение, что именно маршрутизатор должен отвечать за предоставление каждому приложению справедливой доли, но, может быть, это не совсем так, как работают маршрутизаторы? Пожалуйста помоги.

2 ответа2

2

Разве мой маршрутизатор LinkSys E1000 не должен предоставлять каждому исходящему соединению TCP/IP свою долю пропускной способности? Я дважды проверил настройки маршрутизатора и функциональность QOS отключена.

Нет. Маршрутизатор не контролирует, какие пакеты ваш провайдер отправляет вам по проводам. QoS не даст ему контроля над этим.

Такое ощущение, что именно маршрутизатор должен отвечать за предоставление каждому приложению справедливой доли, но, может быть, это не совсем так, как работают маршрутизаторы?

Нет, это не так, как работают маршрутизаторы. Ваш маршрутизатор просто маршрутизирует пакеты, которые он получает от остального мира. Он не имеет никакого контроля над тем, что он получает или как данные передаются по проводам от вашего провайдера к маршрутизатору.

Не было предпринято никаких существенных усилий для того, чтобы обеспечить постоянный доступ к интернету для поддержки любого понятия "справедливости" в пределах доступной полосы пропускания для отдельного клиента. Существуют некоторые маршрутизаторы, которые имитируют такие технологии, как StreamBoost, но они являются исключением.

0

Большинство DSL модемов не предлагают эту функциональность, но если вы можете выделить компьютер с низкой спецификацией, а через некоторое время вы можете установить pfsense и настроить его следующим образом:

конфигурация pfSense

Перейдите в брандмауэр> Traffic Shaper> Ограничители

Создайте новый ограничитель(8) для загрузки WAN1, названный как LimWan1Down. Просто установите его пропускную способность на бит (5) ниже загрузочной BW вашей WAN (3) (предпочтительно (1) с кратностью 64 кбит / с). Не иди ниже 256Kbps (6)

Сохраните ограничитель и щелкните опцию « Добавить новую очередь»(7), чтобы создать очередь с именем « QueWan1Down», и просто установите ее маску в «адреса назначения ».

Создайте еще один ограничитель для загрузки WAN1 с именем, подобным LimWan1Up. Просто установите его пропускную способность немного ниже загрузочной BW вашей WAN * (желательно с кратностью 64 кбит / с). Не иди ниже 256Kbps (6)

Сохраните ограничитель и выберите опцию « Добавить новую очередь», чтобы создать очередь с именем « QueWan1Up», и просто установите ее маску на « исходные адреса».

Наконец, перейдите в межсетевой экран> правила> LAN и найдите правило (2), которое передает трафик в WAN1. Нажмите «Изменить» и перейдите в раздел «Дополнительные параметры»> «Вход / выход» и укажите свою очередь загрузки в первой ( входящей ) части и свою очередь загрузки во второй (выходной) части (9).

Не забудьте нажать кнопку Применить изменения.

Теперь ограничители будут ограничивать общую загрузку или загрузку BW со всех ваших клиентов, чтобы избежать нежелательной буферизации на стороне интернет-провайдера, в то время как очереди распределяют этот ограниченный BW равномерно между всеми клиентами LAN (точнее, IP-адресами локальной сети).

Для немедленного тестирования необходимо сначала перейти в « Диагностика»> «Состояния»> «Сбросить состояния» и нажать « Сбросить», но имейте в виду, что мы будем сбрасывать все TCP- соединения для каждого сервера (включая ваше подключение к веб-интерфейсу).

Теперь перейдите к загрузке / загрузке и проверьте Диагностика> Информация об ограничителе.

Этот метод поддерживает низкое время RTT, ограничивая общую пропускную способность загрузки и выгрузки (таким образом предотвращая буферизацию у провайдера), и равномерно распределяет этот BW между вашими клиентами LAN. Вы получаете приличный опыт просмотра / скайпа / RDP / ssh, когда многие пользователи максимально используют ваши глобальные сети, и все же это позволяет одному клиенту получить полный BW, когда это больше никому не нужно.

Краткий справочник

Если вы привыкли к вышеописанной процедуре и просто хотите получить краткую справку, чтобы не перепутать настройки, вот они:

Pipe | Direction  | Queue mask
-----+------------+--------------------
In   | Upload     | Source Address
Out  | Download   | Destination Address

Заметки:

(1): не уверен, если это важно.

(2): не уверен, работает ли он одинаково, когда есть много правил, потому что я тестировал только одно правило.

(3): если у вас есть несколько глобальных сетей, вы делаете вышеупомянутое для каждой глобальной сети, но я считаю, что все становится сложнее, потому что на вашем брандмауэре каждое правило локальной сети, которое передает трафик, должно работать с определенной глобальной сетью (4). в моем случае, когда у меня было 2 WAN, я разделял IP-адреса LAN на четные и нечетные, и каждая группа использовала определенную WAN (с переключением при сбое, конечно). Немного хакерский, я знаю. Имейте в виду, что Драконт не разделяет моих забот. Он заявляет, что «описанные здесь ограничители работают должным образом при использовании в сочетании с группами шлюзов (т. Е. Multi-WAN) без каких-либо дополнительных изменений, если в правила брандмауэра входит группа шлюзов в качестве шлюза (в разделе« Дополнительно »)».

(4): Я на 99% уверен, что это так, но никогда не проверял.

(5): вот как узнать, сколько это будет немного: найти плохой день / время для вашей линии, где он скачивает / выгружает с наихудшей скоростью. Перед тем, как включить что-либо, начните массовую загрузку / выгрузку и посмотрите, сколько времени прошло с вашей стороны Попробуйте установить ограничение для загрузки / выгрузки. Если ваше время пинга сходит с крыши, вам нужно снизить предел.

(6) Я не проверял это, но я прочитал эту логику: максимальный размер пакета IPv4 составляет 64 КБ, то есть 256 Кбит. Поэтому, если вы уйдете ниже, ограничителю может потребоваться разбить пакеты на части, что приведет к более высокой задержке, более низкой пропускной способности и плохому пользовательскому опыту.

(7) Пользовательский интерфейс pfsense на данный момент немного сбит с толку. Закончите свой лимитер, сохраните его, нажмите на его имя еще раз и затем попытайтесь нажать Добавить новую очередь

(8) терминология немного сбивает с толку. В этом тексте я использовал термины с осторожностью, но вы можете увидеть, что термины ограничитель, канал и очередь используются взаимозаменяемо.

(9) думать о потоках пакетов с точки зрения интерфейса локальной сети. Пакеты, поступающие из локальной сети в интерфейс локальной сети, станут загружаться по глобальной сети и наоборот.

Расширенный материал

Вот некоторые дополнительные заметки, скопированные непосредственно из поста drakontas reddit (см. Раздел «Кредиты»):

  • Если вы используете правила плавающего межсетевого экрана вместо правил для интерфейса, у вас должно быть два правила: одно применяется к трафику "In", а другое - к трафику "Out" (направление указано в правиле).

  • Если у вас много пользователей (например, тысячи устройств с относительно небольшой восходящей линией связи), вам нужно увеличить расширенный параметр "Размер очереди" для каждого канала и очереди (по умолчанию 50, если значение не указано). Это позволяет более аккуратно обрабатывать пользовательский трафик в периоды высокой загруженности.

  • Для расширенного параметра "Размер очереди" может быть установлено максимум 100. Это не задокументировано и не указано в графическом интерфейсе, но если вы попытаетесь установить это значение> 100, ограничители будут выдавать ошибку и не будут корректно применяться. Это может замедлить перезагрузку, а также может быть совершенно скрытой ошибкой при применении в работающей системе (единственный признак того, что что-то не так, - то, что страница Diagnostics> Limiter Info не будет отражать новые настройки, даже после сброса состояний).

  • Помните, что для потоков TCP, где ответы ACK требуются для целостности данных, загрузка необходима даже во время загрузки (и наоборот). В моих тестах ограничение загрузки до 512 кбит / с приводило к максимальной реальной скорости загрузки 50-60 Мбит / с; ограничение загрузки до 256 Кбит / с приводит к максимальной скорости загрузки 20-30 Мбит / с (и, конечно, YMMV). Для потоков UDP это не имеет значения

кредиты

Эта статья основана на серии постов foxale08 со скриншотами на форуме pfsense (вы должны войти в систему, чтобы увидеть скриншоты) и на отличном посте drakontas reddit

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .