Дросселирование пропускной способности с помощью QoS
ОГЛАВЛЕНИЕ
Одним из возможных решений этой проблемы является QoS. QoS, или качество службы, является технологией присвоения приоритетов пакетам данных. QoS позволяет вам передавать чувствительные к временным значениям пакеты с более высоким приоритетом, чем остальные пакеты.
QoS – это стандарт индустрии, а не стандарт, принадлежащий Microsoft. Однако впервые компания Microsoft представила этот стандарт QoS в Windows 2000. Версия QoS от Microsoft довольно сильно эволюционировала с того времени, но все еще отвечает стандартам индустрии.
В Windows XP Professional, QoS в первую очередь работает как механизм резервирования пропускной способности. Когда QoS включена, приложению разрешено резервировать до 20% всей пропускной способности сети, обеспечиваемой каждым сетевым адаптером машины. Однако количество резервируемой приложением пропускной способности сети можно настраивать. Я покажу вам, как изменять количество резервируемой пропускной способности в третьей части.
Чтобы посмотреть, как используется резервная пропускная способность, предположим, у вас есть приложение для проведения видеоконференций, требующее приоритетной полосы пропускания для правильной работы. Предположив, что для этого приложения включена QoS, можно сказать, что оно резервирует 20% всей полосы пропускания машины, оставляя 80% пропускной способности для остального сетевого трафика.
Все приложения, кроме приложений для видеоконференций, используют технологию под названием наилучшая доставка (best effort delivery). Это означает, что пакеты отправляются с одинаковыми приоритетами 'первый доставленный пакет обслуживается в первую очередь'. С другой стороны, трафик приложений для видеоконференций всегда будет иметь более высокий приоритет по сравнению с остальным трафиком, но приложению никогда не будет позволено потреблять более 20% всей пропускной способности.
Однако только тот факт, что Windows XP оставляет часть пропускной способности для приоритетного трафика, вовсе не означает, что приложения с обычным приоритетом не смогут использовать резервную пропускную способность. Хотя приложения видеоконференций пользуются преимуществами более высоких приоритетов, резервируемой пропускной способности, шансы постоянного использования таких приложений очень малы. В этом случае Windows позволяет прочим приложениям использовать резервную и не резервную пропускную способность для максимально хорошей доставки до тех пор, пока приложения, для которых зарезервирована часть пропускной способности сети не будут использоваться.
Как только приложение видеоконференции запускается, Windows начинает в принудительном порядке использовать резервирование. Но даже в этом случае резервирование не абсолютное. Предположим, Windows зарезервировал 20% пропускной способности сети для приложения видеоконференции, но этому приложению не нужны все 20%. В этих случаях Windows позволяет другим приложениям использовать остаточную пропускную способность, но будет постоянно контролировать потребности приложения с более высоким приоритетом. В случае если приложению потребуется больше пропускной способности, пропускная способность будет выделяться для него до максимального значения в 20%.
Как я уже говорил, QoS – это стандарт индустрии, а не технология Microsoft. Будучи таковой, QoS используется в Windows, но Windows не может делать эту работу самостоятельно. Чтобы QoS работал, каждый компонент оборудования между отправителем и получателем должен поддерживать QoS. Это означает, что сетевые адаптеры, коммутаторы, маршрутизаторы и все остальные используемые устройства должны знать о QoS, равно как и операционные системы получателя и отправителя.
Если вам интересно, то вам нет необходимости устанавливать какую-то безумную экзотическую сетевую инфраструктуру, чтобы использовать QoS. Асинхронный режим передачи (Asynchronous Transfer Mode – АTM) – является отличной сетевой технологией для использования QoS, поскольку это технология, ориентированная на подключения, однако вы можете использовать QoS и с другими технологиями, такими как Frame Relay, Ethernet и даже Wi-FI (802.11x).
Причина, по которой ATM является столь идеальным выбором для QoS, заключается в том, что она способна внедрять резервирование пропускной способности и распределять ресурсы на уровне оборудования. Такой тип распределений выходит за рамки возможностей Ethernet и сходных сетевых технологий. Это не означает, что QoS нельзя использовать. Это лишь означает, что QoS должен применяться не так, как в среде ATM.
В среде ATM ресурсы распределяются сразу, на уровне физических устройств. Поскольку Ethernet и прочие сходные технологии не могут распределять ресурсы таким способом, технологии такого типа основываются на присвоении приоритетов, а не на истинном выделении ресурсов. Это означает, что резервирование пропускной способности происходит на более высоком уровне модели OSI. Как только пропускная способность была зарезервирована, пакеты с более высокими приоритетами передаются в первую очередь.
Одним моментом, который следует учитывать, если вы собираетесь применить QoS через Ethernet, Wi-Fi или другие схожие технологии, является то, что такие технологии не имеют соединения. Это означает, что у отправителя нет возможности проверить состояние получателя или состояние сети между отправителем и получателем. А это в свою очередь означает, что отправитель может гарантировать отправку пакетов с более высокими приоритетами в первую очередь, но не может гарантировать доставку этих пакетов в течение определенного времени. С другой стороны, QoS способен дать такого рода гарантии на ATM сети, поскольку ATM является технологией, ориентированной на подключение.
Windows 2000 vs. Windows Server 2003
Ранее я говорил о том, что Microsoft впервые представила QoS в Windows 2000, и что это применение QoS с того времени значительно эволюционировало. Поэтому я хочу немного рассказать о различиях между QoS в Windows 2000 и в Windows XP и Windows Server 2003 (в которых этот стандарт используется примерно одинаково).
В Windows 2000 применение QoS было основано на архитектуре Intserv, которая не поддерживается в Windows XP или Windows Server 2003. Причина, по которой Microsoft решила не использовать такую архитектуру, крылась в том, что лежащий в основе API было трудно использовать, и архитектура имела проблемы с масштабностью.
Некоторые организации все еще используют Windows 2000, поэтому я решил дать вам немного информации о том, как работает архитектура Windows 2000 QoS. Windows 2000 использует протокол под названием RSVP для резервирования ресурсов пропускной способности. Когда запрашивается пропускная способность, Windows необходимо определить, когда пакеты можно передавать. Для этого Windows 2000 использует протокол сигнала под названием SBM (менеджер пропускной способности подсети – Sunbelt Bandwidth manager), чтобы сообщать отправителю о том, что она готова принимать пакты. Служба Admission Control Service (ACS) проверяет, что эффективная пропускная способность доступна и затем, либо предоставляет, либо отвергает запрос на пропускную способность.
API управления трафиком
Одной из основных проблем с приоритетами сетевого трафика является то, что вы не можете назначать приоритеты трафику на основе компьютера, который генерирует его. Для одиночных компьютеров является обычным делом использование нескольких приложений, и для каждого приложения (и операционной системы) создавать отдельный поток трафика. Когда это случается, каждому потоку трафика должны назначаться приоритеты в индивидуальном порядке. В конце концов, одному приложению может потребоваться резервная пропускная способность, в то время как для другого приложения наилучшая доставка идеально подходит.
Здесь в игру вступает Traffic Control API (программный интерфейс управления трафиком). Traffic Control API – это программный интерфейс приложения, позволяющий применять параметры QoS к индивидуальным пакетам. Traffic Control API работает на основе определения отдельных потоков трафика, и применения различных способов QoS контроля к этим потокам.
Первое, что делает Traffic Control API, это создает то, что известно под названием filterspec. Filterspec – это, по сути, фильтр, определяющий, что значит для пакета принадлежать к определенному потоку. Некоторые атрибуты, используемые filterspec, включают IP адрес источника и назначения пакета и номер порта.
Как только filterspec был определен, API позволяет создать flowspec. Flowspec определяет QoS параметры, которые будут применяться к последовательности пакетов. Некоторые из параметров, определяемые flowspec, включают скорость передачи (допустимую скорость передачи) и тип службы.
Третий концепт, определяемый интерфейсом Traffic Control API – это концепт потока. Поток представляет собой простую последовательность пакетов, которые подвержены одному flowspec. Проще говоря, filterspec определяет, какие пакеты будут включены в flowspec. Flowspec определяет, будут ли пакеты обрабатываться с более высокими приоритетами, а поток – это собственно передача пакетов, которые подвергаются обработке flowspec. Все пакеты в потоке обрабатываются равноправно.
Следует упомянуть, что одним из преимуществ Traffic Control API над Generic QoS API, использовавшемся в Windows 2000, является способность использовать агрегирование (объединение). Если узел имеет несколько приложений, передающих множественные потоки данных в общее место назначения, то эти пакеты могут быть объединены в общий поток. Это действует, даже если приложения используют различные номера портов, но при условии, что IP адрес источника и назначения одинаков.
Классификатор общих пакетов (Generic Packet Classifier)
В предыдущем разделе я рассказал о взаимоотношениях между flowspec, filterspec и потоком. Однако важно помнить, что интерфейс Traffic Control API – это просто программный интерфейс приложения. Будучи таковым, его работа заключается в определении и назначении приоритетов потокам трафика, а не создание этих потоков.
За создание потоков отвечает Generic Packet Classifier. Как вы помните из прошлого раздела, одним из атрибутов, который определялся в flowspec, был тип службы. Тип службы, по сути, определяет приоритет потока. Generic Packet Classifier отвечает за определение типа службы, который был назначен для flowspec, после чего он помещает связанные пакеты в очередь, соответствующую типу службы. Каждый поток помещается в отдельную очередь.
QoS Packet Scheduler (планировщик пакетов)
Третий QoS компонент, о котором вам нужно знать, - это планировщик пакетов QoS. Проще говоря, основной задачей планировщика пакетов QoS является формирование трафика. Для этого планировщик пакетов получает пакеты из различных очередей, а затем маркирует эти пакеты приоритетами и скоростью потока.
Как я говорил в первой части этой серии статей, для корректной работы QoS различные компоненты, расположенные между источником пакетов и местом их назначения, должны поддерживать QoS (т.е. знать о нем). Хотя эти устройства должны знать, как работать с QoS, они также должны знать о том, как обрабатывать обычный трафик без приоритетов. Чтобы сделать это возможным, QoS использует технологию под названием маркировка.
На самом деле, здесь присутствует два типа маркировки. Планировщик пакетов QoS использует Diffserv маркировку, которая распознается устройствами третьего уровня, и маркировку 802.1p, которая распознается устройствами второго уровня.
Настройка планировщика пакетов QoS
Прежде чем я покажу вам, как работает маркировка, следует отметить, что вам нужно будет настроить планировщика пакетов QoS, чтобы все работало. В Windows Server 2003 планировщик пакетов QoS относится к необязательным сетевым компонентам, так же как и клиент для сетей Microsoft или TCP/IP протокол. Чтобы включить планировщика пакетов QoS, откройте страницу свойств вашего сетевого подключения сервера и поставьте флажок рядом со строкой планировщик пакетов QoS, как показано на рисунке A. Если планировщик пакетов QoS отсутствует в списке, нажмите кнопку «Установить» и следуйте указаниям.
Еще один момент, который вам нужно знать касаемо планировщика пакетов QoS, заключается в том, что для его корректной работы ваш сетевой адаптер должен поддерживать 802.1p маркировку. Чтобы проверить свой адаптер, нажмите кнопку «Настроить», рисунок A, и Windows отобразит свойства вашего сетевого адаптера. Если вы посмотрите во вкладку «Дополнительно» на странице свойств, вы увидите различные свойства, которые поддерживает ваш сетевой адаптер.
Если вы посмотрите на рисунок B, вы увидите, что одним из свойств в списке является 802.1Q / 1P VLAN Tagging. Вы также видите, что это свойство отключено по умолчанию. Чтобы включить 802.1p маркировку, просто включите это свойство и нажмите OK.
Вы, возможно, заметили на рисунке B, что свойство, которое вы включили, связано с VLAN тегированием, а не с пакетной маркировкой. Причина тому кроется в том, что маркеры приоритетов включаются в VLAN теги. 802.1Q стандарт определяет VLANs и VLAN теги. Этот стандарт на самом деле резервирует три бита в VLAN пакете, которые используются для записи кода приоритетности. К сожалению, 802.1Q стандарт никогда не определяет, каковы должны быть эти коды приоритетности.
802.1P стандарт был создан в качестве дополнения к 802.1Q. 802.1P определяет маркировку приоритетности, которая может быть заключена в VLAN тег.
802.1P сигнал
Как я говорил в предыдущей части, передача сигнала 802.1p осуществляется на втором уровне модели OSI. Этот уровень используется такими физическими устройствами, как коммутаторы. Устройства второго уровня, поддерживающие 802.1p, могут просматривать маркировку приоритетов, которые назначены пакетам, а затем группировать эти пакеты в отдельные классы трафика.
В сетях Ethernet маркировка приоритетов включена в тэги VLAN. VLANs и VLAN тэги определяются 802.1Q стандартом, который определяет поле трехразрядных приоритетов, но на самом деле не определяет то, как это поле приоритетов должно использоваться. Именно здесь в игру вступает 802.1P стандарт.
802.1P определяет различные классы приоритетов, которые можно использовать совместно с 802.1Q стандартом. В конечном счете, 802.1Q оставляет право выбора маркировки приоритетов за администратором, поэтому технически вам не нужно следовать указаниям 802.1P, но 802.1P, кажется, является тем, что все выбирают.
Хотя идея использования 802.1P стандартов для обеспечения маркировки второго уровня, вероятно, звучит как чистая теория, на самом деле она может определяться с помощью параметров групповой политики. Стандарт 802.1P обеспечивает восемь различных классов приоритетов (варьирующихся в пределах от 0 до 7). Пакеты с приоритетами более высокого класса обрабатываются QoS с более высоким приоритетом доставки.
По умолчанию Microsoft назначает следующие маркировки приоритетов:
| Маркировка приоритета | Уровень службы |
|---|---|
| 0 | Пакеты, не соответствующие flowspec |
| 0 | Качественный |
| 0 | Доставка с максимальными усилиями (Best effort delivery) |
| 4 | Управляемая нагрузка (Controlled load) |
| 5 | Гарантированное обслуживание (Guaranteed service) |
| 7 | Сетевой контроль (Network control) |
Но как я упомянул ранее, вы можете изменять эти приоритеты, модифицируя различные параметры групповой политики. Для этого нужно открыть редактора групповой политики и перейти в древе консоли по ветвям Конфигурация компьютера \ Шаблоны администрирования \ Сети \ Планировщик QoS пакетов \ Значение приоритетов второго уровня. Как видно из рисунка A, есть параметры групповой политики, соответствующие каждой маркировке приоритетов, которые я перечислил выше. Вы можете назначить свои уровни маркировки приоритетов любому из этих типов служб. Однако не следует забывать о том, что эти параметры групповой политики действуют только для хостов, на которых используется Windows XP, 2003 или Vista.
Раздельные службы (Differentiated Services)
Как я объяснял в предыдущей статье, QoS выполняет маркировку приоритетов на втором и третьем уровнях модели OSI. Это обеспечивает учет приоритетов на протяжении всего процесса доставки пакетов. К примеру, коммутаторы работают на втором уровне модели OSI, но маршрутизаторы, как правило, работают на третьем уровне. Таким образом, если бы пакеты использовали только 802.1p маркировку приоритетов, то приоритеты этим пакетам назначал бы коммутатор, однако эти приоритеты игнорировались бы сетевыми маршрутизаторами. Чтобы препятствовать этому, QoS использует протокол Differentiated Services protocol (Diffserv) для назначения приоритетов трафику на третьем уровне модели OSI. Маркировка Diffserv включена в IP заголовки пакетов с помощью TCP/IP.
Архитектура, используемая Diffserv, была изначально определена RFC 2475. Однако многие спецификации архитектуры были переписаны в RFC 2474. RFC 2474 определяет Diffserv архитектуру для IPv4 и IPv6.
Интересный момент IPv4 применения в RFC 2474 заключается в том, что даже, несмотря на тот факт, что Diffserv был абсолютно переопределен, он все еще обратно совместим с оригинальной RFC 2475 спецификацией. Это означает, что более старые маршрутизаторы, которые не поддерживают новые спецификации, могут распознавать назначенные приоритеты.
Текущее Diffserv применение использует октеты типов служб пакетов Type of Service (TOS) для хранения Diffserv значения (которое называется DSCP значением). В рамках этого октета первые шесть битов хранят DSCP значение, а последние два бита не используются. Причина, по которой эти маркировки обратно совместимы с RFC 2475 спецификацией, заключается в том, что RFC 2475 требовала первые три бита в том же октете для использования в информации посследовательности IP. Хотя DSCP значения в длину составляют шесть бит, первые три бита все равно отражают IP последовательность.
Как и в случае с маркировкой 802.1p, которую я демонстрировал ранее, вы можете настраивать Diffserv приоритеты с помощью различных параметров групповой политики. Прежде чем я покажу вам как, я представлю стандартные Diffserv приоритеты, используемые в Windows:
| Маркировка приоритетов | Тип службы |
|---|---|
| 0 | Наилучшие усилия (Best Effort) |
| 0 | Качественная (Qualitative) |
| 24 | Управляемая нагрузка (Controlled Load) |
| 40 | Гарантированная служба (Guaranteed Service) |
| 48 | Сетевой контроль (Network Control) |
Вы, возможно, заметили, что маркировки приоритетов Diffserv используют абсолютно другой диапазон, нежели 802.1P. Вместо поддержки диапазона 0 - 7, Diffserv поддерживает диапазон маркировки приоритетов в пределах от 0 до 63, при этом большие числа имеют более высокие приоритеты.
Как я уже говорил, Windows позволяет вам определять Diffserv маркировку приоритетов с помощью параметров групповой политики. Однако следует помнить, что некоторые более совершенные маршрутизаторы будут назначать пакетам свои собственные Diffserv значения, независимо от тех значений, которые назначила Windows.
Учитывая это, вы можете настроить маркировку приоритетов Diffserv, открыв редактора групповой политики, и перейдя в древе консоли по ветвям Конфигурация компьютера \ Шаблоны администрирования \ Сеть \ Планировщик пакетов QoS.
Если вы посмотрите на рисунок B, вы заметите, что там есть две вкладки, связанных с DSCP, которые расположены под вкладкой планировщика пакетов QoS. Одна из этих вкладок позволяет вам назначать маркировку приоритетов DSCP для пакетов, соответствующих flowspec, а вторая позволяет вам устанавливать маркировку приоритетов DSCP для несоответствующих пакетов. Действительные параметры сами по себе сходны для обеих вкладок, как показано на рисунке C.
Разнообразные параметры групповой политики
Если вы посмотрите на рисунок B, вы заметите, что там есть три параметра групповой политики, о которых я не говорил. Я хотел вкратце упомянуть о том, что это за параметры и что они делают, для тех, кому может быть интересно.
Параметр Limit Outstanding Packets, по сути, представляет собой значение порога службы. Если количество превосходящих пакетов достигает определенного значения, то QoS запретит любые дополнительные выделения пропускной способности для сетевого адаптера, пока значение не опустится ниже максимально допустимого порога.
Параметр Limit Reservable Bandwidth управляет процентом общей пропускной способности, которую могут зарезервировать приложения с поддержкой QoS. По умолчанию приложения с поддержкой QoS могут резервировать до 80% процентов пропускной способности сети. Конечно, любая часть полосы пропускания, зарезервированная, и в данный момент не используемая QoS приложениями, может использоваться другими приложениями.
Параметр Set Timer Resolution управляет минимальными единицами времени (в микросекундах) которые планировщик пакетов QoS будет использовать для планирования пакетов. По сути, этот параметр контролирует максимальную частоту, с которой пакеты могут ставиться в очередь на доставку.
QoS и модемы
В этот век практически всеобщей доступности широкополосных технологий кажется странным сам разговор о модемах. Однако все еще существует множество малых предприятий и домашних пользователей, которые используют модемы в качестве механизма подключения к интернету. Недавно я даже видел большую корпорацию, использующую модемы для связи со спутниковыми офисами, которые расположены в удаленных местах, где нет доступа к широкополосной технологии.
Конечно, самой большой проблемой использования модемов является ограниченная пропускная способность, которой они обладают. Менее очевидной, но не менее важной проблемой является то, что пользователи, как правило, не меняют своего поведения в режиме онлайн при использовании модемных соединений. Конечно, пользователи могут не испытывать большого желания к загрузке больших файлов при подключении к интернету через модем, но остальное поведение пользователей остается таким же, как если бы они были подключены через широкополосное соединение.
Обычно пользователи не слишком беспокоятся о том, чтобы держать Microsoft Outlook постоянно открытой, или просматривать страницы, пока файлы загружаются в фоновом режиме. Некоторые пользователи также держат систему мгновенного обмена сообщениями постоянно открытой. Проблема с таким типом поведения заключается в том, что каждое из этих приложений или задач потребляет определенный объем пропускной способности подключения к интернету.
Чтобы посмотреть, как QoS может помочь, давайте рассмотрим, что происходит в обычных условиях, когда QoS не используется. Обычно первое приложение, которое пытается получить доступ к интернету, обладает наибольшими правами использования соединения. Это не означает, что другие приложения не могут использовать соединение, а, скорее, Windows считает, что другие приложения не будут использовать соединение.
Как только соединение создано, Windows начинает динамически настраивать размер окна получения TCP. Размер окна получения TCP – это объем данных, который можно отправить, прежде чем ожидать подтверждения, что данные были получены. Чем больше размер окна получения TCP, тем больше пакеты, которые отправитель может передать, прежде чем ждать подтверждения успешной доставки.
Размер окна получения TCP нужно настраивать аккуратно. Если окно получения TCP слишком маленькое, будет страдать и эффективность, так как TCP требует очень частых подтверждений принятия. Однако если окно получения TCP слишком большое, то машина может передать слишком много данных, прежде чем узнает, что во время передачи возникла проблема. В результате требуется повторная передача большого объема данных, что также воздействует на эффективность.
Когда приложение начинает использовать dial-up подключение к интернету, Windows динамически настраивает размер окна получения TCP по мере отправления пакетов. Целью Windows здесь является достижение стабильного состояния, в котором размер окна получения TCP настроен оптимально.
Теперь предположим, что пользователь открывает второе приложение, которое также требует подключения к интернету. После того, как он это сделает, Windows инициирует алгоритм медленного запуска TCP, который представляет собой алгоритм, несущий ответственность за настройку размера окна получения TCP на оптимальное значение. Проблема заключается в том, что TCP уже используется приложением, которое было запущено ранее. Это воздействует на второе приложение двумя способами. Во-первых, второму приложению требуется гораздо больше времени на достижение оптимального размера окна получения TCP. Во-вторых, скорость передачи данных для второго приложения всегда будет медленнее, чем скорость передачи для приложения, запущенного вперед.
Хорошая новость заключается в том, что вы можете избежать этих проблем в Windows XP и Windows Server 2003 путем простого запуска планировщика пакетов QOS. После этого планировщик пакетов QOS будет автоматически использовать технологию под названием Deficit Round Robin всякий раз, когда Windows обнаруживает медленную скорость подключения.
Принцип работы Deficit Round Robin заключается в динамическом создании отдельных очередей для каждого приложения, которому требуется доступ к интернету. Windows обслуживает эти очереди в виде циклического алгоритма, который значительно улучшает эффективность всех приложений, нуждающихся в доступе к интернету. Если вам интересно, Deficit Round Robin также доступен в Windows 2000 Server, но не включается автоматически.
Совместное использование интернет соединения
В Windows XP и Windows Server 2003, QoS также способствует совместному использованию интернет подключения. Как вы, вероятно, знаете, совместное использование интернет соединения является упрощенным вариантом создания маршрутизатора на базе NAT. Компьютер, к которому интернет соединение подключено физически, играет роль маршрутизатора и DHCP сервера для других компьютеров в сети, тем самым обеспечивая им доступ к интернету через этот хост. Совместное использование интернет подключения обычно используется только в малых, пиринговых сетях, в которых отсутствует инфраструктура домена. Сети больших размеров обычно используют маршрутизаторы на базе физических устройств, или маршрутизацию и службы удаленного доступа.
В вышеприведенном разделе я уже объяснял, как Windows динамически настраивает размер окна получения TCP. Однако такая динамическая настройка может вызывать проблемы при совместном использовании интернет подключения. Причина тому кроется в том, что подключение между компьютерами в локальной сети обычно относительно быстрое. Обычно такое подключение состоит из 100 Mb Ethernet, или из 802.11G беспроводного соединения. Хотя эти типы соединения далеко не самые быстрые, но они гораздо быстрее большинства подключений к интернету, доступных в США. Именно здесь кроется проблема.
Клиентскому компьютеру нужно взаимодействовать через интернет, но он не может сделать этого напрямую. Вместо этого он использует хост совместного использования подключения к интернету в качестве модуля доступа. Когда Windows высчитывает оптимальный размер окна получения TCP, он делает это, основываясь на скорости соединения между локальной машиной и машиной Internet Connection Sharing. Разница между объемом данных, которые локальная машина может действительно получить из интернета, и объемом, которые она думает, что сможет получить, основываясь на скорости подключения к хосту Internet Connection Sharing, может вызывать проблемы. Если говорить точнее, разница в скорости подключения может потенциально вызывать ситуации, в которых данные создают резервные копии в очереди, подключенной к низкоскоростному соединению.
Здесь в игру вступает QoS. Если вы установите планировщик пакетов QOS на узле Internet Connection Sharing, то хост Internet Connection Sharing аннулирует размер окна получения TCP. Это означает, что хост Internet Connection Sharing будет задавать размер окна получения TCP для локальных хостов на такое же значение, которое у них было бы в случае прямого подключения к интернету. Это устраняет проблемы, вызванные несовпадением скоростей сетевого подключения.
Заключение
В этой серии статей я рассказал о QoS и том, как ее можно использовать для формирования потока трафика в различных типах сетевых подключений. Как вы видите, QoS может заставить сеть работать гораздо эффективнее, формируя трафик таким образом, что он может пользоваться моментами наименьшей загруженности в сети, и гарантировать быструю доставку трафика с более высоким приоритетом.
Брайн Позей (Brien Posey)