უფრო სწრაფია პატარა VPN MTU? შეადარეთ რეალური მტკიცებულებები
დაბალი MTU შეიძლება გვერდი აუაროს ბილიკის ზღვარს და მაინც დაგიჯდეს გამტარუნარიანობა. შეადარეთ რეალური შეზღუდვა, სათაურების ხარჯი და დატვირთვა, სანამ ცვლილებას დატოვებთ.
გვირაბი დიდ გადაცემებს ყრის, მაგრამ პინგს ატარებს, ამიტომ რჩევა სწრაფად მოდის: შეამცირეთ MTU. შესწორება ზოგჯერ მუშაობს, შემდეგ კი ყველა ქსელის ყველა პროფილზე გამოიყენება. სწორედ აქ იქცევა მიზნობრივი შეკეთება მუდმივ შესრულების გადასახადად. შედარება, რომელიც უნდა გაკეთდეს, არის ბილიკის რეალურ ზღვარსა და მის ქვემოთ ყოველი პაკეტის შემცირების ხარჯს შორის.
რა მცირდება სინამდვილეში, როცა MTU-ს ამცირებთ
ყოველი პაკეტი სათაურებს ატარებს სანამ თქვენს მონაცემებს ატარებს. 1500 ბაიტიან Ethernet ბილიკზე IPv4 და TCP 40 ბაიტს მოიხმარენ და 1460-ს ტოვებენ სასარგებლო დატვირთვისთვის; ინკაფსულაცია ზემოდან ამატებს გარე IP, UDP და გვირაბის სათაურებს, ამიტომ შიდა დატვირთვის ბიუჯეტი კვლავ ეცემა. ინტერფეისის MTU-ს შემცირება განზრახ ამცირებს ამ ბიუჯეტს.
ხარჯი პროპორციულია პაკეტების რაოდენობის, და არა ბაიტების რაოდენობის. იგივე ფაილი მეტ პაკეტად დაყოფილი მოითხოვს მეტ შეწყვეტას, მეტ მარშრუტიზაციის გადაწყვეტილებას და მეტ დამუშავებას პაკეტზე ბილიკის ყველა მოწყობილობაზე. მარშრუტიზატორზე, რომელიც უკვე ახლოსაა წამში პაკეტების ზღვართან, ეს ნამდვილი შენელებაა და არა დამრგვალების შეცდომა. ხარჯი ჩანს მაშინაც, როცა თავად გადაცემა წარმატებულია.
ამიტომ პატარა MTU შეზღუდვის გვერდის ავლაა და არა ზოგადი ოპტიმიზაცია. ის საიმედოობას ყიდულობს ბილიკთან, რომელსაც უფრო დიდი ჩარჩოს ტარება არ შეუძლია, და დამატებით ხარჯს აკისრებს ყოველ პაკეტს, რომელსაც შემცირება არ სჭირდებოდა.
როდის არის პატარა MTU სწორი შესწორება
კლასიკური სიმპტომი კონკრეტულია: TCP ხელის ჩამორთმევა სრულდება, პატარა პასუხები მოდის, ხოლო დიდი ჩამოტვირთვა ჩერდება ან გადაიტვირთება. 1472 ბაიტზე „ნუ დაყოფ“ ბიტით პინგი ვერ ახერხებს, ხოლო 1400 ბაიტიანი პინგი ახერხებს, რაც მიუთითებს ბილიკზე, რომელსაც სრული ზომის პაკეტის ტარება არ შეუძლია და არ აწვდის იმ ICMP შეტყობინებას, რომელიც გამგზავნს შემცირებას ეუბნებოდა.
ბილიკის MTU-ს აღმოჩენა ამ ICMP დაყოფის-საჭიროების შეტყობინებებზეა დამოკიდებული. როცა ქსელური ფარი მათ ყრის, გამგზავნი განაგრძობს დიდი პაკეტის ხელახლა ცდას და კავშირი ჩამოკიდებულად ჩანს. გვირაბის მხარეს MTU-ს შემცირება თავიდან იცილებს გამეორებას, და ეს იმ ქსელისთვის ლეგიტიმური შეკეთებაა.
წვდომის ტექნოლოგიებიც საკუთარ ზღვრებს აწესებენ: PPPoE ჩვეულებრივ 1492-ზე შემოიფარგლება, ზოგი მობილური და DSL ბილიკი უფრო დაბალია, ხოლო ჩადგმული გვირაბები დამატებით ხარჯს ორჯერ აკლებენ. გაზომეთ რეალური ბილიკი და არ დააკოპიროთ რიცხვი სახელმძღვანელოდან, და დაიმახსოვრეთ, რომ IPv6 მოითხოვს მინიმუმ 1280 ბაიტ MTU-ს ყოველ რგოლზე, რომელიც მას ატარებს, როგორც RFC 8200 განსაზღვრავს.
სამი მართვის საშუალების შედარება ერთის შეცვლამდე
MTU, MSS და დაყოფა სხვადასხვა დონის სხვადასხვა მართვის საშუალებაა, და არასწორის შეცვლა სიმპტომს ადგილზე ტოვებს.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS-ის შეზღუდვა ხშირად ყველაზე ნაკლებად ინვაზიური შეკეთებაა, რადგან მხოლოდ TCP-ზე მოქმედებს და ინტერფეისს სხვა ტრაფიკისთვის თავისუფალს ტოვებს. დაბალი ინტერფეისის MTU უფრო ფართოა და უფრო ადვილი გასააზრებელი, ამიტომ გავრცელებულია საოჯახო მარშრუტიზატორებზე, მაგრამ ერთი პროტოკოლის პრობლემას ყველა პროტოკოლს აკისრებს.
„ნუ დაყოფ“ ქცევის გამორთვა მალავს სიმპტომს დაყოფის დაშვებით, და ჩვეულებრივ აუარესებს დაყოვნებას, ამავდროულად არღვევს იმ უკუკავშირს, რომელიც სწორ ზომას იპოვიდა. მოერიდეთ მას მუდმივ გადაწყვეტად.
გაზომეთ კომპრომისი და არა ერთი რიცხვი
იპოვეთ ბილიკის ზღვარი „ნუ დაყოფ“ ზონდით, დაიწყეთ მაღლიდან და ჩამოდით, სანამ პასუხი მოვა:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10შემდეგ შეადარეთ რეალური ამოცანა ორივე პარამეტრზე: იგივე ფაილის გადაცემა, იგივე ბოლო წერტილი და იგივე ქსელი. ჩაწერეთ დასრულების დრო და ხელახალი გადაცემები, მაგალითად nstat -az TcpRetransSegs-ით, და აკვირდით მოწყობილობის პროცესორს, თუ გვირაბი პატარა მარშრუტიზატორზე მთავრდება. მოკლე სინთეტიკური გამტარუნარიანობის ტესტი შეიძლება გამოტოვოს ის გაჩერება, რომელიც მხოლოდ რამდენიმე მეგაბაიტის შემდეგ ჩნდება.
პაკეტების მთვლელები გაიზრდება შემცირების შემდეგ, რადგან იგივე გადაცემა ახლა მეტ პაკეტს იყენებს. ეს მოსალოდნელია და არ არის უფრო მაღალი გამტარუნარიანობის მტკიცებულება. შეადარეთ დასრულებული აპლიკაციის მონაცემები, ხელახალი გადაცემების რაოდენობა და რეაგირებადობა და არა მხოლოდ პაკეტების სიხშირე.
შეიტანეთ ცვლილება ეტაპობრივად და შეინახეთ შეზღუდული
ჩაწერეთ საწყისი მნიშვნელობა, შეცვალეთ ერთი მართვის საშუალება და გაიმეორეთ გაზომვა სანამ მას მუდმივს გახდით. თუ მტკიცებულებები სარგებელს არ აჩვენებს, აღადგინეთ წინა მნიშვნელობა იმავე ინტერფეისის ბრძანებით, რომლითაც დააყენეთ:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500შეზღუდეთ შედეგი იმ ქსელით, რომელსაც ის სჭირდებოდა. პროფილი, რომელიც სასტუმროს Wi-Fi-ზე, მობილურ hotspot-სა და ოფისის LAN-ზე უნდა მუშაობდეს, არ უნდა მემკვიდრეობით მიიღოს რომელიმე მათგანის მოთხოვნილი ყველაზე დაბალი მნიშვნელობა, თუ კლიენტი ბილიკს ვერ ამოიცნობს.
სწორი მნიშვნელობა ყველაზე დიდი MTU-ა, რომელიც ბილიკზე ცოცხლდება, და არა ყველაზე პატარა, რომელიც სიმპტომს აქრობს. დააფიქსირეთ ბილიკი, ზონდის შედეგი და უკუქცევა, და გადახედეთ პარამეტრს, როცა წვდომის ქსელი იცვლება.