Топъл 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 е препратката за това, което повторното използване наистина обещава, включително условията, които прекратяват връзка. Прочетете го веднъж, преди да се доверите на измерване, което ги игнорира.