VPN-ის ატვირთვა ჩამოტვირთვაზე ნელია? დაადგინეთ, რომელ ზღვარს ეჯახებით

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

სამი ზღვარი, რომლებიც პროგრესის ზოლიდან ერთნაირად ჩანს

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

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

გაზომეთ ერთი მიმართულება ერთდროულად

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

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

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

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

გადაწყვიტეთ იმის მიხედვით, სად იცვლება ატვირთვა

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

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

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

როცა გაჩერება სძლევს ნელობას

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

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

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

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

რა შეიცვალოს და რა დარჩეს

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

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