Tcp mss что это

k4’s blog

JunOS, IOS, Unix, Linux, Windows, routing, switching, security, QoS, network design, telecom.. Статьи, заметки. Решил собрать блог, чтоб разместить полезные статьи в одном месте.

четверг, 21 июня 2012 г.

Предотвращение IP-фрагментации. Что такое TCP MSS и как оно работает

Оригинал тут http://www.cyberguru.ru/networks/protocols/ip-fragmentation-page3.html

Максимальный Размер TCP Сегмента (MSS) определяет максимальное количество данных, которые хост желает принимать в единственной TCP/IP датаграмме. Эта TCP/IP датаграмма может быть фрагментирована в уровне IP. Значение MSS посылают как опциию TCP заголовка только в сегменте TCP SYN. Каждая сторона на TCP соединении сообщает свое значение MSS другой стороне. Хост отправитель обязан ограничивать размер данных в единственном TCP сегменте в значение, меньшем или равном MSS, о котором сообщает хост получатель.

Первоначально, значение MSS означало, сколько памяти нужно выделить (больше или равной 65496 КБ) на станции получателя, чтобы в состоянии хранить TCP данные, содержавшиеся в пределах единственной IP датаграммы. MSS был максимальным сегментом (кусочком) данных, которые желал принимать TCP получатель. Этот TCP сегмент мог быть огромным, примерно до 64 КБ (максимальный размер IP датаграммы), и его необходимо было фрагментировать на уровне IP, чтобы передать по сети к хосту получателю. Принимающий хост повторно должен был собрать IP датаграмму прежде, чем передать полный TCP сегмент на уровень TCP.

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

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

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

В Сценарии 2, фрагментация не происходит, потому что хостами были приняты во внимание MTU обоих интерфейсов. Пакеты могут все еще фрагментироваться в сети между Router A и Router B, если они встретят линк с более низким MTU.

Источник

Понятия IP фрагментация, MTU, MSS, PMTUD и их связь

Данный пост написан по мотивам статьи «Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC» c сайта Cisco, рассказывающей про работу механизма Path Maximum Unit Discovery (PMTUD) в связке с разными механизмами туннелирования IP.

IP фрагментация и обратная сборка

Длина IP пакета может достигать 64 Кбайтов, что может превышать размер фрейма (MTU) протокола нижнего уровня, в который инкапсулируется IP. Поскольку IP может передаваться по средам с разными значениями MTU, в него был встроен механизм фрагментации. Задача принимающей стороны обратно собрать фрагменты в оригинальный IP пакет.
При IP фрагментации IP пакет делится на несколько кусочков (фрагментов), оформленных таким образом, чтобы у принимающей машины была возможность их собрать в оригинальный IP пакет. Для ее работы в заголовке IP пакета используются сл. поля: адрес источника и получателя, идентификационный номер, размер пакета, смещение фрагмента и флаги: «не фрагментировать» (DF) и «у пакета еще есть фрагменты»(MF).

Проблемы с IP фрагментацией

При работе с IP фрагментацией следует помнить о нескольких особенностях.

Обход IP фрагментации путем использования TCP MSS.

TCP Maximum Segment Size (MSS) определяет максимальный размер данных, который машина готова получить через один TCP сегмент. Сам TCP сегмент инкапсулируется в IP пакет. Значение MSS передается в заголовке TCP SYN при установлении соединения между двумя узлами (через механизм трехэтапного установления соединения). Обе стороны соединения передают значение своего MSS. В отличие от популярного заблуждения, принимаемое значение MSS не несет характер переговоров. Отправляющий хост обязан ограничить размер своих исходящих TCP сегментов значением равным или меньшим значению, сообщенному ему принимающим хостом.
Значение MSS выбирается таким образом, чтобы предотвратить IP фрагментацию. Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение.
Пример работы MSS:

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

Что такое PMTUD?

В предыдущем примере TCP MSS выполнил работу по избавлению от IP фрагментации. Однако такая ситуация возможна только если MTU сети на пути между двумя хостами будет не ниже MTU исходящих интерфейсов этих машин. На случай различных значений MTU между двумя узлами был создан PMTUD.
Стоит отметить, что PMTUD поддерживается только TCP протоколом, UDP и другие протоколы его не поддерживают. Если машина поддерживает PMTUD, то все TCP IP пакеты помечаются флагом DF («не фрагментировать»).
Когда машина отправляет пакет с DF флагом, работа PMTUD заключается в том, чтобы уменьшать значение MSS в исходящем TCP сегменте, если будет получена информация о том, что пакет нуждается в фрагментации. Машина запоминает значение MTU создавая строчку в таблице маршрутизации до соответствующего получателя.
Если маршрутизатор получает IP пакет, с установленным флагом DF, который он не может передать дальше из-за малого значения MTU исходящего интерфейса, он сбрасывает пакет и отправляет ICMP сообщение «Destination Unreachable» к источнику этого IP пакета указывая «fragmentation needed and DF set» как код ошибки (type 3, code 4). Когда машина, отправлявшая IP пакет, получит данное сообщение, она уменьшит значение MSS, в последующем TCP сегменте.
В соответствии с RFC 1191, маршрутизатор отправляющий ICMP сообщение «fragmentation needed and DF set», должен указать значение MTU исходящего интерфейса.
Механизм PMTUD работает постоянно, поскольку путь от одной машины к другой может измениться. Получив сообщение «Can’t Fragment» он обновляет таблицу маршрутизации машины.
PMTUD выполняется для обоих направлений TCP независимо, т.к. пути входящего и исходящего трафика могут различаться.

Проблемы PMTUD

В процессе работы PMTUD могут произойти три проблемы:

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

С распространением различного вида туннелирования трафика проблема IP фрагментации стала более насущной. Из-за появления допольнительных заголовков размер IP пакета увеличивался и уже не влезал в MTU сети. Например, GRE добавляет 24 байта к пакету, что может привести к IP фрагментации из-за того, что MTU исходящего интерфейса не способно передать пакет целиком.

Что такое туннель?

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

Инкапсуляция трафика при работе туннеля используется, в частности, для связи географически разнесенных сетей (VPN).

Роль маршрутизатора при работе PMTUD на концах туннеля

Маршрутизатор может играть две роли при работе PMTUD на концах туннеля

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

Стоит отметить что ICMP сообщения передаются между двумя адресатами, и не передаются дальше, увеличивая кол-во шагов.

Чистый IPsec в туннельном режиме

IPsec позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов, включая данную информацию в IP пакеты, увеличивая тем самым их размер. Получившийся размер варьируется в зависимости от используемых протоколов.
IPsec может работать в двух режимах:

IPsec также поддерживает механизмы PMTUD и изменения флага DF у своих пакетов.
Пример.

Совместная работа GRE и IPsec

Несколько сложнее дела обстоят, когда IPsec используется для шифрования GRE туннелей. Совместная работа этих технологий необходима, поскольку IPsec не поддерживает IP мультикаст, на котором основываются протоколы динамической маршрутизации, которые могут использоваться в VPN сети. GRE с другой стороны поддерживает мультикаст и может быть использован, для того чтобы сначала инкапсулировать мультикастовый пакет протокола динамической маршрутизации в юникастовый пакет GRE, который затем шифруется IPsec. В данной связке IPsec обычно используется в транспортном режиме, поскольку точки туннеля GRE и пиры IPsec одни и те же, что позволит сохранить 20 байт на излишней IPsec информации.
Может так случиться, что IP пакет разделен на два фрагмента, каждый из которых инкапсулирован GRE. В таком случае IPsec зашифрует каждый из пакетов по отдельности. Получившееся после шифрования пакеты, могут быть слишком большими и потребовать повторной фрагментации. Такая «двойная фрагментация» уменьшает эффективность работы маршрутизаторов и снижает пропускную способность.
Для того, чтобы избежать данной ситуации можно вручную указать MTU виртуального туннельного интерфейса GRE, чтобы нивелировать размер дополнительной информации, добавляемой GRE и IPsec в пакет. Рекомендуемое значение MTU для GRE в таком случае составляет 1400 байт, для ситуаций, когда MTU исходящего интерфейса равно 1500 байтам.
Пример.

Вывод

Суммируя вышенаписанное можно подвести некоторые итоги:

Источник

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

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

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

Максимальный передаваемый блок данных, фрагментация и разгрузка большой отправки

Максимальный передаваемый блок данных

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества и последствия изменения MTU

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

Пример приведен ниже. Размер заголовка Ethernet составляет 14 байт плюс контрольная последовательность кадра из 4 байт для обеспечения согласованности кадров. Если отправляется один 2000-байтовый пакет, в сеть добавляются накладные расходы Ethernet в размере 18 байт. Если пакет разбивается на один 1500-байтовый пакет и один 500-байтовый пакет, каждый пакет будет содержать 18 байт заголовка Ethernet, а всего — 36 байт.

Помните, что увеличение MTU не всегда приводит к повышению эффективности сети. Если приложение отправляет только 500-байтовые пакеты, накладные расходы заголовков будут одинаковыми для MTU размером и 1500 байт, и 9000 байт. Сеть станет более эффективной, только если в ней используются пакеты большего размера, на которые влияет изменение MTU.

Azure и MTU виртуальных машин

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

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

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

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

FragmentSmack — ошибка в повторной сборке ядром Linux фрагментированных пакетов IPv4 и IPv6. Удаленный злоумышленник может использовать этот изъян для активации ресурсоемких операций пересборки фрагментов, что может привести к повышенному потреблению ресурсов ЦП и отказу в обслуживании в целевой системе.

Настройка MTU

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

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

Увеличение MTU не всегда ведет к увеличению производительности и может негативно сказаться на эффективности приложения.

Разгрузка большой отправки

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

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

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

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

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

Заголовок 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 (например, из-за сетевого брандмауэра на маршруте; такая ситуация обычно называется «черной дырой» PMTUD), он не узнает, что размер MSS необходимо уменьшить, и будет повторно передавать этот пакет. Поэтому мы не рекомендуем увеличивать значение MTU виртуальной машины Azure.

VPN и MTU

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

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

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

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

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

В этой таблице показано расстояние по прямой между двумя точками. Расстояние в сетях обычно превышает расстояние по прямой. Ниже приведена простая формула для вычисления минимального 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-подключения снижается, так как отправитель повторно передает уже отправленные данные.

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

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

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

При этом длина заголовка 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) = 262,140 bytes

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

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

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

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

Увеличение размера MTU

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

Мы не рекомендуем клиентам Azure менять значение MTU, установленное по умолчанию на виртуальных машинах.

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

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

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

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

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

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

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

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

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

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

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

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

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

TCP-TIME_WAIT — это еще один стандартный параметр, который влияет на производительность сети и приложений. На загруженных виртуальных машинах, открывающих и закрывающих много сокетов в качестве как клиентов, так и серверов (исходный IP-адрес:исходный порт + конечный IP-адрес:конечный порт), в режиме нормальной работы протокола TCP определенный сокет может надолго оказаться в состоянии TIME_WAIT. Состояние 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»). Для каждой серии существует таблица с характеристиками, в которой спецификации сети указаны в последнем столбце под названием «Максимальное число сетевых адаптеров и ожидаемая пропускная способность сети (Мбит/с)».

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

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

Ускорение сети. Эта функция помогает максимально эффективно использовать заявленный предел, но не изменяет его.

Назначение трафика. При оценке ограничения на исходящий трафик полностью учитываются все назначения.

Протокол. При оценке ограничения на исходящий трафик полностью учитываются все протоколы.

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

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

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

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

Размер MTU/фрагментация. Фрагментация на маршруте может вести к задержкам при получении данных или к неправильному порядку пакетов, что может повлиять на их доставку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Измерение фактической пропускной способности TCP-соединения

NTttcp — это средство для тестирования производительности TCP-соединений виртуальной машины Linux или Windows. Вы можете изменить различные параметры TCP, а затем проверить эффект с помощью NTttcp. Для получения дополнительных сведений см. следующие ресурсы.

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

Вы можете измерять производительность различных типов виртуальных машин, ускорения сети и т. д. с помощью инструмента iPerf. Инструмент iPerf также доступен в Linux и Windows. Для проверки общей пропускной способности сети iPerf может использовать протокол TCP или UDP. На тесты iPerf пропускной способности протокола TCP влияют факторы, описанные в этой статье (например, задержка и RTT). Поэтому, если нужно просто протестировать максимальную пропускную способность, UDP может показать лучшие результаты.

Дополнительные сведения вы найдете в следующих статьях:

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

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

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

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

Дальнейшие действия

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

Источник