[gl00mie]

Цитата:

Сообщение от mazzy

я надеялся получить возможность автоматического и ДИНАМИЧЕСКОГО перенаправления в зависимости от НАРГУЗКИ канала. Т.е. я хочу получить суммарный объем канала при подключении кабеля. Если использовать route, то перераспределять придется вручную каким-нибудь bat-файлом. Причем правила перераспределения не зависят от нагрузки...

Цитата:

Сообщение от mazzy

не нужно задействовать второй интерфейс, когда несущий кабель один и тот же. согласен. но в данном случае несущие каналы разные - один кабель и беспроводная среда. почему в этом случае нельзя подключить второй интерфейс?

Все дело в уровнях взаимодействия и в распределении информации по этим уровням. Сетевой уровень "не знает" о существовании нагрузки, потому что буферизацией данных и очередями занимается транспортный уровень, кроме того, он "не знает" о различиях и особенностях каналов передачи, используемых при работе через различные интерфейсы. То, что один интерфейс - это Ethernet 100BASE-T, другой - это, к примеру, Ethernet 10BASE-T, а третий - это вообще IEEE 802.11g, известно лишь на физическом уровне. Транспортный уровень не может принимать решения о том, велика ли нагрузка для того или иного интерфейса. 5Мбит/с - это много или мало? А для Ethernet 10BASE-T? А для оптоволокна? А если ограничение пропускной способности реализовано на прикладном уровне (например, ftp-сервер не принимает данные быстрее определенной скорости)? Разные уровни (должны быть) абстрагированы друг от друга, иначе пропадают все преимущества разделения на уровни и возможности произвольного изменения реализации в рамках одного уровня. Какая разница тому же ftp-серверу, передаются ли данные по оптоволокну или через беспроводную сеть? Какая разница протоколу TCP, работает ли он через Ethernet или ATM?
Штатно развести трафик по разным сетевым интерфейсам можно лишь с помощью роутинга. Роутинг в IP-сетях - механизм сетевого уровня, а не прикладного, именно поэтому с помощью роутинга можно решать задачи лишь в такой постановке: трафик для такого-то IP-адреса/подсети - по одному маршруту через один интерфейс, а для другого IP-адреса/подсети или весь остальной трафик - по другому маршруту (и, возможно, через другой интерфейс). Кроме того, сетевой уровень, на котором реализована маршрутизация, "не знает", кто именно создает трафик, например, относится ли он к одному TCP-соединению или к нескольким, не говоря уже о том, относится ли он к одной программе (это уже прикладной уровень).
Если попытаться реализовать распределение трафика по разным каналам без учета описанных выше особенностей, могут возникнуть ситуации, когда часть трафика одного и того же соединения пойдет по одному каналу ("быстрому"), а другая часть - по другому каналу ("медленному"), в результате пакеты данных будут приходить в точку назначения с разными задержками. TCP умеет обрабатывать такие ситуации и извлекать данные из пакетов в нужном порядке, другие же IP-протоколы этого могут не уметь, кроме того, за счет ожидания получения фрагментированных данных, часть которых будет направлена через "медленный" канал, такая "балансировка нагрузки" может снизить скорость передачи потока данных, создаваемых теми или иными подсистемами или приложениями. Скажем, копируется большой файл по сети: через один интерфейс он копируется за 5 минут, а при подключении дополнительного более медленнного интерфейса - за 10 минут.
Или, к примеру, я подключился по https и отсылаю данные через одно соединение, второе... В какой-то момент ОСи кажется, что данные отсылаются медленно, и она направляет следуеющее соединение через другой интерфейс с другим IP, а на сервере, может, жестко прописан один IP, с которого можно подключаться. Разумеется, ОСь этого не знает, разумеется, соединение не устанавливается, и я должен как-то вручную разруливать эту ситуацию. Это хорошо, если все происходит интерактивно, а если я на ночь оставил закачку данных? Вместо "распределения нагрузки" я получу, в лучшем случае, только лишние ошибки в логе работы.
Это все к тому, что нельзя при решении задач одного уровня взаимодействия пытаться "притянуть за уши" информацию из других уровней, а без этой информации задача балансировки нагрузки в том виде, как она описана, не решается.

Цитата:

Сообщение от mazzy

Наверное, хочется сформулировать вопрос следующим образом: как заставить винду автоматически изменять интерфейсы в route table в зависимости от доступности и нагрузки этих самых интерфейсов. Но боюсь, что я неправильно употребляют терминологию и/или вообще неправильно формулирую вопрос.
Если я указал приоритет интерфейсов (сначала LAN, второй Wireless), то почему автоматически не задействуется второй интерфейс при полной загрузке первого?

Задачи повышения пропускной способности канала для данного конкретного хоста решаются иначе: не хватает Wireless - протяните 100-мбитный Ethernet, не хватает его - протяните гигабитный, снова не хватает - протяните оптику, т.е. решения тут статические. Задачи же динамического распределения трафика в зависимости от нагрузки решаются на уровне каких-нить больших, умных и дорогих маршрутизаторов, используемых в больших распределенных сетях. Два канала от одного компа до одного adsl-модема - это просто не тот уровень...