Lämmin HTTPS ja lämmin VPN: vertaa samaa pyyntöpolkua

Olet luultavasti lukenut, että HTTPS avaa uuden TCP-yhteyden ja tuoreen TLS-kättelyn jokaista API-pyyntöä varten, joten tunnin ajan pystyssä pysyvä tunneli näyttää halvemmalta. Sen ensimmäinen puolisko on yleensä väärin. Tuettu asiakasohjelma käyttää uudelleen jo muodostettua yhteyttä moneen vaihtoon, ja mittaus, joka rakentaa uuden asiakkaan jokaista kutsua varten, mittaa elinkaarta eikä suojaa. Tämän sivun loppuosa kertoo, mitä sen sijaan kannattaa mitata.

Mitä uudelleenkäyttö todella vaatii

Pysyvyys on osa HTTP-mallia, ei temppu: yksi yhteys kuljettaa useita pyyntö-vastaus-vaihtoja. Yhteys päättyy, kun jompikumpi osapuoli sulkee sen, kun palvelin poistaa käytöstä joutilaan tai ylikuormitetun yhteyden, tai kun otsake tai protokollasääntö kertoo, ettei yhteyttä voi käyttää uudelleen. HTTPS upottaa tuon keskustelun TLS:n sisään vaatimatta uutta kättelyä jokaista vaihtoa varten. Niinpä toinen pyyntö ei toista ensimmäisen pyynnön kättelyä, ellei jokin ole päättänyt yhteyttä välissä.

Uudelleenkäytöllä on myös yksi ehto, jonka sovellukset rikkovat helposti. Asiakasohjelman, joka aikoo käyttää yhteyttä uudelleen, on luettava vastauksen koko runko, ja puoliksi hylätty vastaus on tavallinen tapa, jolla yhteysallas katoaa kenenkään huomaamatta.

Tarkista kirjaston tukema asiakasohjelma ja yhteysaltaan elinkaari sen sijaan, että olettaisit altaan olevan päällä tai pois. Kirjaa myös neuvoteltu HTTP-versio, koska HTTP/2 ja HTTP/3 käsittelevät yhteyksien uudelleenkäyttöä eri tavalla kuin HTTP/1.1. Käsittele neuvoteltua versiota osana mittausta, älä alaviitteenä.

Miksi vertailu mittaa elinkaarta

Uuden asiakasohjelman luominen jokaista toimintoa varten ja sen vertaaminen tuntiin yhteydessä olleeseen tunneliin vertaa yhteyden muodostusta tasaiseen tilaan. Se on pätevä mittaus, eikä se ole HTTPS vastaan VPN. Kaksi ajoa samalla asiakasohjelman kokoonpanolla kuvaa käyttäytymistä paremmin kuin yksi, etenkin kun ensimmäinen ajo lämmittää nimipalvelimen tai yhteysvälimuistin.

Pidä API-toiminto, palvelin, tili ja data vakiona, tai vertailu kuljettaa useampaa kuin yhtä muuttujaa. Päätä etukäteen, mihin ajastimen asetat, koska yhteysmuodostus, TLS-neuvottelu, sovelluksen suoritus ja vastauksen toimitus vaikuttavat kokonaisuuteen eri tavoin. Yksi ensimmäisen pyynnön ajastin luonnehtii yhteyden muodostusta eikä kerro mitään siitä tasaisesta liikenteestä, jota todella ajat. Kirjoita ajastimen rajat numeroiden viereen.

Erota kylmä muodostus lämpimistä pyynnöistä

Mittaa ensimmäinen pyyntö erikseen sitä seuraavista. Lisää sitten se, mitä palvelu todella näkee: joutilaat jaksot, purskeet, rinnakkaisuus, vastauksen koko ja uudelleenyhdistämiset.

Pidä varmenteen vahvistus ja HTTPS käytössä molemmilla poluilla, sillä niiden poistaminen mittaa erilaista turvasuunnittelua kuin nopeampaa. Jos tunneli muuttaa reittiä tai yhdyskäytävän sijaintia, raportoi se ero erikseen sen sijaan, että kohdistaisit jokaisen ajoitusmuutoksen salaukseen, koska polku, häviö ja jonotus voivat hallita pientä pyyntöä. Aja kumpikin polku kahdesti samaa reittiä pitkin ennen johtopäätöstä. Kirjaa neuvoteltu protokolla ja ajastimen rajat molempien ajojen yhteyteen.

Varaudu yhteyteen, joka sulkeutuu

Pysyvä ei tarkoita ikuista. Palvelin, välityspalvelin tai verkon muutos voi sulkea yhteyden joutilaana jaksona, ja asiakasohjelman on palauduttava kirjastonsa tukemalla käyttäytymisellä. Palautumisella on tilakone: pyyntö on voinut valmistua palvelimella tai epäonnistua ennen kuin palvelin luki sen, eikä suljettu pistoke kerro kutsujalle, kumpi tapahtui. Ei-idempotenttia toimintoa ei voi siinä asemassa yksinkertaisesti toistaa, koska toisto muuttaa tuntemattoman tuloksen kahdennetuksi kirjoitukseksi. Tässä lämmin tunneli ja lämmin yhteys käyttäytyvät samoin, koska molemmat voivat epäonnistua hetkellä, jolloin työ on käynnissä.

Käytä palvelun dokumentoitua uudelleenyritys- tai idempotenssimekanismia sen sijaan, että silmukka avaisi pistokkeen uudelleen. Testaa palautuminen nimenomaisesti sulkemalla joutilas yhteys ja seuraamalla, mitä asiakasohjelma tekee seuraavaksi. Pistokkeen uudelleen avaaminen ei tee tilaa muuttavan kutsun toistosta turvallista.

Valitse raja ensin, viritä sitten

Valitse verkkoraja käyttö- ja luottamusvaatimusten perusteella ennen kuin optimoit mitään. VPN suojaa vertaistensa välisen segmentin, kun taas sovelluksen päätepisteet ja mikä tahansa selkokielinen segmentti tunnelin ulkopuolella ovat edelleen merkityksellisiä. Säädä sitten yhteyden elinkaari tuon rajan sisällä. Johtopäätös halvemmasta tunnelista seuraa vain uskosta, että jokainen pyyntö toistaa kättelyn, ja juuri sitä uskoa tässä testataan.

RFC 9112:n pysyvyyttä käsittelevä osa on viite siitä, mitä uudelleenkäyttö todella lupaa, mukaan lukien yhteyden päättävät ehdot. Lue se kerran ennen kuin luotat mittaukseen, joka jättää ne huomiotta.