Teplé HTTPS a teplá VPN: porovnejte stejnou cestu požadavku

Pravděpodobně jste četli, že HTTPS otevírá nové TCP spojení a nový TLS handshake pro každý požadavek API, takže tunel, který zůstává otevřený hodinu, vypadá levněji. První polovina toho je obvykle nepravdivá. Podporovaný klient znovu používá navázané spojení pro mnoho výměn a měření, které při každém volání staví nového klienta, měří životní cyklus, nikoli ochranu. Zbytek této stránky popisuje, co měřit místo toho.

Co opětovné použití skutečně vyžaduje

Trvalost je součástí modelu HTTP, nikoli trikem: jedno spojení nese několik výměn požadavku a odpovědi. Spojení končí, když ho jedna strana zavře, když server vyřadí nečinné nebo přetížené spojení, nebo když hlavička či pravidlo protokolu říká, že spojení nelze znovu použít. HTTPS vrství tuto konverzaci uvnitř TLS, aniž by pro každou výměnu vyžadovalo nový handshake. Druhý požadavek tedy neopakuje handshake prvního požadavku, pokud mezitím něco spojení neukončilo.

Opětovné použití má také jednu podmínku, kterou aplikace snadno poruší. Klient, který chce spojení znovu použít, musí přečíst celé tělo odpovědi, a odpověď opuštěná v polovině je obvyklý způsob, jak fond spojení zmizí, aniž by si toho někdo všiml.

Zkontrolujte klienta, kterého knihovna podporuje, a životní cyklus fondu spojení, místo abyste předpokládali, že sdružování je zapnuté nebo vypnuté. Zaznamenejte také vyjednanou verzi HTTP, protože HTTP/2 a HTTP/3 zpracovávají opětovné použití spojení jinak než HTTP/1.1. Berte vyjednanou verzi jako součást měření, ne jako poznámku pod čarou.

Proč srovnání měří životní cyklus

Vytvořit nového klienta pro každou operaci a porovnat ho s tunelem, který je připojen hodinu, znamená porovnávat navázání spojení s ustáleným stavem. To je legitimní měření a není to HTTPS proti VPN. Dva běhy se stejnou konfigurací klienta popisují chování lépe než jeden, zejména když první běh zahřeje překladač nebo mezipaměť spojení.

Držte operaci API, server, účet a data konstantní, jinak porovnání nese více než jednu proměnnou. Předem rozhodněte, kam umístíte časovač, protože navázání, vyjednávání TLS, běh aplikace a doručení odpovědi přispívají k celku různě. Jeden časovač pro první požadavek charakterizuje navázání a neříká nic o ustáleném provozu, který skutečně provozujete. Zapište hranice časovače vedle čísel.

Oddělte studené navázání od teplých požadavků

Měřte první požadavek odděleně od těch následujících. Pak přidejte to, co služba skutečně vidí: období nečinnosti, nárazy, souběžnost, velikost odpovědi a opětovná připojení.

Ponechte ověřování certifikátů a HTTPS zapnuté na obou cestách, protože jejich odebrání měří jiný bezpečnostní návrh, ne rychlejší. Pokud tunel mění trasu nebo umístění brány, nahlaste tento rozdíl zvlášť, místo abyste každou změnu času přisuzovali šifrování, protože trasa, ztráty a fronty mohou u malého požadavku převážit. Před vyvozením závěru spusťte každou cestu dvakrát po stejné trase. Zaznamenejte vyjednaný protokol a hranice časovače u obou běhů.

Počítejte se spojením, které se zavře

Trvalé neznamená věčné. Server, proxy nebo změna sítě mohou během nečinnosti zavřít spojení a klient se musí zotavit chováním, které jeho knihovna podporuje. Toto zotavení má stavový automat: požadavek mohl na serveru dokončit, nebo mohl selhat dřív, než ho server přečetl, a zavřený socket volajícímu neřekne, co se stalo. Neidempotentní operaci na tomto místě nelze jednoduše přehrát, protože přehrání mění neznámý výsledek v duplicitní zápis. Zde se teplý tunel a teplé spojení chovají stejně, protože oba mohou selhat ve chvíli, kdy je práce na cestě.

Použijte dokumentovaný mechanismus opakování nebo idempotence dané služby místo smyčky, která znovu otevírá socket. Zotavení otestujte výslovně: zavřete nečinné spojení a sledujte, co klient udělá dál. Opětovné otevření socketu nedělá opakování volání, které mění stav, bezpečným.

Nejprve zvolte hranici, potom laďte

Zvolte síťovou hranici podle požadavků na přístup a důvěru dřív, než cokoli optimalizujete. VPN chrání segment mezi svými protějšky, zatímco koncové body aplikace a jakýkoli segment v otevřeném textu mimo tunel stále hrají roli. Pak vylaďte životní cyklus spojení uvnitř této hranice. Závěr o levnějším tunelu vyplývá jen z přesvědčení, že každý požadavek opakuje handshake, a právě toto přesvědčení se zde testuje.

Část RFC 9112 o trvalosti je referencí pro to, co opětovné použití skutečně slibuje, včetně podmínek, které spojení ukončí. Přečtěte si ji jednou, než uvěříte měření, které je ignoruje.