Введение

Прокси-серверы для повышения производительности (PEP) - это сетевые агенты, предназначенные для улучшения производительности некоторых протоколов связи. Стандарты PEP определены в RFC 3135 (PEP, предназначенных для смягчения связанных с связью деградаций) и RFC 3449 (последствия асимметрии маршрутов сети для производительности TCP).

Классификация

В имеющихся реализациях PEP используются различные методы для повышения производительности. Тип прокси: PEP может "разделять" соединение или "внедряться" в него. В первом случае прокси-сервер притворяется противоположной конечной точкой соединения в каждом направлении, буквально разделяя соединение на две части. В последнем случае прокси-сервер контролирует передачу сегментов TCP в обоих направлениях, используя фильтрацию и реконструкцию в существующем соединении (см. протокольный подделку). Это основано на уровне ОСИ внедрения ПЭП. Распределение: ПЭП могут быть интегрированы или распределены. Интегрированный PEP будет работать на одной коробке, в то время как распределенный PEP потребует установки по обе стороны связи, что вызывает ухудшение производительности. Это довольно распространено в коммерческих устройствах PEP, которые действуют как черный ящик, используя более или менее открытые протоколы для связи между ними вместо TCP. Симметрия: реализация ПЭП может быть симметричной или асимметричной. Симметричные PEP используют идентичное поведение в обоих направлениях; действия, предпринятые PEP, происходят независимо от того, с какого интерфейса получается пакет. Асимметричные ПЭП работают по-разному в каждом направлении, что может привести, например, к повышению производительности только одного направления связи.

Разделение TCP

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

Фильтрация/децимация

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

Снуп

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

D-Proxy

D Proxy также предназначен для скрытия потерь пакетов, вызванных помехами или столкновениями, по беспроводной линии связи. D-прокси - это новый распределенный прокси TCP, требующий прокси с обеих сторон потерянной ссылки. Как и Snoop, он использует последовательность номеров TCP для обнаружения потерянных пакетов. Однако он имеет проактивный подход, контролируя последовательность номеров TCP на пакетах данных, а не на подтверждениях. При потере пакета поток TCP будет временно буферизирован до тех пор, пока не будет восстановлен и перепорядочен недостающий пакет.