Вы, верагодна, чыталі, што HTTPS адкрывае новае TCP-злучэнне і новы рукапацісканне TLS для кожнага запыту API, таму тунэль, які застаецца адкрытым гадзіну, выглядае таннейшым. Першая палова гэтага звычайна няпраўда. Падтрыманы кліент паўторна выкарыстоўвае ўсталяванае злучэнне для многіх абменаў, а вымярэнне, якое будуе новы кліент пры кожным выкліку, вымярае жыццёвы цыкл, а не абарону. Рэшта гэтай старонкі распавядае, што замест гэтага вымяраць.

Што паўторнае выкарыстанне насамрэч патрабуе

Устойлівасць — частка мадэлі HTTP, а не трук: адно злучэнне нясе некалькі абменаў запыту і адказу. Злучэнне сканчаецца, калі адзін з бакоў яго закрывае, калі сервер адклікае неактыўнае або перагружанае злучэнне, або калі загаловак або правіла пратаколу кажа, што злучэнне нельга выкарыстоўваць паўторна. HTTPS змяшчае гэтую размову ўнутры TLS, не патрабуючы новага рукапаціскання для кожнага абмену. Таму другі запыт не паўтарае рукапацісканне першага запыту, калі толькі нешта паміж імі не скончыла злучэнне.

Паўторнае выкарыстанне мае таксама адну ўмову, якую праграмы лёгка парушаюць. Кліент, які плануе паўторна выкарыстаць злучэнне, павінен прачытаць усё цела адказу, а адказ, пакінуты на паўдарозе, — звычайны спосаб, якім пул злучэнняў знікае без таго, каб хтосьці гэта заўважыў.

Праверце кліент, які падтрымлівае бібліятэка, і жыццёвы цыкл пула злучэнняў, замест таго каб меркаваць, што пул уключаны ці выключаны. Запішыце таксама ўзгодненую версію HTTP, бо HTTP/2 і HTTP/3 апрацоўваюць паўторнае выкарыстанне злучэнняў інакш, чым HTTP/1.1. Разглядайце ўзгодненую версію як частку вымярэння, а не як зноску.

Чаму параўнанне вымярае жыццёвы цыкл

Стварэнне новага кліента для кожнай аперацыі і параўнанне яго з тунэлем, які падключаны ўжо гадзіну, параўноўвае ўсталяванне злучэння са стабільным станам. Гэта легітымнае вымярэнне, і гэта не HTTPS супраць VPN. Два прагоны з той самай канфігурацыяй кліента апісваюць паводзіны лепш за адзін, асабліва калі першы прагон праграе распазнавальнік або кэш злучэнняў.

Трымайце аперацыю API, сервер, уліковы запіс і даныя нязменнымі, інакш параўнанне нясе больш за адну зменную. Вырашыце загадзя, дзе вы ставіце таймер, бо ўсталяванне, перамовы TLS, выкананне праграмы і дастаўка адказу робяць розны ўнёсак у агульны час. Адзін таймер першага запыту характарызуе ўсталяванне і нічога не кажа пра стабільны трафік, які вы насамрэч вядзеце. Запішыце межы таймера побач з лічбамі.

Аддзяліце халоднае ўсталяванне ад цёплых запытаў

Вымярайце першы запыт асобна ад тых, што ідуць за ім. Затым дадайце тое, што сэрвіс насамрэч бачыць: перыяды бяздзейнасці, усплёскі, адначасовасць, памер адказу і паўторныя падключэнні.

Пакіньце праверку сертыфікатаў і HTTPS уключанымі на абодвух шляхах, бо іх выдаленне вымярае іншы дызайн бяспекі, а не больш хуткі. Калі тунэль змяняе маршрут або месцазнаходжанне шлюза, паведаміце пра гэтую розніцу асобна, замест таго каб прыпісваць кожную змену часу шыфраванню, бо шлях, страты і чарга могуць пераважыць малы запыт. Запусціце кожны шлях двойчы па тым самым маршруце, перш чым рабіць выснову. Запішыце ўзгоднены пратакол і межы таймера пры абодвух прагонах.

Разлічвайце на злучэнне, якое закрываецца

Устойлівы не значыць вечны. Сервер, проксі або змена сеткі могуць закрыць злучэнне ў перыяд бяздзейнасці, і кліент павінен аднавіцца праз паводзіны, якія падтрымлівае яго бібліятэка. Гэтае аднаўленне мае машыну станаў: запыт мог завяршыцца на серверы або не ўдацца, перш чым сервер яго прачытаў, а закрыты сокет не кажа выклікаючаму, што адбылося. Неідэмпатэнтная аперацыя ў гэтым месцы не можа проста быць прайграна паўторна, бо паўтор ператварае невядомы вынік у падвойны запіс. Тут цёплы тунэль і цёплае злучэнне паводзяць сябе аднолькава, бо абодва могуць адмовіць у момант, калі праца ідзе.

Выкарыстоўвайце дакументаваны механізм паўторнай спробы або ідэмпатэнтнасці сэрвісу замест цыклу, які паўторна адкрывае сокет. Праверце аднаўленне яўна: зачыніце неактыўнае злучэнне і паглядзіце, што кліент робіць далей. Паўторнае адкрыццё сокета не робіць паўтор выкліку, які змяняе стан, бяспечным.

Спачатку выберыце мяжу, потым наладжвайце

Выберыце сеткавую мяжу паводле патрабаванняў доступу і даверу, перш чым нешта аптымізаваць. VPN абараняе сегмент паміж сваімі партнёрамі, а канчатковыя пункты праграмы і любы сегмент адкрытага тэксту па-за тунэлем па-ранейшаму важныя. Затым наладзьце жыццёвы цыкл злучэння ўнутры гэтай мяжы. Выснова пра таннейшы тунэль вынікае толькі з пераканання, што кожны запыт паўтарае рукапацісканне, і менавіта гэтае перакананне тут правяраецца.

Раздзел пра ўстойлівасць у RFC 9112 — гэта спасылка на тое, што паўторнае выкарыстанне насамрэч абяцае, уключаючы ўмовы, якія завяршаюць злучэнне. Прачытайце яго аднойчы, перш чым давяраць вымярэнню, якое іх ігнаруе.

Падобныя артыкулы