TCP-настройка

Методы настройки TCP настраивают предотвращения перегрузки сети соединений параметры протокола управления передачей (TCP) в сетях с высокой пропускной способностью и большой задержкой . Хорошо настроенные сети в некоторых случаях могут работать до 10 раз быстрее. ^[1] Однако слепое следование инструкциям без понимания их реальных последствий также может ухудшить производительность.

Характеристики сети и системы

Произведение пропускной способности и задержки (BDP)

Произведение полосы пропускания-задержки (BDP) — это термин, который в основном используется в сочетании с TCP для обозначения количества байтов, необходимых для заполнения «пути» TCP, т. е. оно равно максимальному количеству одновременных битов, передаваемых между передатчиком и приемник.

Высокопроизводительные сети имеют очень большие значения BDP. В качестве практического примера можно сказать, что два узла, обменивающиеся данными по геостационарной спутниковой линии со временем задержки туда и обратно (или временем туда и обратно, RTT) 0,5 секунды и пропускной способностью 10 Гбит/с , могут иметь скорость до 0,5×10 Гбит . т. е. 5 Гбит неподтвержденных данных в процессе передачи. Несмотря на гораздо меньшие задержки, чем у спутниковых каналов, даже наземные оптоволоконные каналы могут иметь очень высокие значения BDP, поскольку их пропускная способность очень велика. Операционные системы и протоколы, разработанные всего несколько лет назад, когда сети были медленнее, были настроены на на порядок меньшие значения BDP, что приводило к ограничению достижимой производительности.

Буферы

Исходные конфигурации TCP поддерживали приема TCP размером буферы до 65 535 (64 КиБ - 1) байт, что было достаточно для медленных каналов или каналов с небольшими значениями RTT. Для опций высокой производительности, описанных ниже, требуются буферы большего размера.

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

Ограничения скорости TCP

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

Размер окна

В компьютерных сетях RWIN ( окно приема TCP) — это объем данных, который компьютер может принять без подтверждения отправителя. Если отправитель не получил подтверждения для первого отправленного им пакета , он остановится и будет ждать, а если это ожидание превысит определенный предел, он может даже повторить передачу . Именно так TCP обеспечивает надежную передачу данных .

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

$\mathrm {Throughput} \leq {\frac {\mathrm {RWIN} }{\mathrm {RTT} }}\,\!$

где RWIN — это окно приема TCP, а RTT — время прохождения туда и обратно для пути.

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

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

Потеря пакетов

Когда в сети происходит потеря пакетов , на соединение накладывается дополнительный лимит. ^[2] В случае легкой и умеренной потери пакетов, когда скорость TCP ограничена алгоритмом предотвращения перегрузки , предел можно рассчитать по формуле (Матис и др.):

$\mathrm {Throughput} \leq {\frac {\mathrm {MSS} }{\mathrm {RTT} {\sqrt {P_{\mathrm {loss} }}}}}$

где MSS — максимальный размер сегмента, а P _loss — вероятность потери пакета. Если потеря пакетов настолько редка, что окно TCP регулярно полностью расширяется, эта формула неприменима.

Опции TCP для высокой производительности

За прошедшие годы в TCP был внесен ряд расширений для повышения его производительности на быстрых каналах с высоким RTT («длинные толстые сети» или LFN).

TCP Временные метки (RFC 1323) играют двойную роль: они позволяют избежать двусмысленности из-за переноса 32-битного поля порядкового номера и позволяют более точно оценить RTT при наличии нескольких потерь на каждый RTT. Благодаря этим улучшениям становится разумным увеличить размер окна TCP за пределы 64 КБ, что можно сделать с помощью опции масштабирования окна (RFC 1323).

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

Path MTU Discovery позволяет избежать фрагментации внутри сети , повышая производительность при потере пакетов.

Настройка медленных соединений

Длина IP-очереди по умолчанию равна 1000, что обычно слишком велико. Представьте себе базовую станцию Wi-Fi со скоростью 20 Мбит/с и средним размером пакета 750 байт. Насколько большой должна быть IP-очередь? Клиент передачи голоса по IP должен иметь возможность передавать пакет каждые 20 мс. Тогда расчетное максимальное количество пакетов в пути составит:

Estimated buffer size = 20000000 * 0,020 / 8 / 750 = 66

Лучшая длина очереди:

ifconfig wlan0 mtu 1492 txqueuelen 100

См. также

Ссылки

^ «Высокопроизводительный SSH/SCP — HPN-SSH» . Psc.edu . Проверено 23 января 2020 г.
^ «Макроскопическое поведение алгоритма предотвращения перегрузки TCP» . Psc.edu . Архивировано из оригинала 11 мая 2012 года . Проверено 3 января 2017 г.

Внешние ссылки

RFC 1323 — Расширения TCP для повышения производительности
RFC 2018 — варианты выборочного подтверждения TCP
RFC 2582 — модификация NewReno алгоритма быстрого восстановления TCP
RFC 2488 — Улучшение TCP по спутниковым каналам с использованием стандартных механизмов
RFC 2883 — расширение опции выборочного подтверждения (SACK) для TCP
RFC 3517 - Консервативный избирательный алгоритм восстановления потерь на основе подтверждений для TCP
RFC 4138 - Прямое восстановление RTO (F-RTO): алгоритм обнаружения ложных тайм-аутов повторной передачи с помощью TCP и протокола передачи управления потоком (SCTP)
Руководство по настройке TCP , ESnet
Кабельщик: автоматическая настройка окна приема TCP
Тестирование пропускной способности данных Web100
DrTCP — утилита для Microsoft Windows (до Vista ), которая позволяет быстро изменять параметры производительности TCP в реестре.
Информация о настройке вашего стека TCP , Отчеты о широкополосном доступе
Анализатор TCP/IP , Speedguide.net
Инструмент тестирования производительности сети NTTTCP , блог группы производительности Microsoft Windows Server
Лучшие практики оптимизации TCP — ExtraHop
Руководство по настройке TCP Питтсбургского суперкомпьютерного центра , - PSC

[1] «Высокопроизводительный SSH/SCP — HPN-SSH» . Psc.edu . Проверено 23 января 2020 г.

[2] «Макроскопическое поведение алгоритма предотвращения перегрузки TCP» . Psc.edu . Архивировано из оригинала 11 мая 2012 года . Проверено 3 января 2017 г.

[1]

[2]