Silts HTTPS pret siltu VPN: salīdziniet to pašu pieprasījuma ceļu

Jūs, iespējams, esat lasījis, ka HTTPS atver jaunu TCP savienojumu un jaunu TLS rokasspiedienu katram API pieprasījumam, tāpēc tunelis, kas paliek atvērts stundu, šķiet lētāks. Pirmā daļa no tā parasti ir nepatiesa. Atbalstīts klients atkalizmanto jau izveidotu savienojumu daudzām apmaiņām, un mērījums, kas katram izsaukumam būvē jaunu klientu, mēra dzīves ciklu, nevis aizsardzību. Pārējā šīs lapas daļa stāsta, ko tā vietā mērīt.

Ko atkalizmantošana patiešām prasa

Noturība ir HTTP modeļa daļa, nevis triks: viens savienojums pārvadā vairākas pieprasījuma un atbildes apmaiņas. Savienojums beidzas, kad to aizver kāda no pusēm, kad serveris atsakās no dīkstāves vai pārslogota savienojuma, vai kad galvene vai protokola noteikums saka, ka savienojumu nevar izmantot atkārtoti. HTTPS ievieto šo sarunu TLS iekšpusē, nepieprasot jaunu rokasspiedienu katrai apmaiņai. Tāpēc otrs pieprasījums neatkārto pirmā pieprasījuma rokasspiedienu, ja vien kaut kas starplaikā nav beidzis savienojumu.

Atkalizmantošanai ir arī viens nosacījums, ko lietojumprogrammas viegli pārkāpj. Klientam, kas plāno atkalizmantot savienojumu, ir jāizlasa viss atbildes pamatteksts, un pusceļā pamesta atbilde ir ierastais veids, kā savienojumu kopums pazūd nevienam nepamanot.

Pārbaudiet bibliotēkas atbalstīto klientu un savienojumu kopuma dzīves ciklu, nevis pieņemiet, ka kopīgošana ir ieslēgta vai izslēgta. Pierakstiet arī saskaņoto HTTP versiju, jo HTTP/2 un HTTP/3 savienojumu atkalizmantošanu apstrādā citādi nekā HTTP/1.1. Uztveriet saskaņoto versiju kā mērījuma daļu, nevis kā zemsvītras piezīmi.

Kāpēc salīdzinājums mēra dzīves ciklu

Jauna klienta izveide katrai darbībai un tā salīdzināšana ar tuneli, kas jau stundu ir savienots, salīdzina savienojuma izveidi ar pastāvīgu stāvokli. Tas ir likumīgs mērījums, un tas nav HTTPS pret VPN. Divi palaidieni ar to pašu klienta konfigurāciju raksturo uzvedību labāk nekā viens, jo īpaši tad, kad pirmais palaidiens iesilda risinātāju vai savienojumu kešatmiņu.

Turiet API darbību, serveri, kontu un datus nemainīgus, citādi salīdzinājums nes vairāk nekā vienu mainīgo. Iepriekš izlemiet, kur novietosiet taimeri, jo iestatīšana, TLS sarunas, lietojumprogrammas izpilde un atbildes piegāde kopējam iegulda atšķirīgi. Viens pirmā pieprasījuma taimeris raksturo iestatīšanu un neko nepasaka par pastāvīgo satiksmi, ko jūs faktiski vadāt. Pierakstiet taimera robežas blakus skaitļiem.

Atdaliet aukstu iestatīšanu no siltiem pieprasījumiem

Mēriet pirmo pieprasījumu atsevišķi no tiem, kas seko. Pēc tam pievienojiet to, ko serviss patiešām redz: dīkstāves periodus, uzliesmojumus, vienlaicību, atbildes lielumu un atkārtotus savienojumus.

Atstājiet sertifikātu validāciju un HTTPS ieslēgtus abos ceļos, jo to noņemšana mēra citu drošības dizainu, nevis ātrāku. Ja tunelis maina maršrutu vai vārtejas atrašanās vietu, ziņojiet par šo atšķirību atsevišķi, nevis piedēvējiet katru laika izmaiņu šifrēšanai, jo ceļš, zudumi un rinda var pārsvert nelielu pieprasījumu. Pirms secinājuma izdarīšanas palaidiet katru ceļu divreiz pa to pašu maršrutu. Pierakstiet saskaņoto protokolu un taimera robežas ar abiem palaidieniem.

Rēķinieties ar savienojumu, kas aizveras

Noturīgs nenozīmē mūžīgs. Serveris, starpniekserveris vai tīkla izmaiņas var aizvērt savienojumu dīkstāves periodā, un klientam ir jāatjaunojas ar savas bibliotēkas atbalstīto uzvedību. Šai atjaunošanai ir stāvokļu mašīna: pieprasījums var būt pabeigts serverī vai neizdevies pirms serveris to izlasīja, un aizvērta ligzda nepasaka izsaucējam, kas notika. Neidempotenta darbība šajā vietā nevar vienkārši tikt atkārtota, jo atkārtošana nezināmu iznākumu pārvērš dubultā ierakstā. Šeit silts tunelis un silts savienojums uzvedas vienādi, jo abi var neizdoties brīdī, kad darbs ir ceļā.

Izmantojiet servisa dokumentēto atkārtošanas vai idempotences mehānismu, nevis cilpu, kas no jauna atver ligzdu. Pārbaudiet atjaunošanos tieši: aizveriet dīkstāves savienojumu un vērojiet, ko klients dara tālāk. Ligzdas atvēršana no jauna nepadara stāvokli mainoša izsaukuma atkārtošanu drošu.

Vispirms izvēlieties robežu, pēc tam regulējiet

Izvēlieties tīkla robežu pēc piekļuves un uzticēšanās prasībām, pirms kaut ko optimizējat. VPN aizsargā segmentu starp saviem vienaudžiem, savukārt lietojumprogrammas galapunkti un jebkurš atklāta teksta segments ārpus tuneļa joprojām ir svarīgi. Pēc tam noregulējiet savienojuma dzīves ciklu šajā robežā. Secinājums par lētāku tuneli izriet tikai no pārliecības, ka katrs pieprasījums atkārto rokasspiedienu, un tieši šī pārliecība šeit tiek pārbaudīta.

RFC 9112 noturības sadaļa ir atsauce uz to, ko atkalizmantošana patiešām sola, ieskaitot nosacījumus, kas beidz savienojumu. Izlasiet to vienreiz, pirms uzticaties mērījumam, kas tos ignorē.