Кратко

  • RFC 3135 описал прокси повышения производительности для спутниковых и беспроводных линий: регулирование и фильтрацию ACK, локальные подтверждения и повторы, разделение соединений, сжатие, туннели и сокрытие разрывов.
  • ACK от прокси мог доказать принятие данных промежуточным узлом, но не получение удалённым TCP и не завершение работы приложением. Вместе с коротким циклом управления в сеть перемещалась обязанность восстановления.

Ответ пришёл раньше данных

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

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

Однако байты ещё не у получателя. Они могут лежать в буфере прокси перед спутником, радио, вторым компонентом, удалённым TCP и приложением. Если данные пропадут после локального ACK, исходный отправитель уже получил свидетельство прогресса. Восстановление должен выполнить посредник.

RFC 3135 назвал этот класс Performance Enhancing Proxies, PEP. Документ вышел в июне 2001 года со статусом Informational. Он не задавал один стандартный продукт и не предписывал повсеместное внедрение. Это был обзор методов против задержки, асимметрии полосы, ошибок, узкого канала и временных разрывов — вместе с их архитектурной ценой.

Историческая граница проходила не между быстрым и медленным. Она проходила между тем, кто выдал квитанцию, и тем, от чьего имени её начали читать.

Одно название скрывало разные вмешательства

Транспортный PEP мог анализировать TCP и менять транспортное поведение, сохраняя протокол приложения между концами. Прикладной PEP понимал сообщения верхнего уровня, преобразовывал их или завершал диалог. Интегрированный вариант помещался в одном узле; распределённый ставил компоненты по обе стороны проблемной линии.

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

При разделённом соединении TCP хоста завершался на прокси, а тот открывал новый TCP к назначению. Между двумя PEP мог существовать третий, специально настроенный транспорт, вплоть до закрытого протокола поверх UDP. Несколько пользовательских соединений могли совместно использовать этот канал.

Другие механизмы были мягче. ACK spacing менял интервалы между подтверждениями, не обязательно их автора. ACK filtering экономил обратную полосу. Snoop-подобная функция кэшировала сегменты у беспроводной базы и повторяла потерянные. Сжатие сокращало объём. Поэтому само слово PEP не отвечало на вопрос о сохранённой семантике.

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

Раннее подтверждение передало обязанность ремонта

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

Локальный ACK вставлял ещё одну квитанцию до этого события. RFC 3135 прямо возлагал на PEP обязанность восстановить всё, что будет потеряно после выданного подтверждения. Для этого нужны копия байтов, последовательности, таймеры, наблюдение за нижестоящими ACK и правила повторной передачи.

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

Но обещание требовало доказательства хранения. Был ли буфер энергозависимым? Все ли байты были закреплены до ACK? Что происходило при переполнении или перезапуске? Какое событие подтверждало переход ответственности к удалённому TCP, а затем приложению?

ACK прокси мог быть точным утверждением: «это пришло ко мне». Ошибка возникала, когда метрика превращала его в «это пришло к назначению».

Пять квитанций для одного потока

Сначала отправляющее приложение передаёт байты локальному TCP. Затем PEP принимает, буферизует и, возможно, подтверждает их. Потом данные проходят деградировавший участок. Удалённый TCP сообщает о приёме. Наконец удалённое приложение создаёт значимое событие: разобрало, поставило в очередь, долговременно записало, зафиксировало транзакцию или завершило задачу.

Ни одна ступень не заполняет следующую. Даже прикладной ACK нуждается в определении: «принято» может означать очередь, а не устойчивое хранение.

Пример почтового relay в RFC 3135 показывал явную передачу ответственности. Промежуточный MTA мог записать письмо на энергонезависимый носитель, подтвердить его на прикладном уровне и взять на себя дальнейшие попытки доставки. Это не стопроцентная гарантия финального вручения, зато хранитель и его обязанность видимы.

Транспортный PEP обычно не выдаёт преждевременный ACK приложения; верхний протокол остаётся сквозным. Это важное ограничение. Но первый транспортный ACK всё равно не становится ранней версией прикладной квитанции. Между ними остаются линия, конечный хост и работа приложения.

Состояние посредника стало судьбой соединения

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

PEP с уже подтверждёнными байтами и состоянием разделённого TCP нельзя обойти как обычный маршрутизатор. Его отказ способен завершить сеанс даже при наличии альтернативного IP-пути. Доступность сети сохранилась, но единственная память обещания исчезла.

RFC 3135 не объявлял такой обмен всегда неразумным. Часто прокси обслуживал последний участок без реальной альтернативы. Долгий отказ радио и без того разрушил бы работу. Пользователь мог выбрать дополнительную точку сбоя ради гораздо лучшей повседневной производительности.

Условием был осознанный контроль: знать последствия, выбирать применение и иметь возможность перейти к обычному сквозному IP. Обязательный прозрачный PEP доступа ослаблял это условие. Оператор получал суммарный выигрыш, поставщик управлял буфером и восстановлением, а приложение несло результат потери.

Сквозной IPsec лишал оптимизатор зрения

Для распознавания ACK, последовательностей, окон и опций нужны видимые заголовки TCP. Разделение требует завершить транспорт, обработка приложения — увидеть ещё больше.

ESP между настоящими концами скрывал заголовок и содержимое от промежуточного узла. RFC 3135 отмечал, что многие PEP при этом работают неоптимально или не работают вовсе. Даже ACK spacing, способный сохранить семантику, должен сначала распознать нужные подтверждения.

Можно завершить защиту на прокси и создать вторую ассоциацию к цели. Оба участка будут шифроваться в пути, но данные откроются внутри PEP. Концы должны доверять посреднику. Разный уровень защиты на двух участках способен создать ложное представление о свойствах всей связи.

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

Позднейшие документы сохранили вопрос. RFC 3449 требовал видимых IP/TCP-заголовков и идентификации потоков для ряда асимметричных методов. RFC 8404 и RFC 8517 зафиксировали последующий конфликт шифрования с транспортными функциями сети. RFC 8684 учёл PEP, способные заранее подтверждать данные, в правилах повторов Multipath TCP. Это преемственность проектирования, не статистика развёртывания 2001 года.

Сокрытие разрыва изменяло и диагностику

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

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

Ping и traceroute необязательно наблюдают тот же путь. ICMP может обойти PEP, пройти через него без TCP-обработки или получить ответ самого прокси. Зелёный ping иногда доказывает достижимость лишь промежуточного узла. Traceroute показывает маршрутизаторы, но не место разделения TCP и не содержимое буферов.

Асимметричная маршрутизация могла провести одно направление мимо части распределённой пары. При мобильности состояние нужно быстро передать новому узлу. Масштабирование создавало отдельный предел: обработка выше IP и память на соединение требуют больше ресурсов, чем простая пересылка. Параллельным PEP нужна ещё и привязка потока к правильному состоянию.

Устройство, скрывающее недостаток линии, само нуждалось в независимом доказательстве исправности.

Обзор не был универсальным приговором

RFC 3135 имел статус Informational. Примеры VSAT, беспроводных WAN, WAP и Snoop объясняли мотивы и варианты. Они не были переписью рынка, общим тестом продуктов или доказательством, что любой PEP разрушает безопасность и надёжность.

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

RFC 3234 позже включил PEP в более широкую классификацию middlebox. RFC 3426 использовал RFC 3135 как пример баланса: выигрыш производительности против ограничения сквозного IPsec, новой точки отказа, трудной диагностики, асимметрии и мобильности. Полная оценка обязана учитывать обе стороны.

К производительности нужна цепочка хранения

Испытание должно сначала зафиксировать исходную проблему: направление, топологию, RTT без PEP, ошибки, асимметрию, разрывы, нагрузку и критерий приложения. Затем — владельца, версию, место, механизмы, прозрачность, разделение и возможность обхода.

Для каждой операции отдельно сохраняются отправка, локальный ACK, приём в буфер, его устойчивость, передача вниз, локальный повтор, удалённый TCP ACK, ответ приложения и долговременный итог. Нужны данные о том, кто повторял, какой таймер сработал, что стёр перезапуск, как шли оба направления и чем закончились handover или failover.

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

Повод для расследования — противоречия: ACK раньше надёжного хранения; потеря подтверждённых байтов при restart; успешный ping при остановленном TCP; шифрование молча отключило функцию; обратный путь обошёл состояние; handover его потерял; транспорт улучшился, а приложение ухудшилось.

RFC 3135 сокращал цикл управления, не цепь фактов. Прокси вправе был сказать: «байты у меня». Пока удалённое приложение не создало собственное доказательство, он не мог сказать: «они у него».

Sources

  1. https://www.rfc-editor.org/rfc/rfc3135.txt
  2. https://www.rfc-editor.org/info/rfc3135
  3. https://www.rfc-editor.org/rfc/rfc3135.html
  4. https://www.rfc-editor.org/rfc/rfc793.html
  5. https://www.rfc-editor.org/rfc/rfc1122.html
  6. https://www.rfc-editor.org/rfc/rfc2401.html
  7. https://www.rfc-editor.org/rfc/rfc2488.html
  8. https://www.rfc-editor.org/rfc/rfc2760.html
  9. https://www.rfc-editor.org/rfc/rfc2775.html
  10. https://www.rfc-editor.org/rfc/rfc3234.html
  11. https://www.rfc-editor.org/rfc/rfc3426.html
  12. https://www.rfc-editor.org/rfc/rfc3449.html
  13. https://www.rfc-editor.org/rfc/rfc8404.html
  14. https://www.rfc-editor.org/rfc/rfc8517.html
  15. https://www.rfc-editor.org/rfc/rfc8684.html