Инженерия Webship

Окончание TLS или прямая передача? Выбор правильной границы обратного прокси Webship

Завершение TLS открывает маршрутизацию, кэширование и проверку безопасности HTTP; проброс (pass-through) сохраняет открытый текст и ключи сессии на исходном сервере. В этом руководстве объясняются компромиссы, измеренная производительность и настройка Webship в реальном времени.

Опубликовано 10 сентября 2026 г.

Выбор между завершением TLS и прохождением TLS не является косметической настройкой прокси. Он определяет, где заканчивается шифрование, какая система хранит ключи сеанса, может ли Webship проверять HTTP и какой уровень должен обеспечивать безопасность приложений.

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

Решение в одном предложении

Используйте TLS pass-through, когда источник должен владеть границей TLS. Используйте TLS termination, когда Webship должен маршрутизировать, защищать, преобразовывать, кэшировать или наблюдать HTTP-трафик.

Ни один из режимов не является универсально более безопасным. Режим прохождения уменьшает количество конфиденциального материала, обрабатываемого на границе, но убирает средства контроля безопасности HTTP на границе. Режим завершения добавляет проверяемую точку принуждения, но делает Webship частью доверенной границы TLS.

| Проблема | Завершение TLS | Проброс TLS | | --- | --- | --- | | TLS-конечная точка | Webship | Источник | | Приложение plaintext на Webship | Да | Нет | | Активные ключи сеанса downstream на Webship | Да | Нет | | Маршрут по HTTP-пути или методу | Да | Нет | | WAF, API Shield и ограничения на тело в Webship | Да | Нет | | Прокси-кэш, перезапись и пересылка заголовков | Да | Нет | | Входящий TCP-маршрут | Политика маршрута и авторитет HTTP | ClientHello SNI | | Маршрутизация HTTP/3 | Данные HTTP-запроса | Один общий UDP-источник | | Ответственность источника | HTTP или отдельно настроенный upstream TLS | Полный стек TLS, ALPN и HTTP |

Следовательно, важный вопрос состоит не в том, «какой переключатель быстрее?», а в том, «какой компонент должен иметь возможность видеть и контролировать запрос?»

Какое завершение предоставляет Webship

С tls_termination = true Webship завершает downstream TLS и передает расшифрованный запрос в свой конвейер HTTP реверс-прокси. Это делает возможными следующие функции:

маршрутизация с учетом пути, хоста и метода;
Инспекция WAF и API Shield;
лимиты тела запроса и тайм-ауты политики;
кэширование через прокси и безопасное для генерации инвалидирование;
управление заголовками пересылки и поля журнала доступа HTTP;
обработка запросов с учётом состояния тела, повторные попытки там, где это безопасно, и политика прерывания цепи;
протокольный перевод между клиентскими и вышестоящими соединениями.

Этот режим также изменяет ответственность за безопасность. Хост Webship должен защищать приватный ключ сертификата, ключи сессии, расшифрованные данные запросов и ответов, данные наблюдаемости и любые кэшированные представления. Если следующий узел должен оставаться зашифрованным, настройте типизированный TLS для вышестоящего узла отдельно; в противном случае HTTP-вышестоящий узел будет в открытом виде.

Завершение — это правая граница, когда ожидается, что Webship будет работать как периферийное устройство с поддержкой приложений, а не только как зашифрованный транспортный ретранслятор.

Что сохраняет проход

С tls_termination = false — по умолчанию — Webship передает зашифрованный трафик TLS или QUIC без расшифровки HTTP-запроса или ответа. Открытый текст приложения и активные ключи сессии остаются на исходном сервере.

Эта меньшая граница доверия ценна, когда сертификаты должны оставаться на уровне приложения, политика соответствия запрещает дешифрование на краю сети или когда идентичность TLS, специфичная для источника, должна достигать клиента без изменений. Она также устраняет обработку HTTP и работу с политиками из пути ретрансляции.

Компромисс строгий: Webship не может проверять то, что не может расшифровать. Он не может применять правила HTTP WAF, маршрутизировать по пути, изменять заголовки, обеспечивать политику API с учетом содержимого тела или заполнять журналы доступа к HTTP-полям. Источник должен обеспечивать все эти контрольные меры самостоятельно.

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

Ограничения, специфичные для протокола, имеют значение

Для HTTP/1.1 TLS и HTTP/2 TLS Webship проверяет ClientHello только настолько, чтобы выбрать настроенный TCP-адрес назначения по SNI. Каждому домену с прямой передачей нужен универсальный маршрут path_prefix = "/", потому что фактический путь запроса остаётся зашифрованным. Клиент без SNI принимается только тогда, когда в конфигурации указан один домен.

Источник должен согласовывать ALPN клиента и поддерживать выбранный протокол. Webship не может преобразовать клиента HTTP/2 в источник HTTP/1.1, пока сеанс TLS проходит без изменений.

HTTP/3 использует QUIC поверх UDP и имеет более узкую границу. Прямое прохождение не может безопасно маршрутизировать по зашифрованной HTTP-авторности, поэтому каждый настроенный маршрут HTTP/3 должен разрешаться в один и тот же IP-сокет UDP. Webship отклоняет Unix-сокеты и несколько источников прямого прохождения HTTP/3 во время проверки конфигурации, а не маршрутизирует их неоднозначно без уведомления.

Обычный текст HTTP/1.1 и h2c не затрагиваются reverse_proxy.tls_termination. Этот параметр управляет только TLS для HTTP/1.1, TLS для HTTP/2 и TLS для HTTP/3 на стороне клиента.

Измеренная пропускная способность запроса

Тест производительности Webship 1.3.1 на Debian измерял две зашифрованные режимы обратного прокси отдельно. Каждый принятый образец не требовал ошибок HTTP, сокетов, протоколов, прокси, серьезных сбоев страниц и потерь пакетов HTTP/3.

| Режим обратного прокси | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Завершение TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS pass-through | 203,950 запросов в секунду | 266,845 запросов в секунду | 167,010 запросов в секунду |

Пропускная передача с малым откликом требует меньше работы от приложения: она передаёт зашифрованные транспортные данные вместо того, чтобы завершать TLS, разбирать HTTP, оценивать политику и создавать новый поток TLS вниз по цепочке. Более высокие скорости запросов при пропускной передаче отражают эту более узкую задачу.

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

Потоковая передача больших объёмов изменяет результат

Тот же эталон использовал точное тело ответа размером 99 943 778 байт для потоковой матрицы размером 100 МБ. Здесь завершение TLS обеспечило более высокую медианную пропускную способность полезной нагрузки для всех трех протоколов:

| Режим обратного прокси | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Завершение TLS | 3,585.7 МиБ/с | 3,355.0 МиБ/с | 1,938.6 МиБ/с | | TLS сквозная передача | 2,783.2 МиБ/с | 2,135.0 МиБ/с | 1,748.5 МиБ/с |

Почему меняется направление? В режиме завершения исходная точка бенчмарка отправляет незашифрованный HTTP на Webship, и Webship управляет оптимизированным нисходящим массовым каналом. Большие ответы HTTP/1.1 и HTTP/2 могут использовать адаптивный Linux kTLS и ограниченное транспортно-специфическое буферизование. HTTP/3 использует управление скоростью QUIC, DPLPMTUD и пакетирование на основе реактора вместо kTLS.

В режиме прямой передачи исходный сервер управляет TLS ниже по потоку, а Webship передаёт полученный зашифрованный поток или пакеты QUIC. Это сохраняет границу TLS исходного сервера, но не позволяет использовать путь массового ответа Webship с поддержкой HTTP.

Квалификация HTTP/3 с семью образцами также проверяла стабильность. Прекращенная передача потоков достигла медианы 1 938,6 МиБ/с с коэффициентом вариации 2,12%; передача через проход достигла 1 748,5 МиБ/с с коэффициентом вариации 1,65%. Обе обеспечили точную передачу тела без ошибок клиента, протокола и потери пакетов.

Настройте прямую передачу намеренно

Минимальная конфигурация пропускного режима сохраняет идентификатор TLS в подготовленном виде, чтобы оператор мог включить завершение позже, не изменяя пути к сертификатам:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Сценический сертификат Webship проверен, но не используется активными сессиями прямой передачи. Источник на 10.0.0.20:443 должен завершать TLS и поддерживать протокол, согласованный с клиентом.

Включить завершение, когда на границе требуется HTTP

Для периметра, осведомленного о приложении, включите завершение и отправьте полученный HTTP-трафик на выбранный источник:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Эта конфигурация может маршрутизировать и проверять HTTP. Добавьте TLS на стороне источника, если сеть между Webship и источником уже не является доверенной или изолированной.

Переключать режимы без перезапуска Webship

Webship может изменить tls_termination через перезагрузку файла конфигурации или через инструмент MCP webship.reverse_proxy.apply_config, проверяющий версии. Прочитайте текущий объект и версию с помощью webship.reverse_proxy.get_config, измените только нужное поле в полном возвращённом объекте и отправьте его с соответствующим expected_version_id.

Новые TCP-соединения используют новый режим. Клиенты HTTP/3 переподключаются к замененному UDP-транспорту. Изменения пути к сертификату и ключу остаются привязанными к процессу и требуют перезапуска, поэтому заранее подготовьте действующую идентификацию завершения перед переходом в рабочем режиме.

Проверка версии предотвращает перезапись одного оператора при одновременном изменении конфигурации. Отклоненное обновление оставляет активную рабочую конфигурацию и сохраненную конфигурацию без изменений.

Практический контрольный список для выбора

Выберите режим прохода, когда все эти условия выполняются:

Происхождение должно сохранять границу сертификата и ключи сессии.
Маршрутизация TCP на уровне SNI — или один общий HTTP/3 UDP-источник — достаточна.
Источник обеспечивает необходимый WAF, авторизацию, ведение журналов, ограничения на тело и контроль злоупотреблений.
Не требуется кэширование на границе, переписывание пути, политика пересылки заголовков или преобразование протокола HTTP.

Выберите завершение, когда требуется любое из этих действий на Webship:

Маршрут по хосту, пути или методу.
Проверяйте запросы с помощью WAF или API Shield.
Применяйте ограничения на размер тела, таймауты HTTP или аутентификацию на границе.
Кэшировать ответы или переписывать HTTP-заголовки.
Перевод между нисходящими и восходящими HTTP-протоколами.
Наблюдайте за HTTP-полями на границе прокси.

Какой бы режим вы ни выбрали, протестируйте SNI, ALPN, идентичность сертификата, отмену клиентом, полузакрытие на стороне сервера и точную целостность ответа. Измеряйте пропускную способность запросов и потоковую передачу отдельно: самый быстрый режим для небольшого ответа не обязательно будет самым быстрым режимом для тела размером 100 МБ.

Webship устанавливает режим прохождения по умолчанию, потому что прокси не должен бесшумно расширять свою зону доверия. Завершение соединения остаётся активным, явным операционным выбором, когда поведение на границе, осознающее HTTP, стоит этой ответственности.

Прочитайте полную [документацию по обратному прокси](/docs/1.3.1), сравните с принятой [матрицей бенчмарков](/benchmarks) или скачайте Webship с [страницы загрузок](/downloads).

Источники и метод содержания

Значения производительности приняты как медианы из унифицированного бенчмарка Webship 1.3.1 для Debian по дате 11 сентября 2026 года; его критерии приёма требуют нулевого количества ошибок клиента, HTTP, сокета, протокола, прокси, ошибок крупной страничной ошибки и потерь пакетов HTTP/3.