VPN გვერდის შუაში გაითიშა: ფონური მოთხოვნები კვლავ გადის?

ჩანართი კვლავ აჩვენებს დაფას იმ მომენტამდე, სანამ გვირაბი მოკვდებოდა. სტატუსის რიცხვები იყინება, პატარა მბრუნავი აგრძელებს ტრიალს და მისამართის ზოლი კვლავ ატარებს იმ აპს, რომელიც საათის წინ გახსენით. გათიშვის შემდეგ არაფერს შეხვედით, მაგრამ გვერდი შეიძლება კვლავ ცდილობდეს საკუთარ სერვერთან მისვლას საკუთარი გრაფიკით. სწორედ ამას უშვებენ ხალხი ხელიდან: გვერდი, რომელიც მხოლოდ ჩანს, და გვერდი, რომელიც კვლავ აგზავნის მოთხოვნებს, გარედან ერთნაირად გამოიყურება და მათგან მხოლოდ ერთი ჩნდება ქსელის ჟურნალში.

სამუშაო, რომელსაც გვერდი თქვენ გარეშე იწყებს

ოთხი მექანიზმი დატვირთულ დოკუმენტს დაკავებულად ინახავს. განმეორებად ტაიმერს შეუძლია ყოველ რამდენიმე წამში სტატუსის გამოძახება ხელახლა გაუშვას. fetch შეიძლება გააქტიურდეს, როცა ჩანართი თქვენი დაბრუნების შემდეგ კვლავ ხილული ხდება. WebSocket-ზე ან სერვერის მიერ გაგზავნილ მოვლენებზე აგებულ ცოცხალ არხს შეუძლია საკუთარი უკანდახევის გრაფიკით ხელახლა დაკავშირება სცადოს. საიტის მიერ რეგისტრირებულ service worker-ს შეუძლია რიგში ჩასმული სინქრონიზაციისთვის გაღვიძება მაშინაც, როცა თქვენ წინ ჩანართი არ არის.

არც ერთი მათგანი არ საჭიროებს დაწკაპუნებას და არც ერთი არ გადატვირთავს დოკუმენტს. მისამართის ზოლი, გადახვევის პოზიცია და ნაჩვენები მნიშვნელობები ყველა თავის ადგილზე რჩება. იცვლება მხოლოდ ქსელის მხარე: ყოველი ახალი მცდელობა არის ახალი გადაწყვეტილება, მიღებული იმ მომენტში, როცა ის იწყება.

ეს განსხვავება მნიშვნელოვანია, რადგან ხილული გვერდი ლოკალურად ინახება. უკვე დახატული პიქსელები არაფერს ამბობენ იმაზე, წარმატებული იყო თუ არა შემდეგი მოთხოვნა. გაყინული გრაფიკი მბრუნავით არის გვერდის ჩვეულებრივი იერი, რომლის მოთხოვნები ახლა ფარცხდება. ეკრანის კითხვა გეუბნებათ, რა თქვა სერვერმა რამდენიმე წუთის წინ, და არა ის, რასაც ბრაუზერი ახლა აკეთებს.

რატომ არ ინახავს გვერდის ადრინდელი ჩატვირთვა მარშრუტს

გვერდის ჩატვირთვაში არაფერი აკავშირებს დოკუმენტს გვირაბს. მარშრუტიზაცია წყდება თითოეული პაკეტისთვის, გაგზავნის მომენტში, იმ ცხრილიდან, რომელიც არსებობს პაკეტის გასვლისას. როცა გვირაბის ინტერფეისი ქრება, ეს ძებნა აღარ ემთხვევა გვირაბის მარშრუტს. ის ან ფიზიკურ ადაპტერზე ვარდება, ან საერთოდ ვერაფერს პოულობს, იმის მიხედვით, რა დატოვა კლიენტმა უკან.

განმეორებადი უკუგამოძახებები ჩვეულებრივი დაგეგმილი ამოცანებია. HTML სტანდარტის ტაიმერების ნაწილი აღწერს, როგორ ხვდებიან ისინი რიგში და ინტერვალს განიხილავს როგორც მინიმალურ დაყოვნებას და არა ზუსტი რიტმის დაპირებას, ამიტომ ფონურ ჩანართს შეუძლია გაცილებით იშვიათად გამოკითხოს, ვიდრე მისი კოდი ითხოვს. ნაკლები მცდელობა არ ნიშნავს მცდელობის არარსებობას და ჩანართის წინ წამოწევა მათი აფეთქების ჩვეულებრივი მომენტია.

სად ვარდება წარუმატებლობის პოლიტიკა

კლიენტის ბლოკირება ფასდება მაშინ, როცა კავშირი სცდება, და არა მაშინ, როცა გვერდი ჩამოიტვირთა. თუ ჩვეულებრივი წვდომა ჯერ კიდევ ნებადართულია, განმეორებითი მცდელობა შეიძლება ფიზიკური ბმულით ღიად გავიდეს. თუ პოლიტიკა აჩერებს ამ ტრაფიკს გვირაბის დაბრუნებამდე, მცდელობა ფარცხდება დაკავშირების მომენტში და გვერდი აჩვენებს შეცდომას, რომელსაც რამდენიმე წამში შეიძლება ხელახლა სცადოს.

ორი დეტალი განსაზღვრავს, რომელს მიიღებთ. პირველია ის აღსრულების არე, რომელსაც კლიენტი უჭერს მხარს: ბლოკი მთელი მოწყობილობისთვის, გვირაბის ადაპტერით შემოფარგლული ბლოკი, ან გამონაკლისებიანი წესების ნაკრები. მეორეა, ხვდება თუ არა დანიშნულება ადრე დამატებულ გამონაკლისში ლოკალური პრინტერის, ტყვე პორტალის ან სტრიმინგ სერვისისთვის.

აპლიკაციის დონის დაშიფვრა ამაში არაფერს ცვლის. HTTPS იცავს ბაიტებს ბრაუზერსა და სერვერს შორის; ის არაფერს ამბობს იმაზე, რომელი ინტერფეისი ატარებს მათ. გვერდი შეიძლება სრულყოფილად დაშიფრული იყოს და მაინც არასწორი გზით გავიდეს, და ზუსტად ამას უშვებს ვიწრო ბლოკი.

კონტროლირებადი შემოწმება ერთჯერადი გვერდით

გამოიყენეთ თქვენს კონტროლქვეშ მყოფი ჰოსტი და გვერდი, რომელიც არაფერს აკეთებს გარდა მისი გამოძახებისა, რომ თამაშში რეალური მონაცემები არ იყოს. ტერმინალიდან აიღეთ ბილიკის ნიმუში გათიშვამდე და მის შემდეგ:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

გაუშვით ის გვირაბით აწეული, შემდეგ ჩამოწიეთ გვირაბი და ისევ გაუშვით. პასუხი საჯარო მისამართიდან, როცა გვირაბი ჩამოშვებულია, გეუბნებათ, რომ პირდაპირი ბილიკი ღიაა. ვადის ამოწურვა ან უარყოფილი კავშირი გეუბნებათ, რომ პოლიტიკა იჭერს. გაიმეორეთ კიდევ ერთხელ მას შემდეგ, რაც კლიენტი ხელახლა დაუკავშირდება, რომ დაინახოთ გვირაბის ბილიკის დაბრუნება და არა ჩათვალოთ, რომ ასე მოხდა.

ბრაუზერში ქსელის პანელი ყოფს ორ კითხვას. გაფილტრეთ Fetch/XHR-ზე, შემდეგ წაიკითხეთ ინიციატორის სვეტი: ჩანაწერი, რომელიც ტაიმერმა ან სკრიპტმა დაიწყო, მანამდე დაფიქსირებული ნავიგაციის გარეშე, ფონური მცდელობაა და არა გადატვირთვა. შეადარეთ მისი დაწყების დრო იმ მომენტს, როცა გვირაბი გაითიშა. თუ ჩანაწერი ჯერ კიდევ მოლოდინშია, როცა გვირაბი წავიდა, მოთხოვნა ელოდება ბილიკს, რომელიც აღარ არსებობს.

სერვერის მხარეს მტკიცებულება უფრო ძლიერია, ვიდრე ყველაფერი, რასაც ბრაუზერი აჩვენებს. მოთხოვნების ჟურნალი დროის ნიშნითა და წყაროს მისამართით ამტკიცებს, რომ პაკეტი ჩამოვიდა. ბრაუზერის ჩანაწერებს შეუძლიათ ატარონ ქუქიები, ტოკენები და სრული URL-ები, ამიტომ შეინახეთ მხოლოდ ის ველები, რომლებიც თქვენს კითხვას სჭირდება, და დანარჩენი დაფარეთ, სანამ სადმე ჩასვამთ.

რა ვუყოთ პასუხს

თუ ფონური მცდელობები კვლავ წარმატებულია, სანამ გვირაბი ჩამოშვებულია, ბლოკი უფრო ვიწროა, ვიდრე ვარაუდობდით, და ეს ნაპრალი ღირს დაიხუროს მანამ, სანამ სენსიტიურ სამუშაოს კლიენტს მიანდობთ. თუ ისინი ფარცხდება, პოლიტიკა თავის საქმეს აკეთებს და გაყინული გვერდი მხოლოდ გარეგნულია. ყოველ შემთხვევაში, ერთი ჩანართის დახურვა არ არის მოწყობილობის მასშტაბის კონტროლი: სხვა ჩანართები, სხვა ბრაუზერები და სხვა აპლიკაციები თითოეული თავის სამუშაოს გეგმავს.

ღირსეული შემდეგი ნაბიჯები: ჩამოთვალეთ, რომელი გამონაკლისები და რატომ დაამატეთ, დაადასტურეთ, ბლოკავს კლიენტი მხოლოდ გვირაბის არეში არსებულ ტრაფიკს თუ მთელ ტრაფიკს, და დააკვირდით ერთ ფონურ მოთხოვნას თავიდან ბოლომდე სერვერის ჟურნალით გახსნილი. ეს სამი პასუხი ფარავს იმის უმეტეს ნაწილს, რასაც «VPN გაითიშა და რაღაც კვლავ დაკავშირებულია» ტიპის მოხსენება რეალურად შეიცავს.