ગરમ HTTPS વિરુદ્ધ ગરમ VPN: એ જ વિનંતિ માર્ગની સરખામણી કરો
HTTPS દરેક API વિનંતિ પર હેન્ડશેક કરતું નથી, તેથી ગરમ કનેક્શન અને ગરમ ટનલ હરીફ નથી. પસંદ કરતાં પહેલાં એ જ વિનંતિ પેટર્નની સરખામણી કરો.
તમે કદાચ વાંચ્યું હશે કે HTTPS દરેક API વિનંતિ માટે નવું TCP કનેક્શન અને નવું TLS હેન્ડશેક ખોલે છે, તેથી એક કલાક ખુલ્લી રહેતી ટનલ સસ્તી લાગે છે. તેનો પહેલો અડધો ભાગ સામાન્ય રીતે ખોટો છે. સમર્થિત ક્લાયન્ટ ઘણા વિનિમયો માટે સ્થાપિત કનેક્શન ફરી વાપરે છે, અને દરેક કૉલ પર નવો ક્લાયન્ટ બનાવતું માપન જીવનચક્ર માપે છે, રક્ષણ નહીં. આ પાનાનો બાકીનો ભાગ એ વિશે છે કે તેના બદલે શું માપવું.
ફરી વાપરવું ખરેખર શું માગે છે
ટકાઉપણું HTTP મોડેલનો ભાગ છે, યુક્તિ નહીં: એક કનેક્શન ઘણા વિનંતિ-પ્રતિસાદ વિનિમયો વહન કરે છે. કનેક્શન ત્યારે પૂરું થાય છે જ્યારે બેમાંથી કોઈ પક્ષ તેને બંધ કરે, જ્યારે સર્વર નિષ્ક્રિય કે વધુ ભારણવાળું કનેક્શન દૂર કરે, અથવા જ્યારે હેડર કે પ્રોટોકોલ નિયમ કહે કે કનેક્શન ફરી વાપરી શકાય નહીં. HTTPS એ વાતચીતને દરેક વિનિમય માટે નવો હેન્ડશેક માંગ્યા વિના TLSની અંદર મૂકે છે. તેથી બીજી વિનંતિ પહેલી વિનંતિનો હેન્ડશેક પુનરાવર્તિત કરતી નથી, સિવાય કે વચ્ચે કંઈકે કનેક્શન પૂરું કર્યું હોય.
ફરી વાપરવાની એક શરત પણ છે જે એપ્લિકેશનો સહેલાઈથી તોડે છે. જે ક્લાયન્ટ કનેક્શન ફરી વાપરવાનું વિચારે છે તેણે પ્રતિસાદનું આખું શરીર વાંચવું પડે, અને અડધે રસ્તે છોડી દીધેલો પ્રતિસાદ એ કનેક્શન પૂલ કોઈને ધ્યાન ન રહેતાં અદૃશ્ય થવાની સામાન્ય રીત છે.
લાઇબ્રેરીનો સમર્થિત ક્લાયન્ટ અને કનેક્શન પૂલનું જીવનચક્ર તપાસો, પૂલ ચાલુ કે બંધ છે તેમ ધારી ન લો. સંમત થયેલી HTTP આવૃત્તિ પણ નોંધો, કારણ કે HTTP/2 અને HTTP/3 કનેક્શન ફરી વાપરવાનું HTTP/1.1 કરતાં જુદી રીતે સંભાળે છે. સંમત આવૃત્તિને માપનનો ભાગ ગણો, પાદટીપ નહીં.
સરખામણી કેમ જીવનચક્ર માપે છે
દરેક ક્રિયા માટે નવો ક્લાયન્ટ બનાવવો અને તેની એક કલાકથી જોડાયેલી ટનલ સાથે સરખામણી કરવી એ કનેક્શન સ્થાપનને સ્થિર સ્થિતિ સાથે સરખાવે છે. તે કાયદેસર માપન છે, અને તે HTTPS વિરુદ્ધ VPN નથી. એક જ ક્લાયન્ટ રૂપરેખા સાથેના બે રન એક કરતાં વર્તન વધુ સારી રીતે વર્ણવે છે, ખાસ કરીને જ્યારે પહેલો રન કોઈ રિઝોલ્વર કે કનેક્શન કેશ ગરમ કરે છે.
API ક્રિયા, સર્વર, ખાતું અને ડેટા સ્થિર રાખો, નહીં તો સરખામણી એક કરતાં વધુ ચલ વહન કરે છે. અગાઉથી નક્કી કરો કે ટાઇમર ક્યાં મૂકશો, કારણ કે સ્થાપન, TLS ચર્ચા, એપ્લિકેશન અમલ અને પ્રતિસાદ પહોંચાડવો કુલમાં જુદો ફાળો આપે છે. પહેલી વિનંતિનો એક ટાઇમર સ્થાપનનું લક્ષણ બતાવે છે અને તમે ખરેખર ચલાવો છો તે સ્થિર ટ્રાફિક વિશે કંઈ કહેતો નથી. ટાઇમરની સીમાઓ સંખ્યાઓની બાજુમાં લખો.
ઠંડું સ્થાપન ગરમ વિનંતિઓથી અલગ કરો
પહેલી વિનંતિને પછીની વિનંતિઓથી અલગ માપો. પછી ઉમેરો જે સેવા ખરેખર જુએ છે: નિષ્ક્રિય સમયગાળા, ફુટાવ, સમકાલીનતા, પ્રતિસાદનું કદ અને પુનઃજોડાણ.
બંને માર્ગો પર પ્રમાણપત્ર ચકાસણી અને HTTPS ચાલુ રાખો, કારણ કે તેમને દૂર કરવાથી અલગ સુરક્ષા રચના માપાય છે, ઝડપી નહીં. જો ટનલ માર્ગ કે ગેટવેનું સ્થાન બદલે, તો દરેક સમય ફેરફારને એન્ક્રિપ્શન પર ઢોળવાને બદલે તે તફાવત અલગ જણાવો, કારણ કે માર્ગ, નુકસાન અને કતાર નાની વિનંતિ પર પ્રભુત્વ કરી શકે છે. તારણ કાઢતાં પહેલાં દરેક માર્ગ એ જ રૂટ પર બે વાર ચલાવો. સંમત પ્રોટોકોલ અને ટાઇમરની સીમાઓ બંને રન સાથે નોંધો.
બંધ થતા કનેક્શન માટે યોજના બનાવો
ટકાઉ એટલે કાયમી નહીં. સર્વર, પ્રોક્સી કે નેટવર્ક ફેરફાર નિષ્ક્રિય સમયગાળામાં કનેક્શન બંધ કરી શકે છે, અને ક્લાયન્ટને તેની લાઇબ્રેરીના સમર્થિત વર્તન દ્વારા પુનઃપ્રાપ્ત થવું પડે છે. તે પુનઃપ્રાપ્તિમાં સ્થિતિ મશીન છે: વિનંતિ સર્વર પર પૂરી થઈ હોઈ શકે, અથવા સર્વરે તેને વાંચ્યા પહેલાં નિષ્ફળ ગઈ હોઈ શકે, અને બંધ સોકેટ કૉલ કરનારને કહેતું નથી કે શું થયું. તે સ્થિતિમાં બિન-આઇડેમ્પોટેન્ટ ક્રિયા ફક્ત ફરી ચલાવી શકાતી નથી, કારણ કે પુનરાવૃત્તિ અજાણ્યા પરિણામને બમણા લેખમાં ફેરવે છે. અહીં ગરમ ટનલ અને ગરમ કનેક્શન સમાન વર્તન કરે છે, કારણ કે કામ ચાલુ હોય તે ક્ષણે બંને નિષ્ફળ થઈ શકે છે.
સોકેટ ફરી ખોલતા લૂપને બદલે સેવાની દસ્તાવેજી પુનઃપ્રયાસ કે આઇડેમ્પોટેન્સી પદ્ધતિ વાપરો. પુનઃપ્રાપ્તિ સ્પષ્ટ રીતે ચકાસો: નિષ્ક્રિય કનેક્શન બંધ કરો અને જુઓ ક્લાયન્ટ પછી શું કરે છે. સોકેટ ફરી ખોલવું સ્થિતિ બદલતા કૉલની પુનરાવૃત્તિને સુરક્ષિત બનાવતું નથી.
પહેલા સીમા પસંદ કરો, પછી ગોઠવો
કંઈ પણ ઑપ્ટિમાઇઝ કરતાં પહેલાં પ્રવેશ અને વિશ્વાસની જરૂરિયાતોમાંથી નેટવર્ક સીમા પસંદ કરો. VPN તેના સાથીઓ વચ્ચેનો ભાગ રક્ષે છે, જ્યારે એપ્લિકેશનના અંતિમબિંદુઓ અને ટનલની બહારનો કોઈ પણ સ્પષ્ટ લખાણનો ભાગ હજી પણ મહત્વનો છે. પછી તે સીમાની અંદર કનેક્શનનું જીવનચક્ર ગોઠવો. સસ્તી ટનલનું તારણ ફક્ત એ માન્યતામાંથી આવે છે કે દરેક વિનંતિ હેન્ડશેકનું પુનરાવર્તન કરે છે, અને અહીં એ જ માન્યતા ચકાસાય છે.
RFC 9112માં ટકાઉપણાનો વિભાગ એ ફરી વાપરવું ખરેખર શું વચન આપે છે તેનો સંદર્ભ છે, જેમાં કનેક્શન પૂરું કરતી શરતોનો પણ સમાવેશ છે. આવા માપન પર ભરોસો મૂકતાં પહેલાં તેને એક વાર વાંચો જે તેમને અવગણે છે.