Тёплый HTTPS и тёплый VPN: сравните один и тот же путь запроса

Вы, вероятно, читали, что HTTPS открывает новое TCP-соединение и новое рукопожатие TLS для каждого запроса API, поэтому туннель, который остаётся открытым час, выглядит дешевле. Первая половина этого утверждения обычно неверна. Поддерживаемый клиент повторно использует установленное соединение для многих обменов, а измерение, которое создаёт нового клиента при каждом вызове, измеряет жизненный цикл, а не защиту. Остальная часть этой страницы рассказывает, что вместо этого измерять.

Что на самом деле требует повторное использование

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

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

Проверьте поддерживаемого клиента библиотеки и жизненный цикл пула соединений, вместо того чтобы предполагать, что пулирование включено или выключено. Запишите и согласованную версию HTTP, потому что HTTP/2 и HTTP/3 обрабатывают повторное использование соединений иначе, чем HTTP/1.1. Считайте согласованную версию частью измерения, а не сноской.

Почему сравнение измеряет жизненный цикл

Создание нового клиента для каждой операции и сравнение его с туннелем, подключённым уже час, сравнивает установку соединения с установившимся режимом. Это законное измерение, и это не HTTPS против VPN. Два прогона с одной и той же конфигурацией клиента описывают поведение лучше одного, особенно когда первый прогон прогревает резолвер или кеш соединений.

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

Отделите холодную установку от тёплых запросов

Измеряйте первый запрос отдельно от последующих. Затем добавьте то, что служба действительно видит: периоды простоя, всплески, параллельность, размер ответа и переподключения.

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

Планируйте соединение, которое закрывается

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

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

Сначала выберите границу, потом настраивайте

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

Раздел RFC 9112 об устойчивости — это источник о том, что повторное использование действительно обещает, включая условия, которые завершают соединение. Прочитайте его один раз, прежде чем доверять измерению, которое их игнорирует.