OpenVPN TCP-ზე: rto_min რიგის თავში არსებულ ბლოკირებას არ ასწორებს

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

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

სიმპტომი: ყველაფერი ერთდროულად ჩერდება

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

ის რაღაც გვირაბის სატრანსპორტო შრეა. TCP რეჟიმში OpenVPN კაფსულირებულ პაკეტებს ერთ TCP კავშირში წერს პირისკენ, ხოლო TCP-ის ხელშეკრულება ერთი ბაიტური ნაკადის რიგით მიწოდებაა. შემდგომი ბაიტები აპლიკაციას არ გადაეცემა ნაკლულამდე, რომელ შიდა საუბარსაც არ უნდა მიეკუთვნოს.

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

ერთი გარე ბაიტური ნაკადი, ბევრი შიდა საუბარი

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

ეს ერთი კავშირის შიგნით რიგის თავში არსებული ბლოკირებაა და არ მოითხოვს, რომ ორმა აპლიკაციამ შიდა კავშირი გაიზიაროს. ისინი გარეს იზიარებენ და ეს საკმარისია.

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

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

რატომ ვერ დაეხმარება გრძელი შიდა ტაიმერი

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

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

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

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

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

რას აკეთებს და რას არ აკეთებს tcp-nodelay

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

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

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

როგორ შევადაროთ ტრანსპორტები სამართლიანად

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

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

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

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