Настройка TCP - TCP tuning

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

Сетевые и системные характеристики

Продукт задержки полосы пропускания (BDP)

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

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

Буферы

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

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

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

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

Размер окна

Смотрите также: Параметр масштаба окна TCP и Окно перегрузки

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

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

где RWIN - это окно приема TCP, а RTT - время приема-передачи для пути.

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

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

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

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

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

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

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

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

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

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

Смотрите также

Рекомендации

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

внешняя ссылка