TCP/IP performance tuning for Azure VMs (Настройка производительности TCP/IP для виртуальных машин Azure)

2025-04-21

В этой статье рассматриваются распространенные методы настройки производительности TCP/IP и некоторые факторы, которые следует учитывать при их использовании для виртуальных машин, работающих в Azure. В ней представлен базовый обзор методов и описано, как можно настроить виртуальные машины.

Распространенные методы настройки TCP/IP

MTU, фрагментация и разгрузка большого объема отправки

MTU

Максимальная единица передачи (MTU) — это самый большой кадр размера (пакеты и заголовки доступа к сети), указанный в байтах, которые можно отправить через сетевой интерфейс. Параметр MTU является настраиваемым. Значение MTU по умолчанию, используемое на виртуальных машинах Azure, и настройка по умолчанию для большинства сетевых устройств составляет 1500 байт.

Фрагментация

Фрагментация происходит при отправке пакета, размер которого превышает значение MTU сетевого интерфейса. Стек TCP/IP разбивает пакет на небольшие части (фрагменты), соответствующие MTU интерфейса. Фрагментация происходит на уровне IP-адреса и не зависит от базового протокола (например, TCP). Когда 2000-байтовый пакет отправляется через сетевой интерфейс с MTU 1500, пакет разбивается на один 1500-байтовый пакет и один 500-байтовый пакет.

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

Бит "не фрагментировать" в пакете IP

Бит "не фрагментировать" (DF) является флагом в заголовке IP-протокола. Бит DF указывает, что сетевые устройства на маршруте между отправителем и получателем не должны фрагментировать пакет. Этот бит может быть установлен по целому ряду причин. (Один из примеров см. в разделе "Определение MTU маршрута" данной статьи.) Когда сетевое устройство получает пакет с установленным битом "не фрагментировать", а пакет превышает MTU интерфейса, оно по умолчанию отбрасывает этот пакет. Устройство отправляет сообщение ICMP о необходимости фрагментации обратно первоначальному источнику пакета.

Влияние фрагментации на производительность

Фрагментация может негативно сказаться на производительности. Одной из основных причин влияния на производительность является влияние фрагментации и повторной сборки пакетов цП или памяти. Если сетевое устройство должно фрагментировать пакет, он должен выделить ресурсы ЦП или памяти для выполнения фрагментации.

То же самое происходит при повторной сборке пакета. Сетевое устройство должно хранить все фрагменты, пока они не будут получены, чтобы он смог повторно собрать их в исходный пакет.

Azure и фрагментация

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

Azure по умолчанию удаляет фрагментированные пакеты, поступающие на виртуальную машину вне порядка, то есть пакеты не соответствуют последовательности передачи из исходной конечной точки. Эта проблема может возникать при перемещении пакетов через Интернет или других крупных WAN.

Настройка MTU

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

Дополнительные сведения о настройке MTU на виртуальных машинах Azure см. в статье "Настройка максимальной единицы передачи ( MTU) для виртуальных машин в Azure.

Выгрузка больших данных

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

При включении LSO клиенты Azure могут заметить большие размеры кадров во время захвата пакетов. Эти большие размеры кадров могут привести к тому, что некоторые клиенты предположат, что фрагментация возникает или используется большой MTU, хотя на самом деле это не так. С помощью LSO адаптер Ethernet может сообщить о большем максимальном размере сегмента (MSS) стеку TCP/IP, чтобы создать более крупный TCP-пакет. Затем адаптер Ethernet разбивает весь несегментированный кадр на множество небольших кадров в соответствии с его MTU, которые отображаются в записи пакетов, выполняемой на виртуальной машине.

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

Максимальный размер сегмента TCP

Максимальный размер сегмента TCP (MSS) — это параметр, ограничивающий размер TCP-сегментов, что позволяет избежать фрагментации пакетов TCP. Операционные системы обычно используют эту формулу для задания MSS:

MSS = MTU - (IP header size + TCP header size)

Заголовок IP и заголовок TCP имеют размер 20 байт каждый (всего 40 байт). Интерфейс с MTU 1500 имеет MSS 1460. MSS можно настроить.

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

Помните, что значения MTU источника и назначения не являются единственными факторами, определяющими величину MSS. На промежуточных сетевых устройствах, таких как VPN-шлюзы Azure, MTU может настраиваться независимо от источника и назначения с целью оптимизировать производительность сети.

Обнаружение пути MTU

Параметр MSS согласовывается, однако не всегда указывает на фактический MSS, который может быть использован. Другие сетевые устройства в пути между источником и назначением могут иметь меньшее значение MTU, чем источник и назначение. В этом случае устройство, MTU которого меньше, чем пакет, удаляет пакет. Устройство отправляет сообщение ICMP "Требуется фрагментация" (тип 3, код 4), содержащее его MTU. Это сообщение ICMP позволяет исходному узлу уменьшить MTU для соответствующего маршрута. Этот процесс называется обнаружением MTU пути (Path MTU Discovery, PMTUD).

Процесс PMTUD снижает производительность сети из-за ее неэффективности. При превышении MTU сетевого пути пакеты необходимо повторно передавать с помощью более низкой MSS. Если сетевой брандмауэр блокирует сообщение ICMP Fragmentation Needed, отправитель остаётся в неведении о необходимости снизить MSS и повторно переотправляет пакет. По этой причине мы советуем не увеличивать MTU виртуальной машины Azure.

VPN и MTU

Если вы используете виртуальные машины, выполняющие инкапсуляцию (например, виртуальные сети IPsec), существуют некоторые другие рекомендации по размеру пакетов и MTU. VPN добавляют дополнительные заголовки в пакеты. Добавленные заголовки увеличивают размер пакета и требуют меньшего размера MSS.

Для Azure мы рекомендуем установить ограничение MSS TCP до 1350 байт и MTU интерфейса туннеля — до 1400 байт. Дополнительные сведения см. на странице параметров VPN-устройств и IPsec/IKE.

Задержка, время кругового пути и масштабирование окна TCP

Задержка и время кругового пути

Скорость света определяет задержку сети по оптоволоконной сети. Время кругового пути (RTT) между двумя сетевыми устройствами управляет пропускной способностью сети TCP.

Маршрут	расстояние;	Время одностороннего маршрута	Время обратного пути
Нью Йорк — Сан-Франциско	4148 км	21 мс	42 мс
Нью Йорк — Лондон	5585 км	28 мс	56 мс
Нью Йорк — Сидней	15993 км	80 мс	160 мс

В этой таблице показано расстояние по прямой между двумя точками. Расстояние в сетях обычно превышает расстояние по прямой. Ниже приведена простая формула для вычисления минимального RTT, зависящего от скорости света.

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Для скорости распространения можно использовать значение 200. Скорость распространения — это расстояние в километрах, которое свет проходит за 1 миллисекунду.

Возьмем в качестве примера расстояние между Нью-Йорком и Сан Франциско. Расстояние по прямой составляет 4148 км. Ввод этого значения в уравнение приводит к следующему уравнению:

Minimum RTT = 2 * (4,148 / 200)

Результат уравнения приведен в миллисекундах.

Если требуется повысить производительность сети, оптимальным вариантом будет выбор мест назначения с кратчайшим расстоянием между ними. Кроме того, следует спроектировать виртуальную сеть таким образом, чтобы оптимизировать маршрут трафика и сократить задержку. Дополнительные сведения см. в разделе "Вопросы проектирования сети" этой статьи.

Влияние задержки и времени кругового пути на TCP

Время кругового пути напрямую влияет на максимальную пропускную способность TCP. В протоколе TCP размер окна — это максимальный объем трафика, который можно отправить через TCP-подключение, прежде чем отправитель должен получить подтверждение от получателя. Если для TCP MSS задано значение 1460, а размер окна TCP имеет значение 65 535, отправитель может отправить 45 пакетов перед подтверждением от получателя. Если отправитель не получает подтверждения, он повторно отправляет данные. Формула выглядит так:

TCP window size / TCP MSS = packets sent

В этом примере 65 535/1460 округляется до 45.

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

Ниже приведена формула для вычисления максимальной пропускной способности отдельного TCP-подключения.

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

В этой таблице показана максимальная пропускная способность (в МБ/с) для одного TCP-подключения (для удобства в качестве единицы измерения используются мегабайты.)

Размер окна TCP, байты	Задержка RTT, мс	Максимальная пропускная способность в мегабайтах за секунду	Максимальная пропускная способность в мегабитах за секунду
65 535	1	65,54	524,29
65 535	30	2.18	17,48
65 535	шестьдесят	1,09	8,74
65 535	девяносто	0.73	5,83
65 535	120	0.55	4,37

Если пакеты потеряны, максимальная пропускная способность TCP-подключения уменьшается, пока отправитель повторно передает данные, отправляемые им.

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

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

Эта зависимость показана в таблице ниже.

Размер окна TCP, байты	Задержка RTT, мс	Максимальная пропускная способность в мегабайтах за секунду	Максимальная пропускная способность в мегабитах за секунду
65 535	30	2.18	17,48
131 070	30	4,37	34,95
262 140	30	8,74	69,91
524 280	30	17,48	139,81

При этом длина заголовка TCP для окна TCP составляет всего 2 байта, что означает, что максимальное значение окна приема равно 65 535. Для увеличения максимального размера окна был введен коэффициент масштабирования окна TCP.

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

TCP window size = TCP window size in bytes * (2^scale factor)

Ниже приведен расчет для коэффициента масштабирования 3 и размера окна 65 535.

65,535 * (2^3) = 524,280 bytes

С коэффициентом масштабирования 14 размер окна TCP увеличивается до 14 (максимальное допустимое смещение). Размер окна TCP составляет 1 073 725 440 байт (8,5 гигабит).

Поддержка масштабирования окна TCP

В Windows можно задавать различные коэффициенты масштабирования для разных типов подключений (классы подключений включают центр обработки данных, Интернет и т. д .). Чтобы просмотреть тип подключения для масштабирования окна, используйте команду PowerShell Get-NetTCPConnection:

Get-NetTCPConnection

Для просмотра значений каждого класса можно использовать команду PowerShell Get-NetTCPSetting:

Get-NetTCPSetting

Задать начальный размер окна TCP и коэффициент масштабирования TCP в Windows можно с помощью команды PowerShell Set-NetTCPSetting. Дополнительные сведения см. в разделе Set-NetTCPSetting.

Set-NetTCPSetting

Ниже приведены действующие параметры TCP для AutoTuningLevel:

уровень автоматической настройки	Коэффициент масштабирования	Множитель масштабирования	Формула для высчитать максимальный размер окна
Отключено	нет	нет	Размер окна
С ограниченным доступом	4	2^4	Размер окна × (2^4)
Высокий уровень ограничений	2	2^2	Размер окна × (2^2)
Обычная	8	2^8	Размер окна × (2^8)
Экспериментальный	14	2^14	Размер окна × (2^14)

Эти параметры, скорее всего, повлияют на производительность TCP, однако следует помнить, что влиять на нее также могут многие другие факторы в Интернете, на которые не влияют настройки среды Azure.

Ускорение работы в сети и масштабирование на стороне приема

Ускорение работы в сети

Функции сети виртуальных машин исторически являются интенсивными ЦП как на гостевой виртуальной машине, так и на гипервизоре или узле. ЦП узла обрабатывает в программном обеспечении все пакеты, проходящие через узел, включая инкапсуляцию и декапсуляцию всех виртуальных сетей. Чем больше трафик проходит через узел, тем выше загрузка ЦП. Если ЦП узла занят другими операциями, влияющими на пропускную способность сети и задержку. Azure решает эту задачу путем ускорения сети.

Режим ускорения сети обеспечивает постоянную сверхнизкую задержку за счет использования встроенного программируемого оборудования Azure и различных технологий, таких как SR-IOV. Ускоренная сеть переносит значительную часть программно-определяемого сетевого стека Azure с процессоров на SmartNIC, основанные на FPGA. Это изменение позволяет приложениям конечных пользователей восстановить циклы вычислений, которые снижают нагрузку на виртуальную машину и несогласованность в задержке. Иными словами, производительность становится более стабильной.

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

Меньшая задержка / большее количество пакетов в секунду (pps): удаление виртуального коммутатора из пути данных устраняет время, которое пакеты проводят в узле для обработки политик, и увеличивает количество пакетов, которые можно обрабатывать в виртуальной машине.
Уменьшение нагрузки. Обработка виртуальных коммутаторов зависит от объема политики, которую необходимо применить, и рабочей нагрузки ЦП, выполняющей обработку. Так как принудительное применение политик осуществляется на аппаратном уровне, эта зависимость устраняется за счет доставки пакетов непосредственно на виртуальную машину. Это позволяет избежать обмена данными между узлом и виртуальной машиной, прерываний работы программного обеспечения и переключений контекста.
Уменьшение использования ЦП. Обход виртуального коммутатора в узле приводит к меньшему использованию ЦП для обработки сетевого трафика.

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

Масштабирование на стороне приема

Масштабирование на стороне приема (RSS) — это технология сетевого драйвера, которая эффективнее распределяет прием сетевого трафика между несколькими процессорами в многопроцессорной системе. Простыми словами, RSS позволяет системе обрабатывать больше поступающего трафика, так как использует все доступные процессоры, а не только один. Для получения дополнительных технических сведений о RSS см. Введение в масштабирование на стороне получения.

Чтобы добиться максимальной производительности с включенным режимом ускорения сети на виртуальной машине, необходимо активировать RSS. Кроме того, RSS повышает эффективность и виртуальных машин, которые не используют ускорение сети. Общие сведения о том, как определить, включен ли RSS и как включить его, см. в статье "Оптимизация пропускной способности сети для виртуальных машин Azure".

Ликвидация TCP TIME_WAIT и TIME_WAIT

TCP-TIME_WAIT — это еще один распространенный параметр, который влияет на производительность сети и приложений. Занятые виртуальные машины часто открывают и закрывают множество сокетов, выступая как клиентами, так и серверами. Во время обычных операций TCP сокет часто входит в состояние TIME_WAIT и остается там в течение длительного периода. Это состояние гарантирует доставку оставшихся данных по сокету, прежде чем он закрывается. В результате стеки TCP/IP обычно предотвращают повторное использование сокета путем автоматического удаления пакета TCP SYN клиента.

Вы можете настроить, сколько времени сокет остается в состоянии TIME_WAIT. Длительность может варьироваться от 30 секунд до 240 секунд. Сокеты являются конечным ресурсом, и их доступность настраивается. Как правило, около 30 000 сокетов доступны для использования в любое время. Если система использует все доступные сокеты или если клиенты и серверы используют несогласованные параметры TIME_WAIT, виртуальная машина может попытаться повторно использовать сокет в состоянии TIME_WAIT. В таких случаях новые подключения завершаются ошибкой, так как пакеты TCP SYN автоматически удаляются.

Значение диапазона портов для исходящих сокетов можно настроить в стеке TCP/IP операционной системы. То же самое применимо и для параметров TCP TIME_WAIT и повторного использования сокета. Изменение этих чисел может вести к улучшению масштабируемости. Но в зависимости от ситуации эти изменения могут вызвать проблемы взаимодействия. Следует соблюдать осторожность при их изменении.

Вы можете использовать метод уничтожения TIME_WAIT, чтобы обойти это ограничение на масштабирование. Ликвидация TIME_WAIT позволяет повторно использовать сокет в определенных ситуациях, например если порядковый номер в IP-пакете нового соединения превышает порядковый номер последнего пакета из предыдущего соединения. В этом случае операционная система позволяет установить новое подключение (оно принимает новый SYN/ACK) и принудительно закрыть предыдущее подключение, которое было в состоянии TIME_WAIT. Эта возможность поддерживается на виртуальных машинах Windows в Azure. Чтобы узнать о поддержке на других виртуальных машинах, обратитесь к поставщику соответствующей ОС.

Сведения о настройке параметров tcp-TIME_WAIT и диапазона исходных портов см. в разделе "Параметры", которые можно изменить для повышения производительности сети.

Факторы виртуальной сети, которые могут влиять на производительность

Максимальная исходящая пропускная способность виртуальной машины

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

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

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

Функция ускорения сети позволяет повысить производительность сети по таким показателям, как задержки в сети, пропускная способность и использование ЦП. Ускорение сети может увеличить пропускную способность вириальной машины, но только в пределах пропускной способности, выделенной для нее.

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

Ожидаемая исходящая пропускная способность и количество сетевых интерфейсов, поддерживаемых каждым размером виртуальной машины, подробно описаны в разделе "Размеры" для виртуальных машин Windows в Azure. Чтобы просмотреть максимальную пропускную способность, выберите тип, например "Общее назначение", а затем найдите раздел о серии размеров на результирующей странице (например, "Серия Dv2"). Для каждой серии существует таблица с характеристиками, в которой спецификации сети указаны в последнем столбце под названием "Максимальное число сетевых адаптеров и ожидаемая пропускная способность сети (Мбит/с)".

Ограничение пропускной способности применяется ко всей виртуальной машине. Пропускная способность не влияет на следующие факторы:

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

Дополнительные сведения см. в разделе "Пропускная способность сети виртуальной машины".

Оптимизация виртуальных машин Linux

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

Дополнительные сведения см. в статье "Оптимизация пропускной способности сети на виртуальных машинах Azure"

Вопросы производительности интернет-соединений

Как обсуждалось в этой статье, на производительность сети могут повлиять факторы в Интернете вне сферы контроля Azure. Ниже приведены некоторые из них.

Задержка: На время кругового пути между двумя конечными точками влияют проблемы в промежуточных сетях, трафик, который не следует "самому короткому" пути, и неоптимальные маршруты пиринга.
Потеря пакетов: потеря пакетов вызвана перегрузкой сети, проблемами физического пути и недоработающими сетевыми устройствами.
Размер MTU/Фрагментация: Фрагментация по пути может привести к задержкам при поступлении данных или к поступлению пакетов в неправильном порядке, что может повлиять на доставку пакетов.

Хорошим инструментом для измерения характеристик производительности сети (таких как потеря пакетов и задержка) по каждому сетевому маршруту между исходным и конечным устройством является утилита Traceroute.

Вопросы проектирования сети

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

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

Регионы Azure, виртуальные сети и задержка

Регионы Azure состоят из нескольких центров обработки данных, которые расположены в одной географической области. Эти центры могут не находиться рядом друг с другом физически. В некоторых случаях они разделены на расстояние до 10 километров. Виртуальная сеть — это логическая конструкция, созданная на базе структуры сети физических центров обработки данных Azure. Виртуальная сеть не подразумевает какую-либо конкретную сетевую топологию в центре обработки данных.

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

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

Нехватка исходных портов SNAT

Развертывания в Azure могут взаимодействовать с конечными точками за пределами Azure в общедоступном сегменте Интернета и / или в пространстве общедоступных IP-адресов. Когда экземпляр инициирует исходящее подключение, Azure динамически сопоставляет частный IP-адрес с общедоступным IP-адресом. После создания этого сопоставления средой Azure обратный трафик исходящего потока также можно направлять по частному IP-адресу, с которого поток исходил изначально.

Подсистема Azure Load Balancer должна поддерживать это сопоставление для каждого исходящего подключения в течение некоторого периода. Учитывая мультитенантную природу Azure, поддержание этого сопоставления для каждого исходящего потока и каждой виртуальной машины может быть ресурсоемкой задачей. Поэтому существуют ограничения, которые задаются и основываются на конфигурации виртуальной сети Azure. Или, чтобы сказать, что более точно виртуальная машина Azure может выполнять только некоторые исходящие подключения в определенное время. По достижении этих ограничений виртуальная машина не сделает больше исходящих подключений.

Но это поведение можно настроить. Дополнительные сведения о SNAT и исчерпании его портов см. в этой статье.

Измерение производительности сети в Azure

Многие из максимальных значений производительности в этой статье связаны с задержкой в сети или временем циклического пути (RTT) между двумя виртуальными машинами. Этот раздел содержит рекомендации по тестированию задержки и RTT, а также проверке производительности TCP и производительности сети виртуальных машин. Вы можете настроить и протестировать производительность для описанных выше параметров TCP/IP и сети, используя методы, описанные в этом разделе. Введите значения задержки, MTU, MSS и размера окна в вычисления, предоставленные ранее, и сравните теоретические максимумы с фактическими значениями, наблюдаемым во время тестирования.

Измерение времени кругового пути и потери пакетов

Производительность TCP в значительной степени зависит от RTT и потери пакетов. Служебная программа PING, доступная в Windows и Linux, является наиболее простым способом для измерения показателей RTT и потери пакетов. Выходные данные PING показывают минимальную/максимальную/среднюю задержку между источником и назначением. В нем показана потеря пакетов. PING по умолчанию использует протокол ICMP. Для проверки RTT TCP-соединения можно использовать PsPing. Дополнительные сведения см. в разделе PsPing.

Пинги ICMP и TCP не измеряют ускоренный сетевой путь. Чтобы оценить производительность пути передачи данных, прочитайте о Latte и SockPerf в этой статье.

Измерение фактической пропускной способности виртуальной машины

Чтобы точно измерить пропускную способность виртуальных машин Azure, следуйте этим рекомендациям.

Дополнительные сведения о тестировании других сценариев см. в следующих статьях:

Обнаружение проблем с эффективностью TCP

При сборе пакетов клиенты Azure могут видеть TCP-пакеты с флагами TCP (SACK, DUP ACK, RETRANSMIT и FAST RETRANSMIT), которые могут указывать на проблемы с производительностью сети. Эти пакеты прямо указывают на неэффективность сети вследствие потери пакетов. Однако потеря пакетов не обязательно связана с проблемами с производительностью Azure. Проблемы с производительностью могут быть результатом приложения, операционной системы или других проблем, которые могут не быть непосредственно связаны с платформой Azure.

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

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

Следующие шаги

Теперь, когда вы узнали о настройке производительности TCP/IP для виртуальных машин Azure, рассмотрите другие факторы планирования виртуальных сетей. Вы также можете узнать больше о подключении и настройке виртуальных сетей.