Компания F5 Networks в своем решении Big-IP для оптимизации трафика на уровне L4 модели OSI использует ТСР профили. ТСР профиль — набор настроек протокола ТСР которые используются для обработки трафика, передаваемого между клиентом и приложением (виртуальным сервером). В этой статье пойдет речь о возможных сценариях применения различных профилей. 

Анализ использования профилей у пользователей системы Big-IP показывает, что большинство из них используют базовый ТСР-профиль при настройке и конфигурации оборудования. Следствием такой конфигурации, является падение производительности связанное с некорректной настройкой профиля ТСР-оптимизации. В связи с этим best practice, является отказ от стандартного ТСР-профиля.

Особенности стандартного ТСР профиля?

Малый размер буферов. Размер TCP-буфера на отправку и прием данных обычно ограничен 64-мя килобайтами. Буфер прокси-сервера или промежуточного узла в таком случае будет не более 48-ми Кб. Если пропускная способность или задержки подключения превышают буфер отправки\получения, что будет наблюдаться в большинстве современных подключений, ваши приложения будут ограничены не допустимой пропускной способностью сети, а ограничениями памяти.

Размер Congestion Window обычно слишком мал. Использование малого размера буфера в сочетании с высокой сегментацией —  эффективно для линий передач с низким качеством. В современных сетях такой подход является не рациональным и лишь приводит к потере производительности. Ответом на развитие сетей явились рекомендации комиссии Internet Engineering Task Force (IETF RFC см 6928) по увеличению допустимого размера буфера первоначальной отправки в рамках ТСР-сессии. Это позволяет передать больше данных за один сеанс и максимально использовать пропускную способность, и возможности ТСР-протокола.

Отложенные подтверждения (ACK-messages). Базовый профиль использует отложенный АСК, который позволяет снизить количество АСК-ответов с помощью окна ожидания в 200мс. Во время этого окна могут прийти дополнительные элементы данных. В таком случае можно будет отправить одно подтверждение на несколько элементов. Если окно слишком мало – подтверждение будет отправляться после каждого пришедшего элемента, из-за чего по сети будет передано много избыточной информации. В современных сетях 200 мс это слишком маленькое окно для ожидания дополнительных данных и рекомендуется его увеличить в зависимости от характера передаваемых по сети данных.

Варианты решения

Оптимальным выходом можно считать построение пользовательского профиля на основе вашей среды и требований к качеству доставки данных. Для тех случаев, в которых эта задача является сложной или невыполнимой, созданы профили, оптимизированные под различные задачи.
Если у вас есть НТТР-профиль прикрепленный к виртуальному серверу, рекомендуется использовать tcp-mobile-optimized-профиль. это рекомендуется даже если ваши клиенты не мобильные пользователи. Название вводит в заблуждение, однако конфигурация этого ТСР-профиля действительно оптимизирует использование ваших каналов связи даже, для «не мобильных» пользователей.
В случае если вы уже используете возможности tcp-mobile-optimized профиля и вам необходима дальнейшая оптимизация НТТР-трафика (и соответственно НТТР профиля) возможна с помощью mptcp-mobile-optimized-профиля. Кроме того, Multipath TCP (MPTCP) для клиентов, которые его запрашивают, использует расширенный контроль перегрузки ("Illinois"). Однако, если вы все еще используете базовый ТСР-профиль, наверное, вам пока что не известно о инновациях в ТСР-протоколе. В таком случае, использование tcp-mobile-optimized-профиля может быть мягким шагом вперед.
Если вы не используете НТТР-профили – лучшим решением будет использование модифицированной версии tcp-mobile-optimized или mptcp-mobile-optimized. Чтобы модифицировать профиль просто создайте новый профиль, а в качестве базового выберите один из вышеуказанных и отключите алгоритм Nagle. Если этот вариант не приемлем, в таком случае вы можете использовать wam-tcp-lan-optimized профиль. И на самом деле, не столь важно подключенная сеть LAN или WAN.

Почему был создан базовый профиль с такими настройками по умолчанию?

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

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