The Cable GuyАвтоматическая настройка окна приема TCP

Джозеф Дэвис (Joseph Davies)

Представляем первую статью рубрики The Cable Guy в журнале TechNet Magazine. Читатели этой рубрики на веб-узле TechNet уже знают, что в ней рассказывается о различных аспектах работы компьютерных сетей. Мы продолжим эту традицию и в журнале. Если вы впервые читаете данную рубрику и хотите ознакомиться с архивом статей, посетите веб-узел Cable Guy (на английском языке).

Темой первой статьи будет окно приема TCP.

Пропускная способность соединений TCP может ограничиваться приложениями, отправляющими и принимающими данные, реализацией протокола TCP на приеме и на передаче, а также маршрутом передачи данных между узлами TCP. В этой статье описывается окно приема TCP и рассказывается о его влиянии на пропускную способность соединений TCP, о применении масштабирования окна TCP и о новой функции автоматической настройки окна приема TCP в Windows Vista™, позволяющей оптимизировать пропускную способность TCP для приема данных.

Окно приема TCP

Соединения TCP имеют ряд важных характеристик. Во-первых, они представляют собой логические цепи типа «точка-точка» между двумя протоколами уровня приложений. Протокол TCP не поддерживает доставку данных с одного узла на несколько узлов, а позволяет только передавать данные с одного узла на другой.

Во вторых, соединения TCP ориентированы на связь. Прежде чем можно будет передать данные, два процесса уровня приложений должны формально установить связь TCP, используя процедуру установки связи TCP. Завершение связи также должно осуществляться формально с использованием процесса прекращения связи TCP.

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

В четвертых, соединения TCP являются полностью дуплексными. Для каждого узла TCP соединение TCP состоит из двух логических каналов: исходящего и входящего. Заголовок TCP содержит порядковый номер исходящих данных и подтверждение получения (ACK) входящих данных.

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

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

На каждом логическом канале (направлении полнодуплексного соединения TCP) у отправителя есть окно отправки, а у получателя — окно приема. Если нет находящихся в пути пересылаемых данных или подтверждающих сегментов, окна приема и отправки на логическом канале совпадают. Другими словами, участок данных в исходящем байтовом потоке, который отправителю разрешено отправлять, соответствует участку данных во входящем байтовом потоке, который получатель может принять. Эти взаимоотношения проиллюстрированы на рис. 1.

рис. 1.** Сопоставление окон приема и отправки **(Щелкните изображение, чтобы увеличить его)

Для определения размера окна приема в заголовке TCP содержится 16-разрядное поле Window. Когда получатель получает данные, он возвращает отправителю подтверждение ACK, показывающее, что байты успешно приняты. В каждом подтверждении поле Window указывает количество остающихся байт в окне приема. Когда данные отправляются, приложение их получает и отправляет подтверждение, окна приема и передачи перемещаются вправо. Окно приема определяет, какой объем неподтвержденных данных может находиться в пути от отправителя к получателю.

Поскольку в окне приема могут быть данные, не полученные приложением, а также данные, которые получены, но не подтверждены, в окне приема TCP имеется дополнительная структура, как показано на рис. 2.

Рис. 2** Типы данных в окне приема TCP **(Щелкните изображение, чтобы увеличить его)

Обратите внимание на разницу между максимальным и текущим окнами приема. Максимальное окно приема имеет фиксированный размер. Текущее окно приема имеет переменный размер, соответствующий оставшемуся объему данных, который получатель разрешает отправлять. Размер текущего окна приема соответствует значению поля Window в подтверждениях ACK, посылаемых отправителю. Он равен разнице максимального размера окна приема и объема данных, который был получен и подтвержден, но не извлечен приложением.

Окно приема TCP и пропускная способность TCP

Для оптимизации пропускной способности TCP (при условии отсутствия ошибок на маршруте передачи) отправитель должен посылать достаточное количество пакетов для заполнения логического канала между отправителем и получателем. Емкость логического канала можно рассчитать по следующей формуле:

Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds

Емкость канала также называют интегральным показателем задержки передачи (BDP). Канал может быть широким (большая ширина полосы пропускания) или узким (маленькая ширина полосы пропускания), коротким (небольшое время приема-передачи) или длинным (большое время приема-передачи). Широкие и длинные каналы имеют самый высокий показатель BDP. Высокие значения BDP на маршрутах передачи встречаются в спутниковых сетях или корпоративных глобальных сетях (WAN), где используются межконтинентальные оптоволоконные соединения.

Повышение производительности на стороне отправителя при передаче с высоким значением BDP

Новая функция автоматической настройки окна приема TCP позволяет повысить производительность получения данных через соединения с высоким значением BDP. Как же повысить производительность отправки?

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

Алгоритм медленного пуска увеличивает окно отправки на один полный сегмент TCP на каждый полученный сегмент подтверждения (для реализации TCP в Windows XP и Windows Server 2003) или на каждый подтвержденный сегмент (для реализации TCP в Windows Vista и Windows Longhorn Server). Алгоритм предотвращения перегрузки увеличивает окно отправки на один полный сегмент TCP на каждое полное подтвержденное окно данных.

Эти алгоритмы дают хорошие результаты при небольших значениях BDP и небольшом размере окон приема. Однако для соединений TCP с большим размером окна приема и большим значением BDP, например в ситуациях с репликацией данных на двух серверах, соединенных высокоскоростным каналом WAN с временем приема-передачи 100 мс, эти алгоритмы не увеличивают окно отправки достаточно быстро для того чтобы полностью использовать пропускную способность соединения.

Для оптимального использования пропускной способности канала TCP в подобных случаях в новую версию набора протоколов TCP/IP включен протокол Compound TCP (CTCP). Протокол CTCP осуществляет более агрессивное увеличение окна отправки для соединений с большим размером окна приема и большим значением BDP. Протокол CTCP пытается максимально повысить пропускную способность подобных соединений, отслеживая изменения уровня задержки и уровня потерь. Кроме того, CTCP обеспечивает отсутствие негативного воздействия на другие соединения TCP.

При проведенном в корпорации Майкрософт тестировании время резервного копирования больших файлов удалось сократить почти в два раза при использовании соединения пропускной способностью 1 Гбит/с с временем приема-передачи 50 мс. Если значение BDP выше, производительность можно повысить еще больше. Совместное использование протокола CTCP и автоматической настройки окна приема TCP позволяет повысить эффективность использования канала и значительно увеличить производительность соединений с большими значениями BDP.

По умолчанию протокол CTCP включен на компьютерах, работающих под управлением ОС Windows Longhorn Server, и отключен на компьютерах, работающих под управлением ОС Windows Vista. Протокол CTCP можно включить с помощью команды netsh interface tcp set global congestionprovider=ctcp. Для отключения протокола CTCP служит команда netsh interface tcp set global congestionprovider=none.

Размер поля Window в заголовке TCP составляет 16 бит; это означает, что узел TCP может указать максимальный размер окна приема 65535 байт. Рассчитать примерную пропускную способность для заданного размера окна TCP можно с помощью следующей формулы:

Throughput = TCP maximum receive windowsize / RTT

Например, при размере окна приема 65535 байт и времени приема-передачи канала 100 мс примерная пропускная способность будет составлять 5,24 Мбит/с независимо от реальной пропускной способности канала. В настоящее время большинство каналов передачи имеют высокую пропускную способность и высокое значение BDP, так что даже при максимальном размере окно TCP превращается в узкое место.

Масштабирование окна TCP

В предложении RFC 1323 (ietf.org/rfc/rfc1323.txt, на английском языке) дано определение масштабирования окон, позволяющего получателю указывать размер окна больше 65535 байт, что позволит применять большие размеры окон и высокоскоростные каналы передачи. Параметр TCP Window Scale указывает коэффициент масштабирования окна, который в сочетании с 16-битным полем Window в заголовке TCP может увеличивать размер окна приема до максимального значения, составляющего примерно 1 ГБ. Параметр Window Scale отправляется только в сегментах синхронизации (SYN) при установке соединения. Оба узла TCP могут указывать разные коэффициенты масштабирования для окон приема. Масштабирование окон TCP позволяет отправителю посылать больше данных, благодаря чему узлы TCP могут более эффективно использовать некоторые типы путей передачи с высоким значением BDP.

Хотя размер окна приема важен для пропускной способности канала TCP, не менее важна для определения оптимальной пропускной способности TCP скорость извлечения данных приложением из окна приема. Если приложение не извлекает данные, окно приема заполняется и принимающий узел уменьшает размер текущего окна приема. В исключительных случаях возможно даже заполнение максимального окна приема, в результате чего размер текущего окна уменьшается до 0 байт. В этом случае отправитель должен прекратить посылать данные до тех пор, пока окно приема не очистится. Таким образом, для оптимизации пропускной способности соединений TCP для окна приема TCP следует устанавливать размер, соответствующий значению BDP канала передачи и скорости извлечения данных приложением.

Тем не менее, даже если значение BDP и скорость извлечения данных приложением определены правильно, они могут измениться. Значение BDP может меняться в зависимости от перегруженности пути передачи, а скорость извлечения данных приложением может меняться в зависимости от числа соединений, по которым приложение получает данные.

Окно приема в Windows XP

Для TCP/IP в Windows XP (и Windows Server® 2003) максимальный размер окна приема имеет ряд важных свойств. Значение по умолчанию зависит от скорости соединения отправляющего интерфейса. Реальное значение автоматически подстраивается к равномерным увеличениям максимального размера сегмента, определяемым при установке соединения TCP.

Максимальный размер окна приема можно настроить самостоятельно. Параметрам реестра HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize и HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize можно устанавливать значения до 65535 байт (без масштабирования окна) или до 1073741823 (с масштабированием).

Для установки максимального размера окна приема можно использовать масштабирование. Его можно включить, поменяв значение параметра реестра HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts на 1 или 3. По умолчанию масштабирование окон используется в соединениях, только если полученный сегмент SYN содержит параметр Window Scale.

Кроме того, максимальный размер окна приема может быть указан приложением с помощью параметра SO_RCVBUF Windows Sockets при установке соединения. При использовании масштабирования окон приложение должно указывать размер более 65535 байт.

Несмотря на поддержку масштабируемых окон, максимальный размер окна приема в Windows XP все равно может ограничивать пропускную способность, поскольку (если приложением не указывается иное) именно фиксированный максимальный размер окна приема для всех соединений TCP может повысить пропускную способность некоторых соединений и понизить пропускную способность для других соединений. Фиксированный максимальный размер окна приема для соединений TCP не меняется с изменением скорости извлечения данных приложением или перегрузки маршрута передачи.

Автоматическая настройка окна приема в Windows Vista

Для оптимизации пропускной способности соединений TCP, особенно для каналов передачи с высоким значением BDP, в новой версии набора протоколов TCP/IP в Windows Vista (и следующей версии Windows Server под кодовым названием «Longhorn») реализована поддержка автоматической настройки окна приема. Оптимальный размер окна приема определяется посредством измерения значения BDP и скорости извлечения данных приложением, после чего размер окна адаптируется в соответствии с параметрами канала передачи и приложения.

Функция автоматической настройки окна приема по умолчанию использует масштабирование окна TCP, благодаря чему максимальный размер окна приема составляет 16 МБ. По мере перемещения данных по каналу набор протоколов TCP/IP нового поколения отслеживает соединение, измеряет текущее значение BDP и скорость извлечения данных приложением и регулирует размер окна приема для оптимизации пропускной способности. Набор протоколов TCP/IP нового поколения больше не использует значение реестра TCPWindowSize.

Функция автоматической настройки окна приема имеет ряд преимуществ. Она автоматически определяет оптимальный размер окна для каждого соединения. В Windows XP значение ключа реестра TCPWindowSize действует для всех соединений. Приложениям больше не требуется указывать размер окон TCP с помощью параметра Windows Sockets. А администраторам больше не надо вручную настраивать размер окна приема TCP для конкретных компьютеров.

С автоматической настройкой окна приема узлы TCP под управлением Windows Vista обычно будут указывать больший размер окна приема, чем узлы TCP под управлением Windows XP. Это позволяет другим узлам TCP задействовать все ресурсы узла TCP под управлением Windows Vista, отправляя больше сегментов данных TCP без ожидания подтверждения (ACK). При этом действует система контроля перегрузки канала TCP. При соединении с клиентскими компьютерами, например для передачи веб-страниц или электронной почты, веб-сервер или сервер электронной почты смогут быстрее отправлять данные TCP на клиентский компьютер, в результате чего повысится общая производительность сети. Чем выше будут значение BDP и скорость извлечения данных приложением, тем значительнее повысится производительность.

В результате пакеты данных TCP, которые в противном случае отправлялись бы медленнее из-за ограничений, посылаются намного быстрее, благодаря чему значительно повышается эффективность использования сети для передачи данных. Для компьютеров под управлением Windows XP и Windows Vista, выполняющих передачу данных по длинному и широкому каналу, передается одинаковый объем данных. Однако для клиентского компьютера под управлением Windows Vista данные передаются быстрее благодаря большому размеру окна приема и наличию у сервера возможности полностью заполнять канал передачи от сервера к клиенту.

Поскольку автоматическая настройка окна приема повышает эффективность использования сетей с высоким значением BDP, использование службы QoS или увеличение скорости отправки данных приложением могут оказаться важными для каналов, емкость которых используется практически полностью. Для этого Windows Vista поддерживает настройку параметров QoS на основе групповых политик, что позволяет определять скорость отправки данных на определенные IP-адреса или порты TCP. Более подробную информацию можно найти на странице, посвященной средствам QoS(на английском языке).

Повышение пропускной способности TCP в сетях с высоким уровнем потери данных

В сетях с высоким уровнем потери данных пропускная способность TCP значительно снижается из-за частого превышения времени ожидания и частой необходимости повторной передачи. В качестве примера сетей с высоким уровнем потерь можно привести беспроводные сети, например, построенные на базе стандартов IEEE 802.11, GPRS или UMTS. В этих сетях наблюдается высокий уровень потери пакетов, что связано с состоянием сети, затуханием сигнала, электромагнитными помехами и изменением положения компьютера.

В новом поколении набора протоколов TCP/IP используются следующие четыре положения RFC для оптимизации пропускной способности в условиях высокого уровня потерь.

RFC 2582: Применение модифицированного алгоритма NewReno к алгоритму TCP Fast Recovery

Алгоритм Fast Recovery, определенный в положении RFC 2001, основан на алгоритме Reno, увеличивающем объем данных, который может быть передан при повторной отправке сегмента в связи с быстрой повторной передачей. Хотя алгоритм Reno хорошо работает с одиночными потерянными сегментами, при потере нескольких сегментов его производительность падает. Алгоритм NewReno обеспечивает более высокую пропускную способность, изменяя способ увеличения скорости посылки данных отправителем при быстром восстановлении, когда теряется несколько сегментов окна данных и отправитель получает частичное подтверждение (подтверждение получения только части данных).

RFC 2883: Расширение параметра SACK для протокола TCP

Параметр SACK, определяемый в положении RFC 2018, позволяет получателю указать до четырех несвязанных блоков полученных данных с помощью параметра SACK TCP. RFC 2883 определяет дополнительное использование полей параметра SACK TCP для подтверждения получения дублирующихся пакетов. Благодаря этому отправитель может определить, когда сегмент передан повторно без необходимости, и откорректировать алгоритм работы так, чтобы предотвратить ненужную передачу данных в будущем. Чем меньше сегментов отправляется повторно, тем выше общая пропускная способность.

RFC 3517: Консервативный алгоритм восстановления после потери с выборочным подтверждением (SACK) в протоколе TCP

В текущей реализации протокола TCP/IP в Windows Server 2003 и Windows XP информация SACK используется только для того чтобы определять, когда сегменты TCP не достигают пункта назначения. В положении RFC 3517 определяется метод использования информации SACK для восстановления после сбоя при получении дублирующихся сегментов с заменой старого алгоритма быстрого восстановления, когда при подключении параметр SACK включен. В новой версии набора протоколов TCP/IP информация SACK отслеживается для каждого соединения и выполняется мониторинг получаемых подтверждений, в том числе дублирующихся подтверждений для быстрого восстановления в ситуациях, когда несколько сегментов остаются не полученными в пункте назначения.

RFC 4138: Forward RTO-Recovery (F-RTO): алгоритм определения истечения времени ожидания при случайной повторной передаче по протоколу TCP и протокол SCTP

Случайная повторная передача сегментов TCP может возникать при внезапном увеличении времени приема-передачи, в результате чего истекает время ожидания повторной передачи уже отправленных сегментов и протокол TCP начинает еще раз отправлять их. Если увеличение происходит перед отправкой полного окна данных, отправитель может заново отправить целое окно данных. Алгоритм F-RTO предотвращает случайную повторную передачу сегментов TCP следующим образом.

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

В результате в сетях, где время приема-передачи может неожиданно меняться, например, если беспроводной клиент переходит от одной точки доступа к другой, F-RTO предотвращает ненужную повторную передачу сегментов и быстрее возвращается к нормальной скорости передачи. Использование восстановления при потерях на базе SACK и F-RTO лучше всего подходит для соединений GPRS.

Джозеф Дэвис (Joseph Davies) работает техническим писателем в корпорации Майкрософт. Он занимается преподаванием и пишет о сетях Windows с 1992 года. Дэвис написал пять книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику TechNet Cable Guy.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.