Теплий 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 про стійкість — це джерело про те, що повторне використання справді обіцяє, включно з умовами, які завершують з'єднання. Прочитайте його один раз, перш ніж довіряти вимірюванню, яке їх ігнорує.