რატომ ჩანს VPN-ით ფაილების გაზიარება ნელი: ორმხრივი მგზავრობები, არა Mbps

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

დისტანციურ სამუშაო ასლს არასწორი ფორმა აქვს

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

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

დათვალეთ ორმხრივი მგზავრობები მეგაბაიტებამდე

გაზომეთ დაყოვნება სანამ სიმძლავრეს იყიდით. ერთი ping გეტყვით, რას იხდის ყოველი გაცვლა.

ping -c 10 fileserver.example.net

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

გადაიტანეთ სამუშაო, არა ბაიტები

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

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

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

ერთსა და იმავე ზომაზე შეჩერება MTU-ის სიმპტომია

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

ping -M do -s 1400 -c 3 fileserver.example.net

წარმატებული ცდა ნიშნავს, რომ 1428-ბაიტიანი IP პაკეტი გზას ფრაგმენტაციის გარეშე გადის, რადგან ICMP და IP სათაურები 28 ბაიტს ამატებს. წარუმატებლობა დაუფრაგმენტების დროშით მიუთითებს, რომ გვირაბის გამოსადეგი MTU უფრო მცირეა, ვიდრე სერვერი ვარაუდობს. სერვერი, რომელიც 9000-ბაიტიან ბუფერებს 1500-ბაიტიან გზაზე აგზავნის, აიძულებს ფრაგმენტაციას ან ჩამოშლას, და გზის MTU-ის აღმოჩენა შეიძლება ჩუმად ჩავარდეს, როცა ICMP იფილტრება. შეამცირეთ გვირაბის MTU, ჩართეთ mssfix OpenVPN-ში, ან შეამცირეთ სერვერის ბუფერები, შემდეგ ხელახლა გაუშვით იგივე გადაცემა დასადასტურებლად.

გაზომეთ ის სხვაობა, რომელსაც მნიშვნელობა აქვს

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

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