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

განვიხილოთ HTTPS მოთხოვნა, რომელიც უკვე CONNECT-ის შიგნითაა. აქტიური პროქსი ფლობს კლიენტისკენ მიმავალ TCP კავშირს და საიტისკენ მიმავალ კიდევ ერთ კავშირს. ის ასევე ფლობს იმ აპლიკაციურ მდგომარეობას, რომელიც ამ ნაკადებს აერთებს.

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

მოლოდინიუზრუნველყოფს ამას ჩვეულებრივი მისამართის გადართვა?
ერთი კონფიგურირებული შესასვლელის შენარჩუნებაეს არის განზრახული უპირატესობა
დამკვიდრებული CONNECT ნაკადის გაგრძელებასაჭირო იქნებოდა დამატებითი მდგომარეობის მექანიზმი
იგივე გარე საჯარო IP-ის შენარჩუნებადამოკიდებულია გასასვლელ მარშრუტიზაციაზე და NAT-ზე
შეწყვეტილი აპლიკაციური ოპერაციის უსაფრთხოდ გამეორებადამოკიდებულია ოპერაციასა და კლიენტზე

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

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

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

დაკავშირებული სტატიები